Horizontal Pod Autoscaler

The Horizontal Pod Autoscaler (HPA) changes the number of replicas of a scalable workload, such as a Deployment or StatefulSet, in response to observed metrics. It scales out when load rises and back in when it falls. It does not apply to objects that cannot be scaled, such as a DaemonSet.

How it works

The HPA controller periodically compares the current metric value with the target and calculates the desired replica count as the ceiling of the current replicas multiplied by the ratio of current to desired metric value. With a CPU target of 70 per cent and three replicas averaging 90 per cent, the result is ceil(3 x 90 / 70), which is four replicas.

Resource metrics such as CPU and memory come from the metrics.k8s.io API, usually provided by Metrics Server, which must be installed separately. Custom and external metrics are served through separate aggregated APIs, normally backed by an adapter such as the Prometheus Adapter. Utilisation targets are calculated as a percentage of each container’s resource request, so if a container has no request, CPU utilisation is undefined and the autoscaler takes no action for that metric.

A practical example

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 10
  metrics: [{type: Resource, resource: {name: cpu, target: {type: Utilization, averageUtilization: 70}}}]

Common mistakes

• Omitting CPU requests on the target Pods, so the HPA cannot compute utilisation. See resource requests and limits.
• Keeping a fixed replicas value in the Deployment manifest while a GitOps tool reapplies it, which can fight the autoscaler.
• Setting requests far above real usage, so utilisation never reaches the target and the workload never scales.
• Using the HPA when the real bottleneck is nodes. Pods that cannot be scheduled need node capacity, which a tool like Karpenter provides.

When to use it and when not to

Use the HPA for stateless services whose load varies and which handle extra replicas well. It suits web APIs and queue workers. It is a poor fit for workloads that cannot run multiple replicas or that take a long time to start. For a single instance that needs more resources rather than more copies, consider the Vertical Pod Autoscaler. Our Kubernetes consulting service covers autoscaling design.

See also

• Vertical Pod Autoscaler
• Karpenter
• Resource Requests and Limits
• Kubernetes