Das Problem der Autoskalierung bei GPU-Workloads besteht möglicherweise nicht darin, dass Kubernetes die Entscheidung nicht trifft, sondern darin, dass die Entscheidung zu spät eintrifft. Ramkumar Nagaraj und Bingi Narasimha Karthik von Adobe beschreiben einen Vorfall, bei dem ein kritischer Produktionsdienst von einer Bedarfsspitze betroffen war, die die Fehlerraten für Nutzer auf 15–20% erhöhte, obwohl der Horizontal Pod Autoscaler mit der Skalierung begonnen hatte. Der Grund war, dass Hunderte Container weiterhin in der Warteschlange blieben, während die neuen GPU-Nodes lange benötigten, bis sie bereit waren.
In der von den Autoren dokumentierten Abfolge traf die Bedarfsspitze um 06:00 Uhr ein, überschritten die HPA-Metriken um 06:05 Uhr den Schwellenwert, und um 06:15 Uhr begann die Planung der Container. Die ersten GPU-Nodes waren jedoch erst um 06:45 Uhr vollständig bereit, also nachdem die Spitze bereits vorüber war. Die Bereitstellung von GPU-Nodes dauert aufgrund des Ladens der Firmware, der Treiberinitialisierung und der CUDA-Vorbereitung üblicherweise drei- bis fünfmal so lange wie die Bereitstellung CPU-basierter Dienste.
Von der Reaktion auf den Bedarf zur Vorbereitung darauf
Das Team schlug vor, innerhalb von Kubernetes alle 60 Sekunden einen Controller auszuführen, der eine Stunde vergangener Metriken einliest und den Bedarf für zehn Minuten später prognostiziert. Ziel ist nicht eine perfekte Vorhersage, sondern die Kapazitätsbereitstellung so früh vor der Spitze zu beginnen, dass Nodes und Container bei Bedarf bereit sind.
Der Entwurf nutzte die von Prometheus erfassten Daten, darunter CPU- und Speichernutzung, Antwortzeit, Anfragerate und GPU-Auslastung. Das Team testete ARIMA-Modelle, exponentielle Glättung, die Prophet-Bibliothek und LSTM, bevor es ein aus zwei Schichten mit jeweils 64 und anschließend 32 Einheiten bestehendes Bi-LSTM-Modell auswählte. Die Wahl erfolgte laut dem Beitrag als Reaktion auf Datenmuster mit kurzen Spitzen, Erholungsphasen und ungewöhnlich konstanten Werten, nicht weil es in jedem Fall theoretisch die beste Option wäre.
Das Modell wird wöchentlich neu trainiert, während das bereitgestellte Modell ausschließlich im Inferenzmodus innerhalb einer in Go geschriebenen Controller-Binärdatei unter Verwendung von TensorFlow Lite läuft. Dadurch benötigt der Entwurf weder eine externe Machine-Learning-Plattform noch eine Model-Serving-Schicht.
Drei Schichten zur Steuerung der Skalierung
Der Entwurf basiert auf drei miteinander verbundenen Funktionen: Prognose, Bereitstellung und Abfederung. Das Modell prognostiziert den Bedarf, anschließend beginnt der Controller, die Anzahl der Replikate schrittweise zu erhöhen, während die vorab bereitgestellte Kapazität Raum zur Aufnahme der tatsächlichen Spitze bietet.
Da die Prognose nicht jede Überraschung bewältigen kann, fügte das Team parallel einen Detektor für plötzliche Anstiege hinzu. Diese Komponente vergleicht den tatsächlichen Bedarf anhand eines adaptiven Schwellenwerts auf Grundlage einer gleitenden Standardabweichung mit den Prognosen. Überschreitet der Bedarf die Prognose um eine Differenz, die das festgelegte Konfidenzniveau erreicht, erhöht der Detektor die Skalierungsgeschwindigkeit. Die Autoren beschreiben diese Komponente als inferenzielles Sicherheitsnetz, nicht als zweites Prognosemodell.
Der schrittweise Scaler begrenzt den Zuwachs auf 20 Container pro Minute. Damit soll eine massive Planungswelle verhindert werden, die den Scheduler und etcd belastet und zu einer Überlastung beim Abruf von Images, beim Starten von Containern, bei der Initialisierung von Init-Containern und beim Injizieren von Sidecar-Containern führt. Außerdem wurde die Zielauslastung auf 70% statt 100% festgelegt, um Spielraum für die Abfederung von Spitzen zu lassen und gelegentliche Ungenauigkeiten des Modells zu ermöglichen, ohne dass der Fehler in eine Kaskade von Ausfällen übergeht.
Was haben die Tests gezeigt?
Das Team betrieb das System zunächst im Schattenmodus, sodass Prognosen aufgezeichnet wurden, ohne eine tatsächliche Skalierung auszuführen, und sammelte mehr als 500 Stunden Daten. Die Ergebnisse zeigten eine Genauigkeit von 85%, wenn die Prognose des Bedarfs zehn Minuten später innerhalb einer Abweichung von ±10% des tatsächlichen Bedarfs lag. Der Spitzendetektor erfasste außerdem neun von zehn Spitzen mit zwei Fehlalarmen, während die Tests des schrittweisen Scalers weder kaskadierende Ausfälle noch ein Schwanken der Skalierung zeigten.
Das System lief außerdem neben HPA v2 ohne Konflikte. Während einer einwöchigen Validierung in einer kontrollierten Entwicklungsumgebung bestand es 23 von 23 Tests. In einer Simulation der Spitzenmuster, die den ursprünglichen Vorfall verursacht hatten, konnte das System die Spitze etwa 11 Minuten im Voraus erkennen.
Wann ist dieser Ansatz geeignet?
Der Wert der prädiktiven Skalierung zeigt sich, wenn die Bereitstellung von Nodes länger als zwei oder drei Minuten dauert und der Bedarf teilweise vorhersehbar ist, etwa bei täglichen oder wöchentlichen Mustern oder bekannten Ereignissen. Außerdem sind gute Monitoringdaten erforderlich, mit mindestens einer Woche an Prometheus-Metriken. Weniger sinnvoll wird der Ansatz dagegen, wenn Nodes innerhalb von 30 Sekunden bereitstehen, der Bedarf völlig zufällig ist oder die Priorität des Teams vor allem auf der Kostensenkung liegt; das Bereithalten warmer Nodes bedeutet, für Reservekapazität zu zahlen.
Redaktionelle Einordnung: Die praktische Veränderung besteht hier nicht darin, HPA zu ersetzen, sondern einer Infrastruktur, die normalerweise erst nach dem Auftreten des Bedarfs reagiert, Vorhersagezeit hinzuzufügen. Ihre Bedeutung zeigt sich insbesondere bei GPU-Workloads, bei denen eine schnelle Skalierungsentscheidung nicht ausreicht, wenn die Infrastruktur vor dem Start der Container mehrere Dutzend Minuten benötigt. Die präsentierten Belege stammen jedoch weiterhin aus einer kontrollierten Validierung und nicht aus einer unabhängigen, groß angelegten Messung in mehreren Produktionsumgebungen.
Auch die Erfahrung des Teams weist auf wichtige Einschränkungen hin: Ein abgestimmtes ARIMA-Modell könnte mit einer einfacheren Architektur ein ähnliches Ergebnis erzielen, und das Modell kann innerhalb weniger Tage veralten, wenn sich die Bedarfsmuster ändern. Außerdem blieb schwer erklärbar, warum eine bestimmte Anzahl von Replikaten vorhergesagt wurde. Fragen zur optimalen Datenmenge, zur Häufigkeit des Neutrainings und zur Fähigkeit des inferenziellen Spitzendetektors, beispiellose Ereignisse zu erkennen, sind ebenfalls noch nicht abschließend geklärt.
Daher empfiehlt der Beitrag, mit einer einwöchigen Sammlung von Metriken zu beginnen, ein einfaches Modell zu trainieren, es im Schattenmodus zu betreiben und anschließend die Genauigkeit vor der Aktivierung der Skalierung zu messen. Beim Übergang in die Produktion sollten ein maximales Replikatlimit und eine klare Deaktivierungsprozedur festgelegt werden; vorzugsweise sollte zunächst eine Phase mit begrenzter Skalierung durchlaufen werden, bevor der vollständige Spielraum freigegeben wird. Die von den Autoren wiederholte Schlussfolgerung ist praktisch: Die Komplexität des Modells ist an sich kein Vorteil. Wenn die einfachere Lösung erfolgreich ist, sollte sie betrieben werden.