Kubernetes v1.32 搶先看

作者：Matteo Bianchi、Edith Puclla、William Rizzo、Ryota Sawada、Rashan Smith | 2024 年 11 月 8 日，星期五

隨著 Kubernetes v1.32 釋出日期的臨近，該專案也在不斷發展和成熟。為了專案的整體健康，一些功能可能會被棄用、移除或被更好的功能所取代。

這篇部落格概述了 Kubernetes v1.32 版本中一些計劃中的變更，釋出團隊認為您應該瞭解這些變更，以便持續維護您的 Kubernetes 環境並跟上最新的變化。下面列出的資訊基於 v1.32 版本的當前狀態，在實際釋出日期前可能會有所變動。

Kubernetes API 移除和棄用流程

Kubernetes 專案對功能特性有明確的棄用策略。該策略規定，只有在有更新、更穩定的 API 版本可用時，才能棄用穩定的 API，並且 API 在每個穩定性級別都有最低生命週期。被棄用的 API 已被標記為將在未來的 Kubernetes 版本中移除，在移除之前（從棄用之日起至少一年）將繼續執行。使用它將顯示警告。被移除的 API 在當前版本中不再可用，因此您必須遷移到使用替代的 API。

正式釋出（GA）或穩定的 API 版本可能會被標記為已棄用，但不能在 Kubernetes 的一個大版本中移除。
Beta 或預釋出 API 版本在棄用後必須支援 3 個版本。
Alpha 或實驗性 API 版本可以在任何版本中被移除，而無需事先發出棄用通知；如果同一功能已經有了不同的實現，這個過程可能會變成一種撤回。

無論是由於功能從 Beta 升級到穩定版而移除 API，還是因為該 API 未能成功，所有移除都遵循此棄用策略。每當移除 API 時，都會在棄用指南中傳達遷移方案。

關於撤回舊 DRA 實現的說明

增強提案 #3063 在 Kubernetes 1.26 中引入了動態資源分配 (DRA)。

然而，在 Kubernetes v1.32 中，這種 DRA 的方法將發生重大變化。與原始實現相關的程式碼將被移除，留下 KEP #4381 作為“新”的基礎功能。

改變現有方法的決定源於它與叢集自動擴縮的不相容性，因為資源可用性不透明，這使得叢集自動擴縮器和控制器的決策變得複雜。新新增的結構化引數模型取代了該功能。

此次移除將使 Kubernetes 能夠更可預測地處理新的硬體需求和資源宣告，繞過與 kube-apiserver 之間來回進行 API 呼叫的複雜性。

另請參閱增強提案#3063以瞭解更多資訊。

API 移除

在 Kubernetes v1.32 中，僅計劃移除一個 API。

FlowSchema 和 PriorityLevelConfiguration 的 flowcontrol.apiserver.k8s.io/v1beta3 API 版本已被移除。為應對此變化，您可以編輯現有的清單並重寫客戶端軟體，以使用自 v1.29 起可用的 flowcontrol.apiserver.k8s.io/v1 API 版本。所有現有的持久化物件都可以透過新的 API 訪問。flowcontrol.apiserver.k8s.io/v1beta3 中的顯著變化包括：PriorityLevelConfiguration 的 spec.limited.nominalConcurrencyShares 欄位僅在未指定時預設為 30，顯式設定的值 0 不會被更改為 30。

有關更多資訊，請參閱 API 棄用指南。

Kubernetes v1.32 預覽

以下增強功能列表很可能包含在 v1.32 版本中。這並非承諾，釋出內容可能會發生變化。

Windows 的反擊！

KEP #4802 為 Kubernetes 叢集中的 Windows 節點添加了優雅關閉的支援。在此版本之前，Kubernetes 為 Linux 節點提供了優雅的節點關閉功能，但缺乏對 Windows 的同等支援。此增強功能使 Windows 節點上的 kubelet 能夠正確處理系統關閉事件。這樣做可以確保在 Windows 節點上執行的 Pod 被優雅地終止，從而允許工作負載在不中斷的情況下重新排程。這一改進增強了包含 Windows 節點的叢集的可靠性和穩定性，尤其是在計劃維護或任何系統更新期間。

允許在環境變數中使用特殊字元

隨著此增強功能升級至 Beta 版，Kubernetes 現在允許幾乎所有可列印的 ASCII 字元（“=”除外）用作環境變數名。這一變化解決了之前對變數命名的限制，透過適應各種應用需求，促進了 Kubernetes 的更廣泛採用。寬鬆的驗證將透過 RelaxedEnvironmentVariableValidation 特性門控預設啟用，確保使用者可以輕鬆使用環境變數而沒有嚴格的限制，從而為使用 .NET Core 等需要在其配置中使用特殊字元的應用程式的開發人員增強了靈活性。

讓 Kubernetes 瞭解 LoadBalancer 的行為

KEP #1860 升級至 GA，為 type: LoadBalancer 的 Service 引入了 ipMode 欄位，可以設定為 "VIP" 或 "Proxy"。此增強旨在改善雲提供商的負載均衡器與 kube-proxy 的互動方式，並且對終端使用者是透明的。使用 "VIP" 時，kube-proxy 的現有行為得以保留，由 kube-proxy 處理負載均衡。使用 "Proxy" 則會將流量直接傳送到負載均衡器，從而使雲提供商在依賴 kube-proxy 方面擁有更大的控制權；這意味著對於某些雲提供商，您可能會看到負載均衡器效能的提升。

為資源重試生成名稱

此增強功能改進了在使用 generateName 欄位建立 Kubernetes 資源時處理名稱衝突的方式。以前，如果發生名稱衝突，API 伺服器會返回 409 HTTP Conflict 錯誤，客戶端必須手動重試請求。透過此更新，API 伺服器在發生衝突時會自動重試生成新名稱，最多七次。這顯著降低了衝突的機率，確保了高達 100 萬個名稱的順利生成，衝突機率低於 0.1%，為大規模工作負載提供了更高的彈性。

想了解更多嗎？

新功能和棄用資訊也會在 Kubernetes 釋出說明中公佈。我們將在 Kubernetes v1.32 的 CHANGELOG 中正式宣佈該版本的新特性。

您可以在以下版本的釋出說明中檢視變更公告：

Kubernetes 部落格