Vertical Pod Autoscaler
Kubernetes per-pod resource autoscaling tool
The Vertical Pod Autoscaler (VPA) is a Kubernetes tool that automatically adjusts the CPU and memory requests and limits of individual pods based on their observed resource usage over time.
Definition
The Vertical Pod Autoscaler (VPA) is a Kubernetes tool that automatically adjusts the CPU and memory requests and limits of individual pods based on their observed resource usage over time.
Overview
Where the Horizontal Pod Autoscaler changes how many pod replicas run, the Vertical Pod Autoscaler changes how much CPU and memory each pod is allocated. It addresses a common and persistent problem: developers often guess at resource requests and limits when writing a pod spec, and those guesses are frequently wrong, either too low, causing throttling or out-of-memory kills, or too generous, wasting cluster capacity and money. VPA replaces guesswork with data by monitoring actual usage and recommending, or automatically applying, more accurate values. VPA operates through three components: a recommender, which analyzes historical and current resource usage to calculate suggested requests and limits; an updater, which evicts pods whose resource allocation is significantly out of line with the recommendation so they can be rescheduled with new values; and an admission controller, which injects the recommended resource values into pods as they are created. VPA can run in different modes — `Off` mode only produces recommendations without applying them, while `Auto` mode actively evicts and resizes pods. A key limitation historically was that VPA needed to evict and recreate a pod to change its resource allocation, causing disruption; newer Kubernetes versions have added in-place pod resizing, which allows some resource changes without a restart, though full VPA support for this is still evolving. Because of the eviction behavior, VPA is typically used carefully in conjunction with Pod Disruption Budgets to avoid violating availability guarantees during resize events. VPA and HPA are generally not recommended for use together on the same metric (such as both scaling on CPU), since they can conflict — VPA changing per-pod CPU allocation while HPA is also reacting to CPU utilization can create feedback loops — though using VPA for memory and HPA for a separate custom metric is a common, safe combination.
Key Features
- Automatically adjusts CPU and memory requests and limits per pod
- Uses a recommender, updater, and admission controller architecture
- Replaces manual guesswork in setting resource requests and limits
- Can run in recommendation-only or fully automatic mode
- Historically requires pod eviction to apply new resource values
- Should generally not scale on the same metric as HPA simultaneously
- Works alongside Pod Disruption Budgets to limit disruption during resize