Was ist KubeVirt? Erläuterung zum Ausführen von VMs auf Kubernetes

Einführung

Die meisten Unternehmen sind nicht zu 100 % containerisiert und werden es wahrscheinlich auch nie sein. Sie verfügen über Legacy-Anwendungen, die ein vollständiges Betriebssystem voraussetzen. Sie haben Windows-Workloads, die nicht in einem Container ausgeführt werden können. Sie verfügen über spezialisierte Software – beispielsweise Telekommunikationsnetzwerkfunktionen, Datenbank-Appliances oder Machine-Learning-Toolkits –, die direkten Hardwarezugriff und eine herkömmliche VM-Umgebung benötigt.

Jahrelang bestand die Lösung darin, zwei getrennte Systemlandschaften zu unterhalten: einen Kubernetes-Cluster für Ihre containerisierten Workloads und eine Hypervisor-Plattform (in der Regel VMware vSphere) für Ihre VMs. Zwei Sätze von Tools, zwei Teams, zwei Abrechnungsmodelle.

KubeVirt ändert diese Situation. Es erweitert Kubernetes, sodass virtuelle Maschinen neben Ihren Containern auf demselben Cluster ausgeführt werden können – verwaltet mit derselben API und denselben Tools, die Sie bereits kennen.

Auch der Zeitpunkt spielt eine Rolle. Die Übernahme von VMware durch Broadcom hat den Virtualisierungsmarkt grundlegend verändert. Die Lizenzkosten sind erheblich gestiegen, und viele Unternehmen suchen aktiv nach Alternativen zu proprietären Hypervisoren. KubeVirt – ein CNCF-Incubator-Projekt, das von Red Hat, NVIDIA, Intel und einer großen Open-Source-Community unterstützt wird – hat sich als ernstzunehmender Konkurrent etabliert.

In diesem Leitfaden wird erläutert, was KubeVirt ist, wie es im Hintergrund funktioniert und wann sich sein Einsatz lohnt.

Was ist KubeVirt?

KubeVirt ist ein Open-Source-Projekt, das Kubernetes um Funktionen zur Verwaltung virtueller Maschinen erweitert. Anstatt Kubernetes zu ersetzen oder eine separate Plattform aufzubauen, fungiert KubeVirt als Kubernetes-Erweiterung – es führt neue benutzerdefinierte Ressourcen (CRDs) ein, mit denen Sie virtuelle Maschinen definieren, starten, stoppen und verwalten können, indem Sie kubectl und die Kubernetes-API.

Das bedeutet in der Praxis Folgendes:

• Es handelt sich um eine Kubernetes-native Lösung. Sie erstellen eine Virtuelle Maschine Erstellen Sie das YAML-Manifest genauso wie bei einem Deployment. Sie wenden es an mit kubectl apply. Die VM wird in Ihrem Cluster neben Ihren Pods angezeigt.
• Im Hintergrund kommen KVM und libvirt zum Einsatz. Dabei handelt es sich um dieselben bewährten Linux-Virtualisierungstechnologien, auf denen Google Cloud, AWS (Nitro basiert auf KVM) und der Großteil der Cloud-Branche basieren. Es handelt sich also nicht um experimentelle Technologie.
• Es handelt sich um ein CNCF-Incubator-Projekt. KubeVirt hat die CNCF-Sandbox erfolgreich durchlaufen und befindet sich auf dem Weg zur Abschlussphase. Es genießt breite Unterstützung in der Branche und verfügt über eine aktive Community von Mitwirkenden.
• VMs und Container existieren nebeneinander. Eine auf KubeVirt ausgeführte VM kann über dasselbe Cluster-Netzwerk mit Pods kommunizieren. Sie können ein VM-basiertes Datenbank-Backend und ein containerisiertes API-Frontend im selben Namespace platzieren, wobei ein Kubernetes-Service als Schnittstelle dient.

KubeVirt ersetzt Ihre Container-Workloads nicht. Es ermöglicht Kubernetes, Workloads zu verarbeiten, die Container nicht bewältigen können.

So funktioniert KubeVirt

Die Architektur von KubeVirt folgt den Standardmustern von Kubernetes – Controllern, DaemonSets und CRDs. Wenn Sie wissen, wie Kubernetes-Operatoren funktionieren, wird Ihnen die Architektur vertraut vorkommen.

Kernkomponenten

virt-controller wird als Deployment auf Cluster-Ebene ausgeführt. Es überwacht Virtuelle Maschine und Virtuelle Maschineninstanz benutzerdefinierte Ressourcen. Wenn Sie eine VM erstellen, ist virt-controller dafür zuständig, den entsprechenden virt-launcher-Pod auf einem geeigneten Knoten zu erstellen.

virt-handler läuft als DaemonSet auf jedem Knoten, der VMs hosten soll. Es fungiert als Brücke zwischen Kubernetes und der zugrunde liegenden Virtualisierungsschicht. Wenn ein virt-launcher-Pod auf einem Knoten landet, konfiguriert virt-handler die VM über libvirt und verwaltet ihren Lebenszyklus – Starten, Stoppen, Migrieren und Überwachen.

virt-launcher ist ein Pod, der eine einzelne VM umschließt. Jede laufende VM erhält einen eigenen virt-launcher-Pod, der den QEMU-Prozess enthält, der die virtuelle Maschine tatsächlich ausführt. Aus Sicht von Kubernetes ist eine VM lediglich ein Pod mit Ressourcenanforderungen. Der Scheduler ordnet sie zu, das Netzwerk verbindet sie und die Überwachung beobachtet sie – alles über die Standardmechanismen von Kubernetes.

CDI (Containerized Data Importer) ist ein Begleitprojekt, das den Import von VM-Festplatten-Images in Ihren Cluster übernimmt. Es kann QCOW2-, ISO-, VMDK- und Raw-Festplatten-Images von HTTP-Endpunkten, Container-Registries oder S3-kompatiblem storage abrufen und sie in PersistentVolumes schreiben, die Ihre VMs als Festplatten verwenden.

Architektur-Ablauf

Das passiert, wenn Sie eine virtuelle Maschine erstellen:

Flussdiagramm TD
    Benutzer["kubectl apply -f vm.yaml"]
    Benutzer --> Ctrl

    Teilgraph ControlPlane["Control Plane"]
        Ctrl["virt-controller
(Deployment)"]
    Ende

    Ctrl -->|erstellt VMI| API[(Kubernetes-API)]
    Ctrl -->|plant virt-launcher-Pod ein| Sched[kube-scheduler]

    Teilgraph Node["Worker-Knoten"]
        Launcher["virt-launcher-Pod
(QEMU-Prozess)"]
        Handler["virt-handler
(DaemonSet)"]
        Libvirt[libvirt + KVM]

        Handler --> Libvirt
        Libvirt --> Launcher
    Ende

    Sched --> Launcher
    Handler -.->|berichtet Status| API
    Launcher -.->|mountet| PV[(PersistentVolumes
= VM-Festplatten)]

Die wichtigste Erkenntnis: Kubernetes muss in keiner Weise speziell über virtuelle Maschinen „Bescheid wissen“. Aus Sicht des Schedulers ist ein „virt-launcher“-Pod ein Pod, der eine bestimmte Menge an CPU-Leistung, Arbeitsspeicher und möglicherweise Geräte (wie eine GPU) anfordert. Die Virtualisierung findet innerhalb des Pods statt.

Tipp: Da VMs innerhalb von Pods ausgeführt werden, funktionieren alle Ihre vorhandenen Kubernetes-Tools – Überwachung mit Prometheus, Protokollierung mit Fluentd, Netzwerkrichtlinien, RBAC – mit KubeVirt-VMs sofort.

Wann sollte man KubeVirt einsetzen?

KubeVirt ist nicht in jeder Situation die richtige Wahl. Hier sind drei Szenarien, in denen es besonders sinnvoll ist.

1. Modernisierung von Altsystemen

Sie verfügen über Anwendungen, die derzeit nicht in Container verpackt werden können – vielleicht sind sie von bestimmten Kernel-Versionen abhängig, erfordern systemd oder laufen unter Windows. Anstatt für diese Workloads einen separaten Hypervisor-Cluster zu unterhalten, führen Sie sie als VMs auf Ihrer bestehenden Kubernetes-Infrastruktur aus.

Auf diese Weise können Sie Ihre Infrastruktur sofort konsolidieren und Ihren Teams gleichzeitig die Zeit geben, diese Anwendungen in ihrem eigenen Tempo zu modernisieren. Die VM-Workloads nutzen dieselben CI/CD-Pipelines, denselben Überwachungsstack und dieselben Netzwerkrichtlinien wie alle anderen Komponenten.

2. Ausstiegsstrategie von VMware

Die Änderungen bei den Lizenzbedingungen von Broadcom haben VMware für viele Unternehmen deutlich verteuert. Wenn Sie nach Alternativen suchen, bietet KubeVirt eine Lösung, bei der Sie keinen weiteren proprietären Hypervisor erwerben müssen.

KubeVirt läuft auf handelsüblichen Linux-Servern mit KVM-Unterstützung – ohne Lizenzierung pro Sockel und ohne Unternehmensverträge. Ihr Betriebsteam verwaltet die VMs über die Kubernetes-API, anstatt sich in eine weitere Verwaltungsebene einarbeiten zu müssen. Tools wie das Gabelstapler Das Projekt (ein weiteres CNCF-Projekt) kann bei der Migration bestehender VMware-VMs zu KubeVirt helfen.

Warnung: Die Migration von VMware zu KubeVirt ist kein Projekt, das man an einem Wochenende erledigen kann. Produktivmigrationen erfordern eine sorgfältige Planung in Bezug auf storage, Netzwerk und VM-Kompatibilität. Prüfen Sie Ihre Workloads gründlich, bevor Sie sich dazu entschließen.

3. Gemischte Workloads auf einer einzigen Plattform

Manche Teams benötigen VMs – beispielsweise Datenwissenschaftler, die GPU-beschleunigte Workloads mit spezifischen Treiberanforderungen ausführen, Entwickler, die Tests auf verschiedenen Betriebssystemen durchführen, oder Betriebsteams, die Netzwerkgeräte betreiben, die ausschließlich als VM-Images erhältlich sind. Andere Teams benötigen Container.

KubeVirt bietet Ihnen eine einzige Plattform für beides. Ihr Plattformteam verwaltet einen einzigen Cluster, eine einzige Infrastruktur und einen einzigen Satz von Richtlinien. Teams, die VMs benötigen, erhalten VMs. Teams, die Container benötigen, erhalten Container. Alle nutzen kubectl.

KubeVirt im Vergleich zu anderen Ansätzen

Wenn Sie bereits Kubernetes einsetzen und virtuelle Maschinen in dieses Ökosystem integrieren möchten, ist KubeVirt der direkteste Weg. Wenn Sie Unternehmenssupport benötigen und Teil des Red Hat-Ökosystems sind, lohnt es sich, OpenShift Virtualization (das auf KubeVirt aufbaut) in Betracht zu ziehen. Wenn Sie noch keine Kubernetes-Umgebung haben und lediglich Virtualisierung benötigen, sind Proxmox oder ein herkömmlicher Hypervisor möglicherweise die einfachere Lösung.

Kernbegriffe

Bevor Sie mit KubeVirt arbeiten, sollten Sie sich mit vier zentralen Ressourcen vertraut machen.

Virtuelle Maschine (VM) ist die dauerhafte Konfiguration Ihrer virtuellen Maschine. Sie umfasst die CPU-, Speicher-, Festplatten- und Netzwerkkonfiguration der VM. Stellen Sie sich das wie eine Bereitstellung vor – sie definiert den gewünschten Zustand und bleibt auch nach einem Neustart erhalten. Wenn Sie aktiv: true Auf einer virtuellen Maschine erstellt KubeVirt die entsprechende Instanz.

Eine VirtualMachineInstance (VMI) ist die laufende Instanz einer VM. Sie entspricht in etwa einem Pod – sie repräsentiert die tatsächlich ausgeführte Arbeitslast und ist kurzlebig. Wenn Sie eine VirtualMachine anhalten, wird die VMI gelöscht. Wenn Sie sie erneut starten, wird eine neue VMI erstellt.

DataVolume verwaltet den Import und die Vorbereitung von Festplatten-Images für Ihre VMs. Im Hintergrund nutzt es CDI. Sie geben bei DataVolume die URL eines QCOW2-Images an, und DataVolume übernimmt das Herunterladen des Images, dessen Konvertierung und das Schreiben auf einen PersistentVolumeClaim, den Ihre VM als Festplatte einbinden kann.

virtctl ist das KubeVirt-CLI-Tool. Zwar können Sie die meisten Vorgänge im Lebenszyklus von VMs mit kubectl, virtctl bietet VM-spezifische Befehle, die keine kubectl entsprechend – beispielsweise das Öffnen einer seriellen Konsole (virtctl-Konsole), eine SSH-Sitzung starten (virtctl ssh) oder die Live-Migration einer VM zwischen Knoten (virtctl migrate).

Tipp: Sie können installieren virtctl als kubectl-Plugin über Krew: kubectl krew install virt. Damit können Sie kubectl virt statt virtctl.

Nächste Schritte

Nachdem Sie nun wissen, was KubeVirt ist und wie es sich in das Kubernetes-Ökosystem einfügt, ist der nächste Schritt die Einrichtung. Lesen Sie den Abschnitt „Installation von KubeVirt auf einem Kubernetes-Cluster“, um KubeVirt auf einem Testcluster bereitzustellen und Ihre erste virtuelle Maschine zu erstellen.

Wenn Sie konkret eine Migration weg von VMware planen, sollten Sie den Leitfaden zur Planung der Migration von VMware zu KubeVirt im Auge behalten, der später in dieser Reihe erscheint.

Zusammenfassung

KubeVirt erweitert Kubernetes, sodass neben Containern auch virtuelle Maschinen ausgeführt werden können, und nutzt dabei den in der Praxis bewährten Virtualisierungsstack KVM/libvirt. Es handelt sich um ein CNCF-Incubator-Projekt mit breiter Unterstützung aus der Industrie und einer aktiven Community. Wenn Sie Workloads haben, die nicht containerisiert werden können – Legacy-Anwendungen, Windows-VMs oder spezialisierte Software –, können Sie diese mit KubeVirt auf derselben Plattform, mit denselben Tools und über dieselbe API wie den Rest Ihrer Infrastruktur verwalten.