Progettare la rete per la virtualizzazione di tipo “ Red Hat OpenShift ” su IBM Cloud VPC

Progettare la rete per la virtualizzazion Red Hat OpenShift su IBM Cloud VPC, includendo il networking VPC, il Software-Defined Networking (SDN) di OpenShift e le reti definite dall'utente (User-Defined Networks) di Open Virtual Networking (OVN).

La progettazione della rete in Red Hat OpenShift Virtualization su IBM Cloud VPC prevede i seguenti livelli distinti.

  • Rete VPC
  • Red Hat OpenShift networking
  • Rete OVN

Gli elementi chiave dell'architettura di rete sono illustrati nel seguente diagramma.

Red Hat OpenShift Virtualizzazione su Rete Virtualizzazione su Rete Virtualizzazione su Rete IBM Cloud
Red Hat OpenShift IBM Cloud

IBM Cloud VPC networking

Si utilizza la rete IBM Cloud VPC per distribuire e gestire le risorse cloud. Fornisce le basi per i carichi di lavoro, compresi i server virtuali, i container e le implementazioni bare metal, che possono contribuire a garantire la segmentazione della rete, la sicurezza e la scalabilità.

Per configurare un Red Hat® OpenShift®, è necessario creare una VPC Kubernetes Service cluster.

Rete privata predefinita con sottoreti

Per eseguire il provisioning di un cluster Red Hat OpenShift Kubernetes Service è necessario creare una sottorete VPC in almeno una zona di disponibilità. Per ulteriori informazioni, vedere Rete privata predefinita con sottoreti.

Programmi di bilanciamento del carico

Nel cluster Red Hat OpenShift Kubernetes Service viene distribuito un controller di ingresso Red Hat OpenShift che funge da endpoint di ingresso per il traffico di rete esterno. In un cluster Red Hat OpenShift Kubernetes Service, un bilanciatore di carico delle applicazioni VPC viene creato automaticamente per ogni cluster per esporre il controller di ingresso. Per ulteriori informazioni, vedere Bilanciatori di carico.

Red Hat OpenShift Kubernetes Service svolge le seguenti funzioni.

  • Il servizio DNS risolve il sottodominio della rotta al nome host del bilanciatore di carico VPC.
  • Il bilanciatore di carico VPC risolve il nome host VPC in un indirizzo IP esterno disponibile di un servizio di controller di ingresso che è stato segnalato come funzionante correttamente.
  • Il bilanciatore di carico VPC invia la richiesta a un servizio controller di ingresso.
  • Il controller di ingresso inoltra la richiesta all'indirizzo IP privato del pod dell'app tramite la rete privata.

endpoint privati virtuali

I Virtual Private Endpoint (VPE) negli ambienti Red Hat OpenShift Kubernetes Service sono utilizzati principalmente per consentire la connettività privata tra il cluster Red Hat OpenShift e i servizi della piattaforma IBM Cloud senza che il traffico di rete attraversi la rete Internet pubblica.

La tabella seguente elenca tutti gli endpoint privati virtuali che vengono forniti automaticamente da IBM Cloud per le operazioni essenziali del cluster.

Endpoint privati virtuali che vengono forniti per le operazioni di cluster.
VPE (Virtual Private Endpoint) Gestito da Descrizione
iks-api Kubernetes Service API
  • Accesso privato all'API IBM Cloud Kubernetes Service
  • Operazioni di gestione del cluster (comandi kubectl, oc)
  • Comunicazione tra nodo lavoratore e piano di controllo
  • Operazioni CLI IBM Cloud (comandi ibmcloud ks )
  • Abilita configurazioni del cluster solo private
iks-riaas Servizi dell'infrastruttura VPC
  • Accesso privato alle API dell'infrastruttura VPC
  • Provisioning e gestione del ciclo di vita dei nodi worker
  • Attacco e gestione dei volumi di storage
  • Operazioni di rete VPC (bilanciatori di carico, gruppi di sicurezza)
  • Gestione delle risorse dell'infrastruttura
  • Utilizzato dall'autoscaler del cluster IBM Cloud, dai driver CSI dello storage per le operazioni sui volumi, dai servizi di provisioning dei bilanciatori di carico, dai controllori del ciclo di vita dei nodi worker
registro iks Container Registry
  • Accesso privato a IBM Cloud Container Registry
  • Prelievo di immagini di container senza Internet pubblico
  • Accesso a spazi dei nomi di registro pubblici e privati
  • Eliminazione dei costi di uscita pubblici per il prelievo di immagini
iks-<id_cluster> Istanza di cluster specifica
  • Endpoint privato specifico per l'istanza del cluster
  • Accesso diretto all'API del cluster
  • Utilizzato per configurazioni del cluster solo private
  • Alternativa all'endpoint API regionale
  • Utilizzato da strumenti che richiedono accesso diretto al cluster, comunicazione da servizio a servizio all'interno del VPC, modelli di accesso privato al cluster
iks-cos-config Cloud Object Storage (Configurazione)
  • Accesso privato alle API di configurazione di IBM Cloud Object Storage
  • Operazioni di gestione e configurazione dei bucket
  • Gestione dei criteri IAM e del controllo degli accessi
  • Operazioni con le credenziali di servizio
iks-cos Cloud Object Storage (Dati)
  • Accesso privato a IBM Cloud Object Storage S3 API
  • Operazioni sul piano dati della memorizzazione degli oggetti (PUT/GET/DELETE)
  • Trasferimento dei dati di backup e ripristino
  • Accesso alla memorizzazione dei dati delle applicazioni

Red Hat OpenShift Reti di virtualizzazione

Red Hat OpenShift La virtualizzazione utilizza le funzionalità di rete di Red Hat OpenShift per fornire una rete flessibile e definita dal software per i server virtuali che vengono eseguiti insieme ai carichi di lavoro containerizzati. È importante capire la differenza tra la rete di server virtuali e la rete di pod. Ogni server virtuale viene eseguito all'interno di un pod virt-launcher che è sempre connesso alla rete pod predefinita.

┌────────────────────────────────┐
│          Worker Node           │
│  ┌──────────────────────────┐  │
│  │      virt-launcher       │  │  ← Kubernetes Pod Security Context
│  │          pod             │  │
│  │  ┌────────────────────┐  │  │
│  │  │   virtual server   │  │  │  ← KVM/QEMU Hypervisor Isolation
│  │  │       (QEMU)       │  │  │
│  │  └────────────────────┘  │  │
│  └──────────────────────────┘  │
└────────────────────────────────┘

A seconda di come si effettua il provisioning e la configurazione del server virtuale, esso condivide una rete pod (oppure può connettersi a reti diverse utilizzando multus).

L'esempio seguente descrive la rete di pod predefinita in Red Hat OpenShift che può essere modificata con OVN- Kubernetes.

Reti Pod (rete cluster)

  • Ogni pod riceve un indirizzo IP privato dalla rete del cluster secondo lo standard CIDR (Classless Inter-Domain Routing)
  • Fornisce comunicazione da pod a pod tra i nodi
  • I pod comunicano direttamente utilizzando i loro IP privati all'interno del cluster
  • I criteri di rete controllano il traffico pod-to-pod a livello 3/4
  • Modello di rete piatto - tutti i pod possono comunicare per impostazione predefinita
  • Nessun NAT tra i pod (comunicazione diretta da pod a pod)
  • I criteri di rete forniscono segmentazione e sicurezza
  • Rilevamento dei servizi basato su DNS all'interno del cluster
  • Quando un server virtuale viene eseguito all'interno del pod virt-launcher, l'indirizzo IP viene sottoposto a traduzione degli indirizzi di rete (NAT) con l'indirizzo IP del pod virt-launcher

Mascheramento dell'IP (NAT di origine (SNAT))

  • Quando i pod avviano connessioni in uscita verso reti esterne, l'IP di origine viene mascherato
  • L'indirizzo IP di origine del pacchetto di richiesta viene modificato in modo da corrispondere all'indirizzo IP del nodo di lavoro su cui è in esecuzione il pod
  • Il masquerading IP è necessario perché gli IP dei pod non sono instradabili al di fuori del cluster
  • Il traffico di ritorno viene demascherizzato all'IP del pod originale
  • I servizi esterni vedono le richieste provenienti dagli IP dei nodi worker, non dagli IP dei pod

ClusterIP servizio

I servizi forniscono endpoint stabili e bilanciamento del carico per i pod. Astraggono i pod IP e forniscono punti di accesso coerenti per le applicazioni. Il servizio ClusterIP fornisce le seguenti funzioni.

  • Crea un IP virtuale ( ClusterIP ) accessibile solo all'interno del cluster
  • ClusterIP è il tipo di servizio predefinito se non specificato
  • Fornisce il bilanciamento del carico interno tra i pod di backend
  • Utilizza kube-proxy o OVN- Kubernetes per la distribuzione del traffico

I seguenti casi d'uso sono un esempio di utilizzo di ClusterIP.

  • Comunicazione interna ai microservizi
  • Servizi di backend che non richiedono un accesso esterno
  • Servizi di database a cui accedono solo i carichi di lavoro del cluster
  • Scoperta del servizio interpodale

Servizio NodePort

I servizi forniscono endpoint stabili e bilanciamento del carico per i pod. Astraggono i pod IP e forniscono punti di accesso coerenti per le applicazioni. Il servizio NodePort fornisce le seguenti funzioni.

  • Espone il servizio su una porta statica (intervallo 30000-32767) su ogni nodo lavoratore
  • Rende il servizio accessibile attraverso <NodeIP>:<NodePort>
  • Crea automaticamente il servizio ClusterIP
  • Il traffico verso qualsiasi NodePort viene inoltrato al servizio

L'esempio seguente mostra il flusso di traffico di NodePort.

  • Il client esterno si connette a <WorkerNodeIP>:<NodePort>
  • I nodi inoltrano il traffico al servizio ClusterIP
  • Il servizio bilancia il carico ai pod di backend
  • La risposta segue il percorso inverso con SNAT (Source Network Address Translation)

I seguenti casi d'uso sono un esempio di come si utilizza NodePorts.

  • Ambienti di sviluppo e di test
  • Accesso esterno rapido senza load balancer
  • Integrazione con bilanciatori di carico esterni
  • Soluzioni di bilanciamento del carico personalizzate

Servizio del programma di bilanciamento del carico

Su IBM Cloud Red Hat OpenShift Kubernetes Service, il servizio di bilanciamento del carico fornisce automaticamente un bilanciatore di carico della rete VPC o un bilanciatore di carico delle applicazioni. Il servizio di load balancer fornisce le seguenti funzioni.

  • Fornitura automatica di un bilanciatore di carico esterno
  • Assegna un IP o un hostname esterno al servizio
  • Crea automaticamente i servizi NodePort e ClusterIP
  • Fornisce il bilanciamento del carico di livello 4 ai backend dei servizi

L'esempio seguente mostra il flusso di traffico in una VPC.

  • Il client esterno si connette all'IP o all'hostname del bilanciatore di carico VPC
  • Il bilanciatore di carico VPC distribuisce al nodo worker NodePorts
  • Node in avanti al servizio ClusterIP
  • Il servizio bilancia il carico ai pod di backend

I seguenti casi d'uso sono un esempio di come vengono utilizzati i bilanciatori di carico.

  • Applicazioni di produzione che richiedono un accesso esterno dedicato
  • Protocolli non HTTP (servizi TCP o UDP )
  • Applicazioni che necessitano di IP esterni stabili
  • Servizi che bypassano il livello di ingress o route

Red Hat OpenShift percorsi

Red Hat OpenShift I percorsi rendono i servizi accessibili al traffico di rete esterno associando i nomi di dominio completi (FQDN) ai servizi di backend, consentendo così l'accesso alle applicazioni dall'esterno del cluster. L'elenco seguente mostra le caratteristiche principali di Red Hat OpenShift Routes.

  • Layer 7 routing - HTTP / HTTPS traffico con routing basato su nomi di host
  • DNS automatico - le rotte utilizzano il sottodominio del cluster: <route-name>-<namespace>.apps.<cluster-domain>
  • Percorsi non garantiti ( HTTP )
  • Terminazione TLS
    • Percorsi terminati ai bordi ( TLS al router)
    • Percorsi di passaggio ( TLS su Pod)
    • Ricodifica delle rotte ( TLS presso il router e il Pod)
  • HAProxy-è implementato dal controllore di ingresso (router) di Red Hat OpenShift
  • Gestione del traffico: instradamento basato sul percorso, suddivisione del traffico e affinità di sessione

Rete virtuale aperta (OVN)

Il plug-in OVN- Kubernetes Container Network Interface (CNI) è l'opzione di rete consigliata per la virtualizzazione " Red Hat OpenShift ", che supporta i casi d'uso relativi alle reti dei server virtuali che operano parallelamente alle reti tradizionali dei pod. OVN - Kubernetes si basa su Open Virtual Networking (OVN) e utilizza Open vSwitch (OVS) su ogni nodo di lavoro. Supporta la multi-tenancy, NetworkPolicies, e la rete ibrida di server virtuali e pod. Red Hat OpenShift on IBM Cloud VPC supporta OVN- Kubernetes come plug-in di rete predefinito.

Gli amministratori che hanno familiarità con VMware vSphere e NSX-T possono consultare la sezione dedicata alle reti OVN all’indirizzo OpenShift, destinata agli amministratori di vSphere, per una corrispondenza tra i concetti OVN e i loro equivalenti in vSphere.

In Red Hat OpenShift con OVN, le seguenti tre topologie di rete forniscono connettività di rete secondaria ai pod e ai server virtuali.

  • Livello 2 ( L2 )- Domini di broadcast L2 definiti dal software utilizzando l'incapsulamento Geneve
  • Layer 3 ( L3 )- Segmenti di rete instradati con sottoreti IP personalizzate. Una rete di tipo “ L3 ” dispone di un CIDR (Classless Inter-Domain Routing) distinto per ogni nodo.
  • Localnet - Accesso diretto alle VLAN della rete fisica sottostante

In Red Hat OpenShift Virtualization on IBM Cloud, OVN layer 2 e OVN localnet sono le due topologie principali utilizzate con le reti definite dall'utente (UDN).

  • OVN Layer 2 fornisce una rete overlay simile ai segmenti overlay di NSX utilizzando l'incapsulamento Geneve per creare domini di broadcast L2 definiti dal software in tutto il cluster. Queste reti sono isolate dalle sottoreti della VPC. Richiedono un pod gateway o un server virtuale collegato a una Localnet OVN per fornire l'ingresso e l'uscita alla subnet VPC e un percorso VPC.
  • OVN Localnet fornisce l'accesso VLAN alla rete VPC sottostante ed è simile ai segmenti VLAN-backed di NSX. In IBM Cloud VPC, questa connettività diretta consente ai server virtuali e ai pod di connettersi direttamente alle sottoreti VPC utilizzando un'interfaccia di rete virtuale (VNI) e gli allegati VLAN.

Il diagramma seguente presenta una panoramica della rete di server virtuali con OVN e multus. Per impostazione predefinita, Kubernetes (e Red Hat OpenShift ) assegna una singola interfaccia di rete a ogni pod utilizzando un plug-in CNI primario (come OVN- Kubernetes ). Multus in Red Hat OpenShift è un plug-in CNI che abilita interfacce di rete multiple per pod e server virtuali.

OVN Networking con multus
OVN Networking con multus

Inizialmente, è disponibile solo la rete OVN Layer 2.

Reti definite dall'utente OVN

Red Hat OpenShift Virtualizzazione

Una rete definita dall'utente (UDN) in Red Hat OpenShift è una rete personalizzata fornita da OVN- Kubernetes. Un UDN sostituisce la rete cluster predefinita (nota anche come rete pod predefinita) Gli UDN si usano per creare reti con le proprie sottoreti IP, gateway e domini di routing. Le UDN sono indipendenti dalla rete pod primaria e vengono comunemente utilizzate quando i carichi di lavoro richiedono le seguenti funzioni.

  • Isolamento della rete dalle altre applicazioni del cluster
  • Intervalli di indirizzi IP personalizzati o sottoreti sovrapposte
  • Controllo diretto del traffico est-ovest tra i namespace o i carichi di lavoro selezionati
  • Integrazione con server virtuali (virtualizzazione Red Hat OpenShift ) che richiedono più interfacce di rete
  • Segmenti di rete dedicati per requisiti di sicurezza o conformità

A differenza della rete pod predefinita, gli UDN sono esplicitamente collegati ai namespace. Ogni UDN crea uno switch logico aggiuntivo in OVN. Quando un UDN viene etichettato come rete primaria definita dall'utente dello spazio dei nomi, tutti i pod e i server virtuali di quello spazio dei nomi lo usano come rete principale, invece di quella predefinita del cluster.

Cluster User-Defined Network (CUDN) espande il concetto di UDN, fornendo una risorsa di tipo cluster-scoped che non appartiene a nessuno spazio dei nomi specifico. Un CUDN viene creato ed è associato a uno o più spazi dei nomi. A differenza delle risorse NAD (namespace-scoped NetworkAttachmentDefinition ) che ne richiedono una per spazio dei nomi, un CUDN crea automaticamente le NAD negli spazi dei nomi quando questi vengono aggiunti alla definizione del CUDN.

Le UDN offrono opzioni di rete flessibili in base all'ambito, al metodo di collegamento e alla topologia:

Ambito della rete

  • Namespace-scoped UDN - Definizione di rete limitata a un singolo spazio dei nomi, che richiede un sito NetworkAttachmentDefinitions separato per ogni spazio dei nomi
  • CUDN a livello di cluster - Definizione di rete disponibile a livello di cluster, con creazione automatica di NetworkAttachmentDefinitions nei namespace selezionati

Metodo di fissaggio

  • Rete primaria: agisce come rete predefinita per tutti i pod/server virtuali nello spazio dei nomi, sostituendo la rete predefinita del cluster
  • Rete secondaria - Collegata tramite Multus CNI per fornire interfacce di rete aggiuntive ai pod/server virtuali accanto alla rete primaria

Topologia di rete

  • Livello 2 - Dominio di trasmissione " L2 " definito dal software tramite l'incapsulamento Geneve, che consente il rilevamento basato sul protocollo ARP (Address Resolution Protocol) e la comunicazione da MAC a MAC
  • Layer 3 - Segmenti di rete instradati con sottoreti IP e gateway personalizzati
  • Localnet - Accesso diretto alle VLAN delle sottoreti VPC sottostanti tramite gli allegati Virtual Network Interface (VNI)

È possibile combinare queste caratteristiche per creare soluzioni di rete personalizzate. Ad esempio, una CUDN con copertura cluster che utilizza la topologia localnet può fornire più namespace con accesso diretto alla subnet VPC come rete primaria o secondaria.

Reti OVN Layer 2

Una rete OVN layer 2 è un dominio di broadcast Layer 2 definito dal software, simile a un segmento overlay NSX o a una VLAN tradizionale. Il livello 2 è implementato interamente all'interno di OVN utilizzando l'incapsulamento Geneve sull'infrastruttura di rete esistente del cluster. Una rete Layer 2 consente ai pod e ai server virtuali di comunicare come se si trovassero sullo stesso segmento Ethernet, con il supporto di ARP discovery, broadcast, multicast e comunicazione diretta da MAC a MAC.

Un cluster Red Hat OpenShift ha una rete primaria del cluster in cui i pod e i server virtuali ricevono IP dal CIDR predefinito del cluster che viene instradato attraverso OVN. Si definisce una rete secondaria Layer 2 attraverso un ClusterUserDefinedNetwork (CUDN) o un namespace-scoped UDN. Una rete secondaria Layer 2 è qualsiasi rete aggiuntiva creata oltre alla rete pod predefinita.

I seguenti elementi sono caratteristiche fondamentali delle reti di livello 2.

  • Fornire domini di broadcast Layer 2 creati da OVN con IPAM, assegnazione di MAC e connettività
  • Nessuna risoluzione DNS integrata per i nomi dei pod sulle reti secondarie
  • Il traffico proveniente dalla rete primaria di livello 2 viene sottoposto a traduzione dell'indirizzo di rete di origine (NAT) all'uscita dal server virtuale e viene inoltre instradato verso la rete di livello 2, che può essere configurata utilizzando le rotte " FRR-K8s " e "VPC"
  • Le reti secondarie Layer 2 sono isolate per impostazione predefinita e non hanno accesso diretto a Internet, a meno che non siano configurate esplicitamente
  • Adatto per la comunicazione da server virtuale a server virtuale all'interno del cluster e per le applicazioni che dipendono dal multicast

OVN Reti locali

Una rete OVN Localnet fornisce ai server virtuali e ai pod un accesso VLAN diretto all'infrastruttura di rete VPC sottostante. OVN Localnet consente ai server e ai pod virtuali di connettersi alle sottoreti VPC utilizzando un'interfaccia di rete virtuale (VNI) e gli allegati VLAN.

Con gli allegati VLAN, è possibile collegare direttamente i server virtuali eseguiti su Red Hat OpenShift Virtualization alle sottoreti VPC. Questo approccio consente di utilizzare il design della subnet VPC esistente per i server virtuali nuovi o migrati, fornendo una rete coerente per i carichi di lavoro.

La rete localnet richiede che ogni NIC di server virtuale collegata a una sottorete VPC abbia i seguenti requisiti:

  • Una risorsa Virtual Network Interface (VNI) che definisce un indirizzo IP riservato dalla subnet VPC e uno o più gruppi di sicurezza che controllano il traffico in entrata e in uscita verso la VNI.
  • Attacco VLAN di un server bare metal. La funzionalità di "floating" di questo collegamento VLAN, che determina se il collegamento può spostarsi tra i nodi di lavoro, deve essere abilitata affinché il server virtuale possa essere migrato in tempo reale su un altro nodo di lavoro.
  • UN ID VLAN. Il tag VLAN associa l'interfaccia PCI ai nodi worker. In genere questa associazione è una mappatura uno-a-uno tra ID VLAN e subnet VPC.

Quando si progettano le regole dei gruppi di sicurezza per le reti localnet, si deve considerare che alcuni passaggi di rete avvengono all'interno di OVS sul nodo worker e non raggiungono mai l'infrastruttura VPC. Le regole dei gruppi di sicurezza vengono applicate solo al traffico che attraversa il tessuto di rete VPC. Il traffico tra server virtuali sullo stesso nodo worker può aggirare i controlli di sicurezza della VPC.

I seguenti esempi sono casi d'uso di Localnet.

  • Server virtuali migrati che richiedono indirizzi IP di sottorete VPC esistenti
  • Integrazione con i gruppi di sicurezza e i criteri di rete VPC esistenti
  • Connettività diretta ad altre risorse VPC
  • Requisiti di conformità per la segmentazione della rete mediante l'uso di sottoreti VPC
  • Architetture ibride che richiedono un indirizzamento IP coerente tra la virtualizzazione VPC e Red Hat OpenShift

Passi successivi

Dopo aver compreso la progettazione della rete per la virtualizzazione di Red Hat OpenShift, è possibile esplorare questi argomenti correlati: