OpenShift-Virtualisierung (Upstream-Projekt â Kubernetes: KubeVirt, siehe und ), ehemals als Container-native Virtualization bekannt, wurde als Funktion der OpenShift-Plattform vorgestellt, die fĂŒr die Bereitstellung und Verwaltung von virtuellen Maschinen (VM) als grundlegende EntitĂ€ten von Kubernetes konzipiert ist. Diese Aufgabe ist technisch anspruchsvoll, da es fundamentale Unterschiede zwischen den Technologien gibt. Um dieses Ziel zu erreichen, wurden bewĂ€hrte Technologien basierend auf Red Hat Enterprise Linux und KVM eingesetzt, die uns seit vielen Jahren begleiten und ihre EffektivitĂ€t bewiesen haben.
In diesem Artikel betrachten wir die technischen Aspekte der OpenShift-Virtualisierung, die ein Zusammenleben von VMs und Containern auf einer Plattform ermöglichen, die sie als Einheit verwaltet.
Rechenaufgaben
Container nutzen Mechanismen des Linux-Kernels, wie Namespaces und cgroups, um Prozesse zu isolieren und Ressourcen zu verwalten. In der Regel versteht man unter Prozessen Anwendungen wie Python, Java oder ausfĂŒhrbare Dateien, aber tatsĂ€chlich können es auch beliebige Prozesse sein, wie bash, Emacs oder vim.
Was ist eine virtuelle Maschine? Aus der Sicht des Hypervisors handelt es sich ebenfalls um einen Prozess. Doch es ist nicht der Prozess einer Anwendung, sondern ein KVM-Prozess, der fĂŒr die AusfĂŒhrung einer bestimmten virtuellen Maschine verantwortlich ist.
Ein Container-Image enthĂ€lt alle Werkzeuge, Bibliotheken und Dateien, die fĂŒr die virtuelle Maschine KVM erforderlich sind. Wenn wir den Pod einer laufenden virtuellen Maschine inspizieren, sehen wir dort Helfer und Prozesse wie qemu-kvm. Zudem haben wir Zugriff auf KVM-Tools zur Verwaltung virtueller Maschinen, darunter qemu-img, qemu-nbd und virsh.
Da die virtuelle Maschine ein Pod ist, erbt sie automatisch alle Funktionen eines Pods in Kubernetes. Auf die VMs-Pods gelten ebenso wie fĂŒr normale Pods die Schemas und Kriterien desSchedulers wie Taints, Tolerations, AffinitĂ€t und AntiaffinitĂ€t. DarĂŒber hinaus profitieren Sie von hoher VerfĂŒgbarkeit usw. Es gibt jedoch einen wichtigen Unterschied: Normale Pods migrieren nicht von Host zu Host im gewohnten Sinne. Wenn ein Knoten ausfĂ€llt, wird der Pod auf diesem Knoten unterbrochen und einem anderen Knoten im Cluster zugewiesen. Bei einer virtuellen Maschine hingegen erwarten wir eine Live-Migration.
Zur Behebung dieses Problems wurde eine benutzerdefinierte Ressourcenbeschreibung (CDR) erstellt, die den Mechanismus der Live-Migration beschreibt. Dieser ist verantwortlich fĂŒr die Initialisierung, Ăberwachung und Verwaltung von Live-Migrationen von VMs zwischen Arbeitsknoten.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
Bei der Deaktivierung eines Knotens werden fĂŒr virtuelle Maschinen, bei denen die Evakuierungsstrategie auf Live Migration festgelegt ist, automatisch Migrationsaufgaben erstellt. Auf diese Weise kann das Verhalten der virtuellen Maschinen beim Wechsel zwischen den Knoten des Clusters kontrolliert werden. Sie können sowohl die Live Migration einrichten als auch die VMs verwalten, wie Sie es mit allen anderen Pods tun.
Netzwerk
Jedes Kubernetes-System gewĂ€hrleistet die Kommunikation zwischen Knoten und Pods durch Software-Defined Networking (SDN). OpenShift bildet da keine Ausnahme und verwendet seit der dritten Version standardmĂ€Ăig OpenShiftSDN. DarĂŒber hinaus gibt es in OpenShift 4 eine weitere neue Funktion namens Multus, die es ermöglicht, mehrere Netzwerke verfĂŒgbar zu machen und Pods gleichzeitig mit ihnen zu verbinden.
Mit Multus kann der Administrator zusĂ€tzliche CNI-Netzwerke definieren, die dann von einem speziellen Cluster Network Operator im Cluster bereitgestellt und konfiguriert werden. AnschlieĂend werden Pods mit einem oder mehreren dieser Netzwerke verbunden, ĂŒblicherweise mit dem Standard OpenShiftSDN und einem zusĂ€tzlichen Interface. SR-IOV-GerĂ€te, Standard-Linux-Bridges, MACVLAN- und IPVLAN-GerĂ€te können ebenfalls verwendet werden, wenn dies fĂŒr Ihre VM erforderlich ist. Das folgende Bild zeigt, wie man Multus CNI fĂŒr ein Bridge-Netzwerk auf dem Interface eth1 konfiguriert:
apiVersion: operator.openshift.io/v1
kind: Network
metadata:
name: cluster
spec:
additionalNetworks:
- name: multus1
rawCNIConfig: '{ "cniVersion": "0.3.1", "type": "bridge", "master": "eth1", "ipam":
{ "type": "static", "addresses": [ { "address": "191.168.1.1/24" } ] } }'
type: Raw
Im Kontext der OpenShift-Virtualisierung bedeutet dies, dass die VM direkt mit dem externen Netzwerk verbunden werden kann, ohne den Weg ĂŒber SDN zu nehmen. Dies ist wichtig fĂŒr virtuelle Maschinen, die von Red Hat Virtualization oder VMware vSphere auf OpenShift migriert wurden, da beim Zugriff auf die zweite OSI-Ebene keine Ănderungen der Netzwerkeinstellungen erforderlich sind. Das bedeutet auch, dass die VM eine Netzwerkadresse haben kann, die die SDN-Umgehung ermöglicht. Dadurch können wir spezialisierte Netzwerkkarten effektiv nutzen oder direkt auf das SAN zugreifenâŠ
Erfahren Sie mehr darĂŒber, wie Sie virtuelle Maschinen der OpenShift-Virtualisierung mit dem Netzwerk erstellen und verbinden können . AuĂerdem , der im Rahmen der OpenShift-Virtualisierung bereitgestellt wird, bietet Ihnen eine weitere vertraute Möglichkeit, Netzwerk-Konfigurationen auf physischen Knoten zu erstellen und zu verwalten, die fĂŒr Hypervisoren genutzt werden.
Speicherung
Die Verbindung und Verwaltung der Festplatten virtueller Maschinen innerhalb der OpenShift-Virtualisierung erfolgt unter Verwendung von Kubernetes-Konzepten wie StorageClasses, PersistentVolumeClaims (PVC) und PersistentVolume (PV) sowie von Standardspeicherprotokollen der Kubernetes-Umgebung. Auf diese Weise erhalten Kubernetes-Administratoren und die fĂŒr die Anwendungen zustĂ€ndigen Teams einen einheitlichen und vertrauten Mechanismus zur Verwaltung sowohl von Containern als auch von virtuellen Maschinen. FĂŒr viele Administratoren von Virtualisierungsumgebungen mag dieses Konzept vertraut erscheinen, da dasselbe Prinzip der Trennung von VM-Konfigurationsdateien und Festplatten verwendet wird, wie es in OpenStack und vielen anderen Cloud-Plattformen ĂŒblich ist.
Es ist jedoch nicht möglich, jedes Mal eine neue Festplatte fĂŒr die VM zu erstellen, da wir beim Migrieren von einem Hypervisor nach OpenShift die Daten behalten mĂŒssen. Selbst beim Bereitstellen einer neuen VM geht es immer schneller, dies aus einer Vorlage zu tun, als sie von Grund auf neu zu erstellen. Daher benötigen wir die FunktionalitĂ€t zum Importieren vorhandener Festplatten.
Um diese Aufgabe zu vereinfachen, implementiert OpenShift Virtualisierung das Projekt Containerized Data Importer (CDI), das den Import von Disk-Images aus mehreren Quellen zur Erstellung eines PVC-Eintrags konsolidiert.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: "fedora-disk0"
labels:
app: containerized-data-importer
annotations:
cdi.kubevirt.io/storage.import.endpoint: "http://10.0.0.1/images/Fedora-Cloud-Base-31-1.9.x86_64.qcow2"
spec:
storageClassName: ocs-gold
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
Genau dieser Eintrag aktiviert CDI und löst die Aktionsequenz aus, die im folgenden Bild dargestellt ist:
Nachdem CDI abgeschlossen ist, enthĂ€lt das PVC die virtuelle Maschinenfestplatte, die bereit zur Nutzung und in ein OpenShift-konformes Format konvertiert istâŠ
Bei der Arbeit mit OpenShift Virtualisierung kann auch der OpenShift Container Storage (OCS) von Red Hat, der auf dem Ceph-Dateisystem basiert, nĂŒtzlich sein. Es bietet dauerhaften Speicher fĂŒr Container. Neben den standardmĂ€Ăigen PVC-Zugriffsverfahren â RWO (Block) und RWX (Datei) â ermöglicht OCS RWX fĂŒr RohblockgerĂ€te, was bei der Bereitstellung eines gemeinsamen Blockzugriffs fĂŒr leistungsintensive Anwendungen sehr hilfreich ist. DarĂŒber hinaus unterstĂŒtzt OCS den neuen Standard zur Beantragung von Objekten, den Object Bucket Claim, der es Anwendungen ermöglicht, direkt auf Objektspeicher zuzugreifen.
Virtuelle Maschinen in Containern
Falls Sie interessiert sind, wie das funktioniert, wissen Sie, dass die OpenShift-Virtualisierung bereits im Tech Preview-Programm in OpenShift 3.11 und höher verfĂŒgbar ist. Besitzer eines aktiven OpenShift-Abonnements können die OpenShift-Virtualisierung kostenlos nutzen, ohne dass zusĂ€tzliche Schritte erforderlich sind. Zum Zeitpunkt der Veröffentlichung dieses Beitrags sind OpenShift 4.4 und OpenShift Virtualization 2.3 aktuell. Wenn Sie frĂŒhere Versionen verwenden, sollten Sie auf die neuesten Funktionen aktualisieren. Die vollstĂ€ndig unterstĂŒtzte Version der OpenShift-Virtualisierung wird voraussichtlich in der zweiten HĂ€lfte des Jahres 2020 veröffentlicht.
FĂŒr weitere Informationen wenden Sie sich an fĂŒr Installationsanleitungen, einschlieĂlich , der Informationen zur Konfiguration externer Netzwerke enthĂ€lt.
Quelle: habr.com
