Vertical Pod Autoscaler

VPA is not part of core Kubernetes. It is a set of components defined by a custom resource that you install separately, and it needs a metrics source such as Metrics Server.

How it works

VPA has three components. The recommender analyses current and historical usage, including out-of-memory events, and writes target, lower bound and upper bound values into the object’s status. The updater compares running pods with those recommendations and, when allowed, evicts them or resizes them in place where supported, respecting PodDisruptionBudgets. The admission controller is a mutating webhook that applies the target to new or recreated pods.

The update mode controls what happens:

• Off: recommendations only, nothing applied.
• Initial: requests are set only when pods are created.
• Recreate: pods are evicted so they restart with new requests.
• InPlaceOrRecreate and InPlace: resize without a restart where possible.
• Auto: deprecated.

A practical example

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-app-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: my-app
  updatePolicy:
    updateMode: "Off"

After the workload has run for a while, kubectl describe vpa my-app-vpa shows the recommended CPU and memory. Teams often use these numbers to adjust the requests in their manifests by hand, then move to an automated mode once they trust the output.

Common mistakes

• Running VPA and the Horizontal Pod Autoscaler on the same CPU or memory metric for one workload, so they work against each other.
• Enabling an eviction mode on a single-replica workload without considering the restart.
• Not setting minimum and maximum bounds, so recommendations can exceed what nodes can offer.
• Treating recommendations from a short, unrepresentative period as final.
• Forgetting that changed requests and limits also affect scheduling and node count.

When to use it and when not to

Use VPA to right-size workloads whose requests were guessed, especially steady or stateful ones that cannot simply add replicas. Start in Off mode. Avoid automatic eviction for workloads that tolerate restarts poorly. Pair it with node provisioning such as Karpenter so right-sized pods translate into right-sized nodes. See our guidance on requests, limits, HPA and PDB.

See also

• Horizontal Pod Autoscaler
• Resource Requests and Limits
• Karpenter
• Pod Disruption Budget