Der Horizontal Pod Autoscaler (HPA) passt die Anzahl der Pods eines Workloads automatisch an die aktuelle Last an. Er ist das Standardwerkzeug in Kubernetes, um bei schwankender Nachfrage weder zu viele Ressourcen zu binden noch unter Last in Rückstand zu geraten.

Wie der Regelkreis arbeitet

Der Autoscaler ist ein Regelkreis mit vier Schritten, der standardmäßig alle 15 Sekunden läuft:

  1. Messen: Kennzahlen der Pods über die Metrik-Schnittstelle abrufen.
  2. Vergleichen: Ist-Werte gegen die Zielwerte stellen.
  3. Rechnen: gewünschte Replikatzahl ermitteln.
  4. Setzen: die Replikatzahl des Ziels anpassen – meist ein Deployment oder StatefulSet.

Die Berechnung ist einfach: gewuenscht = ceil(aktuell * ist_wert / ziel_wert). Steht der Zielwert für CPU bei 50 % und die Pods liegen im Mittel bei 100 %, verdoppelt sich die Zahl. Liegen sie bei 25 %, wird halbiert.

Einrichtung

# Imperativ (zum Ausprobieren)
kubectl autoscale deployment webapp --cpu-percent=60 --min=2 --max=10

# Deklarativ (empfohlen)
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: webapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: webapp
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: "150"
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300     # 5 Minuten Ruhe vor dem Verkleinern
      policies:
        - type: Percent
          value: 50
          periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
        - type: Percent
          value: 100
          periodSeconds: 30

Voraussetzungen

  • Metrik-Server oder Adapter. Für CPU und Speicher braucht der Cluster den metrics-server. Für eigene Kennzahlen (Anfragen pro Sekunde, Warteschlangenlänge) ist ein Adapter nötig, der die Metrik-Schnittstelle bedient – häufig über eine Prometheus-Anbindung.
  • Ressourcenanforderungen gesetzt. Prozentwerte beziehen sich auf die Anforderung (requests) eines Containers. Fehlt sie, kann der Autoscaler nicht rechnen und meldet unknown.

Warum CPU oft das falsche Signal ist

Ein Autoscaler reagiert nur, wenn die gemessene Kennzahl steigt. Eine Anwendung, die auf Anfragen mit Warten auf eine Datenbank reagiert, verbraucht dabei kaum CPU – die Last wächst, die Pods skalieren nicht. Für solche Dienste sind eigene Kennzahlen deutlich besser: Anfragen pro Sekunde, Auslastung der Warteschlange oder Antwortzeit. Der Autoscaler unterstützt das über die Pods-, Object- und External-Metriktypen.

Zusammenspiel und Grenzen

  • Cluster-Autoscaler: Der HPA kann nur Replikate erhöhen, wenn irgendwo Platz ist. Der Cluster-Autoscaler ergänzt ihn, indem er Knoten hinzufügt, wenn Pods nicht eingeplant werden können.
  • Vertikaler Autoscaler: Passt die Ressourcenanforderungen je Pod an. Nicht mit dem HPA auf derselben Kennzahl kombinieren – sonst schaukeln sich beide auf.
  • Nicht alles skaliert. Zustandsbehaftete Dienste, Datenbanken und Anwendungen mit langem Startvorgang sind für automatisches Skalieren meist ungeeignet. Ein Pod, der zwei Minuten zum Starten braucht, hilft bei einer Sekundenspitze nicht.
  • PDB beachten: Ein Pod Disruption Budget kann das Verkleinern blockieren, wenn die Anforderung an die Mindestzahl höher liegt als die Zielzahl.

Nachsehen, was passiert

kubectl get hpa -A
kubectl describe hpa webapp-hpa
kubectl get events --field-selector involvedObject.kind=HorizontalPodAutoscaler

# Typische Zustandsanzeigen:
#   TARGETS  cpu: 45%/60%     -> unter Ziel, stabil
#   TARGETS  cpu: <unknown>/60% -> Metriken fehlen (metrics-server/requests)
#   FAILED   failed to get cpu utilisation -> Container ohne requests

Richtwerte für den Start

  • Mindestens zwei Replikate, nie eines – sonst fällt die Verfügbarkeit während des Skalierens weg.
  • Zielwert bei CPU nicht zu knapp wählen: 60 bis 70 % geben dem Regelkreis Spielraum, ohne dauerhaft auf Höchstlast zu laufen.
  • Verkleinerungsfenster von einigen Minuten setzen. Ohne Verzögerung folgt die Zahl den Messspitzen und schwingt dauerhaft.
  • Obergrenze realistisch bemessen. Zehnfache Verdopplung klingt gut, sprengt aber jede Kapazitätsplanung und die Kosten.

Verwandte Grundlagen: Kubernetes, Pod Disruption Budget, Autoscaling, Kubernetes.