Kubernetes HPA: Anleitung zum Horizontal Pod Autoscaler

Der Kubernetes Horizontal Pod Autoscaler (HPA) passt automatisch die Anzahl der Pod-Replicas in einem Deployment, Replica Set oder Stateful Set basierend auf beobachteten Metriken an. Anstatt Workloads manuell zu skalieren wenn der Traffic um 2 Uhr morgens ansteigt, übernimmt HPA das für dich. In dieser Anleitung lernst du, wie HPA intern funktioniert, wie du ihn mit CPU-, Speicher- und benutzerdefinierten Metriken konfigurierst, und wie du Skalierungsrichtlinien für Produktions-Workloads abstimmst.

Voraussetzungen

Bevor du HPA konfigurierst, stelle sicher, dass du Folgendes hast:

• Einen laufenden Kubernetes-Cluster (v1.23+) — minikube, kind oder ein verwalteter Cluster (EKS, GKE, AKS)
• kubectl installiert und für die Kommunikation mit deinem Cluster konfiguriert
• metrics-server deployed (die meisten verwalteten Cluster enthalten ihn standardmäßig)
• Grundlegende Vertrautheit mit Deployments und Services
• Ein Deployment mit definierten CPU/Speicher-requests (HPA kann die Auslastung ohne sie nicht berechnen)

Überprüfe, ob metrics-server läuft:

kubectl get deployment metrics-server -n kube-system
kubectl top nodes
kubectl top pods

Wenn kubectl top Metriken zurückgibt, bist du bereit fortzufahren.

Wie HPA Funktioniert

HPA läuft als Regelschleife im Kubernetes Controller Manager und prüft Metriken in einem konfigurierbaren Intervall (Standard: 15 Sekunden). Bei jeder Iteration:

1. Ruft aktuelle Metrikwerte von der Metriken-API für alle Pods im Ziel-Workload ab
2. Berechnet die gewünschte Replica-Anzahl mit der Formel:

$$ \text{gewünschteReplicas} = \lceil \text{aktuelleReplicas} \times \frac{\text{aktuellerMetrikwert}}{\text{gewünschterMetrikwert}} \rceil $$

3. Vergleicht die gewünschten Replicas mit den aktuellen Replicas
4. Skaliert den Workload hoch oder herunter, wenn das Verhältnis eine konfigurierbare Toleranz überschreitet (Standard ±10%)

Beispiel: Wenn dein Deployment 3 Replicas hat, die durchschnittlich bei 75% CPU laufen, und dein Ziel 50% ist:

$$ \text{gewünscht} = \lceil 3 \times \frac{75}{50} \rceil = \lceil 4.5 \rceil = 5 $$

HPA würde das Deployment auf 5 Replicas skalieren.

Cooldown-Verhalten: HPA verwendet Stabilisierungsfenster um Schwankungen zu verhindern. Standardmäßig verwenden Scale-Down-Ereignisse ein 5-Minuten-Stabilisierungsfenster — HPA wählt die höchste empfohlene Replica-Anzahl der letzten 5 Minuten. Scale-Up hat kein Standard-Stabilisierungsfenster und reagiert sofort auf Lastanstiege.

HPA mit CPU-Metriken Konfigurieren

Schnelle Einrichtung mit kubectl

Der schnellste Weg einen HPA zu erstellen:

kubectl autoscale deployment my-app \
  --cpu-percent=50 \
  --min=2 \
  --max=10

Das sagt Kubernetes: Halte die durchschnittliche CPU-Auslastung bei 50% über alle Pods, mit mindestens 2 und maximal 10 Replicas.

Vollständiges YAML-Manifest

Für die Produktion definiere HPA als versionierbares YAML-Manifest:

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: 50
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 70

Anwenden und überwachen:

kubectl apply -f hpa.yaml
kubectl get hpa my-app-hpa --watch

Die Ausgabe sieht so aus:

NAME         REFERENCE           TARGETS           MINPODS   MAXPODS   REPLICAS
my-app-hpa   Deployment/my-app   32%/50%, 45%/70%   2         10        3

Wichtig: Die Container deines Deployments müssen Ressourcenanforderungen definiert haben, sonst kann HPA keine Auslastungsprozente berechnen:

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

Benutzerdefinierte Metriken und Externe Metriken

CPU und Speicher reichen oft nicht für Skalierungsentscheidungen aus. Ein Webservice kann niedrige CPU haben, aber eine große Anfragenwarteschlange. HPA v2 unterstützt drei Metriktypen:

Metriktyp	Quelle	Beispiel
Resource	metrics-server	CPU-, Speicherauslastung
Pods	Custom-Metriken-API	Anfragen pro Sekunde pro Pod
External	Externe-Metriken-API	SQS-Warteschlangentiefe, Pub/Sub-Backlog

Benutzerdefinierte Metriken mit Prometheus Adapter Einrichten

Installiere prometheus-adapter um Prometheus-Metriken über die Kubernetes Custom-Metriken-API bereitzustellen:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prometheus-adapter prometheus-community/prometheus-adapter \
  --namespace monitoring \
  --set prometheus.url=http://prometheus-server.monitoring.svc

Dann konfiguriere einen HPA mit einer benutzerdefinierten Metrik:

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

Skalierung nach Externer Warteschlangentiefe

Für ereignisgesteuerte Architekturen skaliere basierend auf einer externen Metrik wie einer SQS-Warteschlange:

metrics:
  - type: External
    external:
      metric:
        name: sqs_queue_length
        selector:
          matchLabels:
            queue: "order-processing"
      target:
        type: Value
        value: "30"

Dies skaliert deine Consumer-Pods um die Warteschlangenlänge bei etwa 30 Nachrichten zu halten.

HPA vs VPA vs Cluster Autoscaler

Eigenschaft	HPA	VPA	Cluster Autoscaler
Was skaliert wird	Anzahl der Pod-Replicas	CPU/Speicheranforderungen pro Pod	Anzahl der Cluster-Nodes
Richtung	Horizontal (mehr Pods)	Vertikal (größere Pods)	Horizontal (mehr Nodes)
Verwendete Metriken	CPU, Speicher, benutzerdefiniert, extern	Historische Ressourcennutzung	Ausstehende Pod-Planung
Erfordert Neustart	Nein	Ja (erstellt Pods neu)	Nein (fügt Nodes hinzu)
Am besten für	Zustandslose, horizontal skalierbare Apps	Einzelinstanz-Apps mit variablen Ressourcen	HPA-Scale-Up unterstützen
Kombinierbar	Ja, mit Cluster Autoscaler	Nicht mit HPA auf gleicher Metrik	Ja, mit HPA
Reaktionsgeschwindigkeit	Sekunden bis Minuten	Minuten (Pod-Neustart)	Minuten (Node-Bereitstellung)

Empfohlene Kombination: Verwende HPA für Workload-Skalierung + Cluster Autoscaler für Infrastruktur-Skalierung. Vermeide die gleichzeitige Verwendung von HPA und VPA auf derselben Metrik für dasselbe Deployment — sie werden in Konflikt geraten.

Praxisszenario

Betrachte eine E-Commerce-Plattform die während Flash-Sales 10x mehr Traffic erlebt. Dein checkout-service Deployment verarbeitet normalerweise 50 Anfragen/Sekunde mit 3 Replicas.

Ohne HPA: Dein Bereitschaftsingenieur wird um Mitternacht alarmiert, skaliert manuell auf 20 Replicas und vergisst dann herunterzuskalieren. Du bezahlst 3 Tage lang für ungenutzte Ressourcen.

Mit konfiguriertem HPA:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: checkout-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: checkout-service
  minReplicas: 3
  maxReplicas: 30
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: "50"
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
        - type: Percent
          value: 100
          periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 10
          periodSeconds: 60

Diese Konfiguration:

• Skaliert aggressiv hoch — verdoppelt Replicas alle 60 Sekunden wenn CPU 60% übersteigt oder die Anfragerate 50 req/s pro Pod übersteigt
• Skaliert konservativ herunter — entfernt nur 10% der Replicas pro Minute mit einem 5-Minuten-Stabilisierungsfenster
• Verhindert vorzeitiges Herunterskalieren nach kurzen Traffic-Spitzen

Während des Flash-Sales skaliert HPA von 3 auf 25 Replicas in unter 5 Minuten. Nachdem der Traffic nachlässt, reduziert es schrittweise auf 3 in etwa 30 Minuten.

Skalierungsrichtlinien und Verhalten

Das behavior-Feld (autoscaling/v2) gibt dir feingranulare Kontrolle über die Skalierungsgeschwindigkeit:

behavior:
  scaleUp:
    stabilizationWindowSeconds: 0
    policies:
      - type: Percent
        value: 100
        periodSeconds: 15
      - type: Pods
        value: 4
        periodSeconds: 15
    selectPolicy: Max
  scaleDown:
    stabilizationWindowSeconds: 300
    policies:
      - type: Percent
        value: 10
        periodSeconds: 60
    selectPolicy: Min

Wichtige Felder:

• stabilizationWindowSeconds — wie weit HPA zurückblickt um die konservativste Empfehlung zu wählen. Setze auf 0 für sofortiges Hochskalieren; 300 (5 Min.) für vorsichtiges Herunterskalieren.
• policies — definiert die Skalierungsrate als Prozentsatz der aktuellen Replicas oder absolute Anzahl von Pods pro Zeitraum.
• selectPolicy — Max wählt die Richtlinie die die meiste Änderung erlaubt (aggressiv), Min wählt die konservativste, Disabled verhindert die Skalierung in dieser Richtung.

Gängige Richtlinienmuster

Schnelles Hochskalieren, langsames Herunterskalieren (empfohlen für die meisten Web-Apps):

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

Herunterskalieren komplett verhindern (Batch-Jobs):

scaleDown:
  selectPolicy: Disabled

Fallstricke und Sonderfälle

Metrik-Verzögerung: Metrics-server sammelt Daten alle 15 Sekunden, und HPA wertet alle 15 Sekunden aus. Das bedeutet eine Verzögerung von 15–30 Sekunden zwischen einem Lastspitze und der ersten Skalierungsentscheidung. Für latenzempfindliche Dienste erwäge mit mehr minReplicas zu starten.

Fehlende Ressourcenanforderungen: Wenn deine Container keine CPU- oder Speicher-requests definieren, meldet HPA <unknown> für die Auslastung und wird nicht skalieren. Definiere immer Requests.

Readiness Probes sind wichtig: HPA zählt nur Ready Pods bei der Metrikberechnung. Wenn neue Pods 60 Sekunden brauchen um bereit zu werden, kann HPA über-provisionieren, weil bestehende Pods während des Starts überlastet bleiben. Optimiere Readiness Probes und erwäge Startup Probes für langsam startende Anwendungen.

PodDisruptionBudget-Konflikte: Ein PDB der null nicht verfügbare Pods erlaubt, kann das Herunterskalieren blockieren wenn HPA versucht Replicas während einer freiwilligen Unterbrechung zu entfernen. Stelle sicher, dass minAvailable deines PDB kleiner ist als minReplicas deines HPA.

Mehrfach-Metriken-Interaktion: Wenn HPA mehrere Metriken auswertet, berechnet er die gewünschte Replica-Anzahl für jede Metrik unabhängig und wählt den höchsten Wert. Das bedeutet, ein Spike bei einer einzelnen Metrik kann die Skalierung auslösen, selbst wenn andere Metriken niedrig sind.

HPA- und Cluster-Autoscaler-Latenz: HPA erstellt sofort neue Pods, aber wenn kein Node Kapazität hat, bleiben Pods im Pending-Status bis der Cluster Autoscaler neue Nodes bereitstellt (typischerweise 2–5 Minuten bei Cloud-Anbietern). Berücksichtige dies in deiner Skalierungsstrategie.

Object-Metrik vs Pods-Metrik: Verwende den Pods-Typ wenn die Metrik pro Pod gilt (Anfragerate). Verwende den Object-Typ wenn die Metrik von einem einzelnen Kubernetes-Objekt wie einem Ingress stammt.

Zusammenfassung

• HPA skaliert Pod-Replicas automatisch basierend auf CPU-, Speicher-, benutzerdefinierten oder externen Metriken
• Die Skalierungsformel ist gewünschteReplicas = ceil(aktuelleReplicas × aktuelleMetrik / zielMetrik)
• Definiere immer CPU- und Speicher-requests in deinen Containern — HPA funktioniert ohne sie nicht
• Verwende die autoscaling/v2 API für Multi-Metrik-Skalierung und Verhaltensrichtlinien
• Konfiguriere aggressives Hochskalieren und konservatives Herunterskalieren für Produktions-Workloads
• Kombiniere HPA mit Cluster Autoscaler für vollständige elastische Skalierung — vermeide die Kombination von HPA und VPA auf derselben Metrik
• Benutzerdefinierte Metriken via prometheus-adapter ermöglichen Skalierung auf Geschäftsmetriken wie Anfragerate oder Warteschlangentiefe
• Teste deine HPA-Konfiguration unter realistischer Last bevor du dich in der Produktion darauf verlässt

Verwandte Artikel

• Kubernetes Fundamentals: Deploy Your First Cluster
• K3s Lightweight Kubernetes for Homelab
• Docker Compose Practical Guide for Sysadmins
• Terraform Infrastructure as Code Getting Started Guide