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

Standard

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

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

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

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

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

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

GKE Sandbox。
Windows オペレーティングシステム。
予約アフィニティの制御。
ローカルの PersistentVolume の自動スケーリング。
エフェメラルストレージとしてローカル SSD を使用するノードの自動プロビジョニング。
変更されたフィルタを使用するカスタムスケジューリングによる自動プロビジョニング。
同時マルチスレッディング（SMT）の構成。

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

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

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

CPU、メモリ、エフェメラルストレージのリソースリクエスト
GPU リクエスト。
保留中の Pod のノードアフィニティとラベルセレクタ
保留中の Pod の Node Taints と容認機能

リソースの上限

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

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

ワークロードの分離

保留中の Pod にノードアフィニティと容認機能が設定されている場合、ノードの自動プロビジョニングはラベルと 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

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`
2x4¹	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`

マシンタイプが 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 のスケジュールを設定する方法が他にない場合のみ作成できます。