Kubernetes v1.36 Workload-Aware Scheduling：Gang Scheduling 與 PodGroup API 重大更新
Kubernetes Blog · 2026-05-13
Kubernetes v1.36 對 AI/ML 工作負載的調度機制進行了重大架構調整，發布新版 scheduling.k8s.io/v1alpha2 API，將 Workload（靜態模板）與 PodGroup（執行時物件）分離，並引入 Gang Scheduling 原子調度、拓樸感知調度與 Dynamic Resource Allocation（DRA）整合。這些功能仍在 alpha 階段，但架構已清晰展示未來穩定化路徑。
核心改動
Workload API 與 PodGroup API 的分離是最重要的架構決策：原本 v1alpha1 的 Workload API 同時承擔靜態模板與執行時狀態的職責，造成大規模部署時的效能問題。v1alpha2 中 Workload 只描述「這個工作負載長什麼樣子」，PodGroup 則代表「這次執行的實例」，透過每個 replica 的狀態更新分片（per-replica status update sharding）提升可擴展性。
Gang Scheduling 讓一組 Pod 只有在全部都能被調度時才一起調度：
podGroupTemplates:
- name: workers
schedulingPolicy:
gang:
minCount: 4 # 必須同時取得 4 個 Pod 的資源才調度這解決了分散式訓練任務中常見的死鎖問題：部分 Pod 啟動後佔據資源，其餘 Pod 卻因資源不足無法啟動，整個任務陷入等待。
其他新增功能
- Topology-Aware Scheduling：首次迭代，讓工作負載感知 Cluster 拓樸進行 Pod 分布
- Workload-Aware Preemption：在工作負載層級而非 Pod 層級做搶佔決策
- ResourceClaim 支援：解鎖 DRA 對 PodGroup 的 GPU/加速器分配
- Job Controller 整合（Phase 1）：Job controller 開始使用新 Workload API
影響範圍
對於運行大規模 AI/ML 訓練任務的 Kubernetes 叢集管理員，Gang Scheduling 是最直接有用的功能，可以避免分散式訓練常見的資源餓死問題。目前功能仍在 alpha，API 版本為 v1alpha2，生產使用需注意 API 可能在未來版本變更。
原始來源：Kubernetes Blog
GitHub 用 eBPF 阻斷部署腳本呼叫自身：解決「自吃」循環依賴問題
GitHub Engineering · 2026-04-16
GitHub 在自身的部署基礎設施中使用 eBPF 攔截網路請求，確保部署腳本在執行時不會呼叫 github.com 本身——因為 GitHub 的原始碼就存放在 github.com 上，一旦服務中斷，無法存取原始碼的部署腳本將導致自我修復變得不可能。這個「雞生蛋、蛋生雞」問題歷時六個月最終透過 eBPF 在生產環境中解決。
原本的問題
GitHub 識別出三類循環依賴：
- 直接依賴：部署腳本在 github.com 不可用時從 GitHub 拉取 release
- 隱藏依賴：工具在執行過程中自動檢查更新，暗地呼叫 GitHub API
- 傳遞依賴：內部服務呼叫其他服務，後者又呼叫 GitHub，形成傳播鏈
採用的方法
解法使用兩種 eBPF program type：
BPF_PROG_TYPE_CGROUP_SKB：掛鉤 cGroup 的網路出口，對隔離在特定 cGroup 中的部署進程做網路過濾，不影響生產流量BPF_PROG_TYPE_CGROUP_SOCK_ADDR：攔截 socket 建立的系統呼叫，將 DNS 查詢（port 53）重定向到 userspace DNS proxy
實作使用 cilium/ebpf Go 函式庫，讓部署腳本進入受限 cGroup，所有 DNS 查詢透過自訂 proxy 評估封鎖清單。為了除錯，系統追蹤 DNS transaction ID 到 Process ID 的對映，並從 /proc/{PID}/cmdline 提取指令行資訊。
實際效果
六個月推廣後，循環依賴偵測已在生產環境上線。當部署腳本引入問題依賴時，團隊會立即收到通知，防止問題在真正發生障礙時才被發現。這也改善了事故期間的平均修復時間，因為消除了循環依賴這個阻礙自我修復的關鍵障礙。
Kubernetes v1.36 DRA 更新：硬體加速器抽象層逐漸成熟
Kubernetes Blog · 2026-05-07
Kubernetes v1.36 繼續推進 Dynamic Resource Allocation（DRA）的成熟化，新增更多硬體驅動支援、功能等級晉升，以及對 AI/ML 工作負載中複雜硬體需求的更好抽象。DRA 為管理 GPU、FPGA、網路加速器等特化資源提供了統一的 Kubernetes 原生 API，取代原本 device plugin 機制的限制。
核心改動
DRA v1.36 的核心進展是擴大驅動生態系統：更多硬體廠商提供原生 DRA driver，涵蓋 GPU（NVIDIA、AMD）、InfiniBand、特化 AI 加速器等。ResourceClaim 與 ResourceClass API 持續細化，讓管理員可以更精確地描述硬體拓樸約束。
新版增強了結構化參數（Structured Parameters）的表達能力：
- 支援跨節點的硬體拓樸感知分配
- 允許在 ResourceClaim 中指定硬體間的親和性與反親和性
- 與 Workload API 整合，讓 PodGroup 可以作為整體申請加速器資源
影響範圍
對於運行多租戶 AI 訓練或推論服務的 Kubernetes 叢集，DRA 解決了 device plugin 無法表達複雜拓樸需求的根本問題：例如「我需要 8 個 GPU，而且必須在同一個 NVLink 域內」這類約束，在舊 API 下無法原生表達，只能靠外部排程器或 hack 解決。v1.36 的 DRA 仍有部分功能在 alpha/beta，但整體架構已足夠成熟，適合作為技術選型的評估依據。
原始來源：Kubernetes Blog