The Two Scalers
Kubernetes provides two primary autoscaling mechanisms for application workloads. They solve the same problem — handling variable load — but in fundamentally different ways.
Horizontal Pod Autoscaler (HPA): Adds or removes Pod replicas. "Traffic is high? Spin up more copies of the Pod." This is the standard approach for stateless applications.
Vertical Pod Autoscaler (VPA): Adjusts the CPU and memory Requests (and optionally Limits) of existing Pods. "Traffic is high? Give each Pod more resources." VPA requires restarting Pods to apply new resource values, since Requests are set at scheduling time.
The Conflict: Why You Can't Run Both on CPU
Running HPA and VPA simultaneously on the same metric — typically CPU — creates a feedback loop that causes both scalers to fight each other in a cycle called thrashing.
Here is the exact sequence:
- Load increases. CPU usage per Pod rises to 80%.
- VPA acts. VPA sees high CPU usage and increases the Pod's CPU Request from
250mto500mto give it more headroom. - HPA recalculates. HPA's formula is:
desiredReplicas = ceil(currentReplicas × (currentUsage / targetUsage)). The "currentUsage" is measured against the Request. Since VPA doubled the Request (the denominator), the calculated utilization drops from 80% to ~40% — even though actual traffic hasn't changed. - HPA scales in. HPA sees 40% utilization (below its 70% target) and removes replicas.
- Load concentrates. The same traffic is now spread across fewer Pods. CPU usage per Pod spikes back to 80%+.
- Loop repeats. VPA increases Requests again. HPA scales in again.
The result is oscillating replica counts and resource requests, with neither scaler converging on a stable state.
The Solution
The safe pattern is to use each scaler for what it does best:
| Workload Type | Recommended Scaler | Reason |
|---|---|---|
| Stateless Deployments (APIs, web servers) | HPA | Easy to add replicas; no data locality concerns |
| Stateful workloads (databases, caches) | VPA | Scaling out requires complex data rebalancing; scaling up is simpler |
| Both needed | HPA on custom metrics (RPS, queue depth) + VPA in Off or Auto mode |
Decouple the metrics each scaler watches |
VPA Modes:
- Off — VPA only records recommendations. You apply them manually. Safe to run alongside HPA.
- Initial — VPA sets Requests only when a Pod is first created. No ongoing adjustments.
- Auto — VPA continuously adjusts and restarts Pods. Conflicts with HPA on CPU/memory.
A common platform engineering interview question: "Can you run HPA and VPA together?" The correct answer is nuanced: yes, but only if they operate on different metrics. HPA should scale on a business metric (requests per second, queue depth) via the custom metrics API, while VPA handles right-sizing CPU/memory Requests. Running both on CPU simultaneously causes the thrashing loop described above. Demonstrating you know why it conflicts — the utilization formula's denominator changes — shows senior-level understanding.