Kubernetes v1.34: Of Wind & Will (O' WaW)

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

編輯：Agustina Barbetta、Alejandro Josue Leon Bellido、Graziano Casto、Melony Qin、Dipesh Rawat

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

此版本包含 58 項增強功能。在這些增強功能中，23 項已進入穩定階段，22 項進入 Beta 階段，13 項進入 Alpha 階段。

此版本中還有一些棄用和移除；請務必閱讀相關內容。

這是一個由我們周圍的風和我們內心的意志驅動的版本。

每個釋出週期，我們都會繼承一些我們無法真正控制的風——我們的工具、文件的狀態以及專案的歷史特性。有時這些風會使我們的帆鼓滿，有時會把我們吹向一邊，或者平息下來。

讓 Kubernetes 不斷前進的不是完美的風，而是我們的水手的意志，他們調整船帆，掌舵，規劃航線並保持船隻穩定。釋出的成功不是因為條件總是理想的，而是因為構建它的人、釋出它的人，以及讓 Kubernetes 航行強勁的熊^、貓、狗、巫師和好奇心——無論風向如何。

本次釋出的主題是 風之語，心之向 (O' WaW)，旨在致敬那些塑造我們的風，以及推動我們前進的意志。

^ 哦，你想知道為什麼是熊嗎？繼續想吧！

重點更新

Kubernetes v1.34 包含許多新功能和改進。以下是釋出團隊希望重點介紹的一些更新！

穩定版：DRA 的核心功能達到 GA

動態資源分配 (DRA) 為選擇、分配、共享和配置 GPU、TPU、NIC 和其他裝置提供了更強大的方式。

自 v1.30 版本以來，DRA 一直基於使用對 Kubernetes 核心不透明的**結構化引數**來宣告裝置。此增強功能的靈感來自儲存卷的動態供應。帶有結構化引數的 DRA 依賴於一組支援的 API 型別：ResourceClaim、DeviceClass、ResourceClaimTemplate 和 ResourceSlice API 型別，這些型別位於 `resource.k8s.io` 下，同時透過新的 `resourceClaims` 欄位擴充套件了 Pod 的 `.spec`。
`resource.k8s.io/v1` API 已進入穩定階段，預設可用。

這項工作是作為由 WG Device Management 領導的 KEP #4381 的一部分完成的。

Beta 版：用於 `kubelet` 映象憑證提供程式的投射 ServiceAccount 令牌

用於拉取私有容器映象的 `kubelet` 憑證提供程式傳統上依賴於儲存在節點上或叢集中的長期 Secret。這種方法增加了安全風險和管理開銷，因為這些憑證不與特定工作負載繫結，也不會自動輪換。
為了解決這個問題，`kubelet` 現在可以請求短期、受眾繫結的 ServiceAccount 令牌以向容器映象庫進行身份驗證。這允許根據 Pod 自身的身份而不是節點級別的憑證來授權映象拉取。
主要好處是顯著提高了安全性。它消除了為映象拉取使用長期 Secret 的需要，減少了攻擊面，併為管理員和開發人員簡化了憑證管理。

這項工作是作為由 SIG Auth 和 SIG Node 領導的 KEP #4412 的一部分完成的。

Alpha 版：支援 KYAML，一種 Kubernetes 的 YAML 方言

KYAML 旨在成為一個更安全、更少歧義的 YAML 子集，並且是專為 Kubernetes 設計的。無論你使用哪個版本的 Kubernetes，從 Kubernetes v1.34 開始，你都可以使用 KYAML 作為 kubectl 的新輸出格式。

KYAML 解決了 YAML 和 JSON 的特定挑戰。YAML 的重要空白需要仔細注意縮排和巢狀，而其可選的字串引用可能導致意外的型別強制轉換（例如：“挪威 Bug”）。同時，JSON 缺乏註釋支援，並且對尾隨逗號和帶引號的鍵有嚴格要求。

你可以編寫 KYAML 並將其作為輸入傳遞給任何版本的 `kubectl`，因為所有 KYAML 檔案也都是有效的 YAML。使用 `kubectl` v1.34，你還可以透過設定環境變數 `KUBECTL_KYAML=true` 請求 KYAML 輸出（例如 kubectl get -o kyaml …）。如果你願意，你仍然可以請求 JSON 或 YAML 格式的輸出。

這項工作是作為由 SIG CLI 領導的 KEP #5295 的一部分完成的。

進入穩定階段的功能

以下是 v1.34 釋出後進入穩定階段的一些改進。

延遲建立 Job 的替換 Pod

預設情況下，Job 控制器在 Pod 開始終止時立即建立替換 Pod，導致兩個 Pod 同時執行。這可能導致在資源受限的叢集中出現資源爭用，替換 Pod 可能難以找到可用節點，直到原始 Pod 完全終止。這種情況還可能觸發不必要的叢集自動縮放器擴充套件。此外，一些機器學習框架，如 TensorFlow 和 JAX，要求每個索引只有一個 Pod 在執行，這使得同時執行 Pod 成為問題。此功能在 Job 中引入了 `.spec.podReplacementPolicy`。你可以選擇僅在 Pod 完全終止時（具有 `.status.phase: Failed`）建立替換 Pod。要做到這一點，請設定 `.spec.podReplacementPolicy: Failed`。
該功能在 v1.28 中作為 Alpha 引入，在 v1.34 中進入穩定階段。

這項工作是作為由 SIG Apps 領導的 KEP #3939 的一部分完成的。

從卷擴充套件失敗中恢復

此功能允許使用者取消底層儲存提供程式不支援的卷擴充套件，並使用可能成功的較小值重試卷擴充套件。
該功能在 v1.23 中作為 Alpha 引入，在 v1.34 中進入穩定階段。

這項工作是作為由 SIG Storage 領導的 KEP #1790 的一部分完成的。

用於卷修改的 VolumeAttributesClass

VolumeAttributesClass 在 v1.34 中進入穩定階段。VolumeAttributesClass 是一個通用的、Kubernetes 原生的 API，用於修改卷引數，如已配置的 IO。它允許工作負載線上垂直擴充套件其卷，以平衡成本和效能，如果其提供程式支援的話。
與 Kubernetes 中所有新的卷功能一樣，此 API 是透過容器儲存介面 (CSI) 實現的。你的特定於提供程式的 CSI 驅動程式必須支援新的 ModifyVolume API，這是此功能的 CSI 端。

這項工作是作為由 SIG Storage 領導的 KEP #3751 的一部分完成的。

結構化身份驗證配置

Kubernetes v1.29 引入了一種配置檔案格式來管理 API 伺服器客戶端身份驗證，從而擺脫了之前對大量命令列選項的依賴。AuthenticationConfiguration 型別允許管理員支援多個 JWT 身份驗證器、CEL 表示式驗證和動態重新載入。這一變化顯著提高了叢集身份驗證設定的可管理性和可審計性，並在 v1.34 中進入穩定階段。

這項工作是作為由 SIG Auth 領導的 KEP #3331 的一部分完成的。

基於選擇器的更精細授權

Kubernetes 授權器，包括 webhook 授權器和內建節點授權器，現在可以根據傳入請求中的欄位和標籤選擇器做出授權決策。當你傳送帶有選擇器的 **list**、**watch** 或 **deletecollection** 請求時，授權層現在可以根據這些額外的上下文評估訪問許可權。

例如，你可以編寫一個授權策略，只允許列出繫結到特定 `.spec.nodeName` 的 Pod。客戶端（可能是某個特定節點上的 kubelet）必須指定策略要求的欄位選擇器，否則請求將被禁止。這一變化使得設定最小許可權規則成為可能，前提是客戶端知道如何遵守你設定的限制。Kubernetes v1.34 現在在諸如每節點隔離或自定義多租戶設定等環境中支援更精細的控制。

這項工作是作為由 SIG Auth 領導的 KEP #4601 的一部分完成的。

透過精細控制限制匿名請求

現在，你可以配置一個嚴格的端點列表，允許未經身份驗證的請求，而不是完全啟用或停用匿名訪問。這為依賴匿名訪問健康或引導端點（如 `/healthz`、`/readyz` 或 `/livez`）的叢集提供了一個更安全的替代方案。

透過此功能，可以避免因 RBAC 配置錯誤而授予匿名使用者廣泛訪問許可權的意外情況，而無需更改外部探針或引導工具。

這項工作是作為由 SIG Auth 領導的 KEP #4633 的一部分完成的。

透過外掛特定的回撥實現更高效的重新排隊

現在，`kube-scheduler` 可以更準確地決定何時重試排程先前無法排程的 Pod。每個排程外掛現在可以註冊回撥函式，告訴排程器傳入的叢集事件是否可能使被拒絕的 Pod 再次變得可排程。

這減少了不必要的重試並提高了整體排程吞吐量——尤其是在使用動態資源分配的叢集中。該功能還允許某些外掛在安全的情況下跳過通常的退避延遲，從而在特定情況下加快排程速度。

這項工作是作為由 SIG Scheduling 領導的 KEP #4247 的一部分完成的。

有序的名稱空間刪除

半隨機的資源刪除順序可能會產生安全漏洞或意外行為，例如在關聯的 NetworkPolicy 被刪除後 Pod 仍然存在。
此改進為 Kubernetes 名稱空間引入了更結構化的刪除過程，以確保安全和確定性的資源移除。透過強制執行尊重邏輯和安全依賴關係的結構化刪除序列，此方法確保在其他資源之前移除 Pod。
該功能在 Kubernetes v1.33 中引入，並在 v1.34 中進入穩定階段。此次升級透過減輕非確定性刪除帶來的風險（包括 CVE-2024-7598 中描述的漏洞）提高了安全性和可靠性。

這項工作是作為由 SIG API Machinery 領導的 KEP #5080 的一部分完成的。

流式 **list** 響應

在 Kubernetes 中處理大型 **list** 響應以前是一個重大的可擴充套件性挑戰。當客戶端請求大量資源列表時，例如數千個 Pod 或自定義資源，API 伺服器需要在傳送前將整個物件集合序列化到一個大的記憶體緩衝區中。這個過程產生了巨大的記憶體壓力，可能導致效能下降，影響叢集的整體穩定性。
為了解決這個限制，引入了一種用於集合（列表響應）的流式編碼機制。對於 JSON 和 Kubernetes Protobuf 響應格式，該流式機制會自動啟用，並且相關的功能門已達到穩定。這種方法的主要好處是避免了 API 伺服器上的大記憶體分配，從而實現了更小、更可預測的記憶體佔用。因此，叢集變得更具彈性和效能，尤其是在需要頻繁請求大量資源列表的大規模環境中。

這項工作是作為由 SIG API Machinery 領導的 KEP #5116 的一部分完成的。

彈性的 watch 快取初始化

Watch 快取是 `kube-apiserver` 內部的一個快取層，它維護著儲存在 etcd 中叢集狀態的最終一致性快取。過去，在 `kube-apiserver` 啟動期間 watch 快取尚未初始化或需要重新初始化時，可能會出現問題。

為了解決這些問題，watch 快取初始化過程已變得對故障更具彈性，從而提高了控制平面的魯棒性，並確保控制器和客戶端能夠可靠地建立 watch。此改進在 v1.31 中作為 Beta 引入，現已達到穩定。

這項工作是作為由 SIG API Machinery 和 SIG Scalability 領導的 KEP #4568 的一部分完成的。

放寬 DNS 搜尋路徑驗證

以前，在 Kubernetes 中對 Pod 的 DNS `search` 路徑進行嚴格驗證，常常在複雜或傳統的網路環境中造成整合挑戰。這種限制性可能會阻止組織基礎設施所必需的配置，迫使管理員實施困難的變通方法。
為了解決這個問題，放寬的 DNS 驗證在 v1.32 中作為 Alpha 引入，現已在 v1.34 中進入穩定階段。一個常見的用例是 Pod 需要與內部 Kubernetes 服務和外部域通訊。透過在 Pod 的 `.spec.dnsConfig` 的 `searches` 列表的第一個條目中設定一個單點（`.`），管理員可以防止系統的解析器將叢集的內部搜尋域附加到外部查詢。這避免了向內部 DNS 伺服器為外部主機名生成不必要的 DNS 請求，提高了效率並防止了潛在的解析錯誤。

這項工作是作為由 SIG Network 領導的 KEP #4427 的一部分完成的。

在 Windows `kube-proxy` 中支援直接服務返回 (DSR)

DSR 透過允許透過負載均衡器路由的返回流量繞過負載均衡器直接響應客戶端，從而提供效能最佳化，減少負載均衡器的負載並改善整體延遲。有關 Windows 上 DSR 的資訊，請閱讀直接服務返回 (DSR) 簡介。
該功能最初在 v1.14 中引入，在 v1.34 中進入穩定階段。

這項工作是作為由 SIG Windows 領導的 KEP #5100 的一部分完成的。

容器生命週期鉤子的休眠操作

為容器的 PreStop 和 PostStart 生命週期鉤子引入了休眠操作，以提供一種直接的方式來管理優雅關閉並改善整體容器生命週期管理。
休眠操作允許容器在啟動後或終止前暫停指定的時間。使用負數或零的休眠持續時間會立即返回，相當於無操作。
休眠操作在 Kubernetes v1.29 中引入，零值支援在 v1.32 中新增。這兩個功能都在 v1.34 中進入穩定階段。

這項工作是作為由 SIG Node 領導的 KEP #3960 和 KEP #4818 的一部分完成的。

Linux 節點交換支援

歷史上，Kubernetes 缺乏交換支援可能導致工作負載不穩定，因為在記憶體壓力下的節點通常必須突然終止程序。這尤其影響了具有大而不常訪問的記憶體佔用量的應用程式，並妨礙了更優雅的資源管理。

為了解決這個問題，在 v1.22 中引入了可配置的每節點交換支援。它已經歷了 Alpha 和 Beta 階段，並在 v1.34 中進入穩定階段。主要模式 `LimitedSwap` 允許 Pod 在其現有記憶體限制內使用交換，為問題提供了直接的解決方案。預設情況下，`kubelet` 配置為 `NoSwap` 模式，這意味著 Kubernetes 工作負載不能使用交換。

此功能提高了工作負載的穩定性，並允許更有效地利用資源。它使叢集能夠支援更廣泛的應用程式，尤其是在資源受限的環境中，儘管管理員必須考慮交換的潛在效能影響。

這項工作是作為由 SIG Node 領導的 KEP #2400 的一部分完成的。

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

Kubernetes 中的環境變數驗證規則已經放寬，允許在變數名中使用幾乎所有可列印的 ASCII 字元，但不包括 `=`。這一變化支援了工作負載需要在變數名中使用非標準字元的場景——例如，像 .NET Core 這樣的框架使用 `:` 來表示巢狀的配置鍵。

放寬的驗證適用於直接在 Pod spec 中定義的環境變數，以及使用 `envFrom` 引用 ConfigMap 和 Secret 注入的環境變數。

這項工作是作為由 SIG Node 領導的 KEP #4369 的一部分完成的。

汙點管理與節點生命週期分離

歷史上，`TaintManager` 根據節點狀況（NotReady、Unreachable 等）應用 NoSchedule 和 NoExecute 汙點的邏輯與節點生命週期控制器緊密耦合。這種緊密耦合使得程式碼更難維護和測試，也限制了基於汙點的驅逐機制的靈活性。此 KEP 將 `TaintManager` 重構為 Kubernetes 控制器管理器內的一個獨立控制器。這是一個旨在提高程式碼模組化和可維護性的內部架構改進。這一變化使得基於汙點的驅逐邏輯可以獨立地進行測試和演進，但對使用者如何使用汙點沒有直接的影響。

這項工作是作為由 SIG Scheduling 和 SIG Node 領導的 KEP #3902 的一部分完成的。

進入 Beta 階段的新功能

以下是 v1.34 釋出後進入 Beta 階段的一些改進。

Pod 級別的資源請求和限制

為具有多個容器的 Pod 定義資源需求一直具有挑戰性，因為請求和限制只能在每個容器的基礎上設定。這迫使開發人員要麼為每個容器過度配置資源，要麼 meticulously 劃分總的所需資源，使得配置複雜且常常導致資源分配效率低下。為了簡化這一點，引入了在 Pod 級別指定資源請求和限制的能力。這允許開發人員為 Pod 定義一個整體的資源預算，然後由其組成的容器共享。此功能在 v1.32 中作為 Alpha 引入，並在 v1.34 中進入 Beta 階段，HPA 現在支援 Pod 級別的資源規範。

主要的好處是為多容器 Pod 管理資源提供了一種更直觀、更直接的方法。它確保所有容器使用的總資源不超過 Pod 定義的限制，從而實現更好的資源規劃、更準確的排程和更高效的叢集資源利用。

這項工作是作為由 SIG Scheduling 和 SIG Autoscaling 領導的 KEP #2837 的一部分完成的。

用於 `kubectl` 使用者偏好的 `.kuberc` 檔案

`.kuberc` 配置檔案允許你為 `kubectl` 定義偏好，例如預設選項和命令別名。與 kubeconfig 檔案不同，`.kuberc` 配置檔案不包含叢集詳細資訊、使用者名稱或密碼。
此功能在 v1.33 中作為 Alpha 引入，受環境變數 `KUBECTL_KUBERC` 限制。它在 v1.34 中進入 Beta 階段並預設啟用。

這項工作是作為由 SIG CLI 領導的 KEP #3104 的一部分完成的。

外部 ServiceAccount 令牌簽名

傳統上，Kubernetes 使用在 `kube-apiserver` 啟動時從磁碟載入的靜態簽名金鑰來管理 ServiceAccount 令牌。此功能引入了一個用於程序外簽名的 `ExternalJWTSigner` gRPC 服務，使 Kubernetes 發行版能夠與外部金鑰管理解決方案（例如，HSM、雲 KMS）整合，用於 ServiceAccount 令牌簽名，而不是基於磁碟的靜態金鑰。

此外部 JWT 簽名功能在 v1.32 中作為 Alpha 引入，在 v1.34 中進入 Beta 階段並預設啟用。

這項工作是作為由 SIG Auth 領導的 KEP #740 的一部分完成的。

DRA 功能進入 Beta 階段

用於安全資源監控的管理員訪問

DRA 透過 ResourceClaims 或 ResourceClaimTemplates 中的 `adminAccess` 欄位支援受控的管理員訪問，允許叢集操作員訪問其他人已在使用的裝置以進行監控或診斷。此特權模式僅限於有權在標記為 `resource.k8s.io/admin-access: "true"` 的名稱空間中建立此類物件的使用者，確保常規工作負載不受影響。此功能在 v1.34 中進入 Beta 階段，透過基於名稱空間的授權檢查提供安全的內省能力，同時保持工作負載隔離。

這項工作是作為由 WG Device Management 和 SIG Auth 領導的 KEP #5018 的一部分完成的。

ResourceClaims 和 ResourceClaimTemplates 中的優先備選方案

雖然工作負載可能在單個高效能 GPU 上執行得最好，但它也可能能夠在兩個中級 GPU 上執行。
隨著 `DRAPrioritizedList` 功能門（現已預設啟用）的引入，ResourceClaims 和 ResourceClaimTemplates 獲得了一個名為 `firstAvailable` 的新欄位。此欄位是一個有序列表，允許使用者指定一個請求可以透過不同方式滿足，包括在特定硬體不可用時完全不分配。排程器將按順序嘗試滿足列表中的備選方案，因此工作負載將被分配到叢集中可用的最佳裝置集。

這項工作是作為由 WG Device Management 領導的 KEP #4816 的一部分完成的。

`kubelet` 報告已分配的 DRA 資源

`kubelet` 的 API 已更新，以報告透過 DRA 分配的 Pod 資源。這允許節點監控代理發現節點上 Pod 的已分配 DRA 資源。此外，它使節點元件能夠使用 PodResourcesAPI 並在開發新功能和整合時利用此 DRA 資訊。
從 Kubernetes v1.34 開始，此功能預設啟用。

這項工作是作為由 WG Device Management 領導的 KEP #3695 的一部分完成的。

`kube-scheduler` 非阻塞 API 呼叫

`kube-scheduler` 在排程週期中進行阻塞性 API 呼叫，造成效能瓶頸。此功能透過帶有請求去重功能的優先佇列系統引入了非同步 API 處理，允許排程器在 API 操作在後臺完成時繼續處理 Pod。主要好處包括減少排程延遲、防止 API 延遲期間排程器執行緒餓死，以及為不可排程的 Pod 提供即時重試能力。該實現保持了向後相容性，並添加了用於監控待處理 API 操作的指標。

這項工作是作為由 SIG Scheduling 領導的 KEP #5229 的一部分完成的。

變更性准入策略

MutatingAdmissionPolicies 為變更性准入 Webhook 提供了一種宣告式的、程序內的替代方案。此功能利用 CEL 的物件例項化和 JSON Patch 策略，結合伺服器端應用（Server Side Apply）的合併演算法。
這透過允許管理員直接在 API 伺服器中定義變更規則，顯著簡化了准入控制。
變更性准入策略在 v1.32 中作為 Alpha 引入，在 v1.34 中進入 Beta 階段。

這項工作是作為由 SIG API Machinery 領導的 KEP #3962 的一部分完成的。

可快照的 API 伺服器快取

`kube-apiserver` 的快取機制（watch cache）高效地服務於對最新觀察狀態的請求。然而，對先前狀態的 **list** 請求（例如，透過分頁或指定 `resourceVersion`）通常會繞過此快取，直接從 etcd 服務。這種直接訪問 etcd 的方式顯著增加了效能成本，並可能導致穩定性問題，特別是在處理大型資源時，由於傳輸大資料塊造成的記憶體壓力。
隨著 `ListFromCacheSnapshot` 功能門預設啟用，`kube-apiserver` 將在 `resourceVersion` 比請求的舊的快照可用時嘗試從快照服務響應。`kube-apiserver` 啟動時沒有快照，在每個 watch 事件上建立一個新快照，並保留它們直到檢測到 etcd 被壓縮或快取中充滿了比 75 秒更舊的事件。如果提供的 `resourceVersion` 不可用，伺服器將回退到 etcd。

這項工作是作為由 SIG API Machinery 領導的 KEP #4988 的一部分完成的。

用於 Kubernetes 原生型別宣告式驗證的工具

在此版本之前，Kubernetes 內建 API 的驗證規則完全是手動編寫的，這使得維護者難以發現、理解、改進或測試。沒有一種單一的方法可以找到可能適用於 API 的所有驗證規則。**宣告式驗證**透過使 API 開發、維護和審查更容易，並實現程式設計檢查以獲得更好的工具和文件，從而使 Kubernetes 維護者受益。對於使用 Kubernetes 庫編寫自己程式碼的人（例如：控制器），新方法透過 IDL 標籤簡化了新欄位的新增，而不是複雜的驗證函式。這一變化有助於透過自動化驗證樣板程式碼來加速 API 建立，並透過對版本化型別進行驗證來提供更相關的錯誤訊息。​​​​​​​​​​​​​​​​
此增強功能（在 v1.33 中進入 Beta 階段，並在 v1.34 中繼續作為 Beta）將基於 CEL 的驗證規則引入到 Kubernetes 原生型別中。它允許直接在型別定義中定義更精細和宣告式的驗證，從而提高了 API 的一致性和開發人員體驗。

這項工作是作為由 SIG API Machinery 領導的 KEP #5073 的一部分完成的。

用於 **list** 請求的流式 Informer

自 v1.32 以來一直處於 Beta 階段的流式 Informer 功能，在 v1.34 中獲得了進一步的 Beta 改進。此功能允許 **list** 請求將資料作為來自 API 伺服器 watch 快取的連續物件流返回，而不是直接從 etcd 組裝分頁結果。透過重用用於 **watch** 操作的相同機制，API 伺服器可以服務於大型資料集，同時保持記憶體使用穩定，並避免可能影響穩定性的分配峰值。

在此版本中，`kube-apiserver` 和 `kube-controller-manager` 預設都利用了新的 `WatchList` 機制。對於 `kube-apiserver`，這意味著 list 請求被更有效地流式傳輸，而 `kube-controller-manager` 則受益於一種更記憶體高效和可預測的方式來處理 Informer。這些改進共同減少了大型 list 操作期間的記憶體壓力，並提高了持續負載下的可靠性，使得 list 流式傳輸更可預測和高效。

這項工作是作為由 SIG API Machinery 和 SIG Scalability 領導的 KEP #3157 的一部分完成的。

Windows 節點的優雅節點關閉處理

Windows 節點上的 `kubelet` 現在可以檢測系統關閉事件，並開始優雅地終止正在執行的 Pod。這與 Linux 上的現有行為類似，有助於確保工作負載在計劃的關閉或重啟期間乾淨地退出。
當系統開始關閉時，`kubelet` 會使用標準的終止邏輯做出反應。它尊重配置的生命週期鉤子和寬限期，在節點關閉前給 Pod 時間停止。該功能依賴於 Windows 的預關閉通知來協調此過程。此增強功能提高了維護、重啟或系統更新期間的工作負載可靠性。它現在處於 Beta 階段並預設啟用。

這項工作是作為由 SIG Windows 領導的 KEP #4802 的一部分完成的。

就地 Pod 調整大小改進

在 v1.33 中進入 Beta 階段並預設啟用的就地 Pod 調整大小，在 v1.34 中獲得了進一步的改進。這些改進包括支援減少記憶體使用以及與 Pod 級別資源的整合。

此功能在 v1.34 中仍處於 Beta 階段。有關詳細的使用說明和示例，請參閱文件：調整分配給容器的 CPU 和記憶體資源。

這項工作是作為由 SIG Node 和 SIG Autoscaling 領導的 KEP #1287 的一部分完成的。

進入 Alpha 階段的新功能

以下是 v1.34 釋出後進入 Alpha 階段的一些改進。

用於 mTLS 身份驗證的 Pod 證書

在叢集內對工作負載進行身份驗證，特別是與 API 伺服器的通訊，主要依賴於 ServiceAccount 令牌。雖然有效，但這些令牌並不總是建立強大、可驗證的相互 TLS (mTLS) 身份的理想選擇，並且在與期望基於證書的身份驗證的外部系統整合時可能會帶來挑戰。
Kubernetes v1.34 引入了一種內建機制，供 Pod 透過 PodCertificateRequests 獲取 X.509 證書。`kubelet` 可以為 Pod 請求和管理證書，然後這些證書可用於使用 mTLS 對 Kubernetes API 伺服器和其他服務進行身份驗證。主要的好處是為 Pod 提供了一個更強大、更靈活的身份機制。它提供了一種實現強 mTLS 身份驗證的本地方式，而不僅僅是依賴於持有者令牌，從而使 Kubernetes 與標準安全實踐保持一致，並簡化了與支援證書的可觀察性和安全工具的整合。

這項工作是作為由 SIG Auth 領導的 KEP #4317 的一部分完成的。

“受限”Pod 安全標準現在禁止遠端探針

探針和生命週期處理程式中的 `host` 欄位允許使用者指定除 `podIP` 之外的實體供 `kubelet` 進行探測。然而，這為濫用和繞過安全控制的攻擊開闢了一條途徑，因為 `host` 欄位可以設定為**任何**值，包括安全敏感的外部主機或節點上的 localhost。在 Kubernetes v1.34 中，只有當 Pod 要麼不設定 `host` 欄位，要麼甚至不使用這種型別的探針時，才滿足受限 Pod 安全標準。你可以使用**Pod 安全准入**或第三方解決方案來強制 Pod 滿足此標準。因為這些是安全控制，請檢查文件以瞭解你選擇的強制執行機制的限制和行為。

這項工作是作為由 SIG Auth 領導的 KEP #4940 的一部分完成的。

使用 `.status.nominatedNodeName` 表示 Pod 放置

當 `kube-scheduler` 需要時間將 Pod 繫結到節點時，叢集自動縮放器可能無法理解 Pod 將被繫結到特定節點。因此，它們可能會錯誤地認為該節點未被充分利用並將其刪除。
為了解決這個問題，`kube-scheduler` 不僅可以使用 `.status.nominatedNodeName` 來表示正在進行的搶佔，還可以用來表達 Pod 放置的意圖。透過啟用 `NominatedNodeNameForExpectation` 功能門，排程器使用此欄位來指示 Pod 將被繫結到哪裡。這暴露了內部預留，以幫助外部元件做出明智的決策。

這項工作是作為由 SIG Scheduling 領導的 KEP #5278 的一部分完成的。

DRA 功能進入 Alpha 階段

DRA 的資源健康狀況

很難知道一個 Pod 何時正在使用一個已發生故障或暫時不健康的裝置，這使得對 Pod 崩潰進行故障排除變得困難或不可能。
DRA 的資源健康狀況透過在 Pod 的狀態中暴露分配給 Pod 的裝置的健康狀況，提高了可觀察性。這使得更容易識別與不健康裝置相關的 Pod 問題的原因並做出適當的響應。
要啟用此功能，必須啟用 `ResourceHealthStatus` 功能門，並且 DRA 驅動程式必須實現 `DRAResourceHealth` gRPC 服務。

這項工作是作為由 WG Device Management 領導的 KEP #4680 的一部分完成的。

擴充套件資源對映

擴充套件資源對映為 DRA 的表達性和靈活性方法提供了一個更簡單的替代方案，透過提供一種直接的方式來描述資源容量和消耗。此功能使叢集管理員能夠將 DRA 管理的資源作為**擴充套件資源**進行宣傳，允許應用程式開發人員和操作員繼續使用熟悉的容器的 `.spec.resources` 語法來消費它們。
這使得現有工作負載無需修改即可採用 DRA，簡化了應用程式開發人員和叢集管理員向 DRA 的過渡。

這項工作是作為由 WG Device Management 領導的 KEP #5004 的一部分完成的。

DRA 可消耗容量

Kubernetes v1.33 增加了對資源驅動程式宣傳可用裝置切片的支援，而不是將整個裝置作為全有或全無的資源暴露。然而，這種方法無法處理裝置驅動程式根據使用者需求管理裝置資源的細粒度、動態部分，或獨立於受其規範和名稱空間限制的 ResourceClaims 共享這些資源的場景。
啟用 `DRAConsumableCapacity` 功能門（在 v1.34 中作為 Alpha 引入）允許資源驅動程式在多個 ResourceClaims 或多個 DeviceRequests 之間共享同一個裝置，甚至是裝置的切片。該功能還擴充套件了排程器，以支援分配裝置資源的部分，如 `capacity` 欄位中定義。此 DRA 功能改進了跨名稱空間和宣告的裝置共享，使其適應 Pod 的需求。它使驅動程式能夠強制執行容量限制，增強了排程，並支援新的用例，如頻寬感知網路和多租戶共享。

這項工作是作為由 WG Device Management 領導的 KEP #5075 的一部分完成的。

裝置繫結條件

Kubernetes 排程器透過延遲將 Pod 繫結到節點，直到其所需的外部資源（如可附加裝置或 FPGA）被確認準備就緒，從而變得更加可靠。
此延遲機制在排程框架的PreBind 階段實現。在此階段，排程器在繼續繫結之前檢查是否所有必需的裝置條件都已滿足。這使得能夠與外部裝置控制器協調，確保更健壯、可預測的排程。

這項工作是作為由 WG Device Management 領導的 KEP #5007 的一部分完成的。

容器重啟規則

目前，一個 Pod 內的所有容器在退出或崩潰時都會遵循相同的 `.spec.restartPolicy`。然而，執行多個容器的 Pod 可能對每個容器有不同的重啟要求。例如，對於用於執行初始化的 init 容器，如果它們失敗，你可能不希望重試初始化。同樣，在具有長時間執行的訓練工作負載的 ML 研究環境中，因可重試的退出程式碼而失敗的容器應該快速就地重啟，而不是觸發 Pod 重建並丟失進度。
Kubernetes v1.34 引入了 `ContainerRestartRules` 功能門。啟用後，可以為 Pod 內的每個容器指定一個 `restartPolicy`。還可以定義一個 `restartPolicyRules` 列表，以根據最後一個退出程式碼覆蓋 `restartPolicy`。這提供了處理複雜場景和更好地利用計算資源所需的精細控制。

這項工作是作為由 SIG Node 領導的 KEP #5307 的一部分完成的。

從執行時建立的檔案中載入環境變數

應用程式開發人員長期以來一直要求在宣告環境變數方面有更大的靈活性。傳統上，環境變數是透過靜態值、ConfigMap 或 Secret 在 API 伺服器端宣告的。

在 `EnvFiles` 功能門後面，Kubernetes v1.34 引入了在執行時宣告環境變數的能力。一個容器（通常是 init 容器）可以生成變數並將其儲存在檔案中，後續的容器可以從該檔案中載入環境變數啟動。這種方法消除了“包裝”目標容器入口點的需要，實現了更靈活的 Pod 內容器編排。

此功能特別有利於 AI/ML 訓練工作負載，其中訓練作業中的每個 Pod 都需要使用執行時定義的值進行初始化。

這項工作是作為由 SIG Node 領導的 KEP #5307 的一部分完成的。

v1.34 中的升級、棄用和移除

升級到穩定版

這裡列出了所有升級到穩定版（也稱為**正式釋出**）的功能。有關包括新功能和從 Alpha 升級到 Beta 的完整更新列表，請參閱釋出說明。

此版本總共包含 23 項升級到穩定版的增強功能

棄用和移除

隨著 Kubernetes 的發展和成熟，功能可能會被棄用、移除或被更好的功能替代，以改善專案的整體健康狀況。有關此過程的更多詳細資訊，請參閱 Kubernetes 棄用和移除策略。Kubernetes v1.34 包括一些棄用。

手動配置 cgroup 驅動程式已棄用

歷史上，為執行 Kubernetes 叢集的使用者配置正確的 cgroup 驅動程式一直是一個痛點。Kubernetes v1.28 添加了一種方式，讓 `kubelet` 查詢 CRI 實現並找出要使用的 cgroup 驅動程式。這種自動檢測現在**強烈推薦**，並且其支援在 v1.34 中已進入穩定階段。如果你的 CRI 容器執行時不支援報告其需要的 cgroup 驅動程式，你應該升級或更改你的容器執行時。`kubelet` 配置檔案中的 `cgroupDriver` 配置設定現已棄用。相應的命令列選項 `--cgroup-driver` 先前已棄用，因為 Kubernetes 推薦使用配置檔案。配置設定和命令列選項都將在未來的版本中移除，該移除不會早於 v1.36 次要版本。

這項工作是作為由 SIG Node 領導的 KEP #4033 的一部分完成的。

Kubernetes 將在 v1.36 中結束對 containerd 1.x 的支援

雖然 Kubernetes v1.34 仍然支援 containerd 1.7 和 containerd 的其他 LTS 版本，但由於自動 cgroup 驅動程式檢測的結果，Kubernetes SIG Node 社群已正式商定了對 containerd v1.X 的最終支援時間表。提供此支援的最後一個 Kubernetes 版本將是 v1.35（與 containerd 1.7 EOL 對齊）。這是一個早期警告，如果你正在使用 containerd 1.X，請考慮儘快切換到 2.0+。你可以監控 `kubelet_cri_losing_support` 指標，以確定你的叢集中是否有任何節點正在使用即將過時的 containerd 版本。

這項工作是作為由 SIG Node 領導的 KEP #4033 的一部分完成的。

`PreferClose` 流量分發已棄用

Kubernetes Service 中的 `spec.trafficDistribution` 欄位允許使用者表達關於如何將流量路由到服務端點的偏好。

KEP-3015 棄用了 `PreferClose` 並引入了兩個額外的值：`PreferSameZone` 和 `PreferSameNode`。`PreferSameZone` 是現有 `PreferClose` 的別名，以澄清其語義。`PreferSameNode` 允許在可能的情況下將連線傳遞到本地端點，在不可能的情況下回退到遠端端點。

此功能在 v1.33 中在 `PreferSameTrafficDistribution` 功能門後引入。它在 v1.34 中進入 Beta 階段並預設啟用。

這項工作是作為由 SIG Network 領導的 KEP #3015 的一部分完成的。

釋出說明

請在我們的釋出說明中檢視 Kubernetes v1.34 釋出的完整詳細資訊。

可用性

Kubernetes v1.34 可在 GitHub 或 Kubernetes 下載頁面上下載。

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

釋出團隊

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

我們紀念 Rodolfo "Rodo" Martínez Vega，他是一位敬業的貢獻者，他對技術和社群建設的熱情在 Kubernetes 社群留下了印記。Rodo 在多個版本中擔任 Kubernetes 釋出團隊的成員，包括 v1.22-v1.23 和 v1.25-v1.30，表現出對專案成功和穩定性的堅定承諾。
除了他在釋出團隊的貢獻之外，Rodo 還深入參與了促進 Cloud Native LATAM 社群的發展，幫助彌合了該領域的語言和文化障礙。他在 Kubernetes 文件的西班牙語版本和 CNCF 術語表方面的工作，體現了他致力於讓全球講西班牙語的開發人員能夠獲取知識的奉獻精神。Rodo 的遺產透過他指導的無數社群成員、他幫助交付的版本以及他幫助培育的充滿活力的 LATAM Kubernetes 社群得以延續。

我們想感謝整個釋出團隊，感謝他們為向我們的社群交付 Kubernetes v1.34 版本而付出的辛勤工作。釋出團隊的成員範圍從首次參與的影子成員到擁有多個釋出週期經驗的迴歸團隊負責人。特別感謝我們的釋出負責人 Vyom Yadav，感謝他在一個成功的釋出週期中指導我們，感謝他解決挑戰的親力親為的方法，以及他為推動我們社群前進所帶來的活力和關懷。

專案速度

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

在 v1.34 釋出週期中，從 2025 年 5 月 19 日到 2025 年 8 月 27 日，為期 15 周，Kubernetes 收到了來自多達 106 家不同公司和 491 名個人的貢獻。在更廣泛的雲原生生態系統中，這一數字上升到 370 家公司，總共有 2235 名貢獻者。

請注意，“貢獻”指的是某人進行提交、程式碼審查、評論、建立 issue 或 PR、審查 PR（包括部落格和文件）或評論 issue 和 PR 的次數。
如果你有興趣貢獻，請訪問我們貢獻者網站上的入門指南。

此資料來源

活動更新

探索即將舉行的 Kubernetes 和雲原生活動，包括 KubeCon + CloudNativeCon、KCD 和全球其他值得關注的會議。隨時瞭解並參與 Kubernetes 社群！

2025 年 8 月

2025 年 9 月

2025 年 10 月

2025 年 11 月

2025 年 12 月

你可以在這裡找到最新的活動詳情。

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

請於 2025 年 9 月 24 日星期三下午 4:00 (UTC) 加入 Kubernetes v1.34 釋出團隊的成員，瞭解此版本的釋出亮點。更多資訊和註冊，請訪問 CNCF 線上計劃網站上的活動頁面。

參與其中

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