Oracle Cloud Hangout Cafe Season 4 #5「Kubernetesのオートスケーリング」(2021年8月4日開催)

Podの垂直スケール

ここからは、Podの垂直スケール(Vertical Pod Autoscaler、以下VPA)について見ていきます。

Podの垂直スケールの概要

Podの垂直スケール(VPA)は、コンテナアプリケーション環境(Pod)を垂直スケール(スケールアップ/ダウン)させる仕組みです。具体的には、Podに要求されるCPU/メモリ(Resource Requests)を上書きして、Pod(≠Deployment)のスペックを調整することでスケールさせます。スケール定義はVPA(VerticalPodAutoscaler)リソースとして定義します。

VPAは複数のControllerの組み合わせで実現されており、単一のControllerで実現されるHPAとは少し仕組みが異なります。主にUpdater、Admission Controller/Admission Plugin(以下、Admission Controller)、Recommenderという3つのコンポーネントが連携して動作し、原則としてスケール時にはPodの再起動が発生(Resource Requests/Limitsを適用させるため)します。in-place update(再起動なしのスケール)は現時点で未実装です。

VPA

VPA時の具体的な動きとしては、VPAが.spec.containers[].resources.requests(起動時に割り当てるCPU/メモリ)の推奨値を算出し、以下のイメージのように.spec.containers[].resources.requests/limitsを上書きすることで実現します。このとき、Resource Limitsの値はResource RequestsとLimitsの初期値の比率によって決定され、同様に上書きされます。

例えば、Resource Requestsに定義したCPUが0.1 core、Resource Limitsに定義したCPUが0.5 coreの時、VPAが算出したResource Requestsの推奨値が0.2 coreだった場合、Resource Requestsは0.2 core、Resource Limitsは1 coreに上書きされます(Resource Requests:Resource Limits = 1:5)。

VPA-action

VPAを実現するコンポーネントには、Recommender、Updater、Admission Controllerの3つがあります。この3つのコンポーネントは、それぞれ以下の役割で動きます。

これらを図にすると、下図のようなイメージです。

VPA-architecture

VPAリソースの定義

VPAリソースの定義方法を説明します。VPAリソースに定義する内容は主に以下の3つです。

上記のアップデートポリシーには、以下の4種類がありします。アップデートポリシーはスケールする際の挙動を示します。

実際のVPAリソース例は以下です。

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

Podリソースのin-place Resize

Kubernetes v1.27からPodリソースのin-place Resize(再起動なしでのスケールアップ)がα機能として実装されています。この機能をVPAと連携させることで、evict(再起動)なしでのPodのスケールアップを実現できます。ただし、VPAではまだPodリソースのin-place Resizeを利用したin-place updateは実装されていません。詳細はAEP-4016で管理されています。

Podリソースのin-place Resizeを利用するにはInPlacePodVerticalScalingのFeatureGatesを有効化する必要があるため、クラウドベンダーなどが提供するマネージドなKubernetesサービスでは利用できない可能性があります。

以下に一例を示します。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: RestartContainer
    resources:
      limits:
        memory: "100Mi"
        cpu: "100m"
      requests:
        memory: "100Mi"
        cpu: "100m"

.spec.containers[].resizePolicyにCPUとメモリに対するスケールアップ時の挙動を定義します。上記のケースではCPUのスケール時は再起動なし(restartPolicy: NotRequired)でのスケールアップが実施され、メモリのスケール時には再起動が実施されます(restartPolicy: RestartContainer)。

また、再起動なしでのスケールアップの場合には、現状時間を要することも確認されており、今後修正予定です(Pod Resize - long delay in updating)。

HPAとVPAの併用

HPAとVPAの併用について説明します。HPAとVPAの併用は、それぞれがCPUとメモリを利用する場合は禁止されています(参考)。

CPUとメモリを利用したHPA/VPAでは、スケール対象がそれぞれDeploymentとPodで異なるため、VPAによりスケールされたPodにHPAでのスケールを適用するとPod毎のResource Requestsが煩雑になり、想定通りのスケール挙動にならない可能性があります。例えば、HPAが実施された結果Pod毎のスペックが異なり、オーバースケールだったり、スケール不足になることがあります。

HPAとVPAを併用する場合は、HPAとVPAのスケールメトリクスを分離する(HPAはCPUを利用する、VPAはメモリを利用するなど)か、PodsのCPU/メモリ以外のメトリクスを利用しましょう。

VPAのデモ

当日のセッションでは、VPAのデモを実施しています。詳細はセッション動画をご確認ください。

HPAとVPAのまとめ

ここまでで、HPAとVPAについて整理します。

• HPA(Podの数が増減するスケール方式)
  • Podが使用しているリソースとResource Requestsをもとに水平スケール、スケール対象はDeployment
    • スケールの範囲や振る舞いをユーザ側で定義する必要性
    • アプリケーション(Pod)にかかる負荷の傾向を把握
    • コスト(経済/リソース)を考慮しながらスケール範囲の見極め
    • アプリケーションの特性や運用、サービス指標(SLA/SLOも含む)などを考慮し、スケールの振る舞いを定義

• VPA(Podのスペック(.spec.containers[].resources.requests/limits)を拡張するスケール方式)
  • Podが使用しているリソース(CPU/メモリ)をもとに垂直スケール
    • 実際のリソース使用量を把握できていなくても、よしなにスケール(実績値との乖離を防止)
  • 実際にスケールさせなくても、算出された推奨値を確認するだけという利用方法もある
  • クラスタ全体のリソースを有効活用できる
  • 現時点では、原則としてはPodの再起動が必要(in-place updateは未実装)