2026 年 4 月 23 日，Kubernetes 在邁入第 12 個年頭的春天端出了 v1.36，命名為「ハル（Haru）」。這是一個帶有「春、晴、遙か」三層意象的版本，整體 69 項改進中包含 18 Stable + 24 Beta + 25 Alpha + 2 Deprecated，分布的比例大致延續了過去幾個版本「穩定化 + 可擴展性 + 資源編排演進」的主線，但這次特別值得關注的是兩個方向：DRA（Dynamic Resource Allocation） 一口氣有多項 KEP 進入 Stable / Beta，AI/GPU 工作負載終於有了原生且彈性的資源語義；以及 WAS（Workload-Aware Scheduling），把社群多年來靠 Volcano、Kueue 自行擴展的 Gang Scheduling 能力收斂回 kube-scheduler 本體。
對長期跟著版本升級的平台團隊來說，這次版本如果只挑兩件事看，就是「DRA 真的可以開始評估從 device plugin 遷移」與「Gang Scheduling 終於走進 mainline」。前者影響的是 GPU/TPU/網卡等異質資源的調度方式，後者影響的是 PyTorch DDP、Megatron、Ray、大規模批處理這類一定要「整組 Pod 同時上」的工作負載。本文會以 release note 的口吻，挑出最值得拆解的 KEP，再以個人觀點補上升級建議。
一、版本主題：Haru（春）
每個 Kubernetes 版本都有自己的主題，v1.36 選了日語「ハル（Haru）」，發音同時可以對應到：
- 春（haru, spring） — 季節更替、白晝漸長
- 晴（hare, clear sky） — 晴空、明朗
- 遙か（haruka, far-away） — 遠方、地平線
版本 Logo 由 Natsuho Ide（avocadoneko） 設計，靈感來自葛飾北齋的《富嶽三十六景》——尤其是其中的《凱風快晴》（俗稱「赤富士」）。「三十六景」剛好對應 v1.36 的數字，而北斎在三十六景之後又追加了十幅、總共四十六景，這個典故也被官方拿來提醒社群：Kubernetes 同樣不會止步於此。
Logo 中赤富士山頂揮灑的書法是「晴れに翔け」（hare ni kake，「翱翔於晴空」），這是一副完整對聯的上聯，下聯為「未来よ明け」（未來破曉）。整段對聯翻成中文大致是「飛向晴空，未來破曉」——對於正在被 AI 工作負載重塑的 Kubernetes 來說，這個命名比過去幾個版本（UwU、迎風破浪三隻熊）多了幾分宏大敘事的意味。
二、本次重點：DRA + WAS 兩大主軸
如果用一句話總結 v1.36，我會說：
這是一個把 AI/GPU 工作負載原生化的版本。
過去幾年 Kubernetes 在 AI 場景一直被詬病兩件事：
- 資源語義不夠靈活 —
nvidia.com/gpu: 2這種 device plugin 模型只能表達整數張卡，無法描述 MIG 分區、NUMA 拓撲、多卡 NVLink 拓撲、設備健康狀態等真實世界需求。 - 沒有原生 Gang Scheduling — 訓練任務需要 N 個 worker 同時起來才能跑（少一個就死鎖），但 kube-scheduler 預設是單 Pod 獨立排程，社群只能靠 Volcano、Kueue 這類外部 scheduler 擴展。
v1.36 同時對這兩個痛點動刀：DRA 從多年的 Alpha/Beta 終於開始批次成熟，WAS 則是 SIG Scheduling 把 Gang Scheduling 推進主線的第一個正式版本。
三、DRA（Dynamic Resource Allocation）一系列更新
3.1 進入 Stable / Beta / Alpha 的 KEP 概覽
v1.36 涉及到 DRA 的主要 KEP 一覽：
| KEP | 名稱 | 狀態 | 影響範圍 |
|---|---|---|---|
| KEP-4816 | Prioritized List（按優先級排列的設備選擇） | Stable | 稀缺 GPU 可調度性 |
| KEP-5004 | Extended Resource via DRA | Beta | device plugin → DRA 平滑遷移 |
| KEP-4815 | Partitionable Devices（GPU MIG / TPU 分區） | Beta | 多主機邏輯設備、分區衝突 |
| KEP-5055 | Device Taints | Beta | 異常設備隔離、維護 |
| KEP-5007 | Binding Conditions（延遲 Pod 綁定） | Beta | 異步 attach 設備 |
| KEP-4680 | Resource Health Status | Beta | 設備健康可觀測性 |
| KEP-3695 | PodResources API for DRA | Beta | 節點側 DRA 可觀測性 |
| KEP-5018 | AdminAccess for ResourceClaims | Stable | 特權診斷模式 |
| KEP-5729 | Workload-level ResourceClaim | Alpha | PodGroup × DRA |
| KEP-5517 | Native Resources（CPU/Memory）via DRA | Alpha | 統一資源記帳 |
| KEP-5677 | DRA 資源池容量視圖 | Alpha | 排障與容量規劃 |
| KEP-5491 | ResourceSlice typed list 屬性 | Alpha | NUMA/PCIe 拓撲 |
從這個表格可以看出 DRA 的演進軌跡：從「能描述設備」走到「能描述設備的拓撲、健康、共享、以及和原生資源的統一帳本」。這也是為什麼我會說 v1.36 是 AI 工作負載原生化的關鍵節點。
3.2 重點 KEP 拆解
KEP-4816：Prioritized List（Stable）
過去 ResourceClaim 一次只能聲明「我要一個符合條件的 GPU」，如果條件失敗就直接 unschedulable。v1.36 起 ResourceClaim 可以按優先級排列多種可接受的設備選擇——例如「優先要 H100、其次 A100、再次 L40S」。對 GPU 嚴重不足的內部叢集來說，這個能力直接決定了 batch job 能不能在現有資源池下繼續排隊。
對應到實務：你不再需要為每張卡的型號各維護一份 Job YAML，而是在同一個 claim template 寫好 fallback 序列，scheduler 會從上而下找出第一個能滿足的設備。
KEP-4815：Partitionable Devices（Beta）
這是 GPU MIG（NVIDIA Multi-Instance GPU）和 TPU 多主機架構在 Kubernetes 真正能被原生表達的關鍵。一張 H100 可以切成 7 份 MIG 實例；過去 device plugin 把這些「動態分區」表現得很彆扭，常常需要在 Pod 啟動前手動切好分區，靜態地註冊成獨立資源。
KEP-4815 讓 DRA 能描述「這顆設備可以動態分區成 X+Y+Z」，並由 scheduler 在排程時決定如何切分、避免分區衝突。這對 inference 服務動態調整 MIG profile 是個大解放——你可以白天跑 7 個小 inference instance、晚上合成一張完整 H100 給訓練。
KEP-5004：Extended Resource via DRA（Beta）
我認為這是讓現有叢集敢於開始遷移的關鍵 KEP。它讓現有的 nvidia.com/gpu: 2 這類請求語法繼續可用，但底層由 DRA driver 滿足。換句話說，你的 Deployment YAML 不用改，只要把 device plugin 換成 DRA driver，就能立刻享受 DRA 的調度能力。
個人觀察：這是典型的「漸進式遷移路徑」設計。沒有這條 KEP，DRA 永遠只能是新叢集的特權；有了這條 KEP，存量叢集才有理由動。
KEP-5055：Device Taints（Beta）
設備也能像節點一樣打 taint。對於 GPU 出現 ECC 錯誤、NCCL 通訊異常、或進入維護模式時，運維可以在不關掉節點的前提下把單張卡踢出排程池，新 Pod 不會再排到這張卡。Workload 也能用 toleration 明確接受某些 taint（例如 dev/staging 願意接受降級設備）。
KEP-5007：Binding Conditions（Beta）
針對 SR-IOV、RDMA 網卡、外部織構附加設備這類異步 attach 的資源，scheduler 現在可以等到「外部資源確認 ready」之後才綁定 Pod，避免 Pod 落到節點上才發現網卡還沒掛好、然後反覆 reschedule。
KEP-4680：Resource Health Status（Beta）
把 device plugin 與 DRA 的設備健康狀態暴露到 Pod Status。過去 Pod CrashLoop 時運維要分別看 node、device plugin、DMI 訊息，現在可以直接從 Pod 看到「這個 Pod 用的 GPU#3 處於 Unhealthy」這種資訊，定位設備故障的時間大幅下降。
KEP-5729：Workload-level ResourceClaim（Alpha，與 WAS 連動）
讓 PodGroup 級別的物件可以整組共享一份 ResourceClaim。這條 KEP 是 DRA 與 WAS 交叉的接口——當你跑一個 4 節點 × 8 GPU 的訓練任務，整組 Pod 應該共享同一份 placement decision，而不是每個 Pod 各自爭搶。
3.3 從 device plugin 遷移到 DRA 的路徑
對平台團隊我建議的遷移節奏：
- 觀察期（v1.36 ~ v1.38）：用 KEP-5004 在 staging 把 nvidia device plugin 換成 nvidia-dra-driver，不改任何 Pod YAML、驗證 GPU 工作負載是否一致運作。
- 能力試點（v1.38 ~ v1.40）：開始用 ResourceClaim 寫法跑 batch job，啟用 Prioritized List 處理 fallback、用 Partitionable Devices 跑 MIG。
- 全面遷移（v1.40+）：當 Workload-level ResourceClaim、CPU/Memory via DRA 都進入 Beta 後，再評估全面切換。
踩雷提醒：DRA driver 的成熟度仍依賴硬體廠商。NVIDIA 的 dra-driver 進度最快，AMD ROCm、Intel Gaudi、Huawei NPU 的 DRA 對接還需要追蹤。
四、WAS（Workload-Aware Scheduling，原生 Gang Scheduling）
4.1 為什麼 K8s 需要原生 Gang Scheduling
KEP-4671 是 SIG Scheduling 在 v1.36 重點推進的方向，整個方向關聯多個 KEP，包括 5832（Workload 重構）、5732（Topology-Aware Scheduling）、5729（PodGroup × DRA）、5710（PodGroup 抢占）、5547、4671 主議。
回到問題本質：Kubernetes 預設的調度單位是 Pod，但 AI/HPC 工作負載的調度單位是「一群 Pod」。
考慮一個 PyTorch DDP 訓練：
- 4 個節點、每節點 8 張 GPU，共 32 個 worker。
- 必須全部 Pod 都成功排上後再開始訓練。
- 任意一個 worker 排不上，其他 31 個 Pod 就要無限期等待，浪費 GPU 算力。
這就是 Gang Scheduling 要解的問題：「要嘛全部排上，要嘛全不排」——避免部分排上後死鎖、占用 GPU 卻無法推進。
4.2 v1.36 帶來什麼
v1.36 在 Gang Scheduling 上踏出了具體的第一步：
- Workload 重構為靜態模板 — 把 workload 定義從 Job/Deployment 抽象出來，讓 PodGroup 成為一等公民。
- 獨立的 PodGroup 運行時 API — 排程週期以 PodGroup 為單位。
- kube-scheduler 新增 PodGroup 調度週期 — 在原本的 per-Pod queue 之外新增 PodGroup queue。
- 拓撲感知調度（KEP-5732，Alpha） — 同一拓撲域內協同放置整組 Pod，減少跨機架/跨可用區通訊放大。
- 工作負載感知抢占（KEP-5710） — 抢占以整組為單位，而不是逐個 Pod。
- PodGroup 的 DRA ResourceClaim 支援（KEP-5729） — 整組共享 GPU placement。
- Job 控制器整合（啟動） — 為後續 Job/批處理整合鋪路。
API 上，PodGroup 透過 schedulingConstraints.topology[].key 宣告拓撲約束（v1.36 僅支援單一 topology constraint）。當與 gang 策略配合時，scheduler 會先驗證至少 minCount 個 Pod 能否在同一拓撲域放下，再執行綁定；若無可行 placement，整組不可調度。
新增的兩個排程框架擴展點 placementGenerate 與 placementScore 是核心改動，搭配的關鍵 plugin：
- TopologyPlacement：生成候選拓撲域
- NodeResourcesFit：對候選 placement 做資源利用評分（placement 場景使用 MostAllocated 邏輯）
- PodGroupPodsCount：按可成功放置 Pod 數量評分
4.3 與現有 Volcano / Kueue 的關係
我認為這是這次版本最值得平台團隊討論的策略題。短期內：
- Volcano 仍會是大規模 batch / HPC 場景的成熟選擇，特別是有 priority queue、fair-share、SLA 等深度 scheduling policy 需求。
- Kueue 依然在 quota management、job queueing、multi-cluster fair-share 上更成熟。
- WAS（kube-scheduler 內建） 提供的是「最小可用的原生 Gang Scheduling」，覆蓋的是「我只要 32 個 Pod 同時起來」這種簡單但高頻的需求。
長期看，WAS 走的路線跟 Validating Admission Policy 取代 webhook 是同一套劇本：先把基礎能力收斂回主線，再讓社群決定哪些 advanced policy 留在外部 scheduler。中期建議是：新叢集可以開始試 WAS 跑簡單訓練任務，現有 Volcano/Kueue 部署不急著換。
4.4 對 ML 訓練的實際影響
對於 PyTorch DDP / Megatron / DeepSpeed 這類訓練框架：
- 冷啟動時間下降 — 過去靠 Volcano 的 PodGroup 加上 admission webhook 拼出來的 Gang Scheduling，鏈路長、debug 困難。原生支援後排程決策延遲明顯下降。
- 拓撲感知（TAS）對 NCCL 親和性是大利多 — 訓練 Pod 集中在同一機架/同一交換機可以大幅提高 all-reduce 頻寬利用率。建議先在分散式訓練場景灰度啟用
TopologyAwareWorkloadSchedulingfeature gate，重點觀測跨域流量、任務完成時延與 pending 行為。 - v1.36 的 TAS 不會觸發 workload/pod preemption — 純粹是放置決策的優化，可以放心啟用。
五、其他重要 GA 功能
5.1 Mutating Admission Policies（KEP-3962）
基於 CEL 的 Mutating Admission Policies 進入 GA。這意味著「聲明式、進程內」的變更准入能力進入穩定階段，與已 GA 的 Validating Admission Policy 形成閉環——校驗 + 變更兩個環節都能擺脫對外部 webhook 的硬依賴。
個人觀察：對多集群平台來說，這是降低控制面複雜度的關鍵。過去一個 mutating webhook 的故障可以放大到所有 API 請求路徑，現在 CEL-based MAP 直接跑在 apiserver 內，不再需要部署、憑證輪換、HA 等運維開銷。對小型團隊尤其友善。
5.2 ServiceAccount Token 外部簽名（KEP-740）
把 ServiceAccount token 簽名能力標準化地委託給外部系統（HSM、雲 KMS）。對有合規要求的金融、政府叢集是剛需——讓 Kubernetes 與企業既有的密鑰治理體系對齊，把密鑰保護邊界從單叢集節點層提升到統一安全基礎設施。
5.3 Volume Group Snapshot（KEP-3476）
把多個相關卷作為一個邏輯組進行快照與恢復，目標是 crash-consistent。對訓練平台、狀態型中介軟體和複雜事務應用都有幫助。特別是 ML 訓練檢查點場景——模型權重、優化器狀態、訓練資料這幾個獨立 PV 之間有強寫入順序關係，過去單卷快照很難拼出一致恢復點。
5.4 細粒度 Kubelet API 鑑權（KEP-2862）
允許按請求類型（exec、logs、metrics、port-forward）進行更細粒度授權。這對最小權限模型是個重要進展——過去拿到 kubelet API 權限就等於拿到全部，現在可以把 logs 給 SRE、把 exec 限制給特定運維帳號。
5.5 Node Log Query（Windows 也 Stable 了）
通過 kubelet /logs 查詢節點服務日誌的能力進一步固化，覆蓋 Linux 與 Windows 節點。注意是否開放系統日誌處理仍依賴 kubelet 配置項 enableSystemLogHandler——能力穩定不等於默認全面開放，建議納入「故障排查開關」運維手冊，而不是長期暴露。
5.6 User Namespaces 持續穩定
hostUsers: false 把容器內的 UID/GID 與宿主機身份解耦，配合 ID-mapped mounts，卷掛載不再依賴大規模 chown，在大卷場景下啟動與恢復效率明顯改善。對降低容器逃逸風險是顯著的安全提升。
六、其他重要 Beta 功能
6.1 Constrained Impersonation（KEP-5284）
「全權限繼承」轉變為「受控委託」的 impersonation 機制。模擬者不只需要「模擬目標身份」的權限，還必須具備「在該身份下執行具體操作」（impersonate-on:<mode>:<verb>）的權限。對多租戶平台、審計敏感的日常運維場景非常實用。
6.2 Mixed Version Proxy（KEP-4020）
混合版本代理（又名「未知版本互操作代理」）在版本偏斜場景下把請求轉發到可處理該資源的 API Server。對「滾動升級中偶發 404 / 發現不一致」的緩解價值高，建議當作升級窗口穩定性增強項評估。
6.3 Controller Stale Cache 防護（KEP-5647）
讓 controller 能感知 informer cache 當前推進到的 resourceVersion，並在關鍵寫入後記錄對應的 resourceVersion；下一輪 reconcile 前如果本地 cache 尚未追上前一次寫入，就跳過本輪處理並 requeue。
這個 KEP 解的是大規模叢集的隱性問題——controller 基於陳舊 cache 做決策導致重複 reconcile、錯誤刪除 Pod、錯誤擴縮容。對自寫 operator 的團隊很值得學習這套「讀己之寫」的模式。
6.4 IP/CIDR 驗證收緊（KEP-4858）
收緊非規範和歧義 IP/CIDR 寫法的接受範圍。升級前建議先做配置巡檢，清理歷史遺留的「可解析但不規範」地址寫法，避免在發布窗口觸發阻塞。
6.5 statusz / flagz 預設啟用
核心組件的 /statusz 與 /flagz 升級 Beta 且預設啟用，組件運行狀態和關鍵配置暴露方式更一致。對控制面巡檢和基線核對是好事。
七、其他 Alpha / 廢棄功能
7.1 HPA Scale to Zero（KEP-2021，Alpha）
HPA 在 Object/External metrics 場景支援從 0 到非 0 的伸縮。注意不適用於 CPU/Memory 這類依賴運行中 Pod 的資源指標，而是更適合佇列長度、外部事件積壓量等可在副本數為 0 時仍被觀測到的指標。試點要重點關注冷啟動時延、指標時效、誤擴縮容保護與回滾路徑。
7.2 Server-side Sharded List/Watch（KEP-5866）
在 LIST/WATCH 請求中加入服務端分片能力（透過 shardSelector 指定 shard key 與 hash range），由 apiserver 在源頭過濾物件和事件。這條對大叢集 kube-state-metrics 的水平擴展是質的飛躍——過去靠 client-side sharding 每個副本還是要收完整 watch stream 再丟棄，副本越多浪費越大。
7.3 CRI List Streaming（KEP-5825）
把類似問題搬到節點側：kubelet 與容器運行時之間的 List 類調用引入服務端流式返回，避免一次性返回大量容器或鏡像信息造成 kubelet 內存峰值。Pod、容器、鏡像數量越多的節點，這個改動的價值越高。
7.4 Native Histogram Support（KEP-5808）
控制面組件可以導出更高解析度的延遲分布資料。比起傳統 Prometheus histogram 依賴固定 buckets，Native Histogram 使用更稀疏、動態的表達方式，提升對長尾延遲和突發抖動的觀察能力。對 apiserver SLI/SLO 建設直接有用。
7.5 Manifest 驅動的准入控制配置（KEP-5793）
由 ManifestBasedAdmissionControlConfig feature gate 控制，apiserver 啟動時從本地目錄載入 ValidatingWebhookConfiguration / MutatingWebhookConfiguration / ValidatingAdmissionPolicy 等。它解決的是 API 型准入配置的治理問題——避免關鍵准入配置在叢集啟動早期尚未創建或尚未生效，也降低被 K8s API 刪除、修改或在 etcd 異常時不可用的風險。
7.6 廢棄 / 重要變更
Service.spec.externalIPs 廢棄（KEP-5707）
v1.36 開始給出告警，計畫在 v1.43 移除實作（字段不會移除）。遷移路徑：LoadBalancer、NodePort 或 Gateway API。
gitRepo 卷驅動永久禁用（KEP-5040）
v1.36 起永久禁用且不可重新啟用。遷移路徑：initContainer、鏡像構建階段打包，或外部 git-sync sidecar。
Ingress NGINX 已退役
雖然不是 K8s 本體變更，但 Ingress NGINX 已於 2026 年 3 月退役，不再提供後續修復和安全更新。現網仍可運行但建議盡快評估遷移到 Ingress NGINX 的後續分支、Gateway API + Cilium / Istio 等方案。
八、升級建議
按照「風險 / 收益」排序，給出我的升級節奏建議：
立刻評估（風險低、收益高）
- MAP（KEP-3962）GA — 把 mutating webhook 改成 CEL policy。
- Mixed Version Proxy（KEP-4020）Beta — 升級窗口的穩定性保險。
- Volume Group Snapshot（KEP-3476）GA — 訓練檢查點、有狀態應用立刻受惠。
- DRA Resource Health（KEP-4680）Beta — GPU 叢集的可觀測性大躍進。
試點驗證（中度改動）
- DRA Extended Resource（KEP-5004）Beta — staging 切換 DRA driver 不改 YAML。
- DRA Partitionable Devices（KEP-4815）Beta — 跑 GPU MIG 場景。
- Constrained Impersonation（KEP-5284）Beta — 多租戶平台值得跟進。
深度評估（高價值但需要規劃）
- WAS（KEP-4671）Alpha — 新訓練叢集可以開始試，舊 Volcano/Kueue 不急著換。
- Server-side Sharded List/Watch（KEP-5866）Alpha — 千節點以上叢集的長期答案。
升級前必做檢查
- [ ] 排查
Service.spec.externalIPs使用情況、規劃遷移 - [ ] 排查
gitRepo卷使用情況、改 initContainer 或 git-sync - [ ] 排查 IP/CIDR 配置是否有非規範寫法（KEP-4858）
- [ ] 評估 Ingress NGINX 替代方案
- [ ] 確認 etcd / kube-apiserver / kubelet 版本偏斜窗口（v1.36 開始 +/-3 minor）
九、小結
v1.36『Haru』把這幾年累積的 AI/HPC 場景需求集中釋放——DRA 一口氣有 7 ~ 8 個 KEP 推進、WAS 把 Gang Scheduling 帶進主線。對長期跟著 Kubernetes 升級的平台團隊，這個版本值得花比平常多的時間做評估。
如果只能挑三個動作做：
- 試 KEP-5004：在 staging 把 device plugin 換成 DRA driver，不改任何 Pod YAML。
- 試 KEP-3962：把一個高頻 mutating webhook 改寫成 CEL Mutating Admission Policy。
- 試 KEP-5732：在訓練叢集啟用
TopologyAwareWorkloadScheduling，觀測 NCCL 通訊頻寬與訓練時延變化。
三個動作做完，你會對「這個版本到底改變了什麼」有比讀完整份 release notes 更深的體感。
赤富士山頂上的「晴れに翔け」——希望我們的叢集也能在這個春天飛向晴空。
參考資料
- Kubernetes v1.36 Sneak Peek
- Kubernetes v1.36 主題討論
- Kubernetes v1.36 發布分支說明
- Kubernetes v1.36 變更日誌
- Kubernetes v1.36 Release Notes Draft
- KEP 索引（kep.k8s.io）
- 原始來源整理：DaoCloud 道客船長公眾號（作者：徐俊杰，Kubernetes 指導委員會成員、Kubeadm Maintainer）
- KubeCon EU 2026 SIG Scheduling / WG Device Management 維護者主題
發佈留言