Kubernetes SIG Release 2020 年度会议纪要解析发布工具迁移、节奏决策与 CI Signal 演进【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community2020 年是 Kubernetes 发布工程体系发生关键转折的一年基于 Bash 的anago发布脚本开始逐步迁移到 Go 实现的krelSIG Release 围绕一年 3 次还是 4 次发布展开了贯穿全年的节奏讨论CI Signal 从 Release Team 的临时角色升格为常设子项目同时完成了 1.19、1.20、1.21 三个版本周期与多项支持政策决策。本文以仓库中 sig-release/meeting-notes-archive/2020.md 记录的全年会议纪要为主干结合 release.md、cherry-picks.md、charter.md 与 annual-report-2020.md 等仓库文档完整还原这一年 SIG Release 的工作脉络帮助你理解 Kubernetes 发布体系从手工脚本走向可维护工具链的演进逻辑以及发布节奏、支持政策、CI 治理这些核心机制的运作方式。一、2020 年 SIG Release 工作全景从会议纪要看全年主线2020.md 记录了 2020 年 1 月至 12 月共 17 次会议其中 6 月 2 日会议取消全年会议有固定的固定议题Recurring Topics 开放讨论Open Discussion结构。固定议题通常包括子项目更新Licensing、Release Engineering、Release Team、CI Signal 四个子项目对应四个 GitHub Project Board新增 Kubernetes 仓库 issue 检视项目看板Project boardwalk-through待分流needs-triageissue 与 PR 检视。从年度报告 annual-report-2020.md 的回顾看2020 年 SIG Release 的亮点包括引入 Program Manager 角色、建立专门的 issue 分流会议、构建长期愿景路线图、持续优化发布周期时间点与配套工具。全年最核心的技术主线可以归纳为四条发布工具现代化anagoBash→krelGo的逐步替换目标是让非 Google 员工也能发布 Kubernetes 版本发布节奏决策一年 3 次还是 4 次发布的反复论证与社区反馈收集CI Signal 子项目化从 Release Team 内的临时岗位变成跨版本持续运作的常设子项目支持政策与制品管理1.19 一年补丁支持政策落地、WG LTS 收尾、镜像与制品管理重构。下文按主题逐条展开其中版本周期细节严格以会议纪要为准。二、发布工程现代化anago 迁移到 krel2.1 迁移背景与目标从 1 月 27 日的会议记录可以看到当时的发布工作高度依赖 Bash 编写的anago脚本且暴露了明显问题关联数组遍历逻辑错误、顶层控制逻辑过于复杂难以调试。会议明确表达了意图替换 anago的态度这也是 krel 项目存在的直接原因。krel 的初始目标在 2 月 24 日会议上被明确让非 Google 员工也能发布版本发布镜像、发布并签名 deb/rpm 包更易维护的实现更多人可参与、无需特殊权限即可本地开发与测试、模块更小、每个模块都有 CI 覆盖的单元测试。2.2 2020 年内的迁移里程碑2 月krel 成功用于 fast-forward 操作同时提交了移除branchff的 PR团队开始逐步将更多组件切换到 krel当前阶段是复刻功能Bash → Go而非增强重构。2 月 10 日krel 的gcbmgr子命令开发中对应 Google Cloud Build 管理提出由 krel 生成 relnotes.k8s.io 更新。8 月 11 日k/release 发布 v0.4.0包含大量新镜像构建与 krel 改进Bash 库向 Go 的移植进展顺利团队期望 2020 年底前完成 anago 替换。12 月 1 日krel 被视为功能完备feature completekrel stage/release已在真实发布中投入使用但仍有少量公告生成相关的后续工作在进行团队明确最初是模仿 anago 行为现在可以开始优化改进方向包括分支/标签与 changelog 生成、直接从 Google Cloud Build 做镜像晋升image promotion、JSON 格式的 Release Notes/Changelog。2.3 与发布流程的配套讨论迁移过程中还牵出了若干发布流程问题changelog 生成时机当时流程是先打 tag再生成 changelog再提交 changelog。如果从 release tag 构建changelog 就不属于发布的一部分因此需要讨论从 HEAD 或其他 tag 之后的提交构建、或改变版本打标方案changelog 归属kubeadm 等从 k/k 拆出的仓库是否各自维护 changelog当时倾向由 SIG Release 工具作为聚合器把多个仓库的 changelog 汇总到 k/k 单一位置形成统一的Kubernetes 项目 changelogtagging/branching 流程重构相关 RFC 与 anago 原型在 1 月 13 日会议上被提出核心是摆脱 anago 对固定仓库、固定分支体系master、release-1.YY的硬编码假设。2.4 迁移中的真实故障案例1 月 13 日的会议记录了一个典型事故补丁发布代码本应按打 v1.16.3 tag → 提交 openapi-spec 版本化文件 → 打 v1.16.4-beta.0 tag的顺序执行实际却变成了提交 openapi-spec 文件 → 打 v1.16.5-beta.0 → 打 v1.16.4。团队不得不排查为何一组串行 Bash 命令的执行顺序与代码不符是 GCB 行为异常还是对 Bash 的理解有误并确认需要移除构建代码中提交 openapi-spec 的 Bash 逻辑。这类事故正是推动工具迁移的直接动力。三、发布节奏之争一年 3 次还是 4 次3.1 讨论起点2020 年初 Kubernetes 的常规节奏是约 3 个月一个版本、一年 4 次发布。3 月 9 日会议上WG LTS 提出一年 3 次、每次 4 个月的替代方案如果一次同时支持 3 个版本、每个版本获得 12 个月补丁支持那么 Release Team 的志愿者承诺期需要从当时的 12 周延长到 16 周同时要评估 k/release 及关联仓库的打标、分支等工具可维护性成本。3.2 社区反馈收集9 月 22 日会议上Stephen Augustus 提到其发起的科学 Twitter 投票3 次还是 4 次获得了超过 700 票12 月 1 日会议上则明确自 keynote 以来收到大量反馈但还不到做决定的时候并安排了 Action Item各 Leads 汇总反馈Stephen 负责向 k-dev、CNCF TL 与 SIG Contributor Strategy 等列表再次征询更广泛社区意见12 月 15 日会议上Jeremy/Nabarun 被指派讨论名义排期notional schedules比较一年 3 次与 4 次两种方案用于后续对外发布的信息摘要。3.3 讨论中的关键观点从纪要看支持放缓节奏的理由包括减少开发者的人为苦役、降低新功能质量风险、给消费者更多喘息空间而反对者则指出最终用户受影响最大任何节奏调整都应当尽早、频繁、大声地与用户沟通。会议还讨论了如果节奏放缓可考虑将 1.20 顺延到 12 月、2021 年恢复正常节奏或安排一个稳定性发布stability release作为过渡。3.4 后续落地该议题在 2021 年通过 KEP-2572: Release Cadence 正式落地为一年 3 次发布。这一点在年度报告 annual-report-2020.md 的 KEP 工作列表中已有记载属于 2020 年启动、跨年完成的工作。四、支持政策决策WG LTS 收尾与 N-3 支持4.1 9 月 22 日的关键决策9 月 22 日会议完成了 WG LTS 的状态宣读与存续决策核心结论1.19 及更新版本将获得 1 年的补丁发布支持1.17、1.18 是否获得 N-3即同时支持最近 3 个版本还是 9 个月支持取决于是否有社区共识否则维持原状会议最终达成共识结束 WG LTS——该工作组已产出了有价值的讨论与具体成果剩余问题可以交给 SIG Release 等更有资源的组织继续推进同时安排 Action Item向 steering 提交最终报告记录决策、成果与待办工作流。4.2 N-3 政策的推算逻辑会议以实际时间线论证了3 个版本支持 ≈ 1 年支持1.20 计划 2020-12-08 发布则 1.172019-12-05 发布按 3 版本政策可获得约 1 年支持1.21 预计不早于 2021 年 3 月底则 1.182020-03-25 发布同样约 1 年而 1.16 已退出支持实际也获得了约 1 年。若按 9 个月政策1.17 与 1.18 会在 2020 年 10 月、12 月分别退出支持。4.3 仓库文档中的政策固化这一政策在 release.md 的定义部分被正式固化release branch 在 vX.Y-rc.0 时创建发布后约 12 个月内以 vX.Y.Z 补丁发布维护1.19 及更新版本获得 1 年补丁支持1.18 及更早版本为 9 个月。cherry-picks.md 的Unsupported Releases一节也说明1.19 支持约 1 年1.18 及更早约 9 个月源自 N-3 加季度发布节奏并记录了 2019 年 1 月对已停止支持版本做例外 backport 的案例及其判定标准CI 仍可用、回归由补丁引入、问题严重度足够、修复小而可控。五、1.19 发布周期时间线变更与四种排期方案5.1 疫情背景下的排期讨论4 月 21 日会议专门讨论了 1.19 的发布时间线变更核心矛盾是当时社区处于特殊时期希望减少开发者与最终用户的负担同时又不希望打破质量底线。会议提出的排期选项如下时间点以会议记录为准事件常规日期3 周6 周8 周Enhancements freeze5 月 5 日5 月 12 日5 月 19 日5 月 19 日Code freeze6 月 11 日6 月 9 日6 月 18 日6 月 18 日Cherry pick deadline6 月 25 日6 月 25 日7 月 31 日7 月 30 日Release target6 月 30 日7 月 21 日8 月 18 日8 月 25 日各方案的后果分析3 周方案仍存在enhancements freeze 后很快进入 code freeze的紧张感6 周与 8 周方案则允许 1.20 在 12 月发布、鼓励/要求特性分支开发、且 enhancements freeze 与 code freeze 间隔短意味着只有更小、更接近完成的东西能进入本版本。8 周方案的附注还提到更长的 Code Freeze并增加了两周发布黑窗期以补偿 KubeCon。5.2 1.19 最终执行时间线5 月 5 日会议公布了 1.19 的最终排期4 月 13 日第 1 周发布周期开始5 月 19 日第 6 周Enhancements Freeze6 月 25 日第 11 周Code Freeze7 月 9 日第 14 周文档必须完成并评审8 月 4 日第 17 周Kubernetes v1.19.0 发布8 月 20 日第 19 周发布回顾Retrospective。从后续会议记录可以看到1.19.0 因给测试留出浸泡时间soak time而推迟到 8 月 26 日周三发布1.19.0-beta.0 于 5 月 19 日发布并包含了更新后的基础镜像与自动生成的 Go 依赖报告Dependencies Added/Changed/Removed。8 月 25 日与 9 月 8 日两次会议专门举行了 1.19 发布回顾Retro分两部分。5.3 1.19 周期内的其他流程调整去掉 fast-forwardFF阶段4 月 7 日会议讨论在 1.19 中移除 fast-forwards减少 alpha 数量、增加 beta、为周期增加一个 RC分支管理3 月 23 日讨论是否延后创建 release branchCode Thaw 太晚Code Freeze 或许足够因为早期分支主要为了额外 CI 信号、对 master 到 release branch 的提交做二次确认、演练工具链与升级测试合并限制受 1.19 长 Code Freeze 影响1.20 周期开头仍保留了 milestone 限制9 月 22 日会议决定解除该限制回到仅在 freeze 期间要求 milestone。5.4 版本周期与里程碑机制关于 Code Freeze、Enhancements Freeze 与 milestone 的机制细节可参考 release.mdEnhancements Freeze在发布周期约第 4 周开始是所有 KEP 必须完成以进入本版本的截止时间Code Freeze约在第 12 周开始、持续约 2 周期间只合入关键 bug 修复版本周期大体分为三个阶段Enhancement Definition、Implementation、Stabilization但 Kubernetes 依赖持续集成保证任何时刻 master 都稳定而不是靠收尾阶段兜底里程碑自动化目前覆盖 kubernetes/enhancements、kubernetes/kubernetes、kubernetes/release、kubernetes/sig-release、kubernetes/test-infra 等仓库master 分支 PR 合并后自动打 milestonerelease 分支 PR 创建时即自动打 milestone。六、CI Signal 子项目从临时岗位到常设子项目6.1 起源与动机1 月 13 日会议首次系统提出创建 CI Signal 子项目如果 CI Signal 是子项目就能获得跨版本的连续性而不必在每个发布周期随 Release Team 大规模轮换同时可以扩大盯 issue的人群不再局限于 Release Team 里的一两位 lead 与 shadow。但 Release Team 中的 CI Signal 角色仍然必要——他们向 Release Team 汇报状态为 go/no-go 发布决策提供依据。6.2 2020 年内的推进3 月 9 日讨论 CI Signal 子项目 RFCsig-release 仓库 issue #966Stephen 提出需要剥离提案中关于范围的争议部分并把界定范围作为该小组的首要任务6 月 16 日提议 Jorge 与 Sascha 担任 SIG Technical Leads与 CI Signal 工作直接相关lazy consensus 截止 6 月 18 日8 月 11 日CI Signal 子项目正式成型Jorge 为执行负责人、Dan M. 为联合 owner其使命是像今天 Release Team 的 CI Signal 团队一样工作但面向所有 release 分支并负责定义 release-blocking 与 release-informing 的形态10 月 6 日 / 10 月 20 日CI Signal 报告工具开发中如 Flaking Jobs 示例输出目标是让 CI Signal 少一点魔法、多一点科学先把收到 testgrid 告警后该怎么办的 happy path 文档化。6.3 CI 质量与 flake 治理贯穿全年的另一条线是 CI 稳定性治理8 月 11 日提到为所有 release-blocking job 配置资源 limits/requests初期增加了 flake 数量但换来的是可诊断性9 月 22 日讨论 Testgrid 对green/red的启发式判断无法理解版本轮换导致的信号不连续问题10 月 20 日讨论 flake issue 的分流与让开发者易读的 flake 报告、以及 flake issue 的 lint 规范化。这些工作与 SIG Testing 紧密协作属于 CI 治理的长期投入。七、里程碑、标签与合并治理7.1 9 月 22 日的里程碑机制讨论1.19 的超长 Code Freeze 留下了大量待合并 PR1.20 周期开始时仍保留 milestone 限制。会议围绕解除还是保留展开支持解除保留会增加摩擦里程碑要求的本意是让掌握项目健康度的人做 bug/feature 合并决策但各 SIG 的 triage 质量参差机械增加 milestone maintainers 人数并无帮助支持保留作为持续 triage 活动的一部分结论移除 k/k 的 milestone 限制回到仅 freeze 期间要求 milestone在 milestone 教育与标准传达清楚之前避免大幅变动 milestone maintainers 名单重新评估更优质的质量门禁如 WG Reliability 提出的方案。会议同时指出 milestone maintainers 团队由 release team leads 与各 SIG 指派的 milestone maintainers通常是 SIG lead组成而何时必须打 milestone多年来的标准并不统一tracked features/enhancements 一直要求、release 周期中后期freeze 后要求、其他条目不要求、多数人工应用而部分自动应用。7.2 标签体系的硬性要求release.md 给出了 PR 合入所需的标签清单Prow 命令形式常规开发期第 1-11 周/sig {name}、/kind {type}、/lgtm、/approvedCode Freeze第 12-14 周额外要求/milestone {v1.y}且kind仅限bug、failing-test发布后第 14 周以后回到常规要求合入 v1.y 分支一律走 cherry pick由 Release Managers 批准。优先级标签决定升级路径与是否阻塞发布priority/critical-urgent视为 release-blocking永不自动移出 milestoneCode Freeze 期间需要 issue owner 每日更新priority/important-soon在 Code Freeze 后 4 天宽限期自动移出priority/important-longterm更宽松。kind 标签api-change、bug、cleanup、design、documentation、failing-test、feature、flake 等则帮助 Release Team 理解版本中变更类型的构成评估更快发布节奏可能遗漏的问题类型。八、Cherry Pick 与补丁发布治理8.1 2020 年的补丁发布节奏从会议记录看补丁发布基本保持每月一次1 月 13 日预告 1.17.1、1.16.5、1.15.8以及可能需要的 1.14.115 月 19 日提到次日补丁发布7 月 14 日讨论 7 月 15 日的 k8s 补丁发布是否会因 Golang 安全公告而推迟8 月 25 日安排最终 1.16 补丁1.16.15在 9 月 2 日发布cherry pick 截止为 8 月 28 日周五。8.2 Cherry pick 的评审要点9 月 22 日与 7 月 14 日会议讨论了 cherry pick 的适用性与治理cloud provider 想为新的、此前未知的场景添加支持时需要区分复杂大特性不太可能 backport与简单改动如向 VM 类型列表追加新类型可以考虑评审标准参考 cherry-picks.md 中什么样的 PR 适合 cherry pick一节。该文档明确规定仅有以下类型可 backport安全修复仅为了安抚扫描器、不修复实际漏洞的依赖升级不可 backport回归修复仅发生在默认关闭的 alpha 特性上的回归不可 backport关键 bug 修复数据丢失、内存破坏、panic、崩溃、挂起关键依赖升级的前置变更如 Go 版本升级稳定 release 分支上失败/flaky 测试的 test-only 变更。8.3 Cherry pick 实操流程cherry-picks.md 记录的实操要点使用hack/cherry_pick_pull.sh upstream/release-3.14 98765形式发起对每一个受支持分支按从新到旧顺序依次发起PR 会立即被打上do-not-merge/cherry-pick-not-approved标签最终由 Release Manager 通过 GitHub review 批准cherrypickapprovedProw 插件负责打上cherry-pick-approved并移除拦截标签Release Manager 团队至少每周、.0 版本 burn down 期间每天扫描 incoming cherry picks。Cherry pick PR 通常被节流metered合入 release 分支以获取更审慎的 CI 信号因此你的 PR 需要在 deadline 前准备好合并但不一定立刻被合入。九、制品管理与镜像构建演进9.1 基镜像与 distroless 迁移2020 年 Release Engineering 在镜像领域做了大量工作5 月 19 日debian-base / debian-iptables 基础镜像迎来久违的更新这些镜像长期存在零散 CVE需要持续跟进go-runner 镜像投入使用1.19.0-beta.0 即包含更新后的基镜像8 月 11 日介绍新的 Go Runner 镜像——在 distroless static 镜像之上封装的糖让部分镜像更轻量1.19 起核心组件镜像开始使用Debian 基镜像切换到 Buster 并合入安全更新如 Perl 的 CVE8 月 25 日Debian 基镜像引入新的镜像 tag 格式os_codename-vx.y.z如buster-v1.0.0go-runner 镜像构建迁移到 k/releasedistroless static 镜像有 static-debian9 / static-debian10 两个流命名中需要体现这些信息12 月 1 日讨论 etcd 镜像是否还需要自建只是基础镜像上的 etcd 加一个迁移脚本以及 migrate-if-needed.sh 迁移脚本 的升级测试依赖问题相关 KEP 包括 sig-release 下的 1729-rebase-images-to-distroless 等。9.2 制品管理CIP、BOM 与 artifactsCIPk8s-container-image-promoter10 月 20 日与 12 月 1 日两次讨论其改进对应 k8s-container-image-promoter 仓库的改进 issueCIP 当时不可作为库导入Promobot 文件被 KOPs 使用首要步骤是让 CIP 进入可导入状态最终目标是把所有工具移入 k/releaseBOMBill of Materials多次被列为下一年路线图项目标是产出一份 JSON说明发布中哪些内容是可消费的制品存储接口抽象讨论通用 store 接口例如 gc2gcs 是否可对接 S3 或其他接口以应对GCR 被 Google Artifacts Registry 取代这类场景发布入口push-build 脚本发布 API 引用/版本标记到 bucketdl.k8s.io指向 gs://kubernetes-release/release bucket绝大多数发布流程发生在 Google Cloud 上后续计划建设 deb/rpm 发布故事并推动 artifacts 仓库归 Kubernetes 组织、由 Release Engineering 全局管理。9.3 安全相关CVE 信息与 changelog10 月 20 日讨论了 CVE 信息进入 changelog 的流程对应 k/release 的相关 PR需要在最后一刻才公开漏洞细节因此存在打补丁发布的人直到最后一刻才知晓 CVE的矛盾会议提出要定义补丁发布工作流是否将 mapfile 提升到 GCS、是否需要私有机制生成 release notes并咨询 Product Security Committee。十、架构与平台支持ARM64 与 Illumos10.1 ARM64 测试信号正式化6 月 30 日会议详细讨论了 ARM64 支持当时已可用 kubeadm/kops 部署 arm64 conformance 测试集群相关 Testgrid 看板包括 conformance-arm、sig-node-arm64、kops-aws-arm64 等讨论重点是把 ARM64 的 CI job 加入 release-informing 看板、逐步把测试报告推进到 release-blocking。会议特别澄清措辞这不是initial support早已有之而是额外的测试信号与质量保证。存在的差距包括SIG Node 就绪度评估、SIG Architecture 对全局支持某架构/发行版流程的看法、federated 测试的 host 网络问题、以及是否需要 RPM/Deb 等额外构建产物。10.2 Illumos 支持提议6 月 16 日会议收到来自 illumos 社区OpenSolaris 的延续的问候Till Wegmueller 计划起草 KEP为 Kubernetes 增加 illumos zones 容器支持与 Linux、Windows 并列。Illumos 有稳定的接口与 CRI/CNI 实现但会牵动 dev/test/release/conformance 全流程需要与 SIG Architecture 讨论。十一、会议运营与协作机制11.1 会议结构与年度调整固定时间块年度报告 annual-report-2020.md 显示2020 年 SIG Release 每周有 45 分钟例会SIG 全体与 Release Engineering 各一场每场约 20 人并优化出固定结构20 分钟项目看板 walk、20 分钟非正式状态更新、最后 5 分钟开放讨论12 月 15 日会议提出 2021 年改进方向更聚焦砍掉固定议题把重心放在walking the board上要求议题先发到邮件列表使会议更有目的性12 月的会议取消2021 年 1 月恢复1 月 13 日 / 2 月 24 日多次讨论调整会议时间Doodle 投票因为新贡献者分布在各地时区。11.2 协作与沟通改进沟通机制8 月 11 日讨论重大更新的最有效沟通渠道——部分 SIG 用 GitHub也有人建议 HackMD会议笔记还应发到 SIG leads 列表因为如果你是 lead就该关注那个列表Josh Berkus 建议在 Release Lead handbook 中增加排期变化时更频繁更新的要求Triage Party6 月至 10 月持续推进 triage-party 工具部署k8s.io 仓库 PR、DNS 与 GitHub token 就绪后先在 k/sig-release 与 k/release 试点并提供 SIG Release 的 bug-triage 入口Emeritus Adviser 扩展提议12 月 15 日 Max 提议将 Emeritus Adviser 扩展为团队制每人按 1 年任期分别负责 Comms/Enhancements/Triage以便承接长期主题如 dockershim 弃用这类动摇市场的变更应尽早进入发布说明而非最后时刻Stephen 已就其开了 issue同日还讨论了弃用页Deprecation Page与通向发布的可视化路径图两个想法freeze 可执行性针对 1.20 出现的freeze 日期之后仍有 PR 未经协调合入讨论引入 merge-blocking 插件但现有实现过于粗粒度作用于整个仓库、基于 issue、issue 关闭则封锁解除需要扩展为团队级 按分支仅 main选择 /override 逃生门并与 wg-reliability、sig-arch 协同。十二、1.20 与 1.21周期交接与人员安排12.1 1.20 周期8 月 11 日Jeremy Rickard 被选定为 1.20 Release Lead所有 role leads 选定并提交 PR8 月 25 日提案获批为 1.20 开发重新开放 k/k9 月 22 日决定移除 k/k 的 milestone 限制详见第七章12 月 1 日1.20 进入收尾发布定在下周二SIG-Scalability 测试无问题Nabarun 被提名为 1.21 Release LeadJoyce 将担任 1.21 CI Signal leadStephen 表扬了整个 release team。12.2 1.21 周期筹备12 月 1 日Nabarun 提名确认lead 提名 issue 在 k/sig-releaselead shadows 由 Nabarun 于下周确定Shadow survey 预计本周末发出12 月 15 日正在搭建 release-1.21 目录脚手架排期决策进行中倾向把 Enhancements collection 推到第 2 周因为 shadow 选定前 Enhancements Team 只有一名成员风险是其余排期不变时 Enhancements collection 时间变少分支管理1.20 期间生成 release branch jobs 时遇到 config rotater 与 forker 的 bugStephen 与 Dan 正在修复。十三、总结2020 年的经验与 2021 年的延续回顾 2020 年全年会议纪要可以看到 SIG Release 的年度主线清晰以工具迁移降低发布门槛anago → krel、kubepkg 进入 alpha、CIP 可导入化、以政策决策稳定支持承诺1.19 一年补丁支持、WG LTS 收尾、N-3 政策固化为文档、以 CI 治理提升发布质量CI Signal 子项目化、release-blocking job 资源规范化、flake 治理、以流程讨论应对特殊时期1.19 排期延展、发布节奏 3 vs 4 之争。对希望理解 Kubernetes 发布体系或参与 SIG Release 的开发者2020.md 是一份难得的过程性档案它记录了机制背后的讨论与权衡而 release.md、cherry-picks.md、charter.md 则是这些讨论沉淀后的结果性规范。前者回答为什么这样设计后者回答现在该怎么做。两者结合才能完整理解 Kubernetes 发布工程的全貌——而 2020 年正是这套体系从经验驱动走向工程化、可持续的关键一年。关于发布周期与生命周期的图示化说明可参考仓库中的 发布周期示意图 与 跨版本生命周期示意图。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考