Herstellen einer Verbindung zu VMs in Red Hat OpenShift Virtualization

OpenShift Virtualization bietet eine großartige Lösung für nicht containerisierte Anwendungen, bringt jedoch einige Herausforderungen im Vergleich zu Legacy-Virtualisierungsprodukten und Bare Metal-Systemen mit sich. Eine dieser Herausforderungen ist die Interaktion mit virtuellen Maschinen (VMs). OpenShift ist auf containerisierte Anwendungen ausgerichtet, die normalerweise keine eingehenden Verbindungen zur Konfiguration und Verwaltung benötigen. Zumindest nicht die Art von Verbindungen, die eine VM für die Verwaltung oder Verwendung benötigen würde.

In diesem Blog werden verschiedene Methoden für den Zugriff auf VMs erläutert, die in einer OpenShift Virtualization-Umgebung ausgeführt werden. Im Folgenden finden Sie eine kurze Zusammenfassung dieser Methoden.

• Die Benutzeroberfläche (UI) von OpenShift

  VNC-Verbindungen über die UI bieten direkten Zugriff auf die Konsole einer VM und werden von OpenShift Virtualization bereitgestellt. Serielle Verbindungen über die UI erfordern keine Konfiguration, wenn von Red Hat bereitgestellte Images verwendet werden. Diese Verbindungsmethoden sind nützlich, um Probleme mit einer VM zu beheben.

• Der Befehl „virtctl“

  Der Befehl virtctl verwendet Websockets, um Verbindungen zu einer VM herzustellen. Er bietet Zugriff über die VNC-Konsole, die serielle Konsole und SSH auf die VM. Der Zugriff über die VNC-Konsole und die serielle Konsole werden von OpenShift Virtualization wie in der UI bereitgestellt. Für den Zugriff über die VNC-Konsole ist ein VNC-Client auf dem Client erforderlich, der den Befehl virtctl ausführt. Der Zugriff über die serielle Konsole erfordert dieselbe VM-Konfiguration wie der Zugriff über die serielle Konsole über die UI. Für den SSH-Zugriff muss das Betriebssystem der VM entsprechend konfiguriert sein. Informationen zu den SSH-Anforderungen finden Sie in der Dokumentation zum Image der VM.

• Das Pod-Netzwerk

  Durch die Bereitstellung eines Ports mit einem Service werden Netzwerkverbindungen zu einer VM ermöglicht. Ein Port auf einer VM kann mithilfe eines Service verfügbar gemacht werden. Die allgemeinen Ports sind 22 (ssh), 5900+ (VNC), 3389 (RDP). In diesem Blog werden 3 verschiedene Servicetypen gezeigt.

  • ClusterIP

    Ein ClusterIP-Service stellt den Port einer VM intern für den Cluster bereit. Dadurch können VMs miteinander kommunizieren, jedoch sind keine Verbindungen von außerhalb des Clusters zulässig.

  • NodePort

    Ein NodePort-Service macht den Port einer VM außerhalb des Clusters über die Cluster-Knoten verfügbar. Der Port der VM wird einem Port auf den Knoten zugeordnet. Der Port auf den Knoten entspricht in der Regel nicht dem Port auf der VM. Der Zugriff auf die VM erfolgt durch Herstellen einer Verbindung zu einer Knoten-IP und der entsprechenden Portnummer.

  • Load Balancer (LB)

    Ein LB-Service stellt einen Pool von IP-Adressen zur Verwendung durch die VMs bereit. Dieser Servicetyp stellt den Port einer VM extern für den Cluster bereit. Für die Verbindung mit der VM wird ein Pool erhaltener oder angegebener IP-Adressen verwendet.

• Eine Layer 2-Schnittstelle

  Eine Netzwerkschnittstelle auf den Knoten des Clusters kann als Bridge konfiguriert werden, um eine L2-Konnektivität zu einer VM zu ermöglichen. Die Schnittstelle einer VM stellt über eine NetworkAttachmentDefinition eine Verbindung zur Bridge her. Dadurch wird der Netzwerk-Stack des Clusters umgangen und die Schnittstelle der VM direkt für das überbrückte Netzwerk bereitgestellt. Durch das Umgehen des Netzwerk-Stacks des Clusters wird auch die integrierte Sicherheit des Clusters umgangen. Die VM sollte genauso gesichert werden wie ein physischer Server, der mit einem Netzwerk verbunden ist.

Informationen zum Cluster

Der in diesem Blog verwendete Cluster heißt wd und befindet sich in der Domain example.org . Er besteht aus 3 Bare Metal-Control Plane-Knoten (wcp-0, wcp-1, wcp-2) und 3 Bare Metal-Workerknoten (wwk-0, wwk-1, wwk-2). Diese Knoten befinden sich im primären Netzwerk 10.19.3.0/24 des Clusters.

MetalLB ist so konfiguriert, dass für VMs aus diesem Netzwerk 4 IP-Adressen (10.19.3.112-115) bereitgestellt werden.

Die Cluster-Knoten haben eine sekundäre Netzwerkschnittstelle im Netzwerk 10.19.136.0/24. Dieses sekundäre Netzwerk verfügt über einen DHCP-Server, der IP-Adressen bereitstellt.

Auf dem Cluster sind die folgenden Operatoren installiert. Diese Operatoren werden von Red Hat, Inc. bereitgestellt.

Auf dem Cluster werden mehrere VMs ausgeführt. Die VMs werden im Namespace blog ausgeführt.

• Eine Fedora 38-VM namens „fedora“
• Eine RHEL9-VM (Red Hat Enterprise Linux 9) namens „rhel9“
• Eine Windows 11-VM namens „win11“

Herstellen einer Verbindung über die UI

Beim Anzeigen einer VM über die UI sind verschiedene Registerkarten verfügbar. Diese bieten Methoden zum Anzeigen oder Konfigurieren verschiedener Aspekte der VM. Eine besondere Registerkarte ist die Registerkarte Console . Sie bietet 3 Methoden zum Herstellen einer Verbindung zur VM: VNC-Konsole, serielle Konsole oder Desktop Viewer (RDP). Die RDP-Methode wird nur für VMs mit Microsoft Windows angezeigt.

VNC-Konsole

Die VNC-Konsole ist immer für jede VM verfügbar. Der VNC-Service wird von OpenShift Virtualization bereitgestellt und erfordert keine Konfiguration des VM-Betriebssystems. Es funktioniert einfach.

Serielle Konsole

Die serielle Konsole muss im Betriebssystem der VM konfiguriert werden. Wenn das Betriebssystem nicht für die Ausgabe an den seriellen Port der VM konfiguriert ist, funktioniert diese Verbindungsmethode nicht. Die von Red Hat bereitgestellten VM-Images sind so konfiguriert, dass Sie Boot-Informationen an den seriellen Port ausgeben und eine Anmeldeaufforderung bereitstellen, sobald die VM ihren Startvorgang abgeschlossen hat. 

Desktop Viewer

Für diese Verbindung muss ein RDP-Service (Remote Desktop) auf der VM installiert sein und ausgeführt werden. Wenn Sie sich für eine RDP-Verbindung auf der Registerkarte „Console“ entscheiden, zeigt das System an, dass derzeit kein RDP-Service für die VM vorhanden ist, und bietet eine Option zum Erstellen eines neuen RDP-Service. Bei Auswahl dieser Option wird ein Popup-Fenster mit dem Kontrollkästchen „Expose RDP Service“ angezeigt. Durch Aktivieren dieses Kontrollkästchens wird ein Service für die VM erstellt, der RDP-Verbindungen zulässt.

Nachdem der Service erstellt wurde, enthält die Registerkarte „Console“ die Informationen für die RDP-Verbindung. 

Die Schaltfläche zum Starten des Remote Desktops (Launch) ist ebenfalls vorhanden. Bei Auswahl dieser Schaltfläche wird eine Datei namens console.rdp heruntergeladen. Wenn der Browser zum Öffnen von .rdp -Dateien konfiguriert ist, sollte er die Datei console.rdp in einem RDP-Client öffnen.

Herstellen einer Verbindung mit dem virtctl-Befehl

Der Befehl virtctl bietet mithilfe des WebSocket-Protokolls per Netzwerktunnel VM-Zugriff über die VNC-Konsole, die serielle Konsole und über SSH.

• Nutzende, die den Befehl virtctl ausführen, müssen über die Befehlszeile beim Cluster angemeldet werden.
• Befindet sich die Nutzerin oder der Nutzer nicht im selben Namespace wie die VM, muss die Option --namespace angegeben werden.

Die korrekte Version von virtctl und andere Clients können von Ihrem Cluster über eine URL wie https://console-openshift-console.apps.CLUSTERNAME.CLUSTERDOMAIN/command-line-tools heruntergeladen werden. Sie kann auch durch Klicken auf das Fragezeichensymbol oben in der UI und durch Auswählen von Befehlszeilentools heruntergeladen werden.

VNC-Konsole

Mit dem Befehl virtctl wird eine Verbindung zu dem von OpenShift Virtualization bereitgestellten VNC-Server hergestellt. Auf dem System, auf dem der Befehl virtctl ausgeführt wird, müssen der Befehl virtctl und ein VNC-Client installiert sein.

Das Herstellen einer VNC-Verbindung erfolgt einfach durch Ausführen des Befehls virtctl vnc . Im Terminal werden Verbindungsinformationen und eine neue VNC-Konsolensession angezeigt. 

Serielle Konsole

Die Verbindung zur seriellen Konsole mit dem Befehl virtctl erfolgt durch Ausführen von virtctl console. Wenn die VM für die Ausgabe an ihren seriellen Port konfiguriert ist, wie bereits erwähnt, sollte die Ausgabe vom Startvorgang oder eine Anmeldeaufforderung angezeigt werden.

$ virtctl console rhel9
Successfully connected to rhel9 console. The escape sequence is ^]


[    8.463919] cloud-init[1145]: Cloud-init v. 22.1-7.el9_1 running 'modules:config' at Wed, 05 Apr 2023 19:05:38 +0000. Up 8.41 seconds.
[  OK  ] Finished Apply the settings specified in cloud-config.
         Starting Execute cloud user/final scripts...
[    8.898813] cloud-init[1228]: Cloud-init v. 22.1-7.el9_1 running 'modules:final' at Wed, 05 Apr 2023 19:05:38 +0000. Up 8.82 seconds.
[    8.960342] cloud-init[1228]: Cloud-init v. 22.1-7.el9_1 finished at Wed, 05 Apr 2023 19:05:38 +0000. Datasource DataSourceNoCloud [seed=/dev/vdb][dsmode=net].  Up 8.95 seconds
[  OK  ] Finished Execute cloud user/final scripts.
[  OK  ] Reached target Cloud-init target.
[  OK  ] Finished Crash recovery kernel arming.

Red Hat Enterprise Linux 9.1 (Plow)
Kernel 5.14.0-162.18.1.el9_1.x86_64 on an x86_64

Activate the web console with: systemctl enable --now cockpit.socket

rhel9 login: cloud-user
Password: 
Last login: Wed Apr  5 15:05:15 on ttyS0
[cloud-user@rhel9 ~]$ 

SSH

Der SSH-Client wird mithilfe des Befehls virtctl ssh aufgerufen. Mit der Option -i dieses Befehls können Nutzende einen zu verwendenden Private Key angeben.

$ virtctl ssh cloud-user@rhel9-one -i ~/.ssh/id_rsa_cloud-user
Last login: Wed May  3 16:06:41 2023

[cloud-user@rhel9-one ~]$ 

Außerdem können mit dem Befehl virtctl scp Dateien auf eine VM übertragen werden. Ich erwähne den Befehl hier, weil er ähnlich funktioniert wie virtctl ssh .

Portweiterleitung

Mit dem Befehl virtctl kann auch der Datenverkehr von lokalen Ports an einen Port auf der VM weitergeleitet werden. Informationen zur Funktionsweise finden Sie in der OpenShift-Dokumentation .

Diese Option kann beispielsweise verwendet werden, um den robusteren, lokalen OpenSSH-Client an die VM weiterzuleiten, anstatt den integrierten SSH-Client des Befehls virtctl zu verwenden. Ein Beispiel hierzu finden Sie in der Kubevirt-Dokumentation .

Sie können auch eine Verbindung zu einem Service auf einer VM herstellen, wenn Sie keinen OpenShift-Service erstellen möchten, um den Port verfügbar zu machen.

Ich verwende beispielsweise eine VM namens fedora-proxy mit installiertem NGINX-Webserver. Über ein benutzerdefiniertes Skript auf der VM werden bestimmte Statistiken in eine Datei namens „process-status.out“ geschrieben. Ich bin die einzige Person, die sich für den Inhalt der Datei interessiert, würde mir diese Datei aber gern den ganzen Tag über ansehen. Ich kann den Befehl virtctl port-forward verwenden, um einen lokalen Port auf meinem Laptop oder Desktop zu Port 80 der VM weiterzuleiten. Ich kann ein kurzes Skript schreiben, mit dem die Daten jederzeit erfasst werden.

#! /bin/bash

# Create a tunnel
virtctl port-forward vm/fedora-proxy 22080:80 &

# Need to give a little time for the tunnel to come up
sleep 1

# Get the data
curl http://localhost:22080/process-status.out

# Stop the tunnel
pkill -P $$

Die Ausführung des Skripts liefert mir die gewünschten Daten und bereinigt sich anschließend selbst.

$ gather_stats.sh 
{"component":"","level":"info","msg":"forwarding tcp 127.0.0.1:22080 to 80","pos":"portforwarder.go:23","timestamp":"2023-05-04T14:27:54.670662Z"}
{"component":"","level":"info","msg":"opening new tcp tunnel to 80","pos":"tcp.go:34","timestamp":"2023-05-04T14:27:55.659832Z"}
{"component":"","level":"info","msg":"handling tcp connection for 22080","pos":"tcp.go:47","timestamp":"2023-05-04T14:27:55.689706Z"}

Test Process One Status: Bad
Test Process One Misses: 125

Test Process Two Status: Good
Test Process Two Misses: 23

Herstellen einer Verbindung über einen verfügbar gemachten Port im Pod-Netzwerk (Services)

Services

Services in OpenShift werden verwendet, um die Ports einer VM für den eingehenden Datenverkehr verfügbar zu machen. Dieser eingehende Datenverkehr kann von anderen VMs und Pods oder von einer Quelle außerhalb des Clusters kommen.

In diesem Blog wird das Erstellen von 3 Servicetypen veranschaulicht: ClusterIP, NodePort und LoadBalancer. Der Servicetyp „ClusterIP“ lässt keinen externen Zugriff auf die VMs zu. Diese 3 Typen bieten einen internen Zugriff zwischen VMs und Pods. Es handelt sich um die bevorzugte Methode, mit der VMs innerhalb des Clusters miteinander kommunizieren. In der folgenden Tabelle sind die 3 Servicetypen und deren Geltungsbereiche aufgeführt.

Services können mit dem Befehl virtctl expose oder durch Definition in YAML erstellt werden. Das Erstellen eines Service mit YAML kann entweder über die Befehlszeile oder die UI erfolgen.

Zuerst definieren wir einen Service mit dem Befehl „virtctl“.

Erstellen eines Service mit dem Befehl „virtctl“

Bei Verwendung des Befehls virtctl muss die Nutzerin oder der Nutzer beim Cluster angemeldet sein. Wenn sich die Nutzerin oder der Nutzer nicht im selben Namespace wie die VM befindet, kann die Option --namespace verwendet werden, um den Namespace anzugeben, in dem sich die VM befindet.

Mit dem Befehl virtctl expose vm wird ein Service erstellt, der verwendet werden kann, um den Port einer VM verfügbar zu machen. Im Folgenden finden Sie gängige Optionen, die beim Erstellen eines Service mit dem Befehl virtctl expose verwendet werden.

Mit dem folgenden Befehl wird ein Service für den SSH-Zugriff auf eine VM namens „RHEL9“ erstellt.

$ virtctl expose vm rhel9 --name rhel9-ssh --type NodePort --port 22

Zeigen Sie den Service an, um den Port zu ermitteln, der für den Zugriff auf die VM von außerhalb des Clusters verwendet werden soll.

$ oc get service

NAME               TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
rhel9-ssh          NodePort    172.30.244.228   <none>        22:32317/TCP   3s

Löschen wir den Port zunächst.

$ oc delete service rhel9-ssh
service "rhel9-ssh" deleted

Erstellen eines Service mit YAML

Das Erstellen eines Service mit YAML kann über die Befehlszeile mit dem Befehl oc create -f oder mithilfe eines Editors in der Benutzeroberfläche erfolgen. Beide Methoden funktionieren und jede hat ihre individuellen Vorteile. Die Befehlszeile lässt sich einfacher per Skript erstellen, aber die Benutzeroberfläche bietet Hilfestellung zu dem Schema, das zum Definieren eines Service verwendet wird.

Sehen wir uns zunächst die YAML-Datei an, da diese für beide Methoden identisch ist.

Eine einzelne Servicedefinition kann einen einzelnen oder mehrere Ports verfügbar machen. Die folgende YAML-Datei ist ein Beispiel für eine Servicedefinition, die 2 Ports bereitstellt, einen für SSH-Datenverkehr und einen für VNC-Datenverkehr. Die Ports werden als NodePort bereitgestellt. Erläuterungen zu den wichtigsten Elementen werden nach der YAML-Datei aufgelistet.

apiVersion: v1
kind: Service
metadata:
  name: rhel-services
  namespace: blog
spec:
  ports:
    - name: ssh
      protocol: TCP
      nodePort: 31798
      port: 22000
      targetPort: 22
    - name: vnc
      protocol: TCP
      nodePort: 31799
      port: 22900
      targetPort: 5900
  type: NodePort
  selector:
    kubevirt.io/domain: rhel9

Beachten Sie die folgenden Einstellungen in der Datei:

Erstellen eines Service über die Befehlszeile

Erstellen wir die beiden Services in der YAML-Datei über die Befehlszeile. Der zu verwendende Befehl lautet oc create -f.

$ oc create -f service-two.yaml 
service/rhel-services created

$ oc get services
NAME               TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                           AGE
rhel-services      NodePort    172.30.11.97     <none>        22000:31798/TCP,22900:31799/TCP   4s

Wir können sehen, dass 2 Ports in einem einzigen Service verfügbar gemacht werden. Entfernen wir nun den Service mit dem Befehl oc delete service .

$ oc delete service rhel-services
service "rhel-services" deleted

Erstellen eines Service über die UI

Erstellen wir denselben Service über die UI. Um einen Service über die UI zu erstellen, navigieren Sie zu „Networking -> Services“, und wählen Sie „Create Service“ aus. Ein Editor mit einer vorausgefüllten Servicedefinition und einer Referenz auf das Schema wird geöffnet. Fügen Sie die YAML-Datei von oben in den Editor ein, und wählen Sie Create aus, um einen Service zu erstellen.

Nachdem Sie Create ausgewählt haben, werden die Details des Service angezeigt. 

Die an eine VM angehängten Services können auch auf der Registerkarte „Details“ der VM oder über die Befehlszeile angezeigt werden, indem Sie wie zuvor den Befehl oc get service verwenden. Wir entfernen den Service, wie zuvor erläutert.

$ oc get services
NAME               TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                           AGE
rhel-services      NodePort    172.30.11.97     <none>        22000:31798/TCP,22900:31799/TCP   4s

$ oc delete service rhel-services
service "rhel-services" deleted

Einfaches Erstellen von SSH- und RDP-Services

Die UI bietet einfache Point and Click-Methoden zum Erstellen von SSH- und RDP-Services auf VMs.

Zur einfachen Aktivierung von SSH ist auf der Registerkarte „Details“ der VM das Dropdown-Menü SSH service type verfügbar. Das Dropdown-Menü ermöglicht zudem die einfache Erstellung eines NodePort- oder LoadBalancer-Service. 

Nachdem der Servicetyp ausgewählt wurde, wird der Service erstellt. Die UI zeigt einen Befehl an, mit dem eine Verbindung zum Service und dem von ihm erstellten Service hergestellt werden kann. 

RDP wird über die Registerkarte „Console“ der VM aktiviert. Handelt es sich bei der VM um eine Windows-basierte VM, wird Desktop Viewer zu einer Option im Dropdown-Menü der Konsole. 

Nach der Auswahl wird die Option Create RDP Service angezeigt. 

Wenn Sie die Option auswählen, wird das Popup Expose RDP Service angezeigt. 

Nachdem der Service erstellt wurde, werden auf der Registerkarte „Console“ die Verbindungsinformationen angezeigt. 

Beispielverbindung mit einem ClusterIP-Service

Services vom Typ „ClusterIP“ ermöglichen es VMs, sich in einem Cluster intern miteinander zu verbinden. Dies ist nützlich, wenn eine VM einen Service für andere VMs bereitstellt, beispielsweise eine Datenbankinstanz. Anstatt eine Datenbank auf einer VM zu konfigurieren, stellen wir einfach SSH auf der Fedora-VM mit einem ClusterIP-Service bereit.

Wir erstellen eine YAML-Datei, die einen Service erstellt, der den SSH-Port der Fedora-VM intern für den Cluster verfügbar macht.

apiVersion: v1
kind: Service
metadata:
  name: fedora-internal-ssh
  namespace: blog
spec:
  ports:
  - protocol: TCP
    port: 22
  selector:
    kubevirt.io/domain: fedora
  type: ClusterIP

Wenden wir nun die Konfiguration an.

$ oc create -f service-fedora-ssh-clusterip.yaml 
service/fedora-internal-ssh created

$ oc get service
NAME                  TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
fedora-internal-ssh   ClusterIP   172.30.202.64    <none>        22/TCP    7s

Unter Verwendung der RHEL9-VM können wir sehen, dass wir mittels SSH eine Verbindung zur Fedora-VM herstellen können.

$ virtctl console rhel9
Successfully connected to rhel9 console. The escape sequence is ^]

rhel9 login: cloud-user
Password: 
Last login: Wed May 10 10:20:23 on ttyS0

[cloud-user@rhel9 ~]$ ssh fedora@fedora-internal-ssh.blog.svc.cluster.local
The authenticity of host 'fedora-internal-ssh.blog.svc.cluster.local (172.30.202.64)' can't be established.
ED25519 key fingerprint is SHA256:ianF/CVuQ4kxg6kYyS0ITGqGfh6Vik5ikoqhCPrIlqM.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'fedora-internal-ssh.blog.svc.cluster.local' (ED25519) to the list of known hosts.
Last login: Wed May 10 14:25:15 2023
[fedora@fedora ~]$ 

Beispielverbindung mit einem NodePort-Service

Wir stellen für dieses Beispiel RDP über die VM windows11 mithilfe eines NodePort-Service bereit, um eine Verbindung zum Desktop herzustellen und so ein besseres IT-Erlebnis als über die Registerkarte „Console“ zu ermöglichen. Diese Verbindung kann von vertrauenswürdigen Nutzenden verwendet werden, da sie die IPs der Cluster-Knoten kennen.

Hinweis zu OVNKubernetes

Die neueste Version des OpenShift-Installationsprogramms verwendet standardmäßig den OVNKubernetes-Netzwerk-Stack. Wenn der Cluster den OVNKubernetes-Netzwerk-Stack ausführt und ein NodePort-Service verwendet wird, funktioniert der Egress-Datenverkehr von den VMs erst, wenn routingViaHost aktiviert ist.

Ein einfacher Patch für den Cluster ermöglicht Egress-Datenverkehr, wenn ein NodePort-Service verwendet wird.

$ oc patch network.operator cluster -p '{"spec": {"defaultNetwork": {"ovnKubernetesConfig": {"gatewayConfig": {"routingViaHost": true}}}}}' --type merge

$ oc get network.operator cluster -o yaml
apiVersion: operator.openshift.io/v1
kind: Network
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      gatewayConfig:
        routingViaHost: true
...

Dieser Patch ist nicht erforderlich, wenn der Cluster den OpenShiftSDN-Netzwerk-Stack oder den MetalLB-Service verwendet.

Beispielverbindung mit einem NodePort-Service

Wir erstellen den NodePort-Service, indem wir ihn zunächst in einer YAML-Datei definieren.

apiVersion: v1
kind: Service
metadata:
  name: win11-rdp-np
  namespace: blog
spec:
  ports:
    - name: rdp
      protocol: TCP
      nodePort: 32389
      port: 22389
      targetPort: 3389
  type: NodePort
  selector:
    kubevirt.io/domain: windows11

Erstellen Sie den Service.

$ oc create -f service-windows11-rdp-nodeport.yaml 
service/win11-rdp-np created

$ oc get service
NAME                  TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)           AGE
win11-rdp-np          NodePort    172.30.245.211   <none>        22389:32389/TCP   5s

Da es sich hierbei um einen NodePort-Service handelt, können wir unter Verwendung der IP eines beliebigen Knotens eine Verbindung zu ihm herstellen. Der Befehl oc get nodes zeigt die IP-Adressen der Knoten an.

$ oc get nodes -o=custom-columns=Name:.metadata.name,IP:status.addresses[0].address
Name    IP
wcp-0   10.19.3.95
wcp-1   10.19.3.94
wcp-2   10.19.3.93
wwk-0   10.19.3.92
wwk-1   10.19.3.91
wwk-2   10.19.3.90

Das Programm xfreerdp ist ein Client-Programm, das für RDP-Verbindungen verwendet werden kann. Wir weisen es an, eine Verbindung zum Knoten „wcp-0“ über den im Cluster bereitgestellten RDP-Port herzustellen.

$ xfreerdp /v:10.19.3.95:32389 /u:cnvuser /p:hiddenpass

[14:32:43:813] [19743:19744] [WARN][com.freerdp.crypto] - Certificate verification failure 'self-signed certificate (18)' at stack position 0
[14:32:43:813] [19743:19744] [WARN][com.freerdp.crypto] - CN = DESKTOP-FCUALC4
[14:32:44:118] [19743:19744] [INFO][com.freerdp.gdi] - Local framebuffer format  PIXEL_FORMAT_BGRX32
[14:32:44:118] [19743:19744] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_BGRA32
[14:32:44:130] [19743:19744] [INFO][com.freerdp.channels.rdpsnd.client] - [static] Loaded fake backend for rdpsnd
[14:32:44:130] [19743:19744] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel rdpgfx
[14:32:45:209] [19743:19744] [WARN][com.freerdp.core.rdp] - pduType PDU_TYPE_DATA not properly parsed, 562 bytes remaining unhandled. Skipping.

Es besteht eine Verbindung zur VM. 

Beispielverbindung mit einem LoadBalancer-Service

Wir erstellen den LoadBalancer-Service, indem wir ihn zunächst in einer YAML-Datei definieren. Wir verwenden die Windows-VM und stellen RDP bereit.

apiVersion: v1
kind: Service
metadata:
  name: win11-rdp-lb
  namespace: blog
spec:
  ports:
    - name: rdp
      protocol: TCP
      port: 3389
      targetPort: 3389
  type: LoadBalancer
  selector:
    kubevirt.io/domain: windows11

Erstellen Sie den Service. Wir sehen, dass er automatisch eine IP erhält.

$ oc create -f service-windows11-rdp-loadbalancer.yaml 
service/win11-rdp-lb created

$ oc get service 
NAME                  TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
win11-rdp-lb          LoadBalancer   172.30.125.205   10.19.3.112   3389:31258/TCP   3s

Wir können sehen, dass wir eine Verbindung zur EXTERNAL-IP vom Service und zum Standard-RDP-Port 3389 herstellen, die wir mit dem Service bereitgestellt haben. Die Ausgabe des Befehls [ xfreerdp zeigt, dass die Verbindung erfolgreich war.

$ xfreerdp /v:10.19.3.112 /u:cnvuser /p:changeme
[15:51:21:333] [25201:25202] [WARN][com.freerdp.crypto] - Certificate verification failure 'self-signed certificate (18)' at stack position 0
[15:51:21:333] [25201:25202] [WARN][com.freerdp.crypto] - CN = DESKTOP-FCUALC4
[15:51:23:739] [25201:25202] [INFO][com.freerdp.gdi] - Local framebuffer format  PIXEL_FORMAT_BGRX32
[15:51:23:739] [25201:25202] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_BGRA32
[15:51:23:752] [25201:25202] [INFO][com.freerdp.channels.rdpsnd.client] - [static] Loaded fake backend for rdpsnd
[15:51:23:752] [25201:25202] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel rdpgfx
[15:51:24:922] [25201:25202] [WARN][com.freerdp.core.rdp] - pduType PDU_TYPE_DATA not properly parsed, 562 bytes remaining unhandled. Skipping.

Es ist kein Screenshot beigefügt, da es sich um den gleichen Screenshot wie oben handelt.

Herstellen einer Verbindung über eine Layer 2-Schnittstelle

Wenn die Schnittstelle der VM intern verwendet werden soll und nicht öffentlich verfügbar gemacht werden muss, ist eine Verbindung mithilfe einer NetworkAttachmentDefinition und einer überbrückten Schnittstelle auf den Knoten eine geeignete Möglichkeit. Diese Methode umgeht den Cluster-Netzwerk-Stack, d. h., der Cluster-Netzwerk-Stack muss nicht jedes Datenpaket verarbeiten, was zu einer Steigerung der Performance beim Netzwerkdatenverkehr führen kann.

Diese Methode hat gewisse Nachteile: Die VMs werden direkt in einem Netzwerk bereitgestellt und sind nicht durch die Sicherheit des Clusters geschützt. Wenn eine VM kompromittiert wird, kann ein Eindringling Zugriff auf die Netzwerke erhalten, mit denen die VM verbunden ist. Bei Verwendung dieser Methode muss darauf geachtet werden, für die entsprechende Sicherheit im Betriebssystem der VM zu sorgen.

NMState

Der von Red Hat bereitgestellte NMState-Operator kann verwendet werden, um physische Schnittstellen auf den Knoten zu konfigurieren, nachdem der Cluster bereitgestellt wurde. Es können verschiedene Konfigurationen angewendet werden, darunter Bridges, VLANs, Bonds und mehr. Wir werden diesen Operator verwenden, um eine Bridge auf einer nicht verwendeten Schnittstelle auf jedem Knoten im Cluster zu konfigurieren. Weitere Informationen zur Verwendung des NMState-Operators finden Sie in der OpenShift-Dokumentation .

Wir konfigurieren eine einfache Bridge für eine nicht verwendete Schnittstelle auf den Knoten. Die Schnittstelle ist an ein Netzwerk angehängt, das DHCP bereitstellt und Adressen im Netzwerk 10.19.142.0 ausgibt. Die folgende YAML-Datei erstellt eine Bridge namens brint auf der Netzwerkschnittstelle ens5f1 .

---
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: brint-ens5f1
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ""
  desiredState:
    interfaces:
      - name: brint
        description: Internal Network Bridge
        type: linux-bridge
        state: up
        ipv4:
          enabled: false
        bridge:
          options:
            stp:
              enabled: false
          port:
            - name: ens5f1

Wenden Sie die YAML-Datei an, um die Bridge auf den Workerknoten zu erstellen.

$ oc create -f brint.yaml 
nodenetworkconfigurationpolicy.nmstate.io/brint-ens5f1 created

Verwenden Sie den Befehl oc get nncp , um den Status von NodeNetworkConfigurationPolicy anzuzeigen. Verwenden Sie den Befehl oc get nnce , um den Status der Konfiguration der einzelnen Knoten anzuzeigen. Sobald die Konfiguration angewendet wurde, wird für den STATUS beider Befehle Available angezeigt. Für REASON wird SuccessfullyConfigured angezeigt.

$ oc get nncp
NAME           STATUS        REASON
brint-ens5f1   Progressing   ConfigurationProgressing

$ oc get nnce
NAME                 STATUS        REASON
wwk-0.brint-ens5f1   Pending       MaxUnavailableLimitReached
wwk-1.brint-ens5f1   Available     SuccessfullyConfigured
wwk-2.brint-ens5f1   Progressing   ConfigurationProgressing

NetworkAttachmentDefinition

VMs können nicht direkt an die von uns erstellte Bridge angehängt werden. Sie können jedoch eine NAD (NetworkAttachmentDefinition) anhängen. Im Folgenden wird eine NAD namens nad-brint erstellt, die an die auf dem Knoten erstellte brint -Bridge angehängt wird. Eine Erläuterung zum Erstellen der NAD finden Sie in der OpenShift-Dokumentation .

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: nad-brint
  annotations:
    k8s.v1.cni.cncf.io/resourceName: bridge.network.kubevirt.io/brint
spec:
  config: '{
    "cniVersion": "0.3.1",
    "name": "nad-brint",
    "type": "cnv-bridge",
    "bridge": "brint",
    "macspoofchk": true
  }'

Nach dem Anwenden der YAML kann die NAD mit dem Befehl oc get network-attachment-definition angezeigt werden.

$ oc create -f brint-nad.yaml 
networkattachmentdefinition.k8s.cni.cncf.io/nad-brint created

$ oc get network-attachment-definition
NAME         AGE
nad-brint    19s

Die NAD kann auch über die UI erstellt werden, indem Sie zu „Networking -> NetworkAttachmentDefinitions“ navigieren.

Beispielverbindung über eine Layer 2-Schnittstelle

Mit der erstellten NAD kann der VM eine Netzwerkschnittstelle hinzugefügt oder eine vorhandene Schnittstelle für die Verwendung geändert werden. Wir fügen eine neue Schnittstelle hinzu, indem wir zu den Details der VM navigieren und die Registerkarte „Network Interfaces“ auswählen. Wählen Sie die Option Add network interface aus. Eine vorhandene Schnittstelle kann durch Auswählen des neben ihr angezeigten Kebap-Menüs geändert werden. 

Nach dem Neustart der VM wird auf der Registerkarte „Overview“ der VM-Details die von DHCP empfangene IP-Adresse angezeigt. 

Sie können jetzt über die IP-Adresse, die von einem DHCP-Server auf der überbrückten Schnittstelle abgerufen wurde, eine Verbindung zur VM herstellen.

$ ssh cloud-user@10.19.142.213 -i ~/.ssh/id_rsa_cloud-user

The authenticity of host '10.19.142.213 (10.19.142.213)' can't be established.
ECDSA key fingerprint is SHA256:0YNVhGjHmqOTL02mURjleMtk9lW5cfviJ3ubTc5j0Dg.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.19.142.213' (ECDSA) to the list of known hosts.

Last login: Wed May 17 11:12:37 2023
[cloud-user@rhel9 ~]$ 

Der SSH-Datenverkehr wird von der VM über die Bridge und über die physische Netzwerkschnittstelle übergeben. Der Datenverkehr umgeht das Pod-Netzwerk und scheint sich in dem gleichen Netzwerk wie die überbrückte Schnittstelle zu befinden. Die VM ist bei dieser Verbindung nicht durch eine Firewall geschützt, und alle Ports der VM sind zugänglich, einschließlich der für SSH und VNC verwendeten Ports.

Zusammenfassung

Wir haben verschiedene Methoden kennengelernt, um eine Verbindung zu VMs herzustellen, die in OpenShift Virtualization ausgeführt werden. Diese Methoden bieten Möglichkeiten zur Fehlerbehebung bei VMs, die nicht ordnungsgemäß funktionieren, und zur Verbindung mit ihnen für den täglichen Gebrauch. Die VMs können lokal innerhalb des Clusters miteinander interagieren, oder Systeme außerhalb des Clusters können entweder direkt oder über das Pod-Netzwerk des Clusters darauf zugreifen. Dies unterstützt den Übergang beim Verschieben von physischen Systemen und VMs auf anderen Plattformen zu OpenShift Virtualization.