ワークロードの安定性を高めるため、Google Kubernetes Engine（GKE）Autopilot モードでは、CPU、メモリ、エフェメラル ストレージなどの Pod リソース リクエストの値が管理されます。このページには、効率的で安定した費用対効果の高いワークロードを計画するために使用できる次の情報が記載されています。
- 値を指定しない Pod に Autopilot が適用するデフォルト値。
- Autopilot がリソース リクエストに適用する最小値と最大値。
- Pod がリクエストするハードウェアに応じて、デフォルト値、最小値、最大値がどのように変化するか。
このページは、クラウド リソースのプロビジョニングと構成、ワークロードのデプロイを行うオペレーターとデベロッパーを対象としています。 Google Cloudのコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE ユーザーのロールとタスクをご覧ください。
このページは、Kubernetes のリソース管理に精通していることを前提としています。
Autopilot リソース リクエストの概要
Autopilot は、ワークロード構成に指定したリソース リクエストを使用して、ワークロードを実行するノードを構成します。Autopilot は、ワークロードが使用するコンピューティング クラスまたはハードウェア構成に基づいて、リソースの最小リクエストと最大リクエストを適用します。一部のコンテナのリクエストを指定していない場合、Autopilot は、コンテナが正常に実行されるようにデフォルト値を割り当てます。
Autopilot クラスタにワークロードをデプロイすると、選択したコンピューティング クラスまたはハードウェア構成（GPU など）で許容される最小値と最大値に対してワークロード構成が GKE により検証されます。リクエストが最小値未満の場合は、Autopilot がワークロード構成を自動的に変更し、リクエストが許容範囲に収まるようにします。リクエストが最大値より大きい場合、Autopilot はワークロードを拒否し、エラー メッセージが表示されます。
次のリストは、リソース リクエストのカテゴリの概要を示します。
- デフォルトのリソース リクエスト: ワークロードに独自のリクエストを指定しない場合、Autopilot によって追加されます。
- リソースの最小リクエストと最大リクエスト: Autopilot は、リクエストがこの制限内に収まるように、指定されたリクエストを検証します。リクエストが制限を超えると、Autopilot によってワークロード リクエストが変更されます。
- ワークロードの分離と期間延長のリクエスト: Autopilot には、互いに分離しているワークロードや GKE が開始した強制排除からの保護を強化した Pod ごとに別々のデフォルト値と最小値があります。
- DaemonSet のリソース リクエスト: Autopilot では、DaemonSet のコンテナごとに異なるデフォルト値、最小値、最大値があります。
リソースのリクエスト方法
Autopilot では、リソースを Pod 仕様でリクエストします。リクエストできるサポート対象の最小リソースと最大リソースは、Pod が実行されるノードのハードウェア構成によって変わります。特定のハードウェア構成をリクエストする方法については、次のページをご覧ください。
デフォルトのリソース リクエスト
Pod 内の一部のコンテナにリソース リクエストを指定しない場合、Autopilot はデフォルト値を適用します。これらのデフォルト値は、多くの小規模なワークロードに適しています。
さらに、Autopilot は、選択したコンピューティング クラスやハードウェア構成に関係なく、次のデフォルト リソース リクエストを適用します。
DaemonSet のコンテナ
- CPU: 50 mCPU
- メモリ: 100 MiB
- エフェメラル ストレージ: 100 MiB
その他すべてのコンテナ
- エフェメラル ストレージ: 1 GiB
Autopilot によるクラスタの制限の詳細については、割り当てと上限をご覧ください。
コンピューティング クラスのデフォルト リクエスト
Autopilot では、コンピューティング クラスで実行される Pod の Pod 仕様で定義されていないリソースには、次のデフォルト値が適用されます。一方のリクエストのみを設定し、もう一方を空白のままにすると、GKE は最小リクエストと最大リクエストのセクションで定義されている CPU とメモリの比率を使用して、欠落しているリクエストを比率に沿う値に設定します。
| コンピューティング クラス | リソース | デフォルト リクエスト |
|---|---|---|
| 汎用（デフォルト） | CPU | 0.5 vCPU |
| メモリ | 2 GiB | |
| アクセラレータ | デフォルトのリクエストは適用されません。 | |
| バランス | CPU | 0.5 vCPU |
| メモリ | 2 GiB | |
| パフォーマンス | デフォルトのリクエストは適用されません。 | |
| スケールアウト | CPU | 0.5 vCPU |
| メモリ | 2 GiB | |
リソースの最小リクエストと最大リクエスト
デプロイ構成でリクエストされるリソースの合計は、Autopilot で許可されるサポート範囲の最小値と最大値の間に入る必要があります。次の条件が適用されます。
エフェメラル ストレージ リクエスト:
エフェメラル ストレージは、ノードにローカル SSD が接続されていない限り、VM ブートディスクを使用します。
A100（80 GB）GPU、H100（80 GB）GPU、Z3 マシンシリーズなど、ローカル SSD を含むコンピューティング ハードウェアは、ローカル SSD のサイズからシステム オーバーヘッドを差し引いた最大リクエストをサポートします。このシステム オーバーヘッドの詳細については、ローカル SSD に基づくエフェメラル ストレージをご覧ください。
GKE バージョン 1.29.3-gke.1038000 以降では、ハードウェアにローカル SSD が含まれていない限り、Performance クラスの Pod とハードウェア アクセラレータ Pod は、最大 56 TiB のエフェメラル ストレージ リクエストをサポートしています。
GKE バージョンに関係なく、他のすべての Autopilot Pod では、Pod 内のすべてのコンテナのエフェメラル ストレージ リクエストの合計は、別途指定しない限り 10 MiB～10 GiB の範囲にする必要があります。
より大きな容量を必要とする場合は、汎用のエフェメラル ボリュームを使用します。これは、エフェメラル ストレージと同等の機能とパフォーマンスを提供し、どの GKE ストレージ オプションでも使用できるため、柔軟性が大幅に向上します。たとえば、
pd-balancedを使用する汎用エフェメラル ボリュームの最大サイズは 64 TiB です。
DaemonSet Pod の場合、最小リソース リクエストは次のとおりです。
- バーストをサポートするクラスタ: Pod あたり 1 mCPU、Pod あたり 2 MiB のメモリ、Pod 内のコンテナあたり 10 MiB のエフェメラル ストレージ。
- バーストをサポートしていないクラスタ: Pod あたり 10 mCPU、Pod あたり 10 MiB のメモリ、Pod 内のコンテナあたり 10 MiB のエフェメラル ストレージ。
クラスタがバースト機能をサポートしているかどうかを確認するには、GKE でのバーストの可用性をご覧ください。
クラスタがバースト機能をサポートしている場合、Autopilot は Pod CPU リクエストに 0.25 vCPU の増分は適用しません。クラスタがバースト機能をサポートしていない場合、Autopilot は CPU リクエストを 0.25 vCPU に切り上げます。クラスタがバースト機能をサポートしているかどうかを確認するには、GKE でのバーストの可用性をご覧ください。
CPU とメモリの比率は、選択したコンピューティング クラスまたはハードウェア構成で許容される範囲内になければなりません。CPU とメモリの比率が許容範囲を超えている場合、Autopilot は小さい方のリソースを自動的に増加させます。たとえば、
Scale-Outクラスで実行されている Pod に 1 vCPU と 16 GiB のメモリ（比率 1:16）をリクエストすると、Autopilot は、CPU リクエストを 4 vCPU に増加させ、比率は 1:4 になります。
コンピューティング クラスの最小値と最大値
Autopilot がサポートするコンピューティング クラスごとの CPU とメモリの最小値、最大値と許容される比率を次の表に示します。
| コンピューティング クラス | CPU とメモリの比率（vCPU:GiB） | リソース | 最小 | 最大 |
|---|---|---|---|---|
| 汎用（デフォルト） | 1:1～1:6.5 | CPU | この値は、クラスタがバーストをサポートしているかどうかによって異なります。
クラスタがバーストをサポートしているかどうかを確認するには、GKE でのバーストの可用性をご覧ください。 |
30 vCPU |
| メモリ | この値は、クラスタがバーストをサポートしているかどうかによって異なります。
クラスタがバーストをサポートしているかどうかを確認するには、GKE でのバーストの可用性をご覧ください。 |
110 GiB | ||
| アクセラレータ | アクセラレータの最小値と最大値をご覧ください。 | |||
| バランス | 1:1～1:8 | CPU | 0.25 vCPU | 222 vCPU 最小 CPU プラットフォームが選択されている場合:
|
| メモリ | 0.5 GiB | 851 GiB 最小 CPU プラットフォームが選択されている場合:
|
||
| パフォーマンス | なし | CPU | 最小リクエスト数は適用されません |
|
| メモリ | 最小リクエスト数は適用されません |
|
||
| エフェメラル ストレージ | 最小リクエスト数は適用されません |
|
||
| スケールアウト | 正確に 1:4 | CPU | 0.25 vCPU |
|
| メモリ | 1 GiB |
|
||
Autopilot Pod でコンピューティング クラスをリクエストする方法については、Autopilot Pod のコンピューティング クラスを選択するをご覧ください。
アクセラレータの最小値と最大値
GKE では、アクセラレータを使用する Pod に対して、CPU、メモリ、エフェメラル ストレージの最小リクエストは適用されません。次の表に、使用するアクセラレータの数とタイプに基づいて、これらの各リソースの最大リクエスト数を示します。
特に指定されていない限り、サポートされるエフェメラル ストレージの最大値は 56 TiB です。
| アクセラレータ タイプ | リソース | 最大 |
|---|---|---|
NVIDIA B200nvidia-B200 |
CPU |
|
| メモリ |
|
|
| エフェメラル ストレージ |
|
|
NVIDIA H200（141 GB）nvidia-h200-141gb |
CPU |
|
| メモリ |
|
|
| エフェメラル ストレージ |
|
|
NVIDIA H100 Mega（80 GB）nvidia-h100-mega-80gb |
CPU |
|
| メモリ |
|
|
| エフェメラル ストレージ |
|
|
NVIDIA H100（80 GB）nvidia-h100-80gb |
CPU |
|
| メモリ |
|
|
| エフェメラル ストレージ |
|
|
NVIDIA A100（40 GB）nvidia-tesla-a100 |
CPU |
A100 GPU ノードで実行されるすべての DaemonSet の CPU リクエストの合計は、2 vCPU を超えないようにする必要があります。 |
| メモリ |
A100 GPU ノードで実行されるすべての DaemonSet のメモリ リクエストの合計は、14 GiB 超えないようにする必要があります。 |
|
NVIDIA A100（80 GB）nvidia-a100-80gb |
CPU |
A100（80GB）GPU ノードで実行されるすべての DaemonSet の CPU リクエストの合計は、2 vCPU を超えないようにする必要があります。 |
| メモリ |
A100（80GB）GPU ノードで実行されるすべての DaemonSet のメモリ リクエストの合計は、14 GiB を超えないようにする必要があります。 |
|
| エフェメラル ストレージ |
|
|
NVIDIA L4nvidia-l4 |
CPU |
L4 GPU ノードで実行されるすべての DaemonSet の CPU リクエストの合計は、2 vCPU を超えないようにする必要があります。 |
| メモリ |
L4 GPU ノードで実行されるすべての DaemonSet のメモリ リクエストの合計は、14 GiB を超えないようにする必要があります。 |
|
NVIDIA Tesla T4nvidia-tesla-t4 |
CPU |
|
| メモリ |
|
|
TPU v5etpu-v5-lite-podslice |
CPU |
|
| メモリ |
|
|
| エフェメラル ストレージ | 56 TiB | |
TPU v5ptpu-v5p-slice |
CPU | 280 vCPU |
| メモリ | 448 GiB | |
| エフェメラル ストレージ | 56 TiB | |
TPU v4tpu-v4-podslice |
CPU | 240 vCPU |
| メモリ | 407 GiB | |
| エフェメラル ストレージ | 56 TiB |
Autopilot Pod で GPU をリクエストする方法については、Autopilot に GPU ワークロードをデプロイするをご覧ください。
ワークロードの分離と期間延長のリソース リクエスト
Autopilot を使用すると、次のような方法を使用して Kubernetes のスケジュール設定と強制排除の動作を操作できます。
- taint と toleration とノードセレクタを使用して、特定の Pod が特定のノードにのみ配置されるようにします。詳細については、GKE でワークロードの分離を構成するをご覧ください。
- Pod の反アフィニティを使用して、Pod が同じノード上に配置されないようにします。これらのメソッドを使用してスケジューリング動作を制御するワークロードのデフォルトと最小のリソース リクエストは、使用しないワークロードよりも高くなります。
- アノテーションを使用して、ノードの自動アップグレードとスケールダウン イベントによる強制排除から Pod を最大 7 日間保護します。詳細については、Autopilot Pod の実行時間を延長するをご覧ください。
指定したリクエストが最小値未満の場合、Autopilot の動作は、使用したメソッドに基づいて次のように変化します。
- taint、toleration、セレクタ、期間延長の Pod: Autopilot は、Pod のスケジュールを設定するときにリクエストを増やすように Pod を変更します。
- Pod の反アフィニティ: Autopilot は Pod を拒否し、エラー メッセージが表示されます。
次の表に、デフォルトのリクエストと、指定できる最小のリソース リクエストを示します。構成またはコンピューティング クラスがこのテーブルにない場合、Autopilot は特別な最小値またはデフォルト値を適用しません。
| コンピューティング クラス | リソース | デフォルト | 最小 |
|---|---|---|---|
| 汎用 | CPU | 0.5 vCPU | 0.5 vCPU |
| メモリ | 2 GiB | 0.5 GiB | |
| バランス | CPU | 2 vCPU | 1 vCPU |
| メモリ | 8 GiB | 4 GiB | |
| スケールアウト | CPU | 0.5 vCPU | 0.5 vCPU |
| メモリ | 2 GiB | 2 GiB |
初期コンテナ
初期コンテナは順番に実行され、アプリケーション コンテナを開始する前に、すべての初期コンテナの実行が完了している必要があります。Autopilot クラスタで、初期コンテナの CPU またはメモリ リクエストを指定しない場合、またはリクエストを明示的に 0 に設定した場合、Autopilot は作成時に Pod を変更して、各初期コンテナにリソース リクエストを追加します。各初期コンテナに割り当てられるリクエストは、Pod 内のすべてのアプリケーション コンテナのリクエストの合計に等しくなります。これはデフォルトの動作です。
この動作は Standard クラスタとは異なります。Standard クラスタでは、init コンテナは Pod がスケジュールされているノードで使用可能な未割り当てリソースを使用します。
初期コンテナのリソース割り当ての自動化
init コンテナのリソースの自動割り当ては、Pod の作成時に行われます。Autopilot クラスタの初期コンテナにリソース リクエストを手動で指定しないことをおすすめします。これにより、各コンテナはデフォルトで Pod で使用可能なすべてのリソースを取得できます。
作成後に Pod 内の非初期コンテナのリソース リクエストを変更しても、Autopilot は初期コンテナのリソース リクエストを自動的に調整しません。その結果、Pod の実際のリソース使用量と一致しない料金が発生することがあります。請求額は、Pod の有効なリソース リクエストに基づいて計算されます。これは、次のいずれか大きい方です。
- Pod 内の単一の初期コンテナのリソース リクエストの最大値。
- Pod 内のすべてのアプリケーション コンテナのリクエストの合計。
詳細については、Autopilot での自動リソース管理をご覧ください。
初期コンテナのリソースを手動で割り当てる
費用とリソースを管理するために、アプリケーション コンテナの既存のリソース リクエストを変更する必要がある場合は、次のいずれかの方法で初期コンテナ リクエストを調整することをおすすめします。
- Pod の新しい合計リクエストに合わせて、初期コンテナのリソース リクエストを手動で更新します。リソース リクエストを手動で指定する場合は、次の点を考慮してください。
- Pod の合計リソースよりも少ないリクエストは、初期コンテナを制限できます。
- Pod の合計リソースを超えるリクエストは、コストの増加につながる可能性があります。
- リソース リクエストを削除して、Autopilot で再計算できるようにします。Autopilot は、Pod 内のすべてのアプリケーション コンテナによってリクエストされた現在の合計リソースに基づいて、各初期コンテナにリソースを再割り当てします。
Autopilot でリソース制限を設定する
Kubernetes では、Pod 仕様のリソースに requests と limits の両方を設定できます。Pod の動作は、次の表に示すように、limits が requests と異なるかどうかによって異なります。
| 値の設定 | Autopilot の動作 |
|---|---|
requests は limits と等しい |
Pod は Guaranteed QoS クラスを使用します。 |
requests は設定、limits は未設定 |
動作は、クラスタがバーストをサポートしているかどうかによって異なります。
クラスタがバーストをサポートしているかどうかを確認するには、GKE でのバーストの可用性をご覧ください。 |
requests は未設定、limits は設定 |
Autopilot は、requests を limits の値に設定します。これは Kubernetes のデフォルトの動作です。変更前: resources:
limits:
cpu: "400m"変更後: resources:
requests:
cpu: "400m"
limits:
cpu: "400m" |
requests は limits より小さい |
動作は、クラスタがバーストをサポートしているかどうかによって異なります。
クラスタがバーストをサポートしているかどうかを確認するには、GKE でのバーストの可用性をご覧ください。 |
requests は limits より大きい |
Autopilot は、requests を limits の値に設定します。変更前: resources:
requests:
cpu: "450m"
limits:
cpu: "400m"変更後: resources:
requests:
cpu: "400m"
limits:
cpu: "400m" |
requests は未設定、limits は未設定 |
Autopilot は、
クラスタがバーストをサポートしているかどうかを確認するには、GKE でのバーストの可用性をご覧ください。 |
ほとんどの場合、ワークロードに適切なリソース リクエストと同等の上限を設定します。
起動時やトラフィックの増加時など、定常状態よりも一時的に多くのリソースを必要とするワークロードの場合は、リクエストよりも高い上限を設定して Pod をバーストできるようにします。詳細については、GKE で Pod バーストを構成するをご覧ください。
Autopilot での自動リソース管理
ワークロードに指定したリソース リクエストが許可された範囲外の場合、または一部のコンテナ用のリソースをリクエストしない場合、Autopilot は、許可された範囲に適合するようにワークロード構成を変更します。Autopilot は、リクエストが指定されていないコンテナにデフォルト値を適用したうえで、リソース比率とリソースのスケールアップ要件を計算します。
- リクエストがない: 一部のコンテナでリソースをリクエストしない場合、Autopilot はコンピューティング クラスまたはハードウェア構成のデフォルトのリクエストを適用します。
- CPU とメモリの比率: Autopilot は、小さい方のリソースをスケールアップして、比率が許容範囲内になるようにします。
- エフェメラルストレージ: Autopilot は、各コンテナで必要な最小サイズを満たすようにエフェメラルストレージ リクエストを変更します。すべてのコンテナにわたるストレージ リクエストの累積値は、最大許容値を超えることはできません。1.28.6-gke.1317000 より前では、値が最大値を超えると、Autopilot はリクエストされたエフェメラル ストレージをスケールダウンします。バージョン 1.28.6-gke.1317000 以降では、Autopilot はワークロードを拒否します。
- 最小数を下回るリクエスト: 選択したハードウェア構成で許容される最小リソース数よりも少ないリソースをリクエストすると、Autopilot は、少なくとも最小リソース値をリクエストするように Pod を自動的に変更します。
デフォルトでは、Autopilot が最小またはデフォルトのリソース値を満たすようにリソースを自動的にスケーリングすると、GKE は追加の容量を Pod マニフェストの最初のコンテナに割り当てます。GKE バージョン 1.27.2-gke.2200 以降では、Pod マニフェストの annotations フィールドに次のコードを追加して、追加のリソースを特定のコンテナに割り当てるように GKE に指示できます。
autopilot.gke.io/primary-container: "CONTAINER_NAME"
CONTAINER_NAME は、コンテナの名前に置き換えます。
リソースの変更の例
次のシナリオ例では、実行中の Pod とコンテナの要件を満たすように Autopilot がワークロード構成を変更する方法を示します。
単一コンテナで 0.05 vCPU 未満の場合
| コンテナ数 | 元のリクエスト | 変更されたリクエスト |
|---|---|---|
| 1 | CPU: 30 mCPU メモリ: 0.5 GiB エフェメラル ストレージ: 10 MiB |
CPU: 50 mCPU メモリ: 0.5 GiB エフェメラル ストレージ: 10 MiB |
複数のコンテナの合計 CPU が 0.05 vCPU 未満の場合
| コンテナ数 | 元のリクエスト | 変更されたリクエスト |
|---|---|---|
| 1 | CPU: 10 mCPU メモリ: 0.5 GiB エフェメラル ストレージ: 10 MiB |
CPU: 30 mCPU メモリ: 0.5 GiB エフェメラル ストレージ: 10 MiB |
| 2 | CPU: 10 mCPU メモリ: 0.5 GiB エフェメラル ストレージ: 10 MiB |
CPU: 10 mCPU メモリ: 0.5 GiB エフェメラル ストレージ: 10 MiB |
| 3 | CPU: 10 mvCPU メモリ: 0.5 GiB エフェメラル ストレージ: 10 MiB |
CPU: 10 mCPU メモリ: 0.5 GiB エフェメラル ストレージ: 10 MiB |
| Pod リソースの合計 | CPU: 50 mCPU メモリ: 1.5 GiB エフェメラル ストレージ: 30 MiB |
単一コンテナで、リクエストされた CPU に対してメモリが低すぎる場合
この例では、メモリが CPU の量に対して少なすぎます（最小比は 1 vCPU : 1 GiB）。CPU とメモリの許容最小比は 1:1 です。この値より小さい場合は、メモリ リクエストが引き上げられます。
| コンテナ数 | 元のリクエスト | 変更されたリクエスト |
|---|---|---|
| 1 | CPU: 4 vCPU メモリ: 1 GiB エフェメラル ストレージ: 10 MiB |
CPU: 4 vCPU メモリ: 4 GiB エフェメラル ストレージ: 10 MiB |
| Pod リソースの合計 | CPU: 4 vCPU メモリ: 4 GiB エフェメラル ストレージ: 10 MiB |
次のステップ
- Autopilot ワークロード内のコンピューティング クラスを選択する方法を確認する。
- サポートされている Autopilot コンピューティング クラスについて確認する。
- Autopilot Pod で GPU を選択する方法を確認する。