# Kubernetes Workload・PodGroup API ## 定義 Kubernetes の Workload・PodGroup API は、kube-scheduler にギャングスケジューリング(ある集合のPodを all-or-nothing で起動する方式)のフレームワーク支援を組み込む [KEP-4671] で導入された、`scheduling.k8s.io` の2つの新規リソース種別である。`Workload` は `podGroupTemplates` を通じてスケジューリングポリシー(`Basic` または `minCount` 指定の `Gang`)を定義する長寿命の設定テンプレートであり、`PodGroup` はそこから生成されるスタンドアロンのランタイムスケジューリング単位で、実行状態(status)を自己完結的に保持する。Pod は `spec.schedulingGroup.podGroupName`(immutable)で自身が属する `PodGroup` を直接参照する。分散学習・推論のように全Pod間の密結合通信を要するワークロード(`JobSet`・`LeaderWorkerSet`・`MPIJob`・`TrainJob` 等)を主要な対象とする。(Source: [[@2025__KEP__KEP-4671 Gang Scheduling using Workload Object]]) Alpha(v1.35)は `PreEnqueue`/`WaitOnPermit` バリアによる単純なall-or-nothing実装、Beta(v1.37)は `PodGroup` 単位で全メンバーPodを単一クラスタスナップショット上で一括処理する **Workload Scheduling Cycle** へ刷新され、専用の `PlacementFeasiblePlugin` 拡張点と専用PodGroupキューを持つ。 ## 横断的知見 - **アカデミアのGPUクラスタスケジューリング研究が積み上げた「配置保証」「公平性」の理論は、Kubernetesネイティブ実装ではAlpha/Betaの時点でほぼ全て将来課題として先送りされている**: [[GPUクラスタスケジューリング]] が集約する [[HiveD]](配置保証のためVirtual Private Cluster抽象を導入)・[[Themis]](ギャングスケジューリングの配置感度がDRF/LASの公平性理論を破壊すると証明しオークション機構で対処)は、いずれも「ギャング全体をどこに置くか」を理論的に厳密化する方向で研究を進めた。対してKEP-4671はNorth Star Visionの8要件(最適配置・デッドロック回避・ワークロードレベルプリエンプション等)を明示的に列挙しながら、Beta時点では「同種(homogeneous)なPodGroupなら配置が存在すれば発見できる」という限定的保証しか提供せず、異種PodGroupや複雑なアフィニティ制約下の最適配置・公平性オークションのような機構は範囲外としている。プロダクショングレードのKubernetesコアAPIは、まず「動くビルディングブロック」を提供し、HiveD/Themis級の高度な保証は後続KEPに委ねるという段階的経路を選んでいる。(Source: [[@2025__KEP__KEP-4671 Gang Scheduling using Workload Object]], [[GPUクラスタスケジューリング]]) - **DRAとギャングスケジューリングは、Kubernetesコアが2つの異なる軸で「単純化されすぎた旧モデル」を置き換える、同時並行の進化として読める**: [[Dynamic Resource Allocation (DRA)]]([KEP-4381])はPodあたりのデバイス要求表現力(単一の線形量しか表せない旧デバイスプラグインAPI)を刷新し、本概念はPod集合のスケジューリング単位(1Pod単位でしか考えられない旧pod-by-pod cycle)を刷新する。両者は互いに独立した拡張だが、KEP-4671自身が「DRAリソースをブロックする際に `NominatedNodeName` だけでは解決できない」という未解決のコーナーケースを明記しており、将来の `Reservation` オブジェクトが両概念を接続する結節点になる設計が示唆されている。(Source: [[@2025__KEP__KEP-4671 Gang Scheduling using Workload Object]], [[Dynamic Resource Allocation (DRA)]]) - **「エコシステムに既存実装が複数ある機能をコアへ吸収する」という設計判断のパターンが、DRAとギャングスケジューリングで反復している**: DRAは4限界を抱えたデバイスプラグインAPIをコアが置き換えた事例であり、本KEPはVolcano.sh・Co-scheduling plugin・Preferred Networks Plugin・Kueueという「kube-scheduler外で少なくとも4回実装されてきた」ギャングスケジューリングをコアへ吸収する事例である。両者ともDrawbacksセクションで「既存実装で十分ではないか」という反論に対し「レース・デッドロック等への対処の不完全さ」「AI時代の基盤性」を理由に反論しており、[[コンテナオーケストレーション]] concept が指摘する「コンテナオーケストレーション研究はデプロイ容易性を主目的としリソース管理は副次的だった」という2019年時点の知見から、2025年前後にはリソース管理・スケジューリングの表現力そのものがコアの主戦場へ移ったことを示す。(Source: [[@2025__KEP__KEP-4671 Gang Scheduling using Workload Object]], [[コンテナオーケストレーション]]) - **本 KEP がスコープ外とする「真のワークロードコントローラ」側の統合実装は、コアAPI設計に先行してレプリカ・プラガブルスケジューラの2軸で既に個別に確立されていた**: 本KEPは `PodGroup` の生成・所有を「真のワークロードコントローラ」([[LeaderWorkerSet]]・Job・JobSet等)に委ねる設計を採るが、その具体的な実装パターンは [[@2025__KEP__KEP-407 Gang Scheduling (LeaderWorkerSet)]] が既に示している。LWS の `SchedulerProvider` インターフェースは、Volcano・coscheduling scheduler-plugin・YuniKornという複数の外部PodGroup実装をプラガブルに切り替える抽象化であり、本KEPが目指す「コアAPI標準化によるエコシステム統合」とは異なる、個別ワークロードコントローラ側での「複数スケジューラを吸収する」設計判断である。両者は同じ「ギャングスケジューリングのエコシステム分散」問題を、コア(本KEP、kube-scheduler拡張点)とコントローラ(KEP-407、Provider抽象)という異なるレイヤーで独立に解いている。(Source: [[@2025__KEP__KEP-4671 Gang Scheduling using Workload Object]], [[@2025__KEP__KEP-407 Gang Scheduling (LeaderWorkerSet)]]) - **LWS の KEP-407 は本KEPの `Workload`/`PodGroup` 分離設計より前(2025-04-08起草、本KEPは2025-09-17)に、PodGroupのownershipをLeader Podへ紐付ける同型の設計に到達している**: 本KEPが `PodGroup` を独立ランタイムオブジェクトとして「真のワークロードコントローラ」に所有させる設計へ転換した理由(§動機)と、KEP-407がPodGroupのOwnerReferenceをLeader Podに設定しライフサイクルを完全同期させた設計は、「PodGroupの寿命を実行主体に厳密に一致させる」という同一の設計原理を異なる時期・異なるレイヤーで独立に発見している。KEP-407はコアAPI標準化を待たず、既存の複数PodGroup CRD実装(Volcano等)へ委任する形でこの原理を先取り実装していた。(Source: [[@2025__KEP__KEP-407 Gang Scheduling (LeaderWorkerSet)]]) ## 未解決の問い - 本KEPの `scheduling.k8s.io` PodGroup APIがGA化した後、[[LeaderWorkerSet]] のような既存ワークロードコントローラは `SchedulerProvider` 経由の外部PodGroup CRD統合(Volcano/coscheduling/YuniKorn)から本KEPのネイティブPodGroup APIへ移行するのか、それとも両者を並行サポートし続けるのか。KEP-407自体はこの移行経路に言及していない。 - [KEP-5710](workload-aware preemption)は本概念と同一フィーチャーゲートで卒業段階が同期されているが、その具体的な設計(ワークロード単位のvictim選定アルゴリズム)はまだ本 vault に取り込んでいない。ingestして本概念・[[GPUクラスタスケジューリング]] のプリエンプション知見(Themisのオークション機構等)と比較する必要がある。 - Beta の Workload Scheduling Cycle アルゴリズムが「同種PodGroupなら配置発見を保証」する一方、[[HiveD]] のVirtual Private Cluster抽象や[[Themis]]の公平性オークションのような、より高度な配置保証・公平性機構をこのAPIの上にどう構築できるか(あるいはKubernetesコアが将来的にどこまで踏み込むか)は本KEPでは示されていない。 - North Star Visionの要件(8)(Cluster Autoscaler/Karpenterとの統合によるインフラプロビジョニングを伴うギャングスケジューリング)は「最大の労力を要する」と明記されつつ初期実装では既存メカニズム(NominatedNodeNameでのリソース予約)による緩和のみとされる。Karpenterとの統合の具体的な設計は今後のKEPで明らかになるはずで、追跡が必要。 - Volcano.sh・Kueueは本KEPのGenericWorkload API GA後もエコシステムで併存し続けるのか、それともコア機能への収斂が進むのか。DRAがデバイスプラグインAPIを置き換えたのとは異なり、こちらはコアがフレームワークのみ提供し複数ワークロードキュー・公平性は引き続きKueue/Volcano.shに委ねる非対称な関係にある点をどう評価するか。 ## 関連 - ソース: [[@2025__KEP__KEP-4671 Gang Scheduling using Workload Object]] / [[@2025__KEP__KEP-407 Gang Scheduling (LeaderWorkerSet)]] - エンティティ: [[Kubernetes]] / [[LeaderWorkerSet]] - 概念: [[GPUクラスタスケジューリング]] / [[Dynamic Resource Allocation (DRA)]] / [[コンテナオーケストレーション]] ## 出典 - [[@2025__KEP__KEP-4671 Gang Scheduling using Workload Object]](KEP全文。API設計・スケジューラアーキテクチャ・昇格条件・代替案) - [[@2025__KEP__KEP-407 Gang Scheduling (LeaderWorkerSet)]](KEP全文。LeaderWorkerSetのReplicaResourceProviderインターフェース設計、PodGroupのownership・ライフサイクル同期)