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

Kubernetes v1.29：曼陀羅

作者：Kubernetes v1.29 發布團隊 |

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

宣布 Kubernetes v1.29：Mandala (宇宙) 發布，這是 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 PersistentVolume 存取模式 (SIG Storage)

在 Kubernetes 中，卷宗 存取模式 是您可以定義持久儲存體如何使用的方式。這些存取模式是 PersistentVolumes (PV) 和 PersistentVolumeClaims (PVC) 規格的一部分。使用儲存體時，有多種方法可以對該儲存體的使用方式進行建模。例如，像網路檔案共用這樣的儲存系統可以有多個使用者同時讀取和寫入資料。在其他情況下，也許每個人都可以讀取資料，但不能寫入資料。對於高度敏感的資料，也許只允許一個使用者讀取和寫入資料，而其他人則不行。

在 v1.22 之前，Kubernetes 為 PV 和 PVC 提供了三種存取模式

  • ReadWriteOnce – 卷宗可以由單個節點以讀寫模式掛載
  • ReadOnlyMany – 卷宗可以由多個節點以唯讀模式掛載
  • ReadWriteMany – 卷宗可以由多個節點以讀寫模式掛載

ReadWriteOnce 存取模式將卷宗存取限制為單個節點，這表示同一節點上的多個 Pod 可以從同一卷宗讀取和寫入。對於某些應用程式而言，這可能會是一個主要問題，特別是如果它們需要最多一個寫入器來保證資料安全性的情況。

為了解決這個問題，在 v1.22 中針對 CSI 卷宗引入了第四種存取模式 ReadWriteOncePod 作為 Alpha 版功能。如果您建立一個 Pod，其 PVC 使用 ReadWriteOncePod 存取模式，Kubernetes 可確保該 Pod 是整個集群中唯一可以讀取該 PVC 或寫入其中的 Pod。在 v1.29 中，此功能已正式發布。

CSI 驅動程式的節點卷宗擴展密鑰支援 (SIG Storage)

在 Kubernetes 中，卷宗擴展操作可能包括節點上卷宗的擴展，這涉及檔案系統調整大小。某些 CSI 驅動程式在節點擴展期間需要密鑰，例如用於存取 SAN 結構的憑證，用於以下使用案例

  • 當 PersistentVolume 代表加密的區塊儲存體時，例如使用 LUKS，您可能需要提供密碼才能擴展裝置。
  • 對於各種驗證，CSI 驅動程式需要在節點擴展時具有與後端儲存系統通訊的憑證。

為了滿足此要求，Kubernetes v1.25 中引入了 CSI 節點擴展密鑰功能。這允許將可選的密鑰欄位作為 NodeExpandVolumeRequest 的一部分由 CSI 驅動程式發送，以便可以使用底層儲存系統執行節點卷宗擴展操作。在 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 刪除。

清理基於舊版密鑰的 ServiceAccount 令牌 (SIG Auth)

Kubernetes 切換為使用更安全的服務帳戶令牌，這些令牌在 1.22 版中受到時間限制並綁定到特定的 Pod。在 1.24 版中停止自動產生基於舊版密鑰的服務帳戶令牌。然後在 1.27 版中開始標記仍在使用的剩餘自動產生基於密鑰的令牌，並標註其上次使用日期。

在 v1.29 中，為了減少潛在的攻擊面，如果 LegacyServiceAccountTokenCleanUp 功能標記為舊版的自動產生基於密鑰的令牌在很長一段時間內（預設為 1 年）未使用，則將其標記為無效，如果標記為無效後很長一段時間（預設為額外 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。

由於某些 Linux 發行版已經開始棄用和移除 iptables，並且 nftables 聲稱可以解決 iptables 的主要效能問題，因此此功能為 kube-proxy 新增了基於 nftables 的新後端。

用於管理服務 IP 位址範圍的 API (SIG Network)

服務是一種抽象方式，用於公開在 Pod 集群上執行的應用程式。服務可以具有集群範圍的虛擬 IP 位址，該位址是從 kube-apiserver 標誌中定義的預定義 CIDR 分配的。但是，使用者可能希望新增、移除或調整為服務分配的現有 IP 範圍的大小，而無需重新啟動 kube-apiserver。

此功能實作了一個新的分配器邏輯，該邏輯使用 2 個新的 API 物件：ServiceCIDR 和 IPAddress，允許使用者透過建立新的 ServiceCIDR 來動態增加可用的服務 IP 數量。這有助於解決 IP 耗盡或 IP 重新編號等問題。

新增對 containerd/kubelet/CRI 的支援，以支援每個執行階段類別的映像檔提取 (SIG Windows)

Kubernetes v1.29 新增了根據使用它們的 Pod 的 RuntimeClass 來提取容器映像檔的支援。此功能在 v1.29 中預設為關閉，並在名為 RuntimeClassInImageCriApi 的功能閘道下。

容器映像檔可以是資訊清單或索引。當提取的映像檔是索引時（映像檔索引具有按平台排序的映像檔資訊清單列表），容器執行階段中的平台比對邏輯用於從索引中提取適當的映像檔資訊清單。預設情況下，平台比對邏輯會選擇與執行映像檔提取的主機相符的資訊清單。對於基於 VM 的容器，這可能會受到限制，在基於 VM 的容器中，使用者可能會提取映像檔以作為基於 VM 的容器執行，例如 Windows Hyper-V 容器。

每個執行階段類別的映像檔提取功能新增了根據指定的執行階段類別提取不同映像檔的支援。這是透過引用 (imageID, runtimeClass) 元組而不是僅僅 imageName 或 imageID 的映像檔來實現的。容器執行階段可以選擇新增對此功能的支援（如果他們願意）。如果他們不這樣做，則會保留 Kubernetes v1.29 之前存在的 kubelet 的預設行為。

Pod 資源的就地更新，適用於 Windows Pod (SIG Windows)

作為 Alpha 版功能，Kubernetes Pod 在其 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 群組

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

如果您有使用已棄用的 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 日 在法國巴黎舉行！您可以在 活動網站 上找到有關會議和註冊的更多資訊。

即將舉行的發布網路研討會

加入 Kubernetes v1.29 發布團隊成員於 2023 年 12 月 15 日星期五上午 11 點（太平洋時間）/下午 2 點（美東時間）舉行的網路研討會，以了解此版本的主要功能，以及有助於規劃升級的棄用和移除。如需更多資訊和註冊，請造訪 CNCF 線上課程網站上的 活動頁面。

參與其中

參與 Kubernetes 最簡單的方式是加入與您的興趣一致的眾多特殊興趣小組 (SIG) 之一。有想向 Kubernetes 社群廣播的內容嗎？在我們的每週 社群會議 以及透過以下管道分享您的聲音。感謝您持續不斷的回饋和支持。