カスタム コンピューティング クラスについて

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

コンピューティング クラスの概要

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

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

カスタム コンピューティング クラスのメリット

カスタム コンピューティング クラスには、次のようなメリットがあります。

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

カスタム コンピューティング クラスのユースケース

次のようなシナリオでは、カスタム コンピューティング クラスの使用を検討してください。

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

カスタム コンピューティング クラスの仕組み

カスタム コンピューティング クラスは、Google Cloud インフラストラクチャをプロビジョニングする Kubernetes カスタム リソースです。クラスタで ComputeClass オブジェクトを定義し、ワークロードでそのコンピューティング クラスをリクエストするか、そのコンピューティング クラスを Kubernetes Namespace のデフォルトとして設定します。コンピューティング クラスをリクエストするワークロードをデプロイすると、GKE はコンピューティング クラスの要件を満たすノードに Pod を配置しようとします。

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

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

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

ComputeClass カスタム リソースの完全なカスタム リソース定義（CRD）を表示するには、次のコマンドを実行します。

kubectl describe crd computeclasses.cloud.google.com

出力には、サポートされているすべてのフィールドとフィールド間の関係を含む CRD 全体が表示されます。カスタム コンピューティング クラスをより深く理解するため、このドキュメントを読む際には、この定義を参照してください。

カスタム コンピューティング クラスを計画する

クラスタでカスタム コンピューティング クラスを効果的に計画、デプロイ、使用するには、次の操作を行います。

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

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

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

フォールバック戦略は、カスタム コンピューティング クラスで優先度ルールのリストを定義して作成します。クラスタをスケールアップする必要がある場合、GKE は最初の優先度ルールに一致するノードの作成を優先します。GKE がこれらのノードを作成できない場合は、次の優先度ルールにフォールバックします。GKE がクラスタを正常にスケールアップするか、適用可能なルールがなくなるまで、このプロセスが繰り返されます。適用可能なルールがなくなると、GKE は、優先度ルールが適用されない場合のスケーリング動作を定義するで説明されているデフォルトの動作または指定された動作に基づいてノードを作成します。

優先度ルール

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

優先度ルールのタイプに応じて、ノードをプロビジョニングするときに GKE が使用する追加のマシン プロパティ（Spot VM や最小 CPU 容量など）を指定できます。priorities フィールドは、次の優先度ルールのタイプをサポートしています。

• machineFamily: n2 や c3 などの Compute Engine マシンシリーズを使用してノードを定義します。
• machineType: n2-standard-4 などの事前定義された Compute Engine マシンタイプを使用してノードを定義します。
• nodepools: GKE Standard クラスタで、GKE がノードをプロビジョニングするコンピューティング クラスに関連付けられている、手動作成のノードプールのリストを提供します。

machineFamily ルールタイプ

machineFamily フィールドには、n2 や c3 などの Compute Engine マシンシリーズを指定します。指定しない場合は、デフォルトの e2 が使用されます。machineFamily ルールタイプとともに、次のフィールドを使用できます。

• spot: Spot VM。デフォルト値は false です。
• minCores: ノードあたりの最小 vCPU。デフォルト値は 0 です。
• minMemoryGb: ノードあたりの最小メモリ。デフォルト値は 0 です。
• storage.bootDiskKMSKey: ブートディスクの暗号化に使用する Cloud Key Management Service 鍵のパス。

次の例は、machineFamily 優先度ルールを示しています。

priorities:
- machineFamily: n2
  spot: true
  minCores: 16
  minMemoryGb: 64
  storage:
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1

machineType ルールタイプ

machineType フィールドには、Compute Engine の事前定義されたマシンタイプを指定します（n2-standard-32 など）。マシンタイプは、指定した GPU をサポートしている必要があります。

machineType ルールタイプとともに、次のフィールドを使用できます。

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

次の例は、n2-standard-32 マシンタイプの machineType ルールを示しています。

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

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

priorities:
- machineType: g2-standard-16
  spot: false
  gpu:
    type: nvidia-l4
    count: 1

nodepools ルールタイプ

nodepools フィールドには、GKE が保留中の Pod の作成を試みる既存のノードプールのリストを指定します。GKE は、このフィールドの値を順番に処理しません。同じ優先度ルールの項目で、このフィールドとともに他のマシン プロパティを指定することはできません。このフィールドは、GKE Standard モードでのみサポートされます。使用方法の詳細については、コンピューティング クラス定義で特定のノードプールをターゲットに設定するをご覧ください。

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

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

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

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

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

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

GKE Standard ノードプールとコンピューティング クラス

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

• ノードの自動プロビジョニングによって管理されるノードプール: 手動構成は必要ありません。ノードの自動プロビジョニングでは、コンピューティング クラスの構成手順が自動的に実行されます。詳細については、ノードの自動プロビジョニングとコンピューティング クラスをご覧ください。
• 手動で作成したノードプール: 手動での構成が必要です。手動で作成したノードプールにノードラベルとノード taint を追加し、ノードを特定のコンピューティング クラスに関連付ける必要があります。詳細については、コンピューティング クラスで使用するために手動で作成したノードプールを構成するをご覧ください。

コンピューティング クラスで使用するために手動で作成したノードプールを構成する

GKE Standard クラスタに、ノードの自動プロビジョニングなしで手動で作成したノードプールがある場合は、特定のコンピューティング クラスに関連付けるように、これらのノードプールを構成する必要があります。GKE は、特定のコンピューティング クラスをリクエストする Pod のみを、そのコンピューティング クラスに関連付けられたノードプールのノードでスケジューリングします。ノードの自動プロビジョニングによって作成された GKE Autopilot モードと GKE Standard モードのノードプールは、この構成を自動的に実行します。

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

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

これらの属性で、COMPUTE_CLASS はカスタム コンピューティング クラスの名前です。

たとえば、次のコマンドは既存のノードプールを更新し、dev-class コンピューティング クラスに関連付けます。

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

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

ノードの自動プロビジョニングとコンピューティング クラス

カスタム コンピューティング クラスでノードの自動プロビジョニングを使用すると、優先度ルールに基づいてノードプールを自動的に作成および削除できます。

コンピューティング クラスでノードの自動プロビジョニングを使用するには、次の操作を行う必要があります。

1. クラスタでノードの自動プロビジョニングが有効になっていることを確認します。
2. enabled: true 値を持つ nodePoolAutoCreation フィールドを ComputeClass 仕様に追加します。

これにより、GKE は、ノードの自動プロビジョニングを構成するコンピューティング クラスを使用する Pod を新しいノードプールに配置します。GKE は、クラスタのサイズや Pod の要件などの要素に基づいて、既存のノードプールをスケールアップするか、新しいノードプールを作成するかを決定します。ノードの自動プロビジョニングを構成していないコンピューティング クラスを持つ Pod は、引き続き既存のノードプールのみをスケールアップします。

ノードの自動プロビジョニングとやり取りするコンピューティング クラスと、同じクラスタ内の手動で作成されたノードプールとやり取りするコンピューティング クラスを併用できます。

ノードの自動プロビジョニングとの次のやり取りを検討してください。

• マシン ファミリーまたは Spot VM ノードセレクタは、コンピューティング クラスの動作と競合するため使用できません。GKE は、コンピューティング クラスをリクエストし、Spot VM または特定のマシンシリーズもリクエストする Pod を拒否します。
• nodepools フィールドを使用して既存のノードプールを参照するコンピューティング クラスにノードの自動プロビジョニングを構成できます。ノードの自動プロビジョニングは、優先度順に処理し、既存のノードプールをスケールして Pod を配置しようとします。

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

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

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

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

コンピューティング クラスの定義で特定のノードプールをターゲットにする

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

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

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

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

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

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

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

• ScaleUpAnyway: クラスタのデフォルトのマシン構成を使用する新しいノードを作成します。これはデフォルトの動作です。
  • Autopilot クラスタでは、GKE はノードのマシン構成に関係なく、新しいノードまたは既存のノードに Pod を配置します。
  • ノードの自動プロビジョニングを使用しない Standard クラスタの場合、GKE は、特定のコンピューティング クラスに一致するラベルと taint が定義された手動作成のノードプールをスケールアップしようとします。
  • ノードの自動プロビジョニングを使用する Standard クラスタの場合、GKE が新しいノードプールを作成し、デフォルトの E2 マシンシリーズを使用して Pod を配置することがあります。
• DoNotScaleUp: コンピューティング クラスの要件を満たすノードが使用可能になるまで、Pod を Pending ステータスにします。

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

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

ノードの削除のタイミングと基準は、自動スケーリング プロファイルによって異なります。カスタム コンピューティング クラスの定義で 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: n2
  - machineFamily: n2d
  autoscalingPolicy:
    consolidationDelayMinutes: 5
    consolidationThreshold: 70

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

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

アクティブな移行は、カスタム コンピューティング クラスの自動スケーリング機能のオプションです。コンピューティング クラスのフォールバック優先度リストで優先度が低い既存のノードは、フォールバック優先度リストで優先度が高い新しいノードに自動的に置き換えられます。これにより、GKE が最初にそれらの Pod を優先度の低いノードで実行する必要がある場合でも、最終的には、実行中のすべての Pod がそのコンピューティング クラスの最も優先度の高いノードで実行されます。

アクティブな移行が発生すると、GKE はコンピューティング クラスの優先度ルールに基づいて新しいノードを作成し、優先度の低い古いノードをドレインして削除します。ワークロードの中断を最小限に抑えるため、移行は段階的に行われます。アクティブな移行には次の考慮事項があります。

• Standard クラスタでノードの自動プロビジョニングを有効にしている場合、既存のノードプールがカスタム コンピューティング クラスで定義された優先度の高い条件を満たしていないと、アクティブな移行により、新しいノードプールの作成がトリガーされることがあります。
• 重要なワークロードの中断を回避するため、アクティブな移行では次の Pod は移行されません。
  • PodDisruptionBudget を設定している Pod（移行により PodDisruptionBudget を超える場合）。
  • cluster-autoscaler.kubernetes.io/safe-to-evict: "false" アノテーションが設定されている Pod。

N2D ノードよりも N2 ノードを優先するコンピューティング クラス仕様の例について考えてみましょう。

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

このコンピューティング クラスを使用して Pod をデプロイしたときに N2 ノードが使用できなかった場合、GKE はフォールバック オプションとして N2D ノードを使用します。割り当てが増加した場合や、ロケーションで N2 VM が利用可能になった場合など、後で N2 ノードをプロビジョニングできるようになると、GKE は新しい N2 ノードを作成し、既存の N2D ノードから新しい N2 ノードに Pod を段階的に移行します。その後、GKE は古い N2D ノードを削除します。

Compute Engine の予約を使用する

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

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

カスタム コンピューティング クラスで予約を使用するには、次の要件があります。

• Standard モードのクラスタで GKE が予約を使用して新しいノードを作成するには、ノードの自動プロビジョニングを使用する必要があります。詳細については、ノードの自動プロビジョニングとコンピューティング クラスのセクションをご覧ください。クラスタでノードプールを手動で作成する場合でも、予約を引き続き使用できます。
• ローカル SSD を構成するコンピューティング クラスでは、machineFamily ではなく machineType 優先度ルールを使用する必要があります。詳細については、machineType ルールタイプのセクションをご覧ください。

次のコンピューティング クラス仕様の例では、ノードに n2 インスタンスをプロビジョニングするときに使用する特定の共有予約を選択します。

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

shared-specific-reservations コンピューティング クラスを使用する Pod をデプロイすると、GKE は Pod を実行する新しい n2 インスタンスを作成するときに n2-shared-reservation 予約の使用を試みます。予約に使用可能な容量がない場合は、スケールアップ オペレーションは失敗します。

使用できる予約の種類は次のとおりです。

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

  • reservations.specific.name: 予約名。
  • reservations.affinity: Specific にする必要があります。

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

  • reservations.specific.name: 予約名。
  • reservations.specific.project: 予約を所有するプロジェクトのプロジェクト ID。
  • reservations.affinity: Specific にする必要があります。

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

  • reservations.affinity: AnyBestEffort にする必要があります。
  • 予約名やプロジェクトは設定しないでください。

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

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

GKE がコンピューティング クラスの優先度ルールの要件を満たせない場合は、ルールが適用されない場合の動作が発生します。

ワークロードでコンピューティング クラスをリクエストする

カスタム コンピューティング クラスの設計が完了したら、Pod 仕様でそのコンピューティング クラスを明示的にリクエストする必要があります。特定の Kubernetes Namespace でコンピューティング クラスをデフォルトとして設定することもできます。この場合、Pod が別のコンピューティング クラスをリクエストしない限り、その Namespace 内の Pod は設定したコンピューティング クラスを使用します。

GKE でコンピューティング クラスをリクエストして使用する手順については、カスタム コンピューティング クラスを使用して自動スケーリングされたノード属性を制御するをご覧ください。

次のステップ

• GKE Autopilot の他のワークロードのデプロイに関する推奨事項について学習する