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

このページでは、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 でワークロードの分離を構成するをご覧ください。

ワークロード分離にラベルを使用する際の制限事項

ノードの自動プロビジョニングでは、ノードの自動プロビジョニングでサポートされているラベル（cloud.google.com/gke-spot やマシンファミリーなど）を使用すると、新しいノードプールの作成がトリガーされます。Pod マニフェストで他のラベルを使用して、GKE が Pod を配置するノードを絞り込むことができますが、GKE はこれらのラベルを使用して新しいノードプールをプロビジョニングしません。ノードプールの作成を明示的にトリガーしないラベルのリストについては、taint と toleration によるワークロードの分離の制限をご覧ください。

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

自動プロビジョニングされたノードプールにノードが存在しない場合、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（tpu-v4-podslice を使用）
  • TPU v5e（tpu-v5-lite-podslice）。
  • TPU v6e は tpu-v6e-slice です。TPU v6e はプレビュー版です。
• 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: ワークロードが使用する予約の名前。省略した場合、ワークロードは予約を使用しません。

v6e（プレビューで利用可能）を設定すると、ノードの自動プロビジョニングで次の決定が行われます。

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

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

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

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

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

ノードの自動プロビジョニングの設定方法については、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 のスケジュールを設定する方法が他にない場合のみ作成できます。

次のステップ

• ノードの自動プロビジョニングを有効にする方法ついて学ぶ
• クラスタ オートスケーラーについて学ぶ