Sollten VMs und Container unter einem einheitlichen Betriebsmodell koexistieren? Die Kosten für zwei separate Welten sind höher als die für eine...
Hintergrund
Vermehrt nutzen Unternehmen Kubernetes, pflegen zugleich aber noch einen separaten Hypervisor für VMs. Mario Fahlandt, Customer Delivery Architect bei Kubermatic und Technical Oversight Committee Member der CNCF, beobachtet nach eigener Aussage inzwischen vermehrt, wie Betriebe eine Kubernetes-Plattform aufbauen und zugleich ein Proxmox-Cluster für die "alten" Workloads betreiben.
Das Ergebnis: Zwei Welten, zwei APIs, zwei Runbooks und zwei Eskalationspfade. Die These: Wenn Kubernetes die Plattform der Wahl ist, dann ist KubeVirt der Hypervisor… Im folgenden finden Sie eine Zusammenfassung der wesentlichen Punkte, weshalb der Spezialist vom Betrieb zweier Systeme nicht überzeugt ist und davon abrät…
Zum Beitrag
"VMs verschwinden nicht. Legacy-Workloads, Windows-Server, Datenbank-Appliances, Compliance-Themen, das alles läuft als VM und wird das auch noch eine Weile tun. Die Frage ist nicht: Braucht man VMs? Die Frage ist: Wie verwaltet man sie?
Die klassische Antwort: Ein separater Hypervisor. VMware, Proxmox, Hyper-V, jedes mit eigener API, eigenem Auth, eigenem Netzwerk-Modell, eigener Ops-Kultur. Das Ergebnis? Zwei Infrastrukturen. Zwei Automatisierungs-Stacks. Zwei Hiring-Profile.
Zur Lösung
KubeVirt macht VMs zu Kubernetes-Ressourcen. Definiert durch CRDs, gemanagt durch Controller, scheduled durch denselben Scheduler, beobachtbar durch dieselben Prometheus-Metriken, abgesichert durch dasselbe RBAC. Eine Plattform. Eine API. Ein Betriebsmodell.
Das ist kein Komfort-Feature. Das ist ein Force-Multiplier. Alles, was man in Kubernetes investiert hat (GitOps, Observability, Policy Engines, Developer Self-Service) gilt automatisch für VMs. Man baut das nicht neu. Man erbt es.
Imperativ vs. Deklarativ
Proxmox ist imperativ. Man klickt einen Button oder ruft eine API auf, und das System führt das aus. Kein Desired State. Kein Reconciliation. Wenn was halb schiefgeht, steht da eine VM in einem inkonsistenten Zustand, und man sucht manuell.
Es gibt Terraform, aber der Proxmox-Terraform-Provider (Telmate) ist Community-gepflegt. Über 1.500 Issues insgesamt auf GitHub (128 aktuell offen). Ständige Breaks zwischen Versionen. Cloud-Init-Workflows, die nicht verlässlich funktionieren. State Drift nach Disk-Resize. Das ist keine Enterprise-Automatisierung. Das ist ein Workaround.
KubeVirt ist deklarativ, weil es auf Kubernetes aufsetzt. kubectl apply für Deployments? Dasselbe für VirtualMachines. ArgoCD syncs Container-Workloads? Syncs auch VMs. git revert für Rollback? Genau dasselbe. GitOps ist nicht draufgesetzt. Es ist der natürliche Betriebsmodus, und Kubermatic Virtualization unterstützt deklarative, GitOps-style YAML-Installation mit Self-Healing bei wiederholten Runs.
Multi-Tenancy: Berechtigungen vs. Policy
Proxmox hat ein Berechtigungssystem. Pfadbasiert. Rollen. Nutzer. Und, das ist das Problem, nicht viel mehr. Keine NetworkPolicies. Keine Admission Controllers. Keine Namespace-Isolation. Nutzer auf derselben Bridge können potentiell Traffic von Nachbarn sniffen.
Multi-Tenancy auf Proxmox bedeutet: Man klebt RBAC, SDN-Zones, Firewall-Regeln, Routing und VPN manuell zusammen. Ein Integrations-Exercise, kein Konfigurations-Exercise.
KubeVirt erbt das vollständige Kubernetes-Sicherheitsmodell: RBAC auf Namespace-Ebene, NetworkPolicies (Calico/Cilium), Pod Security Standards, Admission Controllers (OPA/Gatekeeper, Kyverno), strukturiertes Audit Logging.
Und seit v1.8: Confidential Computing mit Intel TDX, kryptografische Attestierung, dass VMs auf vertrauenswürdiger Hardware laufen. Für regulierte Umgebungen (Finanz, Behörde) ist das kein Nice-to-have. Das ist ein Hard Requirement.
Skalierung: ~32 Nodes vs. beliebig
Proxmox-Cluster sind praktisch auf ~32 Nodes begrenzt. Proxmox' eigene Doku sagt, es gebe "no explicit limit", räumt aber ein, dass "the actual possible node count may be limited by the host and network performance". Community-Erfahrung und Proxmox' eigene Empfehlung (PDM + mehrere Cluster) bestätigen: über 32 Nodes wird Corosync zum Flaschenhals. Das ist keine Konfiguration. Das ist eine Architektur-Grenze.
Kubernetes skaliert auf Tausende von Nodes. Google, Apple, Shopify beweisen das täglich. KubeVirt erbt dieses Skalierungsmodell. KubeVirt v1.8 wurde in SIG-Scale-Tests bei 8.000 VMs validiert, mit linearem Speicherwachstum im Control Plane (virt-api: 140 MB zu 170 MB, virt-controller: 65 MB zu 1.400 MB). Node Affinity, Anti-Affinity, Taints/Tolerations, Topology Spread Constraints, Priority Classes, Resource Quotas, alles verfügbar für VM-Scheduling. Proxmox hat davon nichts.
Bildquellen: Mario Fahlandt, Customer Delivery Architect bei Kubermatic (August 2026).
Storage und Networking
Proxmox unterstützt LVM, ZFS, Ceph, NFS, iSCSI. Solide Auswahl. Und das war's. Was ist mit Longhorn? Portworx? Cloud-Provider-Storage? CSI-Treiber...
KubeVirt nutzt das volle Kubernetes CSI-Ökosystem. Jeder Storage-Provider mit CSI-Treiber funktioniert. Ceph via Rook (dasselbe Ceph, nur deklarativ gemanagt). Longhorn. AWS EBS. Azure Disk. NetApp, Dell, Everpure.
VM-Disks sind PersistentVolumeClaims mit StorageClasses, Volume Snapshots und dynamischer Provisionierung. Und seit KubeVirt v1.8: CDI Incremental Backup mit Changed Block Tracking (CBT), storage-agnostische inkrementelle VM-Backups, die Backup-Fenster und Storage-Footprint massiv reduzieren.
Beim Networking dasselbe Bild. Proxmox bietet Linux Bridge, VLAN, OVS. Funktionale Basics. Aber keine NetworkPolicies, keinen Service Mesh, kein Ingress, keinen LoadBalancer, kein Multus.
KubeVirt-VMs sind vollwertige Teilnehmer im Kubernetes-Netzwerk. ClusterIPs, Services, Ingress, Cilium Hubble, NetworkPolicies, alles vorhanden. Eine Legacy-Web-App als VM wird über Ingress mit TLS-Terminierung und Rate-Limiting exposed. Genau wie ein Container-Service. KubeVirt v1.8 hat zudem passt als Core-Netzwerk-Plugin befördert, rootless VM-Networking ohne privilegierte Berechtigungen.
Das VMware-Exit-Argument
Seit Broadcom VMware geschluckt hat, suchen Teams Alternativen. Proxmox ist für viele die naheliegende Wahl: kostenlos, open-source, "mach' ja auch KVM". Aber Proxmox ersetzt VMware mit einer Architektur, die 2010 state-of-the-art war. Imperativ, GUI-zentriert, begrenzt skalierbar, schwache Multi-Tenancy.
Wenn man den VMware-Exit durchzieht, sollte man es richtig machen. KubeVirt + Kubernetes = deklarativ, API-first, GitOps-ready, skalierbar, sichere Multi-Tenancy. Das ist kein Sidestep. Das ist ein Upgrade. Und die Zahlen sprechen für sich:
Laut Spectro Cloud Survey 2025 kennen 86% der Kubernetes-Nutzer KubeVirt, 26% betreiben es in Produktion. (1) Red Hat baut OpenShift Virtualization darauf. NVIDIA nutzt es für GeForce NOW. Cloudflare fährt es in Core-Rechenzentren. Swisscom betreibt damit seine Sovereign Cloud. Das ist kein Nischen-Projekt mehr...
Wann Proxmox Sinn macht
Proxmox ist gute Software für den richtigen Kontext, jedoch:
Kein Kubernetes-Footprint. Wenn man keine Container betreibt und keine plant, braucht man auch kein Kubernetes für VMs.
ZFS als Primär-Requirement. Proxmox' ZFS-Integration ist gut. Für backup-obsessive Teams mit eigenem Storage relevant.
LXC reicht für Container.
Proxmox' LXC-Integration bietet leichtgewichtige Container-Isolation ohne Kubernetes-Overhead.
Budget als Hauptkriterium. Proxmox ist kostenlos. KubeVirt braucht einen Kubernetes-Cluster, was Ops-Overhead bedeutet.
Kleine Teams, einfache Requirements. Unter 30 Nodes, unter 500 VMs, keine Multi-Tenancy. Proxmox reicht.
Aber: In jedem dieser Szenarien ist das Schlüsselwort "einfach". Proxmox funktioniert, solange Requirements einfach sind und die Skalierung moderat. Es gerät unter Druck, wenn Requirements komplex werden, mehrere Teams Infrastruktur teilen, Automatisierung robust sein muss, und VMs und Container unter einem einheitlichen Betriebsmodell koexistieren sollen.
Kubermatic Virtualization
KubeVirt ist ein Projekt, kein Produkt. Produktiv betreiben heißt: Kubernetes auf Bare Metal aufsetzen, ein SDN für VM-Netzwerke wählen, Load Balancing konfigurieren, Provisioning automatisieren. Das ist Arbeit.
Kubermatic Virtualization packt das in eine Suite: KubeVirt (VM Runtime), KubeOVN (SDN/VPC-Netzwerke mit Subnetzen, NAT, Elastic IPs), KubeOne (Bare-Metal-Provisioning und Cluster-Lifecycle), KubeLB (Load Balancer für VM-Services), deklarativer Installer mit TUI-Wizard und GitOps-YAML, und eine zentrale Management-UI. Kein Fork, der Upstream-KubeVirt, ergänzt um die Stücke, die produktiv notwendig sind. Supported, als ein Produkt.
Fazit
Proxmox vs. KubeVirt ist kein Feature-Checklisten-Vergleich. Es ist ein Paradigma-Vergleich. Imperativ vs. Deklarativ. Standalone vs. Plattform-integriert. GUI-zentriert vs. API-first. Wenn Kubernetes die Plattform der Wahl ist, dann adoptiert man am besten KubeVirt für Virtualisierung. Die Kosten für zwei Welten sind höher als die für eine. Laut Spectro Cloud Survey 2025 laufen 26% der Kubernetes-Nutzer KubeVirt in Produktion. 2.036 Contributors aus 528 Organisationen bauen daran…“ (1)
(1) Quelle / externer Link > https://www.spectrocloud.com/state-of-kubernetes-2025
Querverweis:
Unser Blogpost mit Podcast > Container oder virtuelle Maschinen – was ist die bessere Wahl?
Unser Beitrag > SNIA Swordfish® v1.2.9: Einheitliche Server- und Speicherverwaltung für Hyperscale- und Cloud-Infrastruktur-Umgebungen
Unser Beitrag > Open-source IT Infrastruktur Monitoring mit Icinga
Unser Beitrag > Die Migration von Hypervisor-Systemen und daraus resultierende Risiken für Backup- und Disaster Recovery