このドキュメントでは、GPU、TPU、高性能 CPU などのリソースを取得するのに役立つ、復元力のある Google Kubernetes Engine（GKE）クラスタとワークロード スケジューリング戦略を設計する方法について説明します。Google Cloud と Compute Advisor（プレビュー版）で Gemini を活用すると、保留中の 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など）でスケジューリングを許可するノード アフィニティまたは容認で 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 仕様で、さまざまなマシン ファミリー（
["n2", "n2d"]のcloud.google.com/machine-familyなど）を許可するノード アフィニティ ルールを使用します。詳細については、ノードプールの自動作成を構成するをご覧ください。
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 を使用して、複数のコンテナが 1 つのアクセラレータを共有できるようにします。このアプローチでは、ノードプール全体で有効容量が最適化されます。詳細については、GKE での GPU 共有戦略についてをご覧ください。
Compute Advisor を使用する
Compute Advisor は、Google Cloud コンソールの Gemini を活用した AI インターフェースで、GKE の復元力のあるアーキテクチャの設計に役立ちます。Compute Advisor は、デプロイ前に組織のポリシーとリソース割り当てを確認しながら、ほぼリアルタイムで Flex Start VM と Spot VM の可用性に関するガイダンスを提供します。Compute Advisor は、オンデマンド リソースを必要とするワークロードの可用性に関するガイダンスを提供しません。
Google Cloud コンソールで Gemini にアクセスする手順は次のとおりです。
Google Cloud コンソールで、[概要] ページに移動します。
[Compute Advisor でインフラストラクチャを設計する] セクションで、プロンプトを送信します。Gemini が回答の生成を開始します。
アーキテクチャの推奨事項を生成するには、Compute Advisor で次のいずれかのプロンプト例を実行します。[Run prompt in Compute Advisor] ボタンをクリックすると、 Google Cloud コンソールの読み込みに 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.