Wann sollte ich die horizontale Pod-Autoskalierung (HPA) in Kubernetes verwenden?

Kurze Antwort: Verwenden Sie HPA, wenn Ihre Anwendung als mehrere identische Replikate ausgeführt werden kann und die Nachfrage schwankt – skalieren Sie nach CPU-/Arbeitsspeicherauslastung, Anwendungsmetriken (RPS/Latenz) oder externen Warteschlangen-/Backlog-Metriken. Verwenden Sie HPA nicht für dienste mit einem Replikat oder wenn es sich bei dem tatsächlichen Engpass um Knotenkapazitäts- oder Downstreamgrenzwerte handelt (DB-Verbindungen, Grenzwerte für Drittanbieterraten).

TL; DR:

  • Verwenden Sie HPA für horizontal skalierbare Workloads, bei denen Metriken pro Pod oder externe Metriken die Last widerspiegeln.
  • Verwenden Sie Ressourcen-, benutzerdefinierte und externe Metriken (CPU, RPS, Warteschlangentiefe); kombinieren Sie diese mit dem Cluster Autoscaler für Knotenkapazität.
  • Verwenden Sie KEDA für ereignisgesteuerte Scale-to-Zero-Szenarien oder externe Skalierer; verwenden Sie VPA im Empfehlungsmodus zur Dimensionierung der Ressourcenanforderungen.

Checkliste für schnelle Entscheidung (Ja/Nein):

  • Ist die Arbeitslast statuslos oder auf viele Replikate verteilbar? (Ja → HPA-Kandidat)
  • Können Sie die Last als podspezifische oder externe Metrik (CPU, Anfragen/Sek., Warteschlangentiefe) erfassen? (Ja → HPA geeignet)
  • Kann der Cluster weitere Pods einplanen (Cluster Autoscaler oder freie Kapazität)? (Ja → fortfahren; wenn nein, aktivieren Sie die automatische Skalierung von Knoten)
  • Beschränken nachgeschaltete Dienste (DB-Pools, APIs von Drittanbietern) die Parallelität? (Ja → Drosselung/Verbindungspooling einführen oder vertikale Skalierung bevorzugen)

Entscheidungsmatrix (Workload → beste Metrik → empfohlenen Scaler):

Workload-Typ Beste Metrik als Zielgröße Empfohlene Skalierung
Web/API (zustandslos) CPU oder RPS pro Pod HPA (+VPA-Empfehlung + Cluster-Autoscaler)
Hintergrundwarteschlangenmitarbeiter Warteschlangenlänge oder Nachrichten/Sek. HPA über externe Metriken oder KEDA (KEDA unterstützt die Skalierung auf null)
Einzelinstanz-Datenbank oder zustandsbehaftete Anwendung N/A (nicht horizontal partitionierbar) VPA oder manuelle Skalierung
Batch-/Ephemeral-Ereignismitarbeiter Rückstand bei Ereignissen KEDA oder HPA mit externen Metriken

Funktionsweise von HPA (einfache Steuerungsschleife und wichtige Felder)

  • Komponenten: der HPA-Controller (Steuerebene) + Metrikanbieter (Metrikserver für Ressourcenmetriken, benutzerdefinierte/externe Metrik-API über Adapter oder KEDA).
  • Steuerungsschleife (auf hoher Ebene): Der HPA-Controller fragt die Metrik-API ab → berechnet aus jeder konfigurierten Metrik die gewünschte Anzahl an Replikaten → verwendet den größten berechneten Wert → wendet Min/Max-Werte und das Verhalten (Richtlinien/Stabilisierung) an → aktualisiert `spec.replicas` auf der Zielressource → wiederholen. Weitere Informationen finden Sie in den Kubernetes HPA-Dokumentationen .
  • Formel (so werden die gewünschten Replikate berechnet): desiredReplicas = ceil(current_total / target_per_pod). Der Controller berechnet eine desiredReplicas für jede konfigurierte Metrik und verwendet dann den größten Wert vor dem Anwenden von Min/Max und Verhalten (dieses metrische Rangfolgeverhalten wird in den HPA-Dokumenten dokumentiert).
  • Wichtige Felder in autoscaling/v2: minReplicas, maxReplicas, Metriken (Resource, Pods, Object, External), Verhalten (scaleUp-/scaleDown-Richtlinien und stabilizationWindowSeconds).
  • Verwenden Sie das Verhalten, um die Änderungsrate zu begrenzen und Flapping zu vermeiden; stabilizationWindowSeconds ist ein Tastenknüppel für die ScaleDown-Glättung.

Beispielausschnitt zum Verhalten (autoscaling/v2)

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

Wann HPA verwendet werden sollte (nach Metriktyp / häufigen Anwendungsfällen)

  1. CPU/Arbeitsspeicher (Ressourcenmetriken)
    • Verwenden Sie HPA, wenn die CPU- oder Speicherauslastung pro Pod mit kapazitätsanforderungen korreliert und Pods die richtigen Ressourcenanforderungen definieren. Typisch für Web-APIs und zustandslose Microservices.
    • Praktischer Ausgangspunkt: Zielwert der durchschnittlichen CPU-Auslastung im 60-80% Bereich und Optimierung durch Auslastungstests. HPA berechnet die Auslastung anhand der Pod-Requests, daher müssen Requests festgelegt sein.
  2. Benutzerdefinierte In-Cluster-Metriken (Prometheus / benutzerdefinierte Metriken)
    • Verwenden Sie HPA, wenn Signale auf App-Ebene (Anfragen/Sek., Latenz, Warteschlangen-Consumer pro Pod) die Last besser abbilden als die CPU.
    • Machen Sie Metriken mit Prometheus + prometheus-adapter (custom.metrics.k8s.io) oder einem anderen benutzerdefinierten Metrikanbieter verfügbar und zielen Sie auf diese Metriken in HPA ab.
  3. Externe Metriken (Warteschlangen, Cloud-Backlogs)
    • Verwenden Sie HPA (über die externe Metrik-API) oder KEDA, wenn die Skalierung auf externe Signale wie Die Warteschlangenlänge (RabbitMQ, Azure Service Bus), Event Hubs oder Cloudüberwachungsmetriken reagieren soll.
    • Wenn Sie scale-to-Zero- oder enges ereignisgesteuertes Verhalten benötigen, bevorzugen Sie KEDA – es integriert nativ externe Scaler und unterstützt Scale-to-Zero (KEDA-Dokumente).

Wann NICHT HPA verwendet werden soll

  • Zustandsbehaftete Dienste mit nur einer Replik (Datenbanken, eindeutiger Zustand innerhalb des Pods): HPA ist nicht angebracht, es sei denn, Sie können sie sicher in Shards aufteilen oder partitionieren.
  • Wenn sich der Engpass auf Knotenebene (GPU, Datenträger-E/A, Knoten-CPU) und nicht pro Pod befindet: Bevorzugen Sie die automatische Skalierung des Knotenpools oder die vertikale Skalierung.
  • Wenn nachgeschaltete Systeme (DB-Verbindungspools, Caches, APIs von Drittanbietern) strenge Parallelitätsgrenzwerte aufweisen: Skalierungs-Pods ohne erhöhung der downstream-Kapazität können Ausfälle verschlechtern – siehe "Nachgeschaltete und betriebliche Überlegungen" weiter unten.
  • Falls Sie eine Skalierung auf null benötigen, kann HPA allein das nicht leisten; verwenden Sie KEDA oder einen externen Controller.

Mehrere Metriken, Rangfolgen und ein Beispiel

  • Wenn Sie mehrere Metriken konfigurieren, berechnet der HPA-Controller für jede Metrik unabhängig einen desiredReplicas-Wert und wählt dann den größten desiredReplicas-Wert als Grundlage für die Skalierung aus. Danach werden minReplicas/maxReplicas und Verhaltensrichtlinien angewendet (Quelle: Kubernetes HPA-Dokumente).
  • Beispiel: Das CPU-Ziel berechnet 5 Replikate, das Ziel für Anfragen/Sek. berechnet 12 Replikate → der HPA wählt 12 aus (dann können Mindest-/Höchstwerte und Verhaltensrichtlinien die endgültig angewendete Anpassung verändern).
  • Um eine plötzliche Überskalierung zu vermeiden, kombinieren Sie eine prozentbasierte ScaleUp-Richtlinie mit einem angemessenen Wert für scaleDown.stabilizationWindowSeconds (siehe obigen Verhaltensabschnitt).

HPA vs VPA vs Cluster Autoscaler vs KEDA (kurze Anleitung)

  • HPA: Skaliert Replikate horizontal basierend auf Metriken. Am besten geeignet für partitionierbare Workloads.
  • VPA: Passt Pod-Ressourcenanforderungen/Grenzwerte (vertikal) an. Am besten geeignet für nicht parallelisierbare Workloads oder zum Festlegen sensibler Standardwerte.
  • Cluster Autoscaler (oder Karpenter): Skaliert Knoten, um Planungsanforderungen (Kapazität auf Knotenebene) zu erfüllen. Verwenden, wenn Pods aufgrund fehlender Knoten im Status „Pending“ verbleiben.
  • KEDA: ereignisgesteuerter Autoscaler, der externe Trigger integriert und das Herunterskalieren auf null für ereignisgesteuerte Workloads unterstützt.

Allgemeines Muster: Verwenden Sie VPA im Empfehlungsmodus, um Basisanforderungen festzulegen, HPA zum Skalieren von Replikaten und Cluster-Autoscaler (oder Karpenter), um die Knotenkapazität bereitzustellen. Verwenden Sie KEDA, wenn Sie Scale-to-Zero oder eine direkte Integration mit externen Ereignisquellen benötigen.

Hinweis: Verwaltete Kubernetes-Angebote (AKS/GKE/EKS) können Metrikanbieter vorinstallieren oder integrierte Autoscaler-Features bereitstellen. AKS Cluster AutoScaler-Dokumente

Nachgelagerte und operative Überlegungen (häufige Stolperfallen)

  • Datenbank-Verbindungspools: Eine Erhöhung der Anzahl von Replikaten erhöht die Anzahl gleichzeitiger Verbindungen. Dem lässt sich durch Verbindungspooling (z. B. PgBouncer), die Begrenzung der Parallelität je Pod oder eine Erhöhung der DB-Poolgröße entgegenwirken, bevor Pods skaliert werden.
  • API-Rate-Grenzwerte und Drittanbieterkontingente: Stellen Sie sicher, dass nachgeschaltete Systeme das Anforderungsvolumen verarbeiten können, das skalierte Pods produzieren; Erwägen Sie die clientseitige Drosselung.
  • PodDisruptionBudgets (PDBs): PDBs verhindern keine HPA-Skalierung, können aber wartungs- und entwässerungsverhalten beeinflussen; Stellen Sie sicher, dass Skalierungsrichtlinien an PDBs ausgerichtet sind.
  • Start- und Aufwärmeffekte: initContainers, Cache-Aufwärmen oder lange Kaltstarts können Metriken verzerren und Schwingungen verursachen – verwenden Sie Bereitschafts- und Startsonden sowie Stabilisierungsfenster.
  • Empfohlene Vorgehensweise für den Betrieb: konservative Skalierungsraten festlegen, Requests/Limits und Probes abstimmen, in Nicht-Produktivumgebungen testen und eine SLO-bewusste Drosselung hinzufügen, wenn nachgelagerte Systeme einen Engpass darstellen.

Konfigurationsprüfliste und sichere Rolloutschritte

Stellen Sie Metriken und RBAC sicher:

  • Bereitstellen des Metrikservers für Ressourcenmetriken (oder Verwenden eines verwalteten Anbieters).
  • Stellen Sie prometheus + prometheus-adapter für benutzerdefinierte Metriken (custom.metrics.k8s.io) bei Bedarf bereit.
  • Für externe oder ereignisbasierte Skalierung sollten Sie KEDA erwägen.

Schreiben Sie HPA (autoscaling/v2) mit:

  • minReplicas und maxReplicas,
  • explizite Metriken und Verhaltensweisen (scaleUp/scaleDown-Richtlinien),
  • Bereitschafts- und Startsonden auf Pods,
  • sinnvolle Ressourcenanforderungen, sodass Ressourcenmetriken sinnvoll sind.

Prüfliste für sichere Tests (sicheres Testen von HPA):

  1. Testen Sie in einem Nicht-Produktionsnamespace/Cluster mit ähnlichen Knotengrößen und aktivierter automatischer Skalierung.
  2. Beginnen Sie mit konservativen Min/Max-Replikaten und sanften ScaleUp-Richtlinien (z. B. max. 100% Wachstum/Minute).
  3. Führen Sie schrittweise Lasttests durch und überwachen Sie desiredReplicas im Vergleich zu currentReplicas sowie Pods im Status Pending.
  4. Durchlaufen Sie Anforderungen/Grenzwerte, Bereitschaftssonden und Verhaltensrichtlinien, bevor sie die Aggressivität erhöhen.

Hinweise zur AKS- und Node-Autoskalierung:

  • AKS und andere Cloud-Angebote können metrics-server vorinstallieren oder eine verwaltete Autoscaler-Integration anbieten. Beispiel für AKS CLI zum Aktivieren der Cluster-Autoskaler: az aks nodepool update --resource-group myRG --cluster-name myAKS --name node-pool1 --enable-cluster-autoscaler --min-count 1 --max-count 5

Karpenter Hinweis: Karpenter ist ein alternativer Knotenautoskalierungsansatz, der sich auf schnelle Bereitstellung konzentriert; Erwägen Sie dies, wenn eine schnelle Knotenbereitstellung erforderlich ist.

Funktionierende YAML-Beispiele

CPU-basierte HPA (autoscaling/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 unter Verwendung einer von Prometheus bereitgestellten benutzerdefinierten Metrik (über 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"

Siehe prometheus-adapter docs für Zuordnungsabfragen

KEDA ScaledObject (Azure Service Bus) – unterstützt Scale-to-Zero:

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-Dokumente

Observability, Warnmeldungen und SRE-Beispiele

Vorgeschlagene Warnungen (kopierbare Prometheus-Beispiele — Metriknamen an Ihr Export-Setup anpassen):

  1. Warnung, wenn der HPA-Sollwert > dem aktuellen Wert für > 5 Min. (Kapazitätsplanungsproblem)

    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. Warnung für ausstehende Pods in einem 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. Warnung bei häufigem Skalieren (Pendeln)

    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"

Instrumententafeln mit:

  • HPA: currentReplicas, desiredReplicas, lastScaleTime, vom HPA verwendete Metrikwerte
  • Pod-Zustand: Ausstehende Pods, FailedScheduling-Ereignisse, Anzahl der Pod-Neustarts
  • Downstream: DB-Verbindungsauslastung, Fehlerraten, externe API-Fehler/429-Raten

Betriebs- und Debuggingbefehle (Kurzübersicht)

  • HPAs auflisten: kubectl get hpa -n
  • HPA beschreiben (achten Sie auf current/current metrics, desiredReplicas, lastScaleTime, Ereignisse): kubectl describe hpa -n
  • Zu prüfende Felder in der describe-Ausgabe: currentReplicas, desiredReplicas, Metriken (aktuelle Werte/Zielwerte), lastScaleTime, Ereignisse (Fehler des Metrikanbieters oder Skalierungsfehler)
  • Ressourcennutzung anzeigen (erfordert Metrikserver): kubectl top pods -n
  • Überprüfen ausstehender Pods und Terminplanungsfehler: kubectl get pods -n | grep Pending, kubectl describe pod -n (Suchen Sie nach FailedScheduling)
  • Überprüfen der Metrikanbieterprotokolle: kubectl logs -n kube-system deploy/metrics-server, kubectl logs -n deploy/prometheus-adapter
  • HPA-Manifest anwenden: kubectl apply -f hpa.yaml

Tipps zur schnellen Problembehandlung:

  • HPA meldet desiredReplicas > currentReplicas und Pods bleiben im Status „Pending“ → wahrscheinlich unzureichende Knotenkapazität; aktivieren Sie den Cluster Autoscaler oder erhöhen Sie den Knotenpool.
  • HPA zeigt Metrikfehler in Ereignissen → Adapter-RBAC/-Konfiguration und Protokolle des Metrikanbieters prüfen.
  • HPA-Skalierung zu schnell/langsam → Optimieren von Verhaltensrichtlinien (Prozent-/Pods-Grenzwerte) und Stabilisierungsfenstern.

Empfohlene Optimierungsstandardeinstellungen und Heuristiken

  • CPU-Ziel: Beginnen Sie bei etwa 60 % durchschnittlicher Auslastung (üblicher Bereich 60–80 %) und optimieren Sie je nach Workload.
  • minReplicas: mindestens 1 zur Verfügbarkeit; verwenden Sie KEDA, wenn Sie minReplicas: 0 benötigen.
  • maxReplicas: basierend auf Kapazitätsplanung und Kosten festlegen; stellen Sie sicher, dass die Grenzwerte des Cluster Autoscalers das Hinzufügen von Knoten bis zur erforderlichen Kapazität erlauben.
  • stabilizationWindowSeconds: scaleDown ≈ 300s (5 min) ist ein häufiger Ausgangspunkt, um rasches Herunterskalieren zu vermeiden; je nach Workload anpassen.
  • Skalierungsrichtlinien: Prozentuale Erhöhungen pro Periode begrenzen (z. B. maximal 100 % Wachstum pro Minute zulassen), um nachgelagerte Systeme nicht zu überlasten.
  • Bereitschafts-/Startsonden: Definieren Sie sie immer, sodass Pods erst dann Datenverkehr empfangen, wenn sie vollständig bereit sind.

Hinweis: Spezifische Controller-Timing-Standardwerte und genaues Verhalten können in Kubernetes-Versionen und -Verteilungen variieren – überprüfen Sie die HPA-Dokumente für Ihre Clusterversion.

Häufige Fallstricke und Prüfliste vor der Aktivierung von HPA

  • Pod-Ressourcenanforderungen fehlen oder falsch → ressourcenbasierte HPA-Ziele sind irreführend.
  • Kein Metrik-Anbieter (metrics-server/prometheus-adapter/KEDA) → HPA kann keine Metriken lesen.
  • Der Cluster verfügt über keine Node-Kapazität und der Cluster Autoscaler ist nicht aktiviert → Pods verbleiben im Status „Pending“.
  • Kombination von HPA & VPA: Vermeiden Sie, dass beide Controller Ressourcenanforderungen aktiv ändern – führen Sie VPA im Empfehlungsmodus aus und lassen Sie HPA die Anzahl der Replikate skalieren.
  • Startspitzen (initContainers, Kalte Caches) ohne Probes → Stabilisierungsfenster oder warme Instanzen manuell anpassen.
  • Fehlkonfiguration von RBAC: Stellen Sie sicher, dass Metrikadapter und HPA-Controller über erforderliche Berechtigungen zum Lesen von Metriken verfügen.

Häufig gestellte Fragen (FAQ)

F: Was sind die Vorteile von HPA? A: Replikatanzahl automatisch an wechselnde Lasten anpassen, die Auslastung verbessern und Kosten senken sowie Latenzziele einhalten, wenn die richtigen Metriken und die automatische Knotenskalierung verwendet werden.

F: Wie berechnet HPA die gewünschten Replikate? A: Es liest konfigurierte Metriken, berechnet desiredReplicas = ceil(current_total / target_per_pod) für jede Metrik, übernimmt den größten berechneten Wert und wendet dann Min/Max- und Verhaltensrichtlinien an (Quelle: HPA-Dokumente).

F: Kann HPA auf Null skaliert werden? A: Nein – einfache HPA kann nicht auf Null skaliert werden. Verwenden Sie KEDA für das Scale-to-Zero-Verhalten (KEDA-Dokumentation).

Q: Wie skaliert man anhand der Warteschlangenlänge oder RPS? A: Warteschlangenlänge/RPS als externe oder benutzerdefinierte Metrik verfügbar machen (Prometheus-Adapter oder die API für externe Metriken) oder KEDA für ereignisgesteuerte Skalierung verwenden.

References

  • Last updated on