Horizontal Pod Autoscaler vs Vertical Pod Autoscaler
Compare Horizontal and Vertical Pod Autoscalers in Kubernetes — scale-out vs scale-up, how each works, and when to use which.
Expected Interview Answer
The Horizontal Pod Autoscaler (HPA) scales a workload out by changing the number of Pod replicas based on observed metrics, while the Vertical Pod Autoscaler (VPA) scales a workload up by adjusting the CPU and memory requests/limits of the existing Pods themselves.
HPA polls metrics — typically CPU/memory utilization via the metrics-server, or custom/external metrics via an adapter — on a fixed interval, compares them to the target defined in the HPA object, and computes the desired replica count using the formula desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric), then updates the replica count on the underlying Deployment or StatefulSet. VPA instead watches the same kind of resource-usage signals but, rather than adding replicas, recommends or automatically rewrites the container’s resource requests, which typically requires evicting and recreating the Pod since resource requests cannot be changed on a running Pod in most Kubernetes versions. HPA suits stateless, horizontally scalable workloads like web servers where adding more instances behind a Service handles more load; VPA suits workloads that cannot be trivially replicated, like a single-instance batch job or a database, where the right-sized container matters more than replica count. Running HPA and VPA together on the same metric (like CPU) is explicitly discouraged because they can fight each other, though VPA on memory combined with HPA on custom metrics is a common safe pairing.
- HPA handles bursty, replicable stateless traffic efficiently
- VPA right-sizes workloads that cannot easily be replicated
- Both reduce manual capacity guesswork
- Together they cover both scale-out and scale-up scenarios when configured carefully
AI Mentor Explanation
HPA is like a franchise adding more players to the squad when a tournament gets busier — same skill level per player, just more of them fielding across matches. VPA is like instead upgrading one key all-rounder’s training and equipment so they personally handle a heavier workload without adding teammates. A T20 league facing more simultaneous fixtures benefits from HPA’s approach of fielding more squads. A single specialist bowler who cannot be duplicated benefits from VPA’s approach of making that one player stronger.
Step-by-Step Explanation
Step 1
Metrics are collected
metrics-server or a custom metrics adapter exposes CPU/memory or custom signals to the autoscalers.
Step 2
HPA computes desired replicas
It compares current metric value to target and scales the replica count on the Deployment/StatefulSet.
Step 3
VPA computes desired resources
It analyzes historical usage and recommends or applies new CPU/memory requests to the Pod template.
Step 4
Pods are updated
HPA adds/removes Pods without disruption to existing ones; VPA typically evicts and recreates Pods with new resource values.
What Interviewer Expects
- Clear distinction: scale-out (more Pods) vs scale-up (bigger Pods)
- Understanding of the HPA replica calculation formula
- Awareness that VPA usually requires Pod recreation to apply new resources
- Knowledge of when combining HPA and VPA on the same metric is risky
Common Mistakes
- Treating HPA and VPA as interchangeable
- Forgetting VPA changes require restarting the Pod in most setups
- Running HPA and VPA on the same CPU metric without conflict awareness
- Assuming HPA works without metrics-server or a metrics adapter installed
Best Answer (HR Friendly)
“HPA and VPA solve scaling in two different directions. HPA adds or removes copies of a Pod based on load, which works great for stateless services that can run many instances. VPA instead makes each individual Pod bigger or smaller by adjusting its CPU and memory allocation, which is better for workloads that cannot simply be duplicated, like a single database instance.”
Code Example
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: web-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70Follow-up Questions
- How does HPA decide when to scale down versus scale up?
- Why can VPA cause a brief disruption when it applies a recommendation?
- When would you choose VPA over HPA for a single-instance workload?
- How would you scale on a custom metric like queue depth instead of CPU?
MCQ Practice
1. What does the Horizontal Pod Autoscaler change?
HPA scales out or in by changing the replica count of the target Deployment or StatefulSet.
2. What does the Vertical Pod Autoscaler typically require to apply a new recommendation?
Since resource requests generally cannot change on a running Pod, VPA evicts and recreates it to apply new CPU/memory values.
3. Which workload type is HPA best suited for?
HPA works best for stateless workloads that can safely run many parallel replicas behind a Service.
Flash Cards
What does HPA scale? — The number of Pod replicas, based on observed metrics.
What does VPA scale? — The CPU/memory requests of the Pod itself.
Does VPA disrupt running Pods? — Usually yes — it evicts and recreates the Pod to apply new resources.
Should HPA and VPA share the same metric? — No — using the same metric (e.g. CPU) for both can cause conflicts.