Google Kubernetes Engine（GKE）で垂直 Pod 自動スケーリングが想定どおりに機能しない場合、ワークロードが正しくスケーリングされない可能性があります。これらの問題により、アプリケーションが負荷を処理できなくなり、パフォーマンスの問題や停止が発生する可能性があります。新しいリソースの推奨事項で Pod が再起動しない場合や、推奨事項が実際の使用量と一致しない場合があります。
このドキュメントでは、VerticalPodAutoscaler の構成に関する一般的な問題や、予期しない推奨事項を解決する方法について説明します。これらのトラブルシューティングの手順に沿って対応することで、需要に基づいてアプリケーションを効率的かつ確実にスケーリングできます。
この情報は、VerticalPodAutoscaler リソースを構成し、アプリケーションが正しくスケーリングされるようにする必要があるアプリケーション デベロッパーにとって重要です。また、プラットフォーム管理者と運用担当者が、自動スケーリング ワークロードに影響するクラスタ構成の問題をトラブルシューティングする際にも役立ちます。 Cloud de Confiance by S3NS のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE ユーザーのロールとタスクをご覧ください。
VerticalPodAutoscaler の問題を診断する
VerticalPodAutoscaler の問題を診断するには、kubectl または Cloud de Confiance コンソールを使用してステータスと構成を調べます。
VerticalPodAutoscaler の説明を取得する
リアルタイム計算と最近のスケーリングの決定を表示するには、kubectl describe vpa コマンドを使用します。
kubectl describe vpa VPA_NAME -n NAMESPACE_NAME
次のように置き換えます。
VPA_NAME: VerticalPodAutoscaler の名前。NAMESPACE_NAME: VerticalPodAutoscaler の Namespace。
出力は次のようになります。
Name: sample-deployment-vpa
Namespace: default
API Version: autoscaling.k8s.io/v1
Kind: VerticalPodAutoscaler
# Multiple lines are omitted here
Spec:
Target Ref:
API Version: apps/v1
Kind: Deployment
Name: sample-deployment
Update Policy:
Update Mode: Auto
Status:
Conditions:
Last Transition Time: 2025-10-09T10:00:00Z
Message: VPA is fetching history in order to provide recommendation
Reason: FetchingHistory
Status: True
Type: FetchingHistory
Last Transition Time: 2025-10-09T10:05:00Z
Message: VPA pod metrics aren't available yet
Reason: NoMetrics
Status: True
Type: LowConfidence
Last Transition Time: 2025-10-09T10:10:00Z
Message: VPA is able to provide a recommendation
Reason: RecommendationProvided
Status: True
Type: RecommendationProvided
Recommendation:
Container Recommendations:
Container Name: sample-container
Lower Bound:
Cpu: 100m
Memory: 128Mi
Target:
Cpu: 200m
Memory: 256Mi
Upper Bound:
Cpu: 500m
Memory: 512Mi
Events: <none>
出力で、次のメイン セクションを確認します。
Spec:targetRefフィールド（ターゲット ワークロード）やupdatePolicyフィールド（更新の適用方法）など、構成の詳細が表示されます。Status:Conditionsセクション（運用の健全性）とRecommendationセクション（各コンテナ用に生成された CPU とメモリのリソース値）が表示されます。Events: VerticalPodAutoscaler オブジェクトに関連する最近のアクションまたはエラーを一覧表示します。
VerticalPodAutoscaler マニフェストを表示する
VerticalPodAutoscaler の完全な構成と状態を表示するには、kubectl または Cloud de Confiance コンソールを使用して YAML マニフェストを調べます。
コンソール
Cloud de Confiance コンソールで、[オブジェクト ブラウザ] ページに移動します。
[オブジェクトの種類] フィルタのリストをクリックします。
既存の選択をすべてクリアします。
[VerticalPodAutoscaler] を選択して、[OK] をクリックします。
フィルタされたリストで、autoscaling.k8s.io API グループを選択します。
VerticalPodAutoscaler オブジェクトの種類を選択します。
検査する VerticalPodAutoscaler の名前をクリックします。
kubectl
kubectl get vpa VPA_NAME \
-n NAMESPACE_NAME \
-o yaml
次のように置き換えます。
VPA_NAME: VerticalPodAutoscaler の名前。NAMESPACE_NAME: VerticalPodAutoscaler の Namespace。
Cloud de Confiance コンソールで VerticalPodAutoscaler のステータスを確認する
Cloud de Confiance コンソールでワークロードの VerticalPodAutoscaler ステータスを検査するには:
[ワークロード] ページに移動します。
ワークロードの名前をクリックします。
[詳細] タブに移動し、[自動スケーラー] セクションを見つけます。
VerticalPodAutoscaler 行で、指標の収集と構成の健全性に関するステータス メッセージを確認します。
意思決定ログを収集する
VerticalPodAutoscaler の計算と決定に関する詳細な分析情報を取得するには、Cloud Logging で垂直 Pod 自動スケーラーの決定ログ（プレビュー）を有効にします。
これらのログは、UPDATE_RECOMMENDATION、EVICT_POD、APPLY_RECOMMENDATION_IN_PLACE、APPLY_RECOMMENDATION_ON_EVICTION などのイベントをキャプチャします。
決定ログを有効にして検査するには、垂直 Pod 自動スケーラー イベントログを収集するをご覧ください。
VerticalPodAutoscaler の推奨事項のトラブルシューティング
以降のセクションでは、VerticalPodAutoscaler が推奨事項を生成できない場合や、期待どおりの推奨事項を生成できない場合の問題について説明します。
VerticalPodAutoscaler が推奨事項を提供していない
症状:
- VerticalPodAutoscaler マニフェストの
Status.Recommendationフィールドが空です。 - VerticalPodAutoscaler マニフェストの条件に、
NoPodsMatched、FetchingHistory、LowConfidenceのステータス条件が表示されます。
原因:
- ターゲットが正しくない: VerticalPodAutoscaler マニフェストの
spec.targetRefフィールドが、同じ Namespace 内の既存のワークロードを指していない。 - Initial metric collection: VerticalPodAutoscaler が最近作成され、過去のリソース使用状況データを収集している。
metrics-serverコンポーネントの問題: VerticalPodAutoscaler はmetrics-serverコンポーネントの指標に依存しています。metrics-serverコンポーネントが正しく機能していない場合、VerticalPodAutoscaler は使用状況データを取得できません。- 実行中の Pod がない: ターゲット ワークロードに、VerticalPodAutoscaler が監視する実行中または準備完了の Pod がありません。
解決策:
targetRefフィールドを確認する:spec.targetRefセクションのkind、name、apiVersionフィールドの値を確認します。すべての値がターゲット ワークロードと一致していることを確認します。ワークロードが存在することを確認するには、次のコマンドを実行します。kubectl get KIND WORKLOAD_NAME \ -n NAMESPACE_NAME次のように置き換えます。
KIND: ワークロード タイプ（deployment、statefulsetなど）。WORKLOAD_NAME: ワークロードの名前。NAMESPACE_NAME: ワークロードの Namespace。
指標の収集に時間をかける: 新しい VerticalPodAutoscaler リソースでは、データの収集に時間がかかります。
Status.Conditionsフィールドをモニタリングして、RecommendationProvidedステータス条件への移行を確認します。metrics-serverコンポーネントを確認します。metrics-serverコンポーネントの Pod が実行されていることを確認します。kubectl get pods -n kube-system | grep metrics-serverPod が実行されていない場合や、再起動回数が多い場合は、ログを確認します。
kubectl logs -n kube-system -l k8s-app=metrics-servererror、failed、unable to fetchなどの単語を含むログエントリは、指標の収集に関する問題を示しています。
Pod が実行されていることを確認する: ターゲット ワークロードに、実行中で準備完了状態の Pod が少なくとも 1 つあることを確認します。
VerticalPodAutoscaler の推奨事項が予期しない
症状:
Status.Recommendationセクションの CPU またはメモリの値が、想定よりも高いか低い。- 推奨事項が、観測されたワークロードのリソース消費量と一致しない。
原因:
- ワークロードの動作の変更: VerticalPodAutoscaler の推奨事項は、過去の使用状況に基づいています。アプリケーションの消費パターンの最近の変化がまだ反映されていない可能性があります。
- ワークロードの特性: 使用パターンが急激に変化する短期間のジョブやワークロードでは、最適な推奨事項が提示されないことがあります。
- 競合する VerticalPodAutoscaler リソース: 同じワークロードをターゲットにするように複数の VerticalPodAutoscaler リソースが構成されている可能性があります。
解決策:
- 調整時間を確保する: アプリケーションの変更後に VerticalPodAutoscaler が新しい使用パターンを学習する時間を確保します。
- 適合性を評価する: VerticalPodAutoscaler または Horizontal Pod Autoscaler がワークロード タイプに最適かどうかを評価します。
競合する VerticalPodAutoscaler リソースを確認する。
クラスタ内のすべての VerticalPodAutoscaler リソースを一覧表示します。
kubectl get vpa --all-namespaces各リソースの
spec.targetRefフィールドを確認します。複数の VerticalPodAutoscaler リソースが同じワークロードをターゲットにしている場合は、競合するリソースを削除または調整して、1 つの VerticalPodAutoscaler のみが特定のワークロードをターゲットにするようにします。
Pod リソースの更新に関する問題のトラブルシューティング
以降のセクションでは、推奨事項が存在するものの、ターゲット Pod に適用されない問題について説明します。
Pod のリソース リクエストが更新されない
症状:
- VerticalPodAutoscaler マニフェストの
Statusセクションに推奨事項が表示されますが、Pod マニフェストのresources.requestsフィールドは更新されません。 AutoまたはRecreate更新モードを使用しているときに、推奨事項を適用するために Pod が再起動されない。
原因:
updateModeフィールドはOffです。spec.updatePolicy.updateModeフィールドがOffに設定されている場合、VerticalPodAutoscaler は推奨事項を生成しますが、適用しません。- ワークロードにレプリカが 1 つしかない:
AutoまたはRecreateの更新モードでは、VerticalPodAutoscaler は、ダウンタイムを回避するために、単一レプリカのワークロードを強制排除しません。
解決策:
updateModeフィールドを確認する: VerticalPodAutoscaler マニフェストを変更して、spec.updatePolicy.updateModeフィールドをAuto、Recreate、またはInPlaceOrRecreateに設定します。- レプリカ数を増やす:
AutoまたはRecreate更新モードを使用するワークロードの場合、Deployment または StatefulSet に複数のレプリカがあることを確認します。
インプレース アップデートが失敗するか、延期されたままになる
症状:
- コンテナのインプレース サイズ変更が完了しないか、延期されたままになる。
原因:
- ノード容量の不足: 更新されたリソース リクエストの容量がノードに不足している場合、インプレース サイズ変更オペレーションは延期されます。
解決策:
遅延サイズ変更のステータスとノード容量を確認する。
サイズ変更が 5 分以上延期された場合、VerticalPodAutoscaler はフォールバックして、推奨事項を適用するために Pod を強制排除して再作成します。遅延更新のステータスを確認する手順は次のとおりです。
Pod アノテーションを調べて、
vpaInPlaceUpdatedアノテーションが"true"に設定されているかどうかを確認します。metadata: annotations: vpaInPlaceUpdated: "true" vpaUpdates: 'Pod resources updated by sample-deployment-vpa: container 0: cpu request, memory request'遅延されたサイズ変更イベントの
status.conditionsフィールドを調べて、遅延ステータスを確認します。status: conditions: - type: PodResizePending status: "True" reason: Deferred message: "Node didn't have enough resource: ..."Pod の Kubernetes イベントを調べます。
kubectl get events -n NAMESPACE_NAME --field-selector involvedObject.kind=Pod,involvedObject.name=POD_NAME次のように置き換えます。
NAMESPACE_NAME: Pod の名前空間。POD_NAME: Pod の名前。
ResizedPod（インプレース更新の成功）またはEvictedByVPA（再作成へのフォールバック）のいずれかの理由を含むイベントを探します。
次のステップ
このドキュメントで問題を解決できない場合は、サポートを受けるで、次のトピックに関するアドバイスなど、詳細なヘルプをご覧ください。
- Cloud カスタマーケアに問い合わせて、サポートケースを登録する。
- StackOverflow で質問する、
google-kubernetes-engineタグを使用して類似の問題を検索するなどして、コミュニティからサポートを受ける。#kubernetes-engineSlack チャネルに参加して、コミュニティ サポートを利用することもできます。 - 公開バグトラッカーを使用して、問題の報告や機能リクエストの登録を行う。