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
