Kubernetes v1.33 搶先看

作者：Agustina Barbetta、Aakanksha Bhende、Udi Hofesh、Ryota Sawada、Sneha Yadav |

隨著 Kubernetes v1.33 版本的臨近，Kubernetes 專案在持續演進。為了提升專案的整體健康度，一些特性可能會被棄用、移除或替換。這篇博文概述了 v1.33 版本中一些計劃中的變更，釋出團隊認為你應該瞭解這些變更，以確保 Kubernetes 環境的持續平穩執行，並讓你瞭解最新的發展動態。以下資訊基於 v1.33 版本的當前狀態，在最終釋出日期前可能會有所變化。

Kubernetes API 移除和棄用流程

Kubernetes 專案對特性有明確的棄用策略。該策略規定，只有在同一 API 的更新、穩定版本可用時，才能棄用穩定的 API，並且 API 在每個穩定性級別都有最低的生命週期。被棄用的 API 意味著其在未來的 Kubernetes 版本中將被移除。在被移除之前（從棄用算起至少一年），該 API 將繼續有效，但使用時會顯示警告資訊。被移除的 API 在當前版本中不再可用，屆時你必須遷移到其替代 API。

  • 正式釋出（GA）或穩定的 API 版本可能會被標記為已棄用，但不能在 Kubernetes 的一個大版本中移除。

  • Beta 或預釋出 API 版本在棄用後必須支援 3 個版本。

  • Alpha 或實驗性 API 版本可能在任何版本中被移除，而無需事先發布棄用通知；如果同一特性的不同實現已經存在，此過程可能會變成撤回。

無論一個 API 是因為特性從 Beta 階段畢業到穩定階段而被移除，還是因為該 API 未能成功，所有的移除都遵循此棄用策略。每當一個 API 被移除時，我們都會在棄用指南中說明遷移選項。

Kubernetes v1.33 的棄用和移除

棄用穩定的 Endpoints API

EndpointSlices API 自 v1.21 版本以來已達到穩定狀態，有效地取代了原有的 Endpoints API。雖然原有的 Endpoints API 簡單直接，但在擴充套件到大量網路端點時也帶來了一些挑戰。EndpointSlices API 引入了雙棧網路等新功能，這使得原有的 Endpoints API 已可被棄用。

此次棄用僅影響那些直接從工作負載或指令碼中使用 Endpoints API 的使用者；這些使用者應遷移到使用 EndpointSlices。未來幾周內，將有一篇專門的博文詳細介紹棄用帶來的影響和遷移計劃。

你可以在 KEP-4974: 棄用 v1.Endpoints 中找到更多資訊。

移除節點狀態中的 kube-proxy 版本資訊

繼 v1.31 中被棄用後，正如在釋出公告中強調的那樣，status.nodeInfo.kubeProxyVersion 欄位將在 v1.33 中被移除。該欄位由 kubelet 設定，但其值並不總是準確。由於自 v1.31 起該欄位預設被停用，v1.33 版本將完全移除此欄位。

你可以在 KEP-4004: 棄用 status.nodeInfo.kubeProxyVersion 欄位中找到更多資訊。

移除對 Windows Pod 的主機網路支援

Windows Pod 網路的目標是實現與 Linux 的功能對等，並透過允許容器使用節點的網路名稱空間來提高叢集密度。最初的實現作為 Alpha 版本在 v1.26 中引入，但由於遇到了意外的 containerd 行為，並且存在替代方案，Kubernetes 專案決定撤回相關的 KEP。我們預計在 v1.33 中將完全移除此支援。

你可以在 KEP-3503: Windows Pod 的主機網路支援中找到更多資訊。

作為本文的作者，我們挑選了一項改進作為最值得一提的重大變化！

支援 Linux Pod 內的使用者名稱空間

當今最古老的開放 KEP 之一是 KEP-127，即透過為 Pod 使用 Linux 使用者名稱空間來提高 Pod 安全性。該 KEP 最初於 2016 年底提出，經過多次迭代，在 v1.25 中釋出了 Alpha 版本，在 v1.30 中釋出了初始 Beta 版本（預設停用），現在計劃成為 v1.33 的一部分，屆時該功能將預設可用。

此支援不會影響現有的 Pod，除非你手動指定 `pod.spec.hostUsers` 來選擇加入。正如在 v1.30 預覽博文中所強調的，這是緩解漏洞的一個重要里程碑。

你可以在 KEP-127: 支援 Pod 中的使用者名稱空間中找到更多資訊。

其他精選的 Kubernetes v1.33 改進

以下增強功能很可能會包含在即將釋出的 v1.33 版本中。這並非承諾，釋出內容可能會有變動。

用於 Pod 垂直擴縮的就地資源調整

在供應 Pod 時，你可以使用各種資源，如 Deployment、StatefulSet 等。可伸縮性需求可能需要透過更新 Pod 副本數來進行水平擴縮，或者透過更新分配給 Pod 容器的資源來進行垂直擴縮。在此增強功能之前，Pod 的 `spec` 中定義的容器資源是不可變的，更新 Pod 模板中的任何這些細節都會觸發 Pod 替換。

但是，如果你可以在不重啟現有 Pod 的情況下動態更新其資源配置呢？

KEP-1287 正是為了允許這種就地 Pod 更新。它為有狀態程序的垂直擴容開闢了各種可能性，無需停機；在流量較低時實現無縫縮容；甚至可以在啟動時分配更大的資源，並在初始設定完成後最終減少。該功能在 v1.27 中作為 Alpha 版本釋出，預計在 v1.33 中作為 Beta 版本釋出。

你可以在 KEP-1287: 就地更新 Pod 資源中找到更多資訊。

DRA 的 ResourceClaim 裝置狀態升級為 Beta

最初在 v1.32 版本中引入的 ResourceClaim `status` 中的 `devices` 欄位，很可能在 v1.33 中升級為 Beta。該欄位允許驅動程式報告裝置狀態資料，從而提高可觀測性和故障排查能力。

例如，在 ResourceClaim 的狀態中報告網路介面的介面名稱、MAC 地址和 IP 地址，可以極大地幫助配置和管理網路服務，以及除錯網路相關問題。你可以在動態資源分配：ResourceClaim 裝置狀態文件中閱讀更多關於 ResourceClaim 裝置狀態的資訊。

此外，你可以在 KEP-4817: DRA: 帶有可能的標準化網路介面資料的 Resource Claim Status 中找到有關計劃增強的更多資訊。

有序的名稱空間刪除

此 KEP 引入了一種更結構化的 Kubernetes 名稱空間刪除過程，以確保安全和確定性的資源移除。當前半隨機的刪除順序可能產生安全漏洞或意外行為，例如 Pod 在其關聯的 NetworkPolicies 被刪除後仍然存在。透過強制執行尊重邏輯和安全依賴關係的結構化刪除順序，此方法確保 Pod 在其他資源之前被移除。該設計透過降低與非確定性刪除相關的風險，提高了 Kubernetes 的安全性和可靠性。

你可以在 KEP-5080: 有序的名稱空間刪除中找到更多資訊。

索引式 Job 管理的增強

這兩個 KEP 都將升級為 GA，為 Job 處理，特別是索引式 Job 提供更好的可靠性。KEP-3850 為索引式 Job 提供了按索引的回退限制，允許每個索引完全獨立於其他索引。此外，KEP-3998 擴充套件了 Job API，以定義在並非所有索引都成功的情況下，將索引式 Job 標記為成功完成的條件。

你可以在 KEP-3850: 索引式 Job 的按索引回退限制和 KEP-3998: Job 成功/完成策略中找到更多資訊。

想了解更多嗎？

新功能和棄用資訊也會在 Kubernetes 釋出說明中公佈。我們將在 Kubernetes v1.33 的 CHANGELOG 中正式宣佈新內容。

Kubernetes v1.33 計劃於 2025 年 4 月 23 日，星期三釋出。敬請關注更新！

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

參與其中

參與 Kubernetes 最簡單的方式是加入眾多與你興趣相符的特別興趣小組（SIG）之一。有什麼想向 Kubernetes 社群廣播的嗎？請在我們每週的社群會議上以及透過以下渠道分享你的聲音。感謝你持續的反饋和支援。