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:
- Messen: Kennzahlen der Pods über die Metrik-Schnittstelle abrufen.
- Vergleichen: Ist-Werte gegen die Zielwerte stellen.
- Rechnen: gewünschte Replikatzahl ermitteln.
- 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.