Wie KI-Workloads das Kubernetes-Autoscaling neu gestalten

GPU-Teams stehen vor einem schlechten Kompromiss: ein Control Plane pro Team oder schwache Isolation in einem gemeinsamen Cluster. Dieses reproduzierbare Labor kombiniert Kamaji (Control Planes als Pods) und HAMi (fraktionierte GPUs) auf einer einzigen Maschine ohne GPU, unter Verwendung von HAMis Mock-Device-Plugin.

Kubernetes hat lange Zeit einen Großteil der containerisierten Software weltweit auf einer Arbeitsteilung zwischen zwei Kontrollschleifen betrieben, die selten miteinander kommunizieren mussten. Der Scheduler platziert jeden Pod auf einem bereits existierenden Knoten; der Cluster-Autoscaler fügt Knoten hinzu, wenn Pods keinen Platz finden.

Ein Jahrzehnt lang war diese Trennung solide: Rechenleistung war weitgehend austauschbar, und beide Schleifen konnten arbeiten, ohne viel über die Entscheidungen der jeweils anderen zu wissen. KI-Workloads – und die Beschleuniger, auf denen sie laufen – haben die Bedingungen verändert.

Das Szenario, das jeder kennt, der GPUs betreibt

Ein Pod, der eingeplant werden sollte, wird es einfach nicht – obwohl der Cluster nicht wirklich an Kapazitätsgrenzen stößt. Die Verzögerung lässt teure Beschleunigerkapazität ungenutzt. Der Instinkt sagt einem, man solle annehmen, die Region sei ausgeschöpft – und manchmal ist sie das auch. In anderen Fällen ist die Kapazität verfügbar und der Pod bleibt trotzdem ausstehend, weil der Knoten, den der Autoscaler hinzufügen möchte, nicht einer ist, den der Scheduler nutzen will.

Der Autoscaler beantwortet die Frage, für die er gebaut wurde – ob ein Knoten hinzugefügt werden soll –, während die eigentliche Frage ist, ob dieser Knoten überhaupt die richtige Form für die Arbeit hat.

Die harten Probleme und wie die Community sie beantwortet

Mehrere Herausforderungen, die Beschleuniger mit sich bringen, haben einen gemeinsamen Nenner: etwas, das beide Schleifen jetzt auf dieselbe Weise verstehen müssen. Drei zeigen, wie weit die gemeinsamen Antworten gekommen sind.

Reservierungen: Kapazität, die vor dem Eintreffen der Arbeit gebunden wird

Da das Angebot knapp und ungenutzte Beschleuniger teuer sind, reservieren Teams Kapazität im Voraus. Wenn eine Skalierung aus einer Reservierung schöpft, muss der Autoscaler nicht nur berücksichtigen, ob er wachsen soll, sondern auch, ob der resultierende Knoten Kapazität nutzt, für die das Team bereits zahlt. Das Starten gegen gebundene Kapazität statt gegen unreserviertes Angebot verändert die Kostenkalkulation, die der Autoscaler optimiert.

Topologie: Das Verbindungsnetz zwischen Geräten, nicht nur ihre Anzahl

Topologie dreht sich darum, wie Geräte miteinander verdrahtet sind, nicht darum, wie weit sie voneinander entfernt sitzen. Ein Beschleuniger stützt sich auf die Teile, die ihn versorgen – die CPU und den Speicher in seiner lokalen NUMA-Domäne, die Netzwerkschnittstelle, die seinen PCIe-Pfad teilt, die Hochbandbreiten-Verbindungen zu seinen Peer-Beschleunigern. Er läuft am besten, wenn diese Teile lokale Nähe teilen, sodass Datenverkehr keinen langsameren Hop überqueren muss.

Diese Lokalität ist eine Hierarchie: Geräte auf demselben Bus innerhalb eines Servers, Server in einem Rack, verbunden durch ein schnelles Beschleuniger-Fabric, Racks, die über ein Rechenzentrumsnetzwerk verbunden sind. Die größten Modelle erstrecken sich gleichzeitig über viele Server, sodass „diese nahe beieinander halten“ über einen einzelnen Knoten hinausreicht.

Historisch stellte Kubernetes Beschleunigerressourcen als bloße Zählwerte dar: Ein Knoten warb mit einer Zahl, ein Pod fragte nach einigen, und der Scheduler matchte zwei Ganzzahlen. Dynamic Resource Allocation (DRA) liefert, was fehlte – ein Workload reicht einen strukturierten Anspruch ein, der beschreibt, was er benötigt, einschließlich Beziehungen wie ein Beschleuniger zusammen mit der Netzwerkschnittstelle, die ihn versorgt. Der Scheduler liest Ansprüche direkt, und DRA-bewusste Autoscaler beginnen, dieselben Informationen zu nutzen, wenn sie Kapazität simulieren, obwohl die Unterstützung je nach Implementierung variiert.

Die Kosten einer blinden Grenze

Ein DRA-bewusster Autoscaler kann die Einschränkungen berücksichtigen, die der Workload deklariert hat. Wo er das nicht kann, erzeugt die Trennung zwischen Scheduling und Skalierung genau den oben genannten Fehlermodus – der Autoscaler stellt Kapazität bereit, die der Scheduler dann ablehnt, oder unterdimensioniert, weil er nicht sehen kann, was der Anspruch wirklich erfordert.

Die Entwicklung ist klar: Der Cluster-Autoscaler wächst von einem „Wie viele Knoten“-Beantworter zu einem scheduler-bewussten Partner, der Form versteht – Reservierungen, Verbindungstopologie und strukturierte Geräteansprüche –, bevor er Geld für Kapazität ausgibt.

Fazit

KI hat die Scheduler/Autoscaler-Trennung nicht gebrochen; sie hat aufgedeckt, wo die Abstraktion die ganze Zeit undicht war. Reservierungen, Topologie und DRA sind die drei Fronten, an denen beide Schleifen lernen, dasselbe Modell der Maschine zu teilen. Wenn Sie Beschleuniger auf Kubernetes betreiben, wird hier die interessante Kapazitätsverwaltungsarbeit in den nächsten Releases stattfinden – und wo häufige Schmerzen wie „ausstehende Pods auf einem gesunden Cluster“ ihre echte Lösung bekommen. Beobachten Sie das DRA-Ökosystem und Autoscaler-Implementierungen, die topologiebewusste Kapazität simulieren können.