Simulierung von Multi-Tenant-GPU-Sharing mit Kamaji und HAMi

Plattform-Ingenieure stehen bei der Verwaltung von GPU-Workloads oft vor dem schwierigen Abwägen zwischen Ressourceneffizienz und Mandantenisolierung. Eine kürzlich veröffentlichte Demonstration von Anish Bista zeigt, wie die Kombination aus Kamaji und HAMi Teams erlaubt, physische GPUs sicher zu teilen, während getrennte Control Planes beibehalten werden. Dieser Ansatz nutzt simulierte Hardware, um die Architektur zu validieren, bevor teure Infrastruktur bereitgestellt wird.

Was passiert ist

Der Artikel beschreibt eine reproduzierbare Laborumgebung, die auf einem einzelnen Linux-Host mit Docker-Containern aufgebaut wurde. Das Ziel war der Nachweis, dass zwei Open-Source-Projekte, Kamaji und HAMi, zusammenarbeiten können, um das Problem der GPU-Unterauslastung in Multi-Tenant-Kubernetes-Clustern zu lösen. Traditionell führt die Zuweisung einer vollständigen GPU-Karte an einen Pod, der nur einen Bruchteil des Speichers benötigt, zu erheblicher Verschwendung. Umgekehrt führt das Teilen eines Clusters durch mehrere Teams oft zu schwacher Isolation und Sicherheitsrisiken.

Bista erstellte einen Management-Cluster unter Verwendung von kind (Kubernetes in Docker), um Kamaji zu hosten. Innerhalb dieser Management-Ebene wurden zwei separate Tenant-Control-Planes als Pods erstellt. Jeder Tenant erhielt seinen eigenen Worker-Knoten, der ebenfalls als Container lief, sich dem Netzwerk anschloss und HAMi-Komponenten ausführte. Das Setup umfasste zwei simulierte Tenants: tenant-a mit einer simulierten NVIDIA A100 und tenant-b mit zwei simulierten NVIDIA L4 Karten. Das Labor bestand erfolgreich acht Tests, was bestätigte, dass jeder Tenant fraktale GPU-Workloads planen konnte, ohne Ressourcen oder Pods des anderen Tenants zu sehen.

Wie es funktioniert

Kamaji adressiert den Overhead des Control Planes, indem es für jeden Tenant den Kubernetes-API-Server und den etcd-Datenspeicher als Pods innerhalb eines zentralen Management-Clusters betreibt. Dies eliminiert die Notwendigkeit dedizierter Control-Plane-Maschinen für jedes Team. HAMi hingegen operiert auf der Ebene der Planung und der Geräte. Es ermöglicht Pods, spezifische Segmente einer GPU anzufordern, definiert durch Speicher in Megabytes und Compute-Prozentsatz, anstatt eine gesamte Karte zu beanspruchen. Dies erlaubt mehreren Pods aus verschiedenen Anwendungen, auf einer einzigen physischen GPU koexistieren.

Der kritische Integrationspunkt betrifft den Kommunikationspfad zwischen dem API-Server des Tenants und dem HAMi-Webhook. Da der API-Server im Management-Cluster läuft, der Webhook jedoch auf den Worker-Knoten des Tenants resides, muss die Verbindung einen Konnectivity-Tunnel durchlaufen. Das Labor bestätigte, dass dieser Reverse-Proxy-Mechanismus korrekt funktioniert und es dem API-Server ermöglicht, für Planungsentscheidungen in die Tenant-Umgebung zurückzurufen. Um dies ohne physische Hardware zu testen, verwendete der Autor das Mock-Device-Plugin von HAMi, das die Interaktion mit Treibern überspringt und fake GPU-Kapazität über Node-Annotierungen registriert.

Wichtige Details

• Das Labor lief auf einem einzelnen Host mit 4 CPU-Kernen, 8 GB RAM und 20 GB Speicherplatz.
• Tenant-a war mit einer simulierten 80 GB NVIDIA A100 konfiguriert, während tenant-b zwei simulierte 24 GB NVIDIA L4 Karten hatte.
• IPv6-Netzwerk in kind verursachte MetalLB-Pool-Fehler, was eine manuelle Inspektion des IPv4-Subnetzes zur Korrektur der Gateway-Konfiguration erforderte.
• Mock-GPU-Pods schlugen zunächst aufgrund von Node-Lock-Kontention fehlten, da das Mock-Plugin Locks nach der Zuteilung nicht automatisch freigibt.
• Manuelle Annotation von Pods und Nodes war erforderlich, um den Abschluss-Schritt des Device-Plugins in der Mock-Umgebung zu simulieren.
• Das Setup beweist die Verdrahtung und die Planungslogik, validiert aber keine realen Speicherlimits oder CUDA-Leistung.

Warum das wichtig ist

Für Softwareentwickler und Plattform-Ingenieure bietet diese Architektur einen Weg, Cloud-Kosten im Zusammenhang mit GPU-Instanzen erheblich zu senken. Durch die Ermöglichung fraktaler Zuteilung können Organisationen mehr Workloads auf weniger Karten packen, was die Auslastungsraten verbessert, ohne die Sicherheitsvorteile isolierter Control Planes zu opfern. Die Fähigkeit, den gesamten Stack unter Verwendung simulierter Hardware zu testen, bedeutet, dass Teams ihre Plattformdesigns und CI/CD-Pipelines validieren können, bevor sie teure GPU-Nodes kaufen.

Darüber hinaus demonstriert die erfolgreiche Integration von Kamaji und HAMi, dass komplexe Multi-Tenant-Anforderungen nicht unbedingt Custom-Glue-Code oder proprietäre Lösungen erfordern. Die Nutzung standardisierter Tunnel wie Konnectivity stellt sicher, dass der Control Plane verteilte Worker-Knoten sicher verwalten kann. Diese Modularität ermöglicht es Teams, diese Tools inkrementell einzuführen, beginnend mit Simulation und fortschreitend zu Produktions-Hardware mit Vertrauen in die zugrunde liegende Planungsmechanik.

Was Sie tun können

• Replizieren Sie die Laborumgebung unter Verwendung von kind und Kamaji, um die Isolierung von Multi-Tenant-Control-Planes auf lokaler Hardware zu testen.
• Verwenden Sie das Mock-Device-Plugin von HAMi, um Planungsrichtlinien und Quota-Logik zu validieren, ohne physische NVIDIA-GPUs zu benötigen.
• Inspectieren Sie Docker-Netzwerk-Subnetze manuell, wenn Sie auf IPv6-bezogene Probleme mit MetalLB in kind-Clustern stoßen.
• Implementieren Sie manuelle Lock-Freigabeschritte in Testumgebungen, um Einschränkungen des Mock-Plugins während der Entwicklung zu umgehen.
• Überprüfen Sie die Konnectivity-Tunnel-Konnektivität zwischen Ihren Management-Cluster-API-Servern und den Tenant-Worker-Webhooks.
• Planen Sie die Integration echter Device-Plugins frühzeitig, da Mock-Setups keine tatsächlichen Speicher- oder Compute-Limits erzwingen.