Horizontal Pod Autoscaler (HPA) for Spring Boot Services
Fast recall
Quick revision
Core answer
behavior.scaleDown.stabilizationWindowSeconds (~300s) to prevent flapping. For event-driven workloads (Kafka, SQS), use KEDA instead — it can scale from zero.Knowledge of Kubernetes autoscaling and its prerequisites (resource requests, metrics server, stabilization)
Omitting resource requests (HPA reports `<unknown>` and never scales), or scaling CPU for an I/O-bound service that never shows CPU load
Explain the metrics pipeline (Metrics Server vs Prometheus Adapter), scale-down stabilization, PDB interaction with scale-down, KEDA for event-driven, and HPA + Cluster Autoscaler coupling
Interview-ready guide
Interview answer
The Horizontal Pod Autoscaler watches a metric and adjusts the replica count to keep it near a target. For Spring Boot APIs, CPU utilization is the standard starting point — when CPU climbs above target, HPA adds replicas; when it drops, HPA removes them.
How HPA calculates scaling
- Divides current metric by target: target CPU 50%, actual 80% → factor 1.6 → 3 replicas become 5.
- Requires metrics-server for CPU/memory —
kubectl top podsworking confirms the pipeline; HPA showing - Respects minReplicas and maxReplicas as hard bounds; set minReplicas high enough to handle sudden spikes before autoscaling reacts.
Scale-down cooldown
- Scales up aggressively (within 15 seconds) but conservatively down; default 5-minute stabilization before further reduction prevents flapping under variable load.
- Adjust
behavior.scaleDown.stabilizationWindowSeconds— shorter for stateless services that restart cheaply; longer for services with slow warm-up. - Scale-down marks the count on the Deployment but actual termination follows
terminationGracePeriodSeconds— ensure Spring Boot's graceful shutdown is configured so in-flight requests complete.
Custom metrics
- Via Micrometer → Prometheus → Prometheus Adapter → custom.metrics.k8s.io; HPA targets RPS or p95 latency or queue depth — semantically meaningful for business load.
- A Kafka consumer with 10,000 messages lag needs more replicas even at 5% CPU; CPU HPA never triggers — use KEDA which scales on Kafka lag directly and can scale from zero, which HPA cannot.
Production gotchas
- Pair HPA with Cluster Autoscaler or Karpenter — without node-level scaling, HPA-requested pods stay Pending when nodes are full.
- Don't run HPA and VPA together on the same CPU/memory dimension — they fight and cause oscillation.
- Alert on
kube_hpa_status_condition{condition="ScalingLimited"}— means you hit maxReplicas and traffic is not being absorbed.
Horizontal Pod Autoscaler (HPA) for Spring Boot Services
Direct Answer
HPA adjusts replica count based on CPU, memory, or custom metrics. Requires resource requests on the container (the denominator in the utilization formula). For Spring Boot, CPU often misleads — I/O-bound services look idle while queued. Prefer custom metrics via Micrometer → Prometheus → Prometheus Adapter → HPA. Configure behavior.scaleDown.stabilizationWindowSeconds (~300s) to prevent flapping. For event-driven workloads (Kafka, SQS), use KEDA instead — it can scale from zero.
Common Mistakes & Pitfalls
Omitting resource requests (HPA reports <unknown> and never scales), or scaling CPU for an I/O-bound service that never shows CPU load
Check your understanding
Answer these without looking back at the article.
- What is the Kubernetes metrics-server and how does it differ from Prometheus?
- What is KEDA and when is it better than HPA for Spring Boot services?
- How does HPA interact with PodDisruptionBudget during scale-down?
- Why should you not run HPA and VPA together on CPU/memory?
Related interview prep categories
2Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.