カスタム 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 Namespace のデフォルトとして設定します。一致するワークロードで新しいインフラストラクチャが要求されると、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 で優先度ルールのリストを定義して作成します。クラスタをスケールアップする必要がある場合、GKE は最初の優先度ルールに一致するノードの作成を優先します。GKE がこれらのノードを作成できない場合は、次の優先度ルールにフォールバックします。GKE がクラスタを正常にスケールアップするか、適用可能なルールがなくなるまで、このプロセスが繰り返されます。適用可能なルールがなくなると、GKE は、優先度ルールが適用されない場合のスケーリング動作を定義するで説明されているデフォルトの動作または指定された動作に基づいてノードを作成します。

さまざまな Compute Engine マシンシリーズは、さまざまなテクノロジーと機能をサポートしています。マシンシリーズの以前の世代では、新しい世代と同じストレージ タイプがサポートされていない場合があります。永続データに依存するステートフル ワークロードを実行する場合は、マシンシリーズの複数の世代にまたがる ComputeClass を使用しないでください。ワークロードは、GKE によりそのストレージ タイプをサポートしていないマシンタイプに配置されると、永続データにアクセスできない可能性があります。詳細については、特定のストレージ タイプでマシンシリーズの比較表をフィルタします。

優先度ルール

優先度ルールは、ComputeClass カスタム リソースの spec.priorities フィールドで定義します。priorities フィールドの各ルールには、プロビジョニングするノードのプロパティを記述します。GKE は priorities フィールドを順番に処理します。つまり、フィールド内の最初の項目がノード プロビジョニングの優先度が最も高くなります。

優先度ルールには次の 2 種類があります。

  • 宣言型ルールタイプ: ノードの特性を使用して、プロビジョニングするノードを記述します。

  • ノードプール ルールタイプ: GKE Standard クラスタで、GKE がノードをプロビジョニングする ComputeClass に関連付けられている、手動作成のノードプールのリストを提供します。

宣言型の優先度ルール

宣言型の優先度ルールを使用すると、ノードのプロビジョニング時に GKE が使用するマシン プロパティ（マシン ファミリーやタイプ、Spot VM、アクセラレータ オプション、ストレージ オプション、予約、最小リソース要件など）を指定できます。サポートされているフィールドの一覧については、ComputeClass CRD リファレンスをご覧ください。

machineFamily 構成

machineFamily フィールドには、n4 や c4 などの Compute Engine マシンシリーズを指定します。指定しない場合は、デフォルトの e2 が使用されます。

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

  • spot: Spot VM。デフォルト値は false です。
  • minCores: ノードあたりの最小 vCPU。デフォルト値は 0 です。
  • minMemoryGb: ノードあたりの最小メモリ。デフォルト値は 0 です。
  • 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:
    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: pd-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 の予約を使用するをご覧ください。

次の例は、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 ワークロードでは次の操作を行えます。

アクセラレータとマシンシェイプの仕様

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

ノードプールの優先度ルール

nodepools フィールドには、GKE が保留中の Pod の作成を試みる既存のノードプールのリストを指定します。GKE は、このフィールドの値を順番に処理しません。nodepools フィールドを含むルールは宣言型ではないため、同じ優先度ルールの項目で nodepools フィールドとともに他の spec.priorities フィールドを使用することはできません。このフィールドは、GKE Standard モードでのみサポートされます。使用方法の詳細については、ComputeClass 定義で特定のノードプールをターゲットに設定するをご覧ください。

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

ComputeClass をリクエストするワークロードをデプロイして、新しいノードが必要になると、GKE は ComputeClass 仕様の priorities フィールドのルールリストを順番に処理します。

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

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 の構成手順が自動的に実行されます。詳細については、ノード自動プロビジョニングと ComputeClass をご覧ください。
  • 手動で作成したノードプール: 手動での構成が必要です。手動で作成したノードプールにノードラベルとノード taint を追加し、ノードを特定の ComputeClass に関連付ける必要があります。詳細については、ComputeClass で使用するために手動で作成したノードプールを構成するをご覧ください。

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 でノード自動プロビジョニングを使用すると、優先度ルールに基づいてノードプールを自動的に作成および削除できます。

ComputeClass でノード自動プロビジョニングを使用するには、次の操作を行う必要があります。

  1. enabled: true 値を持つ nodePoolAutoCreation フィールドを ComputeClass 仕様に追加します。
  2. クラスタが Rapid チャンネルに登録されていて、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 にノード自動プロビジョニングを構成できます。ノード自動プロビジョニングは、優先度順に処理し、既存のノードプールをスケールして 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 の自動スケーリング機能のオプションです。既存のノードが新しいノードに自動的に置き換えられます。移行のタイプに応じて、特定の条件に基づいてノードが置き換えられます。

アクティブな移行が発生すると、GKE は新しいノードを作成し、古いノードをドレインして削除します。ワークロードの停止を最小限に抑えるため、移行は段階的に行われます。アクティブな移行には次の考慮事項があります。

  • アクティブな移行では、Compute Engine Persistent Disk などの永続ストレージに保存されているデータは移行されません。データ損失のリスクを最小限に抑えるため、ステートフル ワークロードが使用する ComputeClass でアクティブな移行を有効にしないでください。
  • Standard クラスタでノード自動プロビジョニングを有効にしている場合、既存のノードプールがカスタム ComputeClass で定義された優先度の高い条件を満たしていないと、アクティブな移行により、新しいノードプールの作成がトリガーされることがあります。
  • アクティブな移行では、削除できないノードは置き換えられません。たとえば、アクティブな移行では、--min-nodes ノードプール設定に違反する場合、ノードは置き換えられません。
  • 重要なワークロードの中断を回避するため、アクティブな移行では次の Pod は移行されません。
    • PodDisruptionBudget を設定している Pod（移行により PodDisruptionBudget を超える場合）。
    • cluster-autoscaler.kubernetes.io/safe-to-evict: "false" アノテーションが設定されている Pod。
  • Hyperdisk などのゾーンリソースを含む永続ボリュームを使用するワークロードは、アクティブな移行では適切に機能しない可能性があります。一部の Hyperdisk プロダクトのゾーン制限とマシンタイプ制限により、アクティブな移行の有効性が低下する可能性があります。また、一部のステートフル ワークロードは、アクティブな移行による停止を許容しない場合があります。
  • 既存の ComputeClass を更新してアクティブな移行を有効にすると、GKE は既存の Pod を新しいノードに移行します。

次のタイプのアクティブな移行がサポートされています。

優先度の高いノードへのアクティブな移行を構成する

アクティブな移行を構成して、ComputeClass フォールバック優先度リスト内の優先度が低い既存のノードを、優先度リスト内の優先度が高い新しいノードに置き換えることが可能です。これにより、GKE が最初にそれらの Pod を優先度の低いノードで実行する必要がある場合でも、最終的には、実行中のすべての Pod がその ComputeClass の最も優先度の高いノードで実行されます。

次の ComputeClass 仕様の例について考えてみましょう。この仕様では、C4 ノードよりも N4 ノードを優先します。

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 ノードをプロビジョニングできるようになると、GKE は新しい N4 ノードを作成し、既存の C4 ノードから新しい N4 ノードに Pod を段階的に移行します。その後、GKE は古い C4 ノードを削除します。

スケジュールできない DaemonSet Pod を実行するようにアクティブな移行を構成する

アクティブな移行を構成して、スケジュールできない DaemonSet Pod を持つ既存のノードを、必要なすべての DaemonSet Pod を実行できる大規模なノードに自動的に置き換えることが可能です。

次の ComputeClass 仕様の例について考えてみましょう。

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

たとえば、この ComputeClass を使用して Pod をデプロイしたことで n1-standard-2 マシンがスケールアップされ、その後 2 つの CPU をリクエストする DaemonSet をデプロイした場合、アクティブな移行では、n1-standard-2 ノードが同じ n1 マシン ファミリーのより大規模なノード（n1-standard-4 など）に置き換えられ、すべての Pod に十分なスペースが作成されます。

Compute Engine の予約を消費する

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

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

カスタム ComputeClass で予約を使用するには、次の要件があります。

  • Standard モードのクラスタで 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 マシンシリーズまたはマシンタイプを定義する優先度ルールで指定できます。優先度ルールで省略されているノードシステム構成フィールドのデフォルトのグローバル値を設定するには、コンピューティング クラスの priorityDefaults フィールドに nodeSystemConfig フィールドを追加します。

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

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

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

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

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

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

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

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 Namespace のデフォルトとして 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: gcr.io/google_containers/pause
        resources:
          requests:
            cpu: 1.5
            memory: "4Gi"

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

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

  • k8s.io
  • cloud.google.com
  • gke.io

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

次のステップ