Warum Kubernetes-Autoscaling bei KI-Workloads scheitert und wie DRA dies behebt

Kubernetes stützt sich seit langem auf eine klare Trennung zwischen dem Scheduler, der Pods auf bestehenden Nodes platziert, und dem Autoscaler, der neue Nodes hinzufügt, wenn die Kapazität erschöpft ist. Diese Arbeitsteilung funktionierte gut für Standard-Compute-Ressourcen, bricht jedoch unter der Last von KI-Workloads zusammen, die spezifische Accelerator-Topologien erfordern. Stand Oktober 2026 arbeitet die Community aktiv daran, diese Komponenten so umzugestalten, dass sie dieselbe Sprache bezüglich Hardware-Einschränkungen sprechen.

Was passiert ist

Jahrzehntelang basierte die Annahme, dass Compute-Ressourcen weitgehend austauschbar seien, darauf, dass Scheduler und Autoscaler unabhängig voneinander operieren konnten. KI-Beschleuniger wie GPUs sind jedoch keine generischen Ressourcen; ihre Leistung hängt stark davon ab, wie sie mit CPUs, Speicher und anderen GPUs verbunden sind. Ein häufiges Fehlerbild besteht darin, dass Pods im Status "pending" verbleiben, obwohl der Cluster scheinbar Kapazität hat. Der Autoscaler fügt einen Node hinzu, aber der Scheduler lehnt ihn ab, weil die Hardware-Topologie nicht den strengen Lokalitätsanforderungen des Workloads entspricht.

Das Kernproblem liegt darin, dass der Autoscaler nur beantwortet, ob ein Node hinzugefügt werden soll, während die eigentliche Frage lautet, ob der hinzugefügte Node die richtige Form für die Aufgabe hat. Wenn der Autoscaler einen Node provisioniert, ohne die komplexe Verkabelung der Acceleratoren zu verstehen, kann der Scheduler den Pod nicht platzieren. Diese Diskrepanz führt dazu, dass teure Accelerator-Kapazitäten ungenutzt bleiben und kritische Inferenz- oder Trainings-Jobs verzögert werden. Die Cloud Native Computing Foundation (CNCF) betont, dass dies kein hersteller-spezifisches Problem ist, sondern eine grundlegende architektonische Herausforderung im Upstream-Kubernetes.

Um dies anzugehen, bewegt sich die Community hin zu einem gemeinsamen Vokabular für die Hardwarebeschreibung. Historisch behandelte Kubernetes Acceleratoren als einfache Ganzzahl-Zähler. Mit der Einführung von Dynamic Resource Allocation (DRA) können Workloads nun strukturierte Claims einreichen, die nicht nur beschreiben, wie viele Geräte benötigt werden, sondern auch, wie diese Geräte zueinander und zu Netzwerkschnittstellen in Beziehung stehen müssen. Dies ermöglicht sowohl dem Scheduler als auch DRA-bewussten Autoscalern, Kapazitäten anhand derselben detaillierten Kriterien zu bewerten.

Wie es funktioniert

Dynamic Resource Allocation ändert das Ressourcenmodell von einem bloßen Zähler zu einem strukturierten Claim. Anstatt vier GPUs anzufordern, spezifiziert ein Workload, dass es vier GPUs innerhalb desselben NUMA-Domains benötigt, die über Hochbandbreiten-Links verbunden sind. Der Scheduler liest diese Claims direkt, um Platzierungsentscheidungen zu treffen. Entscheidend ist, dass DRA-bewusste Autoscaler beginnen, diese Informationen bei der Simulation potenzieller Kapazitätserweiterungen zu nutzen. So wird sichergestellt, dass der Autoscaler beim Skalieren nach oben Node-Typen auswählt, die tatsächlich die Topologie-Einschränkungen erfüllen, die vom Workload definiert wurden.

Über die Topologie hinaus ermöglicht DRA auch eine feinere Granularität bei der Freigabe von Acceleratoren. Moderne Geräte sind leistungsstark genug, dass die Zuweisung einer gesamten GPU an einen kleinen Job ineffizient ist. DRA unterstützt partitionierbare Geräte, sodass ein einzelnes physisches Accelerator-Gerät in isolierte Instanzen oder verbrauchbare Anteile aufgeteilt werden kann. Mehrere Workloads können gleichzeitig gemessene Teile eines Geräts nutzen. Der Scheduler verfolgt diese fraktionalen Allokationen, und Autoscaler können potenzielle Nodes basierend auf verfügbaren Slices statt nur ganzer Geräte bewerten. Dies reduziert die früher übliche "Alles-oder-nichts"-Verschwendung bei der GPU-Nutzung.

Trotz dieser Fortschritte bleibt eine Lücke beim Gang-Scheduling bestehen, bei dem eine Gruppe von Pods gemeinsam geplant werden muss oder gar nicht. Aktuelle workload-bewusste Scheduling-APIs ermöglichen es dem Scheduler, Pods zurückzuhalten, bis eine vollständige Gruppe platziert werden kann, aber der Autoscaler argumentiert weiterhin podweise. Er provisioniert möglicherweise Teilkapazitäten für einige Mitglieder einer Gang, verschwendet Ressourcen, während der Job auf den Rest wartet. Ein provisorischer Mechanismus namens "Provisioning Request" versucht, dies zu überbrücken, indem er Workloads erlaubt, Gruppenkapazität atomar anzufordern, bleibt aber eher eine nachträgliche Lösung als ein tief integrierter Funktionsumfang.

Wichtige Details

• Topologie zählt: Die Leistung von Acceleratoren hängt von der Lokalität ab, einschließlich CPU-NUMA-Domains, PCIe-Pfaden und Inter-GPU-Links, nicht nur von der Geräteanzahl.
• Dynamic Resource Allocation (DRA): Ersetzt ganzzahlbasierte Ressourcenanfragen durch strukturierte Claims, die Gerätebeziehungen und Netzwerkschnittstellen beschreiben.
• Gemeinsames Vokabular: DRA ermöglicht es sowohl dem Scheduler als auch dem Autoscaler, Hardware-Einschränkungen identisch zu verstehen, was Provisioning-Diskrepanzen reduziert.
• Fraktionale Freigabe: DRA unterstützt partitionierbare Geräte und verbrauchbare Kapazitäten, sodass mehrere Workloads ein einzelnes Accelerator-Gerät effizient teilen können.
• Lücke beim Gang-Scheduling: Während der Scheduler atomare Gruppenplatzierung unterstützt, skaliert der Autoscaler weiterhin podweise, was zu potenzieller Verschwendung bei großen verteilten Jobs führt.
• Zukünftige Integration: SIG-Autoscaling und SIG-Scheduling entwerfen APIs, damit der Scheduler provisionierbare Kapazitäten sehen und explizit anfordern kann.

Warum das wichtig ist

Für Engineering-Teams, die KI-Infrastruktur verwalten, führt diese Diskrepanz direkt zu verschwendetem Budget und langsameren Iterationszyklen. GPU-Stunden sind teuer, und deren Leerlauf aufgrund von Meinungsverschiedenheiten zwischen Scheduling und Provisioning stellt erhebliche operative Kosten dar. Das Verständnis, dass ein "pending" Pod nicht unbedingt auf fehlende regionale Kapazität hindeutet, sondern auf eine Topologie-Mismatch, verändert, wie Teams ihre Cluster debuggen und optimieren. Es verschiebt den Fokus davon, einfach mehr Nodes hinzuzufügen, hin zur Sicherstellung, dass die hinzugefügten Nodes mit den strukturellen Bedürfnissen des Workloads kompatibel sind.

Darüber hinaus bedeutet der Trend zum integrierten Design, dass zukünftige Kubernetes-Funktionen Autoscaling-Implikationen von Anfang an berücksichtigen werden. Anstatt Autoscaling-Unterstützung nachträglich zu ergänzen, nachdem eine neue Scheduling-Primitive veröffentlicht wurde, baut die Community Schnittstellen, die beiden Kontrollschleifen proaktive Koordination ermöglichen. Diese Evolution ist entscheidend für die Unterstützung von bursty Inferenz- und agentischen Workloads, die die Latenz von Cold Starts oder falsch provisionierten Nodes nicht tolerieren können. Teams, die heute Acceleratoren betreiben, haben ein Interesse an diesen Upstream-Diskussionen, da die daraus resultierenden Standards die Effizienz ihrer Infrastruktur für die kommenden Jahre definieren werden.

Was Sie tun können

• Pending Pods prüfen: Überprüfen Sie, ob "pending" GPU-Pods auf Topologie-Mismatches zurückzuführen sind und nicht auf echte Kapazitätserschöpfung.
• DRA adoptieren: Migrieren Sie Workloads zur Nutzung von Dynamic Resource Allocation Claims, um Topologie- und Sharing-Anforderungen explizit auszudrücken.
• Workload-aware Scheduling aktivieren: Testen Sie die Beta-Versionen der Workload- und PodGroup-APIs, um das Gang-Scheduling-Verhalten zu verbessern, beachten Sie jedoch, dass diese standardmäßig deaktiviert sind.
• Autoscaler-Kompatibilität evaluieren: Verifizieren Sie, ob Ihre aktuelle Autoscaler-Implementierung DRA-bewusst ist und Topologie-Einschränkungen während des Scale-ups simulieren kann.
• Fragmentierung überwachen: Verfolgen Sie GPU-Nutzungsmetriken, um Verschwendung durch "Alles-oder-nichts"-Zuweisungen zu identifizieren, und erwägen Sie die Aktivierung der fraktionalen Freigabe.
• Mit SIGs engagieren: Nehmen Sie an Diskussionen von SIG-Autoscaling und SIG-Scheduling teil, um das Design kommender Integrations-APIs zu beeinflussen.