What Is Vertical Pod Autoscaling?
Vertical Pod Autoscaling (VPA) automatically adjusts the CPU and memory requests (and optionally limits) of containers based on their historical and current usage, rather than changing how many Pods are running. Where HPA answers 'how many copies do I need,' VPA answers 'how big should each copy be.' VPA is not a built-in Kubernetes API server component; it is a separate project (part of the autoscaler repository) composed of a Recommender, an Updater, and an Admission Controller that work together to keep resource requests realistic over time.
Cricket analogy: It is like a physio adjusting an individual bowler's workload, say capping overs per spell based on their measured fatigue, rather than adding more bowlers to the attack, which is the HPA equivalent.
The Three VPA Components
The Recommender watches historical usage (stored via a metrics history component) and current usage from the Metrics Server to calculate target, lower-bound, and upper-bound recommendations for each container, using a decayed histogram model that weights recent usage more heavily while still accounting for periodic peaks like nightly batch jobs. The Updater checks running Pods against these recommendations and, if a Pod's requests are too far off target and updateMode allows it, evicts the Pod so it can be rescheduled with new values, since Kubernetes does not support in-place resource updates for most resource changes on older API versions. The Admission Controller intercepts Pod creation (via a mutating webhook) and rewrites the new Pod's resource requests to match the current recommendation before it is scheduled.
Cricket analogy: It is like a team combining a data analyst who studies a bowler's spell-by-spell workload history, a fitness manager who decides when to rest that bowler for the next match, and a team doctor who sets the training load the moment the player reports for the next session.
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
name: checkout-vpa
spec:
targetRef:
apiVersion: "apps/v1"
kind: Deployment
name: checkout
updatePolicy:
updateMode: "Auto"
resourcePolicy:
containerPolicies:
- containerName: checkout
minAllowed:
cpu: 100m
memory: 128Mi
maxAllowed:
cpu: 2
memory: 2Gi
controlledResources: ["cpu", "memory"]Update Modes and Trade-offs
VPA supports four update modes: Off, which only produces recommendations visible via kubectl describe vpa without applying them; Initial, which sets requests only at Pod creation time; Recreate, which evicts and recreates Pods when recommendations drift, causing brief downtime unless a PodDisruptionBudget and multiple replicas absorb it; and Auto, which behaves like Recreate today but is intended to eventually use in-place resizing once that graduates to stable. Because Recreate/Auto modes evict Pods, VPA in those modes is risky for single-replica stateful workloads and should generally be paired with a PodDisruptionBudget so the Updater respects availability constraints during eviction.
Cricket analogy: It is like choosing between just noting a bowler's ideal workload for future planning (Off), only fixing their training load when they first join the squad (Initial), and actually pulling them off mid-match to adjust their spell length (Recreate/Auto), each carrying a different disruption cost to the team.
Do not run VPA in Auto/Recreate mode on the same metric (CPU or memory) that an HPA is also scaling on for the same workload; the two controllers can fight each other, with VPA resizing Pods while HPA changes their count, leading to unstable behavior. If you need both, scale VPA on memory only and HPA on CPU (or a custom metric), or use VPA only in Off/recommendation mode alongside HPA.
- VPA resizes containers' resource requests; HPA changes replica count. They answer different questions.
- VPA has three components: Recommender, Updater, and Admission Controller (mutating webhook).
- Update modes range from Off (recommend only) to Auto (evict and recreate Pods with new values).
- Recreate/Auto modes cause Pod eviction and restart, so pair with a PodDisruptionBudget and multiple replicas.
- Avoid running VPA and HPA on the same metric for the same workload to prevent controller conflicts.
- VPA is a separate project from core Kubernetes, installed via the autoscaler repository's manifests.
- In-place Pod resizing (no eviction) is an evolving Kubernetes feature that VPA is expected to adopt over time.
Practice what you learned
1. What is the fundamental difference between VPA and HPA?
2. Which VPA component actually rewrites a new Pod's resource requests before scheduling?
3. Which VPA update mode only produces recommendations without changing any running or new Pods?
4. Why is running VPA in Recreate mode risky for a single-replica stateful workload?
5. What should you avoid when configuring both VPA and HPA for the same Deployment?
Was this page helpful?
You May Also Like
Horizontal Pod Autoscaling
Learn how Kubernetes automatically scales the number of Pod replicas in and out based on CPU, memory, and custom metrics.
Resource Requests and Limits
Understand how Kubernetes uses requests for scheduling and limits for runtime enforcement, and how both determine a Pod's QoS class.
Cluster Autoscaling
Learn how the Cluster Autoscaler adds and removes worker nodes so Pod-level autoscalers always have capacity to grow into.