Kubernetes v1.36 正式發佈，這次更新的核心趨勢可以概括為從一個靈活的框架轉向更具主見的預設標準。對於工程師來說，這次更新不再僅僅是功能的疊加，而是將過去兩年 AI 工作負載在實務中累積的痛點，直接轉化為系統的內建標準。
安全性加固與權限精細化
在安全性方面，v1.36 最大的亮點是 User Namespaces 正式進入 GA 階段。簡單來說，這項技術解決了容器逃逸後的權限問題。在傳統模式下，容器內的 root 使用者若能突破隔離，在宿主機上可能依然擁有高權限。User Namespaces 透過將容器內的 root 映射為宿主機上的非特權使用者，確保即便發生逃逸，攻擊者也無法直接獲取節點的管理權限。
此外，Mutating Admission Policies 也正式 GA。過去如果想要在 Pod 建立前自動修改其設定，必須維護一個獨立的 Webhook 伺服器，這會增加延遲且維運複雜。現在透過 CEL（Common Expression Language，一種簡單且高效的表達式語言），團隊可以直接用 Kubernetes 原生物件定義修改邏輯，不再需要額外的伺服器。
針對監控工具的權限管理，Fine-Grained Kubelet API Authorization 也進入 GA。過去監控工具通常需要 nodes/proxy 這種過於寬鬆的權限，現在則可以實現最小權限原則，僅開放必要的 API 存取。
AI 與機器學習工作負載的實務優化
對於執行 AI 訓練的團隊，v1.36 解決了長期以來 GPU 資源調度不靈活的問題。過去的設備插件模型將 GPU 視為整數單位，即便只用到一點點，也會佔用一整張卡。現在透過 DRA（Dynamic Resource Allocation，動態資源分配）的一系列 Beta 功能，系統能更精確地描述加速器的分區、共享與故障恢復，讓調度器能更聰明地分配資源。
針對分散式訓練的痛點，新引入的 Workload-Aware Preemption（工作負載感知搶佔）解決了部分搶佔失敗的問題。在舊版中，調度器可能會單獨剔除某個 Pod 以騰出空間，導致一個 8 節點的訓練任務只剩 7 個在跑，結果整個任務卡死。現在系統將 PodGroup 視為一個整體，只有在確認高優先級群組能完整放入時才會執行搶佔。
另外，Gang Scheduling API 進入 Beta，而針對暫停任務的 Mutable Pod Resources 則允許佇列控制器在不刪除 Pod 的情況下，動態調整其 CPU 或 GPU 請求量，讓資源利用率能根據集群即時狀況靈活變動。
大規模集群的效能與可擴展性
針對超大規模集群，v1.36 引入了 Sharded List and Watch Streams。在大型環境中，所有的控制器都透過單一連線接收資源更新，容易造成瓶頸。分片（Sharding）機制將負載分散到多個串流中，大幅提升了 API 伺服器的吞吐量。
在資源調整上，In-Place Vertical Scaling（原地垂直擴展）進入 Beta 並預設開啟。這意味著 Pod 的 CPU 和記憶體可以在不重啟容器的情況下完成調整。如果當時節點空間不足，系統會觸發 ResizeDeferred 事件，在有空間後自動重試，避免了因調整資源而導致的服務中斷。
升級注意事項與棄用功能
準備升級的團隊需要注意幾個重要變更。首先是 gitRepo 卷插件被正式移除，因為它存在嚴重的安全性風險，建議遷移至 init containers 或外部的 git-sync 工具。此外，kube-proxy 的 IPVS 模式、kubeadm 中的 flex-volume 以及 Portworx 內建驅動也已被移除。
最值得關注的運維變動是 Ingress NGINX 專案的正式退役。自 2026 年 3 月 24 日起，該專案已不再提供更新或安全性補丁，使用者應儘速規劃遷移至其他 Ingress 控制器。
總結來說，Kubernetes v1.36 顯示出平台正試圖降低維運複雜度，透過將安全與資源管理標準化，讓開發者能更專注於 AI 應用本身的邏輯，而非與底層基礎設施對抗。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。