GPU-Resource-Pooling und -Scheduling in Kubernetes

GPU-Resource-Pooling in Kubernetes bedeutet, eine Reihe physischer Beschleuniger in verwaltete Kapazität zu verwandeln, die Workloads per Richtlinie anfordern können, statt einzelne Server manuell auszuwählen. Kubernetes stellt die grundlegende Geräte-Scheduling-Schicht bereit, während ein vollständiges KI-Scheduling-Modell üblicherweise Ressourcenklassen, Job-Queues, Quotas, Topologieregeln, Health-Awareness und Resource Reclamation hinzufügt.

Der entscheidende Unterschied liegt zwischen "Kubernetes kann eine GPU sehen" und "die Organisation kann einen GPU-Pool betreiben". Ersteres ist ein Geräteintegrationsproblem. Zweites ist ein Ressourcenmanagement-Problem.

Wie sieht Kubernetes eine GPU?

Kubernetes sieht spezialisierte Geräte durch Integrationen, die diese Geräte dem kubelet und dem Scheduler bekanntgeben.

Der traditionelle Mechanismus ist das Device-Plugin-Framework. Ein Vendor-Plugin entdeckt unterstützte Geräte auf einem Node und meldet die entsprechende Ressourcenkapazität. Ein Pod kann diese Ressource anfordern, und Kubernetes scheduled den Pod auf einen Node mit ausreichend verfügbarer Kapazität.

Die Kubernetes-Dokumentation listet GPU-Scheduling-Unterstützung über Device Plugins auf und beschreibt das Device-Plugin-Framework seit Kubernetes 1.26 als stabil.

Neuere Cluster können auch Dynamic Resource Allocation nutzen.

DRA gibt Workloads eine reichhaltigere Möglichkeit, Geräte anzufordern, und erlaubt Treibern, Geräteeigenschaften und Allokationsverhalten zu beschreiben. Seit Kubernetes 1.35 ist das Haupt-DRA-Feature als stabil dokumentiert und standardmäßig aktiviert.

Der wichtige praktische Punkt ist, dass Kubernetes weiterhin auf Vendor-Treiber und Geräteintegration angewiesen ist.

Es entdeckt nicht jeden existierenden Beschleuniger ohne Hilfe.

Lesen Sie für eine heterogene Umgebung wie man Multi-Vendor-GPUs und -NPUs verwaltet, bevor Sie den Pool entwerfen.

Was ist ein GPU-Resource-Pool?

Ein GPU-Resource-Pool ist ein logischer Vorrat an Beschleuniger-Kapazität, der nach gemeinsamen Regeln verwaltet wird.

Die physischen Karten können sich in verschiedenen Nodes befinden. Sie können unterschiedliche Modelle sein. Manche sind vielleicht vollständige Karten. Manche sind vielleicht partitioniert. Manche gehören vielleicht zu einem Trainings-Cluster, während andere für Inferenz reserviert sind.

Der Resource-Pool schafft eine Management-Schicht oberhalb einzelner Geräte.

Statt einem Nutzer zu sagen "Lauf auf Server 27, GPU 3", kann die Plattform eine Ressourcenklasse anbieten wie "vier High-Memory-Trainings-GPUs".

Der Scheduler wählt dann geeignete Geräte aus.

Ein nützlicher Pool verfolgt mindestens fünf Dinge:

Welche Ressourcen existieren
Welche Ressourcen verfügbar sind
Welche Ressourcen gesund sind
Welche Workloads sie nutzen dürfen
Wie Ressourcen nach der Nutzung zurückgewonnen werden

Ohne diese Kontrollen ist "Pooling" meist nur ein Dashboard-Label.

Was ist der Unterschied zwischen Device Scheduling und Job Scheduling?

Device Scheduling entscheidet, wo ein Pod laufen kann. Job Scheduling entscheidet, wann ein größerer Workload zugelassen werden soll und wie knappe Kapazität zwischen konkurrierenden Jobs geteilt wird.

Diese Unterscheidung ist für KI wichtig.

Ein verteilter Trainings-Job braucht möglicherweise viele Pods und viele GPUs gleichzeitig. Nur einen Teil des Jobs zu starten, kann nutzlos sein.

Eine Plattform braucht möglicherweise auch Tenant-Quotas, Queue-Prioritäten, Borrowing-Regeln und Preemption.

Das Kubernetes-Core-Scheduling konzentriert sich auf das Platzieren von Pods.

Kueue ist ein Kubernetes-natives Projekt, das für Job Queueing und Resource Admission konzipiert ist. Es kann Quotas und Sharing für Batch-, HPC- und KI-Workloads verwalten und unterstützt Resource Flavors für unterschiedliche Hardware-Typen.

Das bedeutet, eine gängige Architektur sieht so aus:

Kubernetes übernimmt Node- und Pod-Scheduling.
Vendor-Plugins oder DRA-Treiber legen Beschleuniger-Geräte offen.
Kueue oder ein anderer Batch-Scheduler übernimmt Queueing und Quota-Admission.
Die Operations-Schicht liefert Health, Topologie, Kosten und Business-Kontext.

Diese Schichten sollten zusammenarbeiten, statt sich gegenseitig zu duplizieren.

Wie sollten GPU-Ressourcenklassen gestaltet werden?

GPU-Ressourcenklassen sollten Fähigkeiten beschreiben, die für den Workload relevant sind, nicht nur den Marketingnamen der Karte.

Eine nützliche Klasse könnte Speichergröße, Beschleuniger-Familie, Anzahl, Topologie, Sharing-Modus, CPU und Systemspeicher kodieren.

Eine Plattform kann zum Beispiel separate Klassen für großes verteiltes Training, kleineres Training, dediziertes Inferenz, geteiltes Inferenz und Entwicklung definieren.

Erstellen Sie nicht zu viele Klassen.

Wenn Nutzer vor 40 fast identischen Optionen stehen, ist die Abstraktion gescheitert.

Gleichzeitig sollten Sie keine Einschränkung verbergen, die den Erfolg des Workloads beeinflusst. Wenn ein Modell nur auf einem bestimmten Software-Stack läuft, muss die Klasse diese Kompatibilität bewahren.

Resource Flavors sind hier nützlich.

Kueue kann verschiedene Versionen einer Ressource darstellen, etwa unterschiedliche GPU-Modelle, und diesen Flavors Quotas zuweisen.

DRA kann Geräteeigenschaften ebenfalls zu einem Teil des Allokationsmodells machen.

Das Ergebnis ist eine Benutzeroberfläche, die einfacher ist als das Hardware-Inventar, ohne vorzugeben, dass die Hardware identisch ist.

Wie funktionieren Quotas bei GPU-Pools?

Quotas begrenzen, wie viel knappe Beschleuniger-Kapazität ein Tenant oder Team verbrauchen kann.

Eine statische Quota reserviert eine definierte Menge für ein Team.

Geteilte Quota-Modelle können Teams erlauben, sich gegenseitig ungenutzte Kapazität zu leihen. Fair Sharing kann verhindern, dass ein Team dauerhaft alle freien Ressourcen verbraucht.

Kueue unterstützt nominale Quota-, Borrowing-, Lending- und Preemption-Richtlinien über ClusterQueues und Cohorts hinweg.

Das ist nützlich, weil die GPU-Nachfrage oft stoßweise auftritt.

Ein Forschungsteam braucht vielleicht für ein paar Stunden große Kapazität, dann für den Rest des Tages nur wenig. Jede GPU strikt nach Abteilung zu partitionieren, kann zu ungenutzter Hardware führen.

Borrowing macht den Pool effizienter, braucht aber klare Rückforderungsregeln.

Wenn Team A sich die ungenutzte Kapazität von Team B leiht und Team B sie plötzlich zurückbraucht, braucht der Scheduler eine Richtlinie dafür, was als Nächstes passiert.

Genau hier werden Priorität und Preemption operativ wichtig.

Wie sollte Preemption bei Trainings-Jobs funktionieren?

Preemption sollte nützliche Arbeit schützen, bevor die Ressource zurückgefordert wird.

Für eine kurze zustandslose Inferenzaufgabe kann ein Neustart günstig sein.

Bei einem Trainings-Job, der bereits Stunden gelaufen ist, kann eine abrupte Eviction eine große Menge an Compute verschwenden, sofern der Workload keinen aktuellen Checkpoint hat.

Ein besserer Ablauf ist:

Den Workload mit niedrigerer Priorität identifizieren.
Wo unterstützt, einen Checkpoint auslösen oder verifizieren.
Auf den Abschluss des Checkpoints warten.
Den Workload evicten oder suspendieren.
Die GPUs freigeben.
Später vom Checkpoint aus fortsetzen.

Das ist nicht rein eine Funktion des Kubernetes-Schedulers. Das Trainings-Framework, der Workload-Controller, das Storage-System und der Queue-Manager können alle daran beteiligt sein.

Deshalb reicht "Preemption unterstützen" als Anforderung nicht aus.

Fragen Sie, was mit der bereits geleisteten Arbeit passiert.

Was ist Health-Aware-GPU-Scheduling?

Health-Aware-Scheduling entfernt oder priorisiert Beschleuniger herunter, die technisch sichtbar, aber operativ unzuverlässig sind.

Der Scheduler sollte nicht warten, bis eine Karte komplett ausfällt.

Eine degradierte Karte kann steigende ECC-Fehler, instabile Temperatur, wiederholte Resets, abnormales Taktverhalten oder Treiberausfälle zeigen.

Das Operations-System kann diese Beobachtungen in einen Health-State umwandeln.

Die Scheduling-Schicht kann die Karte dann von neuen Allokationen ausschließen oder den Node als nicht schedulebar markieren.

Das erzeugt eine nützliche Schleife:

Hardware-Monitoring erkennt die Degradation.
Das Ressourcenmodell markiert das Gerät.
Der Scheduler vermeidet es.
Bestehende Workloads werden geschützt oder verschoben.
Ein Reparatur-Workflow wird eröffnet.
Das Gerät kehrt erst nach Validierung in den Pool zurück.

Das ist einer der Gründe, warum ein KI-Rechenzentrum tiefere Hardware-Sichtbarkeit braucht als ein generischer Container-Cluster.

Wie fügen sich GPU-Partitionen in den Pool ein?

GPU-Partitionen erlauben es, einen physischen Beschleuniger als mehrere kleinere Ressourcen offenzulegen, aber das Isolationsmodell hängt von der Partitionierungstechnologie ab.

NVIDIA Multi Instance GPU partitioniert auf unterstützter Hardware eine physische GPU in isolierte Instanzen mit dedizierten Compute- und Speicherressourcen.

Time Sharing ist anders. Es erlaubt mehreren Workloads, eine GPU über die Zeit hinweg zu nutzen, bietet aber nicht dasselbe Hardware-Partitionierungsmodell.

Aus Scheduling-Perspektive sollten das separate Ressourcenklassen sein.

Ein Nutzer, der eine dedizierte vollständige GPU anfordert, sollte nicht versehentlich eine Time-Shared-Ressource erhalten.

Ein Nutzer, der ein kleines Inferenz-Slice anfordert, sollte nicht eine ganze große Karte reservieren, wenn die Hardware sicher partitioniert werden kann.

Die Pool-Effizienz verbessert sich, wenn die Ressourcenform zum Workload passt.

Warum ist Topologie für Multi-GPU-Jobs wichtig?

Topologie ist wichtig, weil die Kommunikation zwischen GPUs zu einem großen Teil der verteilten Trainingszeit werden kann.

Zwei Sets aus acht GPUs mögen zahlenmäßig identisch aussehen, verhalten sich aber unterschiedlich, wenn ein Set einen besseren lokalen Interconnect oder einen besseren Netzwerkpfad hat.

Topology-Aware-Scheduling versucht, eng gekoppelte Workloads dort zu platzieren, wo Kommunikation effizient ist.

Das kann bedeuten, einen Multi-GPU-Job innerhalb desselben Nodes, derselben Hochgeschwindigkeits-Fabric-Domäne oder einer anderen definierten Topologiegrenze zu halten.

Kueue bietet außerdem Topology-Aware-Scheduling-Funktionen für Workloads, die eine Platzierung basierend auf der Rechenzentrums-Topologie benötigen.

Der operative Punkt ist, dass nicht jeder Nutzer die Topologie lernen muss.

Der Scheduler sollte Topologie als Constraint hinter der Ressourcenklasse nutzen.

Wie erkennt man, warum ein GPU-Job wartet?

Eine gute Queue sollte den konkreten Grund offenlegen, warum ein Workload wartet.

"Pending" reicht nicht aus.

Nützliche Gründe umfassen:

Tenant-Quota ausgeschöpft
Kein passender Beschleuniger-Flavor verfügbar
Insgesamt genug GPUs vorhanden, aber nicht genug in der erforderlichen Topologie verfügbar
Die angeforderte Full-Card-Klasse ist ausgeschöpft
Ein Node ist wegen Health blockiert
Ein Workload mit höherer Priorität hat die Kapazität reserviert
Eine Admission-Prüfung wartet auf Kapazitäts-Provisionierung

Diese Information verändert das Verhalten von Operatoren.

Wenn das Problem die Quota ist, löst zusätzliche Hardware es nicht. Wenn das Problem Fragmentierung ist, sind vielleicht keine zusätzlichen GPUs nötig. Wenn das Problem ein Health-Ausschluss ist, sollte der Reparatur-Workflow Priorität haben.

Queue-Transparenz ist Teil des Produkts, nicht nur ein Debugging-Feature.

Wie sollten Ressourcen zurückgefordert werden?

GPU-Ressourcen sollten automatisch zurückgefordert werden, wenn der Workload endet, ein Timeout erreicht oder bewusst suspendiert wird.

Verwaiste Allokationen sind teuer.

Ein vollständiges System sollte den Scheduler-State, den Pod-State, die Geräteallokation und den Metering-State abgleichen.

Wenn ein Job sagt, er sei fertig, aber eine Ressource bleibt allokiert, stimmt die Pool-Kapazität nicht.

Wenn ein Pod verschwindet, das Metering-System dem Projekt aber weiterhin etwas berechnet, stimmt die Rechnung nicht.

Wenn ein Node ausfällt und die Ressource nie aus der verfügbaren Kapazität entfernt wird, kann der nächste Job einem toten Gerät zugewiesen werden.

Resource Reclamation ist daher sowohl eine Scheduling-Funktion als auch eine Datenkonsistenz-Funktion.

Was sollte ich zuerst bauen?

Bauen Sie zuerst die Resource Truth, dann die Scheduling-Policy.

Sie brauchen zuverlässige Geräteerkennung, Health-State, Node-Beziehungen, Ressourcenklassen und Workload-Bindings, bevor ausgefeiltes Queueing vertrauenswürdig wird.

Fügen Sie dann Quotas, Sharing, Topologieregeln, Checkpoint-Aware-Preemption, Metering und Optimierung hinzu.

Ein Plattformbeispiel, das diese Schichten verbindet, ist Sensaka.

Wenn ich einen kleinen, homogenen Cluster betreiben würde, würde ich das Modell einfach halten und natives Kubernetes-GPU-Scheduling mit klaren Quotas nutzen. Wenn ich einen Multi-Tenant-, Multi-Model-, heterogenen KI-Cluster betreiben würde, würde ich einen expliziten Resource Pool, eine Job-Admission-Schicht, Health-Aware-Scheduling und Cost Accounting hinzufügen. Komplexität ist gerechtfertigt, wenn sie knappe Beschleuniger davor schützt, ungenutzt, fragmentiert oder dem falschen Workload zugewiesen zu sein.