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

Kubernetes v1.29: Mandala

作者：Kubernetes v1.29 釋出團隊 |

編輯：Carol Valencia、Kristin Martin、Abigail McCarthy、James Quigley

我們宣佈 Kubernetes v1.29：曼荼羅（宇宙）的釋出，這是 2023 年的最後一個版本！

與之前的版本類似，Kubernetes v1.29 的釋出引入了新的穩定、Beta 和 Alpha 特性。高質量版本的持續交付凸顯了我們開發週期的實力以及社群充滿活力的支援。

此版本包含 49 項增強功能。其中 11 項已進階至穩定版，19 項進入 Beta 版，19 項已進階至 Alpha 版。

Kubernetes v1.29：曼荼羅（宇宙） ✨🌌

與 Kubernetes v1.29 一起踏上宇宙之旅！

這個版本的靈感來自美麗的藝術形式——曼荼羅，它是完美宇宙的象徵。我們由大約 40 名釋出團隊成員組成的緊密團結的宇宙，在數百名社群貢獻者的支援下，不懈地努力，將挑戰轉化為全球數百萬人的喜悅。

曼荼羅主題反映了我們社群的互聯性——一幅由愛好者和專家共同編織的充滿活力的織錦。每一位貢獻者都是至關重要的一部分，貢獻著他們獨特的能量，就像曼荼羅藝術中多樣化的圖案一樣。Kubernetes 的發展依賴於協作，這與曼荼羅創作中的和諧相呼應。

該版本的徽標由 Mario Jason Braganza 製作（基礎曼荼羅藝術由 Fibrel Ojalá 提供），象徵著 Kubernetes 專案及其所有成員所構成的小宇宙。

本著曼荼羅變革象徵主義的精神，Kubernetes v1.29 慶祝我們專案的演進。就像 Kubernetes 宇宙中的星星一樣，每一位貢獻者、使用者和支持者都照亮了前行的道路。我們一起創造一個充滿可能性的宇宙——一次一個版本。

Kubernetes v1.29 中進階至穩定的改進

以下是 v1.29 釋出後現已穩定的一些改進的精選。

ReadWriteOncePod 持久卷訪問模式（SIG Storage）

在 Kubernetes 中，卷訪問模式是你定義如何使用持久儲存的方式。這些訪問模式是 PersistentVolumes (PVs) 和 PersistentVolumeClaims (PVCs) 規約的一部分。在使用儲存時，有不同的方式來建模儲存的使用方式。例如，像網路檔案共享這樣的儲存系統可以有許多使用者同時讀取和寫入資料。在其他情況下，也許允許所有人讀取資料但不允許寫入。對於高度敏感的資料，也許只允許一個使用者讀取和寫入資料，而其他人則不行。

在 v1.22 之前，Kubernetes 為 PVs 和 PVCs 提供了三種訪問模式

  • ReadWriteOnce – 卷可以被單個節點以讀寫方式掛載
  • ReadOnlyMany – 卷可以被多個節點以只讀方式掛載
  • ReadWriteMany – 卷可以被多個節點以讀寫方式掛載

ReadWriteOnce 訪問模式將卷的訪問限制在單個節點上，這意味著同一節點上的多個 Pod 可以讀寫同一個卷。這對於某些應用程式來說可能是一個主要問題，特別是如果它們為了資料安全保證而要求最多隻有一個寫入者。

為了解決這個問題，v1.22 中為 CSI 卷引入了第四種訪問模式 ReadWriteOncePod 作為 Alpha 特性。如果你建立一個使用 ReadWriteOncePod 訪問模式的 PVC 的 Pod，Kubernetes 會確保該 Pod 是整個叢集中唯一可以讀取或寫入該 PVC 的 Pod。在 v1.29 中，此特性已正式釋出。

CSI 驅動程式支援節點卷擴充套件 Secret（SIG Storage）

在 Kubernetes 中，卷擴充套件操作可能包括在節點上擴展卷，這涉及到檔案系統的大小調整。一些 CSI 驅動程式在節點擴充套件期間需要 Secret（例如用於訪問 SAN 網路的憑據），以用於以下用例：

  • 當 PersistentVolume 代表加密的塊儲存時，例如使用 LUKS，你可能需要提供一個密碼來擴充套件裝置。
  • 為了進行各種驗證，CSI 驅動程式需要在節點擴充套件時擁有與後端儲存系統通訊的憑據。

為了滿足這一要求，Kubernetes v1.25 中引入了 CSI 節點擴充套件 Secret 特性。這允許 CSI 驅動程式在 NodeExpandVolumeRequest 中傳送一個可選的 Secret 欄位，以便可以使用底層儲存系統執行節點卷擴充套件操作。在 Kubernetes v1.29 中，此特性已正式釋出。

KMS v2 靜態加密正式釋出（SIG Auth）

在保護 Kubernetes 叢集時，首先要考慮的事情之一是加密持久化的 API 靜態資料。KMS 為提供商提供了一個介面，以利用儲存在外部金鑰服務中的金鑰來執行此加密。隨著 Kubernetes v1.29 的釋出，KMS v2 已成為一個穩定的特性，在效能、金鑰輪換、健康檢查與狀態以及可觀察性方面帶來了眾多改進。這些增強功能為使用者提供了一個可靠的解決方案，用於加密其 Kubernetes 叢集中的所有資源。你可以在 KEP-3299 中閱讀更多相關資訊。

建議使用 KMS v2。KMS v1 的特性門控預設是停用的。你將必須選擇性啟用才能繼續使用它。

Kubernetes v1.29 中進階至 Beta 的改進

以下是 v1.29 釋出後現已進入 Beta 的一些改進的精選。

排程程式的吞吐量是我們永恆的挑戰。這個 QueueingHint 特性為最佳化重新排隊的效率帶來了新的可能性，這可以顯著減少無用的排程重試。

節點生命週期與汙點管理分離（SIG Scheduling）

如標題所述，這是為了將執行基於汙點的 Pod 驅逐的 `TaintManager` 從 `NodeLifecycleController` 中解耦出來，使它們成為兩個獨立的控制器：`NodeLifecycleController` 用於向不健康的節點新增汙點，而 `TaintManager` 用於在帶有 NoExecute 效果的汙點節點上執行 Pod 刪除。

清理遺留的基於 Secret 的 ServiceAccount 令牌（SIG Auth）

Kubernetes 在 1.22 版本中切換到使用更安全的服務賬戶令牌，這些令牌是時間限制的並繫結到特定的 Pod。在 1.24 版本中停止自動生成遺留的基於 Secret 的服務賬戶令牌。然後在 1.27 版本中開始為仍在使用的剩餘自動生成的基於 Secret 的令牌標記其最後使用日期。

在 v1.29 中，為了減少潛在的攻擊面，LegacyServiceAccountTokenCleanUp 特性將長時間未使用（預設為 1 年）的遺留自動生成的基於 Secret 的令牌標記為無效，並在被標記為無效後長時間未嘗試使用（預設為額外的 1 年）時自動刪除它們。KEP-2799

新的 Alpha 特性

使用 `matchLabelKeys` 定義 Pod 親和性或反親和性（SIG Scheduling）

PodAffinity/PodAntiAffinity 中將引入一項 Alpha 增強功能。它將提高滾動更新期間計算的準確性。

kube-proxy 的 nftables 後端（SIG Network）

目前在 Linux 上的預設 kube-proxy 實現是基於 iptables 的。這是 Linux 核心中多年來首選的資料包過濾和處理系統（從 2001 年的 2.4 核心開始）。然而，iptables 無法解決的問題導致了其後繼者 nftables 的開發。iptables 的開發已基本停止，新特性和效能改進主要都集中在 nftables 上。

此特性為 kube-proxy 添加了一個基於 nftables 的新後端，因為一些 Linux 發行版已經開始棄用和移除 iptables，並且 nftables 聲稱解決了 iptables 的主要效能問題。

用於管理 Service IP 地址範圍的 API（SIG Network）

Service 是一種抽象的方式，用於暴露在一組 Pod 上執行的應用程式。Service 可以有一個叢集範圍的虛擬 IP 地址，該地址從 kube-apiserver 標誌中定義的預定義 CIDR 中分配。然而，使用者可能希望在不重啟 kube-apiserver 的情況下新增、刪除或調整分配給 Service 的現有 IP 範圍。

此特性實現了一個新的分配器邏輯，它使用兩個新的 API 物件：ServiceCIDR 和 IPAddress，允許使用者透過建立新的 ServiceCIDR 動態增加可用的 Service IP 數量。這有助於解決 IP 耗盡或 IP 重新編號等問題。

為 containerd/kubelet/CRI 新增支援，以支援按執行時類別拉取映象（SIG Windows）

Kubernetes v1.29 添加了基於使用容器映象的 Pod 的 RuntimeClass 來拉取容器映象的支援。此特性在 v1.29 中預設關閉，受名為 `RuntimeClassInImageCriApi` 的特性門控控制。

容器映象可以是清單或索引。當被拉取的映象是索引時（映象索引有一個按平臺排序的映象清單列表），容器執行時中的平臺匹配邏輯用於從索引中拉取合適的映象清單。預設情況下，平臺匹配邏輯會選擇一個與執行映象拉取的主機匹配的清單。這對於基於虛擬機器的容器來說可能有限制，因為使用者可能會拉取一個映象，意圖將其作為基於虛擬機器的容器執行，例如 Windows Hyper-V 容器。

按執行時類別拉取映象的特性增加了根據指定的執行時類別拉取不同映象的支援。這是透過使用一個（`imageID`, `runtimeClass`）元組來引用映象，而不是僅僅使用 `imageName` 或 `imageID`。容器執行時可以選擇新增對此特性的支援。如果它們不支援，將保留 Kubernetes v1.29 之前存在的 kubelet 預設行為。

Windows Pods 資源的原地更新（SIG Windows）

作為一項 Alpha 特性，Kubernetes Pods 的 `resources` 可以是可變的，允許使用者更改 Pod 的*期望*資源請求和限制，而無需重啟 Pod。在 v1.29 中，此特性現在支援 Windows 容器。

Kubernetes v1.29 的進階、棄用和移除

進階至穩定

這列出了所有進階至穩定（也稱為*正式釋出*）的特性。有關包括新特性和從 Alpha 到 Beta 的進階在內的完整更新列表，請參閱釋出說明。

此版本共包含 11 項進階至穩定的增強功能

棄用和移除

移除與雲提供商的樹內整合（SIG Cloud Provider）

Kubernetes v1.29 預設*不帶*任何內建的雲提供商整合來執行。如果你之前一直依賴樹內的雲提供商整合（Azure、GCE 或 vSphere），那麼你可以選擇：

  • 啟用一個等效的外部雲控制器管理器整合*（推薦）*
  • 透過將相關的特性門控設定為 `false` 來重新選擇使用遺留整合；需要更改的特性門控是 `DisableCloudProviders` 和 `DisableKubeletCloudCredentialProviders`

啟用外部雲控制器管理器意味著你必須在叢集的控制平面內執行一個合適的雲控制器管理器；它還要求為 kubelet（在每個相關節點上）和整個控制平面（kube-apiserver 和 kube-controller-manager）設定命令列引數 `--cloud-provider=external`。

有關如何啟用和執行外部雲控制器管理器的更多資訊，請閱讀雲控制器管理器管理和遷移副本控制平面以使用雲控制器管理器。

如果你需要一個用於遺留樹內提供商之一的雲控制器管理器，請參閱以下連結

更多細節請見 KEP-2395。

移除 `v1beta2` 流控制 API 組

已棄用的 FlowSchema 和 PriorityLevelConfiguration 的 *flowcontrol.apiserver.k8s.io/v1beta2* API 版本在 Kubernetes v1.29 中不再提供服務。

如果你的清單或客戶端軟體使用已棄用的 Beta API 組，你應該在升級到 v1.29 之前進行更改。有關詳細資訊和建議，請參閱已棄用 API 遷移指南。

棄用 Node 的 `status.nodeInfo.kubeProxyVersion` 欄位

Node 物件的 `.status.kubeProxyVersion` 欄位現已棄用，Kubernetes 專案提議在未來的版本中移除該欄位。這個已棄用的欄位不準確，歷史上由 kubelet 管理——而 kubelet 實際上並不知道 kube-proxy 的版本，甚至不知道 kube-proxy 是否在執行。

如果你一直在客戶端軟體中使用此欄位，請停止使用——該資訊不可靠，且該欄位現已棄用。

遺留的 Linux 軟體包倉庫

請注意，在 2023 年 8 月，遺留的軟體包倉庫（`apt.kubernetes.io` 和 `yum.kubernetes.io`）被正式棄用，Kubernetes 專案宣佈了社群擁有的 Debian 和 RPM 軟體包倉庫的正式釋出，可在 `https://pkgs.k8s.io` 訪問。

這些遺留倉庫已於 2023 年 9 月被凍結，並將在 2024 年 1 月完全消失。如果你目前依賴它們，你**必須**進行遷移。

此棄用與 v1.29 版本沒有直接關係。有關更多詳細資訊，包括這些更改可能如何影響你以及如果你受到影響該怎麼做，請閱讀遺留軟體包倉庫棄用公告。

釋出說明

在我們的釋出說明中檢視 Kubernetes v1.29 釋出的全部細節。

可用性

Kubernetes v1.29 可在 GitHub 上下載。要開始使用 Kubernetes，請檢視這些互動式教程或使用 minikube 執行本地 Kubernetes 叢集。你也可以使用 kubeadm 輕鬆安裝 v1.29。

釋出團隊

Kubernetes 的成功離不開其社群的支援、承諾和辛勤工作。每個釋出團隊都由敬業的社群志願者組成，他們共同努力，構建出你所依賴的 Kubernetes 版本的各個部分。這需要我們社群各個角落的人們的專業技能，從程式碼本身到其文件和專案管理。

我們想感謝整個釋出團隊，他們為我們的社群辛勤工作了數小時，以交付 Kubernetes v1.29 版本。特別感謝我們的釋出負責人 Priyanka Saggu，感謝她在一個成功的釋出週期中支援和指導我們，確保我們所有人都能以最好的方式做出貢獻，並挑戰我們改進發布流程。

專案速度

CNCF K8s DevStats 專案彙總了許多與 Kubernetes 和各個子專案的速度相關的有趣資料點。這包括從個人貢獻到貢獻公司數量的所有內容，並展示了發展這個生態系統所付出的努力的深度和廣度。

在 v1.29 釋出週期中，該週期持續了 14 周（9 月 6 日至 12 月 13 日），我們看到了來自 888 家公司和 1422 位個人的貢獻。

生態系統更新

  • KubeCon + CloudNativeCon Europe 2024 將於 2024 年 3 月 19 日至 22 日在法國巴黎舉行！你可以在活動網站上找到有關會議和註冊的更多資訊。

即將舉行的釋出網路研討會

請於 2023 年 12 月 15 日星期五太平洋時間上午 11 點（東部時間下午 2 點）加入 Kubernetes v1.29 釋出團隊成員，瞭解此版本的主要特性，以及棄用和移除的內容，以幫助規劃升級。有關更多資訊和註冊，請訪問 CNCF 線上計劃網站上的活動頁面。

參與其中

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