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

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

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

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

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

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

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

仕組み

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

  • ComputeClass を使用します。これは、ノードセレクタを使用してさまざまな 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 に同じノードラベルの toleration とノードセレクタの両方がある場合、GKE はこれらの toleration のノード taint を自動作成されたノードに追加します。

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

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

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

GKE のスケーリング設定

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

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

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

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

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

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

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

有効化方法
ワークロードレベル（推奨）

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

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

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

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

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

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

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

  1. GKE は、Pod 仕様または Pod の ComputeClass でマシンタイプが指定されているかどうかを確認します。
  2. Pod 仕様または ComputeClass でマシンタイプが指定されていない場合、GKE はクラスタでノードの自動プロビジョニングのデフォルトのマシンタイプが設定されているかどうかを確認します。
  3. ノード自動プロビジョニングのデフォルトのマシンタイプを設定していない場合、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 を使用する場合でも、クラスタ全体のリソース上限を設定する必要があります。

  • 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 構成ファイルを使用して、自動作成されたノードプールのクラスタ全体のデフォルト設定を指定できます。単一の構成ファイルで複数の設定を指定できます。一部の詳細設定（自動修復設定など）は、構成ファイルを使用してのみ指定できます。

  • 次の構成ファイルの例では、自動作成された新しいノードプールのノードの自動修復と自動アップグレードを有効にします。

    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

    この構成ファイルでは、次のデフォルト値が設定されます。

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

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

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

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

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

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

  • ComputeClass: 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 バージョンでのみ次のマシンシリーズをサポートしています。

他のマシンシリーズは、すべての 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 リソースをリクエストするには、次のいずれかの方法を使用します。

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

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

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

  • TPU v3: 1.31.0 以降。
  • TPU v5 と TPU v4: 1.29.0 以降。
  • TPU Trillium: 1.31.1-gke.1146000 以降。
  • Ironwood（TPU7x）（プレビュー）: 1.34.1-gke.2541000 以降。

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

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

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

  • 単一ホストの TPU スライス ノードプール: GKE は、既存のノードプールで TPU ノードを追加または削除します。ノードプールには、0 からノードプールの最大サイズまでの任意の数の TPU ノードが含まれます。最大サイズは、--max-nodes 自動スケーリング フラグと --total-max-nodes 自動スケーリング フラグによって決まります。ノードプール内のすべての TPU ノードのマシンタイプとトポロジは同じです。単一ホストの TPU スライス ノードプールを作成する方法については、単一ホスト TPU スライス ノードプールを作成するをご覧ください。
  • マルチホスト TPU スライス ノードプール: GKE は、ノードプールを 0 から TPU トポロジを満たすために必要なノード数までアトミックにスケールアップします。たとえば、マシンタイプが ct5lp-hightpu-4t でトポロジが 16x16 の TPU ノードプールの場合、ノードプールには常に 64 個のノードまたは 0 個のノードが含まれます。ノードプールに TPU ワークロードがない場合、GKE はノードプールをスケールダウンします。ノードプールをスケールダウンするために、GKE はスケジュールされたすべての Pod を強制排除し、ノードプール内のすべてのノードを削除します。マルチホスト TPU スライス ノードプールを作成する方法の詳細については、マルチホスト 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
  template:
    spec:
      nodeSelector:
        cloud.google.com/gke-tpu-accelerator: tpu-v4-podslice
        cloud.google.com/gke-tpu-topology: 2x2x2
      containers:
      - name: tpu-job
        image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
        ports:
        - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
        securityContext:
          privileged: true # Required for GKE versions earlier than 1.28 to access TPUs.
        command:
        - bash
        - -c
        - |
          python -c 'import jax; print("Total TPU chips:", jax.device_count())'
        resources:
          requests:
            google.com/tpu: 4
          limits:
            google.com/tpu: 4
        ports:
        - containerPort: 80

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

  • cloud.google.com/gke-tpu-accelerator: TPU のバージョンとタイプ。たとえば、Ironwood（TPU7x）には tpu7x-standard-4t を使用します。
  • cloud.google.com/gke-tpu-topology: TPU スライス内の TPU チップの数と物理的な配置を含むトポロジ。たとえば、2x2x2 を使用します。
  • limits.google.com/tpu: VM あたりの TPU チップ数。たとえば、tpu7x-standard-4t を使用する場合、VM あたりの TPU チップ数は 4 です。

Spot VM の選択

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

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

エフェメラル ストレージの構成

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

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

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

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

ワークロードの分離

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

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

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

制限事項

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

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

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

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

次のステップ