Horizontal Pod Autoscaler

Understand HPA for scaling Pod replicas based on CPU, memory, custom metrics, and production traffic behavior.

Last reviewed: June 2026

·Kubernetes 1.28+kubectl 1.28+Helm 3+Managed Kubernetes: EKS, AKS, GKE
✅
Quick Understanding: HPA automatically changes replica counts for workloads based on metrics such as CPU, memory, or custom application signals.

🔍 What Is It?

Horizontal Pod Autoscaler is a Kubernetes controller that scales supported workloads such as Deployments and StatefulSets by adjusting replica count.

🎯 Why Do We Need It?

Applications experience changing load. HPA helps add replicas during demand and reduce replicas when demand drops.

Common developer mistakes:

  • →Treating Kubernetes YAML as copy-paste configuration instead of production architecture
  • →Ignoring requests, limits, health probes, security context, and rollout behavior
  • →Debugging only the Pod while forgetting Services, DNS, NetworkPolicies, nodes, and admission controls
  • →Manually changing live objects without updating Git or infrastructure automation

🏗️ What Happens in Real Projects?

An API Deployment scales from 4 to 30 replicas based on request latency or CPU. Cluster Autoscaler adds nodes if the cluster lacks capacity for new Pods.

⚙️ How It Works

HPA queries metrics APIs, compares current metrics to target values, and updates the workload's scale subresource. Metrics Server supports resource metrics; adapters support custom and external metrics.

💻 Example

HPA manifest — Scaling a Deployment by CPU utilization.

yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: orders-api
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: orders-api
  minReplicas: 4
  maxReplicas: 30
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 65

🤔 Common Confusions

❓ Does HPA add nodes?

No. HPA adds Pods. Cluster Autoscaler adds nodes when Pods cannot be scheduled.

❓ Can HPA work without requests?

CPU utilization scaling requires CPU requests to calculate utilization.

❓ Is CPU always the best metric?

No. Request rate, queue depth, or latency can be better for some applications.

🚨 Common Production Issues

**Missing CPU requests** breaks resource utilization scaling.

**Scaling on wrong metric** adds replicas without fixing the bottleneck.

**Too low maxReplicas** caps scale during traffic spikes.

**No cluster capacity** leaves scaled Pods pending.

✅ Best Practices

Set accurate resource requests

Choose metrics that reflect real demand

Load test HPA behavior

Pair HPA with Cluster Autoscaler

Use stabilization windows to reduce flapping

🏛️ Architect's Note

Senior Architect's Perspective

HPA is not magic capacity. It is a feedback loop. Good metrics and resource requests decide whether that loop helps or hurts.

💬 Frequently Asked Questions

Interview: How would you explain Horizontal Pod Autoscaler in a real Kubernetes project?

Horizontal Pod Autoscaler should be explained through the workload it supports, the Kubernetes object relationships, the failure modes, the security controls, and how it is observed and rolled back in production.

Interview: What production mistake do developers commonly make with Horizontal Pod Autoscaler?

The common mistake is making the object work once, then skipping ownership, resource sizing, rollout safety, monitoring, least privilege, and recovery behavior.

🎯 Key Takeaways

1HPA scales replicas
2Metrics Server or adapters provide metrics
3Requests are required for CPU utilization
4Cluster capacity must scale too

🎯 Practice this topic in interviews

↗ Where this topic fits

Sources

Sources / References

Use these Kubernetes references to verify the concept in official docs and continue into the most relevant SplashRide pages.

Related SplashRide pages