Skip to main content

Horizontal Pod Autoscaling

Horizontal Pod Autoscaling (HPA) automatically adjusts the number of pods for an application to match the workload. If the load increases, additional pods are launched; if it decreases, pods are terminated.

Distinction from Cluster Autoscaling​

Both mechanisms operate at different levels and complement one another:

MechanismScalesConfiguration
Horizontal Pod Autoscaling (HPA)Number of podsVia a HorizontalPodAutoscaler object in the cluster
Cluster Autoscaling (CA)Number of nodesPer node pool in Control Panel

HPA launches additional pods – if the capacity of the existing nodes is insufficient for this, they remain in status Pending. Only then does the Cluster Autoscaler provision additional nodes. For load-based scaling, therefore, both should be active.

See Enable autoscaling.

Prerequisites​

  • A running metrics-server in the cluster
  • Defined resources.requestss in your deployment – without these, HPA cannot calculate the percentage utilisation

Take a look at the metrics-server:

kubectl top pods

If you receive an error message, install it first; see Advanced Metrics.

Preparing for deployment​

The deployment must define requests:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:stable
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 256Mi

Create a HorizontalPodAutoscaler​

By manifesto​

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

How to use:

kubectl apply -f hpa.yaml

This configuration means that if the average CPU utilisation of the pods exceeds 70 per cent of the requested requests, additional pods will be launched – up to a maximum of 10. If it falls significantly below this level, the number of pods will be reduced to a minimum of 2.

By command​

kubectl autoscale deployment web --cpu-percent=70 --min=2 --max=10

Check status​

kubectl get hpa

Sample output:

NAME      REFERENCE        TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
web-hpa   Deployment/web   45%/70%   2         10        3          5m

Details and scaling events:

kubectl describe hpa web-hpa

If column TARGETS shows the value <unknown>, metrics-server returns no data – or the requests values are missing from the deployment.

Scaling according to RAM​

  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80

Where there are multiple metrics, HPA scales based on the one that requires the highest number of replicas.

Mitigating fluctuations​

If the application scales up and down too frequently, limit this behaviour using behavior:

spec:
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 50
          periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
        - type: Percent
          value: 100
          periodSeconds: 30

Scaling up therefore takes place immediately, whilst scaling down only occurs after five minutes of stable load.

Notes​

  • An HPA and a fixed replicas setting in the deployment are mutually exclusive. As soon as an HPA is active, it manages the number of replicas.
  • Set minReplicas to at least 2 for production services to ensure the application remains accessible even in the event of node failures.
  • Define readiness probes so that newly restarted pods only receive traffic once they have fully started up.
Last updated on