Rete Open Virtual Network (OVN) in Red Hat OpenShift per gli amministratori di vSphere

Scopri come funziona la rete Open Virtual Networking (OVN) in " Red Hat OpenShift on IBM Cloud " rispetto a NSX-T e come utilizzare i tipi di rete User-Defined Network (UDN), Cluster User-Defined Network (CUDN) e Localnet.

Se avete già utilizzato NSX-T, ne avete già compreso il concetto di base. Open Virtual Networking (OVN) è il livello di rete definito dal software integrato in OpenShift. Sostituisce il precedente stack di rete " Calico " allo stesso modo in cui NSX-T ha sostituito lo standard " vSwitches, ", trasferendo l'intelligenza di rete nel software anziché fare affidamento sulla rete fisica sottostante. OVN gestisce l'intera rete interna del cluster: il modo in cui le macchine virtuali comunicano tra loro, come si collegano alle reti esterne e come viene isolato il traffico tra tenant o carichi di lavoro.

Quando si implementa un nuovo cluster ROKS, è necessario scegliere tra OVN e Calico al momento dell'implementazione. Non esiste un percorso di migrazione tra i due, proprio come non è possibile passare da un " vSwitch " standard a un " dvSwitch " su un sistema VM in esecuzione senza una transizione pianificata.

OVN è il livello di rete definito dal software integrato in Red Hat OpenShift on IBM Cloud. Analogamente a come NSX-T sostituisce l' vSwitches,, OVN sostituisce il vecchio stack di rete Calico trasferendo l'intelligenza di rete nel software, anziché fare affidamento sulla rete fisica sottostante. OVN gestisce l'intera rete interna del cluster, comprese le modalità di comunicazione tra le macchine virtuali, il modo in cui queste si collegano alle reti esterne e l'isolamento del traffico tra tenant o carichi di lavoro.

Quando si distribuisce un nuovo cluster di Red Hat® OpenShift® on IBM Cloud®, è necessario scegliere tra OVN e Calico al momento della distribuzione, poiché non esiste un percorso di migrazione tra i due. Il passaggio da uno stack di rete all'altro richiede una pianificazione della transizione, analogamente al passaggio da un' vSwitch standard a un' dvSwitch su una macchina virtuale in esecuzione.

Tipi di rete

La tabella seguente mette in relazione i concetti OVN con i costrutti più noti dell' vSphere:

Concetti OVN mappati su modelli di rete familiari dell' vSphere
Il concetto OVN	vSphere equivalente
UDN o CUDN	Segmento logico NSX oppure dvPortGroup
Rete dell'infrastruttura del cluster (primaria)	Servizi di background: controlli di integrità, DNS, servizi di Kubernetes
VM rete di carico di lavoro (secondaria)	La tua rete effettiva VM: l'indirizzo IP utilizzato dalla tua applicazione
Masquerade	Rete con Network Address Translation (NAT)- Le macchine virtuali possono connettersi all'esterno, ma non ricevono traffico in entrata direttamente
Scuola secondaria di secondo grado	Segmento overlay NSX isolato - indirizzi IP statici, controllo completo
Livello 2 - Primario	Segmento NSX instradato con un uplink BGP verso la rete fisica
Localnet	dvPortGroup supportato da VLAN - passthrough diretto alla rete fisica

UDN e CUDN

Red Hat OpenShift raggruppa i carichi di lavoro in spazi dei nomi. Pensate ai namespace come a gruppi di risorse o cartelle che isolano un’applicazione o un team dagli altri. Le definizioni di rete seguono lo stesso schema:

Rete definita dall'utente (UDN): Limitato a un singolo spazio dei nomi: l'equivalente di un gruppo di porte che può essere utilizzato solo da un cluster o da una cartella.
Rete definita dall'utente in cluster (CUDN): Può estendersi su più spazi dei nomi: l'equivalente di un dvPortGroup condiviso accessibile da più cluster.

Di solito si configurano le CUDN perché sono più flessibili ed evitano di dover definire più volte la rete per ogni namespace che deve accedere allo stesso segmento.

Rete dell'infrastruttura cluster rispetto alla rete dei carichi di lavoro " VM "

La terminologia è controintuitiva, quindi è importante comprendere questo concetto. OVN classifica le reti come primarie o secondarie, ma tali denominazioni descrivono il loro ruolo all’interno del cluster di Red Hat OpenShift on IBM Cloud, non la loro importanza per le macchine virtuali. La corrispondenza è la seguente:

Rete dell'infrastruttura del cluster (primaria): Infrastruttura di rete in background che gestisce il traffico interno di Kubernetes, come i controlli di integrità, il rilevamento dei servizi, gli indirizzi IP virtuali (VIP) dei bilanciatori di carico e il DNS interno. In genere, le macchine virtuali non utilizzano questa rete per il traffico delle applicazioni. Mantenila come rete mascherata. Questa rete deve essere presente affinché i pod e i servizi interni all' Red Hat OpenShift on IBM Cloud o continuino a funzionare.
VM rete di carico di lavoro (secondaria): Dove vengono eseguite le macchine virtuali. Le tue applicazioni utilizzano questa rete, ti connetti al suo indirizzo IP tramite SSH e gestisci la sua sottorete. Trattandosi di una rete secondaria, hai il pieno controllo sull'assegnazione degli indirizzi IP, compresa l'assegnazione statica. Questa rete è la scelta giusta per quasi tutti i carichi di lavoro delle macchine virtuali.

Dal punto di vista delle macchine virtuali, questa denominazione potrebbe sembrare controintuitiva. Dal punto di vista del cluster, "primario" indica "la rete propria del cluster", mentre "secondario" indica "tutto il resto che si collega ad esso" Per i carichi di lavoro delle macchine virtuali, l’aspetto secondario non è un elemento secondario. Questa rete è la rete principale.

Un namespace non necessita di una rete di infrastruttura cluster. Se le tue macchine virtuali non necessitano di servizi di tip Kubernetes, bilanciatori di carico o DNS interni, puoi saltare questa fase e utilizzare solo reti secondarie.

Topologie di rete

Masquerade - rete di infrastruttura cluster (NAT)

Utilizza questa rete come opzione predefinita per la rete primaria dell'infrastruttura del cluster e per i pod in esecuzione nel cluster. Se lo si utilizza per le reti delle macchine virtuali, funziona come una macchina virtuale dietro una regola NAT su un NSX Edge:

Le macchine virtuali possono avviare connessioni in uscita verso l'esterno.
Le macchine virtuali non possono ricevere connessioni in entrata dirette da fonti esterne. Il traffico deve passare attraverso un bilanciatore di carico o un servizio, proprio come si farebbe utilizzando una regola NAT di destinazione (DNAT) su un NSX Edge per rendere accessibile un servizio.
Le macchine virtuali utilizzano l'assegnazione automatica degli indirizzi IP. Non sei tu a gestirlo.
Le macchine virtuali possono utilizzare tutte le funzionalità di rete di Kubernetes, inclusi i bilanciatori di carico, i servizi, le politiche di rete e il DNS.

Alcuni casi d'uso edge potrebbero richiedere l'utilizzo della rete Masquerade per la macchina virtuale, ad esempio nei casi in cui le macchine virtuali necessitino di accesso diretto ai servizi Kubernetes. Tuttavia, nella maggior parte dei casi d'uso delle macchine virtuali non viene utilizzata la rete Masquerade.

Livello 2 primario - rete delle macchine virtuali direttamente instradabile (uplink BGP)

Questa topologia è equivalente a un segmento overlay NSX collegato a un gateway Tier-0 con la ridistribuzione delle rotte BGP abilitata. Utilizza questa opzione, meno comune, quando è necessario che le macchine virtuali siano direttamente raggiungibili dalle reti esterne senza passare attraverso un bilanciatore di carico o un NAT:

Le macchine virtuali ricevono gli indirizzi IP direttamente dalla sottorete del segmento e rimangono raggiungibili dall'esterno tramite il routing.
Le reti esterne raggiungono le singole macchine virtuali tramite gli annunci di route BGP provenienti da ciascun nodo di lavoro. Questo approccio è equivalente a ciò che fa il router di servizio (SR) NSX Edge quando ridistribuisce le rotte connesse.
Le macchine virtuali supportano il multicast e il broadcast.
Gli spazi dei nomi non possono utilizzare la funzione "masquerade" quando si abilita una rete primaria di livello 2. Le due cose non possono coesistere.

Attualmente VPC non supporta un servizio di routing dinamico (Border Gateway Protocol, BGP); pertanto, è necessario utilizzare rotte VPC personalizzate con next hop.

L'assegnazione degli indirizzi IP avviene tramite un sistema DHCP basato sul principio "primo arrivato, primo servito". Gli indirizzi IP non cambiano per tutta la durata di vita di una macchina virtuale, ma non è possibile assegnare in anticipo un indirizzo IP specifico a una determinata macchina virtuale. Se hai bisogno di indirizzi IP statici, utilizza invece una rete secondaria di livello 2.

Alcuni casi d'uso edge potrebbero richiedere la rete primaria per la macchina virtuale, ad esempio nei casi in cui le macchine virtuali necessitino di accesso diretto ai servizi Kubernetes. Tuttavia, nella maggior parte dei casi d'uso delle macchine virtuali non viene utilizzata la rete primaria.

Livello 2 secondario - rete dei carichi di lavoro delle macchine virtuali (segmento isolato)

Utilizza questo tipo di rete per quasi tutti i casi d'uso delle macchine virtuali. Questa topologia è equivalente a un segmento overlay NSX senza uplink esterno: un segmento dedicato di cui hai il controllo completo.

Questa rete supporta l'assegnazione di indirizzi IP statici. È possibile gestire l'assegnazione degli indirizzi IP, come ci si aspetta normalmente per i carichi di lavoro delle macchine virtuali.
Questa rete non si connette automaticamente al mondo esterno. Per consentire l'accesso dall'esterno, collegare un firewall o un router virtuale al segmento, proprio come si farebbe per collegare un NSX Edge o una macchina virtuale " pfSense " a un segmento in vSphere.
Supporta il multicast e il broadcast.
È possibile collegare più reti secondarie di livello 2 alla stessa macchina virtuale. Questa configurazione è utile per separare il traffico delle applicazioni, quello di gestione e quello di archiviazione in segmenti diversi.
La rete può estendersi su più spazi dei nomi quando è configurata come CUDN.

Questa rete rappresenta la scelta ideale per la maggior parte dei carichi di lavoro delle macchine virtuali nell'ambito della virtualizzazion Red Hat OpenShift.

Localnet - pass-through diretto delle VLAN

Questa topologia è l'equivalente più simile a un gruppo di porte standard supportato da VLAN o a un gruppo di porte virtuali distribuite ( dvPortGroup ) senza overlay NSX. La macchina virtuale si connette direttamente alla rete a cui è collegato l'host fisico:

Questa topologia non utilizza un overlay di rete definito dal software (SDN). Il traffico bypassa completamente la commutazione via software OVN.
Questa topologia non offre servizi di ret Red Hat OpenShift on IBM Cloud i quali il bilanciamento del carico, le politiche di rete o il DNS interno.
Questa topologia non prevede una gestione integrata degli indirizzi IP. Gli indirizzi IP vengono assegnati tramite le interfacce di rete virtuale (VNI) della VPC.
Questa topologia va configurata per ogni zona di disponibilità.
Questa topologia supporta più reti locali sulla stessa macchina virtuale.

Utilizza localnet per le macchine virtuali che necessitano di accesso diretto a una sottorete VPC esistente. Ad esempio, potresti migrare un carico di lavoro legacy che comunica con sistemi on-premises tramite una VLAN specifica oppure collegarti a una rete di storage esterna al cluster.

Riepilogo

Confronto tra le opzioni di topologia di rete OVN per i carichi di lavoro delle macchine virtuali
Tipo di rete	Ruolo	Accesso esterno	Indirizzi IP statici	Servizi Kubernetes	Trasmissione / multicast
Masquerade	Infrastruttura dei cluster	Traffico in uscita tramite NAT	No	Sì	No
Livello 2 primario	Macchine virtuali direttamente instradabili	Sì, tramite il routing BGP	No (solo DHCP)	Sì	Sì
Scuola secondaria di secondo grado	Rete dei carichi di lavoro delle macchine virtuali	Tramite un router o un firewall collegato	Sì	Sì	Sì
Localnet	Pass-through fisico delle VLAN	Accesso diretto alla VLAN	Manuale	No	Sì

Passi successivi

Consulta questi argomenti correlati per ulteriori dettagli sulle opzioni specifiche della rete OVN: