Kubernetes发布节奏改变：这是你需要知道的
作者：Celeste Horgan、Adolfo García Veytia、James Laverack、Jeremy Rickard
在 2021 年 4 月 23 日，发布团队合并了 Kubernetes 增强提案（KEP），将 Kubernetes 发布周期从每年 4 个发布（每季度一次）改为每年 3 个发布。
这篇博文为 Kubernetes 社区的贡献者和维护者提供了一个高层次的概述。
改变是的什么，什么时候改变
从Kubernetes 1.22 版本[1]开始，一个轻量级策略将驱动每个发布时间表的创建。这一政策：
日历年的第一个 Kubernetes 发布应该从 1 月的第二或第三周开始，为人们从寒假回来后提供更多的空间。 日历年的最后一次 Kubernetes 发布应该在 12 月中旬完成。 Kubernetes 的发布周期大约为 15 周。 KubeCon + CloudNativeCon 的一周不被认为是 SIG Release 的“工作周”。发布团队不会在此期间召开会议或做出决定。 每个周期之间将强制执行至少两周明确的 SIG Release 休息。
因此，Kubernetes 将遵循每年三个发布的节奏。Kubernetes 1.23 将是 2021 年的最后版本。这个新政策产生了一个非常可预测的发布时间表，允许我们预测即将到来的发布日期：
Proposed Kubernetes Release Schedule for the remainder of 2021
| Week Number in Year | Release Number | Release Week | Note |
|---|---|---|---|
| 35 | 1.22 | 1 (August 23) | |
| 50 | 1.23 | 16 (December 07) | KubeCon + CloudNativeCon NA Break (Oct 11-15) |
Proposed Kubernetes Release Schedule for 2022
| Week Number in Year | Release Number | Release Week | Note |
|---|---|---|---|
| 1 | 1.24 | 1 (January 03) | |
| 15 | 1.24 | 15 (April 12) | |
| 17 | 1.25 | 1 (April 26) | KubeCon + CloudNativeCon EU likely to occur |
| 32 | 1.25 | 15 (August 09) | |
| 34 | 1.26 | 1 (August 22 | KubeCon + CloudNativeCon NA likely to occur |
| 49 | 1.26 | 14 (December 06) |
这些提议的日期只反映了开始和结束日期，它们可能会发生变化。发布团队将在每个发布开始时为增强冻结、代码冻结和其他里程碑选择日期。有关这些里程碑的更多信息，请参考发布阶段[2]文档。来自以前版本的反馈将加入到这个过程中。
这对最终用户意味着什么
最终用户将体验到的主要变化是较慢的发布节奏和较慢的增强毕业率。Kubernetes 发布工件、发布说明以及任何给定发布的所有其他方面都将保持不变。
在此之前，一个增强可以在 9 个月内从 alpha 升级到稳定。随着节奏的变化，这将延伸到 12 个月。此外，在过去的几个版本中，特性的分级在某种程度上是由发布团队活动驱动的。
由于发布的版本更少，用户可以预期功能的升级速度会变慢。用户还可以期望发行版包含大量他们在升级期间需要注意的增强功能。然而，由于每年使用的版本更少，最终用户组织将花更少的时间在升级上，从而获得更多的时间来支持他们的 Kubernetes 集群。这也意味着 Kubernetes 版本支持的时间会稍微长一些，所以 bug 修复和安全补丁将会在更长时间内发布。
这对 Kubernetes 的贡献者意味着什么
对于较慢的发布节奏，贡献者有更多的时间用于项目增强、特性开发、计划和测试。较慢的发布节奏也提供了更多的空间来保持他们的心理健康，为 KubeCon + CloudNativeCon 等事件做准备，或进行下游集成。
为什么我们决定改变发布节奏
Kubernetes 的 1.19 周期比平常要长得多。SIG Release 对其进行了扩展，以减轻 COVID-19 大流行给 Kubernetes 贡献者和最终用户带来的负担。在这个扩展版本之后，Kubernetes 1.20 版本成为了 2020 年的第三个，也是最后一个版本。
随着 Kubernetes 项目的成熟，每个周期增强的数量也在增加，同时增加的还有贡献者，即版本工程团队的负担。下游消费者和集成商也面临着越来越多的挑战，以跟上越来越多的功能打包版本[3]。更广泛的项目采用意味着支持快速发展的平台的复杂性会影响到更大的下游消费者链。
改变每年从四个三个版本发布节奏平衡各种利益相关者因素：虽然这不是严格的 LTS 政策，但消费者和集成商将为每个次要版本获得更长的支持期限，因为延长的发布周期导致前三个版本的支持[4]时间更长。贡献者有更多时间来完善增强功能[5]并为生产做好准备[6]。
最后，SIG Release 和发布工程团队的管理开销减少了，允许团队花更多的时间来改进软件发布的质量和驱动它们的工具。
你如何提供帮助
加入关于沟通未来发布日期的讨论[7]，并注意发布后的调查。
你在哪里可以找到更多信息
阅读KEP[8] 加入kubernetes-dev[9]邮件列表 加入Kubernetes Slack[10]并关注#announcements 频道
参考资料
Kubernetes 1.22 版本: https://github.com/kubernetes/sig-release/tree/master/releases/release-1.22
[2]发布阶段: https://www.k8s.dev/resources/release/#phases
[3]越来越多的功能打包版本: https://kubernetes.io/blog/2021/04/08/kubernetes-1-21-release-announcement/
[4]前三个版本的支持: https://kubernetes.io/blog/2020/08/31/kubernetes-1-19-feature-one-year-support/
[5]完善增强功能: https://www.cncf.io/blog/2021/04/12/enhancing-the-kubernetes-enhancements-process/
[6]为生产做好准备: https://github.com/kubernetes/community/blob/master/sig-architecture/production-readiness.md
[7]讨论: https://github.com/kubernetes/sig-release/discussions/1566
[8]KEP: https://github.com/kubernetes/enhancements/tree/master/keps/sig-release/2572-release-cadence
[9]kubernetes-dev: https://groups.google.com/g/kubernetes-dev
[10]Kubernetes Slack: https://slack.k8s.io/
点击【阅读原文】阅读网站原文。
CNCF概况（幻灯片）
扫描二维码联系我们！
CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。请长按以下二维码进行关注。