このページでは、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 にノード アフィニティと 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 |
-
マシンタイプが
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 のスケジュールを設定する方法が他にない場合のみ作成できます。