ノードの自動プロビジョニングについて

このページでは、Google Kubernetes Engine（GKE）Standard クラスタでのノードの自動プロビジョニングの仕組みについて説明します。ノードの自動プロビジョニングにより、ワークロードの要件に合わせてノードが自動的にスケーリングされます。

Autopilot クラスタでは、GKE がノードのスケーリングとプロビジョニングを自動的に管理するため、手動でノードのプロビジョニングやノードプールの管理を行う必要はありません。

ノードの自動プロビジョニングを使用する理由

ノードの自動プロビジョニングは、ユーザーに代わってノードプールのリストを自動的に管理してスケーリングします。ノードの自動プロビジョニングを使用しない場合、GKE クラスタ オートスケーラーはユーザーが作成したノードプールからのみノードを作成します。ノード自動プロビジョニングにより、GKE ではノードプールが自動的に作成、削除されます。

サポートされていない機能

ノードの自動プロビジョニングでは、次のいずれかの機能を使用するノードプールは作成されません。ただし、クラスタ オートスケーラーは、これらの機能を使用して既存のノードプール内のノードをスケーリングします。

ノードの自動プロビジョニングの仕組み

ノードの自動プロビジョニングはクラスタ オートスケーラーの仕組みの一つで、既存のノードプールのみがスケーリングされます。ノードの自動プロビジョニング機能が有効になっていると、クラスタ オートスケーラーはスケジュール不可の Pod の仕様に基づいてノードプールを自動的に作成します。

ノード自動プロビジョニングは、次の情報に基づいてノードプールを作成します。

リソースの上限

ノードの自動プロビジョニングとクラスタ オートスケーラーには、次のレベルで上限が設定されています。

  • ノードプール レベル: 自動プロビジョニングされるノードプールは 1,000 ノードに制限されています。
  • クラスタレベル:
    • 定義した自動プロビジョニングの制限は、自動プロビジョニングされたプールだけでなく、すべてのノードプールで使用される CPU リソースとメモリリソースの合計に基づいて適用されます。
    • クラスタ オートスケーラーは、設定した制限を超えない範囲で新しいノードを作成します。上限をすでに超えている場合、GKE はノードを削除しません。

ワークロードの分離

保留中の Pod にノード アフィニティと toleration が設定されている場合、ノードの自動プロビジョニングはラベルと taint が一致するようにノードをプロビジョニングできます。

次の条件をすべて満たすと、ノードの自動プロビジョニングはラベルと taints を持つノードプールを作成します。

  • 保留中の Pod のノードに特定のラベルキーと値が設定されている。
  • その Pod には同じキーを持つ taint の容認機能がある。
  • この容認機能が NoSchedule エフェクト、NoExecute エフェクト、またはすべてのエフェクトに対応している。

手順については、GKE でワークロードの分離を構成するをご覧ください。

自動プロビジョニングされたノードプールの削除

自動プロビジョニングされたノードプールにノードが存在しない場合、GKE はそのノードプールを削除します。GKE は、自動プロビジョニングされていないノードプールを削除しません。

サポートされているマシンタイプ

ノードの自動プロビジョニングは、クラスタ内の Pod の要件を確認して、Pod に最適なノードの種類を決定します。

次のいずれかの条件が適用されない限り、GKE はデフォルトで E2 マシンシリーズを使用します。

  • ワークロードが、E2 マシンシリーズで利用できない機能をリクエストしている場合。たとえば、ワークロードで GPU がリクエストされた場合、新しいノードプールには N1 マシンシリーズが使用されます。
  • ワークロードが TPU リソースをリクエストします。TPU の詳細については、Cloud TPU の概要をご覧ください。
  • ワークロードが machine-family ラベルを使用する場合。詳細については、カスタムマシン ファミリーの使用をご覧ください。

Pod が GPU をリクエストした場合は、ノードの自動プロビジョニングによって、Pod がリクエストした GPU の数をサポートするのに十分なマシンタイプが割り当てられます。GPU の数によって、ノードに配置できる CPU とメモリが制限されます。詳細については、GPU プラットフォームをご覧ください。

サポートされているノードイメージ

ノードの自動プロビジョニングによって、次のノードイメージのいずれかを使用してノードプールが作成されます。

  • Container-Optimized OS（cos_containerd）。
  • Ubuntu（ubuntu_containerd）。

サポートされている ML アクセラレータ

ノードの自動プロビジョニングにより、GPU や Cloud TPU などのハードウェア アクセラレータを備えたノードプールを作成できます。ノードの自動プロビジョニングは、GKE バージョン 1.28 以降で TPU をサポートしています。

GPU

Pod が GPU をリクエストした場合は、ノードの自動プロビジョニングによって、Pod がリクエストした GPU の数をサポートするのに十分なマシンタイプが割り当てられます。GPU の数によって、ノードに配置できる CPU とメモリが制限されます。詳細については、GPU プラットフォームをご覧ください。

Cloud TPU

GKE は、ML ワークロードを高速化するために Tensor Processing Unit（TPU）をサポートしています。単一ホストの TPU スライス ノードプールとマルチホストの TPU スライス ノードプールはどちらも、自動スケーリングと自動プロビジョニングをサポートしています

GKE クラスタで --enable-autoprovisioning フラグを指定すると、GKE は、TPU のバージョンとトポロジが保留中のワークロードの要件を満たしている単一ホストまたはマルチホストの TPU スライス ノードプールを作成または削除します。

--enable-autoscaling を使用すると、GKE はタイプに基づいてノードプールを次のようにスケーリングします。

  • 単一ホストの TPU スライス ノードプール: GKE は、既存のノードプールで TPU ノードを追加または削除します。ノードプールには、0 からノードプールの最大サイズまでの任意の数の TPU ノードが含まれます。最大サイズは、--max-nodes フラグと --total-max-nodes フラグによって決まります。ノードプールがスケーリングされると、ノードプール内のすべての TPU ノードのマシンタイプとトポロジは同じになります。単一ホストの TPU スライス ノードプールを作成する方法については、ノードプールを作成するをご覧ください。

  • マルチホスト TPU スライス ノードプール: GKE は、ノードプールを 0 から TPU トポロジを満たすために必要なノード数までアトミックにスケールアップします。たとえば、マシンタイプが ct5lp-hightpu-4t でトポロジが 16x16 の TPU ノードプールの場合、ノードプールには 64 個のノードが含まれます。GKE オートスケーラーは、このノードプールのノード数が 0 または 64 になるように調整します。スケールダウンすると、GKE はスケジュールされたすべての Pod を強制排除し、ノードプール全体が 0 になるようにドレインします。マルチホスト TPU スライス ノードプールの作成方法については、ノードプールを作成するをご覧ください。

特定の TPU スライスに、実行中またはスケジュール設定待ちの Pod がない場合、GKE はノードプールをスケールダウンします。マルチホスト TPU スライス ノードプールは、アトミックにスケールダウンされます。単一ホストの TPU スライスのノードプールは、個々の単一ホストの TPU スライスを削除することでスケールダウンされます。

TPU でノードの自動プロビジョニングを有効にすると、GKE は Pod リクエストで定義された値に基づいてスケーリング判断を行います。次のマニフェストは、2x2x2 トポロジを持つ TPU v4 スライスと 2 つの ct4p-hightpu-4t マシンを含む 1 つのノードプールを作成する Deployment 仕様の例です。

    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

ここで

  • cloud.google.com/gke-tpu-accelerator: TPU のバージョンとタイプ。たとえば、tpu-v4-podslice を含む TPU v4、tpu-v5-lite-podslice を含む TPU v5e などです。
  • cloud.google.com/gke-tpu-topology: TPU スライス内の TPU チップの数と物理的な配置。ノードプールを作成し、ノードの自動プロビジョニングを有効にするときに、TPU トポロジを選択します。Cloud TPU トポロジの詳細については、TPU 構成をご覧ください。
  • limit.google.com/tpu: TPU VM 上の TPU チップの数。ほとんどの構成では、正しい値が 1 つしかありません。ただし、2x4 を持つ tpu-v5-lite-podslice トポロジ構成は次のとおりです。
    • google.com/tpu = 8 を指定すると、ノードの自動プロビジョニングによって単一ホストの TPU スライス ノードプールがスケールアップされ、1 つの ct5lp-hightpu-8t マシンが追加されます。
    • google.com/tpu = 4 を指定すると、ノードの自動プロビジョニングによって 2 つの ct5lp-hightpu-4t マシンを持つマルチホストの TPU スライス ノードプールが作成されます。
  • cloud.google.com/reservation-name: ワークロードが使用する予約の名前。省略した場合、ワークロードは予約を使用しません。

tpu-v4-podslice を設定すると、ノードの自動プロビジョニングで次の決定が行われます。

Pod マニフェストで設定される値 ノードの自動プロビジョニングによって決定
gke-tpu-topology limit.google.com/tpu ノードプールのタイプ ノードプールのサイズ マシンタイプ
2x2x1 4 単一ホスト TPU スライス 柔軟 ct4p-hightpu-4t
{A}x{B}x{C} 4 マルチホスト TPU スライス {A}x{B}x{C}/4 ct4p-hightpu-4t

{A}×{B}×{C} の積が、ノードプール内のチップの数を定義します。たとえば、4x4x4 のような組み合わせで 64 個のチップからなる小さなトポロジを定義できます。64 チップを超えるトポロジを使用する場合、{A}、{B}、{C} に割り当てる値は、次の条件を満たしている必要があります。

  • {A}、{B}、{C} はすべて 4 以下、または 4 の倍数です。
  • サポートされている最大のトポロジは 12x16x16 です。
  • 割り当てられた値は、A ≤ B ≤ C のパターンを維持します。たとえば、小規模なトポロジの場合は 2x2x4 や 2x4x4 です。

tpu-v5-lite-podslice を設定すると、ノードの自動プロビジョニングで次の決定が行われます。

Pod マニフェストで設定される値 ノードの自動プロビジョニングによって決定
gke-tpu-topology limit.google.com/tpu ノードプールのタイプ ノードプールのサイズ マシンタイプ
1×1 1 単一ホスト TPU スライス 柔軟 ct5lp-hightpu-1t
2x2 4 単一ホスト TPU スライス 柔軟 ct5lp-hightpu-4t
2x4 8 単一ホスト TPU スライス 柔軟 ct5lp-hightpu-8t
2x41 4 マルチホスト TPU スライス 2（8/4） ct5lp-hightpu-4t
4x4 4 マルチホスト TPU スライス 4（16/4） ct5lp-hightpu-4t
4x8 4 マルチホスト TPU スライス 8（32/4） ct5lp-hightpu-4t
4x8 4 マルチホスト TPU スライス 16（32/4） ct5lp-hightpu-4t
8x8 4 マルチホスト TPU スライス 16（64/4） ct5lp-hightpu-4t
8x16 4 マルチホスト TPU スライス 32（128/4） ct5lp-hightpu-4t
16x16 4 マルチホスト TPU スライス 64（256/4） ct5lp-hightpu-4t

  1. マシンタイプが google.com/tpu 制限フィールドで定義された値に依存する特殊なケース。↩

アクセラレータ タイプを tpu-v5-lite-device に設定すると、ノードの自動プロビジョニングで次のことが決定されます。

Pod マニフェストで設定される値 ノードの自動プロビジョニングによって決定
gke-tpu-topology limit.google.com/tpu ノードプールのタイプ ノードプールのサイズ マシンタイプ
1×1 1 単一ホスト TPU スライス 柔軟 ct5l-hightpu-1t
2x2 4 単一ホスト TPU スライス 柔軟 ct5l-hightpu-4t
2x4 8 単一ホスト TPU スライス 柔軟 ct5l-hightpu-8t

ノードの自動プロビジョニングの設定方法については、TPU の構成をご覧ください。

Spot VM のサポート

ノードの自動プロビジョニングでは、Spot VM に基づくノードプールの作成がサポートされています。

Spot VM に基づくノードプールの作成は、cloud.google.com/gke-spot="true":NoSchedule taint の容認機能を持つスケジューリングできない Pod が存在する場合にのみ考慮されます。Spot VM に基づいて自動プロビジョニングされたノードプール内のノードには、taint が自動的に適用されます。

容認機能を、cloud.google.com/gke-spot="true" や cloud.google.com/gke-provisioning=spot ノードラベル（GKE バージョン 1.25.5-gke.2500 以降を実行しているノードの場合）の nodeSelector またはノード アフィニティ ルールと組み合わせて使用して、Spot VM に基づくノードプールでのみワークロードが実行されるようにできます。

エフェメラル ストレージをリクエストする Pod のサポート

ノード自動プロビジョニングでは、Pod がエフェメラル ストレージをリクエストした場合にノードプールを作成できます。ノードプールでプロビジョニングされたブートディスクのサイズは、新しく自動プロビジョニングされるすべてのノードプールに適用されます。このブートディスクのサイズはカスタマイズできます。

デフォルトは 100 GiB です。ローカル SSD に基づくエフェメラル ストレージはサポートされていません。

ノード自動プロビジョニングは、指定したブートディスクを持つノードの割り当て可能なエフェメラル ストレージが保留中の Pod のエフェメラル ストレージのリクエストより大きい場合にのみノードプールをプロビジョニングします。エフェメラル ストレージのリクエストが割り当て可能な値よりも大きい場合、ノード自動プロビジョニングはノードプールをプロビジョニングしません。ノードのディスクサイズが、保留中の Pod のエフェメラル ストレージのリクエストに基づいて動的に構成されることはありません。

スケーラビリティの制限

ノードの自動プロビジョニングには、クラスタ オートスケーラーと同じ制限事項のほかに、次の制限があります。

分離されたワークロード数の上限
ノードの自動プロビジョニングでは、分離されたワークロードが最大 100 個までサポートされます。
ノードプール数の上限
ノードの自動プロビジョニングでは、クラスタ内のプール数が 100 に近づくと、新しいノードプールの作成の優先度が低くなります。100 を超えるノードプールは、保留中の Pod のスケジュールを設定する方法が他にない場合のみ作成できます。

次のステップ