KubeVirt: Virtualisierung als Tenancy-Layer für GPU-Workloads

TL;DR

AI-Workloads sprengen klassische Kubernetes-GPU-Muster. Statische Device-Plugins weisen eine GPU fest zu — bis jemand manuell eingreift. Für Teams, die zwischen Passthrough, vGPU und MIG wechseln müssen, ist das zu starr. Die Antwort: DRA für flexible Zuweisung und KubeVirt als Tenancy-Layer — ein Control Plane für Container und VMs, mit NUMA-Topology-Awareness für echte Performance.

Was KubeVirt ist

KubeVirt ist ein Virtualisierungs-Add-on auf Kubernetes. VMs laufen innerhalb von Containern (QEMU/KVM). Ergebnis: ein gemeinsames Control Plane für Container und VMs — statt zwei paralleler Welten. Der Release-Zyklus ist an Kubernetes angeglichen; CNCF-Graduation rückt näher, Produktions-Adoption ist bereits breit.

Warum AI die GPU-Verwaltung bricht

Das alte Muster: Device-Plugin → GPU fest einer Allokationsart zugewiesen. Das AI-Problem: Workloads brauchen Flexibilität — mal Passthrough für volle Leistung, mal vGPU für Teilung, mal MIG für Isolation. Statische Zuweisung bremst Velocity und verschwendet teure Karten.

DRA (Dynamic Resource Allocation) präsentiert Geräte dem Scheduler als verfügbar. Workloads fragen „Rezepte" an; die Zuweisung erfolgt dynamisch. NVIDIA hat seinen DRA-Driver an die Open-Source-Community gespendet — das Ökosystem wächst nicht nur vendor-intern.

Multi-Tenant-Architektur

Der häufigste Einsatz bei GPU-Cloud-Betreibern:

Kubernetes (Basis)
  └── KubeVirt (Tenancy / Virtualisierung)
        └── Tenant-VMs
              └── Kubernetes in der VM → Pods nutzen GPUs

1. Betreiber stellen KubeVirt bereit und geben Tenants VMs.
2. In den VMs läuft eigenes Kubernetes — Pods greifen kontrolliert auf GPUs zu.
3. Alternativ (Serverless/Security): KubeVirt-VM als Kernel-Wrapper um Workloads — VM-Grenze statt reiner Container.

KubeVirt 1.8 bringt Alpha-Support für GPU via DRA: Passthrough, vGPU und MIG in virtualisierten Umgebungen — Ziel: GPUs in VMs so flexibel wie an Pods.

NUMA ist kein Detail

Für leistungssensible AI/ML- und HPC-Workloads muss die NUMA-Alignment von GPU und NIC stimmen. Falsche Topologie bricht Throughput und Latenz. Topology-Awareness stellt sicher, dass Geräte auf dem richtigen NUMA-Knoten landen — Voraussetzung für ernsthafte AI-Adoption, nicht Nice-to-have. Das schließt an CDI/DRA und PCIe-Alignment an.

Die ehrliche Einordnung:

1. Statische GPU-Allokation ist der Flaschenhals — AI-Velocity braucht DRA.
2. KubeVirt reift weiter — Graduation und Release-Disziplin beachten.
3. NUMA falsch = Performance tot — Architektur-Arbeit, kein Tuning-Afterthought.
4. Virtualisierung hat Overhead — nur wo Tenancy oder Security es erfordern.
5. DRA in VMs ist noch jung — Alpha/Beta mitplanen, nicht als fertig verkaufen.

Häufige Fragen

Brauchen wir KubeVirt für jede KI-Plattform?

Nein. Für einen Team-Cluster mit klaren Pods reicht oft GPU-Partitionierung. KubeVirt lohnt bei Multi-Tenant-GPU-Clouds oder harter Mandanten-Isolation.

Container oder VM für Agents?

Wo untrusted Code läuft, helfen VM-Grenzen — vgl. Kata/Agent Sandbox. KubeVirt ist die Orchestrierungs-Schicht dafür auf Kubernetes.

Ist DRA produktionsreif?

Für viele GPU-Use-Cases auf dem Cluster-Level ja/nahe. In KubeVirt-VMs noch früher im Lebenszyklus — schrittweise einführen.

Fazit

Wer eine GPU-Cloud (privat oder als interner Shared Service) baut, braucht eine saubere Tenancy-Ebene und flexible GPU-Zuweisung. KubeVirt plus DRA liefern genau das — mit NUMA als Performance-Fundament.

Ergänzend: AI at Scale und NVIDIA GPU-Server-Familien. Wir beraten, ob KubeVirt+DRA zu Ihrer Tenancy-Strategie passt, und betreiben die Architektur mit Topology-Optimierung und Audit.