Horizontal Pod Autoscaler

Scaling by count, automatically

A HorizontalPodAutoscaler (HPA) is a controller — same reconciliation pattern as everything else in this course — that watches a metric and adjusts a Deployment's (or StatefulSet's) replica count to keep that metric near a target. The most common target: CPU utilization as a percentage of each pod's requested CPU.

That last word matters more than it looks like it should: HPA computes percentage of request, not an absolute number. A pod with no CPU request has nothing to divide by — HPA can't compute a percentage of zero, so it simply can't scale that workload on CPU at all. This is why Module 6's "always set requests" advice wasn't just about scheduling and QoS; it's a hard prerequisite for autoscaling too.

Deployment → ReplicaSet → Pods

Deployment: web

spec.replicas = 3

−scale+

ReplicaSet: web-7d9f6c

desired: 3 · current: 3

📦 podweb-1

📦 podweb-2

📦 podweb-3

The loop, concretely

1. metrics-server scrapes each kubelet's cAdvisor stats and exposes them through the metrics.k8s.io API — this is a separate, optional add-on, not something the API server does natively.
2. The HPA controller polls that API on a sync period (default ~15s), averages utilization across the target's pods.
3. It computes desired replicas ≈ current × (currentMetric / targetMetric), clamped between minReplicas and maxReplicas.
4. It writes a new replicas value onto the Deployment — which the ReplicaSet controller from Module 3 then reconciles exactly like a manual scale, because to that controller, it is a manual scale. HPA doesn't talk to pods directly; it only ever edits the one number.

The API is autoscaling/v2 — the older v1 (CPU-only, no behavior tuning) and v2beta1/v2beta2 are gone from current Kubernetes; v2 has supported CPU, memory, and custom/external metrics, plus configurable scale-up/scale-down behavior, for a long time now.

Why this feels slow the first time you watch it

Nothing is instant here: the kubelet scrapes periodically, metrics-server scrapes the kubelet periodically, the HPA polls metrics-server periodically, and a new pod still needs to schedule, pull its image, and pass readiness before it counts. Budget a minute or two for a real scale-up, not seconds — that's normal, not a bug, and it's exactly what you'll see in this lesson's lab.

The infrastructure analogy

This is the direct platform equivalent of a cloud provider's Auto Scaling Group scaling policy on a CloudWatch metric — same shape (observe a metric, compare to target, adjust capacity), just one layer down: scaling pod count inside a node pool instead of scaling instance count inside a VPC. Module 15 covers the layer above this — scaling the nodes themselves.