このページでは、垂直 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 が強制排除されます。1.33 より前のバージョンの Kubernetes の制限により、実行中の Pod のリソース リクエストを変更する唯一の方法は Pod を再作成することであるため、Pod の強制排除が必要になります。
再作成する Pod の数を制限するには、Pod 停止予算を使用します。クラスタが新しいサイズのワークロードを確実に処理できるようにするには、クラスタ オートスケーラーとノード自動プロビジョニングを使用します。
中断時間を最小限に抑えるため、更新の前に垂直 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 モードのフォールバック シナリオ
インプレース更新が不可能と判断された場合は、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 リクエストをベース値にインプレースでスケールダウンします。
ブーストされたワークロードの更新モードを選択する
VPA の継続的なリソース管理の有無にかかわらず、CPU 起動ブーストを構成できます。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 リクエストと上限の両方を引き上げ、元の比率を維持してコンテナのサービス品質（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 自動スケーリングは、この上限を超える値を推奨しません。この上限は、費用を制御したり、単一のコンテナがノードリソースを過剰に消費するのを防ぐ場合に便利です。
制御対象リソース
デフォルトでは、垂直 Pod 自動スケーリングは CPU とメモリの両方の推奨事項を計算します。controlledResources フィールドを使用して、自動スケーリングするリソースを指定できます。たとえば、メモリのみの推奨事項を提供し、CPU リクエストは変更しないようにオートスケーラーを構成できます。
制限事項
- 水平 Pod 自動スケーリングと垂直 Pod 自動スケーリングを併用する場合、多次元 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 自動スケーリングを使用することはできません。
ベスト プラクティス
VerticalPodAutoscalerオブジェクトの数を制限します。クラスタの更新の中断を回避するには、クラスタあたりのVerticalPodAutoscalerオブジェクト数を 1,000 未満に保持する必要があります。- 垂直 Pod 自動スケーリングは、長時間実行される同種ワークロードで最適に機能します。
- 長時間実行: 24 時間以上実行されるワークロード。垂直 Pod 自動スケーリングでは、信頼性の高い推奨事項を生成するために大量の履歴データが必要です。
AutoモードまたはRecreateモードでは、通常、Pod が 24 時間以上経過してから更新が行われます。これにより、Pod の頻繁な再起動とチャーンを防ぐことができます。 - 同種: 単一の
VerticalPodAutoscalerオブジェクト（Deployment 内のすべてのレプリカなど）によってターゲット設定された Pod は、同様のリソース消費パターンを示す必要があります。垂直 Pod オートスケーラーは、ターゲット Pod 全体の使用状況データを集計して推奨事項を生成します。レプリカの使用量が異種である場合（一部の Pod はアイドル状態、他の Pod は負荷が高いなど）、垂直 Pod 自動スケーラーは、アイドル状態の Pod を過剰にプロビジョニングしたり、ビジー状態の Pod を過少にプロビジョニングしたりする推奨事項を提示する可能性があります。
- 長時間実行: 24 時間以上実行されるワークロード。垂直 Pod 自動スケーリングでは、信頼性の高い推奨事項を生成するために大量の履歴データが必要です。
- 需要が急増するワークロードには、水平 Pod 自動スケーリングを使用します。垂直 Pod 自動スケーリングは、定常状態の適正なサイズ設定を目的としており、リソースの急増に対応するソリューションではありません。トラフィックや CPU またはメモリの需要が急激に変動するワークロードには、代わりに水平 Pod オートスケーラーを使用します。
- OOM 保護を活用します。垂直 Pod 自動スケーラーはリアクティブですが、メモリ不足（OOM）イベントに対する自動保護機能が含まれています。Pod が
OOMKilledの場合、垂直 Pod 自動スケーラーはイベントを直ちに監視し、Pod が再作成されるときの安定性を高めるために、メモリの推奨値を約 20%（または 100 MB のいずれか大きい方）増やします。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 自動スケーリングの構成方法を学習する。
- CPU 起動ブーストを使用してアプリケーションの起動を高速化する方法を学習する。
- 水平 Pod 自動スケーリングの詳細を確認する。
- クラスタ オートスケーラーの詳細を確認する。