Kubernetes 发布节奏变更：你需要知道什么

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

这篇博文将对这一变化对 Kubernetes 社区的贡献者和维护者意味着什么进行高层次概述。

何时以及如何改变

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

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

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

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

2022年 Kubernetes 拟定发布计划

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

这对最终用户意味着什么

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

在此次更改之前，一项增强功能可以在9个月内从 alpha 阶段成熟到稳定阶段。随着节奏的变化，这将延长到12个月。此外，过去几次发布中功能的成熟度在某种程度上是由发布团队的活动驱动的。

随着发布次数的减少，用户可以预期功能成熟的速度会放缓。用户还可以预期发布会包含更多增强功能，他们在升级时需要注意这些功能。然而，每年需要使用的发布次数减少，意味着最终用户组织将花费更少的时间进行升级，并有更多时间支持其 Kubernetes 集群。这也意味着 Kubernetes 发布的受支持时间会稍微延长，因此错误修复和安全补丁将可在更长的时间内用于发布。

这对 Kubernetes 贡献者意味着什么

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

我们为何决定改变发布节奏

Kubernetes 1.19 周期比往常长得多。SIG Release 延长了它，以减轻 Kubernetes 贡献者和最终用户因 COVID-19 大流行而承受的负担。在这次延长发布之后，Kubernetes 1.20 发布成为了 2020 年的第三个也是最后一个发布。

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

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

最后，SIG Release 和发布工程团队的管理开销减少，使团队能够将更多时间用于提高软件发布质量和驱动它们的工具。

您如何提供帮助

加入关于传达未来发布日期的讨论，并务必留意发布后的调查。

您可以在哪里了解更多信息

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

• ←上一篇
• 下一篇→