Autoscaling op een beheerd Kubernetes-cluster: een geteste walkthrough

September 2026 • Product

"Autoscaling" verwijst in Kubernetes naar drie verschillende mechanismen, en ze door elkaar halen is de meest voorkomende reden dat een cluster dat zou moeten schalen dat niet doet. Pods schalen met een HorizontalPodAutoscaler, nodes schalen met de grenzen van worker pools en het control plane schaalt met de belasting van de API. Dit artikel legt elk mechanisme uit en doorloopt daarna een echte test die we op een Kube-DC beheerd cluster uitvoerden, met de manifesten zodat u hem kunt herhalen.

Drie dingen kunnen schalen

We geven per laag aan wat we hebben getest en wat we alleen uit de documentatie weten, omdat het verschil ertoe doet wanneer u capaciteit plant.

Wat de HorizontalPodAutoscaler werkelijk doet

De HorizontalPodAutoscaler (HPA) is een regelkring die binnen het Kubernetes control plane draait. Standaard wordt hij elke 15 seconden wakker, leest de metrics van de pods waarop hij is gericht en past het aantal replica's van de Deployment aan. Vier details verklaren bijna elke verrassing:

• Gebruik is relatief aan de request. Een doel van 50% CPU betekent 50% van de CPU die de containers van de pod aanvragen, niet 50% van de node. Als een container geen CPU-request heeft, is het gebruik niet gedefinieerd en doet de autoscaler niets voor die metric.
• Hij heeft de Metrics-API nodig. De metrics.k8s.io-API wordt normaal geleverd door de Metrics Server-add-on, die op een zelfbeheerd cluster apart moet worden geïnstalleerd.
• De rekensom is een verhouding. Het gewenste aantal replica's is het huidige aantal replica's vermenigvuldigd met de verhouding tussen de huidige metric en het doel, naar boven afgerond. Als de verhouding binnen een tolerantie van 0,1 van 1,0 ligt, gebeurt er niets.
• Terugschalen is bewust traag. De controller onthoudt recente aanbevelingen en handelt naar de hoogste in een venster dat standaard vijf minuten duurt, wat fluctuerende metrics afvlakt en flapperen voorkomt.

Een replica die op 57% CPU draait bij een doel van 50% geeft bijvoorbeeld een verhouding van 1,14, en naar boven afronden van 1 × 1,14 geeft 2 replica's. Dat is precies de eerste stap die we in de onderstaande test zagen.

De test: een beheerd cluster schalen onder echte belasting

In onze end-to-endtest van augustus 2026 maakten we een beheerd cluster met de naam test2 met twee worker nodes, elk gedimensioneerd op 1 vCPU en 2 GB geheugen om in de resterende ruimte van het pakketquotum te passen. Het API-eindpunt van het cluster is standaard privé, dus we bereikten het vanuit de ingebouwde Cloud Shell van het project via het interne serviceadres van het cluster in plaats van via internet. Beide workers waren Ready en metrics-server was al geïnstalleerd en werkte, wat de HPA nodig heeft.

We deployden een kleine webapplicatie met een HPA met een doel van 50% CPU en een bereik van 1 tot 6 replica's. Dit zijn voorbeeldmanifesten in dezelfde vorm als de test; de CPU-requestwaarden zijn illustratief:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
      - name: hello
        image: nginxdemos/hello
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 100m
            memory: 64Mi
---
apiVersion: v1
kind: Service
metadata:
  name: hello
spec:
  selector:
    app: hello
  ports:
  - port: 80
    targetPort: 80
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: hello
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: hello
  minReplicas: 1
  maxReplicas: 6
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

Om aanhoudende belasting te genereren startten we meerdere wegwerppods in het cluster, die elk in een lus HTTP-verzoeken naar de service stuurden. Voer het eerste commando uit in twee of drie shells met verschillende namen en volg de autoscaler in een andere:

kubectl run load-1 --image=busybox:1.36 --restart=Never -- /bin/sh -c "while true; do wget -q -O- http://hello > /dev/null; done"

kubectl get hpa hello --watch

Twee eerlijke opmerkingen over dat resultaat. We hebben het terugschalen niet getimed, en het standaard stabilisatievenster van vijf minuten is de reden dat het achterloopt op het opschalen. En de test bewijst alleen de pod-laag: hij laat zien dat de HPA, de Metrics-API en de scheduling van het cluster samenwerken op een Kube-DC beheerd cluster, niet hoe de worker pools zich gedragen bij schalen op nodeniveau.

Als u klaar bent, verwijdert u de belasting met kubectl delete pod load-1 (en eventuele andere generatoren die u hebt gestart) en daarna de testworkload met kubectl delete hpa,svc,deploy hello.

Wat pods niet alleen kunnen: capaciteit

De HPA voegt pods toe, en pods hebben een plek nodig om te draaien. Als de workers vol zijn, blijven de extra replica's in Pending totdat er capaciteit beschikbaar komt, dus de maxReplicas van de HPA heeft alleen betekenis als de onderliggende pool zoveel pods kan bevatten. Vermenigvuldig het maximale aantal replica's met de requests van elke pod en vergelijk het resultaat met de vrije capaciteit van uw worker pool.

Op Kube-DC worden worker pools per pool gedefinieerd (CPU, geheugen, schijf en image) met autoscalinggrenzen per pool, en de pool put uit het quotum van uw pakket. Dat quotum wordt gedeeld over alles wat u draait: containers, virtuele machines en beheerde clusters delen dezelfde vCPU- en geheugenruimte. We zagen het gevolg in onze test, waar een bestaand beheerd cluster en een virtuele machine ongeveer 7,5 van de 8 vCPU's in een Pro-pakket gebruikten en geen ruimte overlieten voor een GPU-pod. Daarom dimensioneerden we de testworkers op 1 vCPU en 2 GB. Beschouw uw pakket als het plafond voor elke schaallaag en controleer de resterende ruimte voordat u een maximum verhoogt.

Het control plane schaalt ook mee

Een cluster met veel pods en frequente schaalacties belast de API-server en etcd. De documentatie van Kube-DC stelt dat de resources van control plane en etcd automatisch worden bijgesteld binnen geconfigureerde grenzen naarmate de clusterbelasting groeit, met verticale autoscaling standaard ingeschakeld. Op een zelfbeheerd cluster is het correct dimensioneren van die componenten uw taak, en etcd is gevoelig voor een tekort aan resources, zoals we uitleggen in ons artikel over beheerd versus zelf gehost Kubernetes.

Veelgemaakte fouten

• Geen resource requests. Zonder CPU-request kan een gebruiksdoel niet worden berekend en doet de HPA niets voor die metric.
• Het opstartgedrag negeren. Een pod die tijdens het initialiseren veel CPU gebruikt, kan extra opschalingen veroorzaken. De Kubernetes-documentatie beveelt een startup probe aan, of een readiness probe die pas slaagt nadat de piek voorbij is, en de controller negeert CPU-samples van een pod tijdens zijn initialisatieperiode.
• Schalen op CPU terwijl CPU niet de bottleneck is. De autoscaling/v2-API ondersteunt ook geheugen en aangepaste metrics, die beter passen bij workloads die door wachtrijen of I/O worden bepaald.
• Het maximum instellen zonder capaciteit te controleren. Zoals hierboven blijven replica's boven wat de pool kan bevatten gewoon in Pending wachten.
• Eén replica in productie draaien. Een minimum van één betekent één pod zolang de belasting laag is. Gebruik een hoger minimum voor alles wat het verlies van een node moet overleven.

Bronnen

• Kubernetes: Horizontal Pod Autoscaling
• Kube-DC platform datasheet: managed Kubernetes clusters
• Kube-DC: provisioning a Managed Cluster

Gerelateerd

• Beheerd vs. zelf gehost Kubernetes: de technische realiteit
• Hoe u een beheerde Kubernetes-aanbieder in Europa beoordeelt
• Gedeelde GPU op Kubernetes: wat u werkelijk krijgt

Voer deze test uit op uw eigen cluster

Elk Kube-DC-pakket bevat geneste Kubernetes-clusters, aangemaakt vanuit uw project in een self-serviceportaal, met metrics-server klaar voor gebruik en uw quotum zichtbaar zodat u capaciteit kunt plannen. Daarachter zitten dedicated vCPU, op Ceph gebaseerde NVMe-opslag, een dedicated publiek IPv4-adres en S3-compatibele objectopslag, met 24/7 support via e-mail en tickets en een oplostijddoel van 4 uur. Herhaal de bovenstaande walkthrough en zie zelf hoe de replica's bewegen.