Implementing Virtual Machine Use Cases with UDNs | MPLF GmbH

Anwendung von (C)UDN mit Virtuellen Maschinen

Red Hat OpenShift Virtualization unterstützt auch das Betreiben von VMs neben Container-Workloads auf Red Hat OpenShift. VMs haben aber oft andere Anforderungen an das Netzwerk als Containerworkloads. UDNs mit der Layer 2 Topologie bieten die spezifischen Anforderungen, welche VM Workloads benötigen. Vorallem bei der Live Migration und bei IP Adressen Persistenz.

VM Netzwerke in Kubernetes

Da OpenShift Virtualization die VMs in das Kubernetes Pod Networking Model integriert und die VMs innerhalb eines Pods laufen, können VMs die Pod Netzwerk Infrastruktur von OVN-Kubernetes verwenden.

OVN-Kubernetes kümmert sich um die Pod Netzwerk Infrastruktur:

Verwaltet den Lebenszyklus des Pods, der die VM hostet.
Garantiert die Netzwerkkonnektivität für die VM innerhalb des Pods.
Erstellt die eth0-Schnittstelle auf dem Pod.
Erstellt zusätzliche Schnittstellen wie net1 für sekundäre VM-Netzwerke.
Erstellt die udn0-Schnittstelle auf dem Pod, wenn ein primäres UDN für den Namespace konfiguriert ist.

KubeVirt verwaltet den VM-Lebenszyklus und die Netzwerkanbindung:

Verwaltet den VM-Lebenszyklus innerhalb des Pods.
Erstellt virtuelle Netzwerkschnittstellen auf der VM.
Erstellt Netzwerkbindungen (Network Bindings), die die Netzwerkschnittstellen der VM mit den Netzwerkschnittstellen des Pods verbinden.
Unterstützt mehrere Bindungstypen:
- Masquerade: NAT-basierte Bindung für das Standard-Pod-Netzwerk. Wird nicht mit UDNs verwendet.
- l2bridge: Layer-2-Bindung für primäre UDNs. Erforderlich für die VM-Live-Migration mit persistenten IP-Adressen.
- SR-IOV: Hardware-Durchreichung (Passthrough) für hochperformante Netzwerkverbindungen.

Wenn man ein UDN an eine VM attached, verwendet KubeVirt standardmässig ein l2bridge Anbindungsprofil und verbindet sich direkt mit dem Pod Netzwerk von OVN-Kubernetes. VMs benötigen das l2bridge Anbindungsprofil um Live Migration und persistente IP Adressen zu ermöglichen. Diese Architektur ermöglicht es UDNs mit voller Layer 2 Konnektivität zu nutzen und gleichzeitig eine volle Integration in das OVN-Kubernetes-Netzwerk zu erlangen.

Warum VMs Layer 2 UDNs benötigen

Eigentlich unterstützt OVN-Kubernetes beides: primäre Layer und Layer 3 UDNs. In einer Layer 3 Topologie erhält jeder Node ein eigenes Subnetz, natürlich im gleichen CIDR Range (siehe Erstellen eines UDNs). Somit ändert sich bei einer Migration auf einen anderen Node die IP Adresse. Zudem kann so auch keine Live Migration geschehen. Layer 2 UDNs spannen ein flaches, logisches Netz über alle Cluster Nodes und garantieren so das Funktionieren von Live Migration und persistenten IP Adressen.

Folgen Vorteile bieten Layer 2 UDNs:

Persistente IP-Adressen während der Live-Migration und über Neustarts hinweg
Netzwerkisolierung zwischen Mandanten ohne Änderungen an der physischen Infrastruktur
Overlay-Netzwerke, die in Cloud-Umgebungen ohne VLAN-Zugriff funktionieren
Unterstützung für überlappende IP-Adressbereiche über verschiedene Namespaces hinweg

Limitation von primären UDNs mit VMs

Obwohl primäre UDNs erhebliche Vorteile bieten, bringt ihre Implementierung Kompromisse bei den Standard-Clusterfunktionen mit sich. Wenn Sie ein primäres UDN für einen Namespace definieren, können Workloads in diesem Namespace nicht mehr auf das Standard-Pod-Netzwerk zugreifen. Das primäre UDN ersetzt das Standard-Clusternetzwerk für Workloads innerhalb des Namespace. Obwohl der Pod die eth0-Schnittstelle für die Infrastrukturkommunikation mit dem Cluster (wie etwa mit dem Kubelet) beibehält, nutzen Anwendungen und VMs ausschließlich das primäre UDN für ihre Netzwerkanbindung. Infolgedessen sind die folgenden Verwaltungsfunktionen eingeschränkt:

Der Befehl virtctl ssh funktioniert nicht, da er für den Verbindungsaufbau auf die Routen des Standard-Pod-Netzwerks angewiesen ist.
Standardmäßige interne Cluster-Dienste, die vom Standard-Pod-Netzwerk abhängen, werden unerreichbar, es sei denn, Sie konfigurieren diese Dienste explizit innerhalb des UDN.
In- und Egress-Datenverkehrsmuster, die auf dem Verhalten des Standard-Clusternetzwerks basieren, müssen möglicherweise manuell konfiguriert werden.
Der Befehl oc port-forward kann nicht verwendet werden, um Ports an eine VM weiterzuleiten.
Headless-Dienste können nicht genutzt werden, um auf eine VM zuzugreifen.
Readiness- und Liveness-Probes können nicht definiert werden, um VM-Health-Checks zu konfigurieren, wenn Sie die l2bridge-Anbindung verwenden.

Gedanken zu Integration und Limitationen

Es wirkt wie ein Widerspruch, da am Anfang die „Integration in das Kubernetes-Netzwerk“ betont, während der zweite Abschnitt grundlegende Kubernetes-Netzwerkfunktionen auflistet, die nicht mehr funktionieren. Der Unterschied liegt in der Abgrenzung zwischen der Orchestrierung der Netzwerkinfrastruktur durch die Plattform und dem eigentlichen Fluss des Datenverkehrs.

Wenn im Text angegeben wird, dass UDNs die „Integration wahren“, bedeutet dies, dass OpenShift die Bereitstellung nativ orchestriert. OVN-Kubernetes, KubeVirt und Multus arbeiten zusammen, um das Netzwerk über standardmäßige Kubernetes-Manifeste bereitzustellen. Die Infrastruktur (Kubelet) kommuniziert weiterhin über eine eth0-Schnittstelle mit der Pod-Sandbox, um den Lebenszyklus des Pods zu verwalten.

Die im zweiten Abschnitt detaillierten Einschränkungen entstehen jedoch durch die Isolierung der Datenebene (Data Plane Isolation). Wenn man ein primäres UDN auf einen Namespace anwendet, wird die VM (über das l2bridge-Plugin) physisch an ein vollkommen separates, isoliertes Layer-2-Netzwerksegment gebunden. Sie wird dadurch vollständig aus den Routing-Tabellen des Standard-OpenShift-SDNs entfernt.

Diese Isolierung bricht von Natur aus Werkzeuge, die auf das Standard-Clusternetzwerk angewiesen sind:

virtctl ssh und oc port-forward: Diese Befehle leiten den Datenverkehr per Proxy über den Kubernetes-API-Server weiter. Da die IP-Adresse der VM nun auf einer isolierten UDN-Broadcast-Domäne und nicht mehr im Standard-Clusternetzwerk liegt, hat der API-Server keine Route, um die VM zu erreichen.
Liveness- und Readiness-Probes: Probes werden vom Kubelet des Host-Knotens ausgeführt. Bei Verwendung der l2bridge-Bindung wird die VM direkt mit dem UDN gebrückt und umgeht den Standard-Netzwerk-Stack des Knotens vollständig. Das Kubelet kann keinen TCP-/HTTP-Probe-Datenverkehr in dieses isolierte Layer-2-Segment senden.
Standardmäßige interne Dienste: ClusterIP-Dienste basieren darauf, dass OVN-Kubernetes den Datenverkehr im Standard-Pod-Netzwerk abfängt und Load-Balancing-Regeln anwendet. Da sich der VM-Datenverkehr vollständig auf dem UDN befindet, sind das standardmäßige interne Cluster-DNS und das Routing nicht erreichbar.

Der erste Abschnitt beschreibt den architektonischen Erfolg, Kubernetes zur Orchestrierung benutzerdefinierter VM-Netzwerke zu nutzen, während der zweite Abschnitt die physische Routing-Realität darlegt: Das Platzieren einer VM in einem dedizierten Layer-2-Netzwerksegment trennt deren Zugriff auf die standardmäßigen Layer-3-Cluster-Dienste.

Erweiterung der VM-Konnektivität auf Provider-Netzwerke

Primäre UDNs mit einer Layer 2 Topologie erstellen ein OVN Overlay Netzwerk innerhalb des Cluster. Um die VM Konnektivität zu externen Providern zu erweitern kann ein sekundäres ClusterUserDefinedNetwork erstellt werden. Diese verwendet die localnet Topologie. Die localnet Topologie überbrückt (Bridge) das sekundäre Netzwerk mit einem physikalischen Cluster Netzwerk. Diese ermöglicht es VMs mit Workloads ausserhalb des Cluster zu kommunizieren.

Anders als beim Layer 2 Overlay, benötigt die localnet Topologie zusätzliche Konfiguration des unterliegenden Open vSwitch (OVS) auf den Cluster Knoten. Die localnet Topologie ist eine sekundär-only Topologie.

Primäre UDNs für VMs konfigurieren

Bitte siehe Erstellen eines UDNs

Sobald das primäre UDN erstellt wurde können wir es in der VM Konfiguration verwenden, natürlich in selben Namespace:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: my-vm
  namespace: mplf-udn
spec:
  template:
    spec:
      domain:
        devices:
          interfaces:
            - name: mplf-l2-network # Der Name der Netzwerkschnittstelle, der mit dem Netzwerknamen übereinstimmen muss.
              binding:
                name: l2bridge # Das l2bridge-Binding-Plugin verbindet die VM-NIC mit dem UDN. 

      networks:
      - name: mplf-l2-network # Der Netzwerkname muss mit dem NIC Name übereinstimmen.
        pod: {} # Referenziert das Pod-Netzwerk, das das primäre UDN in diesem Namespace ersetzt.

Anwendungsfälle für VMs mit Layer-2-UDNs

Die Funktionalitäten von Layer-2-UDNs adressieren typische Herausforderungen für virtualisierte Workloads in OpenShift.

Hochverfügbare Anwendungen ohne Ausfallzeiten

VMs, die persistente Verbindungen bereitstellen (wie etwa Datenbankserver), können während Wartungsarbeiten auf einen anderen Knoten migrieren, ohne dass Client-Verbindungen unterbrochen werden. Die unveränderte IP-Adresse sorgt dafür, dass Load Balancer, DNS-Caches und Anwendungssitzungen ohne Neukonfiguration weiter funktionieren.

Mandantenfähige Umgebungen in der Public Cloud

Jeder Mandanten-Namespace nutzt sein eigenes primäres UDN mit einem dedizierten Subnetz. VMs in einem Mandanten-Namespace können nicht mit VMs in einem anderen Mandanten-Namespace kommunizieren, was die Datentrennung und -isolierung gewährleistet. Da UDNs softwaredefinierte Overlay-Netzwerke sind, funktioniert diese Isolierung in Cloud-Umgebungen, ohne dass ein VLAN-Zugriff oder Änderungen am Netzwerk des Cloud-Anbieters erforderlich sind.

Legacy-Workloads, die eine Layer-2-Adjazenz erfordern

Einige Anwendungen, wie etwa Clustering-Protokolle von Datenbanken, benötigen eine direkte Layer-2-Konnektivität zwischen den Knoten. Layer-2-UDNs bieten eine flache Broadcast-Domäne über den gesamten Cluster hinweg und erfüllen diese Anforderung ohne Umkonfiguration der physischen Netzwerkinfrastruktur.