カスタム ComputeClass について

独自の ComputeClass を作成して、クラスタの自動スケーリング時に Google Kubernetes Engine（GKE）がプロビジョニングするノードのプロパティを制御できます。このドキュメントは、特定のワークロードが要件を満たすハードウェアで実行されるように、ノードに対して自動スケーリング プロファイルを宣言的に定義するプラットフォーム管理者を対象としています。ComputeClass の詳細については、GKE ComputeClass についてをご覧ください。

ComputeClass の概要

GKE の ComputeClass は、自動スケーリング イベント中にワークロードが実行されるノードのプロビジョニングに GKE が使用する一連のノード属性で構成されるプロファイルです。ComputeClass では、高パフォーマンス ノードのプロビジョニングや、運用コストを削減するための費用最適化構成の優先付けなど、特定の最適化をターゲットに設定できます。カスタム ComputeClass を使用すると、GKE が特定のワークロードの要件に厳密に一致するノードを自動スケーリングするためのプロファイルを定義できます。

カスタム ComputeClass は、バージョン 1.30.3-gke.1451000 以降の GKE Autopilot モードと GKE Standard モードで使用できます。また、ノード属性と自動スケーリングの優先度を宣言的に定義できます。デフォルトでは、カスタム ComputeClass は対象となるすべての GKE クラスタに構成し、使用できます。

カスタム ComputeClass のメリット

カスタム ComputeClass には、次のようなメリットがあります。

  • フォールバック コンピューティングの優先度: GKE が優先順位を判断できるように、各 ComputeClass でノードの構成の階層を定義できます。最も優先される構成が使用できない場合、GKE は階層内の次の構成を自動的に選択します。このフォールバック モデルにより、コンピューティング リソースが使用できない場合でも、ワークロードは最適化されたハードウェアで実行され、スケジューリングの遅延を最小限に抑えることができます。
  • きめ細かい自動スケーリング制御: 特定のワークロードに最適なノード構成を定義できます。GKE は、スケーリングでノードを作成するときに、これらの構成を優先します。
  • 宣言型インフラストラクチャ構成: インフラストラクチャ管理に宣言型アプローチを採用し、GKE が特定のワークロード要件に一致するノードを自動的に作成できるようにします。
  • アクティブな移行: 優先されるマシン構成のコンピューティング リソースがロケーションで利用可能になると、GKE は優先構成を使用する新しいノードにワークロードを自動的に移行します。
  • 費用の最適化: Spot VM などの費用対効果の高いノードタイプが優先されます。これにより、クラスタの費用を削減できます。
  • デフォルトのカスタム ComputeClass: カスタム ComputeClass をクラスタ全体または特定の Kubernetes Namespace のデフォルトとして設定し、特定の ComputeClass をリクエストしない場合でも、ワークロードが最適化されたハードウェアで実行されるようにします。
  • カスタムノードの統合しきい値: ノードにカスタム リソース使用率のしきい値を定義します。特定ノードのリソース使用量がしきい値を下回ると、GKE はワークロードを使用可能な類似のノードに統合し、使用率の低いノードをスケールダウンします。

カスタム ComputeClass のユースケース

次のようなシナリオでは、カスタム ComputeClass の使用を検討してください。

  • 特定の GPU または TPU 構成で AI / ML ワークロードを実行する。
  • 特定のチームが実行するワークロードのデフォルトのハードウェア構成を設定し、アプリケーション オペレーターのオーバーヘッドを軽減する。
  • 特定の Compute Engine マシンシリーズまたはハードウェア構成で最適に動作するワークロードを実行する。
  • 高パフォーマンス、費用の最適化、高可用性など、特定のビジネス要件を満たすハードウェア構成を宣言する必要がある。
  • コンピューティング リソースが使用できない場合に、GKE が特定のハードウェア構成を使用するように階層的にフォールバックし、ワークロードが常に要件に合ったマシンで実行されるようにする。
  • 企業のフリート全体で最適な構成を一元的に決定し、コストを予測可能にすることで、ワークロードをより確実に実行できるようにする。
  • GKE が特定のワークロードの新しいノードのプロビジョニングに使用する Compute Engine 容量予約を、一元的に指定できるようにする。
  • GKE Autopilot で使用するコンパクト プレースメント ポリシーを指定する。詳細については、コンパクト プレースメントをご覧ください。

カスタム ComputeClass の仕組み

カスタム ComputeClass は、Google Cloud インフラストラクチャをプロビジョニングする Kubernetes カスタム リソースです。クラスタで ComputeClass オブジェクトを定義し、ワークロードでその ComputeClass をリクエストするか、その ComputeClass を Kubernetes 名前空間のデフォルトとして設定します。一致するワークロードで新しいインフラストラクチャが要求されると、GKE は ComputeClass 定義で設定した優先度に従って新しいノードをプロビジョニングします。

ComputeClass で設定する属性は、GKE がワークロードを実行するように新しいノードを構成する方法を定義します。既存の ComputeClass を変更すると、GKE がその ComputeClass 用に作成する今後のすべてのノードで、変更された構成が使用されます。GKE は、変更内容に合わせて既存ノードの構成を遡及的に変更しません。

カスタム ComputeClass は自動スケーリングの決定に影響しますが、kube-scheduler では考慮されません。Pod のスケジューリング中に、既存のノードがさまざまな優先度で利用可能な場合でも、スケジューラは優先度の高いカスタム ComputeClass を持つノードを優先しないことがあります。

カスタム ComputeClass をフリート用に最適化するには、次のガイドラインを考慮してください。

  • アプリケーション固有のハードウェア要件など、フリートのコンピューティング要件を把握します。
  • 各 ComputeClass の設計指針となるテーマを決めます。たとえば、パフォーマンスが最適化された ComputeClass には、高 CPU マシンタイプのみを使用するようにフォールバック戦略を計画します。
  • ワークロードに最も適した Compute Engine マシン ファミリーとマシンシリーズを決定します。詳しくは、マシン ファミリーのリソースと比較ガイドをご覧ください。
  • 常に類似したマシン構成を使用するノードでワークロードが実行されるように、各 ComputeClass 内でフォールバック戦略を計画します。たとえば、N4 マシンシリーズを使用できない場合は、C3 マシンにフォールバックします。

完全なカスタム リソース定義を表示する

すべてのフィールドとその関係を含む、ComputeClass カスタム リソースの最新のカスタム リソース定義（CRD）を表示するには、ComputeClass リファレンス ドキュメントをご覧ください。

次のコマンドを実行して、クラスタ内の CRD を表示することもできます。

kubectl describe crd computeclasses.cloud.google.com

カスタム ComputeClass を計画する

クラスタでカスタム ComputeClass を効果的に計画、デプロイ、使用するには、次の操作を行います。

  1. フォールバックのコンピューティングの優先度を選択する: GKE が ComputeClass に作成するノードのプロパティを管理するために、一連のルールを定義します。
  2. GKE Standard ノードプールと ComputeClass を構成する: Standard モードのクラスタの場合は、必要な構成手順に沿って、ノードプールで ComputeClass を使用します。
  3. 優先度ルールが適用されない場合のスケーリング動作を定義する: 必要に応じて、優先度ルールを満たすノードをプロビジョニングできない場合の処理を GKE に指示します。
  4. ノード統合用に自動スケーリング パラメータを設定する: ワークロードを統合し、使用効率の低いノードを削除するタイミングを GKE に指示します。
  5. 優先度の高いノードへのアクティブ移行を構成する: ハードウェアが利用可能になったときに、ワークロードを優先ノードに移動するよう GKE に指示します。
  6. Compute Engine 予約を使用する: 必要に応じて、新しいノードを作成するときに既存の Compute Engine ゾーン予約を使用するように GKE に指示します。

フォールバックのコンピューティングの優先度を選択する

カスタム ComputeClass を使用する主な利点は、リソースの枯渇や割り当ての制限などの要因により、優先ノードが使用できない場合のフォールバック戦略を制御できることです。

フォールバック戦略は、ComputeClass 仕様の priorities フィールドで優先度ルールのリストを定義して作成します。各優先度ルールは、次のいずれかの方法でノードをリクエストできます。

  • ノード プロパティ: 使用するマシン ファミリーなど、Pod を実行するノードのプロパティを定義します。Pod がスケールアップ オペレーションをトリガーすると、GKE はこれらのプロパティを持つノードを作成しようとします。優先ルールのトップレベルのノード プロパティのセクションで説明されているように、各優先ルールでプロビジョニングするハードウェアのタイプを指定する必要があります。

  • ノードプールの選択: GKE Standard クラスタで、ComputeClass に関連付ける既存のノードプールの名前を指定します。Pod がスケールアップ オペレーションをトリガーすると、GKE はこれらのノードプールに Pod を配置しようとします。ノードプールを選択する優先度ルールでは、他のフィールドはサポートされていません。詳細については、GKE Standard ノードプールと ComputeClass をご覧ください。

デフォルトでは、ComputeClass を選択する受信 Pod に新しいノードが必要になると、GKE は ComputeClass マニフェストに優先度ルールが表示される順序でノードの作成を試みます。GKE バージョン 1.35.2-gke.1842000 以降では、priorityScore フィールドを使用して、ComputeClass のすべての優先度ルールのスコアを明示的に設定することもできます。この場合、GKE はスコアの高い順にルールを処理します。ComputeClass の優先度ルールがすべて適用されると、GKE は、優先度ルールが適用されない場合のスケーリング動作を定義するで説明されている動作に基づいてノードを作成します。

優先度ルールのスコア

GKE バージョン 1.35.2-gke.1842000 以降が必要です。

ComputeClass の優先度ルールの処理順序を細かく制御するには、ルールの priorityScore フィールドを使用します。スケーリング中、GKE はスコアに基づいて優先度ルールを処理します。スコア値が大きいほど、優先度が高くなります。

priorityScore フィールドには次のプロパティがあります。

  • このフィールドには、最小値が 1、最大値が 1000 の整数値を指定します。
  • すべての優先順位ルールで priorityScore フィールドを使用するか、すべての優先順位ルールで priorityScore フィールドを使用しない必要があります。

  • 最大 3 つの個別のルールに同じ優先度スコアを設定できます。スケーリング中、GKE は同じスコアのルールをまとめて処理します。GKE は、クラスタ オートスケーラーの動作条件に基づいて、使用する特定のルールを選択します。

    グループ化されたルールでは、最適なノード構成を決定するために GKE が実行するシミュレーションの数が増えるため、自動スケーリングのレイテンシが増加する可能性があります。レイテンシの増加に気づく可能性は、ルールのハードウェア選択の範囲によって次のように異なります。

    • machineFamily プロパティなど、範囲の広いルールは、自動スケーリングのレイテンシがわずかに増加する原因となる可能性が高くなります。ただし、GKE では、これらのルールの要件を満たす利用可能なハードウェアが見つかる可能性が高くなります。
    • machineType プロパティなど、範囲が狭いルールは、レイテンシの増加に寄与する可能性が低くなります。ただし、GKE は、これらのルールの要件を満たす利用可能なハードウェアを見つけられない可能性が高くなります。

次の例は、優先度ルールのスコアを設定する ComputeClass を示しています。

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: priority-rule-score-class
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  # Highest priority score in the ComputeClass
  - machineFamily: e2
    spot: true
    priorityScore: 30
  # Grouped priority rules that have the same score.
  - machineFamily: n2
    spot: true
    priorityScore: 20
  - machineFamily: t2d
    spot: true
    priorityScore: 20
  # Lowest priority score in the ComputeClass.
  - machineFamily: n1
    spot: true
    priorityScore: 10
  whenUnsatisfiable: ScaleUpAnyway

この例の ComputeClass のスケールアップ イベント中に、GKE は次の処理を行います。

  1. GKE は E2 インスタンスの作成を試みます。
  2. E2 インスタンスが使用できない場合、GKE はクラスタ オートスケーラーの結果に応じて N2 インスタンスまたは T2D インスタンスを作成します。
  3. N2 インスタンスと T2D インスタンスを使用できない場合、GKE は N1 インスタンスの作成を試みます。
  4. N1 インスタンスを使用できない場合、GKE はクラスタのデフォルトのマシンシリーズにフォールバックします。

優先度ルールの最上位ノード プロパティ

ノードのプロパティを定義する優先度ルールを指定する場合は、ノードに必要な最上位のハードウェア タイプを選択する必要があります。ルールに指定できる他のプロパティは、そのルールのトップレベル プロパティによって異なります。

ルールには、次のトップレベル プロパティを使用できます。

  • machineFamily: Compute Engine マシンシリーズ（n4 など）。
  • machineType: 特定の Compute Engine マシンタイプ（n4-standard-32 など）。
  • gpu: GPU 構成。GPU タイプ、特定の数の GPU、ドライバ構成が含まれる場合があります。
  • tpu: Cloud TPU 構成。TPU のバージョン、トポロジ、チップの数などが含まれます。

アクセラレータ構成では、予約と組み合わせて使用する場合を除き、machineType フィールドまたは machineFamily フィールドを明示的に指定する必要はありません。

Compute Engine マシンシリーズの各世代は、特定のディスクタイプをサポートしています。たとえば、N4 マシンシリーズは Hyperdisk ML ディスクタイプをサポートしていますが、N2 マシンシリーズはサポートしていません。複数の世代にまたがる ComputeClass では、特定ディスクタイプをリクエストするステートフル ワークロードは、マシンタイプがそのディスクタイプをサポートしていない場合、永続データにアクセスできない可能性があります。ワークロードでディスクを作成して使用する方法に応じて、次のいずれかの方法を使用して、アクセスできない永続データの発生リスクを軽減します。

  • 動的ボリューム プロビジョニング: GKE バージョン 1.35.3-gke.1290000 以降では、自動ディスクタイプ選択を構成する StorageClass を使用します。GKE は、ワークロードを実行するノードのマシンタイプと互換性のあるディスクタイプを作成します。以前の GKE バージョンでは、ComputeClass 内のすべてのマシンシリーズが、StorageClass がプロビジョニングするディスクタイプをサポートしていることを確認します。

  • 既存の永続ディスク: ComputeClass 内のすべてのマシンシリーズが、既存の永続ディスクのディスクタイプをサポートしていることを確認します。

各マシンシリーズでサポートされているディスクタイプの詳細については、マシンシリーズの比較表をご覧ください。

machineFamily 構成

machineFamily フィールドには、n2 や c3 などの Compute Engine マシンシリーズを指定します。指定しない場合は、デフォルトの e2 が使用されます。machineFamily フィールドを使用すると、GKE は Pod の実行に十分な大きさのマシンタイプを使用して、そのシリーズからノードをプロビジョニングします。オートスケーラー アルゴリズムは、保留中のすべての Pod の集約リソース リクエストに基づいて、最適なサイズを決定します。正確なマシンサイズをより細かく制御するには、代わりに machineType フィールドを使用します。

machineFamily フィールドとともに他の spec.priorities フィールドを使用して、コンピューティング要件を宣言的に定義できます。次に例を示します。

  • spot: Spot VM。デフォルト値は false です。
  • minCores: ノードあたりの最小 vCPU。デフォルト値は 0 です。このフィールドは、ニーズに合わないほど小さいノードの作成を防ぐのに役立ちます。
  • minMemoryGb: ノードあたりの最小メモリ。デフォルト値は 0 です。
  • storage.bootDiskType: ブートディスクの種類。Autopilot クラスタでは、bootDiskType の pd-balanced タイプのみがサポートされています。GKE バージョン 1.34.1-gke.1431000 以降が必要です。
  • storage.bootDiskSize: ノード ブートディスクのサイズ（GB）。GKE バージョン 1.34.1-gke.1431000 以降が必要です。
  • storage.bootDiskKMSKey: ブートディスクの暗号化に使用する Cloud Key Management Service 鍵のパス。
  • storage.secondaryBootDisks: ML モデルやコンテナ イメージなどのデータを GKE ノードにプリロードするために使用される永続ディスク。GKE バージョン 1.31.2-gke.1105000 以降が必要です。クラスタが使用するセカンダリ ブートディスクを設定するには、セカンダリ ブートディスクを構成するをご覧ください。
    • storage.secondaryBootDisks.diskImageName: プリロードするディスク イメージの名前。
    • storage.secondaryBootDisks.project: ディスク イメージが属するプロジェクトの名前。この値を指定しない場合、デフォルトはクラスタ プロジェクトです。
    • storage.secondaryBootDisks.mode: セカンダリ ブートディスクを使用する必要があるモード。この値が CONTAINER_IMAGE_CACHE に設定されている場合、セカンダリ ブートディスクはコンテナ イメージ キャッシュとして使用されます。値は CONTAINER_IMAGE_CACHE または MODE_UNSPECIFIED にする必要があります。この値を指定しない場合、デフォルトは MODE_UNSPECIFIED です。
  • placement: マシンの配置の詳細:

次の例で示すのは、machineFamily を使用する優先度ルールです。

priorities:
- machineFamily: n4
  spot: true
  minCores: 16
  minMemoryGb: 64
  storage:
    bootDiskType: hyperdisk-balanced
    bootDiskSize: 100
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1
    secondaryBootDisks:
    - diskImageName: pytorch-mnist
      project: k8s-staging-jobset

machineType 構成

machineType フィールドには、Compute Engine の事前定義されたマシンタイプ（n4-standard-32 など）またはカスタム マシンタイプの文字列（n4-custom-8-20480 など）を指定します。カスタム マシンタイプを使用するには、GKE バージョン 1.33.2-gke.1111000 以降が必要です。

machineType フィールドとともに他の spec.priorities フィールドを指定して、コンピューティング要件を宣言的に定義できます。次に例を示します。

  • spot: Spot VM を使用します。デフォルトは false です。
  • storage: ノード ストレージを構成します。
    • storage.bootDiskType: ブートディスクの種類。Autopilot では、bootDiskType の pd-balanced タイプのみがサポートされています。
    • storage.bootDiskKMSKey: ブートディスクの暗号化に使用する Cloud KMS 鍵のパスと名前。
    • storage.bootDiskSize: ノード ブートディスクのサイズ（GB）。
    • storage.localSSDCount: ノードに接続するローカル SSD の数。指定する場合は、1 以上にする必要があります。

次の例で示すのは、machineType を使用して n4-standard-32 マシンタイプをプロビジョニングする優先度ルールをです。

priorities:
- machineType: n4-standard-32
  spot: true
  storage:
    bootDiskType: hyperdisk-balanced
    bootDiskSize: 250
    localSSDCount: 2
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1

GPU 構成

優先度ルールで GPU を選択するには、優先度ルールの gpu フィールドに GPU のタイプ、数、driverVersion（省略可）を指定します。次のフィールドがサポートされています。

gpu フィールドと組み合わせて、Spot VM、ストレージ オプション、予約などの他の spec.priorities フィールドを指定することもできます。

次の例で示すのは、GPU のルールです。

priorities:
- gpu:
    type: nvidia-l4
    count: 1
  storage:
    secondaryBootDisks:
    - diskImageName: big-llm
      project: k8s-llm
  spot: true

TPU の構成

GKE バージョン 1.31.2-gke.1518000 以降が必要です

優先度ルールで TPU を選択するには、優先度ルールの tpu フィールドに TPU のタイプ、数、トポロジを指定します。次のフィールドに値を入力する必要があります。

優先度ルールの tpu フィールドとともに、他の spec.priorities フィールドを指定することもできます。次に例を示します。

  • spot: Spot VM を使用します。デフォルトは false です。
  • storage: ノード ストレージを構成します。
    • storage.bootDiskType: ブートディスクの種類。
    • storage.bootDiskKMSKey: ブートディスクの暗号化に使用する Cloud KMS 鍵のパスと名前。
    • storage.bootDiskSize: ノード ブートディスクのサイズ（GB）。
  • reservations: Compute Engine の予約を使用します。詳細については、Compute Engine の予約を使用するをご覧ください。
  • location:
    • zones: GKE がノードをプロビジョニングできる Google Cloud ゾーンのリスト。指定しない場合、GKE はクラスタのノード自動プロビジョニング設定で構成されたゾーンにノードをプロビジョニングします。ノード自動プロビジョニング用にゾーンが構成されていない場合、GKE はコントロール プレーンが使用する標準ゾーンのいずれかにノードをプロビジョニングします。

      省略可: us-central1-ai1a などの AI ゾーンを使用します。AI ゾーンは、 Google Cloud リージョン内の AI/ML ワークロード向けに最適化された特別なロケーションです。

    • zoneTypes: GKE がノードをプロビジョニングできる Google Cloudゾーンのセットを指定するゾーンタイプのリスト。サポートされている値は、CLUSTER_DEFAULT（デフォルト）、STANDARD、AI です。詳細については、ロケーションの zoneTypes の優先度の使用をご覧ください。

次の例は、TPU のルールを示しています。

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-class
spec:
  priorities:
  - tpu:
      type: tpu-v5p-slice
      count: 4
      topology: 4x4x4
    reservations:
      specific:
      - name: tpu-reservation
        project: reservation-project
      affinity: Specific
  - spot: true
    tpu:
      type: tpu-v5p-slice
      count: 4
      topology: 4x4x4
  nodePoolAutoCreation:
    enabled: true

この例では、次のフォールバック動作を定義します。

  1. GKE は、reservation-project プロジェクトの tpu-reservation という名前の共有 Compute Engine 予約を使用して、16 ノードマルチホスト TPU v5p スライスのプロビジョニングを試みます。
  2. 予約に使用可能な TPU がない場合、GKE は Spot VM で実行される 16 ノードマルチホスト TPU v5p スライスのプロビジョニングを試みます。
  3. 上記のルールを満たすことができない場合、GKE は優先度ルールが適用されない場合のスケーリング動作を定義するのロジックを適用します。

TPU カスタム ComputeClass をクラスタにデプロイしたら、ワークロードでそのカスタム ComputeClass を選択します。

また、TPU ワークロードでは次の操作を行えます。

目標 AI ゾーン

コンピューティング クラスを使用して、Pod の AI ゾーンを指定することもできます。AI ゾーンは、AI/ML ワークロード用に最適化された Google Cloud リージョン内の特殊なロケーションです。次のコンピューティング クラスは、AI ゾーンを含むゾーンの優先順位付きリストを設定します。

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: accelerator-ai-preferred
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
    # --- Priority 1: TPU in a specific AI zone (On-Demand) ---
    - tpu:
        type: tpu-v5p-slice
        count: 4
        topology: 4x4x4
      location:
        zones:
          - "us-central1-ai1a" # Specify your target AI zone
      # machineFamily: a3 # Optional

    # --- Priority 2: TPU in any AI zone (On-Demand)  ---
    - tpu:
        type: tpu-v5p-slice
        count: 4
        topology: 4x4x4
      location:
        zoneTypes:
          - "AI" # All AI zones in the cluster's region

    # --- Priority 3: GPU in a specific Standard zone (On-Demand) ---
    - gpu:
        type: nvidia-tesla-a100
        count: 1
      location:
        zones:
          - "us-central1-a" # Fallback to a standard zone
          - "us-central1-b"
  whenUnsatisfiable: DoNotScaleUp

この ComputeClass は、ワークロード用に v5p TPU または A100 GPU を使用してノードをプロビジョニングするように GKE を構成します。ノードには次の設定があります。

  • 優先度 1: us-central1-ai1a AI ゾーンで TPU のプロビジョニングを試みます。
  • 優先度 2: 特定の AI ゾーンで TPU を使用できない場合は、クラスタのリージョンの任意の AI ゾーンでプロビジョニングを試みます。
  • 優先度 3: AI ゾーンで TPU が使用できない場合は、us-central1-a または us-central1-b 標準ゾーンで GPU のプロビジョニングを試みます。
  • 指定されたゾーンのいずれにも A100 GPU がない場合、GKE はノードプールをスケールアップしません。

GKE が優先度ルールを使用してノードを作成する方法

ComputeClass をリクエストするワークロードをデプロイして、新しいノードが必要になると、GKE は ComputeClass 仕様の priorities フィールドのルールリストを出現順に処理します。priorityScore フィールドが設定されている場合は、スコアの高い順に処理します。

たとえば、次の仕様について考えてみましょう。

spec:
  ...
  priorities:
  - machineFamily: n4
    spot: true
    minCores: 64
  - machineFamily: n4
    spot: true
  - machineFamily: n4
    spot: false

この優先度ルールに従って ComputeClass をリクエストするワークロードをデプロイすると、GKE は次のようにノードを照合します。

  1. GKE は、この ComputeClass に関連付けられている既存のノードに Pod を配置します。
  2. 既存のノードに Pod を収容できない場合、GKE は N4 マシンシリーズを使用する新しいノードをプロビジョニングします。このノードは Spot VM で、64 vCPU 以上です。
  3. リージョンで 64 個以上の vCPU を備えた N4 Spot VM が使用できない場合、GKE はコア数に関係なく、Pod に適合する N4 Spot VM を使用する新しいノードをプロビジョニングします。
  4. リージョンで使用可能な N4 Spot VM がない場合、GKE は新しいオンデマンド N4 VM をプロビジョニングします。
  5. 上記のルールを満たすことができない場合、GKE は優先度ルールが適用されない場合のスケーリング動作を定義するのロジックを適用します。

優先度ルールのデフォルト値

ComputeClass 仕様の優先度ルールの一部フィールドにデフォルト値を設定できます。これらのデフォルト値は、特定のルールの対応するフィールドが省略されている場合に適用されます。これらのデフォルト値は、ComputeClass 仕様の priorityDefaults フィールドを使用して設定できます。

priorityDefaults フィールドには次の制限があります。

  • GKE バージョン 1.32.1-gke.1729000 以降が必要です。
  • フィールドが含まれていない nodepools 優先度ルールとは互換性がありません。

設定できるデフォルト値の種類については、ComputeClass CustomResourceDefinition の priorityDefaults セクションをご覧ください。

GKE Standard ノードプールと ComputeClass

GKE Standard モードを使用する場合は、ComputeClass Pod が想定どおりにスケジュールされるように、手動構成が必要になることがあります。

ComputeClass で使用するために手動で作成したノードプールを構成する

GKE Standard クラスタに手動で作成したノードプールがある場合は、特定の ComputeClass に関連付けるように、これらのノードプールを構成する必要があります。GKE は、特定の ComputeClass をリクエストする Pod のみを、その ComputeClass に関連付けられたノードプールのノードでスケジューリングします。この要件は、クラスタレベルのデフォルトとして構成する ComputeClass には適用されません。

GKE Autopilot モードと、GKE Standard モードで自動作成されたノードプールでは、この構成が自動的に実行されます。

手動で作成したノードプールを ComputeClass に関連付けるには、作成時または更新時に、次のように --node-labels フラグと --node-taints フラグを指定して、ノードプールにノードラベルとノード Taint を追加します。

  • ノードラベル: cloud.google.com/compute-class=COMPUTE_CLASS
  • Taint: cloud.google.com/compute-class=COMPUTE_CLASS:NoSchedule

これらの属性で、COMPUTE_CLASS はカスタム ComputeClass の名前です。

たとえば、次のコマンドは、既存のノードプールを更新し、dev-class ComputeClass に関連付けます。

gcloud container node-pools update dev-pool \
    --cluster=example-cluster \
    --node-labels="cloud.google.com/compute-class=dev-class"

gcloud container node-pools update dev-pool \
    --cluster=example-cluster \
    --node-taints="cloud.google.com/compute-class=dev-class:NoSchedule"

クラスタ内の各ノードプールを 1 つのカスタム ComputeClass に関連付けることができます。手動で作成されたノードプールで GKE がスケジュールする Pod は、自動スケーリング イベント中にのみ、そのノードプール内でノードの作成をトリガーします。

ノードプールの自動作成と ComputeClass

カスタム ComputeClass でノードプールの自動作成を使用すると、GKE によって優先度ルールに基づいてノードプールが自動的に作成および削除されます。

GKE で ComputeClass のノードプールを自動的に作成するには、次の操作を行う必要があります。

  1. enabled: true 値を持つ nodePoolAutoCreation フィールドを ComputeClass 仕様に追加します。
  2. クラスタが GKE バージョン 1.33.3-gke.1136000 より前のバージョンを実行している場合は、クラスタレベルのノード自動プロビジョニングを有効にする必要もあります。

これにより、GKE は、ComputeClass を使用する Pod の新しいノードプールを作成できます。GKE は、クラスタのサイズや Pod の要件などの要素に基づいて、既存のノードプールをスケールアップするか、新しいノードプールを作成するかを決定します。ノードプールの自動作成を構成していない ComputeClass を持つ Pod は、引き続き既存のノードプールのみをスケールアップします。

ノードプールの自動作成を有効にする ComputeClass と、同じクラスタ内の手動で作成されたノードプールとやり取りする ComputeClass を併用できます。

ノードプールの自動作成との次のやり取りを検討してください。

  • マシン ファミリーまたは Spot VM ノードセレクタは、ComputeClass の動作と競合するため使用できません。GKE は、ComputeClass をリクエストし、Spot VM または特定のマシンシリーズもリクエストする Pod を拒否します。

  • クラスタのデフォルトの ComputeClass を設定すると、マシン ファミリー ノード セレクタを使用する Pod は、次のいずれかの状況でのみ、そのデフォルト クラスのノード作成をトリガーします。

    • Pod は、クラスタレベルのデフォルト クラスの優先度ルールのいずれかに一致するマシン ファミリーを選択します。たとえば、クラスタレベルのデフォルト クラスに N4 インスタンスの優先度ルールがある場合、N4 インスタンスを選択する Pod はノード作成をトリガーします。
    • クラスタレベルのデフォルトの ComputeClass の spec.whenUnsatisfiable フィールドの値は ScaleUpAnyway です。Pod が ComputeClass の優先度に含まれていないマシン ファミリーを選択した場合でも、GKE はそのマシン ファミリーで新しいノードを作成します。

    クラスタレベルのデフォルト クラスの優先順位に含まれていないマシン ファミリーを選択する Pod は、ComputeClass の whenUnsatisfiable フィールドに DoNotScaleUp の値がある場合、ノード作成をトリガーしません。

  • nodepools フィールドを使用して既存のノードプールを参照する ComputeClass にノードプールの自動作成を構成できます。GKE は、優先度順に処理し、既存のノードプールをスケールして Pod を配置しようとします。

手動で作成したノードプールがあり、ノードプールの自動作成が設定されているクラスタについて考えてみましょう。

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - nodepools: [manually-created-pool]
  - machineFamily: n4
  - machineFamily: c4
  nodePoolAutoCreation:
    enabled: true

この例では、GKE は次の処理を試みます。

  1. manually-created-pool ノードプールに新しいノードを作成します。
  2. 既存の N4 ノードプールまたは新しく作成したノードプールに N4 ノードをプロビジョニングします。
  3. GKE が N4 ノードを作成できない場合、既存の C4 ノードプールのスケールアップを行うか、新しい C4 ノードプールを作成します。

ComputeClass の定義で特定のノードプールをターゲットにする

priorities.nodepools フィールドを使用すると、クラスタの自動スケーリングを使用する GKE Standard クラスタで GKE が Pod のスケジューリングを試みる、手動作成のノードプールのリストを指定できます。このフィールドはノードプールのリストのみをサポートします。同じ優先度ルールのマシンシリーズなどの追加のマシン プロパティを指定することはできません。名前付きノードプールのある ComputeClass をリクエストするワークロードをデプロイすると、GKE は保留中の Pod をこれらのノードプールでスケジュールしようとします。GKE は、Pod を配置するために、これらのノードプールに新しいノードを作成する場合があります。

priorities.nodepools フィールドで指定するノードプールは、ComputeClass 用に手動で作成したノードプールを構成するに記載されているように、ノードラベルとノード taint を使用して、その ComputeClass に関連付ける必要があります。

nodepools フィールドで指定するノードプールのリストには優先順位がありません。名前付きノードプールのフォールバック順序を構成するには、複数の個別の priorities.nodepools 項目を指定する必要があります。たとえば、次の仕様について考えてみましょう。

spec:
  ...
  priorities:
  - nodepools: [pool1, pool2]
  - nodepools: [pool3]

この例では、GKE はまず、この ComputeClass をリクエストする保留中の Pod を、ComputeClass のラベルが付いたノードプールの既存のノードに配置しようとします。既存のノードが使用できない場合、GKE は pool1 または pool2 に新しいノードをプロビジョニングしようとします。GKE がこれらのノードプールで新しいノードをプロビジョニングできない場合、GKE は pool3 に新しい Pod をプロビジョニングしようとします。

優先度ルールが適用されない場合のスケーリングの動作を定義する

ComputeClass カスタム リソースを使用すると、優先度ルールの条件を満たすノードがない場合に GKE が行う処理を指定できます。仕様の whenUnsatisfiable フィールドは、次の値をサポートしています。

  • ScaleUpAnyway: クラスタのデフォルトのマシン構成を使用する新しいノードを作成します。1.33 より前の GKE バージョンでは、このフィールドを省略した場合、これがデフォルトの動作になります。

    GKE は次のいずれかのアクションを実行します。

    • Autopilot クラスタでは、GKE はノードのマシン構成に関係なく、新しいノードまたは既存のノードに Pod を配置します。
    • ノードプールの自動作成を使用しない Standard クラスタの場合、GKE は、特定の ComputeClass に一致するラベルと taint が定義された手動作成のノードプールをスケールアップしようとします。
    • ノードプールの自動作成を使用する Standard クラスタの場合、GKE が新しいノードプールを作成し、デフォルトの E2 マシンシリーズを使用して Pod を配置することがあります。

  • DoNotScaleUp: ComputeClass の要件を満たすノードが使用可能になるまで、Pod を Pending ステータスにします。GKE バージョン 1.33 以降では、このフィールドを省略すると、これがデフォルトの動作になります。

プレースメント ポリシーをリクエストする

GKE バージョン 1.33.2-gke.1335000 以降の GKE Autopilot クラスタでは、カスタム プレースメント ポリシーまたはワークロード ポリシーでコンパクト プレースメントを使用できます。詳細については、コンパクト プレースメント ポリシーとワークロード ポリシーの比較をご覧ください。

プレースメント ポリシーとワークロード ポリシーの両方で、ネットワーク レイテンシを短縮するためにノードが物理的に近い場所に配置されます。特定のポリシーを使用するには、policyName フィールドにその名前を指定します。ポリシーは、GKE プロジェクトにすでに存在する Compute Engine リソース ポリシーである必要があります。

次に例を示します。

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n4
    placement:
      policyName: my-placement-policy
  nodePoolAutoCreation:
    enabled: true

この構成では、GKE はこの ComputeClass を使用するすべてのワークロードにコンパクト プレースメント ポリシーを適用し、my-placement-policy という名前の既存のリソース ポリシーに従ってノードをプロビジョニングします。

ノード統合の自動スケーリング パラメータを設定する

デフォルトでは、GKE はワークロードの実行で使用率の低いノードを削除し、容量のある他のノードにワークロードを統合します。ComputeClass を使用するすべてのクラスタは、クラスタ オートスケーラーを使用するか、Autopilot クラスタにする必要があるため、すべての ComputeClass でこれがデフォルトの動作になります。ノードの統合中、GKE は使用率の低いノードをドレインし、別のノードでワークロードを再作成してから、ドレインされたノードを削除します。

ノードの削除のタイミングと基準は、自動スケーリング プロファイルによって異なります。カスタム ComputeClass の定義で autoscalingPolicy セクションを使用すると、ノードの削除とワークロードの統合をトリガーするリソース未使用率のしきい値を微調整できます。次のパラメータを微調整できます。

  • consolidationDelayMinutes: GKE が未使用ノードを削除するまでの時間（分）
  • consolidationThreshold: CPU とメモリの使用率のしきい値（ノードの使用可能なリソースの割合）。リソース使用率がこのしきい値を下回ると、GKE はノードの削除を検討します。
  • gpuConsolidationThreshold: GPU の使用率しきい値（ノードの使用可能なリソースの割合）。リソース使用率がこのしきい値を下回ると、GKE はノードの削除を検討します。割り当てられた GPU の使用率が 100% に達していないノードが統合されるように、この値を 100 または 0 に設定することを検討してください。

次に例を示します。

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n4
  - machineFamily: c4
  autoscalingPolicy:
    consolidationDelayMinutes: 5
    consolidationThreshold: 70

この構成では、GKE は 5 分後に未使用ノードを削除します。ノードは、CPU とメモリの使用率の両方が 70% 未満の場合にのみ、統合の候補になります。

アクティブな移行

アクティブな移行は、ComputeClass の自動スケーリング機能のオプションです。既存のノードが新しいノードに自動的に置き換えられます。次のタイプのアクティブな移行がサポートされています。

  • optimizeRulePriority: 優先度の低い構成を使用するノードを、優先度の高い構成を使用するノードに置き換えます。このオプションを使用すると、GKE が最初に優先度の低いノード構成で Pod を実行する必要がある場合でも、最終的には Pod が最も優先度の高いノード構成で実行されるようになります。
  • ensureAllDaemonSetPodsRunning: GKE は、スケジュールできない DaemonSet Pod を持つノードを、必要なすべての DaemonSet Pod を実行できる大規模なノードに置き換えます。このオプションを使用すると、すべての DaemonSet が最終的にノードで実行されるようになります。

アクティブな移行中、GKE は次の処理を行います。

  1. GKE は、アクティブな移行タイプの要件を満たす構成で新しいノードを作成します。
  2. GKE は既存のノードを遮断して、新しい Pod がそのノードで実行されないようにします。

  3. GKE は既存のノードをドレインし、ノードから Pod を強制的に排除します。ノードのドレイン速度には、次の要因が影響します。

    Deployment や Job などの Kubernetes コントローラは、強制排除された Pod を置き換える Pod を作成します。GKE は、これらの新しい Pod を新しいノードにスケジュールします。

  4. 既存のノードがドレインされると、GKE はノードを削除します。

次のシナリオでは、アクティブな移行は Pod とノードに影響しません。

  • アクティブな移行では、cluster-autoscaler.kubernetes.io/safe-to-evict: "false" アノテーションが設定されている Pod は強制排除されません。
  • アクティブな移行では、Pod の強制排除が PodDisruptionBudget に違反する場合、Pod は強制排除されません。
  • アクティブな移行では、削除できないノードは置き換えられません。たとえば、アクティブな移行では、--min-nodes ノードプール設定に違反する場合、ノードは置き換えられません。

ComputeClass でアクティブな移行を有効にする前に、次の影響を考慮してください。

  • アクティブな移行では、Compute Engine Persistent Disk などの永続ストレージに保存されているデータは移行されません。データ損失のリスクを最小限に抑えるため、ステートフル ワークロードが使用する ComputeClass でアクティブな移行を有効にしないでください。
  • Standard クラスタでノードプールの自動作成を使用している場合、既存のノードプールが ComputeClass で定義された条件を満たしていないと、アクティブな移行により、新しいノードプールの作成がトリガーされることがあります。
  • Hyperdisk などのゾーンリソースを含む永続ボリュームを使用するワークロードは、アクティブな移行では適切に機能しない可能性があります。一部の Hyperdisk プロダクトのゾーン制限とマシンタイプ制限により、アクティブな移行の有効性が低下する可能性があります。また、一部のステートフル ワークロードは、アクティブな移行による停止を許容しない場合があります。
  • 既存の ComputeClass を更新してアクティブな移行を有効にすると、GKE はコンピューティング リソースが利用可能になったときに既存の Pod を新しいノードに移行します。

優先度の高いノードへのアクティブな移行

optimizeRulePriority アクティブな移行タイプを使用すると、GKE は優先度の低い構成を使用する既存のノードを、優先度の高い構成を使用するノードに置き換えることができます。

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n4
  - machineFamily: c4
  activeMigration:
    optimizeRulePriority: true

この ComputeClass を使用して Pod をデプロイしたときに N4 ノードが使用できなかった場合、GKE はフォールバック オプションとして C4 ノードを使用します。割り当てが増加した場合や、ロケーションで N4 VM が利用可能になった場合など、後で N4 ノードをプロビジョニングできるようになると、次の処理が行われます。

  1. GKE は新しい N4 ノードを作成します。
  2. GKE は、既存の C4 ノードを閉鎖してドレインします。PodDisruptionBudget と停止の猶予期間の構成が考慮され、Pod が強制排除されます。
  3. Kubernetes コントローラは、強制排除された Pod を置き換える Pod を作成します。これらの新しい Pod は N4 ノードで実行されます。
  4. C4 ノードがドレインされると、GKE はノードを削除します。

同様に、priorityScore フィールドを使用して優先度ルールの明示的なスコアを設定する場合、GKE はスコアの低いノードをスコアの高いノードに置き換えます。

スケジュールできない DaemonSet Pod を実行するためのアクティブな移行

ensureAllDaemonSetPodsRunning アクティブな移行タイプを使用すると、GKE はスケジュールできない DaemonSet Pod を持つ既存のノードを、これらの DaemonSet Pod を実行できる大規模なノードに自動的に置き換えます。

たとえば、次の ComputeClass 仕様では N4 マシン ファミリーが構成されます。

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n4
  activeMigration:
    ensureAllDaemonSetPodsRunning: true

この ComputeClass を使用して 2 つの vCPU をリクエストする単一 Pod Deployment を作成したシナリオを考えてみましょう。この Pod を実行するために、GKE は n4-standard-2 ノードを作成しました。後で、2 つの vCPU をリクエストする DaemonSet を作成します。DaemonSet Pod は n4-standard-2 ノードで実行できません。このシナリオでは、GKE は次の処理を行います。

  1. GKE は、Pod と DaemonSet Pod を実行できる、より大きな N4 マシンタイプ（n4-standard-4 など）を使用するノードを作成します。保留中の DaemonSet Pod がこの新しいノードでスケジュールされます。
  2. GKE が n4-standard-2 ノードを遮断してドレインします。
  3. Pod が強制排除されると、Deployment は代替 Pod を作成します。GKE は、この Pod を n4-standard-4 ノードに DaemonSet Pod とともにスケジューリングします。
  4. n4-standard-2 ノードがドレインされると、GKE はノードを削除します。

Compute Engine の予約を使用する

GKE バージョン 1.31.1-gke.2105000 以降で利用可能

Compute Engine の容量の予約を使用して、特定のGoogle Cloud ゾーンでハードウェアの可用性をより確実に確保するために、カスタム ComputeClass で各フォールバック優先度を構成し、GKE が新しいノードを作成するときに予約を使用するようにできます。

カスタム ComputeClass を使用して Compute Engine 予約を消費するには、次の方法を使用します。

  • ノードプールの自動作成: GKE は、指定された予約を使用するために新しいノードプールを自動的に作成します。詳細については、ノードプールの自動作成と ComputeClass をご覧ください。
  • 手動で作成したノードプール: Standard モードのクラスタでは、ComputeClass で spec.priorities.nodepools フィールドを指定することで、手動で作成したノードプールにワークロードを転送できます。

手動で作成したノードプールで予約を使用する

ComputeClass を使用して Standard クラスタで手動で作成したノードプールで予約を使用する手順は次のとおりです。

  1. GKE Standard で予約済みインスタンスを使用するの手順に沿って、予約をノードプールにバインドします。

  2. nodepools 優先度ルールを使用して、手動で作成したノードプールを選択する ComputeClass を作成します。

たとえば、それぞれが個別の容量予約にリンクされている 2 つのノードプールがあるシナリオを考えてみましょう。Pod が reservation-pool-2 ノードプールではなく reservation-pool-1 ノードプールの予約済み容量を使用することを希望している。これらの設定を実装する ComputeClass は、次の例のようになります。

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: manual-pool-reservations
spec:
  priorities:
  - nodepools: ['reservation-pool-1']
  - nodepools: ['reservation-pool-2']

この例では、priorities フィールドに最初に表示される優先度ルールであるため、GKE はまず Pod を reservation-pool-1 に配置しようとします。

予約を使用するノードプールを自動作成する

ノードプールの自動作成を使用する場合は、特定の優先度ルールのノードプールを作成するために容量予約を使用するように GKE にリクエストできます。自動作成されたノードプールで予約を使用するには、次の要件を満たす必要があります。

  • ComputeClass でノードプールの自動作成を有効にする必要があります。
  • TPU 以外の予約は、machineType または machineFamily のいずれかが定義されている場合にのみ使用できます。
  • ローカル SSD を構成する ComputeClass では、machineFamily ではなく machineType 優先度ルールを使用する必要があります。詳細については、machineType ルールタイプのセクションをご覧ください。
  • ローカル SSD がアタッチされている machineType の予約を指定する ComputeClass には、localSSDCount: フィールドを明示的に含める必要があります。

次の ComputeClass 仕様の例について考えてみましょう。この仕様では、a3-highgpu-1g インスタンスのプロビジョニング時に使用する特定の共有予約を優先します。優先インスタンス タイプを使用できない場合、GKE は仕様内の一致する予約にフォールバックします。

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: accelerator-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineType: a3-highgpu-1g
    storage:
      localSSDCount: 2
    gpu:
      type: nvidia-h100-80gb
      count: 1
    reservations:
      specific:
      - name: a3-shared-reservation
        project: reservation-project
      affinity: Specific
  - machineType: a3-highgpu-1g
    storage:
      localSSDCount: 2
    gpu:
      type: nvidia-h100-80gb
      count: 1
    reservations:
      affinity: AnyBestEffort
  whenUnsatisfiable: DoNotScaleUp

accelerator-reservations ComputeClass を使用する Pod をデプロイする場合、GKE は Pod を実行する新しい a3-highgpu-1g インスタンスを作成するときに、まず a3-shared-reservation 予約の使用を試みます。この特定の予約に使用可能な容量がない場合は、GKE は一致する予約を使用して a3-highgpu-1g インスタンスをスケールアップしようとします。予約にアクセスできない場合、GKE は a3-highgpu-1g Spot VM にフォールバックします。最後に、使用可能な Spot VM がない場合、スケール オペレーションは失敗します。

この例では、a3-highgpu-1g マシンシェイプにローカル SSD が含まれているため、予約参照を含む優先度ルールの両方に localSSDCount: フィールドが明示的に必要です。

次の例は、Spot VM にフォールバックし、最終的にオンデマンド VM にフォールバックする特定の共有予約を示しています。

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: shared-specific-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineFamily: n4
    reservations:
      specific:
      - name: n4-shared-reservation
        project: reservation-project
      affinity: Specific
  - machineFamily: n4
    spot: true
  - machineFamily: n4
  whenUnsatisfiable: DoNotScaleUp

使用できる予約のタイプは次のとおりです。

  • 特定の単一プロジェクトの予約: 次のフィールドを構成します。

    • reservations.specific.name: 予約名。
    • reservations.affinity: Specific でなければなりません。

  • 特定の共有予約: 次のフィールドを構成します。

    • reservations.specific.name: 予約名。
    • reservations.specific.project: 予約を所有するプロジェクトのプロジェクト ID。
    • reservations.affinity: Specific でなければなりません。

  • 任意の一致する予約: 次のフィールドを構成します。

    • reservations.affinity: AnyBestEffort でなければなりません。
    • 予約名やプロジェクトは設定しないでください。

TPU の予約には特定のアフィニティが必要です。reservations.affinity: AnyBestEffort はサポートされていません。

GKE が予約で使用可能な容量を見つけられない場合、結果として生じる動作は、ComputeClass の優先度ルールで選択されている次のような予約のタイプによって異なります。

  • 特定の予約: GKE は、ComputeClass の次の優先度ルールを試みます。
  • 任意の一致する予約: GKE は、その優先度ルールの要件を満たすオンデマンド ノードのプロビジョニングを試みます。GKE がオンデマンド ノードをプロビジョニングできない場合、GKE は ComputeClass の次の優先度ルールを試みます。

GKE が ComputeClass の優先度ルールの要件を満たせない場合は、ルールが適用されない場合の動作が発生します。

特定の予約ブロックを消費する

GKE バージョン 1.31.4-gke.1072000 以降では、ハードウェアベースの予約内の特定の予約ブロックをターゲットにできます。この機能は、A3 Ultra マシンタイプと A4 マシンタイプで使用できます。

特定の予約ブロックを使用するには、次の例に示すように ComputeClass リソースを構成します。

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: specific-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineFamily: a3
    gpu:
      type: nvidia-h200-141gb
      count: 8
    reservations:
      specific:
      - name: a3ultra-specific-reservation
        reservationBlock:
          name: RESERVATION_BLOCK_NAME
      affinity: Specific

RESERVATION_BLOCK_NAME は、ターゲット予約ブロックの名前に置き換えます。

GKE バージョン 1.33.1-gke.1788000 以降では、予約ブロック内の特定の予約サブブロックをターゲットにできます。この機能は、A4X マシンタイプで使用できます。

特定の予約サブブロックを消費するには、特定の予約サブブロックを使用するの例に示すように ComputeClass リソースを構成します。

この機能を使用する際は、次の点にご注意ください。

  • これらの機能は、単一プロジェクトまたは共有プロジェクトの特定の予約にのみ適用されます。

ノードシステム構成をカスタマイズする

ComputeClass 仕様の nodeSystemConfig フィールドを使用して、kubelet と Linux カーネルの特定のパラメータをカスタマイズできます。このフィールドは、Compute Engine マシンシリーズまたはマシンタイプを定義する優先度ルールで指定できます。優先度ルールで省略されているノードシステム構成フィールドのデフォルトのグローバル値を設定するには、ComputeClass の priorityDefaults フィールドに nodeSystemConfig フィールドを追加します。

この機能は、GKE バージョン 1.32.1-gke.1729000 以降で使用できます。

詳しくは次のページをご覧ください。

ノードのラベルと taint を指定する

ComputeClass 仕様の nodeLabels フィールドと taints フィールドを使用すると、既存のノードプールと一致し、新しいノードプールの作成を制御する構成を定義できます。これらの構成は、ComputeClass 全体の nodePoolConfig フィールド内でグローバルに適用することも、priority フィールドを使用して特定の優先度にスコープすることもできます。ただし、優先度レベルで定義されたラベルと taint が、グローバルに設定されたラベルと taint と重複しないようにする必要があります。

これらの機能は、次の対象で利用できます。

  • GKE バージョン 1.33.2-gke.1111000 以降の優先度ノードラベル。
  • GKE バージョン 1.33.4-gke.1350000 以降の優先度テイント。
  • GKE バージョン 1.34.1-gke.3084002 以降のグローバル ノードラベルと taint。

詳細については、ComputeClass CustomResourceDefinition をご覧ください。

クラスタと名前空間のデフォルトの ComputeClass

特定の ComputeClass を選択しない Pod にデフォルトで ComputeClass を適用するように GKE を構成できます。特定の名前空間またはクラスタ全体に対してデフォルトの ComputeClass を定義できます。デフォルト クラスを使用してクラスタまたは名前空間を構成する方法については、デフォルトで ComputeClass を Pod に適用するをご覧ください。

ノードプールをグループ化する

GKE バージョン 1.32.2-gke.1359000 以降では、ComputeClass 仕様の nodePoolGroup フィールドを使用して、複数のノードプールを 1 つの論理ユニット（コレクション）にグループ化できます。このグループ化により、多くのノードプールに共有構成を適用できます。

TPU マルチホスト コレクション

GKE バージョン 1.31.2-gke.1518000 以降が必要です。TPU Trillium（v6e）でのみ使用可能

TPU マルチホスト デプロイをグループ化して、コレクション内のすべてのノードプールにサービスレベル目標（SLO）を設定できます。ノードプールをグループ化するには、nodePoolGroup フィールドにグループの名前を指定します。この ComputeClass を使用してプロビジョニングされたすべてのノードプールは、同じグループに属します。

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-multi-host-collection
spec:
  nodePoolGroup:
    name: my-tpu-collection
  ...

詳しくは以下をご覧ください。

ノードプールの構成

ComputeClass 仕様の nodePoolConfig フィールドを使用すると、そのクラスを使用して作成されたノードプール内のすべてのノードに反映される構成を適用できます。

イメージタイプを指定する

imageType フィールドを使用して、ノードプール内のノードの基本オペレーティング システムを指定できます。このフィールドでは、ノードで実行されるノードプールのイメージタイプを選択できます。このフィールドを省略した場合、デフォルト値は cos_containerd です。次の例は、ComputeClass で imageType を指定する方法を示しています。

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-node-pool-config
spec:
  nodePoolConfig:
    imageType: cos_containerd

詳細については、ノードイメージをご覧ください。

サービス アカウント

serviceAccount フィールドには、ComputeClass によって管理されるノードプール内のノードで使用される Google Cloud サービス アカウントを指定します。次の例は、ComputeClass で serviceAccount を指定する方法を示しています。

spec:
  nodePoolConfig:
    serviceAccount: my-service-account@my-project.iam.gserviceaccount.com

詳細については、GKE のサービス アカウントについてをご覧ください。

TPU SLO のワークロード タイプを定義する

GKE バージョン 1.32.2-gke.1359000 以降では、nodePoolConfig 内の workloadType フィールドを使用して、TPU ワークロードのサービスレベル目標（SLO）を定義できます。このフィールドの値は、TPU リソースの用途を GKE に伝えます。workloadType フィールドは、次の値をサポートしています。

  • HIGH_AVAILABILITY: 推論サービングなど、可用性に重点を置いたワークロードにこの値を使用すると、中断を制限して効率化できます。
  • HIGH_THROUGHPUT: 基盤となるインフラストラクチャの大部分が常に実行されている必要があるバッチジョブまたはトレーニング ジョブにこの値を使用します。この値は、nodePoolGroup も指定されている場合にのみ使用できます。

次の例では、高可用性推論ワークロード用に最適化されたマルチホスト TPU コレクションの ComputeClass を定義します。

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: multi-host-inference
spec:
  nodePoolGroup:
    name: my-inference-collection
  nodePoolConfig:
    workloadType: HIGH_AVAILABILITY
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - tpu:
      type: tpu-v6e-slice
      topology: 2x4

詳しくは次のページをご覧ください。

ワークロードで ComputeClass をリクエストする

カスタム ComputeClass を使用するには、Pod 仕様で nodeSelector を使用して、その ComputeClass を明示的にリクエストする必要があります。必要に応じて、特定の Kubernetes 名前空間のデフォルトとして ComputeClass を設定できます。その名前空間内の Pod は、別の ComputeClass をリクエストしない限り、その ComputeClass を使用します。

たとえば、次のマニフェストは cost-optimized ComputeClass をリクエストします。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: custom-workload
spec:
  replicas: 2
  selector:
    matchLabels:
      app: custom-workload
  template:
    metadata:
      labels:
        app: custom-workload
    spec:
      nodeSelector:
        cloud.google.com/compute-class: cost-optimized
      containers:
      - name: test
        image: registry.k8s.io/pause
        resources:
          requests:
            cpu: 1.5
            memory: "4Gi"

システム ノードラベルのノードセレクタ

GKE は、マシンタイプ、アタッチされたハードウェア アクセラレータ、ブートディスク タイプなどの条件でノードを識別するために、ノードにシステムラベルを追加します。これらのシステムラベルのラベルキーには、次のいずれかの接頭辞が付いています。

  • k8s.io
  • cloud.google.com
  • gke.io
  • node.kubernetes.io/instance-type

GKE バージョン 1.32.3-gke.1499000 以降では、ノードセレクタを使用してシステムラベルと ComputeClass を同時に選択するワークロードをデプロイできます。ComputeClass を選択する Pod でシステムラベルを選択する場合は、それらの Pod が想定どおりにスケジュールされていることを確認します。ComputeClass の構成と Pod のノードセレクタの間に競合があると、次のような問題が発生する可能性があります。

  • GKE は、ComputeClass の最優先構成を使用するノードを作成できません。
  • Pod は Pending ステータスのままです。

GKE は、ComputeClass 仕様に対応するフィールドがあるシステムラベルを選択する Pod も拒否します。ComputeClass を使用する場合は、ワークロードを更新して、ノードセレクタから次のラベルを削除し、作成する ComputeClass で対応するフィールドを構成します。

ノードラベル ComputeClass フィールド
cloud.google.com/machine-family priorities.machineFamily
cloud.google.com/machine-type priorities.machineType
cloud.google.com/gke-spot priorities.spot
cloud.google.com/gke-accelerator priorities.gpu.type
cloud.google.com/gke-gpu-driver-version priorities.gpu.driverVersion
cloud.google.com/reservation-name priorities.reservations.specific.name
cloud.google.com/reservation-project priorities.reservations.specific.project
cloud.google.com/reservation-affinity priorities.reservations.affinity
cloud.google.com/gke-ephemeral-storage-local-ssd priorities.storage.localSSDCount
cloud.google.com/gke-boot-disk priorities.storage.bootDiskType
cloud.google.com/gke-boot-disk-size priorities.storage.bootDiskSize
cloud.google.com/gke-node-pool-group-name nodePoolGroup.name
cloud.google.com/gke-workload-type nodePoolConfig.workloadType
node.kubernetes.io/instance-type priorities.machineType

制限事項

ComputeClass の名前を gke または autopilot で始めることはできません。

次のステップ