このページでは、垂直 Pod 自動スケーリングを使用して、リソース割り当ての分析と最適化を行い、Google Kubernetes Engine（GKE）でワークロードの効率を改善する方法について説明します。ワークロードのリソース使用状況の経時的な変化を分析することで、最適化の推奨事項を取得し、Pod 内のコンテナの CPU リクエスト、メモリ リクエスト、上限を自動調整できます。
このページでは、垂直 Pod 自動スケーリングの仕組み、そのメリットと制限事項、使用に関するベスト プラクティスについて説明します。また、VerticalPodAutoscaler カスタム リソースとそれに関連するタイプの API リファレンスを提供します。
このページは、クラウド リソースのプロビジョニングと構成、ワークロードのデプロイ、アプリケーションのスケーリング管理を行うオペレーターとデベロッパーを対象としています。一般的なロールの詳細については、GKE ユーザーの一般的なロールとタスクをご覧ください。
このページを読む前に、Kubernetes のリソース リクエストと上限について理解しておいてください。
リソース使用量の急増に対応して迅速なスケーリングが必要な場合は、HorizontalPodAutoscaler を使用します。
自動スケーリングのベスト プラクティスについては、コストが最適化された Kubernetes アプリケーションを GKE で実行するためのベスト プラクティスをご覧ください。
垂直 Pod 自動スケーリングを使用する理由
垂直 Pod 自動スケーリングには次のような利点があります。
- ワークロードに適切なリソース リクエストと制限を設定することで、安定性とコスト効率が向上します。Pod のリソースサイズがワークロードに必要なサイズよりも小さい場合、アプリケーションが抑制されたり、メモリ不足エラーのために失敗したりする可能性があります。リソースはサイズが大きすぎると無駄に消費され、結果として請求額も大きくなります。
- Pod が必要な分のリソースのみを使用するため、クラスタノードを効率的に利用できます。
- Pod は、適切な量のリソースが利用可能なノードにスケジュールされます。
- CPU リクエストやメモリ リクエストの適切な値を求めるために、時間のかかるベンチマーク タスクを実施する必要がありません。
- オートスケーラーによって時間の経過とともに CPU リクエストとメモリ リクエストが自動的に調整されるため、人手によるメンテナンス時間が短縮されます。
- 垂直 Pod 自動スケーリングは、長時間実行される同種ワークロードで最適に機能します。
GKE の垂直 Pod 自動スケーリングには、オープンソース Kubernetes オートスケーラーに比べて次のような利点があります。
- 推奨サイズを決定する際は、ノードサイズとリソースの割り当ての最大量を考慮する必要があります。
- クラスタの容量を調整するようにクラスタ オートスケーラーに通知します。
- 過去のデータを使用します。これには、VerticalPodAutoscaler を有効にする前に収集された指標も含まれます。
- ワーカーノードにデプロイする代わりに、VerticalPodAutoscaler Pod をコントロール プレーン プロセスとして実行します。
垂直 Pod 自動スケーリングの仕組み
垂直 Pod 自動スケーリングを使用すると、Pod に必要な CPU リソースとメモリリソースを分析して設定できます。Pod 内のコンテナに最新の CPU のリクエストと制限やメモリのリクエストと制限を設定する代わりに、垂直 Pod 自動スケーリングを構成して CPU とメモリのリクエストおよび制限の推奨値を指定します。これらの推奨値は、Pod を手動で更新するときに使用できます。または、値を自動的に更新するように垂直 Pod 自動スケーリングを構成することもできます。
垂直 Pod 自動スケーリングは、Autopilot クラスタではデフォルトで有効になっています。
Kubernetes オープンソースの VerticalPodAutoscaler との関係
GKE の垂直 Pod 自動スケーリングは、オープンソースの Kubernetes VerticalPodAutoscaler API をベースにしていますが、GKE 固有の別の実装です。GKE の実装は、独自の Recommender を使用してスケーリングするように設計されていますが、オープンソース バージョンで定義されているものと同じ VerticalPodAutoscaler API の種類とフィールドを維持しています。
詳細については、垂直 Pod 自動スケーリングに関する Kubernetes のドキュメントをご覧ください。
垂直 Pod 自動スケーリングのモード
異なる更新モードを適用することで、垂直 Pod 自動スケーリングがリソースの変更をどのように適用するかを構成できます。
Auto（Recreate）モード
Recreate モードでは、垂直 Pod 自動スケーリングにより、Pod のリソース リクエストを変更する必要が生じると、その Pod が強制排除されます。1.33 より前のバージョンの Kubernetes の制限により、実行中の Pod のリソース リクエストを変更する唯一の方法は Pod を再作成することであるため、Pod の強制排除が必要になります。
再作成する Pod の数を制限するには、Pod Disruption Budget を使用します。クラスタが新しいサイズのワークロードを確実に処理できるようにするには、クラスタ オートスケーラーとノード自動プロビジョニングを使用します。
中断時間を最小限に抑えるため、更新の前に垂直 Pod 自動スケーリングからクラスタ オートスケーラーに通知がなされ、ワークロードを再作成する前に、サイズ変更されたワークロードに必要なリソースが提供されます。
Initial モード
Initial が有効になっている場合は、Pod の作成時にのみリソース リクエストが割り当てられます。Pod の作成後にリソース リクエストが変更されることはありません。
InPlaceOrRecreate モード
InPlaceOrRecreate モードは、サービスの中断を短縮することを狙いとしており、Pod を再作成せずに Pod リソースの更新を試みます。
InPlaceOrRecreate モードを使用するには、VerticalPodAutoscaler オブジェクトで spec.updatePolicy.updateMode フィールドを "InPlaceOrRecreate" に設定します。このモードでは、ワークロード マニフェストで定義された resizePolicy フィールドを使用して、リソースの変更に再起動が必要かどうかを判断します。resizePolicy フィールドが定義されていない場合、CPU とメモリのデフォルトは NotRequired になります。つまり、インプレース更新が試行されます。
OOM（メモリ不足）イベントが原因でコンテナが終了した場合、InPlaceOrRecreate モードの垂直 Pod 自動スケーリングは Auto モードと同様に動作し、障害から学習します。クラッシュによってトリガーされた後続の Pod の再作成時に、垂直 Pod 自動スケーリングは、OOM エラーの即時繰り返しを防ぐために、安全バッファ（通常は 20% の追加メモリまたは 100 MB のいずれか大きい方）を含む推奨事項を適用します。
InPlaceOrRecreate モードは、Kubernetes バージョン 1.34.0-gke.2201000 以降で使用できます。
InPlaceOrRecreate モードのフォールバック シナリオ
垂直 Pod 自動スケーリングによりインプレース更新が不可能と判断された場合は、Recreate モードの動作に戻ります。つまり、変更を適用するために Pod が強制排除されてから再作成されます。垂直 Pod 自動スケーリングが再作成にフォールバックする一般的なシナリオには、次のようなものがあります。
- ノード容量が不足している: 更新されたリソース リクエストが現在のノードの割り当て可能な容量を超えており、更新をインプレースでスケジュールできない（「実行不可能」または「遅延」状態がタイムアウトより長く続く）。
- QoS クラスの変更: リソースの更新により、Pod の Quality of Service（QoS）クラスが変更されます（
BurstableからGuaranteedなど）。 RestartContainerポリシー: 垂直 Pod 自動スケーリングが変更しようとしているリソースに対して、Pod のresizePolicyフィールドがRestartContainerに設定されている。- タイムアウト: インプレース更新リクエストが保留状態のまま長時間経過している。
Off モード
Off モードでは、垂直 Pod 自動スケーリングによって Pod に変更が自動的に適用されることはありません。過去の使用量に基づく CPU とメモリのリクエストと制限の推奨値は、どちらも引き続き確認できますが、これらの推奨値は自動的には適用されません。必要に応じて、推奨値を Pod に手動で適用できます。
CPU 起動ブースト
CPU 起動ブーストは、初期化中に CPU リクエストを一時的に増やし、ベースライン レベルにサイズを戻すことで、アプリケーションの起動を高速化し、費用対効果を向上させます。
CPU 起動ブーストの構成方法については、CPU 起動ブーストを使用してアプリケーションの起動を高速化するをご覧ください。
CPU 起動ブーストの仕組み
CPU 起動ブーストは、コンテナのベースライン CPU リクエストに基づいて、一時的なリソースの増加を計算します。Pod は、起動フェーズ後にこのベースライン リクエスト レベルに戻ります。
ブーストは、このベースライン リクエストを乗数または固定量で増加させます。この引き上げられたリクエストは、Pod の準備が整うまでアクティブなままになります。その後、GKE は CPU リクエストをベースライン レベルに戻します。
ブーストのライフサイクルを理解する
起動ブースト プロセスは、次の 3 つのフェーズで構成されています。
- アドミッション フェーズ: Pod のアドミッション中に、VPA アドミッション Webhook がリクエストをインターセプトし、GKE が Pod をスケジュールする前にブーストされた CPU 値を挿入します。
- 起動フェーズ: アプリケーションは、一時的に引き上げられた CPU 割り当てを使用して初期化され、初期化のスロットリングを回避します。
- ブースト解除フェーズ: Pod が
Readyステータスに達し、durationSeconds期間が経過すると、VPA は CPU リクエストをインプレースでベース値にダウンスケールします。
ブーストされたワークロードの更新モードを選択する
CPU 起動ブーストは、VPA の継続的なリソース管理の有無にかかわらず構成できます。VPA の継続的なリソース管理により、起動フェーズの終了後に Pod のリソース リクエストが自動調整されます。設定を選択するには、VPA オブジェクトの updateMode フィールドを設定します。VPA 更新モードの詳細については、垂直 Pod 自動スケーリング モードをご覧ください。
updateMode: "Off": VPA は、Pod アドミッション（Pod 作成のフェーズ）中の初期ブーストと、起動後のダウンスケールのみを管理します。コンテナの定常状態のリソース リクエストは変更されません。updateMode: "Auto"、"Recreate"、"InPlaceOrRecreate": VPA は起動ブーストを管理し、継続的な使用状況に基づいて Pod のリソース リクエストを自動的に調整し続けます。
CPU ブースト リソースの割り当ての計算方法
GKE は、一時的にブーストされた CPU リクエストを次のように計算します。
ベース CPU を決定する: ベースライン CPU リクエストは、VPA の
updateModeフィールドによって異なります。Auto、Recreate、InPlaceOrRecreate: ベースライン CPU リクエストは VPA の推奨値です。推奨値が存在しない場合、GKE は Pod 仕様で定義された CPU リクエストにフォールバックします。Off: ベースライン CPU リクエストは、Pod 仕様のリクエスト値です。
ブーストされた CPU を計算する: 計算は、ブースト構成の
typeフィールドで指定した計算方法によって異なります。Factor: ベース CPU リクエストに乗数を適用します。ブーストされた CPU = ベース CPU ×
factorQuantity: 基本 CPU リクエストに絶対 CPU 数量を追加します。ブーストされた CPU = ベース CPU +
quantity
最終的な CPU リクエストは、クラスタモードによって異なります。
- Standard クラスタ: 最終的な CPU リクエストは、ブーストされた CPU 値です。
- Autopilot クラスタ: 最終的な CPU リクエストは、割り当てられた Pod メモリに許可される最大 CPU で上限が設定された、ブーストされた CPU 値です。
ブースト中の CPU 上限の動作を理解する
GKE による CPU 上限の処理方法は、containerResourcePolicy の controlledValues 設定によって異なります。
RequestsAndLimits（デフォルト）: GKE は CPU リクエストと上限の両方をブーストし、元の比率を維持してコンテナの Quality of Service（QoS）クラスを維持します。RequestsOnly: GKE は CPU リクエストのみをブーストします。GKE は、QoS を維持するために、定義された CPU 上限のすぐ下でブーストされたリクエストを制限します。
Autopilot クラスタに関する考慮事項
GKE Autopilot は特定の CPU とメモリの比率範囲と最小 Pod サイズを適用するため、GKE は Pod のアドミッション中にブーストを評価してコンプライアンスを確保します。ブーストは、次のシナリオで変更または無視されることがあります。
- Autopilot の最小値: ブーストされたリクエストが Autopilot ワークロードの最小 CPU 要件（汎用 Pod の場合は 50m など）を下回る場合、GKE はブーストを適用せず、標準の最小値を適用します。
- 比率の上限（部分的なブーストまたはスキップされたブースト）: ブーストされた CPU リクエストが必要な CPU とメモリの比率の範囲を超える場合、GKE は、割り当てられたメモリを考慮して、ブーストを最大値に制限します。元の Pod リクエストがすでに最大許容 CPU / メモリ比率を使用している場合、GKE はメモリのサイズ変更を回避するためにブーストをスキップします。
- Scale-Out ComputeClass: Scale-Out ComputeClass は、1:4（CPU:メモリ）の厳密な比率を適用します。メモリを増やさずにスケールアウト Pod の CPU をブーストしようとすると、GKE がブーストを無視する可能性があります。
リソース ポリシー
ContainerResourcePolicy を使用すると、垂直 Pod 自動スケーリングが特定のコンテナの推奨事項を生成する方法をカスタマイズできます。このポリシーを使用すると、制約を設定して、スケーリングするリソースを制御できます。
最小値と最大値
コンテナのリソースの最小値（minAllowed）と最大値（maxAllowed）を指定できます。
minAllowed: 垂直 Pod 自動スケーリングは、この上限を下回る値を推奨しません。この上限は、ベースライン レベルのパフォーマンスを確保したり、アプリケーション固有の要件を満たしたりするのに役立ちます。maxAllowed: 垂直 Pod 自動スケーリングは、この上限を超える値を推奨しません。この上限は、コストを管理したり、1 つのコンテナが過剰なノードリソースを消費しないようにするのに役立ちます。
制御対象リソース
デフォルトでは、垂直 Pod 自動スケーリングは CPU とメモリの両方の推奨値を計算します。controlledResources フィールドを使用して、自動スケーリングするリソースを指定できます。たとえば、メモリのみの推奨事項を提供するようにオートスケーラーを構成し、CPU リクエストを変更しないようにできます。
制限事項
- CPU で垂直 Pod 自動スケーリングと水平 Pod 自動スケーリングを併用するには、VPA を使用した HPA のサイズ適正化（プレビュー）または多次元 Pod 自動スケーリングを使用します。また、カスタム指標と外部指標でも、水平 Pod 自動スケーリングと垂直 Pod 自動スケーリングを併用できます。
- ワークロードの実際のメモリ使用量の可視性が制限されているので、JVM ベースのワークロードには垂直 Pod 自動スケーリングを使用できません。
- GKE バージョン 1.35.1 以前では、垂直 Pod 自動スケーリングのデフォルト設定では、Deployment が Pod を更新されたリソース値に置き換えるために、最小レプリカ数は 2 に設定されています。バージョン 1.35.2 以降では、デフォルトは 1 つの最小レプリカです。バージョン 1.22 以降では、PodUpdatePolicy フィールドの
minReplicasフィールドに値を指定することで、この設定をオーバーライドできます。 - 垂直 Pod 自動スケーリングの
InPlaceOrRecreate更新モードを使用している場合に、インプレース更新が不可能なときには（たとえば、ノード容量を超えて Pod をアップスケールしようとしたとき）、推奨事項を適用するために Pod が強制排除されてから再作成されます。再作成を回避するために仕様でresizePolicyフィールドが設定されている Pod でも、強制排除と再作成が行われます。この動作は、最小リソースと CPU: メモリ比率の制約の適用時など、Autopilot のサイズ変更リクエストで発生します。 - 垂直 Pod 自動スケーリングには、Deployment、StatefulSet、ReplicaSet、ReplicationControllers など、Pod を管理するワークロード オブジェクトが必要です。Pod の再作成プロセスを管理するためには、ワークロード コントローラが必要であるため、スタンドアロン Pod で垂直 Pod 自動スケーリングを使用することはできません。
- 垂直 Pod 自動スケーリングは、コンテナレベルのリソース リクエストと上限（
spec.containers[].resources）のみを対象に推奨事項を生成し、更新を適用します。垂直 Pod 自動スケーリングは、Pod レベルのリソース仕様（spec.resources）をサポートしていません。
ベスト プラクティス
VerticalPodAutoscalerオブジェクトの数を制限する。クラスタの更新の中断を回避するには、クラスタあたりのVerticalPodAutoscalerオブジェクト数を 1,000 未満に保持する必要があります。- 垂直 Pod 自動スケーリングは、長時間実行される同種ワークロードで最適に機能します。
- 長時間実行: 24 時間以上実行されるワークロード。垂直 Pod 自動スケーリングでは、信頼性の高い推奨事項を生成するために、大量の過去のデータが必要です。
AutoモードまたはRecreateモードでは、通常、Pod が 24 時間以上経過した後に更新が行われます。これにより、Pod の頻繁な再起動やチャーンを防ぐことができます。 - 均一: 単一の
VerticalPodAutoscalerオブジェクトの対象となる Pod（Deployment 内のすべてのレプリカなど）は、同様のリソース消費パターンを示す必要があります。垂直 Pod 自動スケーラーは、すべての対象 Pod の使用状況データを集計して推奨事項を生成します。レプリカの使用状況が不均一な場合（たとえば、一部の Pod がアイドル状態で、他の Pod に大きな負荷がかかっている場合）、垂直 Pod 自動スケーラーは、アイドル状態の Pod を過剰にプロビジョニングするか、ビジー状態の Pod を過少にプロビジョニングする推奨事項を提示することがあります。
- 長時間実行: 24 時間以上実行されるワークロード。垂直 Pod 自動スケーリングでは、信頼性の高い推奨事項を生成するために、大量の過去のデータが必要です。
- 需要が急増するワークロードには、水平 Pod 自動スケーリングを使用します。垂直 Pod 自動スケーリングは、定常状態のサイズ適正化を目的として設計されており、短時間の急激なリソースの急増に対応するソリューションではありません。トラフィックや CPU またはメモリの需要が急激に変動するワークロードの場合は、代わりに水平 Pod 自動スケーリングを使用します。
- OOM 保護を活用する。垂直 Pod 自動スケーラーはリアクティブですが、メモリ不足（OOM）イベントに対する自動保護機能が含まれています。Pod が
OOMKilledの場合、VerticalPodAutoscaler はイベントをすぐに監視し、メモリの推奨値を約 20%（または 100 MB のいずれか大きい方）増やして、Pod の再作成時の安定性を向上させます。OOM イベントの詳細については、OOM イベントのトラブルシューティングをご覧ください。
API リファレンス
これは v1 API リファレンスです。このバージョンの API を使用することを強くおすすめします。
VerticalPodAutoscaler v1 autoscaling.k8s.io
| フィールド | |
|---|---|
|
API グループ、バージョン、種類。 |
metadata |
標準のオブジェクト メタデータ。 |
spec |
|
status |
直近に観測された |
VerticalPodAutoscalerSpec v1 autoscaling.k8s.io
| フィールド | |
|---|---|
targetRef |
Deployment や StatefulSet など、オートスケーラーで制御する Pod のセットを管理するコントローラへのリファレンス。スケール サブリソースを含む任意のコントローラで |
updatePolicy |
Pod の起動時に推奨更新を適用するかどうか、また Pod のライフサイクル期間中に推奨更新を適用するかどうかを指定します。 |
resourcePolicy |
個々のコンテナに対する CPU リクエストおよびメモリ リクエストの調整方法に関するポリシーを指定します。リソース ポリシーを使用して、個々のコンテナの推奨事項に制約を設定できます。指定されていない場合、オートスケーラーは、追加の制約なしに、Pod 内のすべてのコンテナの推奨リソースを計算します。 |
recommenders |
この VPA オブジェクトに関する推奨事項を生成する Recommender。GKE によって指定されるデフォルトの Recommender を使用するには、空のままにします。それ以外の場合、リストには、ユーザーが指定する代替 Recommender のエントリを 1 つのみ配置できます。GKE 1.22 以降でサポートされます。 |
VerticalPodAutoscalerList v1 autoscaling.k8s.io
| フィールド | |
|---|---|
|
API グループ、バージョン、種類。 |
metadata |
標準のオブジェクト メタデータ。 |
items |
|
PodUpdatePolicy v1 autoscaling.k8s.io
| フィールド | |
|---|---|
updateMode |
Pod の起動時に推奨更新を適用するかどうか、また Pod のライフサイクル期間中に推奨更新を適用するかどうかを指定します。使用できる値は次のとおりです。
|
minReplicas |
Pod の強制排除を試みる際に存続している必要があるレプリカの最小数（Pod Disruption Budget などの他のチェックは保留になります）。正の値のみを使用できます。デフォルトは、GKE バージョン 1.35.2 以降では |
PodResourcePolicy v1 autoscaling.k8s.io
| フィールド | |
|---|---|
containerPolicies |
個々のコンテナに対するリソース ポリシーの配列。名前付きのコンテナごとに最大で 1 つのエントリを作成できます。また、必要に応じて、個別のポリシーを持たないすべてのコンテナを処理する「containerName = '*'」のワイルドカード エントリを 1 つ指定できます。 |
ContainerResourcePolicy v1 autoscaling.k8s.io
| フィールド | |
|---|---|
containerName |
ポリシーが適用されるコンテナの名前。指定しない場合、そのポリシーはデフォルト ポリシーとして機能します。 |
mode |
コンテナの起動時に推奨アップデートを適用するかどうか、またコンテナのライフサイクル期間中に推奨アップデートを適用するかどうかを指定します。有効な値は「Off」と「Auto」です。値を指定しない場合のデフォルトは「Auto」です。 |
minAllowed |
そのコンテナで許容される CPU リクエストとメモリ リクエストの最小値を指定します。デフォルトでは、適用される最小値はありません。 |
maxAllowed |
そのコンテナで許容される CPU リクエストとメモリ リクエストの最大値を指定します。デフォルトでは、適用される最大値はありません。 |
controlledResources |
|
VerticalPodAutoscalerRecommenderSelector v1 autoscaling.k8s.io
| フィールド | |
|---|---|
name |
このオブジェクトに関する推奨事項の生成を担当する Recommender の名前。 |
VerticalPodAutoscalerStatus v1 autoscaling.k8s.io
| フィールド | |
|---|---|
recommendation |
CPU リクエストおよびメモリ リクエストの最新の推奨値。 |
conditions |
|
RecommendedPodResources v1 autoscaling.k8s.io
| フィールド | |
|---|---|
containerRecommendations |
個々のコンテナに関するリソース推奨値からなる配列。 |
RecommendedContainerResources v1 autoscaling.k8s.io
| フィールド | |
|---|---|
containerName |
推奨値が適用されるコンテナの名前。 |
target |
そのコンテナに対する CPU リクエストとメモリ リクエストの推奨値。 |
lowerBound |
そのコンテナに対する CPU リクエストとメモリ リクエストの推奨値の下限。この値は、アプリケーションが安定して動作するのに十分であるとは限りません。CPU リクエストとメモリ リクエストがこの値に満たない場合、パフォーマンスや可用性に重大な影響を及ぼす可能性があります。 |
upperBound |
そのコンテナに対する CPU リクエストとメモリ リクエストの推奨値の上限。CPU リクエストとメモリ リクエストをこの値より大きくしても、無駄になる可能性があります。 |
uncappedTarget |
オートスケーラーによって計算された最新のリソース推奨値。これは実際のリソース使用量に基づいており、ContainerResourcePolicy は考慮されません。実際のリソース使用量によって、ターゲットが ContainerResourcePolicy に違反する場合、この値は制限付きの推奨値と異なる場合があります。このフィールドは、実際のリソース割り当てには影響しません。ステータスの表示にのみ使用されます。 |
VerticalPodAutoscalerCondition v1 autoscaling.k8s.io
| フィールド | |
|---|---|
type |
記述する状態のタイプ。有効な値は、「RecommendationProvided」、「LowConfidence」、「NoPodsMatched」、「FetchingHistory」です。 |
status |
状態のステータス。有効な値は、「True」、「False」、「Unknown」です。 |
lastTransitionTime |
状態のステータスが最後に遷移した時刻。 |
reason |
最後のステータス遷移の理由。 |
message |
対人可読な文字列で記述された、最後のステータス遷移についての詳細情報。 |
次のステップ
- 垂直 Pod 自動スケーリングの構成方法を確認する。
- VPA を使用して HPA ワークロードを適正化する方法を確認する。
- CPU 起動ブーストを使用してアプリケーションの起動を高速化する方法を確認する。
- 水平 Pod 自動スケーリングの詳細を確認する。
- クラスタ オートスケーラーの詳細を確認する。