このドキュメントでは、GPU、TPU、高性能 CPU などのリソースを取得するのに役立つ、復元力のある Google Kubernetes Engine（GKE）クラスタとワークロード スケジューリング戦略を設計する方法について説明します。Cloud de Confiance by S3NS の Gemini と Compute Advisor（プレビュー版）を活用することで、保留中の Pod を防止し、AI ワークロードの信頼性の高いスケジューリングを改善できます。
このドキュメントは、GKE インフラストラクチャを管理し、容量計画とスケジューリングを最適化したいと考えている Cloud Architect、プラットフォーム管理者、オペレーターを対象としています。
GKE でのコンピューティング容量の柔軟性、効率性、可用性の概要
Kubernetes のスケジューリングは、宣言されたリソース リクエストに依存します。GPU や TPU などの大規模なアクセラレータをスケジューリングする場合、厳格なリソース リクエストを行うと、特定のハードウェアが利用できない場合にクラスタのスケールアップが失敗する可能性があります。次の機能を使用すると、GKE で容量の可用性を最適化できます。
- ノードプールの自動作成: 動的なマルチファミリー ノードプールの作成。
- ワークロード レベルのフォールバック: 代替ハードウェアを受け入れるように構成された toleration とノードセレクタ。
- 地理的スケジューリングとリージョン スケジューリング: GKE のマルチゾーン機能とマルチリージョン機能。
- 予約管理: オンデマンド リソースをリクエストする前に、事前購入した容量を消費します。
GKE でのコンピューティング容量の柔軟性、効率性、可用性に関するベスト プラクティス
このセクションでは、GKE でワークロードをスケジュールする際に容量の可用性を高めるための推奨事項について説明します。これらのベスト プラクティスでは、柔軟なハードウェア要件の設計、ノードプールの自動作成の構成、地理的な分散を活用してリソースの制約に適応するなどの戦略について説明します。ノードプールの自動作成は、Pod の仕様に基づいてノードプールを自動的に管理します。ノードプールを事前に定義するのではなく、Pod マニフェストでリソース要件を指定し、GKE でノードを動的に作成します。
Compute Advisor（プレビュー版）を使用して、次のベスト プラクティスを検出して実装することもできます。詳細については、Compute Advisor を使用するをご覧ください。
コンピューティング容量の可用性を高めるオプション
容量の可用性を最適化するには、ワークロードを単一の静的マシン ファミリーまたはアクセラレータ タイプにバインドしないように GKE に指示します。以下に、さまざまなワークロード クラスに対してフレキシブル ノードプールと Pod アフィニティ ルールを構成する方法の例を示します。選択する具体的な代替手段は、アプリケーションのリソース需要によって異なります。
汎用 CPU ノードプール:
- 主な例: N4（Intel ベースの汎用）。
- 代替案の例: N4D（AMD EPYC 汎用）、C4 または C3（Intel 汎用）、C4D または C3D（AMD EPYC 汎用）。
- 実装パターン: 複数のマシン ファミリー ラベル（
["n4", "n4d", "c4", "c4d"]のcloud.google.com/machine-familyなど）にまたがるスケジューリングを許可するカスタム ComputeClass またはノード アフィニティ ルールを使用して Pod 仕様を構成します。この構成により、GKE は使用可能な容量があるプールをプロビジョニングできます。
GPU ノードプール:
- 主な例: A3 シリーズ（NVIDIA H100 GPU）または A4 シリーズ（NVIDIA B200 GPU）。
- 代替案の例: G2 シリーズ（NVIDIA L4 GPU）または代替アクセラレータ ティア。
- 実装パターン: 異なる GPU ティアに個別のノードプールまたは ComputeClass を構成します。アクセラレータの世代間で実行できる推論ワークロードまたはサービング ワークロードの場合、プライマリ アクセラレータのプロビジョニングが制限されている場合は、Pod が G2（L4）または代替 GPU プールにフォールバックできるようにします。
TPU ノードプール:
- 主な例: TPU Ironwood（TPU7x）。
- 代替の例: TPU v6（Trillium）または TPU v5（v5e または v5p）。
- 実装パターン: TPU スライスのプロビジョニングは、厳しく制限される場合があります。TPU Ironwood（TPU7x）の容量が利用できない場合に v6 または v5 スライスにデプロイできるように、フレームワーク レベルの柔軟性（可変スライス トポロジをサポートする JAX または PyTorch 構成など）を備えたトレーニング ワークロードを設計します。
次の表に、さまざまなタイプのワークロードの主な選択肢とハードウェアの代替案をまとめます。
| ワークロード タイプ | プライマリ選択の例 | サンプルの代替案 | アーキテクチャに関する注意事項 |
|---|---|---|---|
| システム ワークロードまたはコア ワークロード | N4 | N4D、C4、C4D、C3、C3D | ノードプールの自動作成に最新の Intel および AMD ハードウェア プールを使用します。 |
| GPU 推論と処理 | A3（H100）または A4（B200） | G2（L4） | 低コストまたは高可用性の GPU ノードプールを柔軟にターゲットに設定します。 |
| TPU モデルのトレーニング | TPU Ironwood（TPU7x） | TPU v6、TPU v5（v5e または v5p） | スライスベースのスケジューリングに柔軟なトポロジを利用します。 |
ノードプールの自動作成と ComputeClass を実装する
容量の可用性を最適化するには、ノードプールの自動作成と ComputeClasses を組み合わせます。次のリストに、ベスト プラクティスを示します。
ComputeClass を定義する: マシン ファミリー、GPU タイプ、プロビジョニング モデルの優先順位付きリストを指定する ComputeClass リソースを作成します。GKE は、クラスで使用可能な最優先構成を使用してノードをプロビジョニングしようとします。優先順位付けされたフォールバック リストは、ワークロードに必要なリソースを取得するのに役立ちます。たとえば、優先する専用アクセラレータが使用できない場合に GKE が汎用マシンにフォールバックしないようにするには、ComputeClass 構成に
whenUnsatisfiable: DoNotScaleUp設定を追加します。詳細については、カスタム ComputeClass を使用して、自動スケーリングされたノードの属性を制御するをご覧ください。ステートレス ワークロードまたは中断に耐性のあるワークロードに対してアクティブな移行（
optimizeRulePriority: true）を有効にする: ComputeClass でアクティブな移行を構成します。これにより、そのロケーションで容量が回復すると、GKE はフォールバック ノードを自動的に切断、ドレイン、優先度の高いマシンシリーズに置き換えます。世代間のフォールバックに動的 StorageClass を使用する: GKE バージョン 1.35.3-gke.1290000 以降では、ComputeClass が Hyperdisk のみのシリーズ（C4、C4D、N4 など）と Persistent Disk シリーズ（N2、N2D など）にまたがる場合、GKE が互換性のあるディスクタイプを動的に選択するようにステートフル ワークロードを構成します。これを行うには、ディスクタイプの自動選択（
parameters.type: dynamic）とvolumeBindingMode: WaitForFirstConsumer設定で StorageClass を使用します。Pod 仕様で ComputeClass を参照する: ワークロードの Pod 仕様で、
cloud.google.com/compute-classラベルを使用して、特定のマシン ファミリーや GPU タイプではなく、カスタム ComputeClass をターゲットにします。詳細については、ワークロードで ComputeClass をリクエストするをご覧ください。複数の toleration を定義する: ComputeClass を使用しない場合は、Pod 仕様でノード アフィニティ ルールを使用して、さまざまなマシン ファミリー（
["n4", "n4d", "c4", "c4d"]のcloud.google.com/machine-familyなど）を許可します。詳細については、ノードプールの自動作成を構成するをご覧ください。
GKE の地理的およびマルチリージョンの柔軟性
容量の可用性を高めるには、複数のゾーンにまたがる GKE クラスタをデプロイするか、マルチクラスタ アーキテクチャを実行します。
マルチゾーン クラスタ: リージョン内のすべての利用可能なゾーンにわたって自動スケーリングするようにノードプールが構成されていることを確認します。
マルチリージョン クラスタ フェデレーション: 大規模な非同期ジョブ（オフライン バッチ推論や分散トレーニングなど）の場合は、マルチクラスタ オーケストレーター（Kueue や Cluster Director など）をデプロイして、ワークロードをグローバルにキューに入れ、利用可能な容量を持つリージョンにディスパッチします。
Spot VM で実行される Pod: toleration を追加し、異なるゾーンに余剰容量を分散するように GKE に指示することで、Spot VM で中断可能なワークロードを実行します。
GKE でのコンピューティング容量の柔軟性、効率性、可用性を高めるためのその他のベスト プラクティス
ハードウェアの多様化に加えて、次の GKE のベスト プラクティスを組み込んで、クラスタのスケーリングを最適化します。
- 容量バッファを使用する: 予備のノード容量を事前に予約して、優先度の高い AI ワークロードが新しいノードのプロビジョニングを待たずにすぐにスケジュールできるようにします。GPU ワークロードと TPU ワークロードにアクティブ バッファ戦略で宣言型の容量バッファを使用すると、クラスタ オートスケーラーが予備容量を自動的に維持します。
- キューに格納されたプロビジョニングで 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 は、Gemini を活用したCloud de Confiance コンソールの 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 A3 GPU nodes with automatic fallbacks to G2 (L4) 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.