Cluster Toolkit を使用して AI 最適化 GKE クラスタを作成する

このドキュメントでは、A4X、A4、A3 Ultra、A3 Mega、A3 High（8 GPU）Compute Engine インスタンスを使用して AI と ML ワークロードをサポートする、AI に最適化された Google Kubernetes Engine（GKE）クラスタを作成する方法について説明します。

A4X、A4、A3 Ultra、A3 Mega、A3 High（8 GPU）マシンシリーズは、ターゲットを絞ったワークロード配置、高度なクラスタ メンテナンス制御、トポロジーを考慮したスケジューリングなどの機能を備えた大規模な AI / ML クラスタを実行できるように設計されています。詳細については、クラスタ管理の概要をご覧ください。

GKE は、組織のニーズに合わせてさまざまなワークロードを実行するための単一のプラットフォーム サーフェスを提供します。これらのワークロードには、高パフォーマンスの分散事前トレーニング、モデルのファインチューニング、モデル推論、アプリケーション サービング、サポート サービスが含まれます。GKE を使用すると、複数のプラットフォームを管理する運用上の負担を軽減できます。

AI 向けに最適化された GKE クラスタの作成方法を選択する

クラスタ作成の次の各オプションでは、クラスタ構成とワークロード スケジューリングの容易さと柔軟性が異なります。

始める前に

作業を始める前に、次のタスクが完了していることを確認してください。

  • Google Kubernetes Engine API を有効にする。
    • Google Kubernetes Engine API を有効化
  • このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化します。gcloud CLI をインストール済みの場合は、gcloud components update コマンドを実行して最新のバージョンを取得します。以前のバージョンの gcloud CLI では、このドキュメントのコマンドを実行できない場合があります。
  • GKE クラスタと関連するサービス アカウントの作成と管理に必要な権限があることを確認します。
    • Kubernetes Engine 管理者（roles/container.admin）
    • Compute 管理者（roles/compute.admin）
    • ストレージ管理者（roles/storage.admin）
    • プロジェクト IAM 管理者（roles/resourcemanager.projectIamAdmin）
    • サービス アカウント管理者（roles/iam.serviceAccountAdmin）
    • サービス アカウント ユーザー（roles/iam.serviceAccountUser）
    • Service Usage コンシューマー（roles/serviceusage.serviceUsageConsumer）
    • ロール管理者（roles/iam.roleAdmin）
    • Secret Manager のシークレット バージョン マネージャー（roles/secretmanager.secretVersionManager）
    • 単一プロジェクトの予約を使用する場合: プロジェクトに対する Compute インスタンス管理者（v1）（roles/compute.instanceAdmin.v1）
    • 共有予約を使用するには: オーナー プロジェクトと、予約を使用するコンシューマ プロジェクトの両方に対する Compute インスタンス管理者（v1）（roles/compute.instanceAdmin.v1）

使用オプションを選択して容量を取得する

容量を取得する手順は次のとおりです。

  1. 使用オプションを選択する: GPU リソースの取得方法と使用方法に基づいて選択します。詳細については、使用オプションを選択するをご覧ください。

    GKE の場合は、使用オプションを選択する際に次の追加情報を考慮してください。

  2. 容量を取得する: 容量を取得するプロセスは、使用オプションごとに異なります。選択した使用オプションのプロセスについては、容量の概要をご覧ください。

要件

AI 向けに最適化された GKE クラスタには、次の要件が適用されます。

  • A4X Max の場合は、次のいずれかのバージョンを使用する必要があります。

    • 1.35 以降の場合は、GKE バージョン 1.35.0-gke.2745000 以降を使用します。
    • 1.34 の場合は、GKE バージョン 1.34.3-gke.1318000 以降を使用します。

    これらのバージョンにより、A4X Max で次のものが使用されるようになります。

    • R580.95.05。A4X Max の最小 GPU ドライバ バージョン。デフォルトで有効になっています。
    • コヒーレント ドライバベースのメモリ管理（CDMM）。デフォルトで有効になっています。NVIDIA は、Kubernetes クラスタでこのモードを有効にして、メモリの過剰報告を解決することをおすすめしています。CDMM を使用すると、オペレーティング システム（OS）ではなくドライバを介して GPU メモリを管理できます。このアプローチにより、GPU メモリの OS オンライン化を回避し、GPU メモリを不均一メモリアクセス（NUMA）ノードとして OS に公開できます。CDMM が有効になっている場合、マルチインスタンス GPU はサポートされません。CDMM の詳細については、ハードウェアとソフトウェアのサポートをご覧ください。
    • GPUDirect RDMA と MNNVL。これらは、A4X Max ノードプールで A4X Max のネットワーキング機能を使用できるようにするために推奨されます。

  • A4X の場合は、次のいずれかのバージョンを使用する必要があります。

    • 1.33 以降の場合は、GKE バージョン 1.33.4-gke.1036000 以降を使用します。
    • 1.32 の場合は、GKE バージョン 1.32.8-gke.1108000 以降を使用します。

    これらのバージョンは、A4X で以下が使用されるようにするのに役立ちます。

    • R580。A4X の最小 GPU ドライバ バージョン。デフォルトで有効になっています。
    • コヒーレント ドライバベースのメモリ管理（CDMM）。デフォルトで有効になっています。NVIDIA は、Kubernetes クラスタでこのモードを有効にして、メモリの過剰報告を解決することをおすすめしています。CDMM を使用すると、オペレーティング システム（OS）ではなくドライバを介して GPU メモリを管理できます。このアプローチにより、GPU メモリの OS オンライン化を回避し、GPU メモリを不均一メモリアクセス（NUMA）ノードとして OS に公開できます。CDMM が有効になっている場合、マルチインスタンス GPU はサポートされません。CDMM の詳細については、ハードウェアとソフトウェアのサポートをご覧ください。
    • GPUDirect RDMA と MNNVL。これらは、A4X ノードプールで A4X のネットワーキング機能を使用できるようにするために推奨されます。

  • マシンタイプに応じて、最小の GPU ドライバ バージョンを使用してください。

    • A4X Max: A4X Max ベアメタル インスタンスの GB300 GPU には、R580.95.05 以降の GPU ドライバ バージョンが必要です。前述のバージョンの要件をご覧ください。
    • A4X: A4X インスタンスの GB200 GPU には、R580 GPU ドライバ バージョン以上が必要です。前述のバージョン要件をご覧ください。
    • A4: A4 インスタンスの B200 GPU には、R570 GPU ドライバ バージョン以上が必要です。GKE は、デフォルトで、A4 に必要な最小バージョン（1.32.1-gke.1729000 以降）を実行しているすべての A4 ノードに、このドライバ バージョンを自動的にインストールします。
    • A3 Ultra: A3 Ultra インスタンスの H200 GPU には、R550 GPU ドライバ バージョン以降が必要です。これは、GKE 1.31 で latest ドライバ バージョンとして利用できます。A3 Ultra の場合は、GKE 1.31 で gpu-driver-version=latest を設定する必要があります。GKE バージョン 1.31.5-gke.1169000 以降の場合、GKE はデフォルトで A3 Ultra ノードに R550 GPU ドライバ バージョンを自動的にインストールします。
    • A3 Mega と A3 High: A3 High インスタンスと A3 Mega インスタンスの H100 GPU は、サポートされているすべての GKE バージョンのデフォルトの GPU ドライバ バージョンでサポートされています。gpu-driver-version=latest を設定して、サポートされている GKE バージョンで利用可能な新しい本番環境ドライバにアクセスすることもできます。

  • A3 Ultra ノードプールの場合、ディスクタイプを hyperdisk-balanced に設定する必要があります。

  • GPUDirect RDMA を使用するには、マシンタイプに応じて次の最小バージョンを使用します。

    • A4X Max: 前述のバージョンの要件をご覧ください。
    • A4X: 前述のバージョン要件をご覧ください。
    • A4: 1.32.2-gke.1475000 以降を使用します。
    • A3 Ultra: 1.31.4-gke.1183000 以降を使用します。

  • GPUDirect-TCPXO（A3 Mega の場合）と GPUDirect-TCPX（A3 High の場合）を使用するには、次の GKE バージョンを使用します。

    • A3 High: 1.34 より前の利用可能な GKE バージョンを使用します。
    • A3 Mega: 利用可能な GKE バージョンを使用します。

  • GPUDirect RDMA を使用するには、GKE ノードで Container-Optimized OS ノードイメージを使用する必要があります。Ubuntu と Windows のノードイメージはサポートされません。

  • A4X Max と A4X を使用してクラスタを作成するには、予約にバインドされたプロビジョニング モデルを使用する必要があります。他のプロビジョニング モデルはサポートされていません。

Cluster Toolkit を使用してクラスタを作成する

Cluster Toolkit を使用してクラスタを作成する手順は次のとおりです。このセクションでは、クラスタの作成プロセスについて説明します。プロジェクトがベスト プラクティスに沿って、AI に最適化された GKE クラスタの要件を満たしていることを確認します。このセクションでは、Terraform を使用してデプロイのインフラストラクチャをプロビジョニングして管理する方法についても説明します。

A4X Max

  1. Cloud Shell を起動します。別の環境を使用することもできますが、依存関係が Cluster Toolkit にすでにプリインストールされているため、Cloud Shell をおすすめします。Cloud Shell を使用しない場合は、依存関係をインストールする手順に沿って別の環境を準備します。

  2. Cluster Toolkit をインストールする。

  3. Terraform デプロイの状態を保存するために、バージョニングを有効にした Cloud Storage バケットを作成します。

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    次の変数を置き換えます。

    • BUCKET_NAME: 新しい Cloud Storage バケットの名前。バケットの命名要件を満たす必要があります。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • COMPUTE_REGION_TERRAFORM_STATE: Terraform デプロイの状態を保存するコンピューティング リージョン。

  4. GitHub リポジトリの examples/gke-a4x-max-bm/gke-a4x-max-bm-deployment.yaml ブループリントで、terraform_backend_defaults セクションと vars セクションに次の設定を入力して、デプロイの特定の値と一致させます。

    • BUCKET: 前の手順で作成した Cloud Storage バケットの名前。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • DEPLOYMENT_NAME: デプロイの一意の名前。長さは 6～30 文字にする必要があります。デプロイ名がプロジェクト内で一意でない場合、クラスタの作成は失敗します。デフォルト値は gke-a4x-max-bm です。
    • REGION: クラスタのコンピューティング リージョン。
    • ZONE: A4X Max マシンのノードプールのコンピューティング ゾーン。このゾーンは、予約に対して使用可能なマシンがあるゾーンと一致する必要があります。
    • STATIC_NODE_COUNT: クラスタのノードプール内の A4X Max ノードの数。18 ノード以下にする必要があります。NVLink ドメインを使用して 1 つのサブブロックで 1x72 の GPU トポロジを取得するには、18 個のノードを使用することをおすすめします。
    • AUTHORIZED_CIDR: クラスタへの接続を許可する IP アドレス範囲。この CIDR ブロックには、Terraform を呼び出すマシンの IP アドレスを含める必要があります。詳細については、承認済みネットワークの仕組みをご覧ください。

    • reservation フィールドには、ノードプールのプロビジョニング時に、予約の特定のブロックをターゲットにするかどうかに応じて、次のいずれかを使用します。

    • ノードプールを予約の任意の場所に配置するには、予約の名前（RESERVATION_NAME）を指定します。

    • 予約の特定のブロックをターゲットにするには、予約名とブロック名を次の形式で使用します。

      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      予約で使用可能なブロックが不明な場合は、予約のトポロジを表示するをご覧ください。

    • RESERVATION_PROJECT_ID: 予約がある Google Cloudプロジェクト ID。予約が PROJECT_ID とは異なるプロジェクトに存在する可能性があります。

    • NUM_NODE_POOLS: クラスタで有効にするノードプールの数。18 ノードを超えるクラスタが必要な場合は、複数のノードプールを指定できます。デフォルト値は 1 です。

    詳細設定を変更するには、examples/gke-a4x-max-bm/gke-a4x-max-bm.yaml ファイルを編集します。

  5. 省略可: 高パフォーマンスの共有ストレージ用に Google Cloud Managed Lustre を構成します。A4X Max GKE ブループリントでは、Managed Lustre CSI ドライバがデフォルトで有効になっています。クラスタで Managed Lustre インスタンスと永続ボリュームをプロビジョニングするには、次の操作を行います。

    1. examples/gke-a4x-max-bm/gke-a4x-max-bm.yaml ファイルを開きます。
    2. vars セクションで、lustre_instance_id、lustre_size_gib、per_unit_storage_throughput 変数のコメント化を解除します。
    3. # --- MANAGED LUSTRE ADDITIONS --- セクションで、private_service_access、lustre_firewall_rule、managed-lustre、lustre-pv の各モジュールのコメント化を解除します。

  6. アプリケーションのデフォルト認証情報（ADC）を生成して、Terraform にアクセスできるようにします。Cloud Shell を使用している場合は、gcloud auth application-default login コマンドを使用します。

    gcloud auth application-default login

  7. gcluster deploy コマンドを使用してブループリントをデプロイし、A4X Max マシンタイプを使用して GKE インフラストラクチャをプロビジョニングします。

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a4x-max-bm/gke-a4x-max-bm-deployment.yaml \
    examples/gke-a4x-max-bm/gke-a4x-max-bm.yaml

  8. プロンプトが表示されたら、[(A)pply] を選択してブループリントをデプロイします。

    • このブループリントは、VPC ネットワーク、GPU RDMA VPC ネットワーク、サービス アカウント、クラスタ、ノードプールを作成します。
    • ブループリントで fio-bench-job-template ジョブ テンプレートをサポートするために、Google Cloud バケット、ネットワーク ストレージ、永続ボリューム リソースが作成されます。

A4X

  1. Cloud Shell を起動します。別の環境を使用することもできますが、依存関係が Cluster Toolkit にすでにプリインストールされているため、Cloud Shell をおすすめします。Cloud Shell を使用しない場合は、依存関係をインストールする手順に沿って別の環境を準備します。

  2. Cluster Toolkit をインストールする。

  3. Terraform デプロイの状態を保存するために、バージョニングを有効にした Cloud Storage バケットを作成します。

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    次の変数を置き換えます。

    • BUCKET_NAME: 新しい Cloud Storage バケットの名前。バケットの命名要件を満たす必要があります。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • COMPUTE_REGION_TERRAFORM_STATE: Terraform デプロイの状態を保存するコンピューティング リージョン。

  4. GitHub リポジトリの examples/gke-a4x/gke-a4x-deployment.yaml ブループリントで、terraform_backend_defaults セクションと vars セクションに次の設定を入力して、デプロイの特定の値と一致させます。

    • BUCKET: 前の手順で作成した Cloud Storage バケットの名前。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • DEPLOYMENT_NAME: デプロイの一意の名前。長さは 6～30 文字にする必要があります。デプロイ名がプロジェクト内で一意でない場合、クラスタの作成は失敗します。デフォルト値は gke-a4x です。
    • REGION: クラスタのコンピューティング リージョン。
    • ZONE: A4X マシンのノードプールのコンピューティング ゾーン。このゾーンは、予約に対して使用可能なマシンがあるゾーンと一致する必要があります。
    • STATIC_NODE_COUNT: クラスタのノードプール内の A4X ノードの数。18 ノード以下にする必要があります。NVLink ドメインを使用して 1 つのサブブロックで 1x72 の GPU トポロジを取得するには、18 個のノードを使用することをおすすめします。
    • AUTHORIZED_CIDR: クラスタへの接続を許可する IP アドレス範囲。この CIDR ブロックには、Terraform を呼び出すマシンの IP アドレスを含める必要があります。詳細については、承認済みネットワークの仕組みをご覧ください。

    • reservation フィールドには、ノードプールのプロビジョニング時に、予約の特定のブロックをターゲットにするかどうかに応じて、次のいずれかを使用します。

    • ノードプールを予約の任意の場所に配置するには、予約の名前（RESERVATION_NAME）を指定します。

    • 予約の特定のブロックをターゲットにするには、予約名とブロック名を次の形式で使用します。

      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      予約で使用可能なブロックが不明な場合は、予約のトポロジを表示するをご覧ください。

    • RESERVATION_PROJECT_ID: 予約がある Google Cloudプロジェクト ID。予約が PROJECT_ID とは異なるプロジェクトに存在する可能性があります。

    • NUM_NODE_POOLS: クラスタで有効にするノードプールの数。18 ノードを超えるクラスタが必要な場合は、複数のノードプールを指定できます。デフォルト値は 1 です。

    詳細設定を変更するには、examples/gke-a4x/gke-a4x.yaml ファイルを編集します。

  5. 省略可: 高性能な共有ストレージ用に Managed Lustre を構成します。A4X GKE ブループリントでは、Managed Lustre CSI ドライバがデフォルトで有効になっています。クラスタで Managed Lustre インスタンスと永続ボリュームをプロビジョニングするには、次の操作を行います。

    1. examples/gke-a4x/gke-a4x.yaml ファイルを開きます。
    2. vars セクションで、lustre_instance_id、lustre_size_gib、per_unit_storage_throughput 変数のコメント化を解除します。
    3. # --- MANAGED LUSTRE ADDITIONS --- セクションで、private_service_access、lustre_firewall_rule、managed-lustre、lustre-pv の各モジュールのコメント化を解除します。

  6. アプリケーションのデフォルト認証情報（ADC）を生成して、Terraform にアクセスできるようにします。Cloud Shell を使用している場合は、gcloud auth application-default login コマンドを使用します。

    gcloud auth application-default login

  7. gcluster deploy コマンドを使用してブループリントをデプロイし、A4X マシンタイプを使用して GKE インフラストラクチャをプロビジョニングします。

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a4x/gke-a4x-deployment.yaml \
    examples/gke-a4x/gke-a4x.yaml

  8. プロンプトが表示されたら、[(A)pply] を選択してブループリントをデプロイします。

    • このブループリントは、VPC ネットワーク、GPU RDMA VPC ネットワーク、サービス アカウント、クラスタ、ノードプールを作成します。
    • ブループリントで fio-bench-job-template ジョブ テンプレートをサポートするために、Google Cloud バケット、ネットワーク ストレージ、永続ボリューム リソースが作成されます。

A4

  1. Cloud Shell を起動します。別の環境を使用することもできますが、依存関係が Cluster Toolkit にすでにプリインストールされているため、Cloud Shell を使用することをおすすめします。Cloud Shell を使用しない場合は、依存関係をインストールする手順に沿って別の環境を準備します。

  2. Cluster Toolkit をインストールする。

  3. Terraform デプロイの状態を保存するために、バージョニングを有効にした Cloud Storage バケットを作成します。

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    次の変数を置き換えます。

    • BUCKET_NAME: 新しい Cloud Storage バケットの名前。バケットの命名要件を満たす必要があります。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • COMPUTE_REGION_TERRAFORM_STATE: Terraform デプロイの状態を保存するコンピューティング リージョン。

  4. GKE デプロイの使用オプションを選択します。

    デフォルトでは、デプロイ ファイルは特定の予約を使用するように構成されています。別の使用量モデル（Spot VM や Flex Start プロビジョニング モードなど）を使用するには、デプロイ YAML ファイルを更新します。詳細については、GKE の使用オプションをご覧ください。

  5. GitHub リポジトリの examples/gke-a4/gke-a4-deployment.yaml ブループリントで、terraform_backend_defaults セクションと vars セクションに次の設定を入力して、デプロイの特定の値と一致させます。

    • BUCKET: 前の手順で作成した Cloud Storage バケットの名前。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • DEPLOYMENT_NAME: デプロイの一意の名前。長さは 6～30 文字にする必要があります。デプロイ名がプロジェクト内で一意でない場合、クラスタの作成は失敗します。デフォルト値は gke-a4 です。
    • REGION: クラスタのコンピューティング リージョン。
    • ZONE: A4 マシンのノードプールのコンピューティング ゾーン。このゾーンは、予約に対して使用可能なマシンがあるゾーンと一致する必要があります。
    • AUTHORIZED_CIDR: クラスタへの接続を許可する IP アドレス範囲。この CIDR ブロックには、Terraform を呼び出すマシンの IP アドレスを含める必要があります。詳細については、承認済みネットワークの仕組みをご覧ください。
    • 特定の予約セクションで、次の設定を構成します。

    • reservation_affinity ブロックの specific_reservations リストで、予約の name フィールドを指定します。

      • ノードプールを予約の任意の場所に配置するには、予約の名前（RESERVATION_NAME）を指定します。
      • 予約の特定のブロックをターゲットにするには、予約名とブロック名を次の形式で使用します。
      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      予約で使用可能なブロックが不明な場合は、予約トポロジを表示するをご覧ください。

      詳細設定を変更するには、examples/gke-a4/gke-a4.yaml を編集します。

    Flex Start

    1. GitHub リポジトリの examples/gke-a4/gke-a4-deployment.yaml ブループリントで、terraform_backend_defaults セクションと vars セクションに次の設定を入力して、デプロイの特定の値と一致させます。

      • BUCKET: 前の手順で作成した Cloud Storage バケットの名前。
      • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
      • DEPLOYMENT_NAME: デプロイの一意の名前。長さは 6 ～ 30 文字にする必要があります。デプロイ名がプロジェクト内で一意でない場合、クラスタの作成は失敗します。デフォルト値は gke-a4 です。
      • REGION: クラスタのコンピューティング リージョン。
      • ZONE: A4 マシンのノードプールのコンピューティング ゾーン。
      • AUTHORIZED_CIDR: クラスタへの接続を許可する IP アドレス範囲。この CIDR ブロックには、Terraform の呼び出しに使用するマシンの IP アドレスを含める必要があります。詳細については、承認済みネットワークの仕組みをご覧ください。
      • reservation フィールドを削除し、フィールドを enable_flex_start: true に置き換えます。キューに格納されたプロビジョニングも使用する場合は、次の行に enable_queued_provisioning: true を追加します。詳細については、キューに格納されたプロビジョニングでの Flex Start を使用するノードプールをご覧ください。
      • static_node_count を削除します。

    2. GitHub リポジトリの examples/gke-a4/gke-a4.yaml ブループリントで、次の変更を行います。

      • vars ブロックから static_node_count を削除します。
      • vars ブロックで、version_prefix 番号が "1.32." 以上であることを確認します。GKE で Flex Start を使用するには、クラスタでバージョン 1.32.2-gke.1652000 以降を使用する必要があります。
      • vars ブロックで、reservation ブロック全体（reservation 行自体を含む）を enable_flex_start: true に置き換えます。必要に応じて enable_queued_provisioning: true に置き換えます。
      • vars ブロックで、キューに格納されたプロビジョニングが不要な場合は、kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")) 行を削除します。
      • id: a4-pool で、static_node_count: $(vars.static_node_count) の行を削除します。

      • id: a4-pool で、reservation_affinity ブロックを削除します。このブロックを次の行に置き換えます。

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • キューに格納されたプロビジョニングを有効にする場合は、次の行を追加します。
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0

      • id: workload-manager-install で、次のブロックを削除します。

         kueue:
    install: true
    config_path: $(vars.kueue_configuration_path)
    config_template_vars:
       num_gpus: $(a3-ultragpu-pool.static_gpu_count)
       accelerator_type: $(vars.accelerator_type)

        • キューに格納されたプロビジョニングでの Flex Start の場合は、次の操作を行います。

          1. gpu_nominal_quota: NOMINAL_QUOTA を vars ブロックに追加します。gpu_nominal_quota 値は、ClusterQueue 仕様で GPU の nominalQuota を設定するために使用されます（以下では、ClusterQueue を設定するステップをご覧ください）。この例では、GPU リクエストの合計が NOMINAL_QUOTA 値以下の場合にのみ、ClusterQueue はワークロードを許可します。ClusterQueue の詳細については、クラスタキューの Kueue ドキュメントをご覧ください。

          2. kueue ブロックを次のように更新します。

            kueue:
   install: true
   config_path: $(vars.kueue_configuration_path)
   config_template_vars:
      num_gpus: $(vars.gpu_nominal_quota)

          3. kueue-configuration.yaml.tftpl ファイルの内容を次のように置き換えます。

            apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
   name: "default-flavor"
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: AdmissionCheck
metadata:
   name: dws-prov
spec:
   controllerName: kueue.x-k8s.io/provisioning-request
   parameters:
      apiGroup: kueue.x-k8s.io
      kind: ProvisioningRequestConfig
      name: dws-config
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ProvisioningRequestConfig
metadata:
   name: dws-config
spec:
   provisioningClassName: queued-provisioning.gke.io
   managedResources:
   - nvidia.com/gpu
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
   name: "dws-cluster-queue"
spec:
   namespaceSelector: {}
   resourceGroups:
   - coveredResources: ["nvidia.com/gpu"]
      flavors:
      - name: "default-flavor"
      resources:
      - name: "nvidia.com/gpu"
         nominalQuota: ${num_gpus}
   admissionChecks:
   - dws-prov
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
   namespace: "default"
   name: "dws-local-queue"
spec:
   clusterQueue: "dws-cluster-queue"
---

      • id: job-template で、node_count 変数を 2 に置き換えます。

    スポット

    1. GitHub リポジトリの examples/gke-a4/gke-a4-deployment.yaml ブループリントで、terraform_backend_defaults セクションと vars セクションに次の設定を入力して、デプロイの特定の値と一致させます。

      • BUCKET: 前の手順で作成した Cloud Storage バケットの名前。
      • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
      • DEPLOYMENT_NAME: デプロイの一意の名前。長さは 6 ～ 30 文字にする必要があります。デプロイ名がプロジェクト内で一意でない場合、クラスタの作成は失敗します。デフォルト値は gke-a4 です。
      • REGION: クラスタのコンピューティング リージョン。
      • ZONE: A4 マシンのノードプールのコンピューティング ゾーン。
      • STATIC_NODE_COUNT: クラスタ内の A4 ノードの数。
      • AUTHORIZED_CIDR: クラスタへの接続を許可する IP アドレス範囲。この CIDR ブロックには、Terraform の呼び出しに使用するマシンの IP アドレスを含める必要があります。詳細については、承認済みネットワークの仕組みをご覧ください。
      • reservation ブロック全体（reservation 行自体を含む）を spot: true に置き換えます。

    2. GitHub リポジトリの examples/gke-a4/gke-a4.yaml ブループリントで、次の変更を行います。

      • vars ブロックで、reservation ブロック全体（reservation 行自体を含む）を spot: true に置き換えます。

      • id: a4-pool で、reservation_affinity ブロックを削除します。このブロックを次の行に置き換えます。

        • spot: $(vars.spot)

  6. 省略可: 高性能な共有ストレージ用に Managed Lustre を構成します。A4 GKE ブループリントでは、Managed Lustre CSI ドライバがデフォルトで有効になっています。クラスタで Managed Lustre インスタンスと永続ボリュームをプロビジョニングするには、次の操作を行います。

    1. examples/gke-a4/gke-a4.yaml ファイルを開きます。
    2. vars セクションで、lustre_instance_id、lustre_size_gib、per_unit_storage_throughput 変数のコメント化を解除します。
    3. # --- MANAGED LUSTRE ADDITIONS --- セクションで、private_service_access、lustre_firewall_rule、managed-lustre、lustre-pv の各モジュールのコメント化を解除します。

  7. アプリケーションのデフォルト認証情報（ADC）を生成して、Terraform にアクセスできるようにします。Cloud Shell を使用している場合は、gcloud auth application-default login コマンドを使用します。

    gcloud auth application-default login

  8. gcluster deploy コマンドを使用してブループリントをデプロイし、A4 マシンタイプを使用して GKE インフラストラクチャをプロビジョニングします。

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a4/gke-a4-deployment.yaml \
    examples/gke-a4/gke-a4.yaml

  9. プロンプトが表示されたら、[(A)pply] を選択してブループリントをデプロイします。

    • このブループリントは、VPC ネットワーク、GPU RDMA VPC ネットワーク、サービス アカウント、クラスタ、ノードプールを作成します。
    • ブループリントで fio-bench-job-template ジョブ テンプレートをサポートするために、Google Cloud バケット、ネットワーク ストレージ、永続ボリューム リソースが作成されます。

A3 Ultra

  1. Cloud Shell を起動します。別の環境を使用することもできますが、依存関係が Cluster Toolkit にすでにプリインストールされているため、Cloud Shell を使用することをおすすめします。Cloud Shell を使用しない場合は、依存関係をインストールする手順に沿って別の環境を準備します。

  2. Cluster Toolkit をインストールする。

  3. Terraform デプロイの状態を保存するために、バージョニングを有効にした Cloud Storage バケットを作成します。

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    次の変数を置き換えます。

    • BUCKET_NAME: 新しい Cloud Storage バケットの名前。バケットの命名要件を満たす必要があります。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • COMPUTE_REGION_TERRAFORM_STATE: Terraform デプロイの状態を保存するコンピューティング リージョン。

  4. GKE デプロイの使用オプションを選択します。

    デフォルトでは、デプロイ ファイルは特定の予約を使用するように構成されています。別の使用量モデル（Spot VM や Flex Start プロビジョニング モードなど）を使用するには、デプロイ YAML ファイルを更新します。詳細については、GKE の使用オプションをご覧ください。

  5. GitHub リポジトリの examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml ブループリントで、terraform_backend_defaults セクションと vars セクションに次の設定を入力して、デプロイの特定の値と一致させます。

    • BUCKET: 前の手順で作成した Cloud Storage バケットの名前。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • DEPLOYMENT_NAME: デプロイの一意の名前。長さは 6～30 文字にする必要があります。デプロイ名がプロジェクト内で一意でない場合、クラスタの作成は失敗します。デフォルト値は gke-a3-ultragpu です。
    • REGION: クラスタのコンピューティング リージョン。
    • ZONE: A3 Ultra マシンのノードプールのコンピューティング ゾーン。このゾーンは、予約に対して使用可能なマシンがあるゾーンと一致する必要があります。
    • AUTHORIZED_CIDR: クラスタへの接続を許可する IP アドレス範囲。この CIDR ブロックには、Terraform を呼び出すマシンの IP アドレスを含める必要があります。詳細については、承認済みネットワークの仕組みをご覧ください。
    • 特定の予約セクションで、次の設定を構成します。

    • reservation_affinity ブロックの specific_reservations リストで、予約の name フィールドを指定します。

      • ノードプールを予約の任意の場所に配置するには、予約の名前（RESERVATION_NAME）を指定します。
      • 予約の特定のブロックをターゲットにするには、予約名とブロック名を次の形式で使用します。
      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      予約で使用可能なブロックが不明な場合は、予約のトポロジを表示するをご覧ください。

    • STATIC_NODE_COUNT: クラスタ内の A3 Ultra ノードの数。

      詳細設定を変更するには、examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml を編集します。

    Flex Start

    1. GitHub リポジトリの examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml ブループリントで、terraform_backend_defaults セクションと vars セクションの次の変数を、デプロイの特定の値と一致するように置き換えます。

      • BUCKET_NAME: 前の手順で作成した Cloud Storage バケットの名前。
      • DEPLOYMENT_NAME: デプロイの一意の名前。長さは 6 ～ 30 文字にする必要があります。デプロイ名がプロジェクト内で一意でない場合、クラスタの作成は失敗します。
      • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
      • COMPUTE_REGION: クラスタのコンピューティング リージョン。
      • COMPUTE_ZONE: A3 Ultra マシンのノードプールのコンピューティング ゾーン。
      • IP_ADDRESS/SUFFIX: クラスタへの接続を許可する IP アドレス範囲。この CIDR ブロックには、Terraform の呼び出しに使用するマシンの IP アドレスを含める必要があります。詳細については、承認済みネットワークの仕組みをご覧ください。
      • reservation フィールドを削除し、フィールドを enable_flex_start: true に置き換えます。キューに格納されたプロビジョニングも使用する場合は、次の行に enable_queued_provisioning: true を追加します。詳細については、キューに格納されたプロビジョニングでの Flex Start を使用するノードプールをご覧ください。
      • static_node_count を削除します。

    2. GitHub リポジトリの examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml ブループリントで、次の変更を行います。

      • vars ブロックから static_node_count を削除します。
      • vars ブロックで、version_prefix 番号を "1.32." 以降に更新します。GKE で Flex Start を使用するには、クラスタでバージョン 1.32.2-gke.1652000 以降を使用する必要があります。
      • vars ブロックで、reservation ブロック全体（reservation 行自体を含む）を enable_flex_start: true に置き換えます。必要に応じて enable_queued_provisioning: true に置き換えます。
      • vars ブロックで、kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")) の行を削除します。
      • id: a3-ultragpu-pool で、static_node_count: $(vars.static_node_count) の行を削除します。

      • id: a3-ultragpu-pool で、reservation_affinity ブロックを削除します。このブロックを次の行に置き換えます。

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • キューに格納されたプロビジョニングを有効にする場合は、次の行を追加します。
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0

      • id: workload-manager-install で、次のブロックを削除します。

        config_path: $(vars.kueue_configuration_path)
config_template_vars:
  num_gpus: $(a4-pool.static_gpu_count)
  accelerator_type: $(vars.accelerator_type)

        • キューに格納されたプロビジョニングの Flex Start の場合は、次の 3 つの手順を行います。

          1. gpu_nominal_quota: NOMINAL_QUOTA を vars ブロックに追加します。gpu_nominal_quota 値は、ClusterQueue 仕様で GPU の nominalQuota を設定するために使用されます。この例では、ClusterQueue は、GPU リクエストの合計が NOMINAL_QUOTA 値以下の場合にのみワークロードを許可します。ClusterQueue の詳細については、クラスタキューの Kueue ドキュメントをご覧ください。

          2. kueue ブロックを次のように更新します。

            kueue:
   install: true
   config_path: $(vars.kueue_configuration_path)
   config_template_vars:
      num_gpus: $(vars.gpu_nominal_quota)

          3. kueue-configuration.yaml.tftpl ファイルの内容を次のように置き換えます。

            apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
   name: "default-flavor"
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: AdmissionCheck
metadata:
   name: dws-prov
spec:
   controllerName: kueue.x-k8s.io/provisioning-request
   parameters:
      apiGroup: kueue.x-k8s.io
      kind: ProvisioningRequestConfig
      name: dws-config
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ProvisioningRequestConfig
metadata:
   name: dws-config
spec:
   provisioningClassName: queued-provisioning.gke.io
   managedResources:
   - nvidia.com/gpu
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
   name: "dws-cluster-queue"
spec:
   namespaceSelector: {}
   resourceGroups:
   - coveredResources: ["nvidia.com/gpu"]
      flavors:
      - name: "default-flavor"
      resources:
      - name: "nvidia.com/gpu"
         nominalQuota: ${num_gpus}
   admissionChecks:
   - dws-prov
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
   namespace: "default"
   name: "dws-local-queue"
spec:
   clusterQueue: "dws-cluster-queue"
---

        • id: job-template フィールドで、node_count 変数を 2 に置き換えます。

    スポット

    1. GitHub リポジトリの examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml ブループリントで、terraform_backend_defaults セクションと vars セクションに次の設定を入力して、デプロイの特定の値と一致させます。

      • BUCKET_NAME: 前の手順で作成した Cloud Storage バケットの名前。
      • DEPLOYMENT_NAME: デプロイの一意の名前。長さは 6 ～ 30 文字にする必要があります。デプロイ名がプロジェクト内で一意でない場合、クラスタの作成は失敗します。
      • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
      • COMPUTE_REGION: クラスタのコンピューティング リージョン。
      • COMPUTE_ZONE: A3 Ultra マシンのノードプールのコンピューティング ゾーン。
      • IP_ADDRESS/SUFFIX: クラスタへの接続を許可する IP アドレス範囲。この CIDR ブロックには、Terraform の呼び出しに使用するマシンの IP アドレスを含める必要があります。詳細については、承認済みネットワークの仕組みをご覧ください。
      • reservation ブロック全体（reservation 行自体を含む）を spot: true に置き換えます。
      • NODE_COUNT: クラスタ内の A3 Ultra ノードの数。

    2. GitHub リポジトリの examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml ブループリントで、次の変更を行います。

      • vars ブロックで、reservation 変数全体を spot: true に置き換えます。

      • id: a3-ultragpu-pool セクションで、reservation_affinity ブロックを削除します。このブロックを次の行に置き換えます。

        • spot: $(vars.spot)

  6. 省略可: 高性能な共有ストレージ用に Managed Lustre を構成します。A3 Ultra GKE ブループリントでは、Managed Lustre CSI ドライバがデフォルトで有効になっています。クラスタで Managed Lustre インスタンスと永続ボリュームをプロビジョニングするには、次の操作を行います。

    1. examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml ファイルを開きます。
    2. vars セクションで、lustre_instance_id、lustre_size_gib、per_unit_storage_throughput 変数のコメント化を解除します。
    3. # --- MANAGED LUSTRE ADDITIONS --- セクションで、private_service_access、lustre_firewall_rule、managed-lustre、lustre-pv の各モジュールのコメント化を解除します。

  7. アプリケーションのデフォルト認証情報（ADC）を生成して、Terraform にアクセスできるようにします。Cloud Shell を使用している場合は、gcloud auth application-default login コマンドを使用します。

    gcloud auth application-default login

  8. gcluster deploy コマンドを使用してブループリントをデプロイし、A3 Ultra マシンタイプを使用して GKE インフラストラクチャをプロビジョニングします。

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml \
    examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml

  9. プロンプトが表示されたら、[(A)pply] を選択してブループリントをデプロイします。

    • このブループリントは、VPC ネットワーク、GPU RDMA VPC ネットワーク、サービス アカウント、クラスタ、ノードプールを作成します。
    • ブループリントで fio-bench-job-template ジョブ テンプレートをサポートするために、Google Cloud バケット、ネットワーク ストレージ、永続ボリューム リソースが作成されます。

A3 Mega

  1. Cloud Shell を起動します。別の環境を使用することもできますが、依存関係が Cluster Toolkit にすでにプリインストールされているため、Cloud Shell を使用することをおすすめします。Cloud Shell を使用しない場合は、依存関係をインストールする手順に沿って別の環境を準備します。

  2. Cluster Toolkit をインストールする。

  3. Terraform デプロイの状態を保存するために、バージョニングを有効にした Cloud Storage バケットを作成します。

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    次の変数を置き換えます。

    • BUCKET_NAME: 新しい Cloud Storage バケットの名前。バケットの命名要件を満たす必要があります。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • COMPUTE_REGION_TERRAFORM_STATE: Terraform デプロイの状態を保存するコンピューティング リージョン。

  4. GitHub リポジトリの examples/gke-a3-megagpu/gke-a3-megagpu-deployment.yaml ブループリントで、terraform_backend_defaults セクションと vars セクションの次の変数を、デプロイの特定の値と一致するように置き換えます。

    • BUCKET: 前の手順で作成した Cloud Storage バケットの名前。
    • DEPLOYMENT_NAME: デプロイの一意の名前。長さは 6～30 文字にする必要があります。デプロイ名がプロジェクト内で一意でない場合、クラスタの作成は失敗します。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • REGION: クラスタのコンピューティング リージョン。
    • ZONE: A3 Mega マシンのノードプールのコンピューティング ゾーン。このゾーンは、予約に対して使用可能なマシンがあるゾーンと一致する必要があります。
    • AUTHORIZED_CIDR: クラスタへの接続を許可する IP アドレス範囲。この CIDR ブロックには、Terraform を呼び出すマシンの IP アドレスを含める必要があります。詳細については、承認済みネットワークの仕組みをご覧ください。ホストマシンの IP アドレスを取得するには、curl -s https://ifconfig.me コマンドを実行します。

  5. GKE デプロイの使用オプションを選択します。

    デフォルトでは、デプロイ ファイルは標準予約または将来の予約を使用するように構成されています。別の使用量モデル（オンデマンド容量、Spot VM、Flex Start プロビジョニング モードなど）を使用するには、デプロイ YAML ファイルを更新します。詳細については、GKE の使用オプションをご覧ください。

    予約を構成するには、特定の予約セクションで次の値を設定します。

    • reservation_affinity ブロックの specific_reservations リストで、予約の name フィールドを指定します。
    • ノードプールを予約の任意の場所に配置するには、予約の名前（RESERVATION_NAME）を指定します。

    • 予約の特定のブロックをターゲットにするには、予約名とブロック名を次の形式で使用します。

      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      予約で使用可能なブロックが不明な場合は、予約のトポロジを表示するをご覧ください。

    • STATIC_NODE_COUNT: クラスタ内の A3 Mega ノードの数。

    詳細設定を変更するには、GitHub リポジトリの examples/gke-a3-megagpu/gke-a3-megagpu.yaml ブループリントを編集します。

  6. アプリケーションのデフォルト認証情報（ADC）を生成して、Terraform にアクセスできるようにします。Cloud Shell を使用している場合は、gcloud auth application-default login コマンドを使用します。

    gcloud auth application-default login

  7. gcluster deploy コマンドを使用してブループリントをデプロイし、A3 Mega マシンタイプを使用して GKE インフラストラクチャをプロビジョニングします。

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a3-megagpu/gke-a3-megagpu-deployment.yaml \
    examples/gke-a3-megagpu/gke-a3-megagpu.yaml

  8. プロンプトが表示されたら、[(A)pply] を選択してブループリントをデプロイします。ブループリントは、VPC ネットワーク、サービス アカウント、クラスタ、ノードプールを作成します。

A3 High

  1. Cloud Shell を起動します。別の環境を使用することもできますが、依存関係が Cluster Toolkit にすでにプリインストールされているため、Cloud Shell を使用することをおすすめします。Cloud Shell を使用しない場合は、依存関係をインストールする手順に沿って別の環境を準備します。

  2. Cluster Toolkit をインストールする。

  3. Terraform デプロイの状態を保存するために、バージョニングを有効にした Cloud Storage バケットを作成します。

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    次の変数を置き換えます。

    • BUCKET_NAME: 新しい Cloud Storage バケットの名前。バケットの命名要件を満たす必要があります。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • COMPUTE_REGION_TERRAFORM_STATE: Terraform デプロイの状態を保存するコンピューティング リージョン。

  4. GitHub リポジトリの examples/gke-a3-highgpu/gke-a3-highgpu-deployment.yaml ブループリントで、terraform_backend_defaults セクションと vars セクションの次の変数を、デプロイの特定の値と一致するように置き換えます。

    • BUCKET: 前の手順で作成した Cloud Storage バケットの名前。
    • DEPLOYMENT_NAME: デプロイの一意の名前。長さは 6～30 文字にする必要があります。デプロイ名がプロジェクト内で一意でない場合、クラスタの作成は失敗します。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • REGION: クラスタのコンピューティング リージョン。
    • ZONE: A3 High マシンのノードプールのコンピューティング ゾーン。このゾーンは、予約に対して使用可能なマシンがあるゾーンと一致する必要があります。
    • AUTHORIZED_CIDR: クラスタへの接続を許可する IP アドレス範囲。この CIDR ブロックには、Terraform を呼び出すマシンの IP アドレスを含める必要があります。詳細については、承認済みネットワークの仕組みをご覧ください。ホストマシンの IP アドレスを取得するには、curl -s https://ifconfig.me コマンドを実行します。

  5. GKE デプロイの使用オプションを選択します。

    デフォルトでは、デプロイ ファイルは標準予約または将来の予約を使用するように構成されています。別の使用量モデル（オンデマンド容量、Spot VM、Flex Start プロビジョニング モードなど）を使用するには、デプロイ YAML ファイルを更新します。詳細については、GKE の使用オプションをご覧ください。

    予約を構成するには、特定の予約セクションで次の値を設定します。

    • reservation_affinity ブロックの specific_reservations リストで、予約の name フィールドを指定します。
    • ノードプールを予約の任意の場所に配置するには、予約の名前（RESERVATION_NAME）を指定します。

    • 予約の特定のブロックをターゲットにするには、予約名とブロック名を次の形式で使用します。

      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      予約で使用可能なブロックが不明な場合は、予約のトポロジを表示するをご覧ください。

    • STATIC_NODE_COUNT: クラスタ内の A3 High ノードの数。

    詳細設定を変更するには、GitHub リポジトリの examples/gke-a3-highgpu/gke-a3-highgpu.yaml ブループリントを編集します。

  6. アプリケーションのデフォルト認証情報（ADC）を生成して、Terraform にアクセスできるようにします。Cloud Shell を使用している場合は、gcloud auth application-default login コマンドを使用します。

    gcloud auth application-default login

  7. gcluster deploy コマンドを使用してブループリントをデプロイし、A3 High マシンタイプを使用して GKE インフラストラクチャをプロビジョニングします。

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a3-highgpu/gke-a3-highgpu-deployment.yaml \
    examples/gke-a3-highgpu/gke-a3-highgpu.yaml

  8. プロンプトが表示されたら、[(A)pply] を選択してブループリントをデプロイします。ブループリントは、VPC ネットワーク、サービス アカウント、クラスタ、ノードプールを作成します。

Dynamic Workload Scheduler のサンプルジョブを実行する

Dynamic Workload Scheduler（Flex Start またはキューに格納されたプロビジョニング）を使用してクラスタをプロビジョニングした場合は、サンプルの Kubernetes Job を送信してワークロードのスケジューリングを検証できます。

Dynamic Workload Scheduler のプロビジョニング モードの詳細については、キューに格納されたプロビジョニングでの Dynamic Workload Scheduler の Flex Start をご覧ください。

サンプルジョブを送信する

使用オプションに対応するタブを選択します。

Flex Start

このタスクは省略可能で、Flex Start でクラスタをプロビジョニングした場合にのみ適用されます。Flex Start 用に構成されたワークロードでは、Pod 仕様に cloud.google.com/gke-flex-start: "true" ノードセレクタが必要です。

  1. サンプルの Flex Start ジョブを送信します。

    kubectl apply -f examples/dws-sample-workloads/sample-job-flex.yaml

  2. Job と Pod のステータスをモニタリングします。

    kubectl get jobs
kubectl describe job JOB_NAME
kubectl get pods
kubectl describe pod POD_NAME

    次のように置き換えます。

    • JOB_NAME: Job の名前。
    • POD_NAME: Pod の名前。

  3. Job が完了したら、Job リソースを削除します。

    kubectl delete -f examples/dws-sample-workloads/sample-job-flex.yaml

キューに格納されたプロビジョニング

このタスクは省略可能で、キューに格納されたプロビジョニングでクラスタをプロビジョニングした場合にのみ適用されます。キューに格納されたプロビジョニング用に構成されたワークロードには、Pod 仕様に次のラベルとアノテーションが必要です。

  • ラベル: kueue.x-k8s.io/queue-name: dws-local-queue
  • アノテーション: provreq.kueue.x-k8s.io/maxRunDurationSeconds: "MAX_RUN_DURATION"

詳細については、キューに格納されたプロビジョニングのワークロード マニフェストの要件をご覧ください。

  1. サンプルのキューに格納されたプロビジョニング ジョブを送信します。

    kubectl apply -f examples/dws-sample-workloads/sample-job-flex-queue.yaml

  2. Job と Pod のステータスをモニタリングします。

    kubectl get jobs
kubectl describe job JOB_NAME
kubectl get pods
kubectl describe pod POD_NAME

    次のように置き換えます。

    • JOB_NAME: Job の名前。
    • POD_NAME: Pod の名前。

  3. Job が完了したら、Job リソースを削除します。

    kubectl delete -f examples/dws-sample-workloads/sample-job-flex-queue.yaml

ネットワーク パフォーマンスをテストする

プロビジョニングされたクラスタの機能を検証することをおすすめします。これを行うには、Google 環境用に最適化された NVIDIA Collective Communications Library（NCCL）テストである NCCL テストを使用します。

再現可能なベンチマークを実行する

Cluster Toolkit を使用してクラスタを作成したら、GitHub で提供されているレシピに沿って、選択したマシンシリーズで大規模な ML オープンモデルの事前トレーニング ベンチマークを再現できます。

各レシピには、次のタスクを完了するための手順が記載されています。

  • 環境を準備する。
  • ベンチマークを実行します。
  • ベンチマーク結果を分析します。このレビューには、ベンチマーク結果と詳細なログが含まれており、さらに分析できます。

トレーニングやその他のタイプのワークロードで使用できるすべてのレシピを確認するには、GPU レシピの GitHub リポジトリをご覧ください。

Cluster Toolkit によって作成されたリソースをクリーンアップする

このページで使用したリソースに対して繰り返し課金されないようにするには、gcluster destroy コマンドを使用して、Cluster Toolkit によってプロビジョニングされたリソース（VPC ネットワークや GKE クラスタなど）をクリーンアップします。

   cd ~/cluster-toolkit
   ./gcluster destroy CLUSTER_NAME/

CLUSTER_NAME は、使用するクラスタの名前に置き換えます。Cluster Toolkit で作成されたクラスタの場合、クラスタ名は DEPLOYMENT_NAME 名に基づいています。

次のステップ