Pexon Consulting | 11 Min. Lesezeit | 30.08.2026
TL;DR
NVIDIA GPU Operator bringt Treiber, Device Plugin und DCGM auf GPU-Nodes. MIG teilt Karten isoliert. DRA ersetzt 2026 schrittweise das klassische Plugin, DynamicMIG bleibt Alpha. Der Text trennt den produktiven Pfad von Feature-Gates, die ihr noch nicht einschalten solltet. Stand: Operator 26.7, DRA-Treiber v0.5.0.
Das Problem: eine GPU im Cluster ist noch kein GPU-Betrieb
Ein Node mit H100 und ein Pod mit nvidia.com/gpu: 1 beweisen nur, dass das Device Plugin die Karte gesehen hat. Sie beweisen nicht, dass der nächste Node-Tausch denselben Treiberstand hat, dass zwei Teams sich die Karte teilen können oder dass ein Audit nachvollziehen kann, wer wann welche Instanz bekommen hat.
Kubernetes kennt keine halbe GPU. Ohne Operator, Sharing-Regel und Autoscaling bleibt die Lastspitze als Dauerkosten stehen. Genau das ist der Sprung vom PoC zum Betrieb: nicht das erste kubectl apply, sondern Treiber, Geometrie und Nachweis.
Wer nur Queues und Fair-Share sucht, ist bei Kueue besser aufgehoben. Dieser Text bleibt beim Operator: wie Karten überhaupt im Cluster auftauchen, wie MIG sie schneidet und wann DRA den Device-Plugin-Pfad ablösen darf. GPU-Scheduling auf Kubernetes: Queue vor der Karte
Was der NVIDIA GPU Operator 2026 wirklich ausrollt
Der Operator ist ein Helm-Chart plus Custom Resources, kein magischer Scheduler. Er hält auf jedem GPU-Node denselben Stack: Kernel-Treiber (oder preinstalled), Container Toolkit, Device Plugin oder DRA-Treiber, GPU Feature Discovery, DCGM Exporter. Ohne diese Schicht hängt jeder Node-Tausch an Handarbeit.
Zwei Betriebsmodelle, die sich gegenseitig ausschließen (NVIDIA-Doku zum DRA-Treiber, Operator 26.7):
Ein Cluster darf entweder ClusterPolicy oder GPUCluster haben, nicht beides. Wer DRA „mal testen“ will, braucht einen zweiten Cluster oder ein sauberes Cutover-Fenster. Der DRA-Treiber in der Operator-Linie 26.7 ist v0.5.0. Volle GPU und vorkonfigurierte MIG-Geräte sind GA. DynamicMIG, ConsumableShares und MPS über DRA sind Alpha und standardmäßig aus.
# Orientierungsbeispiel: Operator mit klassischem Device Plugin (ClusterPolicy)
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update
helm install gpu-operator nvidia/gpu-operator
--namespace gpu-operator --create-namespace
-f values-clusterpolicy.yaml
# Chart-Version gegen den NGC-Index der Linie 26.7 pinnen, kein latestvalues-clusterpolicy.yaml ist der Vertrag: Driver-Strategie (operator vs. preinstalled), MIG-Strategie, DCGM, Taints. Floating latest gehört nicht in Produktion.
MIG: isolierte Schnitte statt Zeitscheibe
Multi-Instance GPU zerlegt Ampere- und neuere Rechenzentrumskarten in Hardware-Instanzen mit eigenem Speicher. Das ist der Unterschied zu Time-Slicing: Zeitscheiben teilen Rechenzeit, nicht den Fehlerschutz. Zwei Teams auf einer ungeteilten Karte stören sich gegenseitig. MIG gibt jedem Team eine Instanz mit fester Geometrie.
Ab GPU Operator v26.3.0 erzeugt der MIG Manager pro Node eine ConfigMap mit den Profilen, die NVML auf der Hardware findet (all-disabled, all-enabled, Profile wie all-1g.10gb, all-balanced). Ihr setzt das Label nvidia.com/mig.config auf den Node. Der Manager stoppt GPU-Pods, wendet die Geometrie an und startet neu. Manche Wechsel brauchen einen Reboot, weil MIG-Mode erst dann aktiv wird.
- Hardware prüfen: nur unterstützte Data-Center-GPUs, nicht jede Workstation-Karte.
- Strategie wählen:
singleodermixed, bevor der erste Produktiv-Pod die Karte hält. - Label setzen, ConfigMap prüfen, erst dann Workloads mit dem passenden MIG-Profil schedulen.
- Node-Tausch und Karpenter: neue Nodes müssen dieselbe Geometrie bekommen, sonst landet der Pod im Pending.
- Nachweis: welche ConfigMap, welches Label, welcher Zeitpunkt im Git.
Time-Slicing bleibt erlaubt für Dev und niedrige Isolation. Für mehrere Teams auf derselben physischen Karte im Kundenkontakt nehmen wir MIG. MPS (gleiche Karte, gemeinsame Prozesse) lassen wir im Produktivbetrieb mit getrennten Mandanten weg.
DRA 2026: Nachfolger, kein Default-Tag-1
Dynamic Resource Allocation ist die Kubernetes-API für Geräte über Claims statt über limits.nvidia.com/gpu: 1. Vorteil: ihr könnt Modell, Speicher, MIG-Klasse und Topologie beschreiben, statt nur eine Zahl. Nachteil: der Pfad ist jünger, Health-Reporting über NVML ist Alpha, Preemption für DRA-Geräte gibt Kubernetes nicht.
NVIDIA sagt klar: Device Plugin und DRA-Treiber nicht parallel auf denselben Nodes für dieselbe Allokation. Für DRA setzt der Operator gpuCluster.deployCR=true und lässt ClusterPolicy weg. Nodes für den DRA-Kubelet-Plugin brauchen das vorgesehene Label. Kubernetes v1.34-v1.35 verlangt für partitionierbare Geräte extra Feature-Gates. Ab v1.36 ist DRAPartitionableDevices default an.
DynamicMIG erzeugt MIG-Schnitte erst beim Claim. Das klingt nach dem Traum jedes FinOps-Teams. Es ist Alpha, zerstört fremde Partitionen beim Plugin-Start und kollidiert mit mehreren anderen Feature-Gates. In einem Cluster mit Kundenlast bleibt DynamicMIG aus, bis NVIDIA und Kubernetes das auf Beta heben.
DRA produktiv heißt Projekt: Versionspin, CDI-Runtime, Runbook für Claim-Stuck, Observability ohne die gewohnte Device-Plugin-Health. Für „GPUs sollen einfach ankommen“ bleibt 2026 ClusterPolicy plus MIG-Manager.
Checkliste: Operator, Sharing, Autoscaling
Abhaken, bevor ihr GPU-Nodes als Produktivplattform verkauft. Stand geprüft: 30.08.2026, Operator-Linie 26.7, DRA-Treiber v0.5.0.
- Ein Allokationspfad: ClusterPolicy oder GPUCluster, dokumentiert.
- Image und Chart pinnen: Operator-Version im Git, kein
latest. - Taints und Tolerations: normale Deployments dürfen GPU-Nodes nicht vollaufen.
- MIG-Geometrie im Git: Label plus ConfigMap-Quelle, nicht nur „haben wir mal gesetzt“.
- Karpenter oder Cluster-Autoscaler: GPU-Pool getrennt, Consolidation nach Last, nicht nach Hoffnung.
- DCGM und Alerts: Temperatur, XID, Util, nicht nur Pod-Ready.
- Warteschlange getrennt denken: Operator bringt Karten. Fair-Share zwischen Jobs ist Kueue oder ein Batch-Scheduler.
- Nachweis: Treiberstand, MIG-Profil, Change-Commit, Runbook Node-Replace.
PoC hat Punkt 1 und einen Pod. Betrieb hat 3-8. Dazwischen liegt die Production-Gap: der Assistent antwortet, die Monatsrechnung und der nächste Node-Tausch tun es nicht.
Was Pexon konkret macht
Unter KI-Plattform-Betrieb betreiben wir GPU-Nodes auf eurem Cluster: Operator, MIG wo Isolation nötig ist, Karpenter für die Rechnung, DCGM für den Montagmorgen. DRA nehmen wir, wenn eure Kubernetes-Version und euer Risiko das tragen, nicht weil es auf einer Keynote stand.
Der AI-Readiness-Scan (990 EUR) prüft zuerst, ob ihr überhaupt dauerhaft GPU-Nodes braucht oder ob eine Karte im Versuch reicht. Betrieb liegt bei 5.000-10.000 EUR im Monat plus eure Rechenleistung direkt beim Anbieter. Servicezeit Mo-Fr 08:00-18:00 MEZ. Training und Fine-Tuning bleiben bei euch.
Was das nicht ist
Das ist keine Kaufberatung für H100 gegen L40S und kein Training-How-to. Es ist auch kein 24/7-NOC und kein Versprechen, NVIDIA-Lock-in auf Treiberebene aufzulösen. Operator, MIG und DRA sind die Schicht unter Inferenz. Wer vLLM-Flags sucht, ist in der Engine-Checkliste besser.
Häufig gestellte Fragen
GPU Operator oder nur das NVIDIA Device Plugin?
Das Plugin allein reicht für einen festen Node mit vorinstalliertem Treiber. Der Operator lohnt, sobald Nodes dazukommen und verschwinden, Treiberstände gleich bleiben müssen und DCGM nicht von Hand gepflegt werden soll. Ab zwei GPU-Nodes ist der Operator der kürzere Weg.
MIG oder Time-Slicing für mehrere Teams?
MIG, wenn Isolation und Speichergrenzen zählen. Time-Slicing, wenn Dev-Dichte zählt und ein Crash des Nachbarn akzeptabel ist. Mischbetrieb auf derselben Karte ohne Geometrie-Plan endet in Pending-Pods und Streit.
Ist DRA 2026 schon der Default?
Nein. Default bleibt ClusterPolicy plus Device Plugin. DRA ist der Nachfolgekandidat mit GA für volle GPUs und statisches MIG. Alpha-Gates (DynamicMIG, Shares, MPS) bleiben aus, bis euer Cluster und euer Audit das explizit tragen.
Was kostet GPU-Betrieb grob pro Monat?
Die Karte (Miete oder Abschreibung) dominiert, nicht die Operator-Lizenz (NVIDIA GPU Operator ist frei nutzbar im Rahmen der NVIDIA-Lizenz). Pexon-Betrieb für die Plattform darunter: 5.000-10.000 EUR im Monat. Eine einzelne Versuchskarte ohne SLA braucht diesen Vertrag nicht.
GPU Operator Kubernetes und Kueue: was zuerst?
Zuerst Operator, sonst sieht der Scheduler keine Karten. Kueue danach, wenn Jobs um knappe GPUs konkurrieren. Beides in einem Helm-Release zu vermischen, ohne die Reihenfolge zu kennen, erzeugt undurchsichtige Pending-Gründe.
Nächster Schritt
GPU-Nodes laufen, Geometrie und Autoscaling sind unklar: Checkliste gegen euren Cluster legen. Lücken bei MIG, Taints oder Nachweis? Dann den KI-Plattform-Betrieb (AI-Readiness-Scan, 990 EUR). Karten sichtbar machen, teilen und abschalten können – nicht nur einen Pod starten.
