CoreWeaves SUNK betreibt Slurm in Kubernetes auf einem gemeinsamen Compute-Pool

Das Problem: zwei Scheduler, zwei Compute-Pools

CoreWeave bezeichnet Slurm und Kubernetes als die beiden führenden Werkzeuge in der HPC- und KI-Welt. Slurm, entwickelt von SchedMD, ist der De-facto-Scheduler für viele HPC-Workloads und auf Batch-Jobs mit begrenzter Laufzeit ausgelegt. Kubernetes wurde für langlebige Workloads wie Inferenz entwickelt.

Laut CoreWeave ist der Kubernetes-Scheduler für Batch-Workloads weniger verbreitet als Slurm und es fehlen ihm einige Funktionen. Andere Kubernetes-basierte Scheduler wie Volcano und YuniKorn wollen Slurm-ähnliches Scheduling bieten, haben es aber schwer gegen das umfangreiche Wissen, das sich rund um Slurm angesammelt hat.

Manche Unternehmen betreiben beide Systeme parallel. CoreWeave zufolge bedeutet das, dass jeder Cluster seinen eigenen Compute-Pool verwaltet, teils in unterschiedlichen Clouds mit getrenntem Speicher. Das Ressourcenmanagement ist komplett getrennt, jede Zusammenarbeit der beiden Seiten erfordert daher manuelle Arbeit. Das Unternehmen argumentiert, so lasse sich die Auslastung der GPU-Ressourcen schwerer maximieren.

Was SUNK leistet und warum CoreWeave es gebaut hat

SUNK bringt containerisierte Kubernetes-Deployments und GitOps zu Slurm und integriert ein Slurm-Scheduler-Plugin in Kubernetes. In der Praxis fungiert Slurm als Kubernetes-Scheduler, und Slurm-Jobs laufen innerhalb von Kubernetes. CoreWeave zufolge unterstützt das sowohl Burst- als auch Batch-Workloads auf derselben zentralen Plattform, wobei sich die Rechenleistung sowohl von der Kubernetes- als auch von der Slurm-Seite aus nutzen lässt.

Als Motivation nennt CoreWeave die Effizienz für Kunden. Bei sehr großen und teuren HPC-Clustern kommt es darauf an, einer Auslastung von 100 % möglichst nahezukommen, denn ungenutzte, aber bezahlte Rechenleistung ist teuer. CoreWeave sagt, die eigene Cloud basiere vollständig auf Kubernetes, und viele Kunden, die Slurm bevorzugten, hätten es entweder separat betrieben oder um eine Integration gebeten. Da es keine solche Lösung gab, habe das Unternehmen sie selbst entwickelt.

Zu den von CoreWeave genannten Funktionen zählen:

• Ein Slurm-Cluster, der über ein stark anpassbares Helm-Chart als Kubernetes-Ressourcen bereitgestellt wird und Kubernetes-basierte GitOps-Workflows ermöglicht.
• Einfache Nachverfolgung und Konfiguration von Prolog- und Epilog-Skripten, schnelles Bereitstellen von Staging-Clustern sowie Unterstützung für s6-Skripte und -Dienste.
• Konfigurierbare Authentifizierung, darunter LDAP über ein begleitendes OpenLdap-Helm-Chart oder Drittanbieter-Optionen wie Authentik und GAuth.
• Kubernetes-Vorteile wie schnelles Scheduling, Containerisierung, Hochverfügbarkeit der Control-Plane-Dienste, dynamische Knotenskalierung, Requests und Limits sowie gemeinsame Dateisysteme über PersistentVolumeClaim-Ressourcen.
• Zustandsverwaltung mit bidirektionaler Synchronisierung zwischen Kubernetes und Slurm, automatische Topologieerzeugung, Unterstützung der Container-Ausführung mit Pyxis und GRES-Unterstützung mit automatischer Erkennung.

So ist SUNK aufgebaut

Alle SUNK-Dienste sind in Kubernetes containerisiert. Die typischen Slurm-Komponenten laufen in Pods, jeweils mit konfigurierbaren Ressourcenanforderungen. Login-Knoten sind enthalten; sobald sich Nutzer darauf verbinden, ist Kubernetes abstrahiert, und die Bedienung entspricht der eines normalen Slurm-Clusters. Slurm-Konfiguration, Topologie, Prolog- und Epilog-Skripte sowie sensible Daten wie Datenbankpasswörter werden als Kubernetes-ConfigMaps und -Secrets bereitgestellt und lassen sich so an einer Stelle verwalten.

Die Compute-Knoten laufen als Bare-Metal-Kubernetes-Knoten. Die slurmd-Daemons laufen in Compute-Pods in einer 1:1-Zuordnung. Ein Slurm-Syncer vermittelt zwischen beiden Seiten und tauscht Informationen über die REST-API von Slurm aus. Clusterweite Operatoren überwachen Ressourcen und nehmen Änderungen vor, unabhängig davon, ob sie von Kubernetes oder Slurm ausgehen; Metriken lassen sich über Prometheus bereitstellen.

CoreWeave zufolge hat das Team drei Komponenten eigens entwickelt, damit das funktioniert: das Nodeset, den Syncer und den Scheduler. Das Nodeset ist eine CRD, die einen Slurm-Knoten in der Kubernetes-Umgebung definiert. Es wird ähnlich wie ein StatefulSet oder Deployment definiert, ist aber eins zu eins den Knoten zugeordnet, eher wie ein DaemonSet. Es führt Statusfelder, die den Slurm-Zustand widerspiegeln, und ermöglicht so geschützte Updates und das Skalieren von Slurm-Knoten auf Basis des Zustands in beiden Systemen. Nodeset-Pods führen sowohl slurmd als auch munged aus und binden gemeinsame ConfigMaps und Volumes des gemeinsamen Dateisystems als PVCs ein.

Der eigene Kubernetes-Scheduler nutzt den synchronisierten Slurm-Zustand, um native Kubernetes-Workloads auf Compute-Knoten zu platzieren. So können Nutzer einen Compute-Pool flexibel zwischen Slurm-Jobs (Burst-Workloads) und Kubernetes-Workloads (Serverless-Workloads) verschieben.

Was das für HPC- und KI-Teams bedeutet

Für Organisationen, die auf Slurm setzen, aber Kubernetes für Produktivdienste wie Inferenz nutzen wollen, bietet SUNK die Möglichkeit, vertraute Slurm-Workflows beizubehalten, ohne einen zweiten Cluster zu betreiben. CoreWeave zufolge ergibt sich daraus eine einzige Plattform mit einem einzigen Compute-Pool, mehr Flexibilität bei der Wahl der Workloads auf der Hardware und bessere Chancen, teure GPUs auszulasten. Die Aussagen stammen aus der eigenen Beschreibung von CoreWeave; der vorliegende Quelltext enthält keine Leistungsmessungen.