垂直Pod自動スケーリング

Kubernetesにおいて、VerticalPodAutoscaler は、ワークロード管理リソース(DeploymentやStatefulSetなど)を自動的に更新し、インフラストラクチャリソースの要求と制限を実際の使用状況に合わせて自動的に調整します。

垂直スケーリングとは、リソース需要が増加した際に、ワークロードで既に実行されているPodに、より多くのリソース(たとえば、メモリやCPUなど)を割り当てることを意味します。 これは、rightsizing や、時には autopilot とも呼ばれます。 これは、Kubernetesで負荷を分散するために追加のPodをデプロイする水平スケーリングとは異なります。

リソース使用量が減少し、Podのリソース要求が最適なレベルを上回っている場合、VerticalPodAutoscalerは、ワークロードリソース(Deployment、StatefulSet、または類似のリソース)に指示して、リソース要求を下げ、リソースの浪費を防ぎます。

VerticalPodAutoscalerは、Kubernetes APIリソースおよびコントローラーとして実装されています。 リソースがコントローラーの動作を決定します。 Kubernetesデータプレーン内で実行される垂直Pod自動スケーリングコントローラーは、過去のリソース使用率の分析、クラスターで利用可能なリソースの量、およびout-of-memory(OOM)条件などのリアルタイムイベントに基づいて、対象(Deploymentなど)のリソース要求と制限を定期的に調整します。

APIオブジェクト

VerticalPodAutoscalerは、Kubernetesでカスタムリソース定義(CRD)として定義されています。 KubernetesのコアAPIの一部であるHorizontalPodAutoscalerとは異なり、VPAはクラスターに個別にインストールする必要があります。

現在の安定版のAPIバージョンはautoscaling.k8s.io/v1です。VPAのインストール方法とAPIの詳細については、VPA GitHubリポジトリを参照してください。

VerticalPodAutoscalerはどのように動作するか?

図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からメトリクスを取得します。 メトリクスサーバーは、ほとんどのクラスターでデフォルトではデプロイされないため、個別に起動する必要があります。 リソースメトリクスの詳細については、メトリクスサーバーを参照してください。

更新モード

VerticalPodAutoscalerは複数の 更新モード をサポートしており、リソース推奨値がいつ、どのようにPodに適用されるかを制御することができます。 更新モードは、VPA specのupdatePolicy内にあるupdateModeフィールドで設定します:

---
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

Off 更新モードでは、VPA recommenderは引き続きリソース使用量を分析し、推奨値を生成しますが、これらの推奨値はPodに自動的に適用されません。 推奨値は、VPAオブジェクトの.statusフィールドにのみ保存されます。

kubectlなどのツールを使用して、.statusに含まれる推奨値を表示できます。

Initial

Initial モードでは、VPAはPodが最初に作成されたときにのみリソース要求を設定します。 推奨値が時間とともに変化しても、既に実行中のPodのリソースは更新しません。 推奨値はPod作成時にのみ適用されます。

Recreate

Recreate モードでは、VPAは、現在のリソース要求が推奨値と大きく異なる場合、Podを退避させることでPodリソースを積極的に管理します。 Podが退避されると、ワークロードコントローラー(Deployment、StatefulSetなどを管理)が代替のPodを作成し、VPA admission controllerが更新されたリソース要求を新しいPodに適用します。

InPlaceOrRecreate

InPlaceOrRecreateモードでは、VPAは可能な限りPodを再起動せずにPodリソース要求と制限を更新しようとします。ただし、特定のリソース変更に対してインプレース更新を実行できない場合、VPAはPodの退避にフォールバック(Recreateモードと同様)し、ワークロードコントローラーが更新されたリソースで代替のPodを作成できるようにします。

このモードでは、updaterはコンテナリソースのインプレースリサイズ機能を使用して、推奨値をインプレースで適用します。

Auto(非推奨)

Autoモードは現在、Recreateモードのエイリアスであり、同じように動作します。 これは、将来的に自動更新戦略を拡張できるようにするために導入されました。

リソースポリシー

リソースポリシーを使用すると、VerticalPodAutoscalerが推奨値を生成し、更新を適用する方法を細かく調整できます。 リソース推奨値の境界を設定し、管理するリソースを指定し、Pod内の個々のコンテナに対して異なるポリシーを設定できます。

リソースポリシーは、VPA specのresourcePolicyフィールドで定義します:

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

これらのフィールドは、VPA推奨値の境界を設定します。 実際の使用データが異なる値を示唆していても、VPAはminAllowedを下回る、またはmaxAllowedを上回るリソースを推奨することはありません。

controlledResources

controlledResourcesフィールドは、VPAがPod内のコンテナに対して管理すべきリソースタイプを指定します。 指定されていない場合、VPAはデフォルトでCPUとメモリの両方を管理します。 VPAが特定のリソースのみを管理するように制限できます。 有効なリソース名には、cpuとmemoryが含まれます。

controlledValues

controlledValuesフィールドは、VPAがリソース要求、制限、または両方を制御するかどうかを決定します:

RequestsAndLimits

VPAは要求と制限の両方を設定します。制限は、Pod specで定義されたrequest-to-limitの比率に基づいて、要求に比例してスケールします。これはデフォルトのモードです。

RequestsOnly

VPAは要求のみを設定し、制限は変更されません。制限は維持され、使用量が制限を超えた場合、スロットリングまたはout-of-memory killをトリガーする可能性があります。

これら2つの概念の詳細については、要求と制限を参照してください。

LimitRangeリソース

Admission controllerとupdater VPAコンポーネントは、LimitRangeで定義された制約に準拠するよう推奨値を後処理します。 Kubernetesクラスター内でtypeがPodおよびContainerのLimitRangeリソースがチェックされます。

たとえば、Container LimitRangeリソースのmaxフィールドを超過した場合、両方のVPAコンポーネントは制限をmaxフィールドで定義された値まで引き下げ、Pod specにおけるrequest-to-limitの比率を維持するように、要求が比例して減少されます。

次の項目

クラスターで自動スケーリングを設定する場合、適切な数のノードを実行していることを確認するために、ノードの自動スケーリングの使用を検討することもお勧めします。 水平 Pod自動スケーリングの詳細についても参照してください。