KubeVirt 2026: virtuelle Maschinen als native Kubernetes-Workloads
🇬🇧 Read in English~5 min read
kuberneteskubevirtvirtualizationdevsecopscloud-nativesecurity
Save products you love by clicking the heart icon.
„Kubernetes oder VMs" war ein Jahrzehnt lang eine Migrationsentscheidung. Die Realität 2026: lizenzierte Betriebssysteme, Legacy-Anwendungen mit Kernel-Abhängigkeiten, spezialisierte Appliances und Workloads, die von der Isolation der Hardware-Virtualisierung profitieren, müssen weiterhin laufen — idealerweise auf denselben Clustern, mit denselben Tools und unter denselben Policies wie die Container. KubeVirt erweitert die Kubernetes-API um Virtualisierung: VMs werden zu CRDs, eine laufende VM steckt in einem normalen Pod, und Scheduler, RBAC, Network Policies und GitOps-Pipelines, die du schon betreibst, gelten auch für sie.
Dieser Artikel geht durch das Modell, die Releases 2026 (v1.8 und v1.9) und die Teile, die für eine DevSecOps-Praxis zählen.
Im Kern sitzt die VirtualMachineInstance (VMI) — eine laufende VM, deren Prozess in einem virt-launcher-Pod auf einem Node mit KVM lebt. Die Control-Plane-Komponenten (virt-api, virt-controller und ein virt-handler-DaemonSet pro Node) reconcilen die üblichen CRDs:
VirtualMachine — die langlebige Definition mit einer runStrategy (Always/Halted/…), quasi das Deployment für VMs.VirtualMachineInstance — die laufende Instanz selbst.VirtualMachinePool (pool.kubevirt.io/v1beta1, neu seit v1.9) — ReplicaSets für VMs mit Auto-Healing und Scale-in-Strategien.apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
name: feed-funnel
spec:
runStrategy: Always
template:
spec:
domain:
devices:
disks:
- name: rootdisk
disk: { bus: virtio }
- name: cloudinit
disk: { bus: virtio }
resources:
requests:
memory: 2Gi
volumes:
- name: rootdisk
containerDisk:
image: quay.io/containerdisks/fedora:latest
- name: cloudinit
cloudInitNoCloud:
userData: |
#cloud-config
packages: [nginx]
virtctl ist das kubectl für VMs: virtctl console, virtctl ssh, virtctl migrate, virtctl evacuate-cancel (Evakuierung abbrechen, neu in v1.8).
Flüchtige Root-Disks kommen als containerDisks daher (ein Image in einer Registry — versioniert, signiert, gescannt wie jedes andere Container-Artefakt). Persistenter State läuft über CDI-DataVolumes, die aus URLs, Registries oder Uploads in PVCs importieren, mit Hotplugging für bedarfsgerechtes Wachstum. Das v1.8-Release brachte inkrementelle Backups mit Changed Block Tracking: Auf QEMUs CBT aufbauende Backups erfassen nur geänderte Blöcke, sind storage-agnostisch (kein spezieller CSI-Treiber nötig) und verkleinern sowohl Backup-Fenster als auch Netzwerk-Traffic. Eine neue VirtualMachineBackup-API plus VolumeNamePolicy-Optionen für Clone/Restore machen DR-Pipelines deklarativ.
Das Default-Binding ist MASQUERADE (Pod-IP-NAT). Die Schlagzeile von v1.8: Das passt-Binding wurde zum Core-Binding befördert — User-Space-Netzwerk, das unprivilegiert läuft, nahtlose Live-Migration unterstützt und die privilegierten Helper-Pfade älterer Bridge-Setups eliminiert. Für Spezialfälle gibt es Bridge, macvtap, SR-IOV (Fast Path für Telco/NFV) und — neu in v1.8 — die Entkopplung von KubeVirt von den NetworkAttachmentDefinitions, die API-Aufrufe und Berechtigungen aus virt-controller entfernt (eine echte Sicherheitsverbesserung bei Skalierung).
Live-Migration verschiebt eine laufende VM zwischen Nodes — der Mechanismus hinter Node-Drains, Evakuierungen und Hardware-Wartung ohne Change-Window. Voraussetzungen: migrierbarer (geteilter) Storage und kompatible Netzwerke; v1.8 unterstützt sogar das Aktualisieren eines Network-Attachments an einer laufenden VM per Migration.
Skalierungszahlen aus dem v1.8-Zyklus: Die KWOK-basierten Performancetests laufen inzwischen mit 8000 VMIs, die Speicherkosten pro VMI auf der Control Plane sind für Capacity Planning veröffentlicht. Für KI/HPC brachte v1.8 PCIe-NUMA-Topology-Awareness, damit VMs nahezu native Geräte-Performance bekommen; v1.9 setzte fort mit einem Alpha-IOMMUFD-Device-Plugin, NVIDIA-Grace-GPU-Passthrough (SMMUv3) und Cross-Architecture-VMs (Alpha: ein ARM64-Gast auf einem AMD64-Host via QEMU TCG — der Scheduler bevorzugt native Architektur und fällt auf Emulation zurück).
v1.8 (März 2026, ausgerichtet auf Kubernetes v1.35):
rebootPolicy, um Gast-Reboots für die runStrategy sichtbar zu machen; VirtualMachineTemplate per virt-operator deploybar; neue virtctl-Template-Kommandos (process/create/convert).v1.9 (August 2026):
serviceAccountName in der VMI-Spec (VEP 250) — VMs bekommen ihre eigene Workload-Identität gegenüber der Kubernetes-API.VirtualMachinePool befördert zu pool.kubevirt.io/v1beta1; vereinfachte VirtualMachineBackup-Conditions; DRA-Devices lesen aus einer Metadaten-Datei (VEP-10).serviceAccountName ist der Kubernetes-API-Zugriff einer VM RBAC-geregelt wie bei jedem Pod — keine geteilten statischen Credentials mehr in Images.virt-controller. Default-Härtung, die man beim Upgrade geschenkt bekommt.git tag -v); der Operator pinnt die Komponenten-Images pro Release.KubeVirt ist irgendwann aufgehört, ein Nischenwerkzeug für Telcos zu sein — etwa zu dem Zeitpunkt, als Live-Migration langweilig wurde. 2026 deckt es Confidential Computing, Multi-Architecture-Flotten, storage-agnostische Backups und Pod-Grade-Identität für VMs ab — genug, dass „laufen wir als VM" nicht mehr heißt „läuft außerhalb der Plattform". Wenn deine Organisation noch eine separate, vSphere-förmige Betriebskultur pflegt, ist KubeVirt die Auffahrt, sie in die Kubernetes-Kultur zu überführen.