VPA — Vertical Pod Autoscaling concepts

The Vertical Pod Autoscaler (VPA) adjusts the resource requests and limits of pods based on historical usage. The HPA scales the number of pods; the VPA scales the resources of each pod. This lesson walks the VPA, the components, and the relationship with HPA.

What the VPA does

The VPA is a controller that runs in the cluster. It monitors the resource usage of pods and adjusts the resource requests and limits.

flowchart LR
    A[Pod resource usage] --> B[Recommender]
    B --> C[Recommended requests]
    C --> D[Updater]
    D --> E[Evict old pods]
    E --> F[New pods with new requests]
    F --> G[Admission controller]
    G --> H[New resource requests on new pods]

The VPA observes the actual usage, recommends the appropriate requests, and updates the pods.

The VPA components

The VPA has three components:

flowchart LR
    A[VPA] --> B[Recommender]
    A --> C[Updater]
    A --> D[Admission Controller]
    B --> E[Compute recommended requests]
    C --> F[Evict pods with old requests]
    D --> G[Set requests on new pods]

• Recommender: observes the pod’s resource usage and computes the recommended requests.
• Updater: evicts pods that need new requests.
• Admission Controller: sets the new requests on new pods (mutating webhook).

The VPA configuration

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: nginx-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx
  updatePolicy:
    updateMode: "Auto"
  resourcePolicy:
    containerPolicies:
    - containerName: "*"
      minAllowed:
        cpu: 100m
        memory: 128Mi
      maxAllowed:
        cpu: 2
        memory: 4Gi

The VPA targets a Deployment. The updateMode: Auto allows the VPA to update the pods automatically.

The update modes

The VPA has three update modes:

• Off: the VPA only computes recommendations; it does not update pods.
• Initial: the VPA sets the requests on pod creation only; it does not update running pods.
• Auto: the VPA updates running pods as well.

flowchart LR
    A[Update mode] --> B[Off]
    A --> C[Initial]
    A --> D[Auto]
    B --> E[Recommendations only]
    C --> F[Set on pod creation]
    D --> G[Update running pods]

The recommender

The recommender observes the pod’s resource usage:

Pod: nginx-1-abc
CPU usage: 50m (current)
Memory usage: 128Mi (current)
CPU recommendation: 100m (recommended)
Memory recommendation: 256Mi (recommended)

The recommender uses historical data to compute the recommended requests. The recommendation is conservative; the pod’s usage is at the 90th percentile.

The updater

The updater evicts pods with sub-optimal requests:

sequenceDiagram
    participant VPA as VPA updater
    participant API as API server
    participant K as Kubelet
    VPA->>API: list pods with mismatched requests
    API-->>VPA: 3 pods
    VPA->>API: evict pod nginx-1-abc
    API->>K: terminate pod
    K->>API: pod terminated
    API->>API: Deployment creates new pod
    Note over API: New pod has the new requests

The updater evicts one pod at a time to avoid disrupting the workload.

The admission controller

The admission controller sets the requests on new pods:

sequenceDiagram
    participant API as API server
    participant VPA as VPA admission controller
    participant D as Deployment
    D->>API: create pod
    API->>VPA: mutate pod
    VPA->>VPA: set resource requests
    VPA-->>API: mutated pod
    API->>K: schedule pod
    Note over K: New pod has the new requests

The admission controller is a mutating webhook. It intercepts the pod creation and sets the requests.

The relationship with HPA

The VPA and HPA are complementary:

flowchart LR
    A[Workload] --> B[VPA]
    A --> C[HPA]
    B --> D[Right-size resources per pod]
    C --> E[Scale number of pods]
    D --> F[Better resource utilization]
    E --> F

The VPA right-sizes the resources; the HPA scales the replicas. Used together, they optimize the workload’s resource utilization.

However, mixing them on the same metric is an anti-pattern:

# Anti-pattern: VPA and HPA on CPU
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: nginx-vpa
spec:
  updatePolicy:
    updateMode: "Auto"
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  metrics:
  - type: Resource
    resource:
      name: cpu

The VPA may change the request, which changes the CPU utilization, which triggers the HPA, which may trigger the VPA again. The feedback loop is unstable.

Cross-course references

• The HPA course (Part LXXXII) covers the horizontal alternative.
• The Prometheus course covers custom metrics.
• The Observability course covers VPA metrics.

Quiz

Production discipline

• Choose VPA or HPA, not both. Mixing them is an anti-pattern.
• Use updateMode: Auto in production. The VPA updates running pods.
• Set minAllowed and maxAllowed. Bound the recommendations.
• Test the VPA on staging. Catch the eviction issues before production.
• Monitor the VPA metrics. Prometheus exposes them.
• Document the VPA config. The target, the bounds, the rationale.

The VPA is the workload’s right-sizing tool. Operating it well is choosing the right workload, the right update mode, and the right bounds.