本文へスキップ
MameTechNews
バックエンド

Kubernetes 1.37、ギャングスケジューリングのWorkload APIがベータに

## POINTS

  • WorkloadとPodGroupはv1beta1になり、全部揃ってから起動するギャングスケジューリングがベータになった
  • v1alpha2はv1alpha3へ置き換わり、disruptionModeはallとsingleへ改名される破壊的変更がある
  • ベータとアルファは既定無効なので、ジョブ基盤を自前で持つチームはゲートと移行手順を先に確認する

何が起きたか

Kubernetesプロジェクトは9月8日、v1.37でWorkloadとPodGroup API、およびギャングスケジューリングをベータ（v1beta1）へ進めた。Workload-Aware Preemptionと、PodGroup向けの共有DRA ResourceClaimsもベータになった。階層制約を表すCompositePodGroup APIが新たに入り、JobSetやLeaderWorkerSetが扱う分散構成をネイティブにスケジューリングしやすくする。

背景

学習やバッチは「全部揃ってから起動」が必要で、一部だけ配置されるとデッドロックしやすい。v1.37ではPodGroupがスケジューリングキューの一等市民になり、minCountは可変になった。アルファはv1alpha2からv1alpha3へ置き換わり、disruptionModeはallとsingleへ改名される。

実務への影響

ベータとアルファは既定無効で、フィーチャーゲートの手動有効化が必要だ。自前のジョブコントローラを持つチームは、workloadbuilderと破壊的変更を先に確認し、部分配置を前提にした運用を見直す必要がある。