KubeVirt: Multi-Tenant-GPU-Clouds auf Kubernetes

TL;DR

• KubeVirt bringt Virtualisierung als Add-on auf Kubernetes: VMs und Container mit einem gemeinsamen Control Plane.
• Klassische Device-Plugins sind für AI zu statisch — mal Passthrough, mal vGPU, mal MIG braucht DRA.
• Häufigstes GPU-Cloud-Muster: K8s → KubeVirt → Tenant-VMs → eigenes Kubernetes in der VM → GPUs.
• NUMA-Topology-Awareness ist kein Nice-to-have — falsche Platzierung bricht AI-Performance.
• KubeVirt 1.8+ bringt Alpha-Support für GPU via DRA in virtualisierten Umgebungen.

Was KubeVirt ist

KubeVirt ist ein Virtualisierungs-Add-on: VMs laufen auf Basis von QEMU/KVM innerhalb des Kubernetes-Ökosystems. Teams verwalten Container und VMs nicht in zwei Welten, sondern über dieselben APIs, Policies und GitOps-Pfade.

Status: breite Produktions-Adoption, Release-Zyklus an Kubernetes angeglichen, CNCF-Graduation im Anmarsch. Virtualisierung hat Overhead — nur dort einsetzen, wo Tenancy oder Security es erfordern.

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: tenant-gpu-1
spec:
  running: true
  template:
    spec:
      domain:
        devices:
          disks:
            - name: rootdisk
              disk:
                bus: virtio
          # GPU-Devices je nach DRA/Host-Devices-Konfiguration
        resources:
          requests:
            memory: 32Gi
            cpu: '8'
      volumes:
        - name: rootdisk
          containerDisk:
            image: quay.io/containerdisks/ubuntu:22.04

Warum AI die klassische GPU-Vergabe bricht

Altes Muster: Device-Plugin weist eine GPU einer festen Allokationsart zu — bis jemand manuell umkonfiguriert. AI/ML braucht Velocity: dieselbe Hardware mal als Passthrough, mal als vGPU, mal als MIG.

DRA (Dynamic Resource Allocation) präsentiert Geräte dem Scheduler als verfügbar; Workloads fragen Rezepte an; Zuweisung erfolgt dynamisch. NVIDIA hat seinen DRA-Driver an die Open-Source-Community gespendet — ein Ökosystem statt Single-Vendor-Wartung.

Mehr Technik-Tiefe zu CDI und Sharing: GPU in Kubernetes: CDI, Sharing und DRA.

KubeVirt als Tenancy-Layer

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

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

1. Betreiber betreiben den Host-Cluster und KubeVirt.
2. Tenants bekommen VMs (starke Isolation).
3. In den VMs läuft oft eigenes Kubernetes — Teams behalten vertraute Pod-Workflows.
4. Alternative: KubeVirt-VM als Kernel-Wrapper um Workloads (Security), ohne volles Nested-K8s.

Das ergänzt Namespace-Multi-Tenancy: Wo Container-Isolation nicht reicht, liefert die VM die Grenze — vergleichbar zur Idee hinter Agent-Sandboxes, aber für ganze Tenant-Plattformen.

NUMA und Performance

Für leistungssensible AI/ML- und HPC-Workloads muss die NUMA-Alignment von GPU, NIC und Speicher stimmen. Topology-Awareness stellt sicher, dass Geräte auf dem richtigen Knoten landen — sonst bricht Durchsatz ein, obwohl „eine GPU zugewiesen" ist.

DRA-Constraints (z. B. gemeinsamer PCIe-Root für GPU und NIC) sind genau dafür gebaut. Wer Multi-Tenant-GPU-Clouds baut, behandelt Topologie als Architektur-Arbeit, nicht als Tuning-Nachtrag.

# Skizze: ResourceClaim für GPU (Host-Cluster)
apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaim
metadata:
  name: tenant-a-gpu
spec:
  devices:
    requests:
      - name: gpu
        deviceClassName: gpu.nvidia.com
        allocationMode: ExactCount
        count: 1

GPU-Modi in der VM (Richtung KubeVirt 1.8+)

Zielbild über DRA in virtualisierten Umgebungen:

Alpha-/Beta-Status je Release prüfen. Nicht auf „fertig" warten — aber Upgrade-Pfade und Testlab fest einplanen.

Wann KubeVirt — und wann nicht

Siehe auch Multi-Tenancy auf Kubernetes und vCluster.

Lessons Learned

1. Statische GPU-Allokation ist der Velocity-Killer — DRA gehört auf die Roadmap.
2. Graduation ≠ Betriebsfreiheit — Release-Disziplin und Test-Suites ernst nehmen.
3. NUMA ist kritisch für echte AI-Adoption.
4. Virtualisierung kostet — nur wo Tenancy/Security den Preis wert ist.
5. DRA + KubeVirt reifen parallel — Piloten statt Big-Bang.

Fazit

Multi-Tenant-GPU-Clouds brauchen eine saubere Tenancy-Ebene und flexible Geräte-Zuweisung. KubeVirt liefert die VM-Grenze auf Kubernetes; DRA löst die starre Device-Plugin-Welt. Zusammen mit NUMA-Awareness wird daraus eine Plattform, auf der AI-Workloads nicht nur „eine GPU bekommen", sondern performant und isoliert laufen.

FAQ

Was ist KubeVirt? Virtualisierungs-Add-on: VMs im Kubernetes-Ökosystem, ein Control Plane für Container und VMs.

Warum DRA statt Device-Plugins? Device-Plugins sind statisch. DRA erlaubt Rezepte (Passthrough, vGPU, MIG) und dynamische Zuweisung.

Häufigstes GPU-Cloud-Muster? Host-K8s + KubeVirt + Tenant-VMs mit eigenem Kubernetes und GPU-Zugriff.

Verwandte Artikel

• GPU in Kubernetes: CDI, Sharing und DRA
• GPU Workloads auf Kubernetes
• Kubernetes Multi-Tenancy
• Kubernetes AI at Scale
• AI-Agent-Sandbox mit Kata Containers