垂直 Pod 自動スケーリングを構成する

垂直 Pod 自動スケーリングは、Kubernetes Pod 内のコンテナの CPU リソースとメモリリソースのリクエストと上限の設定を自動化します。垂直 Pod 自動スケーリングは、過去と現在のリソース使用量を分析して推奨事項を提示します。この推奨事項は、表示することも、Pod を更新して自動的に適用することもできます。リソース割り当てを適切なサイズに調整することにより、この機能で安定性と費用対効果を向上させることができます。

始める前に

垂直 Pod 自動スケーリングを構成する前に、次の前提条件を満たしていることを確認してください。

  • ベアメタル クラスタが実行されている。
  • クラスタに対する kubectl アクセス権がある。
  • Metrics Server がクラスタで使用可能である。ベアメタル クラスタには、デフォルトで Metrics Server が含まれています。

垂直 Pod 自動スケーリングを有効にする

プレビュー アノテーションを設定し、クラスタ仕様を構成して、ベアメタル クラスタで垂直 Pod 自動スケーリングを有効にします。

  1. Cluster カスタム リソースのプレビュー アノテーションを追加または更新します。

    Cluster カスタム リソースを直接編集するか、クラスタ構成ファイルを変更して bmctl update を使用します。

    metadata:
  annotations:
    preview.baremetal.cluster.gke.io/vertical-pod-autoscaler: enable

  2. Cluster カスタム リソースの spec を変更して verticalPodAutoscaling フィールドを含め、enableUpdater モードと enableMemorySaver モードを指定します。

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    preview.baremetal.cluster.gke.io/vertical-pod-autoscaler: enable
spec:
  # ... other cluster spec fields
  verticalPodAutoscaling:
    enableUpdater: true       # Set to true for automated updates
    enableMemorySaver: true   # Set to true to reduce recommender memory usage

  3. クラスタ構成ファイルを変更した場合は、次のコマンドを使用して変更を適用します。

    bmctl update cluster -c CLUSTER_NAME --kubeconfig KUBECONFIG

    次のように置き換えます。

    • CLUSTER_NAME: クラスタの名前。

    • KUBECONFIG: クラスタの kubeconfig ファイルのパス。

VerticalPodAutoscaler カスタム リソースを作成する

クラスタで垂直 Pod 自動スケーリングを有効にしたら、特定のワークロードをターゲットにする VerticalPodAutoscaler カスタム リソースを定義します。

  1. ターゲット ワークロードと同じ Namespace に VerticalPodAutoscaler リソースを定義します。

    このカスタム リソースは、targetRef とリソース ポリシーを使用して、ターゲットとする Pod を指定します。

    apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: hamster-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: hamster
  resourcePolicy:
    containerPolicies:
      -   containerName: '*'
        minAllowed:
          cpu: 100m
          memory: 50Mi
        maxAllowed:
          cpu: 1
          memory: 500Mi
        controlledResources: ["cpu", "memory"]

  2. 次のコマンドを使用して VerticalPodAutoscaler マニフェストをデプロイします。

    kubectl apply -f VPA_MANIFEST \
    --kubeconfig KUBECONFIG

    次のように置き換えます。

    • VPA_MANIFEST: VerticalPodAutoscaler マニフェスト ファイルのパス。

    • KUBECONFIG: クラスタの kubeconfig ファイルのパス。

垂直 Pod 自動スケーリングのモードについて

垂直 Pod 自動スケーリングは、リソースの推奨事項の適用方法を制御するさまざまなモードで動作します。

推奨事項モード

推奨事項モードでは、垂直 Pod 自動スケーリングによって Recommender コンポーネントがインストールされます。このコンポーネントは、リソース使用率を分析し、作成した VerticalPodAutoscaler カスタム リソースのステータス セクションに、CPU とメモリのリクエストと上限の推奨事項を公開します。

リソースのリクエストと上限の推奨事項を確認するには、次のコマンドを使用します。

kubectl describe vpa VPA_NAME \
    --kubeconfig KUBECONFIG \
    -n CLUSTER_NAMESPACE

Replace the following:

*   `VPA_NAME`: the name of the `VerticalPodAutoscaler`
    that's targeting the workloads for which you are considering resource
    adjustments.

*   `KUBECONFIG`: the path of the cluster kubeconfig
    file.

*   `CLUSTER_NAMESPACE`: the name of the cluster that's
    running vertical Pod autoscaling.

レスポンスには、次の例のような Status セクションが含まれます。

Status:
  Conditions:
    Last Transition Time:  2025-08-04T23:53:32Z
    Status:                True
    Type:                  RecommendationProvided
  Recommendation:
    Container Recommendations:
      Container Name:  hamster
      Lower Bound:
        Cpu:     100m
        Memory:  262144k
      Target:
        Cpu:     587m
        Memory:  262144k
      Uncapped Target:
        Cpu:     587m
        Memory:  262144k
      Upper Bound:
        Cpu:     1
        Memory:  500Mi

このモードでは、Pod は自動的に更新されません。これらの推奨事項を使用して、Pod 構成を手動で更新します。enableUpdater が設定されていないか、false の場合、これがデフォルトの動作です。

自動更新モード

enableUpdater enableUpdater を true に設定すると、ベアメタル ライフサイクル コントローラは、Recommender に加えて、垂直 Pod 自動スケーリング アップデータとアドミッション コントローラ コンポーネントをデプロイします。アップデータは、現在のリソース リクエストが推奨事項から大幅に逸脱している Pod をモニタリングします。

VerticalPodAutoscaler リソースの更新ポリシーは、アップデータが推奨事項を適用する方法を指定します。デフォルトの更新モードは Auto です。これは、アップデータが Pod の作成時に更新されたリソース設定を割り当てることを意味します。次の VerticalPodAutoscaler のサンプルは、更新モードを Initial に設定する方法を示しています。

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: hamster-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: hamster
  resourcePolicy:
  updatePolicy:
    updateMode: "Initial"
    ...

アップデータは次の 5 つのモードをサポートしています。

  • Auto: アップデータが Pod を強制排除します。アドミッション コントローラは、新しい Pod の作成リクエストをインターセプトし、Recommender が提供する CPU とメモリの推奨値を使用するように変更します。リソースを更新するには、Pod を再作成する必要があります。これにより、停止が発生する可能性があります。アップデータが考慮する Pod Disruption Budget を使用して、削除プロセスを管理します。このモードは Recreate と同じです。

  • Recreate: アップデータは Pod を強制排除し、Pod の再作成時にリソース リクエストと上限の推奨値を割り当てます。

  • InPlaceOrRecreate（アルファ版）: アップデータはインプレース更新を試みますが、インプレース更新が不可能な場合は Pod の再作成にフォールバックする可能性があります。詳細については、インプレース Pod のサイズ変更のドキュメントをご覧ください。

  • Initial: アップデータは、Pod の作成時にのみリソース リクエストを割り当て、後で変更することはありません。

  • Off: アップデータは Pod のリソース要件を自動的に変更しません。推奨値は計算され、VerticalPodAutoscaler オブジェクトで詳細を確認できます。

VerticalPodAutoscaler カスタム リソースの詳細については、kubectl を使用して、バージョン 1.33.0 以降のクラスタにインストールされている verticalpodautoscalercheckpoints.autoscaling.k8s.io カスタム リソース定義を取得します。

次のサンプルは、hamster コンテナの Status セクションにリソースの推奨事項が表示される例を示しています。このサンプルには、Pod の削除イベントの例も示されています。このイベントは、アップデータが推奨リソース構成を再作成された Pod に自動的に割り当てる前に Pod を削除したときに発生します。

Spec:
  Resource Policy:
    Container Policies:
      Container Name:  *
      Controlled Resources:
        cpu
        memory
      Max Allowed:
        Cpu:     1
        Memory:  500Mi
      Min Allowed:
        Cpu:     100m
        Memory:  50Mi
  Target Ref:
    API Version:  apps/v1
    Kind:         Deployment
    Name:         hamster
  Update Policy:
    Update Mode:  Auto
Status:
  Conditions:
    Last Transition Time:  2025-08-04T23:53:32Z
    Status:                True
    Type:                  RecommendationProvided
  Recommendation:
    Container Recommendations:
      Container Name:  hamster
      Lower Bound:
        Cpu:     100m
        Memory:  262144k
      Target:
        Cpu:     587m
        Memory:  262144k
      Uncapped Target:
        Cpu:     587m
        Memory:  262144k
      Upper Bound:
        Cpu:     1
        Memory:  500Mi
Events:
  Type    Reason      Age   From         Message
  ----    ------      ----  ----         -------
  Normal  EvictedPod  49s   vpa-updater  VPA Updater evicted Pod hamster-7cb59fb657-lkrk4 to apply resource recommendation.

メモリセーバー モード

メモリセーバー モードでは、垂直 Pod 自動スケーリングの Recommender コンポーネントのメモリ使用量が削減されます。enableMemorySaver を true に設定すると、Recommender は一致する VerticalPodAutoscaler カスタム リソースを持つ Pod の集計のみを追跡して計算します。

トレードオフとして、既存のワークロード用に新しい VerticalPodAutoscaler カスタム リソースを作成すると、Recommender が正確な推奨事項を提供するために十分な履歴を収集するのに時間がかかります（最大 24 時間）。このモードは、ほとんどのタイプのクラスタでデフォルトで false ですが、エッジクラスタではデフォルトで true になります。

永続履歴プロバイダとして Prometheus を使用する

デフォルトでは、Recommender コンポーネントは、クラスタで実行されているワークロードのリソース消費履歴をメモリに保持し、定期的にその状態を etcd の VerticalPodAutoscalerCheckpoint カスタム リソースに保存して、再起動に対する復元力を提供します。

Google Distributed Cloud バージョン 1.34 以降では、独自に作成した Prometheus のインスタンスを、リソース消費量データ（CPU とメモリ使用量の指標）の永続的な履歴プロバイダとして使用できます。この統合が有効になっている場合、Recommender は起動時または再起動時に Prometheus サーバーにクエリを実行して、すべてのマネージド Pod の長期的なリソース使用履歴データを取得できます。このデータを取得することで、Recommender は豊富なデータセットを使用して内部状態をすぐに構築できるため、最初からより情報に基づいた正確な推奨事項を提供できます。

永続履歴プロバイダとして Prometheus を使用すると、次のメリットがあります。

  • リソース使用率の最適化: 開始するとすぐに、十分な情報に基づいた正確な推奨事項が生成されるため、クラスタ リソースの使用率を最適化できます。

  • メモリ不足（OOM）エラーの防止: Prometheus では、Recommender の内部状態を VerticalPodAutoscalerCheckpoint カスタム リソース（CR）に保存する必要がないため、ETCD のメモリ使用率が向上します。レコメンダー コンポーネントが再起動すると、インメモリの履歴データが失われます。Prometheus を履歴プロバイダとして使用すると、再起動時に Recommender が Prometheus から過去の指標を取得するため、VerticalPodAutoscalerCheckpoint CR が不要になり、ETCD メモリが節約されます。

Prometheus を永続的な履歴プロバイダとして使用するかどうかは、いつでも有効または無効にできます。

垂直 Pod 自動スケーリングで Prometheus を使用するための前提条件

独自の Prometheus インスタンスを垂直 Pod 自動スケーリングの履歴プロバイダとして使用するには、必要な指標をスクレイピングするように構成する必要があります。これには次の手順が含まれます。

  1. 必要に応じて、垂直 Pod 自動スケーリングの永続的な履歴プロバイダとして使用するクラスタに Prometheus Operator をデプロイします。詳細については、Kubernetes で Prometheus Operator をデプロイして構成する方法をご覧ください。

  2. 指標をスクレイピングするための権限を構成します。

    構成ファイルを使用して Prometheus が cAdvisor から指標をスクレイピングできるようにするには、Prometheus サーバーが使用するサービス アカウントに追加の権限を付与する必要があります。これらのルールを含む ClusterRole を作成または更新し、ClusterRoleBinding を使用して正しい Prometheus サービス アカウントにバインドされていることを確認します。

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
   name: prometheus-role
   labels:
      app: prometheus-server
rules:
   - apiGroups: [""]
     resources:
       - nodes
     verbs:
       - get
       - list
       - watch
   - apiGroups: [""]
     resources:
       - nodes/proxy
       - nodes/metrics
     verbs:
       - get
    ---

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: prometheus-binding
  labels:
    app: prometheus-server
subjects:
  - kind: ServiceAccount
    name: prometheus-server        # Service account being used by prometheus
    namespace: prometheus          # Service account's namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus-role            # Name of the ClusterRole created above

  3. Prometheus 構成ファイルを更新して、cAdvisor から次の指標を取得します。

    • container_cpu_usage_seconds_total
    • container_memory_working_set_bytes

    次の行は、cAdvisor 指標のスクレイピングの詳細を定義します。

    - job_name: 'kubernetes-cadvisor'
  scheme: https
  tls_config:
    ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
  bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
  kubernetes_sd_configs:
    - role: node
  relabel_configs:
    - action: labelmap
      regex: __meta_kubernetes_node_label_(.+)
    - target_label: __address__
      replacement: kubernetes.default.svc:443
    - source_labels: [__meta_kubernetes_node_name]
      regex: (.+)
      target_label: __metrics_path__
      replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor

  metric_relabel_configs:
  # Keep only the metrics VPA uses to save disk space
    - source_labels: [__name__]
      regex: (container_cpu_usage_seconds_total|container_memory_working_set_bytes)
      action: keep

  4. kube-state-metrics サービスから次の指標をスクレイピングするように Prometheus 構成ファイルを更新します。

    • kube_pod_labels

    1. クラスタに kube-state-metrics Service をデプロイします。

      次の Helm コマンドを使用して、新しい Service をインストールできます。

      helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

    2. 次の内容の ksm-values.yaml ファイルを作成します。

      fullnameOverride: vpa-kube-state-metrics
metricAllowlist:
  - kube_pod_labels
metricLabelsAllowlist:
  - "pods=[*]"

    3. 前の手順の値ファイルに基づいて Helm チャートをインストールします。

      helm install vpa-ksm prometheus-community/kube-state-metrics \
    -f ksm-values.yaml --namespace kube-system

    4. インストールされた kube-state-metrics サービスから kube_pod_labels 指標をスクレイピングするには、Prometheus 構成ファイルに次の行を追加します。

      - job_name: 'kube-state-metrics'
  static_configs:
    - targets: ['vpa-kube-state-metrics.kube-system.svc.cluster.local:8080']
  metric_relabel_configs:
    - source_labels: [ __name__ ]
      regex: 'kube_pod_labels'
      action: keep

Prometheus を有効にして使用する

垂直 Pod 自動スケーリングは、Prometheus への接続に基本認証とベアラー トークンベースの認証の両方をサポートしています。認証を使用する場合は、必要な認証情報を含む Secret をクラスタ Namespace に作成する必要があります。コントローラは、この Secret をターゲット クラスタに転送し、Recommender Pod のボリュームまたは環境変数としてマウントします。認証なしで Prometheus を使用することもできます。

垂直 Pod 自動スケーリングで独自の Prometheus インスタンスを有効にして使用するには、Prometheus インスタンスへの接続の詳細を使用して、クラスタ仕様の verticalPodAutoscaling セクションを構成する必要があります。

ベアラー トークンで使用するクラスタ仕様の構成の例を次に示します。

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    preview.baremetal.cluster.gke.io/vertical-pod-autoscaler: enable
spec:
  # ... other existing cluster configurations ...
  verticalPodAutoscaling:
    # ... other vertical Pod autoscaling configurations ...
    # Add this new section to configure the vpa to use prometheus using bearer token authentication as history provider
    prometheus:
      url: "http://prometheus.prometheus.monitoring.svc.cluster.local:9090"
      auth:
        bearerTokenAuth:
            name: prom-bearer-creds
            key: bearertoken

垂直 Pod 自動スケーリングで使用するために Prometheus を有効にするには:

  1. 垂直 Pod 自動スケーリングで Prometheus を使用するための前提条件で説明されているように、必要な指標をスクレイピングするように Prometheus インスタンスが設定されていることを確認します。

  2. Cluster カスタム リソースの spec を更新して、verticalPodAutoscaling.prometheus フィールドで Prometheus サーバーの接続設定を指定するようにします。

  3. url を prometheus セクションに追加し、クラスタ内から Prometheus に接続するための完全修飾ドメイン名（FQDN）に設定します。

    spec:
  # ... other existing cluster configurations ...
  verticalPodAutoscaling:
    # ... other vpa configurations ...
    # Add this new section to configure the vpa to use prometheus as history provider
    prometheus:
      # Required: The URL of the Prometheus server
      url: "http://prometheus.prometheus.svc.cluster.local:9090"

  4. 接続の詳細を指定します。

    垂直 Pod 自動スケーリングは、次の 3 つの接続方法をサポートしています。

    • 認証なし
    • 基本認証（ユーザー名、パスワード）

    • 署名なしトークン認証

    認証なし

    Prometheus インスタンスで認証が不要な場合は、これで完了です。prometheus セクションには url フィールドのみを含める必要があります。

    基本認証

    Prometheus の基本認証を指定する手順は次のとおりです。

    1. stringData セクションと baremetal.cluster.gke.io/mark-source: "true" アノテーションにユーザー名とパスワードを含む Secret を作成します。

      次の例は、基本認証をサポートする Secret を示しています。

      apiVersion: v1
kind: Secret
metadata:
  name: prom-basic-creds
  namespace: <cluster-namespace>
  annotations:
    baremetal.cluster.gke.io/mark-source: "true"
type: Opaque
stringData:
  username: admin
  password: pwd

      このアノテーションは、ソース シークレットとターゲット クラスタ内のシークレットが常に同期していることを確認するために必要です。ソース シークレットが更新されると、Secret が更新されます。

    2. クラスタ仕様の prometheus.auth.basicAuth セクションを更新して、Secret の data フィールドからユーザー名とパスワードを参照するようにします。

      次の例は、前のステップの Secret のユーザー名とパスワードを参照する basicAuth セクションを示しています。

      # ... other vpa configurations ...
prometheus:
  url: "http://prometheus.prometheus.svc.cluster.local:9090"
  auth:
    basicAuth:
      usernameRef:
        name: prom-basic-creds
        key: username
      passwordRef:
        name: prom-basic-creds
        key: password

      ユーザー名とパスワードは同じ Secret に存在する必要があります。キーは、Secret の data フィールドの有効なキーである必要があります。

    Cluster カスタム リソースが更新されると、Prometheus インスタンスは垂直 Pod オートスケーラーの履歴プロバイダとして機能を開始します。

    署名なしトークン認証

    次の手順で、Prometheus のベアラートークン認証を指定します。

    1. stringData セクションにベアラートークンが含まれ、baremetal.cluster.gke.io/mark-source: "true" アノテーションを含む Secret を作成します。

      次の例は、ベアラー トークン認証をサポートする Secret を示しています。

      apiVersion: v1
kind: Secret
metadata:
  name: prom-bearer-creds
  namespace: <cluster-namespace>
  annotations:
    baremetal.cluster.gke.io/mark-source: "true"
type: Opaque
stringData:
  bearertoken: "SAMPLE_TOKEN"

      このアノテーションは、ソース シークレットとターゲット クラスタ内のシークレットが常に同期していることを確認するために必要です。ソース シークレットが更新されると、Secret が更新されます。

    2. クラスタ仕様の prometheus.auth.bearerTokenAuth セクションを更新して、Secret の data フィールドからベアラー トークンを参照します。

      次の例は、前の手順の Secret でベアラートークンを参照する bearerTokenAuth セクションを示しています。

      # ... other vertical Pod autoscaling configurations ...
prometheus:
  url: "http://prometheus.prometheus.svc.cluster.local:9090"
  auth:
    bearerTokenAuth:
        name: prom-bearer-creds
        key: bearertoken

      キーは、Secret の data フィールドの有効なキーである必要があります。

    Cluster カスタム リソースが更新されると、Prometheus インスタンスは垂直 Pod 自動スケーリングの履歴プロバイダとして機能を開始します。

Prometheus の使用を無効にする

垂直 Pod 自動スケーリングで Prometheus の使用を無効にするには、Cluster カスタム リソースの verticalPodAutoscaling セクションから prometheus セクションを削除します。

垂直 Pod 自動スケーリングを無効にする

クラスタからカスタム リソースと構成を削除して、垂直 Pod 自動スケーリングを無効にします。

  1. 作成した VerticalPodAutoscaler カスタム リソースを削除します。

  2. Cluster カスタム リソースを変更し、spec から verticalPodAutoscaling セクション全体を削除します。

    Cluster カスタム リソースを直接編集するか、クラスタ構成ファイルを変更して bmctl update を使用できます。

  3. Cluster カスタム リソースから preview.baremetal.cluster.gke.io/vertical-pod-autoscaler アノテーションを削除します。

制限事項

垂直 Pod 自動スケーリングを使用する場合は、次の制限事項を考慮してください。

  • ワークロードの実際のメモリ使用量の可視性が制限されているので、JVM ベースのワークロードには垂直 Pod 自動スケーリングをまだ使用できません。
  • 更新ツールでは、Deployment が Pod を更新されたリソース値に置き換えるために、Pod レプリカが 2 つ以上必要です。
  • メモリ不足（OOM）エラーによりクラッシュ ループが発生している Pod は、アップデータによってすぐに更新されません。
  • Pod の InPlaceOrRecreate 更新ポリシーは、垂直 Pod 自動スケーリング内のアルファ版の機能です。ベスト エフォートでインプレース更新を試みますが、インプレース更新ができない場合は Pod の再作成にフォールバックする可能性があります。

次のステップ