Kubernetes 发布节奏变更：这是您需要了解的内容

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

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

什么在改变以及何时改变

从 Kubernetes 1.22 版本开始，一项轻量级政策将驱动每个发布计划的制定。此政策规定

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

因此，Kubernetes 将遵循每年三次发布的节奏。Kubernetes 1.23 将是 2021 日历年的最终版本。这项新政策产生了一个非常可预测的发布时间表，使我们能够预测即将到来的发布日期

拟议的 2021 年剩余时间 Kubernetes 发布时间表

拟议的 2022 年 Kubernetes 发布时间表

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

这对最终用户意味着什么

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

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

随着发布次数的减少，用户可以预期功能毕业的速度会减慢。用户还可以预期发布将包含更多需要在升级期间注意的增强功能。但是，由于每年要使用的发布次数较少，因此最终用户组织预计将在升级上花费更少的时间，而在支持其 Kubernetes 集群上花费更多的时间。这也意味着 Kubernetes 发布的支持时间会稍长一些，因此错误修复和安全补丁将在更长的时间内可用于发布。

这对 Kubernetes 贡献者意味着什么

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

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

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

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

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

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

您如何提供帮助

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

您可以在哪里找到更多信息

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

• ←上一篇
下一篇→