# 垂直Pod自動スケーリング LLMS index: [llms.txt](/llms.txt) --- Kubernetesにおいて、_VerticalPodAutoscaler_ は、ワークロード管理リソース(DeploymentやStatefulSetなど)を自動的に更新し、インフラストラクチャリソースの[要求と制限](/docs/concepts/configuration/manage-resources-containers/#requests-and-limits)を実際の使用状況に合わせて自動的に調整します。 垂直スケーリングとは、リソース需要が増加した際に、ワークロードで既に実行されているPodに、より多くのリソース(たとえば、メモリやCPUなど)を割り当てることを意味します。 これは、_rightsizing_ や、時には _autopilot_ とも呼ばれます。 これは、Kubernetesで負荷を分散するために追加のPodをデプロイする水平スケーリングとは異なります。 リソース使用量が減少し、Podのリソース要求が最適なレベルを上回っている場合、VerticalPodAutoscalerは、ワークロードリソース(Deployment、StatefulSet、または類似のリソース)に指示して、リソース要求を下げ、リソースの浪費を防ぎます。 VerticalPodAutoscalerは、Kubernetes APIリソースおよびコントローラーとして実装されています。 リソースがコントローラーの動作を決定します。 Kubernetesデータプレーン内で実行される垂直Pod自動スケーリングコントローラーは、過去のリソース使用率の分析、クラスターで利用可能なリソースの量、およびout-of-memory(OOM)条件などのリアルタイムイベントに基づいて、対象(Deploymentなど)のリソース要求と制限を定期的に調整します。 ## APIオブジェクト {#api-object} VerticalPodAutoscalerは、Kubernetesでカスタムリソース定義(CRD)として定義されています。 KubernetesのコアAPIの一部であるHorizontalPodAutoscalerとは異なり、VPAはクラスターに個別にインストールする必要があります。 現在の安定版のAPIバージョンは`autoscaling.k8s.io/v1`です。VPAのインストール方法とAPIの詳細については、[VPA GitHubリポジトリ](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler)を参照してください。 ## VerticalPodAutoscalerはどのように動作するか? {#how-does-a-verticalpodautoscaler-work}
graph BT metrics[Metrics Server] api[APIサーバー] admission[VPA Admission Controller] vpa_cr[VerticalPodAutoscaler CRD] recommender[VPA recommender] updater[VPA updater] metrics --> recommender recommender -->|推奨値を格納| vpa_cr subgraph アプリケーションワークロード controller[Deployment / RC / StatefulSet] pod[Pod / Container] end vpa_cr -->|変更を確認| updater updater -->|Podを退避またはインプレースで更新| controller controller -->|新しいPodをリクエスト| api api -->|新しいPodの作成| admission admission -->|最新の推奨値を取得| vpa_cr admission -->|新しいリソース値を注入| api api -->|Podを作成| controller controller -->|最適なリソースを持つ新しいPod| pod classDef vpa fill:#9FC5E8,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; classDef crd fill:#D5A6BD,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; classDef metrics fill:#FFD966,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; classDef app fill:#B6D7A8,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; class recommender,updater,admission vpa; class vpa_cr crd; class metrics metrics; class controller,pod app;
図1. VerticalPodAutoscalerは、Deployment内のPodのリソース要求と制限を制御します Kubernetesは、断続的に実行される複数の連携するコンポーネントを通じて垂直Pod自動スケーリングを実装します(継続的なプロセスではありません)。VPAは3つの主要なコンポーネントで構成されています: * リソース使用量を分析し、推奨値を提供する _recommender_ * Podのリソース要求を、Podを退避させるか、またはその場で変更することで更新する _updater_ * 新しく作成または再作成されたPodにリソース推奨値を適用する、VPA _admission controller_ webhook 各サイクルごとに1回、Recommenderは各VerticalPodAutoscaler定義によって対象とされるPodのリソース使用率を照会します。Recommenderは、`targetRef`で定義された対象リソースを見つけ、対象リソースの`.spec.selector`ラベルに基づいてPodを選択し、リソースメトリクスAPIからメトリクスを取得して、実際のCPUとメモリ消費を分析します。 Recommenderは、VerticalPodAutoscalerによって対象とされる各Podの現在および過去のリソース使用データ(CPUとメモリ)を分析します。調査される要素には以下が含まれます: - トレンドを特定するための、時間経過に伴う過去の消費パターン - 十分な余裕を確保するための、ピーク使用量と変動 - Out-of-memory(OOM)イベントおよびその他のリソース関連のインシデント この分析に基づいて、Recommenderは3種類の推奨値を計算します: - 目標推奨値(通常の使用に最適なリソース) - 下限値(最小限の実行可能なリソース) - 上限値(最大の合理的なリソース) これらの推奨値は、VerticalPodAutoscalerリソースの`.status.recommendation`フィールドに保存されます。 _Updater_ コンポーネントは、VerticalPodAutoscalerリソースを監視し、現在のPodリソース要求を推奨値と比較します。 差異が設定された閾値を超え、更新ポリシーで許可されている場合、updaterは以下のいずれかを実行できます: - Podを退避し、新しいリソース要求で再作成をトリガーする(従来のアプローチ) - クラスターがインプレースPodリソース更新をサポートしている場合、退避せずにその場でPodリソースを更新する 選択される方法は、設定された更新モード、クラスターのケイパビリティ、および必要なリソース変更の種類に依存します。 インプレース更新が利用可能な場合、Podの中断を回避しますが、変更可能なリソースに制限がある場合があります。 updaterは、サービスへの影響を最小限に抑えるためにPodDisruptionBudgetを尊重します。 _Admission controller_ は、Podの作成リクエストをインターセプトするmutating webhookとして動作します。 PodがVerticalPodAutoscalerの対象であるかどうかを確認し、対象である場合、Podが作成される前に推奨されるリソース要求と制限を適用します。 より具体的には、admission controllerはVerticalPodAutoscalerリソースの`.status.recommendation`スタンザ内のTarget recommendationを新しいリソースリクエストとして使用します。 Admission controllerは、初回デプロイ時、updaterによる退避後、またはスケーリング操作による場合のいずれであっても、新しいPodが適切なサイズのリソース割り当てで起動することを保証します。 VerticalPodAutoscalerは、クラスターにインストールされているKubernetesのメトリクスサーバーアドオンなどのメトリクスソースを必要とします。 VPAコンポーネントは、`metrics.k8s.io` APIからメトリクスを取得します。 メトリクスサーバーは、ほとんどのクラスターでデフォルトではデプロイされないため、個別に起動する必要があります。 リソースメトリクスの詳細については、[メトリクスサーバー](/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-server)を参照してください。 ## 更新モード {#update-modes} VerticalPodAutoscalerは複数の _更新モード_ をサポートしており、リソース推奨値がいつ、どのようにPodに適用されるかを制御することができます。 更新モードは、VPA specの`updatePolicy`内にある`updateMode`フィールドで設定します: ```yaml --- apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: my-app-vpa spec: targetRef: apiVersion: "apps/v1" kind: Deployment name: my-app updatePolicy: updateMode: "Recreate" # Off, Initial, Recreate, InPlaceOrRecreate ``` ### Off {#updateMode-Off} _Off_ 更新モードでは、VPA recommenderは引き続きリソース使用量を分析し、推奨値を生成しますが、これらの推奨値はPodに自動的に適用されません。 推奨値は、VPAオブジェクトの`.status`フィールドにのみ保存されます。 `kubectl`などのツールを使用して、`.status`に含まれる推奨値を表示できます。 ### Initial {#updateMode-Initial} _Initial_ モードでは、VPAはPodが最初に作成されたときにのみリソース要求を設定します。 推奨値が時間とともに変化しても、既に実行中のPodのリソースは更新しません。 推奨値はPod作成時にのみ適用されます。 ### Recreate {#updateMode-Recreate} _Recreate_ モードでは、VPAは、現在のリソース要求が推奨値と大きく異なる場合、Podを退避させることでPodリソースを積極的に管理します。 Podが退避されると、ワークロードコントローラー(Deployment、StatefulSetなどを管理)が代替のPodを作成し、VPA admission controllerが更新されたリソース要求を新しいPodに適用します。 ### InPlaceOrRecreate {#updateMode-InPlaceOrRecreate} `InPlaceOrRecreate`モードでは、VPAは可能な限りPodを再起動せずにPodリソース要求と制限を更新しようとします。ただし、特定のリソース変更に対してインプレース更新を実行できない場合、VPAはPodの退避にフォールバック(`Recreate`モードと同様)し、ワークロードコントローラーが更新されたリソースで代替のPodを作成できるようにします。 このモードでは、updaterは[コンテナリソースのインプレースリサイズ](/docs/tasks/configure-pod-container/resize-container-resources/)機能を使用して、推奨値をインプレースで適用します。 ### Auto(非推奨) {#updateMode-Auto}

備考:

Auto更新モードはVPAバージョン1.4.0から非推奨です。退避ベースの更新にはRecreateを、退避フォールバックを伴うインプレース更新にはInPlaceOrRecreateを使用してください。
`Auto`モードは現在、`Recreate`モードのエイリアスであり、同じように動作します。 これは、将来的に自動更新戦略を拡張できるようにするために導入されました。 ## リソースポリシー {#resource-policies} リソースポリシーを使用すると、VerticalPodAutoscalerが推奨値を生成し、更新を適用する方法を細かく調整できます。 リソース推奨値の境界を設定し、管理するリソースを指定し、Pod内の個々のコンテナに対して異なるポリシーを設定できます。 リソースポリシーは、VPA specの`resourcePolicy`フィールドで定義します: ```yaml apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: my-app-vpa spec: targetRef: apiVersion: "apps/v1" kind: Deployment name: my-app updatePolicy: updateMode: "Recreate" resourcePolicy: containerPolicies: - containerName: "application" minAllowed: cpu: 100m memory: 128Mi maxAllowed: cpu: 2 memory: 2Gi controlledResources: - cpu - memory controlledValues: RequestsAndLimits ``` #### minAllowedとmaxAllowed {#minallowed-and-maxallowed} これらのフィールドは、VPA推奨値の境界を設定します。 実際の使用データが異なる値を示唆していても、VPAは`minAllowed`を下回る、または`maxAllowed`を上回るリソースを推奨することはありません。 #### controlledResources {#controlledresources} `controlledResources`フィールドは、VPAがPod内のコンテナに対して管理すべきリソースタイプを指定します。 指定されていない場合、VPAはデフォルトでCPUとメモリの両方を管理します。 VPAが特定のリソースのみを管理するように制限できます。 有効なリソース名には、`cpu`と`memory`が含まれます。 ### controlledValues {#controlledvalues} `controlledValues`フィールドは、VPAがリソース要求、制限、または両方を制御するかどうかを決定します: RequestsAndLimits : VPAは要求と制限の両方を設定します。制限は、Pod specで定義されたrequest-to-limitの比率に基づいて、要求に比例してスケールします。これはデフォルトのモードです。 RequestsOnly : VPAは要求のみを設定し、制限は変更されません。制限は維持され、使用量が制限を超えた場合、スロットリングまたはout-of-memory killをトリガーする可能性があります。 これら2つの概念の詳細については、[要求と制限](/docs/concepts/configuration/manage-resources-containers/#requests-and-limits)を参照してください。 ## LimitRangeリソース {#limitrange-resources} Admission controllerとupdater VPAコンポーネントは、[LimitRange](/docs/concepts/policy/limit-range/)で定義された制約に準拠するよう推奨値を後処理します。 Kubernetesクラスター内で`type`がPodおよびContainerのLimitRangeリソースがチェックされます。 たとえば、Container LimitRangeリソースの`max`フィールドを超過した場合、両方のVPAコンポーネントは制限を`max`フィールドで定義された値まで引き下げ、Pod specにおけるrequest-to-limitの比率を維持するように、要求が比例して減少されます。 ## 次の項目 クラスターで自動スケーリングを設定する場合、適切な数のノードを実行していることを確認するために、[ノードの自動スケーリング](/docs/concepts/cluster-administration/node-autoscaling/)の使用を検討することもお勧めします。 [_水平_ Pod自動スケーリング](/docs/tasks/run-application/horizontal-pod-autoscale/)の詳細についても参照してください。