Kubernetes v1.36：Workload / PodGroup API 分離，為 AI/ML 批次排程奠定新架構
kubernetes.io · 2026-05-13
Kubernetes v1.36 在 scheduling.k8s.io/v1alpha2 API 組中引入對 AI/ML 與批次排程的重大架構改動：將 Workload API（靜態範本）與 PodGroup API（執行期物件）分離，並在此基礎上新增 topology-aware scheduling、workload-aware preemption 與 Dynamic Resource Allocation（DRA）支援，解決過去 Gang Scheduling 只能以 Pod-by-Pod 方式擴展的限制。所有功能目前均為 alpha 階段。
Workload / PodGroup 分離
v1.35 將排程策略與執行期狀態都放在同一個 Workload 物件中，造成多副本時狀態更新的競爭。v1.36 引入明確分工：
- Workload：宣告式範本，描述排程策略（Gang scheduling 的
minCount、topology hints 等），不可變 - PodGroup：執行期物件，每次執行建立一個，攜帶
schedulingGroup指向對應的 Workload，負責反映實際的排程狀態
apiVersion: scheduling.k8s.io/v1alpha2
kind: Workload
metadata:
name: training-job
spec:
podGroupTemplates:
- name: workers
schedulingPolicy:
gang:
minCount: 4 # 至少 4 個 Pod 可調度才整批啟動新增排程功能
- PodGroup Scheduling Cycle：排程器以 PodGroup 為原子單位批次處理，避免 Gang 一半 Pod 調度成功、另一半失敗的孤兒狀態
- Topology-Aware Scheduling：第一版實作，讓 GPU 訓練任務盡量排在同一 NUMA domain 或 rack，減少跨節點通訊延遲
- Workload-Aware Preemption：驅逐低優先級 Pod 時，以 PodGroup 完整性為考量，不拆散正在執行的 Gang
- ResourceClaim 支援：PodGroup 可透過 DRA 請求 GPU、自訂加速器等特殊硬體資源
遷移注意事項
v1.36 的 alpha API 中 Pod 規格裡的 workloadRef 欄位已被 schedulingGroup 取代，現有 v1.35 的 alpha 使用者需要更新 manifest。Kubernetes Job Controller 的整合也在 v1.36 進入 Phase 1，讓原生 batch/v1 Job 得以利用新的 workload-aware 排程能力，但完整整合預計在後續版本完成。
原始來源：Kubernetes Blog
Slack AI 的多雲之路：四個階段從 SageMaker 到 AWS+GCP 雙雲智慧路由
Slack Engineering · 2026-05-28
Slack Engineering 發文記錄 Slack AI 基礎設施從單一雲端供應商演進至 AWS + GCP 雙雲架構的四個階段。最終架構在 Vertex AI 加入後實現 10% 的 reasoning 準確率提升和 67% 的低 token 負載延遲下降，同時消除單一供應商停機作為單點故障的風險。
四階段演進
| 階段 | 基礎設施 | 主要限制 |
|---|---|---|
| Phase 1 | AWS SageMaker（自行部署模型） | GPU 稀缺、scaling 延遲、模型更新落後生態系 |
| Phase 2 | Amazon Bedrock（全託管） | 單一供應商依賴 |
| Phase 3 | Bedrock 混合模式（PT + OD） | 延遲敏感功能用 Provisioned Throughput，非同步用 On-Demand |
| Phase 4 | AWS Bedrock + GCP Vertex AI | —（目前狀態） |
Spillover Pattern 與智慧路由
Phase 3 引入的 Spillover Pattern 是架構核心：將延遲敏感的同步請求保留在 Provisioned Throughput 容量，當容量不足時自動溢出至 On-Demand，防止請求因容量耗盡而失敗。Phase 4 將此模式延伸至跨雲層次——以自動 circuit breaker 監測各供應商的端點健康，路由層可在毫秒內切換至備援雲端。
多雲帶來的模型優化空間
除了可用性之外，多雲路由開創了模型-任務匹配優化的空間：不同功能使用最適合的模型，而非所有功能共用同一模型。Slack 團隊觀察到將特定低 token 負載功能路由至 Vertex AI 上的模型後，延遲下降 67%，同時 reasoning 類任務的準確率提升 10%。