Kubernetes Node Autoscaling: Bewältigung unvorhersehbarer Traffic-Spitzen ohne manuelle Intervention

Das Problem

Eine Echtzeit-Datenplattform verarbeitete unvorhersehbare Traffic: Wahlupdates, Breaking News, Marktankündigungen erzeugten plötzliche Spitzen von Millionen von Anfragen in Minuten. Das Team versuchte, Horizontal Pod Autoscaler (HPA) zu verwenden, um Repliken zu skalieren, aber es funktionierte nicht.

Warum? HPA skalierte Pods, aber der Cluster hatte keinen Platz, um sie zu platzieren. Neue Pods blieben “Pending” stecken, weil Knoten voll waren. Traffic wurde in die Warteschlange eingereiht, Clients endeten mit Timeout. Das Problem war nicht “wie viele Pods” — es war “wie viele Knoten.”

Die Herausforderung

Alle traditionellen Autoscaling-Ansätze sind fehlgeschlagen:

• Nur HPA funktioniert nicht — skaliert Pod-Anzahl, aber Cluster hat keine Kapazität
• Manuelle Node-Skalierung — widerlegt den Zweck von Kubernetes, kann Spitzen nicht vorhersagen
• Vertical Pod Autoscaler — ändert Request-Größen, löst das “kein Platz”-Problem nicht
• Overprovisioning — Extra-Knoten für “nur für den Fall” kaufen ist verschwenderisch und teuer
• Unvorhersehbarkeit — Traffic-Spitzen sind zufällig; können nicht vorhersagen, wann sie auftreten

Die Lösung

Wir haben Cluster Autoscaler mit korrekter Pod-Request-Größenbestimmung implementiert:

Phase 1: Pod-Request-Größenbestimmung

• Analysierte tatsächliche Ressourcennutzung über alle Workloads
• CPU/Memory-Requests basierend auf 95. Perzentil beobachteter Nutzung gesetzt (nicht Vermutungen)
• Overprovisioning entfernt, das 60% Kapazität verschwendete
• Pod Disruption Budgets für sichere Skalierung nach unten konfiguriert

Phase 2: Cluster Autoscaler

• Cluster Autoscaler bereitgestellt, um auf Pending Pods zu überwachen
• Autoscaling konfiguriert, um Knoten hinzuzufügen, wenn Pods nicht geplant werden können
• Auto-Knoten-Entfernung, wenn sie untätig sind
• Integration mit Cloud-Provider-Skalierungsgruppen (AWS, GCP, Azure)

Phase 3: Skalierungsgruppen & Instanztypen

• Separate Node-Pools für verschiedene Workload-Typen erstellt
• Reserved Instances für Baseline-Kapazität (immer benötigt)
• Spot Instances für burstbare Workloads (verwaltet Spitzen kostengünstig)
• Mixed-Fleet-Strategie zur Reduzierung des Unterbruchungsrisikos

Phase 4: Überwachung & Sicherheit

• Benachrichtigung über Pending Pods (zeigt unzureichende Kapazität an)
• Verfolgung von Scale-Up/Scale-Down-Ereignissen und Timing
• Test-Failover für Spot-Instance-Unterbrechungen
• Dokumentation des Skalierungsverhaltens für das Team

Ergebnisse

Traffic-Handling:

• ✅ Traffic-Spitzen skalieren Cluster automatisch (keine Pending Pods)
• ✅ Scale-Up-Zeit: Pods laufen innerhalb von 2-3 Minuten nach Spike-Start
• ✅ Scale-Down-Zeit: 10 Minuten nach Spike-Ende (elegant)
• ✅ Keine Request-Timeouts aufgrund von Kapazität (zuvor häufig)

Betrieb:

• ✅ Keine manuelle Node-Skalierung erforderlich
• ✅ Skalierung ist vorhersehbar und nachvollziehbar
• ✅ Team-Vertrauen in die Bewältigung von unerwarttem Traffic
• ✅ Einfache Konfiguration (YAML-basiert, kein Custom-Code)

Finanziell:

• ✅ Kosten reduziert vs. manuelle Overprovisioning
• ✅ Spot Instances reduzieren Baseline-Kosten 60-70%
• ✅ Reserved Instances bieten stabile Baseline
• ✅ Keine “nur für den Fall”-Overprovisioning, die Geld verschwendet

Wichtige Erkenntnisse

1. HPA löst Pod-Level-Skalierung, nicht Cluster-Level-Kapazität — Sie brauchen beides
2. Korrekte Pod-Requests sind die Grundlage — ohne sie, kann Autoscaling nicht richtig funktionieren
3. Cluster Autoscaler ist einfach und effektiv — Open Source, Cloud-agnostisch, überwacht nur Pending Pods
4. Spot Instances sind sicher — mit korrekten Disruption Budgets und Mixed-Fleet-Strategie
5. Unvorhersehbare Workloads skalieren trotzdem gut — wenn das System auf tatsächliche Nachfrage reagiert (Pending Pods), nicht vorhergesagte Nachfrage