kalafoto - stock.adobe.com
KubeVirt versus Virtlet für das VM- und Containermanagement
KubeVirt und Virtlet dienen beide der Verwaltung von VMs und Containern in einem Stack, haben aber jeweils ihre eigenen Schwerpunkte und Vorteile. Wir erklären die Unterschiede.
Die Open-Source-Projekte KubeVirt und Virtlet ermöglichen das Planen und Verwalten virtueller Maschinen (VMs) in einem Kubernetes-Cluster. Das vereinfacht die Verwaltung, verringert die Risiken und senkt die Betriebskosten.
Viele IT-Teams arbeiten mit zwei verschiedenen Technologie-Stacks, wenn sie für Entwicklungsprojekte auf Container setzen. Einige Unternehmen migrieren Anwendungen, die in VMs laufen, auf Container, aber das ist nicht immer machbar oder praktisch.
KubeVirt und Virtlet helfen Entwicklungsteams, die einen Teil ihrer Anwendungen in Container umwandeln und gleichzeitig VM-basierte Workloads weiterhin unterstützen wollen. Mit beiden Tools erstellen Entwickler jede Art von Anwendung in einer gemeinsamen Umgebung und stellen sie bereit, wobei sie vertraute und standardbasierte Technologien verwenden.
Es gibt wichtige Unterschiede zwischen KubeVirt und Virtlet, die sich vor allem auf die Art und Weise beziehen, wie sie in Kubernetes implementiert sind.
KubeVirt versus Virtlet
Ursprünglich hat Red Hat das KubeVirt-Projekt ins Leben gerufen, die Cloud Native Computing Foundation (CNCF)hat es jedoch übernommen und begonnen, es unter der Apache License 2.0 zu vertreiben. KubeVirt ist ein Kubernetes-Add-on, mit dem Entwickler Anwendungen in VMs und Containern erstellen, ändern und bereitstellen können. Mit KubeVirt führen Entwickler beide Arten von Anwendungen nebeneinander im selben Kubernetes-Cluster aus.
Mit dem KubeVirt-Add-on erstellen, planen, starten, stoppen und löschen die Controller und Agenten VMs. KubeVirt ist ein Management-Add-on, das als benutzerdefinierte Ressourcendefinition (CRD) implementiert ist und die Kubernetes-API erweitert. KubeVirt-VMs werden als containerisierte Workloads bereitgestellt, die als Pods ausgeführt werden, so dass sie Zugriff auf Pod-Ressourcen wie Netzwerk und Speicher haben.
Virtlet wurde von Mirantis Inc. entwickelt, ist jetzt aber auch als kostenloses Open-Source-Tool unter der Apache License 2.0 verfügbar. Virtlet ermöglicht es Entwicklern ebenfalls, VM-Workloads auf Kubernetes-Clustern auszuführen. Virtlet ist jedoch eine Implementierung der Kubernetes-Container-Laufzeitschnittstelle (CRI) und kein Add-on. Es baut auf Kubernetes-Objekten auf höherer Ebene auf und unterstützt die meisten Standard-Kubectl-Befehle, sodass es VMs wie Pods handhaben kann.
Die VMs selbst verwenden QEMU Copy On Write Version 2-Images. Virtlet ist eine CRI-Implementierung, über die Kubernetes in der Lage ist, VMs ähnlich zu behandeln, wie Container. Folglich stehen Administratoren gängige kubectl-Befehle wie create, get, apply oder attach zur Verfügung, um die VMs zu verwalten.
Da sich ihre Implementierungsprozesse unterscheiden, weisen KubeVirt und Virtlet einige wichtige Unterschiede auf. So unterstützt Virtlet beispielsweise die SR-IOV-Schnittstelle (Single Root I/O Virtualization), eine Erweiterung der Peripheral Component Interconnect Express-Spezifikation, die zu einer besseren Netzwerkleistung führt.
KubeVirt unterstützt ebenfalls SR-IOV sowie weitere Volume-Typen, darunter cloudInitNoCloud, cloudInitConfigDrive, persistentVolumeClaim, dataVolume, ephemeral und containerDisk. Virtlet ist auf einen benutzerdefinierten FlexVolume-Treiber beschränkt, der Blockgeräte für VMs festlegt, was es bezüglich der Speicherflexibilitä einschränkt.
Vor- und Nachteile von KubeVirt und Virtlet
Beide Technologien – insbesondere Virtlet – sind im Vergleich zu ausgereifteren Produkten noch relativ jung und verfügen daher über einen begrenzten Community-Support. Für einige DevOps-Teams ergeben sich daraus Kosten, Risiken und Effizienzprobleme. Mit der Verbesserung der Technologien und der Integration in Kubernetes-Plattformen und -Dienste von Drittanbietern werden einige dieser Bedenken wahrscheinlich verschwinden, obwohl dies zusätzliche Lizenz- oder Abonnementgebühren bedeutet.
Da es sich bei KubeVirt um eine CRD-Implementierung handelt, bietet sie mehr Flexibilität für das Verwalten und Einstellen von VMs. Das bedeutet jedoch auch, dass die VMs nicht mehr so gut in Kubernetes integriert sind wie mit Virtlet; Administratoren müssen sie getrennt von anderen Kubernetes-Komponenten verwalten, was zusätzliche Prozesse und Befehle erfordert.
Virtlet bietet eine engere Kubernetes-Integration und eine Pod-ähnliche Erfahrung, da es sich um eine CRI-Implementierung handelt. Dies ermöglicht die Verwaltung von VMs, als wären sie Container. Außerdem bietet es eine bessere Unterstützung für Hochleistungsnetzwerke, einschließlich der SR-IOV-Schnittstelle. Im Vergleich zu KubeVirt sind die Speicheroptionen jedoch begrenzt. Virtlet-Benutzer sind bei der Verwaltung der VMs auf Kubernetes-Konstrukte beschränkt, so dass sie die Tuning-Möglichkeiten einer VM nicht voll ausschöpfen können, da die VMs auf Pod-Funktionen beschränkt sind.
Die Wahl zwischen KubeVirt und Virtlet
Der primäre Anwendungsfall für KubeVirt oder Virtlet ist, Unternehmen die Möglichkeit zu geben, ihre VM-basierten Anwendungen weiterhin zu unterstützen und gleichzeitig den Overhead zu reduzieren, der mit der Verwaltung mehrerer Technologie-Stacks parallel einhergeht.
IT-Abteilung haben verschiedene Gründe, ihre Legacy-Anwendungen weiterhin in VMs auszuführen:
- Die Migration von Anwendungen von VMs auf Container kann eine erhebliche Investition an Zeit und Ressourcen bedeuten. In einigen Fällen ist es schwierig, die Kosten zu rechtfertigen, insbesondere wenn die Anwendung kurz vor dem Ende ihrer Lebensdauer steht.
- Einige Anwendungen eignen sich besser für VMs als für Container, zum Beispiel bestimmte Datenbanksysteme, Verzeichnisdienste oder GPU-intensive Workloads. Bei einigen Anwendungen gibt es Sicherheits- oder Compliance-Überlegungen, die das VM-Hosting rechtfertigen.
- Selbst wenn ein Unternehmen plant, seine Legacy-Anwendungen auf Container zu migrieren, kann eine solche Umstellung langsam und riskant sein und einen Zeitrahmen von mehreren Jahren umfassen. Das bedeutet, dass die Legacy-Anwendungen weiterhin in VMs laufen und während des Umstellungsprozesses unterstützt werden müssen.
KubeVirt oder Virtlet können eine praktikable Alternative zur Beibehaltung separater Technologiestapel darstellen. Die Entscheidung für eine der beiden Optionen hängt jedoch von den Speicher- und Netzwerkanforderungen eines Unternehmens ab sowie davon, wie viele Funktionen es für die Verwaltung und Abstimmung von VMs benötigt.
Bei beiden Open-Source-Optionen handelt es sich um junge Technologien, und der Implementierungsprozess ist mit Unsicherheiten behaftet. Aus diesem Grund müssen IT- und Entwicklerteams vorsichtig vorgehen. Verschieben Sie VM-Workloads schrittweise und führen Sie die neue Umgebung in kleinen Schritten ein.
