このページでは、垂直 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 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 に手動で適用できます。
リソース ポリシー
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 またはメモリの需要が急激に変動するワークロードには、代わりに HorizontalPodAutoscaler を使用します。
- 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
| フィールド | |
|---|---|
containerRecommendation |
個々のコンテナに関するリソース推奨値からなる配列。 |
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 自動スケーリングの構成方法を学習する。
- 水平 Pod 自動スケーリングの詳細を確認する。
- クラスタ オートスケーラーの詳細を確認する。
- 水平 Pod 自動スケーリングを構成する方法を学習する。
- 指標に基づいて Pod の自動スケーリングを最適化する方法を確認する。