Ein praktischer Leitfaden zur Optimierung des Kubernetes Horizontal Pod Autoscaler (HPA)

Der Kubernetes Horizontal Pod Autoscaler (HPA) kann Ihre App während Verkehrsspitzen reaktionsfähig halten, aber nur, wenn die Metriken und Grenzwerte das Verhalten der App widerspiegeln. Ein schlecht abgestimmter HPA kann zu spät skalieren, zu schnell herunterskalieren oder überhaupt nicht skalieren, weil Ressourcenanforderungen fehlen.

Dieser Leitfaden zeigt Ihnen, wie Sie den Kubernetes HPA mit CPU, Speicher, benutzerdefinierten Metriken, externen Metriken und Steuerungen des Skalierungsverhaltens optimieren.

Grundlegendes zum Horizontal Pod Autoscaler (HPA)

Der HPA skaliert die Anzahl der Pods in Ihrer Anwendung automatisch nach oben oder unten, um die aktuelle Nachfrage zu erfüllen. Er überwacht kontinuierlich bestimmte Metriken und vergleicht sie mit Zielwerten. Wenn die beobachtete Metrik das Ziel überschreitet, initiiert HPA ein Hochskalierungsereignis; wenn sie darunter fällt, löst er eine Herunterskalierung aus. Diese dynamische Anpassung stellt sicher, dass Ihre Anwendung genügend Ressourcen hat, um optimal zu arbeiten, ohne übermäßig bereitzustellen.

HPA kann basierend auf folgenden Metriken skalieren:

Ressourcenmetriken: Hauptsächlich CPU-Auslastung und Speicherauslastung (verfügbar über die metrics.k8s.io-API, normalerweise bereitgestellt durch den Kubernetes Metrics Server).
Benutzerdefinierte Metriken: Anwendungsspezifische Metriken, die über die custom.metrics.k8s.io-API bereitgestellt werden (z. B. Anfragen pro Sekunde, Warteschlangentiefe, aktive Verbindungen). Diese erfordern normalerweise einen Adapter wie prometheus-adapter.
Externe Metriken: Metriken aus Quellen außerhalb des Clusters, die über die external.metrics.k8s.io-API bereitgestellt werden (z. B. Google Cloud Pub/Sub-Warteschlangengröße, AWS SQS-Warteschlangenlänge). Diese erfordern ebenfalls einen benutzerdefinierten Metrik-API-Server, der externe Metriken abrufen kann.

Voraussetzungen für eine effektive HPA-Optimierung

Bevor Sie sich mit HPA-Konfigurationen befassen, stellen Sie sicher, dass diese grundlegenden Elemente vorhanden sind:

1. Definieren Sie genaue Ressourcenanforderungen und -grenzen

Dies ist vielleicht die wichtigste Voraussetzung. HPA verlässt sich stark auf korrekt definierte CPU- und Speicher-Anforderungen, um Auslastungsprozentsätze zu berechnen. Wenn ein Pod keine CPU-Anforderungen definiert hat, kann HPA seine CPU-Auslastung nicht berechnen, was eine CPU-basierte Skalierung unmöglich macht.

Anforderungen: Definieren Sie die minimal garantierten Ressourcen für Ihre Container. HPA verwendet diese Werte, um die Zielauslastung pro Pod zu bestimmen.
Grenzen: Definieren Sie die maximalen Ressourcen, die ein Container verbrauchen kann. Grenzen verhindern, dass ein einzelner Pod übermäßige Ressourcen verbraucht und andere Pods auf demselben Knoten beeinträchtigt.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: my-image:latest
        resources:
          requests:
            cpu: "200m"  # 20% eines CPU-Kerns
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"

2. Installieren Sie den Kubernetes Metrics Server

Damit HPA CPU- und Speicherauslastungsmetriken verwenden kann, muss der Kubernetes Metrics Server in Ihrem Cluster installiert sein. Er sammelt Ressourcenmetriken von Kubelets und stellt sie über die metrics.k8s.io-API bereit.

3. Anwendungsbeobachtbarkeit

Für benutzerdefinierte oder externe Metriken muss Ihre Anwendung relevante Metriken bereitstellen (z. B. über einen Prometheus-Endpunkt), und Sie benötigen eine Möglichkeit, diese Metriken zu sammeln und der Kubernetes-API bereitzustellen, normalerweise unter Verwendung eines Prometheus-Adapters oder eines benutzerdefinierten Metrik-API-Servers.

Konfigurieren des HPA: Kernparameter

Schauen wir uns die grundlegende Struktur eines HPA-Manifests an:

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

Wichtige Parameter:

scaleTargetRef: Definiert die Zielressource (z. B. Deployment), die HPA skalieren wird. Geben Sie ihre apiVersion, kind und name an.
minReplicas: Die minimale Anzahl von Pods, auf die HPA herunterskalieren wird. Es ist gute Praxis, dies auf mindestens 1 oder 2 für hohe Verfügbarkeit zu setzen, selbst unter Nullast.
maxReplicas: Die maximale Anzahl von Pods, auf die HPA hochskalieren wird. Dies dient als Schutz gegen unkontrollierte Skalierung und begrenzt die Kosten.
metrics: Ein Array, das die Metriken definiert, die HPA überwachen soll.
- type: Kann Resource, Pods, Object oder External sein.
- resource.name: Für den Typ Resource, gibt cpu oder memory an.
- target.type: Für den Typ Resource, Utilization (Prozentsatz der angeforderten Ressource) oder AverageValue (absoluter Wert).
- averageUtilization: Für den Typ Utilization, der Zielprozentsatz. HPA berechnet die gewünschte Anzahl von Pods basierend auf current_utilization / target_utilization * current_pods_count.

Optimierung des HPA für Reaktionsfähigkeit und Stabilität

Über die Basiskonfiguration hinaus bietet HPA erweiterte Optimierungsoptionen, insbesondere mit autoscaling/v2 (oder v2beta2 in älteren Versionen), um das Skalierungsverhalten detaillierter zu steuern.

1. CPU- und Speicherziele (`averageUtilization` / `averageValue`)

Das richtige Ziel der Auslastung zu setzen, ist entscheidend. Ein niedrigeres Ziel bedeutet frühere Skalierung (reaktionsschneller, potenziell teurer), während ein höheres Ziel spätere Skalierung bedeutet (weniger reaktionsschnell, potenziell billiger, aber riskiert Leistungseinbußen).

So bestimmen Sie optimale Ziele: Auslastungstests und Profiling sind Ihre besten Freunde. Erhöhen Sie allmählich die Last auf Ihre Anwendung, während Sie die Ressourcennutzung und Leistungsmetriken (Latenz, Fehlerraten) überwachen. Identifizieren Sie die CPU-/Speicherauslastung, bei der die Leistung Ihrer Anwendung nachlässt. Setzen Sie Ihr HPA-Ziel unter diese Schwelle, typischerweise im Bereich von 60-80% für CPU.
Balanceakt: Zielen Sie auf ein Ziel, das ausreichend Spielraum für unerwartete Spitzen lässt, aber nicht so niedrig ist, dass Sie ständig übermäßig bereitstellen.

2. Skalierungsverhalten (`behavior`-Feld)

Eingeführt in HPA autoscaling/v2, bietet das behavior-Feld eine feinkörnige Kontrolle über Hoch- und Herunterskalierungsereignisse und verhindert "Thrashing" (schnelle Hoch- und Herunterskalierungszyklen).

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60 # Warte 60s, bevor wieder hochskaliert wird
      policies:
      - type: Pods
        value: 4
        periodSeconds: 15 # Maximal 4 Pods alle 15 Sekunden hinzufügen
      - type: Percent
        value: 100
        periodSeconds: 15 # Oder die aktuellen Pods alle 15 Sekunden verdoppeln (je nachdem, was weniger restriktiv ist)
    scaleDown:
      stabilizationWindowSeconds: 300 # Warte 5 Minuten, bevor herunterskaliert wird
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60 # Maximal 50% der Pods alle 60 Sekunden entfernen
      selectPolicy: Max # Wähle die Richtlinie, die die größte erlaubte Herunterskalierungsänderung ermöglicht

`scaleUp`-Konfiguration:

stabilizationWindowSeconds: Dies glättet Skalierungsempfehlungen über ein aktuelles Zeitfenster. Hochskalierung verwendet normalerweise ein kurzes Fenster, damit die App schnell reagieren kann.
policies: Definiert, wie Pods während eines Hochskalierungsereignisses hinzugefügt werden. Sie können mehrere Richtlinien definieren, und HPA verwendet diejenige, die die höchste Anzahl von Pods ermöglicht (aggressivste Hochskalierung).
- type: Pods: Skaliert um eine feste Anzahl von Pods hoch. value gibt die Anzahl der hinzuzufügenden Pods an. periodSeconds definiert das Zeitfenster, über das diese Richtlinie gilt.
- type: Percent: Skaliert um einen Prozentsatz der aktuellen Pod-Anzahl hoch. value ist der Prozentsatz.

`scaleDown`-Konfiguration:

stabilizationWindowSeconds: Wichtiger für scaleDown, gibt an, wie lange HPA Metriken unter dem Ziel beobachten muss, bevor es eine Herunterskalierung in Betracht zieht. Ein längeres Fenster (z. B. 300-600 Sekunden) verhindert vorzeitige Herunterskalierung während vorübergehender Flauten und vermeidet "Kaltstarts" und Leistungseinbrüche. Dies ist eine entscheidende Einstellung für stabile Umgebungen.
policies: Ähnlich wie bei scaleUp, definiert, wie Pods entfernt werden. HPA verwendet die Richtlinie, die zur niedrigsten Anzahl von Pods führt (aggressivste Herunterskalierung), wenn selectPolicy Min ist, oder die Richtlinie, die zur höchsten Anzahl von Pods führt, wenn selectPolicy Max ist.
- type: Pods: Entfernt eine feste Anzahl von Pods.
- type: Percent: Entfernt einen Prozentsatz der aktuellen Pods.
selectPolicy: Bestimmt, welche Richtlinie angewendet wird, wenn mehrere scaleDown-Richtlinien definiert sind. Max ist die Standardeinstellung und wählt die Richtlinie, die die größte Skalierungsänderung ermöglicht. Verwenden Sie Min, wenn Sie eine konservativere Herunterskalierung wünschen.
Warnung: Seien Sie vorsichtig mit aggressiven scaleDown-Richtlinien oder kurzen stabilizationWindowSeconds für scaleDown. Wenn Ihre Anwendung lange Initialisierungszeiten hat oder zustandsbehaftete Verbindungen verwaltet, kann eine schnelle Herunterskalierung zu Dienstunterbrechungen oder erhöhter Latenz für Benutzer führen.

Erweiterte HPA-Metriken und -Strategien

Während CPU und Speicher üblich sind, skalieren viele Anwendungen besser mit benutzerdefinierten oder externen Metriken, die ihre tatsächliche Arbeitslast widerspiegeln.

1. Benutzerdefinierte Metriken

Verwenden Sie benutzerdefinierte Metriken, wenn CPU/Speicher kein direkter Indikator für die Last oder den Leistungsengpass Ihrer Anwendung ist. Beispiele: HTTP-Anfragen pro Sekunde (QPS), aktive Verbindungen, Nachrichtenwarteschlangenlänge, Batch-Job-Rückstand.

Um benutzerdefinierte Metriken zu verwenden:

Ihre Anwendung muss diese Metriken bereitstellen (z. B. über einen Prometheus-Exporter).
Stellen Sie einen benutzerdefinierten Metrikadapter (z. B. prometheus-adapter) bereit, der diese Metriken scrapen und über die custom.metrics.k8s.io-API bereitstellen kann.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa-qps
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 15
  metrics:
  - type: Pods # Oder Object, wenn die Metrik für das gesamte Deployment ist
    pods:
      metric:
        name: http_requests_per_second # Der Name der von Ihrer Anwendung/Ihrem Adapter bereitgestellten Metrik
      target:
        type: AverageValue
        averageValue: "10k" # Ziel: 10.000 Anfragen pro Sekunde pro Pod

2. Externe Metriken

Externe Metriken sind nützlich, wenn die Arbeitslast Ihrer Anwendung von einem externen System gesteuert wird, das nicht direkt auf Kubernetes läuft. Beispiele: AWS SQS-Warteschlangentiefe, Kafka-Topic-Verzögerung, Pub/Sub-Abonnement-Rückstand.

Um externe Metriken zu verwenden:

Sie benötigen einen benutzerdefinierten Metrik-API-Server, der Metriken von Ihrem externen System abrufen kann (z. B. einen spezifischen Adapter für AWS CloudWatch oder GCP Monitoring).

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-worker-hpa-sqs
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-worker
  minReplicas: 1
  maxReplicas: 20
  metrics:
  - type: External
    external:
      metric:
        name: aws_sqs_queue_messages_visible # Metrikname von Ihrer externen Quelle
        selector:
          matchLabels:
            queue: my-queue-name
      target:
        type: AverageValue
        averageValue: "100" # Ziel: 100 sichtbare Nachrichten in der Warteschlange pro Pod

3. Mehrere Metriken

HPA kann so konfiguriert werden, dass es mehrere Metriken gleichzeitig überwacht. Wenn mehrere Metriken angegeben sind, berechnet HPA die gewünschte Replikatanzahl für jede Metrik unabhängig und wählt dann die höchste dieser gewünschten Replikatanzahlen aus. Dies stellt sicher, dass die Anwendung für alle beobachteten Lastdimensionen ausreichend skaliert.

# ... (HPA-Boilerplate)
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: "10k"

Überwachung und Validierung

Effektive HPA-Optimierung ist ein iterativer Prozess, der kontinuierliche Überwachung und Validierung erfordert:

Beobachten Sie HPA-Ereignisse: Verwenden Sie kubectl describe hpa <hpa-name>, um den Status, Ereignisse und Skalierungsentscheidungen von HPA zu sehen. Dies bietet wertvolle Einblicke, warum HPA hoch- oder herunterskaliert hat.
Überwachen Sie Metriken und Replikate: Verwenden Sie Ihren Observability-Stack (z. B. Prometheus, Grafana), um die Ressourcennutzung (CPU, Speicher), benutzerdefinierte/externe Metriken und die tatsächliche Anzahl von Pod-Replikaten im Laufe der Zeit zu visualisieren. Korrelieren Sie diese mit Änderungen der eingehenden Last.
Auslastungstests: Simulieren Sie erwartete und Spitzenlasten, um die Reaktionsfähigkeit von HPA zu validieren und sicherzustellen, dass Ihre Anwendung unter Stress wie erwartet funktioniert. Passen Sie HPA-Parameter basierend auf diesen Tests an.

Best Practices für die HPA-Optimierung

Beginnen Sie mit klar definierten Ressourcenanforderungen/-grenzen: Sie sind die Grundlage für eine genaue ressourcenbasierte HPA. Ohne sie kann HPA für CPU/Speicher nicht effektiv funktionieren.
Setzen Sie realistische minReplicas und maxReplicas: minReplicas bietet eine Basislinie für Verfügbarkeit, während maxReplicas als Sicherheitsnetz gegen außer Kontrolle geratene Kosten und Ressourcenerschöpfung dient.
Passen Sie die Zielauslastung schrittweise an: Beginnen Sie mit einem leicht konservativen CPU-Ziel (z. B. 60-70%) und iterieren Sie. Zielen Sie nicht auf 100% Auslastung, da dies keinen Puffer für Latenz- oder Verarbeitungsspitzen lässt.
Nutzen Sie stabilizationWindowSeconds: Unerlässlich, um schnelle Skalierungsschwingungen zu verhindern. Verwenden Sie ein längeres Fenster für scaleDown (z. B. 5-10 Minuten) als für scaleUp (z. B. 1-2 Minuten), um Stabilität zu gewährleisten.
Priorisieren Sie anwendungsspezifische Metriken: Wenn CPU oder Speicher nicht direkt mit den Leistungsengpässen Ihrer Anwendung korrelieren, verwenden Sie benutzerdefinierte oder externe Metriken für eine genauere und effizientere Skalierung.
Überwachen, testen, iterieren: HPA-Optimierung ist keine einmalige Einrichtung. Anwendungsverhalten, Verkehrsmuster und zugrunde liegende Infrastruktur können sich ändern. Überprüfen Sie regelmäßig die HPA-Leistung und passen Sie die Einstellungen nach Bedarf an.
Verstehen Sie die Skalierungseigenschaften Ihrer Anwendung: Skaliert sie linear mit Anfragen? Hat sie lange Startzeiten? Ist sie zustandsbehaftet? Diese Eigenschaften beeinflussen Ihre HPA-Strategie.

Abschließende Erkenntnis

Behandeln Sie die HPA-Optimierung als eine Rückkopplungsschleife. Beginnen Sie mit genauen Ressourcenanforderungen, setzen Sie realistische minReplicas und maxReplicas, wählen Sie eine Metrik, die die tatsächliche Nachfrage verfolgt, und validieren Sie das Hoch- und Herunterskalierungsverhalten mit Auslastungstests, bevor der Produktionsverkehr davon abhängt.