Vertical Pod Autoscaler

What VPA Measures and Who Acts

HPA answers "how many pods?"; VPA answers "how big should each pod be?". Three components cooperate:

• Recommender reads metrics and history, then writes recommended requests/limits into the VPA object status
• Admission controller injects those values when new pods are created
• Updater evicts running pods whose declared requests deviate from the recommendation, so the admission controller can resize them on the next start

VPA needs metrics-server. Resizing happens by pod eviction — VPA cannot change resources of a running container in place.

Deploying and Reading Recommendations

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata: { name: api-vpa }
spec:
  targetRef: { apiVersion: apps/v1, kind: Deployment, name: api }
  updatePolicy:
    updateMode: Auto
  containerPolicies:
  - containerName: '*'
    mode: Auto
    minAllowed: { cpu: 100m, memory: 128Mi }
    maxAllowed: { cpu: 2, memory: 2Gi }

Inspect the output with kubectl describe vpa api-vpa — it reports recommendedTarget (for new pods) and recommended lower/upper bounds per container. Modes: Off (recommend only), Initial (set once at creation), Auto, and Recreate (evict and resize, ignoring controller refusals).

Pitfalls and Interview Angles

HPA conflict. If HPA scales on CPU utilization and VPA changes the CPU request, the utilization ratio shifts under the HPA — a feedback loop with oscillating replica counts. Run VPA in Off mode alongside a CPU HPA, or point the HPA at custom metrics.

Recreate costs availability. updateMode: Recreate evicts pods; without a readiness-gated rollout you take an outage.

Cold recommendations. Until the recommender has usage history its suggestions are conservative or incomplete — expect iterations before values stabilize.

Interview angle: contrast HPA and VPA inputs (replica count vs request size), explain why resizing requires eviction, and describe how you would safely combine both.