Projekt anfragen
Nahaufnahme einer Server-Einschubreihe mit leuchtenden Statusanzeigen und Netzwerkkabeln in blauem Licht

GPU-Plattform · Kubernetes · NVIDIA GPU Operator

GPU Kubernetes Cluster mit NVIDIA GPU Operator

GPU-Server sind noch keine Plattform. SKAFFON baut darauf die Kubernetes-Schicht, mit der mehrere Teams GPUs fair, nachvollziehbar und abgesichert nutzen: Operator, Zuteilung, Scheduling, Quotas, Monitoring und GitOps.

Projekt anfragen Zur Entscheidungsmatrix
  • NVIDIA GPU Operator per Helm
  • Exklusiv, Time-Slicing oder MIG
  • Quotas, Queues und Monitoring
  • Konfiguration als Code in Git

Autor: Ibrahim Yesilay, Gründer und Geschäftsführer Stand:

01Ausgangslage

Ein Treiber auf dem Knoten löst vier Probleme nicht

Ein GPU-Knoten, auf dem ein Treiber installiert ist, ist noch keine Plattform. Ungelöst bleiben typischerweise: Treiber- und Toolkit-Versionen pro Knoten, die bei Updates auseinanderlaufen; ein Team, das alle GPUs belegt; Pods, die auf Knoten ohne passende GPU landen; verteilte Jobs, die nur zur Hälfte starten und GPUs blockieren; und fehlende Sicht auf Auslastung. Die Antworten darauf sind Kubernetes-Mechanismen, keine Hardware.

Diese Seite richtet sich an Plattformverantwortliche und CTOs, die GPU-Server bereits haben oder planen und wissen müssen, wie daraus eine Kubernetes-Plattform wird, die mehrere Teams und Workloads fair und nachvollziehbar nutzen.

02Bausteine

Sechs Bausteine zwischen GPU-Knoten und Team

Jeder Baustein beantwortet eines der Probleme oben, mit Standard-Kubernetes-Mitteln und der Herstellerdokumentation als Grundlage.

  • Device Plugin und Operator

    Der NVIDIA GPU Operator verwaltet laut Dokumentation die NVIDIA-Treiber, das Kubernetes Device Plugin für GPUs, das NVIDIA Container Toolkit, automatische Knoten-Beschriftung mit GPU Feature Discovery und DCGM-basiertes Monitoring. Wir installieren ihn per Helm, abgestimmt auf Betriebssystem und Runtime. Stehen die Treiber bereits auf den Knoten, wird die Treiberverwaltung laut Installationsanleitung abgeschaltet (driver.enabled=false).

  • GPU-Scheduling

    Pods fordern GPUs über nvidia.com/gpu an; laut Kubernetes-Dokumentation gehören GPUs in den Abschnitt limits, und Requests müssen, falls angegeben, gleich dem Limit sein. Bei gemischten GPU-Typen steuern Knoten-Labels und Selektoren die Platzierung.

  • Quotas pro Namespace

    Eine ResourceQuota begrenzt GPUs je Namespace. Für erweiterte Ressourcen sind laut Dokumentation nur Einträge mit Präfix requests. erlaubt, etwa requests.nvidia.com/gpu. Eine Quota begrenzt, sie verteilt nicht fair; dafür braucht es Queues.

  • Monitoring

    DCGM-Exporter und Prometheus für Auslastung, Speicher, Temperatur und Fehler der GPUs, Dashboards je Team und Knoten, Alarme bei Ausfall einer GPU.

  • Sicherheit

    Namespace-Trennung, Netzwerkrichtlinien, Zugriff über Ihre Identity-Lösung. Der Namespace des Operators braucht bei aktiver Pod Security Admission laut Anleitung die Stufe privileged; wir begrenzen diese Ausnahme auf genau diesen Namespace. Vertiefung: Kubernetes Security.

  • GitOps-Rollout

    Operator-Konfiguration, Scheduler, Quotas und Dashboards als Code in Git, ausgerollt per GitOps mit Argo CD. Ein Update von Treiber und Operator ist damit ein nachvollziehbarer Merge statt eines Handgriffs auf Knoten.

03Teamübergreifend

Warteschlangen, Fairness und Gruppenstart mit dem KAI Scheduler

Wenn mehrere Teams um knappe GPUs konkurrieren, reicht der Standard-Scheduler nicht: Er kennt weder Warteschlangen noch Gruppenstart. Für Warteschlangen, Fairness und Gruppenstart setzen wir bei Bedarf den KAI Scheduler ein.

Laut Projekt bietet er hierarchische Queues mit Quoten und Prioritäten, Gang Scheduling, GPU-Sharing sowie Bin-Packing, steht unter Apache-2.0 und ist ein CNCF-Sandbox-Projekt.

  • Queues je Team mit Quoten und Prioritäten
  • Gang Scheduling: Gruppenjobs starten ganz oder gar nicht
  • Bin-Packing statt verstreuter GPU-Reste
Makroaufnahme der Kühlrippen und des vergoldeten PCIe-Steckkontakts einer Grafikkarte

04GPU-Zuteilung

GPU-Zuteilung: exklusiv, Time-Slicing oder MIG

Die Wahl des Zuteilungsmodus entscheidet über Isolation und Auslastung. Sie steht am Anfang des Entwurfs.

Entscheidungsmatrix für die drei Zuteilungsmodi einer GPU unter Kubernetes
ModusPrinzipIsolationGeeignet fürGrenzen
ExklusivEin Pod erhält eine ganze GPUvollständigTraining, große Modelle, Workloads mit hoher AuslastungKleine Workloads verschwenden GPU-Speicher
Time-SlicingMehrere Pods teilen eine GPU im Wechsel; per ConfigMap legt man Replikas pro GPU festkeine: laut NVIDIA-Dokumentation gibt es keine Speicher- und Fehlerisolation zwischen den ReplikasEntwicklung, Notebooks, kleine Inference-Dienste desselben TeamsEin Pod kann anderen Speicher oder Rechenzeit nehmen; keine Garantie auf proportionalen Rechenanteil; Änderungen an der ConfigMap werden nicht automatisch erkannt, das Device Plugin muss neu gestartet werden
MIG (Multi-Instance GPU)Eine GPU wird in feste Instanzen mit eigenem Speicher und eigenen Recheneinheiten geteilthardwareseitig getrenntMehrere Mandanten oder Dienste mit klar begrenztem BedarfNur auf GPUs ab NVIDIA Ampere; Umkonfiguration erfordert laut Dokumentation, dass keine Workloads auf der GPU laufen; Profile sind starr

Bei MIG gibt es die Strategien single (jede Instanz erscheint als nvidia.com/gpu, alle GPUs des Knotens mit demselben Profil) und mixed (Instanzen erscheinen unter ihrem Profilnamen, etwa nvidia.com/mig-1g.10gb). Das Profil wird über das Knoten-Label nvidia.com/mig.config gesetzt, der Zustand ist im Label nvidia.com/mig.config.state sichtbar.

Entscheidungsregel

Mandanten mit unterschiedlichem Vertrauen teilen keine GPU per Time-Slicing

Wo mehrere Mandanten dieselbe Hardware nutzen müssen, ist MIG der Weg, bei dem die Isolation tragfähig begründet werden kann; wo die Hardware es nicht hergibt, bleibt exklusive Zuteilung. Time-Slicing ist ein Werkzeug für Entwicklung und für vertrauenswürdige Workloads, bei dem Auslastung wichtiger ist als Isolation.

05Architektur

So greifen die Schichten ineinander

Beispielarchitektur, keine Messwerte.

Schichtenbild GPU-Kubernetes Beispielarchitektur: GPU-Knoten, GPU Operator, Scheduler, Namespaces mit Quota, Git und Argo CD, Prometheus. GPU-Knoten Treiber, Container Toolkit GPU Operator Device Plugin, Feature Discovery,DCGM-Exporter, MIG Manager Scheduler Standard oderKAI mit Queues Namespaces je Team ResourceQuota und Netzwerkrichtlinie je Namespace Prometheus und Dashboards Git-Repository Argo CD Team ATeam BTeam CTeam D Beispielarchitektur, keine Messwerte
Die GPU-Knoten bilden die unterste Schicht, darüber liegen der GPU Operator, der Scheduler und die Namespaces je Team. Git mit Argo CD und Prometheus ergänzen den Cluster.
Schichtenbild GPU-Kubernetes Beispielarchitektur: GPU-Knoten, GPU Operator, Scheduler, Namespaces mit Quota, Git und Argo CD, Prometheus. Git-Repository Argo CD Namespaces je Team ResourceQuota und Netzwerkrichtlinie je Namespace Scheduler Standard oder KAI mit Queues GPU Operator Device Plugin, Feature Discovery, DCGM-Exporter, MIG Manager GPU-Knoten Treiber, Container Toolkit Prometheus und Dashboards Team ATeam B Team CTeam D Beispielarchitektur, keine Messwerte
Die GPU-Knoten bilden die unterste Schicht, darüber liegen der GPU Operator, der Scheduler und die Namespaces je Team. Git mit Argo CD und Prometheus ergänzen den Cluster.

06Abnahme

Elf Prüfpunkte, bevor der Cluster als übergeben gilt

Jeder Punkt wird belegt. Die Reihenfolge entspricht dem Ablauf auf einem neuen Knoten.

  • Operator gesund. Alle Pods im Operator-Namespace laufen oder sind abgeschlossen; die ClusterPolicy meldet ready.
  • GPUs sichtbar. Jeder GPU-Knoten meldet nvidia.com/gpu in den allokierbaren Ressourcen, in der erwarteten Anzahl.
  • Testlauf. Ein Pod mit einer angeforderten GPU führt einen CUDA-Test aus (das NVIDIA-Beispiel VectorAdd meldet „Test PASSED“).
  • Falsche Knoten ausgeschlossen. Ein GPU-Pod ohne passenden Knoten bleibt Pending, statt auf einem Knoten ohne GPU zu starten.
  • Quota wirkt. Ein Pod über der Namespace-Quota wird abgelehnt.
  • Sharing-Modus verifiziert. Bei Time-Slicing: Zahl der angebotenen Replikas entspricht der Konfiguration. Bei MIG: Profil laut Label gesetzt, Zustand success, Instanzen mit erwartetem Namen sichtbar.
  • Warteschlange und Fairness (bei Einsatz von KAI): Zwei Teams in getrennten Queues erhalten bei Knappheit die vereinbarten Anteile; ein Gruppenjob startet ganz oder gar nicht.
  • Monitoring. GPU-Metriken erscheinen im Dashboard, ein simulierter GPU-Ausfall löst den Alarm aus.
  • Update geübt. Ein Update von Operator oder Treiber wurde auf einem Knoten im Testlauf durchgespielt, einschließlich Rückweg.
  • Mandantentrennung geprüft. Ein Pod aus Namespace A erreicht Workloads aus Namespace B nur, wo es Richtlinien erlauben.
  • Dokumentation. Runbooks für Knotenausfall, Treiberproblem, volle Queue und Quota-Erhöhung liegen vor.

07Abgrenzung der Messwerte

Interconnect und Durchsatz gehören zur Hardware-Abnahme

Messwerte wie Interconnect und Durchsatz gehören zur Abnahme des Hardware-Clusters (GPU-Cluster). Veröffentlichte Benchmarkzahlen geben wir hier nicht an, weil sie nur für genau Ihre Hardware und Konfiguration gelten.

Zu GPU-Cluster

Nahaufnahme gelber Glasfaser-Patchkabel mit FC-Steckern und nummerierten Knickschutzhüllen an einem weißen Verteilerfeld

08Projektablauf

Vom Assessment zur laufenden GPU-Plattform

  1. 01

    Assessment

    Ergebnis: Modus und Scheduler

    Workloads, Teams, Knoten, Sicherheitsvorgaben. Ergebnis ist die Wahl von Zuteilungsmodus und Scheduler.

  2. 02

    Entwurf

    Namespaces, Quoten, Queues, Labels, Monitoring.

  3. 03

    Aufbau als Code

    Operator, Scheduler, Quotas und Dashboards in Git, ausgerollt per GitOps.

  4. 04

    Abnahme

    Nach der Checkliste oben.

  5. 05

    Übergabe

    Mit Runbooks und Schulung oder Überleitung in den Betrieb.

09Eingaben und Lieferumfang

Was wir von Ihnen brauchen und was Sie erhalten

Eingaben für das Assessment, danach der Lieferumfang. Zum Angebot: Bestimmend sind Zahl der Knoten und GPU-Typen, Zahl der Teams und Mandanten, Wahl von Zuteilungsmodus und Scheduler, Sicherheitsvorgaben, Zahl der Umgebungen und der gewünschte Betriebsumfang. Aus diesen Punkten entsteht ein Angebot mit festem Umfang.

  • Eingabe: GPU-Typen und Verteilung auf Knoten, Betriebssystem, Container-Runtime, vorhandener Kubernetes-Cluster
  • Eingabe: Workloads (Inference, Fine-Tuning, Training, interaktive Notebooks) und Größe der Modelle
  • Eingabe: Teams und Mandanten, wer wie viel nutzen und wen verdrängen darf
  • Eingabe: Treiber auf den Knoten vorinstalliert oder vom Operator verwaltet
  • Eingabe: Sicherheitsvorgaben (Pod Security, Netzwerkrichtlinien), Registry- und Air-Gap-Vorgaben
  • Lieferung: Architekturdokument mit Begründung des Zuteilungsmodus
  • Lieferung: Git-Repository mit Konfiguration als Code
  • Lieferung: Quota- und Queue-Konzept
  • Lieferung: Dashboards und Alarme
  • Lieferung: Abnahmeprotokoll und Runbooks

10Ehrliche Einordnung

Lohnt sich der Aufbau für Ihre GPUs?

Dann lohnt sich der Aufbau

  • Mehrere Teams oder Mandanten sollen GPU-Knoten gemeinsam nutzen, mit nachvollziehbaren Quoten.
  • GPU-Server sind vorhanden oder geplant und brauchen eine Kubernetes-Plattform mit Monitoring und GitOps.

Dann ist es das falsche Projekt

  • Sie suchen gemietete GPU-Kapazität: SKAFFON ist kein GPU-Vermieter.
  • Ihr Workload läuft auf einer einzelnen GPU eines Entwicklerrechners: Eine Kubernetes-Plattform ist dann überdimensioniert.
  • Sie wollen GPUs zwischen nicht vertrauenswürdigen Mandanten per Time-Slicing teilen und dabei Isolation zusichern: Das ist laut Herstellerdokumentation nicht gegeben.

11Weiterführend

Was auf der GPU-Plattform aufbaut

Überblick: GPU- und KI-Infrastruktur. NVIDIA, CUDA und weitere genannte Namen sind Marken ihrer Inhaber.

Anfrage

Knoten, Workloads und Teams beschreiben

Beschreiben Sie Knoten, Workloads und Teams in einer Projektanfrage. Daraus ergibt sich die Wahl von Zuteilungsmodus und Scheduler.

Projekt anfragen