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 週期比平常長得多。由於 COVID-19 疫情，SIG Release 延長了它，以減輕 Kubernetes 貢獻者和終端使用者的負擔。在這次延長發布之後，Kubernetes 1.20 版本成為 2020 年的第三個也是最後一個版本。

隨著 Kubernetes 專案的成熟，每個週期的增強功能數量不斷增加，貢獻者和發布工程團隊的負擔也隨之增加。下游消費者和整合者在跟上功能更豐富的版本方面也面臨越來越大的挑戰。更廣泛的專案採用意味著支援快速發展平台的複雜性會影響更大的下游消費者鏈。

將發布節奏從一年四次變更為三次，平衡了利害關係人的各種因素：雖然這嚴格來說不是 LTS 政策，但由於延長的發布週期導致先前的三個版本獲得更長時間的支援，因此消費者和整合者將獲得每個次要版本的更長支援期限。貢獻者有更多時間使增強功能成熟，並使其準備好用於生產環境。

最後，SIG Release 和發布工程團隊的管理負擔減少，使團隊能夠花費更多時間來改善軟體發布的品質以及驅動它們的工具。

您可以如何協助

加入關於溝通未來發布日期的討論，並務必留意發布後調查。

您可以在哪裡找到更多資訊

• 在此處閱讀 KEP
• 加入 kubernetes-dev 郵寄清單
• 加入 Kubernetes Slack 並追蹤 #announcements 頻道

• ←上一篇
下一篇→