Lastspitzen Ohne Pending-Pods: So Skaliert Kubernetes Von Selbst

Ein ruhiger Cluster bei einer Lastspitze ist eine Designentscheidung, kein Glück. Das Muster ist einfach: Pods skalieren nach Bedarf, und der Cluster fügt die nötigen Nodes innerhalb von Minuten hinzu. Dieser Leitfaden gibt Ihnen einen Selbsttest in zwei Minuten und die vier Schritte, die wir verwenden. Er basiert auf einem echten Projekt mit einer Echtzeit-Datenplattform, deren Last innerhalb von Minuten um Millionen Anfragen springt.

Selbsttest in zwei Minuten

Beantworten Sie ehrlich:

1. Finden neue Pods bei doppelter Last einen Node, oder warten sie im Status Pending?
2. Basieren die Pod-Requests auf gemessener Nutzung, zum Beispiel dem 95. Perzentil, oder auf einer Schätzung?
3. Fügt der Cluster selbst Nodes hinzu, und wie lange dauert es, bis neue Pods laufen?
4. Erhalten Sie einen Alarm, wenn Pods in Pending bleiben?
5. Welcher Teil Ihrer Kapazität kann bei einer Unterbrechung auf Spot-Instanzen laufen?

Wenn Sie vier oder mehr beantworten können, sind Sie gut aufgestellt. Jede Antwort, die Sie nicht geben können, ist eine Stelle, an der Sie eine Lastspitze noch überraschen kann.

Das Muster, das funktioniert

Pods zu skalieren ist nur die halbe Autoskalierung. Sind die Nodes voll, warten neue Pods und der Verkehr staut sich. Der Cluster muss auf das reagieren, was tatsächlich in Pending steht, nicht auf eine Prognose.

Der Plan in vier Schritten

1. Requests anpassen. Setzen Sie CPU- und Speicher-Requests nach gemessener Nutzung, am 95. Perzentil. Im Projekt entfiel damit eine Überprovisionierung, die rund 60% der Kapazität gebunden hatte, und der Autoscaler bekommt ein ehrliches Bild.
2. Cluster Autoscaler einsetzen. Er beobachtet Pending-Pods, fügt Nodes hinzu, wenn sie nicht eingeplant werden können, und entfernt ungenutzte Nodes. Mit Pod Disruption Budgets bleibt das Herunterskalieren sanft.
3. Node-Pools mischen. Reservierte Kapazität für die stabile Grundlast, Spot-Instanzen für Lastspitzen, verteilt über mehrere Instanztypen, um das Unterbrechungsrisiko zu senken.
4. Beobachten und üben. Alarm bei Pending-Pods, Zeiten für Hoch- und Herunterskalieren verfolgen und testen, was bei einer Spot-Unterbrechung passiert.

So sah es in der Praxis aus

Nach der Umstellung liefen Pods 2 bis 3 Minuten nach Beginn einer Lastspitze, und der Cluster skalierte etwa 10 Minuten nach deren Ende wieder herunter. Anfragen laufen nicht mehr wegen fehlender Kapazität in Timeouts, niemand skaliert Nodes von Hand und die Konfiguration ist einfaches YAML. Details: die Fallstudie.

Nächster Schritt

Machen Sie heute den Selbsttest. Zeigt er Lücken, buchen Sie einen Termin und wir schauen gemeinsam auf Ihren Cluster.