Multi-Tenant-GPU-Kubernetes auf simulierter Hardware mit Kamaji und HAMi
🇬🇧 Read in English~4 min read
devopscloud-nativekubernetesgpukamajihamimulti-tenantkubeflow
Continuum findet, validiert und behebt Code-Schwachstellen: Es beweist, welche Befunde in Ihrer Umgebung tatsächlich ausnutzbar sind, priorisiert sie nach geschäftlicher Auswirkung und schlägt Korrekturen vor – mit menschlicher Freigabe, bevor etwas ausgeliefert wird.
GPU-Teams stehen meist vor einem schlechten Kompromiss. Gib jedem Team seinen eigenen Kubernetes-Cluster und du zahlst für ein Control Plane pro Team. Setze alle in einen gemeinsamen Cluster und du bekommst schwache Isolation. In beiden Fällen gibt Kubernetes GPUs als ganze Karten aus – ein Pod, der 4 GB einer 80-GB-GPU benötigt, blockiert also trotzdem die gesamte Karte.
Dieser Beitrag zeigt einen Ausweg durch die Kombination zweier Open-Source-Projekte:
Das Ganze läuft auf einer einzigen Maschine ohne physische GPU, unter Verwendung von HAMis Mock-Device-Plugin zur Simulation der Karten. Ergebnis: zwei vollständig isolierte Mandanten-Cluster, die jeweils fraktionierte GPU-Workloads über HAMi planen, mit allen acht Tests bestanden. Alles unten ist reproduzierbar – exakte Versionen, funktionierende Befehle und die unterwegs aufgetretenen Fehler.
Ein kind-Cluster hostet Kamaji und beide Mandanten-Control-Planes; der Worker jedes Mandanten ist ein separater Container, der über das kind-Netzwerk beitritt und HAMi ausführt. Mandanten teilen sich weder einen Node noch einen API-Server. Die einzigen gemeinsamen Teile sind der Management-Cluster und der kamaji-etcd-Datenspeicher, in dem die Daten jedes Mandanten getrennt bleiben.
Kamaji löst das Cluster-Problem, HAMi löst das GPU-Problem – sie arbeiten auf verschiedenen Ebenen, überlappen sich also nicht. Der interessante Teil ist, wo sie sich treffen: Der API-Server eines Mandanten lebt im Management-Cluster, aber der Webhook von HAMi lebt auf den Worker-Nodes des Mandanten. Jede GPU-Pod-Erstellung hängt daher davon ab, dass der API-Server über den Konnectivity-Tunnel von Kamaji zurück in den Mandanten gelangt. Den Nachweis, dass dieser Pfad funktioniert, ist das Hauptziel dieses Labors.
Alles läuft als Docker-Container auf einem einzigen Linux-Host – 4 CPU-Kerne, 8 GB freier RAM und 20 GB Festplatte reichen aus.
Wie testet man GPU-Sharing ohne GPU? Das echte Device-Plugin von HAMi spricht mit dem NVIDIA-Treiber und kann daher ohne Hardware nicht starten. Das Mock-Device-Plugin überspringt die Hardware-Erkennung: Du beschreibst Fake-Karten in einer Node-Annotation, und es registriert daraus die gpumem- und gpucores-Kapazität. Die Webhook-, Scheduler- und Quota-Logik von HAMi läuft dann exakt so, wie sie auf echten Nodes laufen würde.
Zwei simulierte Setups halten die Mandanten leicht unterscheidbar:
Der Aufbau hat fünf Schritte; Schritt 3 erstellt beide Mandanten gleichzeitig, die Schritte 4–5 wiederholen sich pro Mandant. Normales kubectl spricht mit dem Management-Cluster; --kubeconfig tenant-a.kubeconfig spricht mit einem Mandanten.
Schritt 1 – Management-Cluster + cert-manager + MetalLB:
kind create cluster --name kamaji
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.21.2/cert-manager.yaml
kubectl -n cert-manager wait pod --all --for=condition=Ready --timeout=180s
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.16.1/config/manifests/metallb-frr-k8s.yaml
kubectl -n metallb-system wait pod --all --for=condition=Ready --timeout=180s
Gib MetalLB dann einen Pool aus dem IPv4-Subnetz des kind-Netzwerks (docker network inspect kind | grep Subnet), z. B. 172.18.255.200-172.18.255.250 mit einer L2Advertisement.
Schritt 2 – Kamaji installieren:
helm repo add clastix https://clastix.github.io/charts
helm upgrade --install kamaji clastix/kamaji \
--namespace kamaji-system --create-namespace \
--set 'resources=null' --version 0.0.0+latest
kubectl -n kamaji-system get pods
Schritt 3 – die Mandanten-Control-Planes erstellen (TENANT_VERSION=v1.36.4), dann Schritte 4–5 registrieren den Worker jedes Mandanten mit HAMis Mock-Device-Plugin und stellen fraktionierte GPU-Workloads als Smoke-Tests bereit.
Die Trennung funktioniert, weil Isolation und GPU-Effizienz nicht mehr gegeneinander abgewogen werden müssen. Mandanten behalten ihr eigenes Control Plane (eigener API-Server, eigene Namespaces, eigenes RBAC, eigenes Quota), während sie die physische Beschleuniger-Flotte über HAMis Device-Slicing teilen – und das Ganze kann auf einem Laptop ohne GPU prototypisiert werden, weil das Mock-Plugin die Scheduling-Logik real macht, auch wenn die Hardware es nicht ist.
Der Konnectivity-Tunnel zwischen Kamajis API-Server und HAMis Webhook pro Node ist die Nahtstelle, die halten muss; dieses Labor beweist, dass sie Ende-zu-Ende funktioniert, bevor du Geld für echte Karten ausgibst.
Kamaji + HAMi ist eine überzeugende Antwort auf das Dilemma „Control Plane pro Team versus schwache Isolation“ – besonders für Plattform-Teams, die Mandanten-Isolation und GPU-Auslastung im selben Cluster benötigen. Und da HAMis Mock-Plugin den vollständigen Scheduling-Pfad ohne Hardware ausführt, kannst du die Architektur kostengünstig validieren, bevor du beschaffst.