このドキュメントでは、GPU、TPU、高性能 CPU などのリソースを取得するのに役立つ、復元性の高い Google Kubernetes Engine（GKE）クラスタとワークロード スケジューリング戦略を設計する方法について説明します。の Gemini と Cloud de Confiance by S3NS Compute Advisor（プレビュー版）を 活用することで、保留中の Pod を防ぎ、AI ワークロードの信頼性の高いスケジューリングを実現できます。
このドキュメントは、GKE インフラストラクチャを管理し、容量計画とスケジューリングを最適化したいクラウド アーキテクト、プラットフォーム管理者、オペレーターを対象としています。
GKE でのリソース取得可能性の概要
Kubernetes スケジューリングは、宣言されたリソース リクエストに依存します。GPU や TPU などの大規模なアクセラレータをスケジュールする場合、特定ハードウェアが使用できないと、厳格なリソース リクエストによってクラスタがスケールアップできなくなる可能性があります。 次の機能を使用すると、GKE で容量の可用性を最適化できます。
- ノードプールの自動作成: 動的なマルチファミリー ノードプールの作成。
- ワークロード レベルのフォールバック: 代替ハードウェアを受け入れるように構成された toleration とノードセレクタ。
- 地理的スケジューリングとリージョン スケジューリング: GKE のマルチゾーン機能とマルチリージョン機能。
- 予約管理: オンデマンド リソースをリクエストする前に、事前に購入した容量を使用する。
GKE でのリソース取得可能性に関するベスト プラクティス
このセクションでは、GKE でワークロードをスケジュールする際に容量の可用性を高めるための推奨事項について説明します。これらのベスト プラクティスでは、柔軟なハードウェア要件の設計、ノードプールの自動作成の構成、地理的分布を活用してリソースの制約に対応するなどの戦略について説明します。ノードプールの自動作成 は、Pod 仕様に基づいてノードプールを自動的に管理します。ノードプールを事前に定義するのではなく、Pod マニフェストでリソース要件を指定し、GKE でノードを動的に作成します。
Compute Advisor を使用して、次のベスト プラクティスを見つけて実装することもできます。詳細については、Compute Advisor を使用するをご覧ください。
ハードウェアの柔軟性オプション
容量の可用性を最適化するには、単一の静的マシン ファミリーまたはアクセラレータ タイプにワークロードをバインドしないように GKE に指示します。さまざまなワークロード クラスに対して柔軟なノードプールと Pod アフィニティ ルールを構成する方法の例を次に示します。選択する具体的な代替案は、アプリケーションのリソース需要によって異なります。
汎用 CPU ノードプール:
- 主な例: N2（Intel ベースの汎用）。
- 代替案の例: N2D（AMD EPYC）、C2 または C2D（コンピューティング最適化）、E2（費用最適化）。
- 実装パターン: 複数のマシン ファミリー
ラベル（
["n2", "n2d", "c2d"]のcloud.google.com/machine-familyなど）にまたがるスケジューリングを許可するノード アフィニティまたは toleration を使用して Pod 仕様を構成します。この構成により、GKE は使用可能な容量を持つプールをプロビジョニングできます。
GPU ノードプール:
- 主な例: A2 シリーズ（NVIDIA A100 GPU）。
- 代替案の例: L4（ユニバーサル AI/ML）または T4（推論）。
- 実装パターン: さまざまな GPU ティア用に個別のノードプールまたは ComputeClass を構成します。A100 固有の機能なしで実行できるワークロードの場合は、A2 のプロビジョニングが制約されている場合に、Pod が L4 または T4 プールにフォールバックできるようにします。
TPU ノードプール:
- 主な例: TPU Ironwood（TPU7x）。
- 代替案の例: TPU v6（Trillium）または TPU v5（v5e または v5p）。
- 実装パターン: TPU スライス プロビジョニングは非常に制約される可能性があります。TPU Ironwood（TPU7x）の容量が使用できない場合は、v6 または v5 スライスにデプロイできるように、フレームワーク レベルの柔軟性（可変スライス トポロジをサポートする JAX または PyTorch 構成など）を使用してトレーニング ワークロードを設計します。
次の表に、さまざまなタイプのワークロードの主な選択肢とハードウェアの代替案をまとめます。
| ワークロード タイプ | 主な選択肢の例 | 代替案の例 | アーキテクチャに関する注意事項 |
|---|---|---|---|
| システムまたはコア ワークロード | N2 | N2D、C2D、E2 | ノードプールの自動作成のために Intel と AMD のハードウェア プールにまたがります。 |
| GPU 推論と処理 | A2（A100） | L4、T4 | 低コストまたは高可用性の GPU ノードプールを柔軟にターゲットにします。 |
| TPU モデル トレーニング | TPU Ironwood（TPU7x） | TPU v6、TPU v5（v5e または v5p） | スライスベースのスケジューリングに柔軟なトポロジを利用します。 |
ノードプールの自動作成と ComputeClass を実装する
容量の可用性を最適化するには、ノードプールの自動作成と ComputeClasses を組み合わせます。次のリストにベスト プラクティスを示します。
ComputeClass を定義する: マシン ファミリー、GPU タイプ、プロビジョニング モデルの優先順位付きリストを指定する ComputeClass リソースを作成します。 GKE は、クラスで使用可能な最優先の構成を使用してノードをプロビジョニングしようとします。優先順位付きのフォールバック リストは、ワークロードに必要なリソースを取得するのに役立ちます。たとえば、優先する特殊なアクセラレータが使用できない場合に GKE が汎用マシンにフォールバックしないようにするには、ComputeClass 構成に
whenUnsatisfiable: DoNotScaleUp設定を追加します。詳細については、 カスタム ComputeClass で自動スケーリングされたノード属性を制御するをご覧ください。Pod 仕様で ComputeClass を参照する: ワークロード Pod 仕様で、特定のマシン ファミリーまたは GPU タイプではなく、カスタム ComputeClass をターゲットにするには、
cloud.google.com/compute-classラベルを使用します。詳細については、ワークロードで ComputeClass をリクエストするをご覧ください。[複数の toleration を定義する]: ComputeClass を使用しない場合は、Pod 仕様で、さまざまなマシン ファミリー（
cloud.google.com/machine-familyの["n2", "n2d"]など）を許可するノード アフィニティ ルールを使用します。詳細については、ノードプールの自動作成を構成するをご覧ください。
GKE の地理的柔軟性とマルチリージョン柔軟性
容量の可用性を高めるには、複数のゾーンにまたがる GKE クラスタをデプロイするか、マルチクラスタ アーキテクチャを実行します。
マルチゾーン クラスタ: リージョン内の使用可能なすべてのゾーンで自動スケーリングするようにノードプールが構成されていることを確認します。
マルチリージョン クラスタ フェデレーション: 大規模な非同期ジョブ（オフライン バッチ推論や分散トレーニングなど）の場合は、マルチクラスタ オーケストレーター（Kueue や Cluster Director など）をデプロイして、ワークロードをグローバルにキューに登録し、使用可能な容量を持つリージョンにディスパッチします。
Spot VM で実行される Pod: toleration を追加し、GKE に余剰容量をさまざまなゾーンに分散するように指示することで、Spot VM で中断可能なワークロードを実行します。
GKE の取得可能性に関するその他のベスト プラクティス
ハードウェアの多様化に加えて、次の GKE ベスト プラクティスを組み込んで、クラスタ スケーリングの成功を最適化します。
- Pod のオーバープロビジョニング（容量バッファ）を実装する: ノード容量を事前に予約する優先度の低い「一時停止」Pod をデプロイします。優先度の高い AI ワークロードが送信され、リージョンの容量が制約されている場合、Kubernetes は一時停止 Pod をすぐにプリエンプトし、新しいノードのプロビジョニングを待たずにコンテナを起動できます。詳細については、 容量バッファについてをご覧ください。
- キューに格納されたプロビジョニングで Flex Start を使用する: 大規模なバッチジョブと AI モデル トレーニング ジョブの場合は、Kueue と Dynamic Workload Scheduler と統合された、キューに格納されたプロビジョニングで Flex Start を使用します。 キューに格納されたプロビジョニングでの Flex Start は、すべてまたはなしのアトミック ノード割り当てを提供するため、クラスタの部分的なスケールアップの失敗を防ぐことができます。詳細については、キューに格納されたプロビジョニングで Flex Start を使用して大規模なワークロードを実行するをご覧ください。
- イメージ ストリーミングとコンテナ イメージのプリロードを有効にする: 大規模な AI コンテナ イメージ（10 GB を超える PyTorch イメージや TensorFlow イメージなど）の場合は、GKE イメージ ストリーミングを有効にするか、セカンダリ ブートディスクを使用してイメージをプリロードします。この構成により、ノードのウォームアップ時間が短縮され、新しくプロビジョニングされたノードでワークロードを数秒で実行できるようになります。 詳細については、イメージ ストリーミングを使用してコンテナ イメージを pull するおよびセカンダリ ブートディスクを使用してデータまたはコンテナ イメージをプリロードするをご覧ください。
- クラスタ オートスケーラーのロケーション ポリシーを
ANYに設定する:ANYロケーション ポリシーを使用してノードプール （特に Spot VM または Flex Start）を構成します。この設定は、クラスタ オートスケーラーに対し、指定されたすべてのゾーンでリクエストされた容量を検索するように指示します。クラスタ オートスケーラーは、ノード数のバランスを取るよりも容量を優先します。詳細については、 クラスタ オートスケーラーの概要をご覧ください。 - GPU 共有でアクセラレータの使用率を最適化する: 専用 GPU を必要としないワークロードの場合は、GPU タイム シェアリング、マルチインスタンス GPU（MIG）、NVIDIA MPS を使用して、複数のコンテナが単一のアクセラレータを共有できるようにします。このアプローチにより、ノードプール全体で有効な容量が最適化されます。 詳細については、GKE での GPU 共有戦略について をご覧ください。
Compute Advisor を使用する
Compute Advisor は、 Cloud de Confiance Gemini を搭載したコンソールの AI を活用したインターフェースで、GKE の復元性と費用対効果の高い アーキテクチャを設計するのに役立ちます。
Compute Advisor は、デプロイ前に組織のポリシーとリソース割り当てを確認しながら、Flex Start VM と Spot VM のほぼリアルタイムの可用性ガイダンスを提供します。Compute Advisor は、オンデマンド リソースを必要とするワークロードの可用性ガイダンスを提供しません。
コンソール Cloud de Confiance で Gemini にアクセスする手順は次のとおりです。
-
コンソール Cloud de Confiance で、[概要] ページに移動します。
-
[Compute Advisor でインフラストラクチャを設計する] セクションで、プロンプトを送信します。Gemini がレスポンスの生成を開始します。
-
アーキテクチャに関する推奨事項を生成するには、Compute Advisor で次の プロンプトのいずれかを実行します。 [**Compute Advisor でプロンプトを実行**] ボタンをクリックすると、 Cloud de Confiance コンソールの読み込みに 15 秒以上かかることがあります。
一般的なアクセラレータ戦略:
使用例:クラスタ構成を設計する際に、このプロンプトを使用してリージョンの容量シグナルを分析し、マシンタイプ、ゾーン、フォールバック スケジューリング戦略に関する推奨事項を受け取ります。
Configure a GKE cluster to improve chances of obtaining scarce GPU or TPU capacity.地理的な柔軟性とフォールバック:
使用例:マルチクラスタ アーキテクチャまたはグローバル ジョブキュー システム（Kueue など）を設計する際に、このプロンプトを使用して、リソースの可用性に応じてリージョン間でワークロードの実行をシフトします。
Configure multi-region fallbacks and geographic scheduling on GKE to increase GPU availability.優先予約の使用:
使用例:このプロンプトを使用して、予約容量を優先する Pod アフィニティ ルールと自動スケーリング ルールの YAML 構成パターンを生成します。
Configure GKE autoscaling rules and Pod specs to prioritize consuming active reservations before scaling into on-demand pools.フォールバックの優先順位付けのための ComputeClass:
使用例:このプロンプトを使用して、高性能 GPU を優先するが、ワークロードのスケジューリングを確実にするために下位層のフォールバックを含む ComputeClass CustomResourceDefinition の YAML マニフェストを生成します。
Define a ComputeClass manifest for GKE to prioritize A2 GPU nodes with automatic fallbacks to L4 or T4 GPUs.多様化のためのノードプールの自動作成:
使用例:このプロンプトを使用して、NAP が代替の GPU または CPU ノードを自動的にプロビジョニングできるようにする、GKE クラスタ オートスケーラーのリソース上限と Pod アフィニティ ルールの YAML マニフェストを作成します。
Configure GKE node pool auto-creation to diversify machine families and prevent pending pods when regional accelerator capacity is constrained.