Wanneer moet ik Automatische schaalaanpassing van horizontale pods (HPA) gebruiken in Kubernetes?

Kort antwoord: Gebruik HPA wanneer uw workload meerdere identieke replica's kan uitvoeren en de vraag fluctueert: schaal op CPU/geheugen, metrische gegevens van toepassingen (RPS/latentie) of metrische gegevens voor externe wachtrij/achterstand. Gebruik HPA niet voor stateful services met één replica of wanneer het echte knelpunt knooppuntcapaciteit of downstreamlimieten is (DB-verbindingen, frequentielimieten van derden).

TL; DR:

  • Gebruik HPA voor horizontaal partitioneerbare workloads waarbij metrische gegevens per pod of externe metrische gegevens de belasting weerspiegelen.
  • Gebruik resource-/aangepaste/externe metriek(en) (CPU, RPS, wachtrijlengte); combineer dit met Cluster Autoscaler voor nodecapaciteit.
  • Gebruik KEDA voor gebeurtenisgestuurd terugschalen naar nul of externe scalers; gebruik VPA in de aanbevelingsmodus voor het dimensioneren van resourceaanvragen.

Controlelijst voor snelle beslissingen (Ja/Nee):

  • Is de werkbelasting staatloos of kan deze over veel replica's worden verdeeld? (Ja → HPA-kandidaat)
  • Kunt u de belasting waarnemen als metriek per-pod of als externe metriek (CPU, aanvragen per seconde, queuediepte)? (Ja → HPA geschikt)
  • Kan het cluster meer pods inplannen (Cluster Autoscaler of reservecapaciteit)? (Ja → doorgaan. Als nee, schakelt u automatisch schalen van knooppunten in)
  • Beperken downstreamservices (DB-pools, API's van derden) gelijktijdigheid? (Ja → snelheidsbeperking/verbindingspooling toevoegen of bij voorkeur verticaal schalen)

Beslissingsmatrix (workload → beste metriek → aanbevolen schaalfunctie):

Werkbelastingtype Beste metrische waarde voor doel Aanbevolen schaalaanpassing
Web/API (staatloos) CPU of RPS per pod HPA (+VPA-aanbeveling + Cluster Autoscaler)
Achtergrondwachtrijwerker Wachtrijlengte of berichten per seconde HPA via externe metrische gegevens of KEDA (KEDA ondersteunt scale-to-zero)
Database met één exemplaar of app met status N/B (niet horizontaal partitioneerbaar) VPA of handmatig schalen
Batch- en tijdelijke gebeurteniswerkers Gebeurtenisachterstand KEDA of HPA met externe metrische gegevens

Hoe HPA werkt (eenvoudige besturingslus en belangrijke velden)

  • Onderdelen: de HPA-controller (beheerlaag) + metriekproviders (metrics-server voor resourcemetrieken, API voor aangepaste/externe metriek via adapters of KEDA).
  • Regellus (op hoog niveau): de HPA-controller vraagt de metrics-API uit → berekent desiredReplicas voor elke geconfigureerde metriek → neemt de hoogst berekende desiredReplicas → past minimum/maximum en gedrag (beleid/stabilisatie) toe → werkt spec.replicas op de doelresource bij → herhaalt dit. Zie de Kubernetes HPA-documenten voor meer informatie.
  • Formule (hoe gewenste replica's worden berekend): desiredReplicas = ceil(current_total/target_per_pod). De controller berekent een desiredReplicas voor elke geconfigureerde metriek en gebruikt vervolgens de grootste waarde voordat min/max en gedrag worden toegepast (dit gedrag met metrische prioriteit wordt beschreven in de HPA-documenten).
  • Belangrijke velden voor automatisch schalen/v2: minReplicas, maxReplicas, metrische gegevens (Resource, Pods, Object, Extern), gedrag (scaleUp/scaleDown-beleid en stabilisatieWindowSeconds).
  • Gebruik gedrag om snelheid van wijziging te beperken en flapping te voorkomen; stabilisatieWindowSeconds is een sleutelknop voor scaleDown smoothing.

Voorbeeld van gedragsfragment (automatisch schalen/v2)

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

Wanneer gebruikt u HPA (op basis van het metrische type/veelvoorkomende gebruiksvoorbeelden)

  1. CPU / geheugen (resourcestatistieken)
    • Gebruik HPA wanneer cpu-gebruik per pod of geheugengebruik correleert met capaciteitsbehoeften en pods de juiste resourceaanvragen definiëren. Typisch voor web-API's en statusloze microservices.
    • Praktisch uitgangspunt: streef naar een gemiddeld CPU-gebruik tussen 60 en 80% en stem dit af op basis van belastingstests. HPA berekent het gebruik van podaanvragen, zodat aanvragen moeten worden ingesteld.
  2. Aangepaste metrische gegevens in cluster (Prometheus/aangepaste metrische gegevens)
    • Gebruik HPA wanneer signalen op app-niveau (aanvragen per seconde, latentie, wachtrijgebruikers/pod) beter de belasting vertegenwoordigen dan CPU.
    • Stel metrische gegevens beschikbaar met Prometheus + prometheus-adapter (custom.metrics.k8s.io) of een andere aangepaste provider voor metrische gegevens en richt deze metrische gegevens in HPA op.
  3. Externe metrische gegevens (wachtrijen, cloudachterstanden)
    • Gebruik HPA (via de API voor externe metrieken) of KEDA wanneer schaling moet reageren op externe signalen, zoals wachtrijlengte (RabbitMQ, Azure Service Bus), Event Hubs of cloudbewakingsmetrieken.
    • Als u schaal-naar-nul of strak gebeurtenisgestuurd gedrag nodig hebt, geeft u de voorkeur aan KEDA. Het integreert systeemeigen externe schaalders en biedt ondersteuning voor keda-documenten (scale-to-zero).

Wanneer NIET HPA te gebruiken

  • Stateful services met één replica (databases, een unieke toestand in de pod): HPA is niet geschikt, tenzij u veilig kunt sharden of partitioneren.
  • Wanneer het knelpunt zich op knooppuntniveau bevindt (GPU, schijf-I/O, knooppunt-CPU) in plaats van per pod: geef de voorkeur aan automatische schaalaanpassing van knooppuntgroepen of verticale schaalaanpassing.
  • Wanneer downstreamsystemen (DB-verbindingsgroepen, caches, API's van derden) strikte gelijktijdigheidslimieten hebben: pods schalen zonder de downstreamcapaciteit te vergroten, kunnen storingen verslechteren. Zie 'Downstream& operationele overwegingen' hieronder.
  • Als u scale-to-zero nodig hebt, kan gewone HPA dat niet bereiken; gebruik KEDA of een externe controller.

Meerdere metrische gegevens, prioriteit en een voorbeeld

  • Als u meerdere metrische gegevens configureert, berekent de HPA-controller een desiredReplicas-waarde voor elke metriek afzonderlijk en selecteert de grootste desiredReplicas als basis voor schalen. Daarna worden minReplicas/maxReplicas en gedragsbeleid toegepast (bron: Kubernetes HPA-documenten).
  • Voorbeeld: het CPU-doel berekent 5 replica's, het doel voor aanvragen per seconde berekent 12 replica's → HPA zal 12 kiezen (daarna kunnen min/max en gedragsbeleidsregels de uiteindelijk toegepaste wijziging aanpassen).
  • Als u plotselinge overschrijdingen wilt voorkomen, combineert u een op procent gebaseerd scaleUp-beleid en een redelijke scaleDown-stabilisatieWindowSeconds (zie het gedragsfragment hierboven).

HPA versus VPA vs Cluster Autoscaler vs KEDA (korte richtlijnen)

  • HPA: schaalt replica's horizontaal op basis van metrische gegevens. Het meest geschikt voor partitioneerbare workloads.
  • VPA: past aanvraag/limieten voor podresources aan (verticaal). Het meest geschikt voor niet-paralleliseerbare workloads of om zinvolle standaardwaarden in te stellen.
  • Automatische schaalaanpassing van clusters (of Karpenter): schaalt knooppunten om te voldoen aan planningsaanvragen (capaciteit op knooppuntniveau). Gebruik dit wanneer pods Pending blijven door een tekort aan nodes.
  • KEDA: gebeurtenisgestuurde automatische schaler die externe triggers integreert en scale-to-zero voor eventgestuurde workloads ondersteunt.

Veelvoorkomend patroon: gebruik VPA in aanbevelingsmodus om basisaanvragen in te stellen, HPA om replica's te schalen en Cluster Autoscaler (of Karpenter) om nodecapaciteit te leveren. Gebruik KEDA wanneer u schaal-naar-nul of directe integratie met externe gebeurtenisbronnen nodig hebt.

Opmerking: beheerde Kubernetes-aanbiedingen (AKS/GKE/EKS) kunnen metrische providers vooraf installeren of geïntegreerde functies voor automatische schaalaanpassing bieden. Documentatie over automatisch schalen van AKS-clusters

Vervolg- & operationele aandachtspunten (veelvoorkomende valkuilen)

  • Databaseverbindingsgroepen: het verhogen van replica's verhoogt gelijktijdige verbindingen. Beperken met groepsgewijze verbindingen (bijvoorbeeld PgBouncer), het beperken van gelijktijdigheid per pod of het vergroten van de grootte van de DB-pool voordat u pods schaalt.
  • API-snelheidslimieten en quota van externe partijen: zorg ervoor dat downstream-systemen het verzoekvolume kunnen verwerken dat door opgeschaalde pods wordt gegenereerd; overweeg throttling aan clientzijde.
  • PodDisruptionBudgets (PDBs): PDBs verhinderen niet dat HPA omhoog wordt geschaald, maar kan invloed hebben op onderhoudsbewerkingen en afvoergedrag; zorg ervoor dat het schaalbeleid is afgestemd op PDBs.
  • Opstart- en opwarmeffecten: initContainers, cache-warm-up of lange koude start kunnen scheeftrekken van metrische gegevens en veroorzaken oscillatie: gebruik gereedheids-/opstarttests en stabilisatievensters.
  • Aanbevolen operationele aanpak: stel conservatieve opschalingssnelheden in, stem requests/limits en probes af, test in niet-productieomgevingen en voeg SLO-bewuste throttling toe als downstream-systemen een knelpunt vormen.

Configuratiecontrolelijst en veilige implementatiestappen

Zorg voor metrische gegevens en RBAC:

  • Implementeer metrics-server voor resourcemetrieken (of gebruik een beheerde provider).
  • Implementeer Prometheus + prometheus-adapter voor aangepaste metrische gegevens (custom.metrics.k8s.io) indien nodig.
  • Overweeg KEDA voor externe en event-scalers.

HPA schrijven (automatisch schalen/v2) met:

  • minReplicas en maxReplicas,
  • expliciete metrische gegevens en gedrag (scaleUp/scaleDown-beleid),
  • gereedheids- en opstarttests op pods,
  • verstandige resourceaanvragen, zodat metrische resourcegegevens zinvol zijn.

Checklist voor veilig testen (hoe je HPA veilig test):

  1. Test in een niet-productie-namespace/cluster met vergelijkbare nodegroottes en autoscaling ingeschakeld.
  2. Begin met conservatieve min/max replica's en zachte scaleUp-beleidsregels (bijvoorbeeld max 100% groei/minuut).
  3. Voer geleidelijke belastingstests uit en bewaak desiredReplicas ten opzichte van currentReplicas en pods met de status Pending.
  4. Verfijn requests/limits, readiness-probes en gedragsregels voordat u de agressiviteit verhoogt.

Opmerkingen over AKS en automatisch schalen van nodes:

  • AKS en andere cloudaanbiedingen kunnen vooraf metrische gegevensservers installeren of beheerde integratie van automatische schaalaanpassing bieden. Voorbeeld van AKS CLI om automatische schaalaanpassing van clusters in te schakelen: az aks nodepool update --resource-group myRG --cluster-name myAKS --name node-pool1 --enable-cluster-autoscaler --min-count 1 --max-count 5

Karpenter opmerking: Karpenter is een alternatieve benadering voor automatisch schalen van knooppunten gericht op snelle inrichting; houd er rekening mee wanneer snelle inrichting van knooppunten is vereist.

Werkende YAML-voorbeelden

HPA op basis van CPU (automatisch schalen/v2):

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: webapi-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: webapi
  minReplicas: 3
  maxReplicas: 12
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Pods
          value: 1
          periodSeconds: 60

HPA met een door Prometheus beschikbaar gestelde aangepaste metriek (via prometheus-adapter):

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-requests-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: "100"

Zie de documentatie van prometheus-adapter voor query's voor toewijzing

KEDA ScaledObject (Azure Service Bus): ondersteunt schaal-naar-nul:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: sb-queue-scaledobject
  namespace: workers
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: event-worker
  minReplicaCount: 0
  maxReplicaCount: 20
  pollingInterval: 30
  cooldownPeriod: 300
  triggers:
    - type: azure-servicebus
      metadata:
        queueName: orders-queue
        queueLength: "50"
      authenticationRef:
        name: keda-azure-credentials

KEDA-documenten

Waarneembaarheid, waarschuwingen en SRE-voorbeelden

Voorgestelde waarschuwingen (kopieerbare Prometheus-voorbeelden: metrische namen aanpassen aan uw exportinstellingen):

  1. Waarschuwing wanneer HPA de gewenste > stroom heeft voor > 5 min. (probleem met de planningscapaciteit)

    alert: HPAUnschedulable
expr: (kube_hpa_status_desired_replicas - kube_hpa_status_current_replicas) > 0
for: 5m
labels:
  severity: page
annotations:
  summary: "HPA desired replicas exceed current replicas for >5m (possible scheduling issue)"

  2. Waarschuwing bij wachtende pods in een namespace

    alert: PodsPendingHigh
expr: sum(kube_pod_status_phase{phase="Pending", namespace="production"}) > 3
for: 2m
labels:
  severity: ticket
annotations:
  summary: "High number of Pending pods in production"

  3. Waarschuwing voor vaak opschalen (flapping)

    alert: HPAFlapping
expr: increase(kube_hpa_status_replicas_last_transition_count[10m]) > 5
for: 0m
labels:
  severity: warning
annotations:
  summary: "Frequent HPA scaling events detected"

Dashboards voor instrumenten met:

  • HPA: currentReplicas, desiredReplicas, lastScaleTime, door HPA gebruikte metrische waarden
  • Podstatus: In behandeling zijnde pods, FailedScheduling-gebeurtenissen, aantal opnieuw opstarten van pods
  • Downstream: DB-verbindingsgebruik, foutpercentages, externe API-fout/429-tarieven

Operationele en foutopsporingsopdrachten (snelzoekgids)

  • HPA's weergeven: kubectl get hpa -n
  • Beschrijf HPA (zoek naar huidige/huidige metriken, desiredReplicas, lastScaleTime, gebeurtenissen): kubectl describe hpa -n
  • Velden die moeten worden geïnspecteerd in de beschrijving van uitvoer: currentReplicas, desiredReplicas, metrics (huidige/doelwaarden), lastScaleTime, gebeurtenissen (fouten van de provider van metrische gegevens of schaalfouten)
  • Resourcegebruik weergeven (vereist metrische gegevensserver): kubectl top pods -n
  • Controleer pods met status In behandeling en planningsfouten: kubectl get pods -n | grep Pending, kubectl describe pod -n (zoek naar FailedScheduling)
  • Logboeken van metrische gegevensprovider controleren: kubectl logs -n kube-system deploy/metrics-server, kubectl logs -n deploy/prometheus-adapter
  • HPA-manifest toepassen: kubectl apply -f hpa.yaml

Tips voor snelle probleemoplossing:

  • HPA rapporteert desiredReplicas > currentReplicas en pods blijven in behandeling → waarschijnlijk onvoldoende knooppuntcapaciteit; schakel Automatische schaalaanpassing van clusters in of verhoog de knooppuntgroep.
  • HPA toont metrische fouten in gebeurtenissen → de logboeken van de provider van adapter RBAC/config en metrische gegevens controleren.
  • HPA-scaling te snel/traag → stem gedragsregels (procent-/podlimieten) en stabilisatievensters af.

Aanbevolen standaardwaarden voor afstemming en heuristieken

  • CPU-doel: begin rond 60% gemiddelde benutting (gebruikelijk bereik 60–80%) en stem dit per workload af.
  • minReplicas: ten minste 1 voor beschikbaarheid; gebruik KEDA als u minReplicas nodig hebt: 0.
  • maxReplicas: gebaseerd op capaciteitsplanning en kosten instellen; zorg ervoor dat de limieten van Cluster Autoscaler het toevoegen van knooppunten tot de vereiste capaciteit mogelijk maken.
  • stabilizationWindowSeconds: scaleDown ≈ 300s (5 min) is een gangbaar beginpunt om te snelle afschaling te voorkomen; stem dit af op de workload.
  • schaalbeleid: verhoging van het maximumpercentage per periode (bijvoorbeeld maximaal 100% groei per minuut toestaan) om overweldigende downstreamsystemen te voorkomen.
  • Gereedheids-/opstarttests: definieer ze altijd zodat pods geen verkeer ontvangen totdat ze volledig gereed zijn.

Opmerking: de standaardinstellingen voor specifieke timing van de controller en het exacte gedrag kunnen variëren in Kubernetes-versies en -distributies: controleer de HPA-documenten voor uw clusterversie

Veelvoorkomende valkuilen en controlelijst voordat u HPA inschakelt

  • Resourceaanvragen voor pods ontbreken of zijn niet correct → resourcegebaseerde HPA-doelen zullen misleidend zijn.
  • Er is geen provider voor metrische gegevens (metrics-server/prometheus-adapter/KEDA) → HPA geen metrische gegevens kan lezen.
  • Cluster heeft geen knooppuntcapaciteit en Cluster Autoscaler is niet ingeschakeld → pods blijven Pending.
  • HPA en VPA combineren: voorkom dat beide controllers actief resourceverzoeken wijzigen — laat VPA in aanbevelingsmodus draaien en laat HPA het aantal replica's schalen.
  • Opstartpieken (initContainers, koude caches) zonder probes → pas stabilisatievensters aan of warm instances handmatig vooraf op.
  • Onjuiste configuratie van RBAC: zorg ervoor dat metrische adapters en HPA-controller over de vereiste machtigingen beschikken om metrische gegevens te lezen.

Snelle veelgestelde vragen

V: Wat zijn de voordelen van HPA? A: Pas het aantal replica's automatisch aan om de belasting te wijzigen, het gebruik en de kosten te verbeteren en latentiedoelen te behouden wanneer deze worden gebruikt met de juiste metrische gegevens en automatische schaalaanpassing van knooppunten.

V: Hoe berekent HPA de gewenste replica's? A: Het leest geconfigureerde metrische gegevens, berekent desiredReplicas = ceil(current_total / target_per_pod) voor elke metriek, neemt de grootste berekende waarde en past vervolgens min/max- en gedragsbeleid toe (bron: HPA-documenten).

V: Kan HPA schalen naar nul? A: Nee — gewone HPA kan niet schalen naar nul. Gebruik KEDA voor scale-to-zero behavior (KEDA docs).

V: Hoe schaal je op basis van wachtrijlengte of RPS? A: Stel wachtrijlengte/RPS beschikbaar als een externe of aangepaste metrische gegevens (Prometheus-adapter of externe metrische API) of gebruik KEDA voor gebeurtenisgestuurd schalen.

Verwijzingen

  • Last updated on