Kubernetes 发布节奏变更：你需要知道的一切

2021 年 4 月 23 日，发布团队合并了一项 Kubernetes 增强提案（KEP），将 Kubernetes 发布周期从每年四次（每季度一次）更改为每年三次。

这篇博客文章提供了关于此更改对 Kubernetes 社区贡献者和维护者意味着什么的高层次概述。

什么正在改变，以及何时改变

从Kubernetes 1.22 版本开始，一项轻量级策略将驱动每个发布计划的创建。这项策略规定：

• 日历年的第一个 Kubernetes 版本应在一月的第二或第三周开始，以便为刚从年终假期回来的贡献者提供更多时间。
• 日历年的最后一个 Kubernetes 版本应在十二月中旬完成。
• 一个 Kubernetes 发布周期大约持续 15 周。
• KubeCon + CloudNativeCon 的那一周不被视为 SIG Release 的“工作周”。发布团队在此期间不会举行会议或做出决策。
• 每个周期之间将强制执行至少两周的 SIG Release 明确休息时间。

因此，Kubernetes 将遵循每年三次发布的节奏。Kubernetes 1.23 将是 2021 日历年的最后一个版本。这项新策略带来了高度可预测的发布计划，使我们能够预测即将到来的发布日期。

2021 年剩余时间的 Kubernetes 拟定发布计划

2022 年的 Kubernetes 拟定发布计划

这些拟定日期仅反映开始和结束日期，且可能会发生变化。发布团队将在每个版本开始时确定增强冻结、代码冻结及其他里程碑的日期。有关这些里程碑的更多信息，请参阅发布阶段文档。先前版本的反馈将纳入此流程。

这对最终用户意味着什么

最终用户将体验到的主要变化是发布节奏变慢以及增强功能成熟速度变慢。Kubernetes 发布工件、发行说明以及任何给定版本的所有其他方面将保持不变。

在此更改之前，一项增强功能可以在 9 个月内从 Alpha 发展到 Stable。随着节奏的变化，这将延长至 12 个月。此外，过去几个版本中功能的成熟部分是由发布团队活动驱动的。

版本数量减少后，用户可以预期功能成熟的速度会放缓。用户还可以预期版本中会包含更多的增强功能，在升级时需要了解这些功能。然而，每年需要消耗的版本减少了，旨在让最终用户组织花费更少的时间进行升级，并将更多时间用于支持其 Kubernetes 集群。这也意味着 Kubernetes 版本的支持周期会略长一些，因此错误修复和安全补丁的可用时间会更长。

这对 Kubernetes 贡献者意味着什么

发布节奏降低后，贡献者将有更多时间进行项目增强、功能开发、规划和测试。较慢的发布节奏也为维护心理健康、准备 KubeCon + CloudNativeCon 等活动或进行下游集成工作提供了更多空间。

为什么我们决定改变发布节奏

Kubernetes 1.19 周期远超往常。SIG Release 延长了该周期，以减轻因 COVID-19 大流行给 Kubernetes 贡献者和最终用户带来的负担。在这次延长的发布之后，Kubernetes 1.20 版本成为 2020 年的第三个也是最后一个版本。

随着 Kubernetes 项目的成熟，每个周期的增强功能数量不断增加，同时也增加了贡献者和发布工程团队的负担。下游用户和集成商在跟进功能日益丰富的版本时也面临着越来越大的挑战。项目被更广泛地采用意味着支持一个快速演进平台的复杂性影响着更大的下游用户链。

将发布节奏从每年四次改为每年三次，平衡了利益相关者的多种因素：虽然这并非严格意义上的 LTS（长期支持）策略，但由于发布周期的延长导致前三个版本得到更长时间的支持，用户和集成商将获得每个小版本更长的支持期。贡献者有更多时间使增强功能成熟并使其为生产环境做好准备。

最后，SIG Release 和发布工程团队的管理开销降低，使得团队能够将更多时间投入到提高软件发布质量和驱动发布的工具上。

您如何提供帮助

加入有关未来发布日期沟通的讨论，并务必留意发布后的调查。

了解更多信息

• 在此阅读 KEP
• 加入kubernetes-dev 邮件列表
• 加入Kubernetes Slack 并关注 #announcements 频道

• ←上一篇
• 下一篇→