このページは Cloud Translation API によって翻訳されました。

ノードプールの自動作成について

Standard

Google Kubernetes Engine（GKE）は、ワークロードの構成に基づいてクラスタ内のノードプールを自動的に作成して管理できます。このドキュメントでは、ノードプールの自動作成の仕組み、スケーリングパラメータとデフォルトの動作について説明し、スケーラビリティの向上に役立つ推奨事項を示します。このドキュメントは、Standard モードのクラスタで手動のインフラストラクチャ管理に関連するコストを削減したいクラスタ管理者を対象としています。

次のコンセプトに精通している必要があります。

Autopilot モードでは、GKE はワークロードに基づいてノードとノードプールを常に作成して管理します。Autopilot クラスタまたは Standard クラスタの Autopilot ワークロードに対して、ノードプールの自動作成を手動で構成する必要はありません。詳細については、GKE Autopilot の概要をご覧ください。

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

GKE では、ノードプールはノードの論理グループです。ノードプール内のすべてのノードは、そのノードプール内の他のすべてのノードと同じ構成になります。ノードプールの自動作成は、GKE がワークロードの要件を満たす新しいノードプールをクラスタに作成できるようにするインフラストラクチャの自動スケーリングメカニズムです。GKE は、これらの自動作成されたノードプールを管理し、ノードメタデータの更新、ノードプール内のノードの作成と削除、不要になったノードプール全体の削除などのタスクを実行します。ノードプールの自動作成は、個々のノードプール内のノードを自動的にスケーリングする GKE クラスタオートスケーラーの拡張機能です。

ノードプールの自動作成は、GKE がクラスタから空のノードプールを自動的にスケールダウンして削除できるように設計されています。自動作成されたすべてのノードプールに設定する必要がある最小ノード数を設定することはできません。最小数が 0 より大きいと、空のノードプールを削除できなくなるためです。ユースケースで、クラスタで常に実行される最小数のノードが必要な場合は、自動スケーリングが有効になっているノードプールを手動で作成します。

仕組み

ノードプールの自動作成により、GKE クラスタオートスケーラーが拡張され、保留中の Pod のハードウェア要件とリソースリクエストを満たす新しいノードプールを GKE がプロビジョニングできるようになります。ハードウェア要件は次の方法で定義できます。

ComputeClasses を使用します。これは、ノードセレクタを使用してさまざまな Pod で選択します。この方法をおすすめするのは、複数のワークロードで使用できる共通のノード構成を一元的に定義できるためです。
ノードセレクタまたはノードアフィニティを使用して、Pod 仕様で特定の GKE ノードラベルをリクエストします。

GKE は、次のようなパラメータに基づいて新しいノードプールを構成します。

Pod とコンテナの CPU、メモリ、エフェメラルストレージのリソースリクエスト。DaemonSet によって管理される Pod も含まれます。
Pod 仕様または ComputeClass の GPU リクエストと TPU リクエスト。
保留中の Pod の仕様または ComputeClass のマシンタイプやブートディスクタイプなどのハードウェア要件。
一致するノードセレクタを持つ保留中の Pod の仕様の Toleration。

GKE は、自動作成されたノードプールの各ノードのリソース容量を、保留中の Pod のリソースリクエスト以上になるように構成します。Pod が想定どおりに機能するのに十分な大きさのリソースリクエストを確保する必要があります。Pod リクエストが小さすぎると、GKE が自動作成されたノードに Pod をスケジュールした後、Pod は想定どおりに実行されません。

ノードメタデータの構成

GKE は、次の例のように、ワークロードの要件に基づいてノードメタデータ（ラベル、アノテーション、ノード taint など）も構成します。

N2 マシンシリーズをリクエストすると、GKE は各ノードに cloud.google.com/machine-family: n2 ノードラベルを追加します。
Pod で ComputeClass を選択すると、GKE は cloud.google.com/compute-class キーがその ComputeClass の名前に設定されたノードラベルを追加します。
Pod に同じノードラベルの容認値とノードセレクタの両方がある場合、GKE はこれらの容認値のノード taint を自動作成されたノードに追加します。

自動作成されたノードプールの削除

ノードプールの自動作成により、クラスタオートスケーラーは新しいノードプールとノードを作成して、保留中の Pod を実行できます。自動作成されたノードプール内の Pod の数が減少すると、クラスタオートスケーラーはノードプールを徐々にスケールダウンします。可能であれば、GKE はノードプール内の使用率の低いノードをドレインし、Pod を他のノードに統合して、空のノードを削除します。

自動作成されたノードプール内のノード数がゼロの場合、GKE はそのノードプールを削除します。GKE は、手動で作成したノードプールなど、ノードプールの自動作成から除外したノードプールを削除しません。クラスタオートスケーラーがノードプールをスケールダウンする方法については、クラスタオートスケーラーの仕組みをご覧ください。

GKE のスケーリング設定

GKE がインフラストラクチャを自動スケーリングするときには、次の設定が適用されます。

コンピューティングリソースの無駄を削減する: GKE は、クラスタ内の既存の自動作成ノードプールのリソース容量を使用して、新しいノードプールに使用するマシンタイプを決定します。クラスタのサイズが大きくなると、GKE は新しいノードプールに大きいマシンタイプを使用することを優先します。これにより、ノードプールの各ノードでより多くの Pod を実行できます。
スケーラビリティとレイテンシを最適化する: GKE は、新しいノードプールを作成するのではなく、既存の互換性のあるノードプールのスケールアップを常に優先します。この優先設定の強度は、クラスタ内の個別のノードプールの数が増えるにつれて高くなります。個別のノードプールの数が最適なレイテンシとスケーラビリティのサポート上限に近づくと、GKE は新しいノードプールの作成の優先度を下げます。

これらの優先度により、次のシナリオ例のように、クラスタで効率的なコンピューティングリソースの使用を大規模に確保できます。

ノードプールの数が少なく、リソース使用量が少ないクラスタでは、GKE は新しいノードプールをより頻繁に作成し、これらのノードプールに小規模なマシンタイプを使用します。
ノードプールの数が多いクラスタでは、リソース使用率が高くなります。GKE は、新しいノードプールを作成する頻度を減らし、これらのノードプールに大きなマシンタイプを使用します。これにより、Pod のスケジューリングを継続しながら、クラスタのスケーラビリティとレイテンシの制限に向けた進行を遅らせることができます。

GKE が自動作成されたノードプールに使用するインスタンスの最小サイズは、priorities.machineFamily フィールドと priorities.minCores フィールドまたは priorities.minMemoryGb フィールドのいずれかを含む ComputeClass を使用して手動で制御できます。

ノードプールの自動作成の有効化方法

クラスタの構成方法に応じて、GKE は特定の ComputeClass または互換性のある構成を使用するワークロードのノードプールを自動的に作成できます。

有効化方法
ワークロードレベル（推奨）	GKE バージョン 1.33.3-gke.1136000 以降では、ComputeClass を使用して、クラスタレベルのノード自動プロビジョニングを使用せずにノードプールの自動作成を有効にします。GKE は、自動作成が有効になっている特定の ComputeClass を選択するワークロードに対してのみ、新しいノードプールを作成します。クラスタ内の既存のワークロードは影響を受けません。 1.33.3-gke.1136000 より前の GKE バージョンでも、ComputeClass はワークロードのインフラストラクチャをリクエストして構成する推奨の方法です。ComputeClass は独自の機能を提供し、クラスタ内のスケーリングを柔軟に最適化する方法を提供します。詳細については、カスタム ComputeClass についてをご覧ください。
クラスタレベル	クラスタ全体のノード自動プロビジョニングを有効にします。クラスタ内の CPU やメモリなどのリソースの上限を設定する必要があります。これらの上限はクラスタ全体に適用されます。1.33.3-gke.1136000 より前の GKE バージョンでノードプールの自動作成を有効にするには、クラスタレベルの構成が必要です。 GKE は、Pod 仕様の ComputeClass またはセレクタを使用して、クラスタ内の保留中のワークロード用に新しいノードプールを作成できます。

有効化方法

ワークロードレベル（推奨）

GKE バージョン 1.33.3-gke.1136000 以降では、ComputeClass を使用して、クラスタレベルのノード自動プロビジョニングを使用せずにノードプールの自動作成を有効にします。GKE は、自動作成が有効になっている特定の ComputeClass を選択するワークロードに対してのみ、新しいノードプールを作成します。クラスタ内の既存のワークロードは影響を受けません。

1.33.3-gke.1136000 より前の GKE バージョンでも、ComputeClass はワークロードのインフラストラクチャをリクエストして構成する推奨の方法です。ComputeClass は独自の機能を提供し、クラスタ内のスケーリングを柔軟に最適化する方法を提供します。詳細については、カスタム ComputeClass についてをご覧ください。

クラスタレベル

クラスタ全体のノード自動プロビジョニングを有効にします。クラスタ内の CPU やメモリなどのリソースの上限を設定する必要があります。これらの上限はクラスタ全体に適用されます。1.33.3-gke.1136000 より前の GKE バージョンでノードプールの自動作成を有効にするには、クラスタレベルの構成が必要です。

GKE は、Pod 仕様の ComputeClass またはセレクタを使用して、クラスタ内の保留中のワークロード用に新しいノードプールを作成できます。

これらの構成方法は相互に排他的ではありません。ComputeClass を使用して、ノード自動プロビジョニングを使用するクラスタでノードプールを自動作成できます。これらの両方の方法を使用してクラスタでノードプールの自動作成を有効にした場合、GKE は次の優先順位で、ノードプールに使用する構成設定の値を見つけます。

ComputeClass または Pod 仕様: ComputeClass または Pod 仕様で設定（マシンタイプなど）を指定すると、GKE はその設定を使用します。
クラスタレベルのノード自動プロビジョニングのデフォルト: ComputeClass または Pod 仕様で設定が指定されていない場合、GKE はクラスタでノード自動プロビジョニングのデフォルト値を設定したかどうかを確認します。クラスタレベルのデフォルト値が存在する場合、GKE はその値を使用します。
クラスタレベルのデフォルト: ComputeClasses、Pod 仕様、またはクラスタレベルのノード自動プロビジョニングのデフォルト値として設定が指定されていない場合、GKE は Google Cloud がクラスタに設定したデフォルト値を使用します。

たとえば、GKE が自動作成されたノードプールで使用するマシンタイプを検索しようとするシナリオを考えてみましょう。上記の優先順位は次のように適用されます。

GKE は、Pod 仕様または Pod の ComputeClass でマシンタイプが指定されているかどうかを確認します。
Pod 仕様または ComputeClass でマシンタイプが指定されていない場合、GKE はクラスタでノードの自動プロビジョニングのデフォルトのマシンタイプが設定されているかどうかを確認します。
ノード自動プロビジョニングのデフォルトのマシンタイプを設定していない場合、GKE はクラスタのデフォルトのマシンタイプを使用します。

ほとんどの場合、ComputeClass の有効化方法のみを使用することをおすすめします。以降のセクションでは、これらの各構成方法について、制限事項や考慮事項を含めて詳しく説明します。

ComputeClass を使用したワークロードレベルでの有効化

クラスタ内の任意の ComputeClass でノードプールの自動作成を有効にするには、ComputeClass 仕様で次のいずれかのフィールドを使用します。

nodePoolAutoCreation: 必要に応じて GKE がノードプールを自動作成できるようにします。ノードプールは引き続き操作できます。GKE は、構成した設定または制約のみを実装します。
autopilot: この ComputeClass を選択するワークロードを Autopilot モードで実行します。Autopilot クラスタと同様に、GKE はノードを完全に管理し、さまざまな Autopilot の制約と設定を実装します。autopilot フィールドを使用する場合は、このドキュメントをスキップできます。詳細については、Standard での Autopilot モードのワークロードについてをご覧ください。

次の要件を満たすクラスタでは、クラスタレベルでノード自動プロビジョニングを有効にせずに、ComputeClass でこれらのフィールドを使用できます。

GKE バージョン 1.33.3-gke.1136000 以降を使用します。
Rapid リリースチャンネルに登録されている。

クラスタのノード自動プロビジョニングを有効にせずに ComputeClass でノードプールの自動作成を構成すると、GKE は ComputeClass を使用するワークロードに対してのみ新しいノードプールを作成します。他のワークロードには影響しません。

次の ComputeClass マニフェストの例では、ComputeClass を使用する Pod のノードプールの自動作成を有効にしています。

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: example-computeclass
spec:
  priorities:
  - machineFamily: n4
  - machineFamily: c4
  whenUnsatisfiable: ScaleUpAnyway
  nodePoolAutoCreation:
    enabled: true

ノードの自動プロビジョニングによるクラスタレベルでの有効化

クラスタ全体でノードプールの自動作成を有効にするには、Google Kubernetes Engine API を使用して、クラスタのノードの自動プロビジョニング機能を有効にします。ノード自動プロビジョニングを使用すると、GKE は Pod 仕様または ComputeClass 構成に基づいて、クラスタ内のワークロードに必要な新しいノードプールを作成できます。GKE はクラスタ内の既存のノードプールを管理しませんが、クラスタでノード自動プロビジョニングを有効にした後、個々のノードプールを自動プロビジョニングとしてマークできます。

次のような状況では、ノードの自動プロビジョニングを有効にします。

1.33.3-gke.1136000 より前の GKE バージョンを実行するクラスタで、GKE がノードプールを自動的に作成するようにします。
クラスタ全体のリソース上限を手動で設定する。1.33.3-gke.1136000 より前の GKE バージョンでは、ComputeClass を使用する場合でも、クラスタ全体のリソース上限を設定する必要があります。

注意: 大規模な環境では、これらの明示的なリソース上限により Pod がスタックする可能性があります。割り当ての調整などの別の方法を使用して、リソース使用量を制御します。
ComputeClass でサポートされていない特定の機能または構成を使用する。
クラスタ全体のデフォルトのノード構成値を設定する。

ノードの自動プロビジョニングを有効にしたら、Google Cloud CLI または YAML 構成ファイルを使用して、さまざまなノード設定のデフォルト値を構成できます。

ノードの自動プロビジョニングを使用したクラスタレベルのリソース上限

クラスタ全体でノードの自動プロビジョニングを有効にする場合は、クラスタ内の CPU、メモリ、GPU、TPU などのリソースの上限も構成する必要があります。これらの上限は、クラスタ内のすべてのリソース容量の合計に適用されます。これには、手動で作成したノードプールと ComputeClass が含まれます。オペレーションがこれらのリソース上限のいずれかを超える場合、GKE は新しいノードまたはノードプールを作成しません。

これらのクラスタレベルのリソース上限は、クラスタでノード自動プロビジョニングを有効にする場合にのみ必要です。次の要件を満たすクラスタでは、ノード自動プロビジョニングを有効にせずに、ComputeClass でノードプール自動作成を使用できます。

GKE バージョン 1.33.3-gke.1136000 以降を使用します。
Rapid リリースチャンネルに登録されている。

クラスタがこれらの要件を満たしている場合は、ComputeClass のみを使用して自動作成されたノードプールを構成することをおすすめします。

自動作成されたノードプールのデフォルト設定

GKE が自動作成されたノードプールに適用するデフォルト値は、ワークロードレベルまたはクラスタレベルで指定できます。

ワークロードレベルのデフォルト設定: ComputeClass 仕様の spec.nodePoolConfig フィールドと spec.priorityDefaults フィールドを使用して、特定のノード設定のデフォルト値を設定できます。これらのデフォルト値は、GKE がその ComputeClass に作成するノードプールにのみ適用されます。
クラスタレベルのデフォルト設定: ノードの自動プロビジョニングを構成するときに、自動作成されたノードプールのデフォルト値を設定できます。デフォルト値を指定するには、gcloud CLI または YAML 構成ファイルを使用します。

デフォルトを設定するこれらの方法は相互に排他的ではありません。ComputeClass とクラスタ全体で特定の設定のデフォルト値を構成した場合、GKE は ComputeClass の値を使用します。ComputeClass でその設定の値が指定されていない場合、GKE は代わりにクラスタレベルのデフォルト値を使用します。

構成ファイルを使用したクラスタレベルのデフォルト設定

ノード自動プロビジョニングを有効にすると、YAML 構成ファイルを使用して、自動作成されたノードプールのクラスタ全体のデフォルト設定を指定できます。1 つの構成ファイルで複数の設定を指定できます。一部の詳細設定（自動修復設定など）は、構成ファイルを使用してのみ指定できます。

次の構成ファイルの例では、自動作成された新しいノードプールのノードの自動修復と自動アップグレードを有効にします。
```
management:
  autoRepair: true
  autoUpgrade: true
```
次の構成ファイルの例では、ノードの自動プロビジョニングのクラスタ全体のリソース上限を設定し、複数のデフォルト設定を構成しています。
```
resourceLimits:
  - resourceType: 'cpu'
    minimum: 4
    maximum: 10
  - resourceType: 'memory'
    maximum: 64
  - resourceType: 'nvidia-tesla-t4'
    maximum: 4
management:
  autoRepair: true
  autoUpgrade: true
shieldedInstanceConfig:
  enableSecureBoot: true
  enableIntegrityMonitoring: true
diskSizeGb: 100
```
この構成ファイルでは、次のデフォルト値が設定されます。
- 自動作成された新しいノードプールに対して、ノードの自動修復と自動アップグレードを有効にします。
- 自動作成された新しいノードプールに対して、セキュアブートと整合性モニタリングを有効にします。
- 新しく自動作成されたノードプールのブートディスクサイズを 100 GiB に設定します。

構成ファイルをクラスタに適用すると、GKE はファイル内の設定をクラスタ内の自動作成された新しいノードプールにのみ使用します。ファイルで指定した新しい設定または変更された設定は、GKE がクラスタに作成した既存のノードプールには適用されません。クラスタに以前に設定された値を更新すると、GKE はすべての新しいノードプールに新しい値を使用します。たとえば、デフォルトのマシンシリーズを N2 に設定していて、構成ファイルで値を N4 に更新すると、新しいノードプールはすべて N4 マシンタイプを使用します。

クラスタレベルの構成ファイルの使用方法については、ノード自動プロビジョニング構成ファイルを使用して設定を構成するをご覧ください。

ノードプールの自動作成のユースケース

以降のセクションでは、ノードプールの自動作成の一般的なユースケースとサポートされているハードウェアについて説明します。その他のユースケースとサポートされている構成の詳細については、特定のユースケースのドキュメントをご覧ください。

注: 1.33.3-gke.1136000 より前のバージョンで ComputeClass を使用して自動作成されたノードプールを取得するには、クラスタ全体のノード自動プロビジョニングが必要です。これらのバージョンでは、ノードの自動プロビジョニングを有効にするときに、クラスタのリソース上限を設定する必要があります。たとえば、1.33.3-gke.1136000 より前のバージョンで ComputeClasses を使用して TPU をリクエストする場合は、ノード自動プロビジョニングを有効にして、クラスタ全体の TPU 上限を設定する必要があります。詳細については、ノードの自動プロビジョニングによるクラスタレベルでの有効化をご覧ください。

マシンシリーズまたはマシンタイプの選択

GKE が自動作成されたノードプールで使用する Compute Engine マシンシリーズまたはマシンタイプは、次のいずれかの方法で選択できます。

ComputeClasses: machineFamily または machineType 優先度ルールを使用します。
Pod 仕様: マシンシリーズの場合は、cloud.google.com/machine-family ノードラベルのノードセレクタを使用します。マシンタイプには、cloud.google.com/machine-family と node.kubernetes.io/instance-type の両方のノードラベルを使用します。詳細については、マシンシリーズまたはマシンタイプを選択するをご覧ください。

マシンを明示的に選択しない場合、GKE は E2 マシンシリーズまたはワークロードがリクエストするハードウェアと互換性のあるマシンタイプを使用します。たとえば、GKE は GPU に GPU マシンタイプを使用し、TPU リソースに専用マシンを使用します。

マシンシリーズまたはマシンタイプをリクエストする場合は、他のノードセレクタと Pod リソースリクエストが指定されたマシンと互換性があることを確認してください。たとえば、GPU と N2 マシンシリーズを同時にリクエストすることはできません。

サポートされているマシンシリーズ

ComputeClass またはワークロードで、サポートされている Compute Engine マシンシリーズまたはマシンタイプを明示的にリクエストできます。ノードプールの自動作成は、特定の GKE バージョンでのみ次のマシンシリーズをサポートしています。

Z3 マシンシリーズ: 1.29 以降。
C4 マシンシリーズ:
- 1.28.15-gke.1159000 以降。
- 1.29.10-gke.1227000 以降。
- 1.30.3-gke.1225000 以降。
C4A マシンシリーズ:
- 1.28.15-gke.1344000 以降。
- 1.29.11-gke.1012000 以降。
- 1.30.7-gke.1136000 以降。
- 1.31.3-gke.1056000 以降。
C4D マシンシリーズ: 1.32.3-gke.1717000 以降。
N4 マシンシリーズ: 1.29.3 以降。

他のマシンシリーズは、すべての GKE バージョンでサポートされています。

GPU の選択

自動作成されたノードプールの GPU は、次のいずれかの方法でリクエストできます。

ComputeClasses:
1. gpu 優先度ルールを使用して GPU を構成します。
2. Pod で GPU リソースをリクエストします。
Pod の仕様:
1. ノードの自動プロビジョニング用にクラスタ全体の GPU 上限を構成します。
2. ノードセレクタを使用して GPU を構成します。
3. Pod で GPU リソースをリクエストします。

GKE は、GPU の数をサポートするのに十分な大きさの GPU マシンタイプを選択します。選択した GPU の数によって、ノードの CPU とメモリ容量が影響を受けます。

Cloud TPU の選択

自動作成されたノードプールに対して Cloud TPU リソースをリクエストするには、次のいずれかの方法を使用します。

ComputeClasses: tpu 優先度ルールを使用して TPU を構成します。次に、Pod で同じ数の TPU リソースをリクエストします。詳細については、カスタムコンピューティングクラスを使用して TPU をプロビジョニングするをご覧ください。
Pod 仕様: クラスタ全体の TPU 上限を構成します。次に、ノードセレクタを使用して TPU を構成し、Pod で TPU リソースをリクエストします。詳細については、Cloud TPU の構成をご覧ください。

単一ホスト TPU スライスノードプールとマルチホスト TPU スライスノードプールはどちらも、自動スケーリングとノードプールの自動作成をサポートしています。ノードプールの自動作成では、GKE は、TPU のバージョンとトポロジが保留中のワークロードの要件を満たしている単一ホストまたはマルチホストの TPU スライスノードプールを作成します。

Cloud TPU の GKE バージョンの要件

ノードプールの自動作成は、特定の GKE バージョンでのみ次の Cloud TPU をサポートしています。

Cloud TPU v5p:
- 1.28.7-gke.1020000 以降。
- 1.29.2-gke.1035000 以降。
TPU Trillium: 1.31.1-gke.1146000 以降。

他の Cloud TPU タイプは、すべての GKE バージョンでサポートされています。

Cloud TPU ノードプールの自動スケーリング

GKE は、クラスタオートスケーラーを使用する自動作成または手動作成の Cloud TPU ノードプールを次のいずれかの方法で自動的にスケーリングします。

単一ホストの TPU スライスノードプール: GKE は、既存のノードプールで TPU ノードを追加または削除します。ノードプールには、0 からノードプールの最大サイズまでの任意の数の TPU ノードが含まれます。最大サイズは、--max-nodes 自動スケーリングフラグと --total-max-nodes 自動スケーリングフラグによって決まります。ノードプール内のすべての TPU ノードのマシンタイプとトポロジは同じです。単一ホストの TPU スライスノードプールを作成する方法については、ノードプールを作成するをご覧ください。
マルチホスト TPU スライスノードプール: GKE は、ノードプールを 0 から TPU トポロジを満たすために必要なノード数までアトミックにスケールアップします。たとえば、マシンタイプが ct5lp-hightpu-4t でトポロジが 16x16 の TPU ノードプールの場合、ノードプールには常に 64 個のノードまたは 0 個のノードが含まれます。ノードプールに TPU ワークロードがない場合、GKE はノードプールをスケールダウンします。ノードプールをスケールダウンするには、GKE はスケジュールされたすべての Pod を強制排除し、ノードプール内のすべてのノードを削除します。マルチホスト TPU スライスノードプールを作成する方法の詳細については、ノードプールを作成するをご覧ください。

Cloud TPU ノードプールの構成

GKE は、Pod または ComputeClass の構成を使用して、TPU ノードの構成を決定します。次のマニフェストは、Pod 仕様で TPU をリクエストする Deployment 仕様の例です。クラスタレベルのノード自動プロビジョニング設定が有効になっている場合、この Deployment はノードプールの自動作成をトリガーします。この Deployment の例を作成すると、GKE は 2x2x2 トポロジと 2 つの ct4p-hightpu-4t マシンを含む TPU v4 スライスを含むノードプールを作成します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tpu-workload
  labels:
    app: tpu-workload
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-tpu
  template:
    metadata:
      labels:
        app: nginx-tpu
    spec:
      nodeSelector:
        cloud.google.com/gke-tpu-accelerator: tpu-v4-podslice
        cloud.google.com/gke-tpu-topology: 2x2x2
        cloud.google.com/reservation-name: my-reservation
      containers:
      - name: nginx
        image: nginx:1.14.2
        resources:
          requests:
            google.com/tpu: 4
          limits:
            google.com/tpu: 4
        ports:
        - containerPort: 80

このマニフェストでは、次のフィールドで TPU 構成を定義します。

cloud.google.com/gke-tpu-accelerator: TPU のバージョンとタイプ。たとえば、次のいずれかを使用できます。
- TPU v4（tpu-v4-podslice）
- TPU v5e と tpu-v5-lite-podslice。
- tpu-v5p-slice を使用する TPU v5p。
- TPU Trillium（v6e）と tpu-v6e-slice。
cloud.google.com/gke-tpu-topology: TPU スライス内の TPU チップの数と物理的な配置。詳細については、トポロジを選択するをご覧ください。
limits.google.com/tpu: TPU VM 上の TPU チップの数。ほとんどの構成では、正しい値が 1 つしかありません。詳細については、GKE での TPU の仕組みをご覧ください。
cloud.google.com/reservation-name: TPU リソースの取得に使用する容量予約の名前。省略した場合、ワークロードは予約を使用しません。

自動作成されたノードプールの構成は、選択した TPU タイプ、TPU トポロジ、TPU チップの数によって異なります。ノードプールのタイプ、サイズ、構成を予測するには、次の操作を行います。

[トポロジを選択] で、指定した TPU タイプ（TPU Trillium や TPU v5e など）の Standard の表をフィルタします。
指定した値を使用して、次のようにノードプール構成を識別します。
1. gke-tpu-topology: Topology の値が同じテーブル内の行を見つけます。
2. limits: 表で、[TPU チップの数] の値を [VM の数] の値で割ります。指定した値と同じ結果値を持つ行をテーブルで探します。

たとえば、2x4 トポロジで tpu-v6e-slice（TPU Trillium）をリクエストしたシナリオを考えてみましょう。このシナリオでは、トポロジを選択するの表を TPU Trillium でフィルタします。次に、指定した構成に対応する行を次のように特定します。

gke-tpu-topology: TPU Trillium の 2x4 トポロジには次の構成があります。
- 1 つの ct6e-standard-8t インスタンスに 8 個の TPU チップがある単一ホストの TPU スライスノードプール。
- 2 つの ct6e-standard-4t インスタンスに 8 個の TPU チップが分散されているマルチホスト TPU スライスノードプール。
limits: TPU Trillium には 2x4 トポロジのオプションが複数あるため、limits フィールドで指定する値は、必要なノードプールのタイプによって異なります。
- 単一ホストの TPU スライスのノードプール: limits.google.com/tpu: 8 を指定して、8 個の TPU チップと 1 個の VM を含むノードプールを取得します。8 個のチップすべてがその VM にアタッチされています。
- マルチホスト TPU スライスノードプール: limits.google.com/tpu: 4 を指定して、8 個の TPU チップと 2 つの VM を持つノードプールを取得します。各 VM には 4 つのチップがあります。

Spot VM の選択

自動作成されたノードプールで Spot VM を選択するには、次のいずれかの方法を使用します。

ComputeClasses: 優先度ルールの spot フィールドを使用します。
Pod 仕様: NoSchedule 効果のある cloud.google.com/gke-spot="true" ノードラベルの容認能力を使用します。cloud.google.com/gke-spot=true または cloud.google.com/gke-provisioning=spot ノードラベルのノードセレクタを追加します。または、容認とノードセレクタで cloud.google.com/gke-preemptible ノードラベルを使用して、プリエンプティブル VM を選択することもできます。ただし、代わりに Spot VM を使用することを強くおすすめします。

一時ストレージの構成

GKE は、Pod のエフェメラルストレージにノードブートディスクの一部を使用します。GKE が自動作成されたノードに使用するブートディスクのサイズは、次のいずれかの方法でカスタマイズできます。

ComputeClasses: 優先度ルールで storage.bootDiskSize フィールドと storage.bootDiskType フィールドを使用します。ComputeClass ごとに異なるブートディスク設定を構成できます。
Pod 仕様: クラスタレベルの構成ファイルの diskSizeGb フィールドと diskType フィールドを使用します。この方法では、個々の Pod のブートディスクのサイズとタイプを制御できません。

詳細については、カスタムブートディスクをご覧ください。ブートディスクの設定を明示的に変更しない場合、デフォルトは容量が 100 GiB の pd-balanced ボリュームになります。

GKE は、指定したブートディスクを持つノードの割り当て可能なエフェメラルストレージが保留中の Pod のエフェメラルストレージのリクエスト以上の場合にのみ、新しいノードプールを作成します。エフェメラルストレージリクエストがノードの割り当て可能なエフェメラルストレージよりも大きい場合、GKE は新しいノードプールを作成せず、Pod は保留状態のままになります。GKE は、Pod のエフェメラルストレージリクエストに基づいてブートディスクのサイズを動的に調整しません。

ワークロードの分離

特定の Pod がクラスタ内の他の Pod とは別のノードで常に実行されるようにリクエストできます。GKE は、ノード taint を使用して、他のワークロードがこれらのノードで実行されないようにします。自動作成されたノードプールでワークロード分離を構成する方法は次のとおりです。

ComputeClasses: 特定の ComputeClass に対して GKE が作成するノードは、その ComputeClass を選択する Pod のみ実行できます。Pod 仕様を変更する必要はありません。Pod 間アフィニティと反アフィニティを使用すると、ComputeClass 内の Pod を分離できます。
Pod 仕様: クラスタでノードの自動プロビジョニングを有効にすると、Pod 仕様のフィールドを使用してワークロードの分離を構成できます。ノードプールの自動作成中に、次の条件をすべて満たすと、GKE はラベルと taints を持つノードプールを作成することがあります。
- Pod は、ノードセレクタを使用してカスタムノードラベルのキーと値をリクエストします。ワークロードの分離にシステムノードラベルは使用できません。
- Pod には、同じノードラベルキーの容認があります。
- 容認エフェクトが NoSchedule、NoExecute、または未指定です。

これらのフィールドの構成と制限事項の詳細については、GKE でワークロードの分離を構成するをご覧ください。

制限事項

クラスタオートスケーラーの制限事項はすべて、ノードプールの自動作成にも適用されます。
ノードプールの合計数が 200 を超えるクラスタでは、自動スケーリング中にレイテンシが増加する可能性があります。ワークロードの分離や複数の ComputeClass の使用など、新しいノードプールの作成をトリガーする構成を行うと、この数が増加します。クラスタの上限の詳細については、「大規模なクラスタの計画」の上限とベストプラクティスをご覧ください。
ノードの自動プロビジョニングを有効にしたときにクラスタに設定したリソース上限は、GKE が ComputeClass 用に作成するノードプールにも適用されます。
次の設定は、ComputeClass でサポートされていません。
- サージアップグレードまたは Blue/Green アップグレード。
- ノードの整合性とセキュアブート。
1.33.3-gke.1136000 より前の GKE バージョンで ComputeClass のノードプールの自動作成を有効にするには、クラスタレベルのノード自動プロビジョニングも有効にする必要があります。この制限は、GKE バージョン 1.33.3-gke.1136000 以降には適用されません。

サポートされていない構成

GKE は、次の構成を使用する新しいノードプールを作成しません。

GKE Sandbox
Windows オペレーティングシステム
ローカル PersistentVolume の自動スケーリング。
Pod のエフェメラルストレージに専用のローカル SSD を使用するノード。ただし、GKE は、raw ブロックストレージにローカル SSD を使用する新しいノードプールを作成できます。
カスタムスケジューリング用に変更されたフィルタを使用するノード。
同時マルチスレッディング（SMT）。
パフォーマンスモニタリングユニット（PMU）。

クラスタオートスケーラーは、これらの構成を使用する既存のノードプール内のノードをスケーリングできます。

次のステップ

ノードプールの自動作成を構成する