Horizontal Pod Autoscaling

Analogy categoryAnalogies

Scaling Workloads Automatically

The HorizontalPodAutoscaler (HPA) is a Kubernetes controller that automatically increases or decreases the number of Pod replicas in a Deployment, ReplicaSet, or StatefulSet based on observed metrics such as CPU utilization, memory usage, or custom application metrics, keeping workloads responsive without manual intervention. HPA relies on the metrics.k8s.io API, typically served by the Metrics Server add-on, which aggregates resource usage from kubelets — without it, kubectl top and CPU/memory-based HPAs cannot function.

🏏

Cricket analogy: A tournament organizer automatically calls up reserve players from the bench based on how hard the current squad is working, but this only functions if there's a scoreboard system (Metrics Server) actually tracking each player's exertion levels in real time.

Defining a CPU-Based HPA

The most common HPA configuration targets average CPU utilization across a Deployment's Pods, scaling out when usage exceeds a threshold and scaling in when it drops.

🏏

Cricket analogy: The most common squad-rotation rule targets a bowler's average workload across an over-heavy series, bringing in a fresh bowler once average exertion exceeds a threshold and resting one when the workload drops, mirroring HPA's CPU-based scale-out and scale-in.

yaml

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80

Requirement: Resource Requests on Pods

CPU/memory-based HPAs calculate utilization as a percentage of the container's resource requests. If a target Deployment's Pods don't specify requests.cpu, the HPA cannot compute utilization and will fail to scale.

🏏

Cricket analogy: A workload threshold for resting a bowler only makes sense relative to their known personal fitness baseline; if a bowler's baseline capacity was never recorded, the coach can't compute what percentage they're at and can't decide when to rotate them out.

yaml

resources:
  requests:
    cpu: 250m
    memory: 256Mi
  limits:
    cpu: 500m
    memory: 512Mi

Scaling Behavior and Stabilization

The autoscaling/v2 API allows fine-tuning how aggressively the HPA scales up or down using the behavior field, which can add stabilization windows to prevent rapid flapping caused by transient traffic spikes.

🏏

Cricket analogy: A cautious captain doesn't rotate the entire bowling attack after just one expensive over, waiting to confirm it's a real trend rather than a fluke; the autoscaling/v2 'behavior' field similarly adds stabilization windows so HPA doesn't overreact to a brief traffic spike.

yaml

spec:
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Pods
          value: 2
          periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
        - type: Percent
          value: 100
          periodSeconds: 15

HPA evaluates metrics roughly every 15 seconds by default (--horizontal-pod-autoscaler-sync-period) and recalculates the desired replica count using the formula: desiredReplicas = ceil(currentReplicas * currentMetricValue / desiredMetricValue).

HPA scales the number of Pod replicas (horizontal scaling), not the CPU/memory allocated to each Pod. Adjusting per-Pod resource size is the job of the VerticalPodAutoscaler — combining both without care can cause conflicting scaling decisions.

HPA requires the Metrics Server (or a custom/external metrics adapter) to read utilization data.
Utilization percentages are computed relative to each container's resource requests.
autoscaling/v2 supports multiple metrics simultaneously (CPU, memory, custom, external).
minReplicas/maxReplicas bound the scaling range; behavior tunes scale-up/down speed.
HPA changes replica COUNT; it does not resize individual Pods (that's VPA's job).
scaleTargetRef must point to a scalable workload: Deployment, ReplicaSet, or StatefulSet.

Practice what you learned

1. What does the HorizontalPodAutoscaler primarily adjust?

2. What component must be running in the cluster for CPU/memory-based HPA to function?

3. Utilization percentages used by a CPU-based HPA are calculated relative to what?

4. What is the purpose of scaleDown.stabilizationWindowSeconds in the HPA behavior field?

5. Which of these can an autoscaling/v2 HPA target for scaling decisions?

Was this page helpful?

Namespaces and Resource Quotas

Ingress Controllers

Related Study Notes in DevOps

Browse all study notes

DevOps

Nginx Study Notes

DevOps · 30 topics

DevOps

Ansible Study Notes

DevOps · 30 topics

DevOps

Advanced Kubernetes Study Notes

Kubernetes · 30 topics

DevOps

Advanced Bash Scripting Study Notes

Bash · 30 topics

DevOps

Apache Kafka Study Notes

Kafka · 30 topics

DevOps

CI/CD Tools & Pipelines Study Notes

YAML · 37 topics

Topics covered

#YAML#DockerKubernetesStudyNotes#DevOps#HorizontalPodAutoscaling#Horizontal#Pod#Autoscaling#Scaling#Kubernetes#StudyNotes#SkillVeris

Scaling Workloads Automatically

Defining a CPU-Based HPA

Requirement: Resource Requests on Pods

Scaling Behavior and Stabilization

Practice what you learned

You May Also Like

Related Reading

Related Study Notes in DevOps

Topics covered