Kubernetes 为啥要调整版本更新节奏?

马哥Linux运维

共 934字,需浏览 2分钟

 ·

2021-08-09 02:22

Kubernetes 官博宣布,版本发布团队合并了一个 Kubernetes 增强提案(KEP),将版本发布周期由每年 4 次调整为每年 3 次。为什么会进行这样的调整呢。官博解释到,随着 Kubernetes 项目的成熟,每个周期的增强功能在变多,这给贡献者和发布团队带来了不少的负担。与此同时,版本更新频繁也会给下游消费者跟供应商带来不少诸多挑战。他们需要不断升级更新到功能丰富的新版本。

同时,这一政策的落实也会缩减 SIG 发布和发布团队的开销,将精力更多地放在提升软件版本发布质量及工具上。


具体都有哪些改变?

从 Kubernetes 1.22 开始,一个轻量级策略将推动每个发布计划的创建,该政策规定:

  • 一个日历年的第一个 Kubernetes 版本应该在 1 月的第二个或第三个星期开始,为人们从寒假回来后提供更多的空间;

  • 一个日历年的最后一个 Kubernetes 版本应该在 12 月中旬完成;

  • Kubernetes 发布周期的长度约为 15 周;

  • KubeCon + CloudNativeCon 的一周不被视为 SIG Release 的“工作周”。发布团队在此期间不会召开会议或做出决定;

  • 每个周期之间将强制执行至少两周的明确 SIG 发布中断。

因此,Kubernetes 将遵循每年三个版本的节奏。Kubernetes 1.23 将是 2021 年的最终版本。下面的基于该政策预测的版本更新计划时间表:

这些更新日期仅反映开始和结束日期,并且可能会发生变化。发布团队将在每个发布开始时选择增强冻结、代码冻结和其他里程碑的日期,此外,该项政策并不是一个LTS。具体详情可以访问:https://kubernetes.io/blog/2021/07/20/new-kubernetes-release-cadence/

文章转载:CSDN(ID:CSDNnews)
(版权归原作者所有,侵删)

点击下方“阅读原文”查看更多

浏览 10
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报