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". Das erste ist ein Geräteintegrationsproblem, das zweite 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 und nicht jeden existierenden Beschleuniger ohne Hilfe entdeckt. 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 in verschiedenen Nodes stecken und unterschiedliche Modelle sein. Manche sind vielleicht vollständige Karten, manche partitioniert, und manche gehören 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", und der Scheduler wählt dann geeignete Geräte aus.

Ein nützlicher Pool verfolgt mindestens fünf Dinge: welche Ressourcen existieren, welche davon verfügbar sind, welche gesund sind, welche Workloads sie nutzen dürfen und 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, weil ein verteilter Trainings-Job möglicherweise viele Pods und viele GPUs gleichzeitig braucht und es nutzlos sein kann, nur einen Teil des Jobs zu starten. Eine Plattform braucht unter Umständen außerdem 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.

Eine gängige Architektur sieht deshalb so aus: Kubernetes übernimmt Node- und Pod-Scheduling, Vendor-Plugins oder DRA-Treiber legen die Beschleuniger-Geräte offen, Kueue oder ein anderer Batch-Scheduler übernimmt Queueing und Quota-Admission, und 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 die Fähigkeiten beschreiben, die für den Workload relevant sind, und sich nicht auf den Marketingnamen der Karte beschränken. 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 dabei 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, und 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 und dann für den Rest des Tages nur wenig, und 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. 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 identifiziert zuerst den Workload mit niedrigerer Priorität, löst dort einen Checkpoint aus oder verifiziert ihn, soweit der Workload das unterstützt, und wartet auf den Abschluss des Checkpoints. Erst danach wird der Workload evicted oder suspendiert, die GPUs werden freigegeben, und der Job setzt später vom Checkpoint aus fort.

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 stattdessen, 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, und 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, und 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 funktioniert 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, und 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, denn "Pending" reicht nicht aus. Nützliche Gründe sind eine ausgeschöpfte Tenant-Quota, ein fehlender passender Beschleuniger-Flavor, insgesamt genug GPUs, von denen aber nicht genug in der erforderlichen Topologie verfügbar sind, eine ausgeschöpfte Full-Card-Klasse, ein wegen Health blockierter Node, ein Workload mit höherer Priorität, der die Kapazität reserviert hat, oder eine Admission-Prüfung, die auf Kapazitäts-Provisionierung wartet.

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 gehört damit zum Produkt und ist mehr als 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, denn 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. Und 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.