Understanding the Kubernetes Vertical Pod Autoscaler
The Vertical Pod Autoscaler (VPA) is a Kubernetes add-on that automatically adjusts a container’s CPU and memory resource requests and limits based on observed historical usage, rather than the number of replicas. Where the Horizontal Pod Autoscaler (HPA) scales workloads out by changing spec.replicas, the VPA scales workloads up or down by resizing individual Pods – correcting requests that were set too high (wasting cluster capacity) or too low (risking throttling or OOMKilled Pods).
How It Works
VPA is deployed as three components: a Recommender that watches historical resource usage via metrics and calculates suggested requests, an Updater that evicts Pods whose current requests deviate significantly from the recommendation, and an Admission Controller (via a webhook) that rewrites resource requests on Pod creation to match the latest recommendation. A VerticalPodAutoscaler object references a target workload (Deployment, StatefulSet, etc.) and sets an updateMode: Off simply produces recommendations without acting, Initial applies recommendations only at Pod creation, and Auto both recommends and actively evicts and resizes running Pods.
Simple Example
A team notices their reporting-service Pods were given resources.requests.memory of 2Gi by a developer guessing at the time, but actual usage hovers around 512Mi. They create a VerticalPodAutoscaler targeting the Deployment with updateMode set to Off first, and after a few days review the recommendation via kubectl describe vpa, which suggests 600Mi. Confident in the number, they switch updateMode to Auto; the VPA’s Updater then evicts existing Pods over time and the admission webhook sets new Pods to the recommended value, freeing up over 1Gi per replica across the cluster.
Common Use Cases
Right-Sizing Workloads
Teams use VPA in recommendation-only mode to identify over- or under-provisioned workloads without any disruptive automatic action, then apply the numbers manually or via GitOps.
Batch and Single-Replica Workloads
Workloads that can’t scale horizontally (a single-replica stateful service, a batch Job) benefit from vertical scaling since HPA isn’t a good fit for them.
Cost Optimization
FinOps-driven teams use VPA recommendations across a fleet of services to reclaim wasted CPU and memory requests that inflate node counts unnecessarily.
Benefits
- Removes guesswork from setting resource requests, replacing manual tuning with data-driven recommendations.
- Reduces both resource waste (over-requested Pods blocking bin-packing) and instability (under-requested Pods getting OOMKilled or throttled).
- Works well alongside Cluster Autoscaler or Karpenter, since more accurate requests lead to more accurate scaling decisions.
Limitations and Risks
- VPA in Auto mode evicts and restarts Pods to resize them, which causes brief disruption – not suitable for workloads that can’t tolerate restarts without careful PodDisruptionBudget configuration.
- VPA and HPA should not both control the same resource metric (CPU) for the same workload simultaneously – they can fight each other, so combining them typically means VPA manages memory while HPA manages CPU-based or custom-metric scaling.
- Recommendations are based on historical usage and can lag behind sudden workload pattern changes, like a new feature launch that changes memory profile overnight.
- The admission webhook is a critical dependency – if it’s misconfigured or down, Pod creation for targeted workloads can be affected.
Best Practices
- Start every VPA rollout in updateMode: Off to review recommendations before allowing automatic changes.
- Set minAllowed and maxAllowed bounds on the VerticalPodAutoscaler to prevent runaway recommendations in either direction.
- Avoid using VPA and HPA on the same resource metric for the same workload; split responsibility between them deliberately.
- Pair Auto mode with a properly configured PodDisruptionBudget so resize-triggered evictions don’t take down all replicas at once.
- Re-evaluate recommendations after major application or traffic pattern changes rather than assuming they remain accurate indefinitely.
Frequently Asked Questions
What is Kubernetes Vertical Pod Autoscaler?
The Vertical Pod Autoscaler automatically adjusts a container's CPU and memory requests based on observed usage history, correcting over- or under-provisioned Pods without changing replica count.
How does Kubernetes Vertical Pod Autoscaler work?
Kubernetes Vertical Pod Autoscaler works by combining the components described in the sections above. The main page walks through the architecture, the typical use cases, and the trade-offs to weigh before adopting it.
Why does Kubernetes Vertical Pod Autoscaler matter?
Teams adopt Kubernetes Vertical Pod Autoscaler to ship faster, run more reliably, and reduce the cognitive load on engineers. The benefits, limits, and adjacent tools are covered in the body above.
When should you use Kubernetes Vertical Pod Autoscaler?
Use Kubernetes Vertical Pod Autoscaler when the problems it solves match what your team is hitting today. The page above outlines the signals that mean you should adopt it now, and the cases where a simpler approach is fine.
