Horizontal Pod Autoscaler

The Horizontal Pod Autoscaler (HPA) adjusts the number of Pod replicas to match load. It watches a metric — CPU utilization, memory, or a custom signal — and scales a Deployment up or down to keep that metric near a target. It is how a workload absorbs traffic swings without manual intervention.

The HPA is a control loop like everything else in Kubernetes, with a few specific behaviors — a metrics dependency, a stabilization window, and a hard requirement on resource requests — that determine whether it works smoothly or thrashes.

How the HPA Computes Replicas

The HPA periodically reads the current metric value across the Pods, compares it to the target, and computes the replica count that would bring the metric to target — roughly, desired = current_replicas × (current_metric ÷ target_metric). If average CPU is 80% against a 50% target, it scales out proportionally. It then clamps to the configured minReplicas and maxReplicas.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50

It Needs Requests and a Metrics Source

CPU and memory utilization are measured relative to the Pod's request — "80% CPU" means 80% of the requested CPU. So an HPA on CPU does nothing useful if the container has no CPU request; this is the single most common reason an HPA "isn't scaling." The HPA also needs a metrics source: metrics-server for CPU/memory, or an adapter exposing custom and external metrics (often backed by Prometheus) for anything else.

Stabilization and Thrashing

Naive scaling oscillates — scale out on a spike, scale in immediately, repeat. The HPA dampens this with a stabilization window (it considers recent recommendations and, by default, scales down conservatively over several minutes while scaling up quickly) and configurable scaling policies that cap how fast replicas change. Tuning these is how you trade responsiveness against stability.

Custom and External Metrics

CPU is a poor proxy for many workloads. Queue-based systems scale better on queue depth; web services on requests-per-second or latency. The HPA's autoscaling/v2 API supports custom metrics (from inside the cluster) and external metrics (from outside, like a cloud queue length). For event-driven scale-to-zero, KEDA extends the HPA with dozens of event sources. Choosing the metric that actually reflects load is more important than tuning the loop.