KubeVirt-Integration in OpenShift und Rancher
Best of both worlds
Veröffentlicht in Ausgabe 02/2024 - PRAXIS
Die Containerisierung von Anwendungen schreitet voran, aber nicht mit der Geschwindigkeit, die sich viele IT-Profis wünschen. Zu viele Applikationen kleben an ihren alten, monolithischen Architekturen und widerstehen Kubernetes, Podman und Docker. Daher nutzen die meisten Administratoren nach wie vor eine zweischichtige Architektur: Auf den physischen Servern laufen traditionelle Enterprise-Virtualization-Cluster. Darauf setzen dann die Kubernetes-Cluster auf, deren Knoten in virtuellen Maschinen arbeiten. Diese Architektur hat eine ganze Reihe an Nachteilen. Zum einen verursachen beide Layer Lizenz- beziehungsweise Subskriptionskosten. Zum anderen virtualisieren sowohl der VM- als auch der Container-Layer Ressourcen wie Netzwerke und Speicher, was in vielen Installationen die Performance verschlechtert.
Bei vielen Unternehmen stellen Kubernetes-Knoten bereits die Mehrzahl der VMs im Cluster, während die Zahl der klassischen VM-basierten Applikationen stetig sinkt. Das Blatt hat sich also von "viele VMs und ein paar Container" zu "viele Container und ein paar VMs" gewendet. Um diese verbliebenen VMs kann sich Kubernetes selbst kümmern, mit einem Add-on namens KubeVirt. Damit können Admins den ausgedienten Virtualisierungs-Layer aus dem RZ entfernen und die Serverhardware mit allen Ressourcen allein Kubernetes unterstellen, das dann Container und VMs steuert.
Add-ons bereiten Weg für VMs
Wer Kubernetes hört, denkt automatisch an Container. Doch streng genommen ist Kubernetes ein offenes Cluster-Management-Framework. Mit den geeigneten CRDs (Custom Ressource Definitions) und passenden Add-ons verwaltet das Framework neben Containern auch virtuelle Netzwerke, verteilten Storage und natürlich alle Sicherheitsregeln und Zugriffsrechte.
Die Containerisierung von Anwendungen schreitet voran, aber nicht mit der Geschwindigkeit, die sich viele IT-Profis wünschen. Zu viele Applikationen kleben an ihren alten, monolithischen Architekturen und widerstehen Kubernetes, Podman und Docker. Daher nutzen die meisten Administratoren nach wie vor eine zweischichtige Architektur: Auf den physischen Servern laufen traditionelle Enterprise-Virtualization-Cluster. Darauf setzen dann die Kubernetes-Cluster auf, deren Knoten in virtuellen Maschinen arbeiten. Diese Architektur hat eine ganze Reihe an Nachteilen. Zum einen verursachen beide Layer Lizenz- beziehungsweise Subskriptionskosten. Zum anderen virtualisieren sowohl der VM- als auch der Container-Layer Ressourcen wie Netzwerke und Speicher, was in vielen Installationen die Performance verschlechtert.
Bei vielen Unternehmen stellen Kubernetes-Knoten bereits die Mehrzahl der VMs im Cluster, während die Zahl der klassischen VM-basierten Applikationen stetig sinkt. Das Blatt hat sich also von "viele VMs und ein paar Container" zu "viele Container und ein paar VMs" gewendet. Um diese verbliebenen VMs kann sich Kubernetes selbst kümmern, mit einem Add-on namens KubeVirt. Damit können Admins den ausgedienten Virtualisierungs-Layer aus dem RZ entfernen und die Serverhardware mit allen Ressourcen allein Kubernetes unterstellen, das dann Container und VMs steuert.
Add-ons bereiten Weg für VMs
Wer Kubernetes hört, denkt automatisch an Container. Doch streng genommen ist Kubernetes ein offenes Cluster-Management-Framework. Mit den geeigneten CRDs (Custom Ressource Definitions) und passenden Add-ons verwaltet das Framework neben Containern auch virtuelle Netzwerke, verteilten Storage und natürlich alle Sicherheitsregeln und Zugriffsrechte.
Erweiterungen für Kubernetes sichern ihre laufende Konfiguration im systemeigenen Key/Value-Store (in der Regel "etcd") und stellen eine Rest-API bereit. Über diese erhalten sie vom Kubernetes-Framework passende Anweisungen. Möchte ein Administrator nun die Add-on-Funktionen nutzen, formuliert er einen entsprechenden Request an das Kubernetes-Framework. Das im Request verwendete "Kind", also der zu verwaltende Ressourcentyp, verweist dann an die Add-on-API, an die Kubernetes die Anforderung übergibt.
Die Erweiterungen kommunizieren untereinander ebenfalls über das Kubernetes-Framework. So lassen sich die Ressourcen besser abstrahieren. Benötigt ein Add-on beispielsweise Zugriff auf ein persistentes Volume, stellt es diese Anforderung an die von Kubernetes verwaltete Speicherklasse. Das fordernde Add-on muss daher gar nicht wissen, welcher Storage-Treiber im Cluster aktiv ist und wie dieser das Volumen bereitstellt. Nach demselben Prinzip abstrahiert Kubernetes auch Netzwerkressourcen.
Grundlagen von KubeVirt
KubeVirt [1] gliedert sich wie alle anderen Add-ons in das Framework ein. Das Open-Source-Projekt gründete Red Hat bereits 2016 als Folgeprojekt der Enterprise-Virtualisierung oVirt, die seit Ende 2022 nicht mehr weiter entwickelt wird. Im Backend nutzt KubeVirt bekannte und etablierte Technologien wie libvirt und den Qemu/KVM-Stack. KVM steuert dabei die Virtualisierungsfunktionen der CPUs, während Qemu die Maschine und deren Peripherie simuliert. Damit läuft KubeVirt auf allen Systemen, deren CPU Virtualisierungsfunktionen bereitstellt. Für Testinstallationen genügt im Zweifelsfall auch eine virtuelle Maschine, sofern diese "Nested Virtualization", also eine VM in einer VM beherrscht.
Damit KubeVirt nicht die Installation des Host-OS verändern muss, packt es die Virtualisierungsfunktionen des Qemu-KVM-Stacks selbst in Container. Diese müssen jedoch auf dem jeweiligen Host in "privileged" Pods laufen, um Zugang zu den Virtualisierungsfunktionen der Host-CPUs zu erhalten. Auf der Clientseite führt KubeVirt zusätzlich zum regulären kubectl-Kommando ein weiteres CLI-Tool zur Steuerung der VMs ein: virtctl. Als vollständig integrierte Kubernetes-Erweiterung liefert KubeVirt damit auch Enterprise-VM-Funktionen wie automatische VM-Failover bei einem Host-Ausfall. Um die Redundanz der Datenträger kümmert sich das passende Storage-Add-on, das für KubeVirt persistente Volumen (PV) als Block-Storage zur Verfügung stellen muss. Ein reines Dateisystem wie NFS funktioniert hier nicht.
Wer sich gut mit Kubernetes auskennt, kann KubeVirt manuell aufsetzen. Dazu genügt bereits ein K3s- oder MicroShift-Single-Node-Setup, etwas Geduld und viele Zeilen YAML-Definitionen. Eine solche händische Installation funktioniert zwar, lässt aber jeglichen Bedienkomfort vermissen. Besser arbeitet KubeVirt integriert in eine Distribution. Die zwei großen Kubernetes-Distributionen OpenShift (Red Hat) und Rancher (SUSE) nutzen jedoch sehr unterschiedliche Architekturen, um KubeVirt zu integrieren.
KubeVirt auf OpenShift
In Red Hat OpenShift oder dessen freier Variante OKD lässt sich KubeVirt einfach über den OperatorHub auf einem bestehenden Cluster nachinstallieren — sofern dieser auf physischen Servern läuft oder die OpenShift-Nodes Nested Virtualization unterstützen. KubeVirt setzt wie erwähnt eine Storage-Klasse voraus, die Block-PVs für virtuelle Maschinen bereitstellen kann.
Um virtuelle Maschinen zu bauen, erzeugt der Admin zunächst passende Templates. Der KubeVirt-Operator bringt dabei bereits einen Katalog mit Vorlagen mit. KubeVirt kann bestehende RAW- oder QCOW-Disk-Images klonen. Alternativ möglich ist eine traditionelle Installation der VM, beispielsweise von einem OS-ISO. Qemu simuliert in den KubeVirt-VM dieselbe Hardware und Firmware, die auch bei herkömmlichen KVM-Desktop-VMs zum Einsatz kommen. Es gibt den Maschinentyp Q35, der dank UEFI-Secure-Boot auch moderne Windows-Systeme betreiben kann. Um Storage- und LAN-Adapter in der VM kümmern sich die paravirtualisierten VirtIO-Devices.
Welche Knoten im OpenShift/OKD-Cluster VMs ausführen können, bestimmt der Administrator über Node-Tags. Es steht Unternehmen daher offen, ob sie Container- und VM-Workloads gemeinsam auf einem Node betreiben möchten oder ob sie VMs und Application-Pods voneinander trennen und unterschiedlichen Node-Gruppen zuweisen. Als Speicher kann OpenShift/OKD alle unterstützten und Block-Storage-fähigen Treiber verwenden. In hyperkonvergenten Szenarios dürften die meisten Administratoren auf den OpenShift-Storage-Operator zurückgreifen, der auf den Open-Source-Projekten Rook und Ceph basiert. Aber auch externe Werkzeuge wie Trident für NetApp-Speichersysteme funktionieren.
Interessant für Service Provider ist dabei auch das Projekt HyperShift. Es nutzt die VM-Funktionen des KubeVirt-Operators, um mehrere separate virtualisierte OpenShift-Cluster auf einem physischen Cluster laufen zu lassen. Somit lassen sich mehrere Cluster mit voneinander getrennten Root-Zugängen betreiben, die aber gemeinsam zugrundeliegende Ressourcen wie den Ceph-Storage verwenden.
Gute Integration bei Red Hat
Die Integration von KubeVirt auf OpenShift lässt nur wenig Wünsche offen. Die Web-GUI stellt viele komfortable Funktionen bereit, auch wenn es einige Abstriche gegenüber traditionellen Enterprise-Virtualisierungsplattformen gibt. Wer etwa bei einer einmal definierten VM Änderungen an den Disk-Zuordnungen vornehmen will, findet nicht alle dafür benötigten Funktionen in der grafischen Oberfläche und endet im Zweifelsfall in bester Kubernetes-Manier wieder mit dem Editor im YAML-Code.
Zudem kommt es gelegentlich vor, dass der sanfte Shutdown einer VM via Web-GUI nicht funktioniert. Der Bedienoberfläche fehlt hier beispielsweise der Button "Force Power Down". In solchen Fällen findet sich der Nutzer einmal mehr auf der CLI wieder, wo er per
virtctl stop <VM-Name> --force die widerspenstige VM zum Abschalten zwingt.Generell ist zu erwähnen, dass das Gespann aus OpenShift, OpenShift-Virtualisierung und OpenShift-Storage ein großes und ressourcenintensives Setup darstellt, das sich in der Regel auf großen Datacenter-Installationen finden dürfte. Für eine kleine drei- bis fünf-Knoten-Umgebung in einer Zweigstelle eignet sich solch ein Stack eher weniger.
Rancher Harvester
SUSE implementiert KubeVirt ein wenig anders. Hier setzt der Hersteller auf ein separates Hyperconverged-Werkzeug namens Harvester. Ähnlich dem CoreOS-Projekt (Fedora/RHEL) greift SUSE hier auf eine abgespeckte, "immutable" Linux-Distribution namens "Elemental for SLES/Opensuse Leap" zurück. Elemental besteht dabei nur aus den unterstützten Hardwaretreibern, dem Kernel, einer Container-Runtime und Kubernetes. Alle weiteren Funktionen arbeiten in Containern. Für interessierte Nutzer stellt Suse das Elemental-Toolkit [2] bereit, mit dem sich eigene Immutable-Images bauen lassen. Diese sind dann beispielsweise für schlanke K3s-Clusterknoten einsetzbar.
Die Harvester-Distribution vereint dabei ein Elemental-Image mit den Basis-Kubernetes-Funktionen, Longhorn (verteilter iSCSI-Speicher für Kubernetes), KubeVirt und eine simple Web-UI ähnlich der von Rancher. Während der unkomplizierten Harvester-Installation vom Elemental-Boot-Image wählt der Administrator, ob er einen neuen Cluster erstellen möchte oder den Knoten einem bestehenden Cluster hinzufügen will. Der erste Node stellt die Web-GUI auf einer virtuellen IP-Adresse bereit. Somit können auch andere Knoten im Cluster diese Funktion übernehmen. Für einfache Testaufstellungen arbeitet Harvester aber bereits mit einem einzigen Knoten.
Einmal installiert, präsentiert sich Harvester mit einer sehr einfachen Oberfläche, die an bekannte Enterprise-Virtualisierungsumgebungen erinnert. Nutzer können ISO-Images hochladen und in wenigen Schritten neue VMs erstellen und starten. Den Zugriff auf die GUI der VMs erfolgt über eine Browser-basierte VNC-Konsole. Zudem sind die üblichen Funktionen wie Snapshots oder Live-Migration vorhanden. Vom darunter liegenden Kubernetes merkt der Admin wenig. Auch gibt es in Harvester keine Option, reguläre Container-Workloads laufen zu lassen.
Einen LAN-Adapter der Harvester-Knoten nutzt die Umgebung für ihr Managementnetzwerk. Weitere Netzwerkschnittstellen kann der Administrator dann gebridgten VM-Networks zuweisen. VMs auf diesen virtuellen LANs haben dann direkten Netzwerkzugriff.
Ähnlich wie bei OpenShift fehlt es der Harvester-GUI hier und da an Funktionen. Wer nach einer VM-Installation beispielsweise die Boot-Reihenfolge der Datenträger ändern will, findet dafür keine Option, sondern muss den YAML-Code im Editor anpassen.
VMs ja, Container nein
Mit den gebotenen Funktionen ist Harvester ein alleinstehender, hyperkonvergenter Ansatz nur für VMs. Jedoch lässt sich ein Harvester-Cluster mit wenigen Schritten in eine bestehende Rancher-Umgebung integrieren. Betreibt das Unternehmen bereits eine solche, kann es dort die Verbindung zu Harvester herstellen und dann die Harvester-Funktionen via Rancher-GUI bedienen. Richtig interessant wird es aber erst, wenn der Harvester-Node-Driver zum Einsatz kommt. Über diesen Treiber steuert Rancher den Rollout und das Management von weiteren Kubernetes-Clustern mit K3s- oder RKE2-Knoten, die auf Harvester laufen.
Der Nutzer stellt sich hier in einem Menü erst einmal die gewünschte Clusterkonfiguration zusammen, also wie viele Knoten zum Einsatz kommen, welche Linux- und Kubernetes-Distribution der Cluster verwendet und welche Ressourcen wie Disks, CPUs und Speicher die VMs erhalten. Im Anschluss rollt Rancher alle benötigten VMs auf Harvester aus, konfiguriert die Umgebung und übernimmt die neu ausgerollten Kubernetes-Cluster im Rancher-Multi-Cluster-Management. Diese virtuellen Kubernetes-Cluster auf Harvester-VMs können dabei Ressourcen wie den darunter liegenden Longhorn-Storage mitbenutzen.
Wie angedeutet stellt Kubernetes unter der Haube von Harvester erst einmal nur einen hyperkonvergenten Cluster für VMs und verteilten Storage bereit. Container für Applikationen kommen hier nicht zum Einsatz. Das Open-Source-Tool liefert einen soliden Funktionsumfang mit vergleichsweise geringen Hardwareanforderungen und kann damit problemlos teure vSphere-Installationen ersetzen. Spannend wird Harvester im Zusammenspiel mit Ranchers Multicloud-Management, das mehrere Kubernetes-Cluster automatisiert auf Harvester ausrollen und verwalten kann.
Fazit
OpenShift und Rancher lösen die VM-Integration in Form von KubeVirt zwar mit demselben Toolkit, aber mit sehr unterschiedlichen Architekturen. Während OpenShift VMs direkt integriert und den parallelen Betrieb von VMs und Pods auf denselben Knoten zulässt, trennt Rancher die VM-Plattform mit Harvester auf eigenen Knoten von der Container-Plattform ab. Beide Ansätze haben ihre Vor- und Nachteile. An Harvester gefällt, dass es auch sehr gut in kleinen und mittelgroßen Installationen als vSphere-Ersatz zum Einsatz kommen kann. Die Integration in das Rancher Management ist gut, vor allem wenn es um die Verwaltung mehrerer virtueller Rancher-Cluster auf der Harvester-Plattform geht.
Bei OpenShift gut gelungen ist die nahezu nahtlose Verzahnung der VMs mit containerisierten Applikationen. Aus Sicht des Admins besteht hier kaum mehr ein Unterschied zwischen einer Anwendung in einem Container-Pod oder einer VM, zumal Container und VMs gemeinsam in virtuellen Netzwerken laufen können. Allerdings macht OpenShift samt Virtualisierungskomponente erst in Umgebungen mit mehr als acht Knoten Sinn und zielt damit eher auf große Infrastrukturen.
(ln)
Link-Codes
[1] KubeVirt: https://kubevirt.io
[2] Elemental Toolkit: https://github.com/rancher/elemental-toolkit