本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

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 擬定釋出計劃

一年中的週數釋出版本號釋出周說明
351.231 (8月23日)
501.2316 (12月07日)KubeCon + CloudNativeCon 北美假期 (10月11-15日)

2022年 Kubernetes 擬定釋出計劃

一年中的週數釋出版本號釋出周說明
11.241 (1月03日)
151.2415 (4月12日)
171.251 (4月26日)KubeCon + CloudNativeCon 歐洲可能舉行
321.2515 (8月09日)
341.261 (8月22日)KubeCon + CloudNativeCon 北美可能舉行
491.2614 (12月06日)

這些擬定日期僅反映開始和結束日期,並可能發生變化。釋出團隊將在每個釋出開始時選擇增強功能凍結、程式碼凍結和其他里程碑的日期。有關這些里程碑的更多資訊,請參閱釋出階段文件。之前釋出的反饋將納入此過程。

這對終端使用者意味著什麼

終端使用者將體驗到的主要變化是釋出節奏變慢和增強功能成熟速度變慢。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 和釋出工程團隊的管理開銷減少,使團隊能夠將更多時間用於提高軟體釋出質量和驅動它們的工具。

您如何提供幫助

加入關於傳達未來發布日期的討論,並務必留意釋出後的調查。

您可以在哪裡瞭解更多資訊