分散AIトレーニング基盤では、ノード資源不足時にPodがばらばらに起動してしまい、GPU・ネットワーク・ストレージを消費したまま学習が開始できない問題が発生しやすい。Kubernetesは2025-12-29公開の公式解説で、Workload APIとGangSchedulingプラグインをv1.35でAlpha導入したことを明示している。本稿執筆時点の2026-03-19では、Kubernetes v1.36は2026-04-22リリース予定であり、すでにKEPではv1.36向けのAPI再設計（PodGroup分離）が進んでいる。したがって実装の現実解は「v1.35 Alphaを運用検証しつつ、v1.36のAPI差分を吸収できる構成」を先に作ることである。

v1.35とv1.36の位置づけを先に固定する

まず前提を誤ると設計が崩れる。公式Release情報では、v1.36.0のリリース日は2026-04-22であり、2026-03-19時点では未リリースである。一方、Workload APIとGang Schedulingの初期実装は、v1.35の機能紹介で明確に示されている。したがって、実装計画は以下の二層で設計するべきである。

  • 運用導入層: v1.35の scheduling.k8s.io/v1alpha1 と GenericWorkload/GangScheduling を前提にPoCとSLO検証を実施する。
  • 将来互換層: KEP-4671/5832が示すv1.36系の v1alpha2（workloadRef から schedulingGroup への変更、PodGroup分離）へ移行しやすい抽象化を先に入れる。

この二層分離をしない場合、Alpha API変更のたびにジョブコントローラ・Admission・監視クエリを同時改修する必要が生じ、AI基盤全体の変更リードタイムが長期化する。

Workload API + PodGroupの最小実装パターン

v1.35の公式記事で示される設計は、Workloadオブジェクトで「どうスケジュールするか」を記述し、Pod側でWorkload参照を持たせる形である。分散訓練では、同一レプリカ群をPodGroupとして扱い、gang.minCount で最小同時起動数を宣言する。設計上のポイントは次の3点である。

  • 学習ジョブ粒度をWorkloadに寄せる: JobSetや独自Controllerの各レプリカ群をWorkload/PodGroup単位で定義する。
  • 同期起動閾値を数値化する: 例として8 GPUノード学習なら minCount=8 を明示し、部分起動による資源浪費を回避する。
  • 観測対象をPodからPodGroupへ拡張する: 失敗分析を「どのPodが失敗したか」から「どのグループが成立しなかったか」に切り替える。

v1.36系ではPodGroupの独立ライフサイクルと状態管理が強化される方向でKEPが更新されているため、監視や運用Runbookは今の段階からグループ中心に寄せておく方が安全である。

ギャングスケジューリングを有効化する実装手順

v1.35時点では、機能を明示的に有効化しないと期待動作にならない。実装時はControl Plane構成とジョブ定義の両方を同時に管理する。

# kube-apiserver / kube-scheduler のfeature gate例
--feature-gates=GenericWorkload=true,GangScheduling=true
# API group有効化（環境に応じて設定）
--runtime-config=scheduling.k8s.io/v1alpha1=true

ジョブ側の設計例（概念）は以下である。

Workload:
  podGroups:
    - name: workers
      policy:
        gang:
          minCount: 4

Pods:
  spec:
    workloadRef:
      name: training-job-workload
      podGroup: workers

運用で必ず計測すべき指標は、(1) group成立待ち時間、(2) pending解消率、(3) preemption回数、(4) ジョブ開始遅延である。特にGPUクラスタでは、minCount を過大にすると待機時間が増加し、過小にすると通信同期（AllReduce）の失敗率が上がるため、ワークロード特性ごとの閾値テーブル化が必要である。

CSIボリューム制限とCluster Autoscalerの統合点

分散学習では、GPUだけでなくチェックポイントI/O用のボリューム制約がボトルネックになる。Cluster Autoscaler 1.35.0のリリースノートには、ノードスケール時にCSI volume limitsをカウントする機能追加（PR #9037）が記載されている。これは「CPU/GPU余力はあるが、アタッチ可能ボリューム上限で実際は配置不可」という誤判定を減らすための重要な改善である。

実装上は次の順で統合する。

  • ノードグループごとにCSIドライバのアタッチ上限を明示し、Autoscaler判定に取り込む。
  • GangSchedulingの minCount 設計時に、GPU数だけでなく「同時に張れるボリューム数」を同一式で制約化する。
  • スケールアウト成功判定を「Node増加」ではなく「PodGroup成立 + ボリュームAttach成功」で定義する。

この統合がないと、見かけ上はノードが増えてもPodGroupが成立せず、学習開始までのP95レイテンシが改善しない。

既存AI基盤からの移行設計（90日プラン）

既存基盤（Argo/Kubeflow/JobSet独自拡張）からの移行は、API安定化を待って一括移行するより、段階的に進める方が失敗コストが低い。推奨は90日3フェーズである。

  • Phase 1（0-30日）: v1.35 Alphaで非本番PoC。Workload API適用、feature gate有効化、Group単位メトリクス収集を実装。
  • Phase 2（31-60日）: 本番の一部学習ジョブをカナリア移行。minCount と優先度を調整し、ジョブ開始遅延と失敗率を比較。
  • Phase 3（61-90日）: v1.36 API差分（workloadRef→schedulingGroup 等）に備え、Controllerの参照レイヤを抽象化して切り替えテスト。

リスク管理では、Alpha機能の仕様変更を前提に「マニフェスト変換器」「互換Webhook」「ロールバック可能なFeature Gate管理」をセットで準備することが必須である。これにより、Kubernetes本体の進化速度に合わせてAI基盤を安全に追従できる。

FAQ

Q1. v1.36が未リリースでも、タイトルをv1.36実装ガイドにしてよいか？

可能である。ただし本文で「2026-03-19時点ではv1.36未リリース、2026-04-22予定」と明示し、実装の基点をv1.35 Alpha、移行先をv1.36設計差分として分離して記述する必要がある。

Q2. GangSchedulingだけ導入すれば分散学習の詰まりは解消するか？

不十分である。実運用ではGPU在庫、ネットワーク帯域、CSIボリュームAttach上限が同時制約になるため、Autoscaler側のCSI volume limitsカウントと合わせて設計しないと、PodGroup成立率は上がらない。

Q3. 既存のVolcanoやkueueと競合しないか？

競合し得る。ネイティブ機能の適用範囲（ジョブ種別・優先度制御・プリエンプション方針）を先に定義し、同一ワークロードに複数のスケジューリング責務を重ねない設計が必要である。

Q4. どのメトリクスをSLOに置くべきか？

最低限、PodGroup成立時間P95、学習開始成功率、スケールアウト後のAttach失敗率、pending総時間を四半期で追うべきである。個別PodのPending時間だけではボトルネックを見誤る。

参考文献