Accesso alle macchine virtuali in ambienti Red Hat OpenShift Virtualization

OpenShift Virtualization è una valida soluzione per le applicazioni non containerizzate, ma può introdurre alcune complessità con i prodotti di virtualizzazione esistenti e i sistemi bare metal. Ad esempio, OpenShift può complicare le interazioni con le macchine virtuali (VM) essendo progettato per le applicazioni containerizzate, che in genere non vengono configurate e gestite tramite connessioni in entrata, o almeno non con le stesse connessioni con cui viene gestita o utilizzata una VM.

Questo articolo del blog illustra diversi metodi per accedere alle VM in esecuzione in un ambiente OpenShift Virtualization. Di seguito è riportato un breve riepilogo di questi metodi.

• Interfaccia utente di OpenShift

  Le connessioni VNC tramite l'interfaccia utente permettono l'accesso diretto alla console di una VM e sono fornite da OpenShift Virtualization. Le connessioni seriali tramite l'interfaccia utente non richiedono alcuna configurazione se si utilizzano le immagini fornite da Red Hat. Sono entrambi metodi di connessione utili per la risoluzione dei problemi di una VM.

• Comando virtctl

  Il comando virtctl utilizza il protocollo WebSocket per connettersi a una VM, fornendo l'accesso alla VM tramite console VNC, console seriale e SSH. L'accesso tramite console VNC e tramite console seriale sono forniti da OpenShift Virtualization come nell'interfaccia utente. Per l'accesso tramite console VNC è necessario un client VNC sul client che esegue il comando virtctl . Per l'accesso tramite console seriale è necessaria la stessa configurazione della VM necessaria per accedere tramite l'interfaccia utente. Per accedere tramite SSH, il sistema operativo della VM deve essere configurato per l'accesso SSH. Consulta la documentazione dell'immagine della VM per i requisiti di SSH.

• Rete Pod

  L'esposizione di una porta tramite un servizio permette le connessioni di rete a una VM. Utilizzando un servizio, è possibile esporre qualsiasi porta di una macchina virtuale. Le porte più comuni sono la 22 (SSH), la 5900+ (VNC) e la 3389 (RDP). I tre diversi tipi di servizio sono illustrati nel seguito di questo articolo del blog.

  • ClusterIP

    Un servizio ClusterIP espone la porta di una VM all'interno del cluster, così che le VM possano comunicare tra di loro, mentre non sono consentite le connessioni provenienti dall'esterno del cluster.

  • NodePort

    Un servizio NodePort espone la porta di una VM all'esterno del cluster tramite i nodi del cluster. La porta della VM è associata a una porta sui nodi. In genere, quest'ultima non è la stessa porta della VM. È possibile accedere alla VM connettendosi all'IP dei nodi e al numero di porta appropriato.

  • LoadBalancer

    Un servizio LoadBalancer fornisce un pool di indirizzi IP utilizzabili dalle VM. Questo tipo di servizio espone la porta di una VM all'esterno del cluster. Per la connessione alla VM viene utilizzato il pool di indirizzi IP acquisito o specificato.

• Interfaccia di livello 2

  È possibile configurare un'interfaccia di rete sui nodi del cluster affinché funga da bridge per la connessione di livello L2 a una VM. L'interfaccia di una VM si connette al bridge tramite NetworkAttachmentDefinition, che ignora lo stack di rete del cluster ed espone l'interfaccia della VM direttamente alla rete connessa tramite bridge. Ignorando lo stack di rete del cluster, il servizio ignora anche la sicurezza integrata del cluster, pertanto la VM deve essere protetta come un server fisico connesso a una rete.

Alcune informazioni sul cluster

Il cluster utilizzato in questo articolo si chiama wd e fa parte del dominio example.org . È costituito da tre nodi del piano di controllo bare metal (wcp-0, wcp-1, wcp-2) e da tre nodi di lavoro bare metal (wwk-0, wwk-1, wwk-2), che si trovano sulla rete principale del cluster, con IP 10.19.3.0/24.

MetalLB è configurato per fornire quattro indirizzi IP (10.19.3.112-115) alle VM di questa rete.

I nodi del cluster dispongono di un'interfaccia di rete secondaria sulla rete 10.19.136.0/24. Questa rete secondaria dispone di un server DHCP che fornisce gli indirizzi IP.

Nel cluster sono installati gli operatori indicati di seguito, tutti forniti da Red Hat.

Nel cluster sono in esecuzione alcune VM, eseguite nello spazio dei nomi blog .

• Una VM Fedora 38 denominata fedora.
• Una VM Red Hat Enterprise Linux 9 (RHEL9) denominata rhel9.
• Una VM Windows 11 denominata win11.

Connessione tramite l'interfaccia utente

Quando si visualizza una VM tramite l'interfaccia utente, sono disponibili diverse schede, ognuna delle quali fornisce dei metodi per visualizzare o configurare vari aspetti relativi alla VM. La scheda Console  fornisce tre metodi per la connessione alla VM: console VNC, console seriale o visualizzatore desktop (RDP). Il metodo RDP viene visualizzato solo per le VM che eseguono Microsoft Windows.

Console VNC

La console VNC è sempre disponibile per qualsiasi VM. Il servizio VNC è fornito da OpenShift Virtualization e non richiede alcuna configurazione del sistema operativo della VM, in quanto è già attivo.

Console seriale

La console seriale deve essere configurata all'interno del sistema operativo della VM. Se il sistema operativo non è configurato per l'output sulla porta seriale della macchina virtuale, questo metodo di connessione non funziona. Le immagini della VM fornite da Red Hat sono configurate per eseguire l'output delle informazioni di avvio alla porta seriale e per inviare una richiesta di accesso al termine del processo di avvio della VM. 

Visualizzatore desktop

Questa connessione richiede l'installazione e l'esecuzione di un servizio Desktop remoto (RDP) nella VM. Se nella scheda Console si sceglie di connettersi tramite RDP, il sistema segnala che al momento non esiste un servizio RDP per la VM e fornisce un'opzione per crearlo. Selezionando questa opzione viene visualizzata una finestra a comparsa con la casella di controllo Expose RDP Service. Selezionando la casella viene creato un servizio per la VM che consente le connessioni RDP.

Una volta creato il servizio, la scheda Console fornisce le informazioni per la connessione RDP 

e visualizza il pulsante Launch Remote Desktop per l'avvio del desktop remoto. Selezionando questo pulsante, il sistema scarica un file chiamato console.rdp. Se il browser è configurato per aprire i file .rdp , il file console.rdp viene aperto in un client RDP.

Connessione tramite il comando virtctl

Il comando virtctl fornisce l'accesso alla VM tramite console VNC, console seriale e accesso SSH, avvalendosi di un tunnel di rete sul protocollo WebSocket.

• L'utente che esegue il comando virtctl deve essere connesso al cluster dalla riga di comando.
• Se l'utente non si trova nello stesso spazio dei nomi della VM, è necessario specificare l'opzione --namespace .

Puoi scaricare la versione corretta di virtctl e di altri client dal tuo cluster, da un URL che sarà simile a https://console-openshift-console.apps.CLUSTERNAME.CLUSTERDOMAIN/command-line-tools. Puoi scaricarlo anche facendo clic sul punto interrogativo nella parte superiore dell'interfaccia utente e selezionando Command line tools.

Console VNC

Il comando virtctl si connette al server VNC fornito da OpenShift Virtualization. Nel sistema in cui viene eseguito il comando virtctl devono essere installati il comando virtctl e un client VNC.

Per aprire una connessione VNC è sufficiente eseguire il comando virtctl vnc . Le informazioni sulla connessione vengono visualizzate nel terminale, insieme alla nuova sessione della console VNC. 

Console seriale

La connessione alla console seriale tramite il comando virtctl viene eseguita eseguendo virtctl console. Se la VM è configurata per l'output sulla propria porta seriale, come spiegato in precedenza, dovresti poter visualizzare l'output del processo di avvio o un prompt di accesso.

$ 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

Il client ssh viene richiamato tramite il comando virtctl ssh . Con l'opzione -i di questo comando puoi specificare la chiave privata da utilizzare.

$ 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 ~]$ 

Puoi utilizzare anche il comando virtctl scp per trasferire file su una VM. Ne parlo qui perché il funzionamento è simile a quello del comando virtctl ssh .

Port forwarding

Il comando virtctl può anche inoltrare il traffico dalle porte locali di un utente a una porta nella VM. Per approfondirne il funzionamento, consulta la documentazione di OpenShift .

Il port forwarding può essere quindi utilizzato per l'inoltro del client OpenSSH locale alla VM, perché è più robusto e può sostituire il client ssh integrato del comando virtctl . Consulta la documentazione di Kubevirt per un esempio su come procedere.

Può risultare utile anche per la connessione a un servizio su una VM quando non intendi creare un servizio OpenShift per esporre la porta.

In questo esempio, nella VM chiamata fedora-proxy è installato il server web NGINX. Uno script personalizzato nella VM scrive alcune statistiche in un file chiamato process-status.out. Sono l'unica persona interessata ai contenuti del file, ma mi occorre visualizzarlo nel corso della giornata. Posso usare il comando virtctl port-forward per inoltrare una porta locale del mio laptop o desktop alla porta 80 della VM. Posso quindi creare un breve script per raccogliere i dati ogni volta che è necessario.

#! /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 $$

L'esecuzione dello script mi consente di ottenere i dati che mi occorrono e poi di eliminarli automaticamente.

$ 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

Connessione tramite una porta esposta sulla rete Pod (servizi)

Servizi

In OpenShift i servizi vengono utilizzati per esporre le porte di una VM al traffico in entrata, che può provenire da altre VM e pod o da una sorgente esterna al cluster.

In questo articolo del blog spiego come creare tre tipi di servizi: ClusterIP, NodePort e LoadBalancer. Il tipo di servizio ClusterIP non consente l'accesso alle VM dall'esterno. Tutti e tre i tipi forniscono l'accesso interno tra VM e pod, che è il metodo preferito per la comunicazione tra le VM all'interno del cluster. La tabella seguente elenca i tre tipi di servizio e il relativo ambito di accessibilità.

Puoi creare i servizi con il comando virtctl expo oppure definendoli in YAML, in questo caso dalla riga di comando o dall'interfaccia utente.

Iniziamo definendo un servizio tramite il comando virtctl.

Creazione di un servizio tramite il comando virtctl

Quando si utilizza il comando virtctl , l'utente deve essere connesso al cluster. Se l'utente non si trova nello stesso spazio dei nomi della VM, è possibile utilizzare l'opzione --namespace per specificare lo spazio dei nomi in cui si trova la VM.

Il comando virtctl expo vm crea un servizio che può essere utilizzato per esporre la porta di una VM. Di seguito sono elencate le comuni opzioni utilizzate insieme al comando virtctl expo per la creazione di un servizio.

Il comando seguente crea un servizio per l'accesso ssh a una VM chiamata RHEL9.

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

Visualizza il servizio per determinare la porta da utilizzare per accedere alla VM dall'esterno del cluster.

$ oc get service

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

Per il momento, eliminiamo la porta.

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

Creazione di un servizio tramite YAML

È possibile creare un servizio tramite YAML dalla riga di comando utilizzando il comando oc create -f o dall'interfaccia utente utilizzando un editor. Entrambi i metodi sono validi e offrono alcuni vantaggi. Creare uno script con la riga di comando è più semplice, ma con l'interfaccia utente sono disponibili informazioni sullo schema utilizzato per definire un servizio.

Esaminiamo innanzitutto il file YAML poiché è lo stesso per entrambi i metodi.

Una singola definizione di servizio può esporre una o più porte. Il file YAML riportato di seguito è un esempio di definizione di servizio che espone due porte, una per il traffico ssh e l'altra per il traffico VNC. Le porte sono esposte come NodePort. Le spiegazioni degli elementi chiave sono elencate dopo il codice YAML.

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

Ecco alcune impostazioni del file spiegate:

Creazione di un servizio tramite la riga di comando

Creiamo i due servizi nel file YAML utilizzando la riga di comando. Il comando che usiamo è 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

Nell'esempio, due porte sono esposte in un singolo servizio. Ora rimuoviamo il servizio utilizzando il comando oc delete service .

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

Creazione di un servizio tramite l'interfaccia utente

Ora creiamo lo stesso servizio utilizzando l'interfaccia utente. Innanzitutto, passa a Networking -> Services e seleziona Create Service. L'editor visualizzato mostra una definizione di servizio precompilata e un riferimento allo schema. Incolla il codice YAML precedente nell'editor e seleziona Create per creare un servizio.

Dopo aver selezionato Create, vengono visualizzati i dettagli del servizio. 

I servizi collegati a una VM possono essere visualizzati anche nella scheda VM Details o dalla riga di comando tramite il comando oc get service come abbiamo visto prima. Ora rimuoviamo il servizio.

$ 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

Creazione semplificata dei servizi SSH e RDP

L'interfaccia utente fornisce metodi per creare servizi SSH e RDP su VM in poche mosse.

Per abilitare SSH, ad esempio, nella scheda Details della VM è disponibile il menu a discesa SSH service type . Con questo menu puoi anche creare con facilità un servizio NodePort o LoadBalancer. 

È sufficiente selezionare il tipo di servizio che intendi creare. Nell'interfaccia utente viene visualizzato un comando per connettersi al servizio e attivarne la creazione. 

L'abilitazione di RDP avviene tramite la scheda Console della VM. Se la VM è basata su Windows, nel menu a discesa della console è visibile l'opzione Desktop viewer . 

Una volta selezionata, viene visualizzata l'opzione Create RDP Service . 

Selezionando l'opzione, viene visualizzata la finestra a comparsa Expose RDP Service. 

Una volta creato il servizio, la scheda Console contiene le informazioni sulla connessione. 

Esempio di connessione che utilizza un servizio ClusterIP

I servizi di tipo ClusterIP consentono la connessione tra le VM all'interno del cluster, e sono utili quando una VM fornisce un servizio ad altre VM, ad esempio un'istanza di database. Invece di configurare un database su una VM, esponiamo una porta SSH sulla VM Fedora usando un ClusterIP.

Creiamo un file YAML che a sua volta crea un servizio che espone la porta SSH della VM Fedora all'interno del cluster.

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

Applichiamo la configurazione.

$ 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

Utilizzando la VM RHEL9 possiamo connetterci alla VM Fedora tramite SSH.

$ 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 ~]$ 

Esempio di connessione tramite un servizio NodePort

Per questo esempio, esponiamo la porta RDP dalla VM windows11 utilizzando un servizio NodePort, in modo da poterci connettere al desktop e avere un'esperienza migliore rispetto all'utilizzo della scheda Console. Questa connessione verrà utilizzata da utenti attendibili, che conoscono gli indirizzi IP dei nodi del cluster.

Una nota su OVNKubernetes

Per impostazione predefinita, l'ultima versione del programma di installazione di OpenShift utilizza lo stack di rete OVNKubernetes. Se il cluster esegue lo stack di rete OVNKubernetes e viene utilizzato un servizio NodePort, il traffico in uscita dalle VM non viene consentito fino a quando routingViaHost è abilitato.

È sufficiente applicare una semplice patch al cluster per abilitare il traffico in uscita quando si utilizza un servizio NodePort.

$ 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
...

La patch non è necessaria se il cluster utilizza lo stack di rete OpenShiftSDN o un servizio MetalLB.

Esempio di connessione tramite un servizio NodePort

Creiamo il servizio NodePort definendolo prima in un file YAML.

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

Creiamo il servizio.

$ 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

Poiché si tratta di un servizio NodePort, possiamo connetterci al servizio utilizzando l'IP di qualsiasi nodo. Il comando oc get nodes mostra gli indirizzi IP dei nodi.

$ 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

Il programma client xfreerdp può essere utilizzato per le connessioni RDP. Il codice seguente fornisce le indicazioni per la connessione al nodo wcp-0 tramite la porta RDP esposta nel cluster.

$ 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.

La connessione alla VM è attiva. 

Esempio di connessione tramite un servizio LoadBalancer

Creiamo il servizio LoadBalancer definendolo in un file YAML. Utilizzeremo la VM Windows ed esporremo la porta RDP.

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

Creiamo il servizio e osserviamo che ottiene automaticamente un IP.

$ 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

Come si nota, ci connettiamo a EXTERNAL-IP dal servizio e alla porta RDP standard 3389 che abbiamo esposto utilizzando il servizio. L'output del comando xfreerdp indica che la connessione è riuscita.

$ 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.

Non allego nessuno screenshot perché si tratta dello stesso screenshot precedente.

Connessione tramite un'interfaccia di livello 2

Se l'interfaccia della VM viene utilizzata internamente e non esposta al pubblico, la connessione tramite NetworkAttachmentDefinition e un'interfaccia con bridge sui nodi può essere una valida scelta. Questo metodo ignora lo stack di rete dei cluster, il quale quindi non deve elaborare ogni pacchetto di dati, migliorando le prestazioni del traffico di rete.

Il metodo tuttavia presenta alcuni inconvenienti: le VM sono esposte direttamente a una rete e non sono protette da nessuna delle misure di sicurezza dei cluster. In caso di compromissione della VM, un intruso potrebbe accedere alla rete o alle reti a cui la VM è connessa. Se si utilizza questo metodo, è quindi necessario fare attenzione a garantire l'adeguata sicurezza del sistema operativo della VM.

NMSate

Una volta completato il deployment del cluster, l'operatore NMState fornito da Red Hat può essere utilizzato per configurare le interfacce fisiche sui nodi. È possibile applicare diverse configurazioni, tra cui bridge, VLAN, bond e altro ancora. Nel nostro esempio utilizziamo l'operatore per configurare un bridge su un'interfaccia inutilizzata in ciascun nodo del cluster. Consulta la documentazione di OpenShift per ulteriori informazioni sull'utilizzo dell'operatore NMState.

Procediamo ora alla configurazione di un semplice bridge su un'interfaccia inutilizzata nei nodi. L'interfaccia è collegata a una rete che fornisce il DHCP e distribuisce gli indirizzi sulla rete 10.19.142.0. Il codice YAML seguente crea un bridge chiamato brint sull'interfaccia di rete 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

Applica il file YAML per creare il bridge sui nodi di lavoro.

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

Usa quindi il comando oc get nncp per visualizzare lo stato di NodeNetworkConfigurationPolicy, e il comando oc get nnce per visualizzare lo stato della configurazione dei singoli nodi. Dopo aver applicato la configurazione, nello STATUS di entrambi i comandi viene visualizzato Available e in REASON SuccessfullyConfigured.

$ 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

Le VM non possono collegarsi direttamente al bridge che abbiamo creato, ma possono collegarsi a una definizione NetworkAttachmentDefinition (NAD). Il codice seguente crea una NAD denominata nad-brint che si collega al bridge  brint creato nel nodo. Consulta la documentazione di OpenShift per una spiegazione su come creare la NAD.

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
  }'

Dopo aver applicato il file YAML, possiamo visualizzare la NAD utilizzando il comando oc get network-attachment-definition .

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

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

Puoi creare la NAD anche tramite l'interfaccia utente passando a Networking -> NetworkAttachmentDefinitions.

Esempio di connessione tramite un'interfaccia di livello 2

Dopo aver creato la NAD, possiamo aggiungere un'interfaccia di rete alla VM o modificare e utilizzare un'interfaccia esistente. Per aggiungere una nuova interfaccia passiamo ai dettagli della VM e selezioniamo la scheda Network interfaces. Scegliamo l'opzione Add network interface. Possiamo modificare un'interfaccia esistente selezionando il menu con i tre puntini. 

Dopo aver riavviato la VM, la scheda Overview dei dettagli della VM mostra l'indirizzo IP ricevuto dal DHCP. 

Possiamo quindi connetterci alla VM utilizzando l'indirizzo IP acquisito da un server DHCP sull'interfaccia con bridge.

$ 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 ~]$ 

Il traffico SSH passa dalla VM al bridge e arriva all'interfaccia di rete fisica. Il traffico ignora la rete del pod e arriva sulla rete in cui risiede l'interfaccia con bridge. Se connessa in questo modo, la VM non è protetta da alcun firewall e tutte le sue porte sono accessibili, comprese quelle utilizzate per ssh e VNC.

Conclusioni

Abbiamo esaminato diversi metodi di connessione alle VM eseguite in OpenShift Virtualization. Tali metodi ci consentono di risolvere i problemi delle VM che non funzionano correttamente e di avviare la connessione per le attività di routine. Le VM possono interagire tra loro localmente all'interno del cluster mentre i sistemi esterni al cluster possono accedervi direttamente o utilizzando la rete dei pod dei cluster. Il trasferimento su OpenShift Virtualization dei sistemi fisici e delle VM eseguiti su altre piattaforme risulta quindi semplificato.