>_SecOpsLog_
BlogKubernetes

Kubernetes autoscaling with the Horizontal Pod Autoscaler

Scale on CPU, memory, or custom Prometheus metrics, and tune stabilization windows so the HorizontalPodAutoscaler won't flap under spiky, bursty load.

Dec 3, 2024·9 min readIntermediate

The Horizontal Pod Autoscaler adds and removes replicas to match load. CPU-target autoscaling is one manifest; the parts people get wrong are needing metrics-server, scaling on the right signal, and stopping the replica count from flapping under spiky traffic.

The basic CPU autoscaler

hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata: { name: api }
spec:
  scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: api }
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target: { type: Utilization, averageUtilization: 70 }
bash — watch it scalelive
kubectl get hpa api -w
NAME TARGETS REPLICAS
api 42%/70% 3
api 88%/70% 6 (scaled up under load)
CPU is a proxy, not the goal
For a queue worker, scale on queue depth; for an API, on requests-per-second or latency. HPA v2 supports custom and external metrics — use the signal your users actually feel.

Stop the flapping

hpa.yaml
behavior:
  scaleDown:
    stabilizationWindowSeconds: 300   # wait 5m before scaling in
    policies: [{ type: Percent, value: 50, periodSeconds: 60 }]
Go deeper in a courseKubernetes administrationAutoscaling, scheduling, and running workloads at scale.View course

Related posts

Kubernetes network policies: default-deny, keep DNS upJul 3, 2026 · 11 minPod Security Standards: enforce restricted without breakageApr 28, 2026 · 12 minKubernetes RBAC least privilege: from admin to scoped rolesApr 14, 2026 · 10 min