OpenShift-Virtualisierung: Container, KVM und virtuelle Maschinen

OpenShift-Virtualisierung (Upstream-Projekt – Kubernetes: KubeVirt, siehe. hier und hier), früher bekannt als Container-native Virtualization, wurde als Funktionalität der OpenShift-Plattform vorgestellt, die für die Bereitstellung und Verwaltung von virtuellen Maschinen (VMs) als Grundeinheiten von Kubernetes gedacht ist. Eine solche Aufgabe ist technisch komplex aufgrund der grundlegenden Unterschiede der Technologien. Um das gesetzte Ziel zu erreichen, wurden vertraute Technologien auf Basis von Red Hat Enterprise Linux und KVM verwendet, die uns schon seit vielen Jahren begleiten und ihre Effizienz bewiesen haben.

In diesem Artikel werden wir die technischen Aspekte der OpenShift-Virtualisierung betrachten, die das Zusammenleben von VMs und Containern auf einer Plattform ermöglichen, die diese als eine Einheit verwaltet.

Rechenaufgaben

Container nutzen Mechanismen des Linux-Kernels wie Namespaces und cgroups zur Isolierung von Prozessen und zur Ressourcenverwaltung. In der Regel versteht man unter Prozessen Anwendungen wie Python, Java oder ausführbare Dateien, allerdings können dies in Wahrheit beliebige Prozesse sein, wie zum Beispiel bash, Emacs oder vim.

Was ist eine virtuelle Maschine? Aus Sicht des Hypervisors ist sie ebenfalls ein Prozess. Aber nicht ein Anwendungsprozess, sondern ein KVM-Prozess, der für die Ausführung einer bestimmten VM verantwortlich ist.

Das Container-Image enthält alle Werkzeuge, Bibliotheken und Dateien, die für die KVM-VM erforderlich sind. Wenn wir ein Pod der laufenden VM inspizieren, sehen wir dort Helfer und Prozesse von qemu-kvm. Darüber hinaus haben wir Zugang zu KVM-Tools zur Verwaltung virtueller Maschinen, wie qemu-img, qemu-nbd und virsh.

Da die virtuelle Maschine ein Pod ist, erbt sie automatisch die gesamte Funktionalität eines Pods in Kubernetes. Auf VM-Pods gelten genau wie bei normalen Pods Schemata und Kriterien desSchedulers wie Taints, Toleranzen, Affinität und Anti-Affinität. Außerdem profitieren Sie von hoher Verfügbarkeit usw. Ein wichtiger Unterschied besteht jedoch: Normale Pods migrieren nicht im gewohnten Sinne von Host zu Host. Wenn ein Knoten ausfällt, wird das Pod dort unterbrochen und einem anderen Knoten im Cluster zugewiesen. Bei einer virtuellen Maschine erwarten wir hingegen, eine live Migration zu sehen.

Um diese Lücke zu schließen, wurde eine benutzerdefinierte Ressourcenbeschreibung (CDR) erstellt, die den Mechanismus der Live-Migration beschreibt, der für die Initialisierung, Überwachung und Verwaltung der Live-Migrationen von VMs zwischen den Arbeitsknoten verantwortlich ist.

apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
  name: migration-job
spec:
  vmiName: fedora

Beim Deaktivieren eines Knotens werden automatisch Migrationsaufgaben für alle virtuellen Maschinen erstellt, die für die Eviction-Strategie die Live-Migration angegeben haben. Auf diese Weise kann das Verhalten der virtuellen Maschinen beim Verschieben zwischen den Knoten des Clusters kontrolliert werden. Sie können sowohl die Live-Migration einrichten als auch die VMs verwalten, wie auch alle anderen Pods.

Netzwerk

Jedes Kubernetes-System stellt die Kommunikation zwischen Knoten und Pods mithilfe von softwarebasierten SDN-Netzwerken sicher. OpenShift bildet da keine Ausnahme und verwendet ab Version 3 standardmäßig OpenShiftSDN dafür. Darüber hinaus wurde mit OpenShift 4 eine neue Funktion mit dem Namen Multus eingeführt, die es ermöglicht, mehrere Netzwerke verfügbar zu machen und Pods gleichzeitig damit zu verbinden.

Mit Multus kann der Administrator zusätzliche CNI-Netzwerke definieren, die dann von einem speziellen Operator, dem Cluster Network Operator, im Cluster bereitgestellt und konfiguriert werden. Danach werden Pods mit einem oder mehreren dieser Netzwerke verbunden, normalerweise mit dem standardmäßigen 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 Multus CNI für ein Bridge-Netzwerk am Interface eth1 konfiguriert wird:

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 von OpenShift-Virtualisierung bedeutet dies, dass VMs direkt mit einem externen Netzwerk verbunden werden können, ohne SDN zu umgehen. Dies ist wichtig für virtuelle Maschinen, die aus Red Hat Virtualization oder VMware vSphere nach OpenShift migriert wurden, da es bei Zugang auf OSI-Schicht 2 keine Änderung der Netzwerkeinstellungen gibt. Dies bedeutet auch, dass die VM eine Netzwerkadresse haben kann, die SDN umgeht. So können wir spezialisierte Netzwerkadapter effizient nutzen oder direkt über das Netzwerk mit dem SAN verbinden...

Weitere Informationen darüber, wie Sie OpenShift-Virtualisierungs-VMs mit Netzwerken verbinden, finden Sie hier. Darüber hinaus nmstate operator, der zusammen mit OpenShift-Virtualisierung bereitgestellt wird, bietet Ihnen eine weitere Ihnen wohlbekannte Möglichkeit, Netzwerkkonfigurationen auf physischen Knoten, die von Hypervisoren genutzt werden, zu erstellen und zu verwalten.

Speicherung

Die Verbindung und Verwaltung der Festplatten virtueller Maschinen im Rahmen der OpenShift-Virtualisierung erfolgt unter Verwendung von Kubernetes-Konzepten wie StorageClasses, PersistentVolumeClaims (PVC) und PersistentVolume (PV) sowie der für die Kubernetes-Umgebung typischen Speicherprotokolle. Damit erhalten Kubernetes-Administratoren und die für Anwendungen zuständigen Teams einen einheitlichen und gewohnten Verwaltungsmechanismus sowohl für Container als auch für virtuelle Maschinen. Für viele Administratoren von Virtualisierungsumgebungen mag dieses Konzept vertraut erscheinen, da es dasselbe Prinzip der Trennung von Konfigurationsdateien von VMs und Festplatten verwendet, das auch in OpenStack und vielen anderen Cloud-Plattformen angewendet wird.

Es ist jedoch nicht möglich, jedes Mal eine neue Festplatte für die VM zu erstellen, da wir bei der Migration von einem Hypervisor zu OpenShift die Daten erhalten müssen. Selbst wenn wir eine neue VM bereitstellen, geht das immer schneller aus einer Vorlage, als von Grund auf neu zu erstellen. Daher benötigen wir die Funktionalität zum Import vorhandener Festplatten.

Um diese Aufgabe zu vereinfachen, implementiert OpenShift-Virtualisierung das Projekt Containerized Data Importer (CDI), das den Import von Festplatten-Images aus verschiedenen Quellen auf das Erstellen eines Eintrags in PVC reduziert.

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 Abfolge von Aktionen aus, die im Bild unten dargestellt ist:

Nachdem CDI ausgeführt wurde, enthält PVC die Festplatte der virtuellen Maschine, die bereit zur Nutzung und im für OpenShift standardisierten Format ist…
Bei der Arbeit mit OpenShift-Virtualisierung ist auch OpenShift Container Storage (OCS) nützlich, eine Red Hat-Lösung auf Basis des Ceph-Dateisystems, die Funktionalität für persistente Speicher für Container bereitstellt. Neben den Standardzugriffsarten für PVC – RWO (Block) und RWX (Datei) – bietet OCS RWX für Raw-Blockgeräte, was bei der Einrichtung des gemeinsamen Blockzugriffs für Anwendungen mit hohen Leistungsanforderungen sehr hilfreich ist. Darüber hinaus unterstützt OCS den neuen Standard für Object Bucket Claim-Anfragen, der es Anwendungen ermöglicht, direkt auf das objektspeicherbasierte Datenspeicher zuzugreifen.

Virtuelle Maschinen in Containern

Wenn Sie interessiert sind, wie das funktioniert, wissen Sie, dass die OpenShift-Virtualisierung bereits in der Tech Preview in OpenShift 3.11 und höher verfügbar ist. Besitzer eines aktiven Abonnements für OpenShift können die OpenShift-Virtualisierung völlig kostenlos und ohne zusätzliche Schritte nutzen. Zum Zeitpunkt der Veröffentlichung dieses Beitrags sind OpenShift 4.4 und OpenShift-Virtualisierung 2.3 aktuell. Wenn Sie frühere Versionen verwenden, sollten Sie ein Upgrade durchführen, um die neuesten Funktionen zu erhalten. Die vollständig unterstützte Version der OpenShift-Virtualisierung wird in der zweiten Hälfte des Jahres 2020 erwartet.

Für weitere Informationen wenden Sie sich an die Dokumentation zu OpenShift für Installationsanweisungen, einschließlich dem Abschnitt zur Konfiguration von Multus, der Informationen zur Konfiguration von externen Netzwerken enthält.

Quelle: habr.com