Horizontal Pod Autoscaler

How HPA Computes Replicas

The HPA controller runs inside kube-controller-manager and polls metrics every --horizontal-pod-autoscaler-sync-period (default 15s). For CPU utilization it computes:

desiredReplicas = ceil(currentReplicas × currentUtilization / targetUtilization)

A ±10% tolerance band prevents flapping: targeting 50% with 4 pods keeps the count stable while measured utilization sits between 45% and 55%. Scaling up takes effect on the next sync. Scaling down waits for --horizontal-pod-autoscaler-downscale-stabilization-window (default 5m) so a brief traffic dip never shrinks capacity you are about to need again.

Creating and Configuring HPAs

The imperative generator still writes a real autoscaling/v2 object:

kubectl autoscale deployment api --cpu-percent=50 --min=2 --max=10
kubectl get hpa api -w

The declarative form combines metrics and controls the ramp:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: api }
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target: { type: Utilization, averageUtilization: 60 }

The optional behavior field sets scaleUp/scaleDown policies (pods or percent per second) and stabilization windows per direction.

Pitfalls and Interview Angles

Unknown replicas means metrics are missing. Confirm kubectl top pods works — that requires metrics-server, which feeds the resource metrics API the HPA reads.

Utilization is relative to requests. With no CPU request declared, utilization is undefined and CPU scaling cannot work. Set requests first; memory targets behave the same way.

The controller also ignores changes inside the tolerance band, and scale-down is delayed five minutes by design.

Interview angle: derive the ceil formula, explain the tolerance band, name where custom metrics come from (prometheus-adapter serving custom.metrics.k8s.io), and say why HPA and VPA must not both manage CPU.