How Does Horizontal Pod Autoscaling Work in Kubernetes?
Understand how Kubernetes HPA computes desired replicas, polls metrics, and uses stabilization windows to scale pods reliably.
Expected Interview Answer
The Horizontal Pod Autoscaler (HPA) in Kubernetes automatically increases or decreases the number of pod replicas in a deployment by periodically comparing observed metrics, like CPU utilization or a custom metric, against a target value and computing the desired replica count from that ratio.
The HPA controller polls the metrics API (typically metrics-server for CPU/memory, or a custom/external metrics adapter for things like queue depth or requests-per-second) every sync period, by default every 15 seconds. It computes the desired replica count roughly as: desiredReplicas = ceil(currentReplicas x (currentMetricValue / targetMetricValue)), then applies that change to the deployment’s replica count, subject to configured min and max bounds. To avoid thrashing, Kubernetes applies a stabilization window (default 5 minutes for scale-down, near-immediate for scale-up as of recent versions) that looks back over recent recommendations and picks the safest one rather than reacting to a single noisy reading. HPA works purely on replica count (horizontal scaling); it is complementary to the Vertical Pod Autoscaler, which resizes individual pod resource requests, and to the Cluster Autoscaler, which adds or removes nodes when pods cannot be scheduled due to insufficient cluster capacity.
- Automatically matches pod replica count to real load without manual intervention
- Supports custom and external metrics beyond CPU, like queue depth or request latency
- Stabilization windows prevent rapid scale up/down oscillation from noisy metrics
- Composes with the Cluster Autoscaler so node capacity grows alongside pod count
AI Mentor Explanation
Horizontal Pod Autoscaling is like a franchise deciding how many net bowlers to call in for a training session based on how many batters are hitting the nets. Every fifteen minutes, the team manager checks the ratio of batters waiting to bowlers currently working, and if it exceeds the target ratio, more bowlers are called up to bring it back in line. There is a cooldown before releasing bowlers early, so the squad does not release someone only to call them back moments later when one batter briefly steps away. The manager also respects a minimum and maximum number of bowlers allowed on the roster for the session, exactly like HPA’s min and max replica bounds.
Step-by-Step Explanation
Step 1
Define the HPA target
Attach an HPA resource to a Deployment/ReplicaSet specifying the metric (CPU, memory, or custom) and target value, plus min/max replica bounds.
Step 2
Poll current metrics
Every sync period (default 15s), the HPA controller queries metrics-server or a custom metrics adapter for current values across pods.
Step 3
Compute desired replicas
desiredReplicas = ceil(currentReplicas x (currentMetricValue / targetMetricValue)), clamped to minReplicas and maxReplicas.
Step 4
Apply with stabilization
The controller applies a stabilization window (looking at recent recommendations) before scaling down, to avoid thrashing from transient dips.
What Interviewer Expects
- Describes the core formula: desired replicas scales proportionally with the metric-to-target ratio
- Mentions the default sync/polling interval and metrics-server or custom metrics adapters
- Explains the stabilization window and why it prevents thrashing
- Distinguishes HPA (replica count) from Vertical Pod Autoscaler (resource sizing) and Cluster Autoscaler (node count)
Common Mistakes
- Confusing HPA (horizontal, replica count) with VPA (vertical, per-pod resource sizing)
- Forgetting that pods must have resource requests set for CPU-based HPA to work at all
- Not mentioning the stabilization window and its role in preventing scale-down thrashing
- Ignoring that pod scheduling can fail if the Cluster Autoscaler is not also configured to add nodes
Best Answer (HR Friendly)
“Horizontal Pod Autoscaling automatically changes how many copies of an application are running in Kubernetes, based on real usage like CPU load. If usage climbs above a target level, Kubernetes starts more copies to spread the load, and when usage drops back down, it removes copies after a safety delay so it does not flip-flop back and forth too quickly.”
Code Example
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: orders-service-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: orders-service
minReplicas: 3
maxReplicas: 30
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 65
behavior:
scaleDown:
stabilizationWindowSeconds: 300
scaleUp:
stabilizationWindowSeconds: 0Follow-up Questions
- What is the difference between HPA, VPA, and the Cluster Autoscaler?
- Why do pods need CPU resource requests set for CPU-based HPA to function?
- How would you configure HPA to scale on a custom metric like requests-per-second?
- What happens if the HPA wants to scale up but the cluster has no available node capacity?
MCQ Practice
1. What does the Horizontal Pod Autoscaler primarily adjust?
HPA scales horizontally by changing the replica count of pods; resizing a single pod’s resources is the Vertical Pod Autoscaler’s job.
2. Why is a stabilization window used before scaling down?
The stabilization window looks at recent recommendations rather than a single reading, so a momentary dip does not trigger premature scale-down.
3. What must be set on a pod’s spec for CPU-based HPA to compute utilization correctly?
HPA computes CPU utilization as a percentage of the requested CPU, so without a resource request, utilization cannot be calculated.
Flash Cards
What does HPA scale? — The number of pod replicas in a deployment, based on observed metrics vs a target value.
HPA desired replicas formula? — ceil(currentReplicas x (currentMetricValue / targetMetricValue)), bounded by min/max replicas.
Why a stabilization window? — To avoid scale-down thrashing from brief, noisy dips in the observed metric.
HPA vs VPA vs Cluster Autoscaler? — HPA changes replica count; VPA resizes a pod’s resource requests; Cluster Autoscaler changes node count.