AIワークロードでKubernetesの自動スケーリングが失敗する理由と、DRAによる解決策

Kubernetesは長らく、既存ノード上にPodを配置する「スケジューラ」と、容量不足時に新しいノードを追加する「オートスケーラー」を明確に分離して運用してきました。この役割分担は標準的な計算リソースではうまく機能していましたが、特定のアクセラレーター・トポロジーを必要とするAIワークロードの増加により、その限界が見え始めています。2026年10月現在、コミュニティではこれらのコンポーネントを再設計し、ハードウェア制約について共通の認識を持てるように取り組んでいます。

何が起きたのか

過去10年間、計算リソースは基本的に互換性があるという前提のもと、スケジューラとオートスケーラーは独立して動作していました。しかし、GPUなどのAIアクセラレーターは汎用的ではなく、CPU、メモリ、他のGPUとの接続方法によって性能が大きく左右されます。現在よくある障害パターンとして、クラスターに空き容量があるように見えてもPodがPending状態のまま留まることが挙げられます。オートスケーラーがノードを追加しても、ハードウェアのトポロジーがワークロードの厳密な局所性要件と一致しないため、スケジューラがそのノードを拒否してしまうのです。

根本的な問題は、オートスケーラーが「ノードを追加すべきか」という問いには答えますが、「追加されたノードがワークロードに適した形状か」という本当の質問には答えられない点にあります。オートスケーラーがアクセラレーターの複雑な配線を理解せずにノードをプロビジョニングすると、スケジューラはPodを配置できません。この不一致により、高価なアクセラレーター容量が無駄になり、重要な推論やトレーニングジョブが遅延します。Cloud Native Computing Foundation（CNCF）は、これがベンダー固有の問題ではなく、上流のKubernetesにおける根本的なアーキテクチャ上の課題であることを強調しています。

これに対応するため、コミュニティはハードウェア記述のための共通語彙への移行を進めています。従来、Kubernetesはアクセラレーターを単純な整数カウントとして扱っていました。しかし、Dynamic Resource Allocation（DRA）の導入により、ワークロードは必要なデバイス数だけでなく、それらのデバイス間およびネットワークインターフェースとの関係性を記述する構造化されたクレーム（要求）を提出できるようになりました。これにより、スケジューラとDRA対応のオートスケーラーの両方が、同じ詳細な基準を用いて容量を評価できます。

仕組み

Dynamic Resource Allocationは、リソースモデルを生粋のカウントから構造化されたクレームへと変更します。単に「4つのGPUが必要」と要求する代わりに、ワークロードは「同一NUMAドメイン内にあり、高帯域幅リンクで接続された4つのGPUが必要」と指定します。スケジューラはこれらのクレームを直接読み取り、配置決定を行います。重要なのは、DRA対応のオートスケーラーが、将来の容量追加をシミュレートする際にこの同じ情報を利用し始めている点です。これにより、オートスケーラーがスケールアップを決定する際、ワークロードによって定義されたトポロジー制約を実際に満たすノードタイプを選択することが保証されます。

トポロジーに加え、DRAはアクセラレーターのより細粒度な共有も可能にします。現代のデバイスは高性能であり、小さなジョブにGPU全体を割り当てるのは無駄が多いと言えます。DRAはパーティショニング可能なデバイスをサポートしており、単一の物理アクセラレーターを隔離されたインスタンスや消費可能なシェアに分割できます。複数のワークロードが同時にデバイスの測定された部分を利用できます。スケジューラはこれらの分数割り当てを追跡し、オートスケーラーは丸ごとデバイスだけでなく、利用可能なスライスに基づいて候補ノードを評価できます。これにより、以前までGPU利用率を阻害していた「全有無」型の無駄が削減されます。

これらの進歩にもかかわらず、グループ全体が一括してスケジュールされるか、全くされないかのどちらかでなければならない「ガン・スケジューリング」については依然としてギャップが残っています。現在のワークロード認識型スケジューリングAPIにより、スケジューラはグループ全体を配置できるまでPodを保持できますが、オートスケーラーはまだPod単位で判断を下します。そのため、ジョブが残りのメンバーを待っている間に、ガン内の少数メンバーに対して部分的な容量をプロビジョニングし、リソースを無駄にする可能性があります。「プロビジョニングリクエスト」という暫定的なメカニズムが、ワークロードがグループ容量をアトミックに要求できるようにすることでこのギャップを埋めようとしていますが、これは深く統合された機能というよりは、後付けのソリューションにとどまっています。

主要なポイント

• トポロジーが重要: アクセラレーターの性能は、デバイス数だけでなく、CPU NUMAドメイン、PCIeパス、GPU間リンクなどの局所性に依存します。
• Dynamic Resource Allocation (DRA): デバイス関係やネットワークインターフェースを記述する構造化されたクレームで、整数ベースのリソース要求を置き換えます。
• 共通語彙: DRAにより、スケジューラとオートスケーラーがハードウェア制約を同一に理解できるようになり、プロビジョニングの不一致が減少します。
• 分数共有: DRAはパーティショニング可能なデバイスと消費可能な容量をサポートし、複数のワークロードが単一のアクセラレーターを効率的に共有できるようにします。
• ガン・スケジューリングのギャップ: スケジューラはアトミックなグループ配置をサポートしていますが、オートスケーラーはまだPod単位でスケーリングするため、大規模分散ジョブでは潜在的な無駄が発生します。
• 将来の統合: SIG-AutoscalingとSIG-Schedulingは、スケジューラがプロビジョニング可能な容量を確認し、明示的に要求できるようにするAPIを設計しています。

なぜ重要なのか

AIインフラストラクチャーを管理するエンジニアリングチームにとって、この不一致は直接的に予算の浪費とイテレーションサイクルの遅延につながります。GPU時間は高価であり、スケジューリングとプロビジョニングの不一致のためにアイドル状態になることは、大きな運用コストとなります。Pending状態のPodは地域全体の容量不足を示すのではなく、トポロジーの不一致を示している可能性があることを理解することは、チームがクラスターをデバッグし最適化する方法を変えます。焦点は単にノードを増やすことから、追加されるノードがワークロードの構造的ニーズと互換性があることを確保することへ移ります。

さらに、統合設計への移行は、今後のKubernetes機能が最初から自動スケーリングへの影響を考慮することを意味します。新しいスケジューリングプリミティブが出荷された後に自動スケーリングサポートを後付けするのではなく、コミュニティは2つの制御ループが積極的に対話できるインターフェースを構築しています。この進化は、コールドスタートや誤ったプロビジョニングによるレイテンシーを許容できないバースト性の推論やエージェント型ワークロードをサポートするために不可欠です。現在アクセラレーターを実行しているチームは、結果として生じる標準が数年間にわたるインフラ効率を定義するため、これらの上流での議論に関与する利害関係者となっています。

実行できること

• Pending Podの監査: Pending状態のGPU Podが、真の容量枯渇ではなくトポロジーの不一致によるものかどうかを確認してください。
• DRAの採用: ワークロードをDynamic Resource Allocationクレームに移行し、トポロジーと共有要件を明示的に表現してください。
• ワークロード認識型スケジューリングの有効化: ガン・スケジューリングの挙動を改善するために、ベータ版のWorkloadおよびPodGroup APIをテストしてください（デフォルトでは無効です）。
• オートスケーラーの互換性評価: 現在のオートスケーラー実装がDRA対応であり、スケールアップ中にトポロジー制約をシミュレートできるかどうかを検証してください。
• 断片化の監視: GPU使用率メトリクスを追跡し、全有無型の割り当てによる無駄を特定し、分数共有の有効化を検討してください。
• SIGへの関与: 今後の統合APIの設計に影響を与えるために、SIG-AutoscalingおよびSIG-Schedulingの議論に参加してください。