垂直 Pod 自動スケーリングのトラブルシューティング

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 の完全な構成とステータスを表示するには、 YAML マニフェストを kubectl または Cloud de Confiance コンソールを使用して検査します。

コンソール

  1. Cloud de Confiance コンソールで、[オブジェクト ブラウザ] ページに移動します。

    オブジェクト ブラウザに移動

  2. [オブジェクトの種類] フィルタリストをクリックします。

  3. 既存の選択をすべてクリアします。

  4. [VerticalPodAutoscaler] を選択して [OK] をクリックします。

  5. フィルタされたリストで、[autoscaling.k8s.io] API グループを選択します。

  6. [VerticalPodAutoscaler] オブジェクトの種類を選択します。

  7. 検査する 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 のステータスを検査するには:

  1. [ワークロード] ページに移動します。

    [ワークロード] に移動

  2. ワークロードの名前をクリックします。

  3. [詳細] タブに移動し、[オートスケーラー] セクションを見つけます。

  4. [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 コンポーネントを確認する:

    1. metrics-server コンポーネントの Pod が実行されていることを確認します。

      kubectl get pods -n kube-system | grep metrics-server

    2. Pod が実行されていない場合や、再起動回数が多い場合は、ログを確認します。

      kubectl logs -n kube-system -l k8s-app=metrics-server

      error、failed、unable to fetch などの単語を含むログエントリは、指標の収集に関する問題を示しています。

  • Pod が実行されていることを確認する: ターゲット ワークロードに、実行中かつ準備完了の Pod が少なくとも 1 つあることを確認します。

VerticalPodAutoscaler の推奨値が想定外である

症状:

  • Status.Recommendation セクションの CPU またはメモリの値が、想定よりも高いか低い。
  • 推奨値が、観測されたワークロードのリソース消費量と一致しない。

原因:

  • ワークロードの動作の変更: VerticalPodAutoscaler の推奨値は、過去の使用量に基づいています。アプリケーションの消費パターンが最近変更された場合、まだ反映されていない可能性があります。
  • ワークロードの特性: 短期間のジョブや、使用パターンが非常にスパイク状のワークロードでは、最適な推奨値が得られない可能性があります。
  • VerticalPodAutoscaler リソースの競合: 複数の VerticalPodAutoscaler リソースが同じワークロードをターゲットにしている可能性があります。

解決策:

  • 調整時間を確保する: アプリケーションの変更後、VerticalPodAutoscaler が新しい使用パターンを学習する時間を確保します。
  • 適合性を評価する: VerticalPodAutoscaler または HorizontalPodAutoscaler がワークロード タイプに最適かどうかを評価します。

  • 競合する VerticalPodAutoscaler リソースを確認する:

    1. クラスタ内のすべての VerticalPodAutoscaler リソースを一覧表示します。

      kubectl get vpa --all-namespaces

    2. 各リソースの 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 を強制排除して再作成し、推奨値を適用します。延期された更新のステータスを確認する手順は次のとおりです。

    1. Pod アノテーションを調べて、vpaInPlaceUpdated アノテーションが "true" に設定されているかどうかを確認します。

      metadata:
  annotations:
    vpaInPlaceUpdated: "true"
    vpaUpdates: 'Pod resources updated by sample-deployment-vpa: container 0: cpu request, memory request'

    2. 延期されたサイズ変更イベントの status.conditions フィールドを調べて、延期されたステータスを確認します。

      status:
  conditions:
  - type: PodResizePending
    status: "True"
    reason: Deferred
    message: "Node didn't have enough resource: ..."

    3. 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
    • 公開バグトラッカーを使用して、問題や機能リクエストを登録する。