Kubernetes v1.36 發布：安全默認配置強化，AI 工作負載支持日趨成熟

作者 | Matt Saunders

譯者 | 明知山

Kubernetes發布 1.36 版本，代號 Haru，這是 2026 年的首個重要版本。該版本包含 70 項增強功能：18 項進入 Stable 階段，25 項進入 Beta 階段，以及 25 項新的 Alpha 功能，重點聚焦安全加固、人工智能和機器學習工作負載，以及大規模 API 的可擴展性。由編輯 Chad M. Crowell、Kirti Goyal、Sophia Ugochukwu、Swathi Rao 和 Utkarsh Umre 撰寫的發布博客將此次發布描述為“時節更迭、山巔光影流轉”之時如約而至，共有 106 家公司和 491 位個人參與了貢獻。

本次發布最亮眼的安全功能是用戶命名空間（User Namespaces）正式達到 GA，該功能已經歷多個版本周期的打磨。該功能可將容器內的 root 用戶映射為主機上的非特權用戶，即便進程突破容器隔離，也無法獲取底層節點的管理權限。同樣達到 GA 的還有可變準入策略（Mutating Admission Policies），允許團隊借助通用表達式語言（CEL）把變更邏輯定義為原生 Kubernetes 對象，無需再單獨維護獨立的 Webhook 服務器。發布博客表示，這“為傳統 Webhook 提供了原生、高性能的替代方案”，同時降低了“管理自定義準入 Webhook 帶來的延遲與運維復雜度”。Kloia 官方 博客 也對此做了詳細解讀并配有原理圖示。

細粒度 Kubelet API 授權也在本版本中正式達到 GA。該功能于 v1.32 版本首次以 Alpha 狀態引入，支持對 Kubelet HTTPS API 進行更精細的最小權限訪問控制，替代了監控與可觀測性工具以往所需的過度寬泛的nodes/proxy權限。SELinux 卷標簽功能進入 Stable 階段，通過mount -o context=XYZ選項替代遞歸文件重標記，在掛載時為整個卷統一配置正確的 SELinux 標簽，以此降低開啟 SELinux 強制模式環境下的 Pod 啟動延遲。基于validation-gen的聲明式驗證、以及卷組快照（Volume Group Snapshots）——支持同時為多個持久卷聲明（PersistentVolumeClaim）創建崩潰一致性快照——也均在本版本中達到 GA。

DRA 管理員訪問以及動態資源分配的優先列表功能同樣達到 GA，為集群管理員提供了一個固定框架用于全局訪問和管理硬件資源，并保障資源選擇邏輯在各類集群環境中保持統一。

v1.36 版本在人工智能與機器學習方面的優化主要體現在默認配置適配了日益增長的工作負載需求。ScaleOps 團隊在 文章 中表示，該版本“與其說是全新的機制，不如說是默認配置補齊了兩年間沉淀的 AI 工作負載實踐經驗”。多項 DRA 增強功能進入測試階段并默認開啟：DRA 可分區設備、DRA 可消耗容量以及 DRA 設備污點與容忍，均無需手動配置特性門控即可啟用。這些功能替代了傳統的整數 GPU 設備插件模型——該模型不考慮實際資源利用率，直接將整張顯卡整體分配——轉而提供原生能力，適配現代加速器的分區、共享以及故障恢復機制。VMware Cloud Foundation 博客還提到，以往“申請復雜資源往往需要晦澀且廠商專屬的配置模塊，調度器也難以做優化調度”，而 v1.36 版本采用的標準化架構大幅降低了多節點 AI 部署的復雜度。

AI 工作負載方面重磅新增的 Alpha 功能是工作負載感知搶占（Workload-Aware Preemption）。在這項功能之前，調度器在為高優先級工作負載騰出空間時會搶占單個 Pod，容易出現分布式訓練任務八個進程中七個都在運行，卻始終無法正常推進的情況。新的機制將 PodGroup 視為一個整體搶占單元，只有在確認高優先級任務組確實能夠容納資源后才會執行驅逐操作。正如 Palark 團隊 在版本解讀文章中所說，該功能解決了分布式訓練的“部分搶占故障模式”，這也是運行大型 GPU 任務的團隊長期面臨的痛點。Gang 調度 API 于 v1.35 版本以 Alpha 狀態引入，在 v1.36 中正式進入 Beta 階段。

暫停作業的 Pod 可變資源（Mutable Pod Resources for Suspended Jobs）功能也進入 Beta 狀態，并默認啟用。該功能允許隊列控制器暫停正在運行的作業，調整其 CPU、內存、GPU 及擴展資源請求，適配集群當前可用容量，隨后恢復作業運行，無需銷毀并重新創建 Pod。Kloia 團隊 表示，這省去了依賴自定義控制器或徹底終止、重啟作業的操作，讓工作負載隊列系統能夠根據集群實時狀態進行靈活調度。

在 API 可擴展性方面，v1.36 版本引入了分片列表與分片監聽流作為全新的 Alpha 功能。擁有大量控制器的大型集群常會遇到監聽流瓶頸，原因是所有觀察者都通過每種資源類型的單一連接接收更新。分片機制可將這類負載分攤到多個流中，Palark 團隊 表示，這解決了“超大規模部署里監聽流容易成為性能瓶頸的關鍵痛點”。

通過 cgroup v2 實現的內存服務質量（Memory QoS）在本版本中進入 Beta 階段，提供了分層內存保護機制，能夠更好地將內核控制與 Pod 的資源請求和限制相匹配，減少同一節點上各工作負載之間的資源爭用。Pod 級資源原地垂直擴縮容（In-Place Vertical Scaling for Pod-Level Resources）同樣進入 Beta 版本并默認啟用，支持在不重啟容器的前提下調整 Pod 級別的 CPU 和內存配額上限。新版本新增ResizeDeferred事件類型，當因節點容量不足無法立即執行擴縮容操作時，Pod 會繼續按現有資源規格運行，待節點資源空閑后，Kubelet 將自動重試完成擴縮容。

計劃進行版本升級的團隊需要留意本版本中若干已移除的功能。gitRepo卷插件自 v1.11 版本開始被廢棄后，現已被徹底移除。該插件存在允許攻擊者以 root 權限在節點上執行代碼的漏洞，PerfectScale 團隊 建議在升級前遷移至初始化容器或外部 git-sync 工具。Kube-proxy 中自 v1.35 版本開始廢棄的 IPVS 模式也已正式移除。此外，kubeadm 中的 FlexVolume 支持以及 Portworx 內置驅動也在本版本中被移除，正如 Kloia 團隊 在其升級指南中所說明的那樣。

有一項早于本版本發布、但仍在 v1.36 官方博客中重點強調的重大運維變更是 Ingress NGINX 的正式退役。Kubernetes SIG Network 與安全響應委員會已于 2026 年 3 月 24 日正式退役該項目。自當日起，項目不再進行任何版本發布、問題修復以及安全漏洞補丁推送。InfoQ 在 Kubernetes 1.35 版本報道 中梳理了 Kubernetes 網絡生態的發展脈絡，并指出 Ingress NGINX 只會“盡力維護至 2026 年 3 月”。

VMware Cloud Foundation 博客將本次版本置于更大的行業轉變背景下：“Kubernetes 正從一個靈活的框架逐步轉向擁有更標準化、更具強制性的默認安全與資源規范。”文章還提到，“跟進 Kubernetes 版本迭代已不再只是簡單升級集群”，還涉及“管理生命周期復雜度、判斷何時采用新版本、厘清變更對現有工作負載的影響，以及避免平臺演進帶來的業務中斷”。

“通過采用更規范化的實現方式，Kubernetes 讓調度器能夠更清晰地識別 GPU 及 AI 加速器的專屬資源需求，大幅降低了多節點 AI 部署的復雜度。” ——VMware Cloud Foundation 博客，Kubernetes 1.36：企業平臺的實際變化

完整的 Kubernetes 1.36 發布說明 也已發布。

查看英文原文：

https://www.infoq.com/news/2026/05/kubernetes-1-36-released/

會議推薦

Agent 從 Demo 到工程化還差什么？安全與可信這道坎怎么過？研發體系不重構，還能撐多久？

AICon 上海站 2026，13 大重磅專題已上線，誠摯邀請你登臺分享實戰經驗。AICon 2026，期待與你同行。快來掃碼鎖定 8 折專屬席位或提交演講議題

今日薦文

你也「在看」嗎？