Eine Plattform statt zwei Welten

Mario Fahlandt, Customer Delivery Architect bei Kubermatic und Mitglied des Technical Oversight Committee der Cloud Native Computing Foundation (CNCF), beobachtet vermehrt, dass Unternehmen moderne Kubernetes-Plattformen aufbauen und parallel dazu weiterhin auf einen separaten Hypervisor für ihre virtuellen Maschinen setzen. Das erhöht aus seiner Sicht die betriebliche Komplexität unnötig. Im Gastbeitrag erläutert er, warum KubeVirt bei einer Kubernetes-Strategie die konsequentere Wahl sein kann.

Foto: Kubermatic

Kubernetes hat sich längst als Standardplattform für containerisierte Anwendungen etabliert. Gleichzeitig betreiben viele Unternehmen weiterhin geschäftskritische Anwendungen als virtuelle Maschinen – von Legacy-Systemen über Windows-Server bis hin zu spezialisierten Datenbanklösungen. In der Praxis entstehen dadurch häufig zwei getrennte Betriebswelten, die jeweils eigene Werkzeuge, Prozesse und Kompetenzen erfordern.

Am Markt lässt sich beobachten, dass viele Organisationen zwar konsequent in Kubernetes investieren, für bestehende VM-Workloads jedoch weiterhin auf klassische Virtualisierungsplattformen setzen. Dadurch wachsen parallele Infrastrukturen heran, die unabhängig voneinander verwaltet, automatisiert und abgesichert werden müssen. Die eigentliche Herausforderung besteht deshalb nicht darin, ob virtuelle Maschinen weiterhin benötigt werden, sondern wie sie sich möglichst effizient in moderne Plattformstrategien integrieren lassen.

VMs verschwinden nicht

Virtuelle Maschinen werden Unternehmen noch lange begleiten. Legacy-Anwendungen, Windows-Server, Datenbank-Appliances oder regulatorische Vorgaben sorgen dafür, dass klassische VM-Workloads vielerorts unverzichtbar bleiben. Die entscheidende Frage lautet daher nicht, ob VMs weiterhin gebraucht werden, sondern wie sie künftig verwaltet werden.

Die klassische Antwort lautet häufig: ein separater Hypervisor. VMware, Proxmox oder Hyper-V bringen jeweils eigene APIs, eigene Authentifizierungsmodelle, eigene Netzwerkkonzepte und eigene Betriebsprozesse mit. Das Ergebnis sind zwei Infrastrukturen, zwei Automatisierungs-Stacks und oftmals unterschiedliche Kompetenzprofile innerhalb der IT.

Mit KubeVirt verfolgt das Kubernetes-Ökosystem einen anderen Ansatz. Virtuelle Maschinen werden zu nativen Kubernetes-Ressourcen. Sie werden über Custom Resource Definitions definiert, von Kubernetes-Controllern verwaltet, über denselben Scheduler orchestriert und mit denselben Observability- und Sicherheitsmechanismen betrieben wie Container. Statt zweier Plattformen entsteht ein gemeinsames Betriebsmodell.

Der Mehrwert geht dabei weit über eine vereinfachte Verwaltung hinaus. Unternehmen können bestehende Investitionen in GitOps, Observability, Policy Engines oder Self-Service-Plattformen unmittelbar auch für virtuelle Maschinen nutzen. Funktionen müssen nicht doppelt aufgebaut werden, sondern stehen beiden Workload-Typen gleichermaßen zur Verfügung.

Imperativ vs. deklarativ

Ein wesentlicher Unterschied zwischen klassischen Hypervisoren und Kubernetes liegt im Betriebsmodell.

Proxmox folgt einem imperativen Ansatz. Aktionen werden über die grafische Oberfläche oder APIs ausgelöst und unmittelbar ausgeführt. Einen gewünschten Sollzustand, den das System kontinuierlich überwacht und wiederherstellt, gibt es nicht. Kommt es während einer Änderung zu Problemen, sind häufig manuelle Eingriffe erforderlich.

Zwar existieren Terraform-Provider für Proxmox, diese werden jedoch von der Community gepflegt und stoßen in komplexeren Umgebungen regelmäßig an Grenzen. Versionswechsel, Cloud-Init-Prozesse oder Änderungen an Storage-Konfigurationen können zusätzlichen Administrationsaufwand verursachen.

KubeVirt übernimmt dagegen das deklarative Betriebsmodell von Kubernetes. Virtuelle Maschinen werden wie Deployments per YAML beschrieben und über kubectl apply ausgerollt. GitOps-Werkzeuge wie Argo CD oder Flux behandeln Container und VMs gleichermaßen. Rollbacks erfolgen über Git, Änderungen bleiben nachvollziehbar dokumentiert und wiederholbare Deployments gehören zum Standard.

Multi-Tenancy: Sicherheit als Plattformfunktion

Auch beim Thema Mandantenfähigkeit unterscheiden sich beide Ansätze deutlich.

Proxmox verfügt über ein klassisches Rollen- und Berechtigungssystem. Für einfache Umgebungen genügt das häufig. Sollen jedoch mehrere Teams oder Geschäftsbereiche sicher auf einer gemeinsamen Plattform arbeiten, steigt der Integrationsaufwand deutlich. Netzwerksegmentierung, Firewall-Regeln, Routing oder VPN-Konzepte müssen häufig separat geplant und miteinander kombiniert werden.

KubeVirt profitiert dagegen vom vollständigen Sicherheitsmodell von Kubernetes. Rollen und Berechtigungen werden über Namespaces und RBAC geregelt. NetworkPolicies, Admission Controller, Pod Security Standards und strukturierte Audit-Logs stehen ebenso zur Verfügung wie moderne Policy Engines etwa auf Basis von OPA oder Kyverno.

Hinzu kommen neue Funktionen wie Confidential Computing mit Intel TDX, das seit KubeVirt 1.8 kryptografisch nachweisen kann, dass virtuelle Maschinen auf vertrauenswürdiger Hardware ausgeführt werden. Gerade in regulierten Branchen wie Finanzdienstleistungen oder im öffentlichen Sektor gewinnt diese Form der Hardware-Vertrauenswürdigkeit zunehmend an Bedeutung.

Skalierung: Wenn Plattformen wachsen

Auch beim Skalieren zeigen sich grundlegende Unterschiede.

Proxmox eignet sich hervorragend für kleinere bis mittlere Cluster. In sehr großen Umgebungen stößt die Architektur jedoch an Grenzen. Die Herstellerdokumentation nennt zwar keine feste Obergrenze, verweist aber selbst darauf, dass Host- und Netzwerkleistung die Clustergröße begrenzen können. In der Praxis gelten Cluster mit rund 30 bis 32 Nodes vielfach als sinnvoller Bereich.

Kubernetes wurde dagegen von Beginn an für große Cluster entwickelt. Tausende Nodes und mehrere Tausend Workloads gehören bei Hyperscalern längst zum Alltag. Von diesem Skalierungsmodell profitiert auch KubeVirt. Aktuelle Versionen wurden in umfangreichen Skalierungstests mit mehreren Tausend virtuellen Maschinen validiert und bieten sämtliche Kubernetes-Mechanismen für intelligentes Scheduling – von Node Affinity über Taints und Tolerations bis hin zu Resource Quotas und Topology Spread Constraints.

Storage und Networking: Die Stärken des Kubernetes-Ökosystems nutzen

Auch bei Storage und Networking unterscheiden sich klassische Virtualisierungsplattformen und Kubernetes-native Ansätze deutlich.

Proxmox unterstützt etablierte Storage-Technologien wie LVM, ZFS, Ceph, NFS oder iSCSI und deckt damit viele klassische Virtualisierungsszenarien zuverlässig ab. Wer jedoch Cloud-native Speicherlösungen oder moderne CSI-Treiber einsetzen möchte, stößt vergleichsweise schnell an Grenzen.

KubeVirt greift dagegen auf das komplette Kubernetes-Ökosystem zurück. Sämtliche Storage-Lösungen, die einen CSI-Treiber bereitstellen, lassen sich grundsätzlich auch für virtuelle Maschinen nutzen. VM-Festplatten werden als Persistent Volume Claims verwaltet und profitieren von Funktionen wie Storage Classes, Snapshots oder dynamischer Provisionierung. Mit KubeVirt 1.8 kamen darüber hinaus inkrementelle Backups auf Basis von Changed Block Tracking hinzu, wodurch Backup-Fenster und Speicherbedarf deutlich reduziert werden können.

Ein ähnliches Bild zeigt sich beim Netzwerk. Während Proxmox mit Linux Bridge, VLANs oder Open vSwitch solide Grundlagen bietet, stehen in Kubernetes zusätzliche Funktionen wie Network Policies, Service Meshes, Ingress-Controller oder Multus-Netzwerke zur Verfügung. Virtuelle Maschinen werden damit zu gleichberechtigten Teilnehmern innerhalb der Kubernetes-Netzwerkarchitektur und lassen sich nach denselben Prinzipien absichern und verwalten wie containerisierte Anwendungen.

Der VMware-Exit als Chance

Seit der Übernahme von VMware durch Broadcom überprüfen viele Unternehmen ihre Virtualisierungsstrategie. Proxmox zählt dabei häufig zu den ersten Alternativen, weil die Plattform etabliert, quelloffen und vergleichsweise einfach einzuführen ist.

Aus strategischer Sicht lohnt sich jedoch ein Schritt weiter. Wer ohnehin in Kubernetes investiert oder Container und virtuelle Maschinen künftig gemeinsam betreiben möchte, sollte die Gelegenheit nutzen, beide Welten auf einer Plattform zusammenzuführen. KubeVirt ersetzt in diesem Fall nicht nur einen Hypervisor, sondern integriert Virtualisierung unmittelbar in das bestehende Kubernetes-Betriebsmodell.

Der eigentliche Mehrwert liegt deshalb weniger in einzelnen Funktionen als in einer konsistenten Plattformstrategie. Automatisierung, Sicherheit, Observability und Deployment-Prozesse müssen nicht doppelt aufgebaut werden, sondern gelten gleichermaßen für Container und virtuelle Maschinen.

Dass dieser Ansatz zunehmend an Bedeutung gewinnt, zeigt auch die Entwicklung des Projekts. Laut dem Spectro Cloud Survey 2025 kennen bereits 86 Prozent der Kubernetes-Anwender KubeVirt, rund ein Viertel setzt die Technologie produktiv ein. Gleichzeitig wird das Open-Source-Projekt unter dem Dach der Cloud Native Computing Foundation kontinuierlich weiterentwickelt und ist inzwischen Bestandteil zahlreicher Enterprise-Plattformen.

Wann Proxmox weiterhin die richtige Wahl sein kann

Trotzdem bedeutet das nicht, dass Proxmox grundsätzlich die schlechtere Lösung ist. Wie so oft hängt die Entscheidung vom jeweiligen Einsatzszenario ab.

Wer ausschließlich virtuelle Maschinen betreibt und keine Containerstrategie verfolgt, benötigt nicht zwangsläufig Kubernetes als zusätzliche Plattform. Auch für kleinere Infrastrukturen mit überschaubarer Anzahl an Hosts oder für Umgebungen, in denen eine enge Integration von ZFS im Vordergrund steht, bleibt Proxmox eine leistungsfähige und wirtschaftliche Lösung.

Anders sieht es aus, wenn Infrastruktur zunehmend automatisiert werden soll, mehrere Teams dieselbe Plattform nutzen oder Container und virtuelle Maschinen dauerhaft gemeinsam betrieben werden. In solchen Szenarien gewinnt ein Kubernetes-nativer Ansatz deutlich an Attraktivität, weil sich Prozesse vereinheitlichen und Doppelstrukturen vermeiden lassen.

Wer Kubernetes als strategische Plattform etabliert, sollte deshalb auch die Virtualisierung konsequent mitdenken. KubeVirt ersetzt klassische Hypervisoren nicht in jedem Szenario. Wo Container und virtuelle Maschinen jedoch langfristig auf einer gemeinsamen Plattform betrieben werden sollen, bietet der Kubernetes-native Ansatz aus meiner Sicht erhebliche Vorteile – von der Automatisierung über Sicherheitsmechanismen bis hin zu Skalierung und Betrieb. Entscheidend ist letztlich weniger die Frage nach dem Hypervisor als nach einem konsistenten Plattformmodell.

Gastbeitrag von Mario Fahlandt