Google Kubernetes Engine（GKE）で垂直 Pod 自動スケーリングが想定どおりに機能しない場合、ワークロードが正しくスケーリングされない可能性があります。この問題により、アプリケーションが負荷を処理できなくなり、パフォーマンスの問題や停止が発生する可能性があります。新しいリソースの推奨値で Pod が再起動しない場合や、推奨値が実際の使用量と一致しない場合があります。
このドキュメントでは、VerticalPodAutoscaler の構成や予期しない推奨値に関する一般的な問題を解決する方法について説明します。これらのトラブルシューティングの手順に沿って対応することで、需要に基づいてアプリケーションを効率的かつ確実にスケーリングできます。
この情報は、VerticalPodAutoscaler リソースを構成し、アプリケーションが正しくスケーリングされるようにする必要があるアプリケーション デベロッパーにとって重要です。また、プラットフォーム管理者と運用担当者が、自動スケーリング ワークロードに影響するクラスタ構成の問題をトラブルシューティングする際にも役立ちます。 Google Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、 一般的な GKE ユーザーのロールとタスクをご覧ください。
VerticalPodAutoscaler の問題を診断する
VerticalPodAutoscaler の問題を診断するには、ステータスと
構成を kubectl または Google Cloud コンソールを使用して検査します。
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 の完全な構成とステータスを表示するには、
YAML マニフェストを kubectl または Google Cloud コンソールを使用して検査します。
コンソール
Google Cloud コンソールで、[オブジェクト ブラウザ] ページに移動します。
[オブジェクトの種類] フィルタリストをクリックします。
既存の選択をすべてクリアします。
[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。
コンソール Google Cloud で VerticalPodAutoscaler のステータスを確認する
Google Cloud コンソールでワークロードの VerticalPodAutoscaler のステータスを検査するには:
[ワークロード] ページに移動します。
ワークロードの名前をクリックします。
[詳細] タブに移動し、[オートスケーラー] セクションを見つけます。
[Vertical Pod Autoscaler] 行で、指標の収集と構成の健全性に関するステータス メッセージを確認します。
決定ログを収集する
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 内の既存のワークロードを指していません。 - 初期指標の収集: 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 または HorizontalPodAutoscaler がワークロード タイプに最適かどうかを評価します。
競合する 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タグを使用して類似の問題を検索するなどして、コミュニティからサポートを受ける。Slack チャネル に参加して、コミュニティ サポートを利用することもできます。#kubernetes-engine - 公開バグトラッカーを使用して、問題や機能リクエストを登録する。