Kubernetes Autoscaling in der Praxis — HPA, VPA und Cluster Autoscaler

Kubernetes kann skalieren. Aber Autoscaling richtig zu konfigurieren, damit es auf reale Last reagiert, keine Ressourcen verschwendet und unter Spitzenlast nicht zusammenbricht — das ist eine Kunst.

Drei Ebenen des Autoscalings¶

• HPA — fügt Pods hinzu/entfernt sie (für Stateless Services)
• VPA — ändert CPU/RAM-Limits von Pods (für Monolithen)
• Cluster Autoscaler — fügt Nodes hinzu/entfernt sie

Custom Metriken statt CPU¶

Standard-HPA skaliert nach CPU, aber das reicht nicht. Über den Prometheus Adapter haben wir Requests/sec, Latenz p95 und Queue Depth hinzugefügt. Jetzt skaliert HPA auf Basis dessen, was wirklich zählt.

Overprovisioning für schnelles Scale-Up¶

Ein neuer AKS-Node braucht 3–5 Minuten. Lösung: Wir halten einen „leeren” Node mit Pause-Containern vor, sofort verfügbar für reale Workloads. Der Cluster Autoscaler fügt einen neuen Node im Hintergrund hinzu.

Spot Instances — 60–80% Ersparnis¶

Für fehlertolerante Workloads (Batch, CI/CD, Dev) nutzen wir Azure Spot VMs in einem dedizierten Node Pool. Produktion immer auf On-Demand.

Größter Fehler: Falsche Resource Requests¶

Entwickler setzten 2 CPU und 4 GB RAM „zur Sicherheit”. Reale Auslastung 15%. Der Cluster Autoscaler fügte unnötig Nodes hinzu. Lösung: VPA im Recommendation Mode.

Autoscaling erfordert Investition¶

Es ist kein „einrichten und vergessen”. Richtige Metriken, realistische Requests und kontinuierliches Tuning — aber die Belohnung ist ein System, das Spitzen automatisch bewältigt.