Hoe gebruik ik de Kubernetes Horizontal Pod Autoscaler?

Met een Horizontal Pod Autoscaler (HPA) laat je Kubernetes automatisch het aantal pods van een workload aanpassen aan de actuele belasting. Zo voeg je bij een hoge belasting capaciteit toe en verminder je het aantal pods wanneer de belasting afneemt. 

In deze handleiding configureer je autoscaling op basis van CPU-gebruik. Je controleert de Metrics API, maakt een voorbeeld-Deployment en test hoe de HPA onder load omhoog en omlaag schaalt.

De Horizontal Pod Autoscaler past het aantal pods automatisch aan. Om ook het aantal nodes automatisch aan te passen raden we aan de Cluster Autoscaler te gebruiken.

De werking van een Horizontal Pod Autoscaler

De HPA-controller is onderdeel van het Kubernetes-control plane. Deze controller leest periodiek metrics en vergelijkt de actuele waarde met de ingestelde doelwaarde. Bij CPU-autoscaling berekent Kubernetes de gemiddelde CPU-belasting als percentage van de CPU-requests van de betrokken pods.

Stel dat een Deployment één pod heeft met een CPU-request van 200m en de HPA een waarde van 50 procent als doel gebruikt. De doelbelasting is dan gemiddeld 100m CPU per pod. Komt de gemiddelde belasting boven deze waarde, dan verhoogt de HPA het aantal replicas tot maximaal de ingestelde bovengrens.

Het opschalen gebeurt doorgaans relatief snel. Voor het omlaag schalen van pods gebruikt Kubernetes standaard een stabilisatieperiode van vijf minuten. Hiermee voorkomt de HPA dat het aantal pods voortdurend wisselt door korte schommelingen.

Benodigdheden

Voor deze handleiding heb je het volgende nodig:

• Een cluster: een Kubernetes-cluster.
• kubectl: kubectl, geconfigureerd voor het juiste cluster.
• Kubernetes-versie: versie 1.23 of nieuwer.

De commando's in deze handleiding werken hetzelfde in Linux, macOS en Windows PowerShell.

Metrics Server controleren en installeren

Een HPA heeft een metrics-bron nodig (voor het verzamelen van data, in dit geval voor CPU-gebruik). Voor CPU- en geheugenmetrics gebruikt Kubernetes doorgaans Metrics Server. Deze component verzamelt resource metrics bij de kubelets en stelt ze beschikbaar via de Metrics API.

Stap 1

Controleer de actieve context en de Kubernetes-versie:

kubectl config current-context
kubectl version

Ga alleen verder wanneer de getoonde context bij het bedoelde cluster hoort en de serverversie 1.23 of nieuwer is.

Stap 2

Controleer of de Metrics API al beschikbaar is:

kubectl top nodes

Zie je CPU- en geheugengebruik per node? Ga dan verder met de paragraaf ‘Een voorbeeldapplicatie deployen’.

Krijg je de melding ‘Metrics API not available’? Installeer dan de actuele officiële Metrics Server-configuratie:

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

De optie -f laat kubectl de configuratie op het opgegeven adres toepassen. Controleer voor productieomgevingen altijd eerst de actuele Metrics Server-release en de inhoud van het manifest.

Stap 3

Wacht tot Metrics Server beschikbaar is en controleer daarna de Metrics API:

kubectl rollout status deployment/metrics-server --namespace kube-system --timeout=180s
kubectl get apiservice v1beta1.metrics.k8s.io
kubectl top nodes

De optie --namespace selecteert de kube-system-namespace. Met --timeout=180s stopt kubectl na 180 seconden met wachten. Het kan na de rollout nog ongeveer één minuut duren voordat de eerste metrics beschikbaar zijn. In de APIService-uitvoer hoort onder AVAILABLE de waarde True te staan.

Een voorbeeldapplicatie deployen

Voor de test gebruik je de officiële php-apache-voorbeeldapplicatie van Kubernetes. Deze applicatie verbruikt CPU wanneer ze requests verwerkt en heeft een CPU-request van 200m.

Stap 1

Maak een afzonderlijke namespace voor de test:

kubectl create namespace hpa-tutorial

Stap 2

Maak de Deployment en bijbehorende Service met het officiële voorbeeld .yaml-manifest:

kubectl apply --namespace hpa-tutorial -f https://k8s.io/examples/application/php-apache.yaml

De optie --namespace maakt de resources in hpa-tutorial. De optie -f verwijst naar het manifest dat kubectl toepast.

Stap 3

Wacht tot de Deployment beschikbaar is:

kubectl rollout status deployment/php-apache --namespace hpa-tutorial --timeout=180s
kubectl get pods --namespace hpa-tutorial

De eerste opdracht wacht maximaal 180 seconden op een geslaagde rollout. De tweede opdracht hoort één actieve php-apache-pod te tonen.

Een Horizontal Pod Autoscaler maken

Stap 1

Maak een HPA die gemiddeld 50 procent van de aangevraagde CPU nastreeft:

kubectl autoscale deployment php-apache --namespace hpa-tutorial --cpu=50% --min=1 --max=10

De opties in deze opdracht hebben de volgende functie:

• --namespace hpa-tutorial: maakt de HPA in dezelfde namespace als de Deployment.
• --cpu=50%: stelt de gemiddelde doelbelasting in op 50 procent van de CPU-request.
• --min=1: houdt minimaal één replica actief.
• --max=10: staat maximaal tien replicas toe.

Stap 2

Controleer de HPA en de ontvangen metrics:

kubectl get hpa --namespace hpa-tutorial
kubectl describe hpa php-apache --namespace hpa-tutorial

Direct na het maken kan onder TARGETS tijdelijk <unknown>/50% staan. Wacht tot Metrics Server een meetwaarde heeft verzameld en voer de opdracht opnieuw uit. In de uitgebreide uitvoer geeft ScalingActive aan of de HPA een geldige metric gebruikt.

De Horizontal Pod Autoscaler onder load testen

Stap 1

Start een tijdelijke pod die continu requests naar de voorbeeldapplicatie stuurt:

kubectl run load-generator --namespace hpa-tutorial --image=busybox:1.37.0 --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

De optie --image selecteert de gebruikte container image. Met --restart=Never maakt kubectl een afzonderlijke pod in plaats van een Deployment. Alles na -- is de opdracht die in de container wordt uitgevoerd.

Stap 2

Volg in je terminal hoe de HPA reageert:

kubectl get hpa php-apache --namespace hpa-tutorial --watch

De optie --watch blijft wijzigingen tonen. Zodra het CPU-gebruik boven 50 procent komt, verhoogt de HPA het gewenste aantal replicas. Stop het volgen met ctrl + c.

Controleer ook de aangemaakte pods:

kubectl get deployment,pods --namespace hpa-tutorial

Stap 3

Stop de load test:

kubectl delete pod load-generator --namespace hpa-tutorial

Volg de HPA opnieuw:

kubectl get hpa php-apache --namespace hpa-tutorial --watch

Na het verdwijnen van de load verlaagt de HPA het aantal replicas weer tot het ingestelde minimum. Door de standaard stabilisatieperiode voor omlaag schalen duurt dit doorgaans ongeveer vijf minuten.

Een HPA voor je eigen workload configureren

Gebruik voor een blijvende configuratie een .yaml-manifest met API-versie autoscaling/v2. Hiermee leg je de HPA-configuratie samen met de overige configuratie van je applicatie vast.

Stap 1

Open op Linux of macOS een nieuw bestand:

nano hpa.yaml

Gebruik in Windows PowerShell Notepad:

notepad.exe hpa.yaml

Voeg de volgende configuratie toe:

apiVersion: autoscaling/v2
kind: HorizontalpodAutoscaler
metadata:
  name: <hpa-naam>
  namespace: <namespace>
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: <deployment-naam>
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300

Vervang <hpa-naam>, <namespace> en <deployment-naam> door de namen van jouw HPA, namespace en Deployment. minReplicas en maxReplicas bepalen de onder- en bovengrens. averageUtilization is het gemiddelde gewenste CPU-percentage ten opzichte van de CPU-request. stabilizationWindowSeconds voorkomt dat de HPA na een korte daling direct pods verwijdert.

Stap 2

Controleer of iedere container waarop je CPU-autoscaling baseert een CPU-request heeft. Een containerconfiguratie bevat bijvoorbeeld:

resources:
  requests:
    cpu: 200m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 256Mi

De HPA gebruikt de CPU-request als basis voor het percentage. Een waarde van 200m staat voor 0,2 CPU-core.

Stap 3

Pas de HPA-configuratie toe en controleer de status:

kubectl apply -f hpa.yaml
kubectl get hpa --namespace <namespace>
kubectl describe hpa <hpa-naam> --namespace <namespace>

Vervang <namespace> en <hpa-naam> door de waarden uit je manifest. Gebruik de conditions en events in de uitgebreide uitvoer om te controleren of de HPA metrics ontvangt en de workload mag schalen.

Problemen met een Horizontal Pod Autoscaler oplossen

• TARGETS toont <unknown>: controleer met kubectl top pods of de Metrics API waarden levert. Controleer daarna of alle relevante containers een request hebben voor de metric waarop je schaalt.
• ScalingActive is False: bekijk de events met kubectl describe hpa. Veelvoorkomende oorzaken zijn ontbrekende metrics, een verkeerde scaleTargetRef of onvoldoende rechten.
• De HPA schaalt niet omhoog: controleer of de gemiddelde belasting daadwerkelijk boven de doelwaarde komt. De controller negeert kleine schommelingen rond de doelwaarde.
• Nieuwe pods blijven Pending: controleer met kubectl describe pod of de nodes voldoende CPU en geheugen beschikbaar hebben. Een HPA maakt geen nieuwe nodes.
• De HPA schaalt niet direct omlaag: dit is meestal de stabilisatieperiode voor scale-down. De standaardwaarde is 300 seconden.

Gebruik voor de belangrijkste controles:

kubectl top pods --namespace <namespace>
kubectl describe hpa <hpa-naam> --namespace <namespace>
kubectl get events --namespace <namespace> --sort-by=.metadata.creationTimestamp

Vervang <namespace> en <hpa-naam> door de namespace en naam van jouw HPA. De optie --sort-by sorteert de events op aanmaaktijd.

De testresources verwijderen

Verwijder de namespace wanneer je klaar bent met de test. Hiermee verwijder je ook de voorbeeld-Deployment, Service, HPA en tijdelijke pods:

kubectl delete namespace hpa-tutorial

Metrics Server is een clusterbrede component die ook door andere workloads gebruikt kan worden. Verwijder deze component daarom niet als onderdeel van de testcleanup.

Je hebt een Kubernetes Horizontal Pod Autoscaler op basis van CPU-gebruik gemaakt en onder load getest. Gebruik voor productie realistische resource requests, passende minimum- en maximumwaarden en voldoende nodecapaciteit, en blijf het schaalgedrag en de applicatieprestaties monitoren.