Funzioni chiave

VNI statici per nodo worker

Quando si crea un cluster Red Hat OpenShift on IBM Cloud basato su bare metal o un nuovo pool di lavoratori in IBM Cloud VPC, vengono automaticamente create due VNI e collegate staticamente a ogni nodo lavoratore bare metal. Una VNI gestisce il traffico regolare dei lavoratori (rete di pod, UDN in overlay e comunicazione con il master). La seconda VNI funge da vettore per gli allegati VNI dinamici gestiti dall'utente.

Allegati dinamici VNI

È possibile creare e gestire le VNI on-demand dopo la creazione del cluster. I VNI dinamici possono essere collegati a lavoratori specifici o configurati per fluttuare tra i lavoratori della stessa zona, seguendo i carichi di lavoro di VM durante la migrazione live.

Supporto alla migrazione in tempo reale

Con le VNI collegate ai nodi worker bare metal, le migrazioni live delle macchine virtuali basate su OpenShift possono preservare le connessioni di rete. Il VNI fluttua implicitamente e segue il carico di lavoro tra le istanze worker bare metal all'interno della stessa zona.

Per importanti limitazioni e considerazioni sui VNI, vedere Limitazioni e considerazioni.

Attacco trasversale al conto

In Red Hat OpenShift on IBM Cloud, i nodi worker non vengono forniti nell'account dell'utente, il che significa che la gestione del ciclo di vita delle VNI è leggermente diversa da quella delle istanze bare metal VPC standalone. L'amministratore del cluster Red Hat OpenShift on IBM Cloud ha una visibilità diversa sugli allegati delle VNI perché sono collegati a carichi di lavoro che non sono visibili all'interno dell'account. Le differenze nella gestione delle VNI sono descritte in questa documentazione.

Per ulteriori informazioni sulle VNI sulle istanze bare metal VPC standalone, vedere Informazioni sulle interfacce di rete virtuali.

Creazione di un UDN primario

Per utilizzare una rete definita dall'utente primaria per i pod o per il carico di lavoro di VM, occorre innanzitutto creare la UDN stessa.

Esempio di rete definita dall'utente del cluster che può essere utilizzata in tutti i namespace:

apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
  name: primary
spec:
  namespaceSelector:
    matchLabels:
      kubernetes.io/metadata.name: green
  network:
    layer2:
      ipam:
        lifecycle: Persistent
      role: Primary
      subnets:
        - 10.0.0.0/24
    topology: Layer2

Quindi, creare gli spazi dei nomi che lo utilizzeranno. Lo spazio dei nomi deve contenere un'etichetta specifica (chiamata k8s.ovn.org/primary-user-defined-network) al momento della creazione per l'utilizzo dell'UDN primario.

Esempio:

kind: Namespace
apiVersion: v1
metadata:
  name: green
  labels:
    k8s.ovn.org/primary-user-defined-network: ''

Una volta che il (C)UDN e gli spazi dei nomi sono stati creati, qualsiasi carico di lavoro creato in questo spazio dei nomi accederà all'UDN con il percorso predefinito.

Creazione di un UDN secondario

La configurazione dell'UDN secondario è simile a quella dell'UDN primario, ma con il ruolo impostato su Secondary. Per informazioni dettagliate, consultare il sito Red Hat OpenShift documentazione sulle reti multiple.

Installazione dell'operatore NMState

OpenShift Servizio di virtualizzazione I cluster hanno l'operatore NMState preinstallato e gestito dal componente aggiuntivo " openshift-virtualization ". Salta questo passaggio se stai utilizzando il Servizio di virtualizzazione.

1. Distribuire NMState Operator dal sito OperatorHub nella console Red Hat OpenShift on IBM Cloud o utilizzando la CLI.

2. Creare un'istanza di NMState con la configurazione predefinita.

   apiVersion: nmstate.io/v1
   kind: NMState
   metadata:
     name: nmstate
   spec:
     probeConfiguration:
       dns:
         host: root-servers.net
   

Creazione del ponte OVS

OpenShift Servizio di virtualizzazione I cluster dispongono delle risorse NNCP necessarie già preconfigurate. È necessario creare manualmente queste risorse solo per i cluster standard di OpenShift con installazione manuale di Virtualization OpenShift.

1. Creare un ponte OVS dedicato con eth1 collegato ad esso distribuendo la seguente risorsa personalizzata NMState.

   apiVersion: nmstate.io/v1
   kind: NodeNetworkConfigurationPolicy
   metadata:
     name: "br-eth1"
   spec:
     desiredState:
       interfaces:
       - name: "br-eth1"
         description: A dedicated OVS bridge with a NIC as a port
         type: ovs-bridge
         state: up
         bridge:
           allow-extra-patch-ports: true
           options:
             stp: false
           port:
           - name: "eth1"
   

2. Controllare lo stato della risorsa personalizzata e attendere che tutti i nodi del cluster interessati riconcilino la richiesta di creazione del ponte.

3. Collegare il nuovo ponte OVS a quello predefinito creando la seguente risorsa personalizzata NMState. Sostituire vpc-vlans con il nome della rete desiderata.

   apiVersion: nmstate.io/v1
   kind: NodeNetworkConfigurationPolicy
   metadata:
     name: "vpc-vlans"
   spec:
     desiredState:
       ovn:
         bridge-mappings:
         - localnet: "vpc-vlans"
           bridge: "br-eth1"
           state: present
   

4. Controllare lo stato della risorsa personalizzata e attendere che tutti i nodi del cluster interessati riconcilino la richiesta di mappatura del ponte.

Creazione di una rete definita dall'utente localnet

Creare una UDN o ClusterUserDefinedNetwork (CUDN) che renda disponibile il traffico dalle VNI utilizzando la VLAN selezionata.

apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
  name: "vlan250"
spec:
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: In
      values:
      - "default"
  network:
    topology: Localnet
    localnet:
      role: "Secondary"
      physicalNetworkName: "vpc-vlans"
      ipam:
        mode: Disabled
      vlan:
        mode: Access
        access:
          id: 250

Sostituisci i seguenti valori:

• vlan250: Il nome del vostro CUDN
• default: Lo spazio dei nomi in cui si vuole utilizzare il CUDN
• vpc-vlans: Il nome della rete fisica definito nella mappatura del ponte
• 250: ID VLAN desiderato (intervallo: 1-500)

In questo modo si conclude l'impianto idraulico di rete di una specifica VLAN. È possibile definire più CUDN utilizzando ID VLAN diversi e riutilizzando le mappature dei ponti.

Dopo aver completato l'impostazione dell'UDN localnet, è possibile collegare le VNI al cluster utilizzando la console IBM Cloud o il comando IBM Cloud CLI ks vni. Si vedano gli esempi nelle sezioni seguenti.

Prima di iniziare

1. Creare le VNI nella VPC con la configurazione appropriata di subnet e indirizzi IP.

2. Assicurarsi di avere le autorizzazioni necessarie per gestire sia il cluster che le VNI.

Esempio

ibmcloud ks vni attach baremetal --vni 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba --worker kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123 --vlan 251

Output di esempio

OK
Successfully attached VNI 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba to worker node kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123.
Worker Node ID                                         VNI ID                                      VLAN ID
kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123   0716-aac49630-f3b4-4ef6-9a3a-5145481697ba   251

Output di esempio

ibmcloud ks vni ls --cluster-id c9pqfcmw0tq431jdnrrg

OK
VNI ID                                      Worker Node                                            IP Address   MAC Address         VLAN   Floating   Auto-delete
0716-d97d3626-acb2-476b-8b12-bcafa1dec5bb   kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000456   10.240.1.5   02:00:02:00:73:A5   250    -          false
0716-aac49630-f3b4-4ef6-9a3a-5145481697ba   kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123   10.240.1.4   02:00:01:00:73:A5   251    -          false

Esempio

ibmcloud ks vni detach --vni 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba --worker kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123

Detach VNI 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba from worker node kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123? This action cannot be undone. [y/N]> y
OK
Successfully detached VNI 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba from worker node kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123.

Perché non è possibile collegare pod regolari a UDN localnet?

Le UDN Localnet hanno la gestione degli indirizzi IP (IPAM) disabilitata sul lato OVN, il che significa che l'assegnazione di indirizzi IP statici ai pod non avviene da OVN. Questa configurazione è progettata per i carichi di lavoro di VM che utilizzano DHCP o impostano IP statici all'interno del sistema operativo guest. Queste opzioni non sono disponibili per i carichi di lavoro pod.

Perché la migrazione live è in sospeso tra i pool di lavoratori?

I diversi pool di lavoratori possono avere diversi tipi di lavoratori con CPU di generazioni e capacità diverse. Se l'intero set di funzionalità della CPU è visibile in modo trasparente al carico di lavoro VM, non è possibile eseguire la migrazione live di VM a un altro worker che non supporta tutte le funzionalità della CPU. È possibile limitare le caratteristiche della CPU visibile del sistema operativo guest all'inizio, per ottenere una maggiore compatibilità tra i vari flavor di worker.

Perché i VNI allegati dinamici non funzionano?

Controlla quanto segue:

• Verificare che l'ID VLAN del CUDN corrisponda all'ID VLAN dell'allegato VNI. Il VPC DHCP potrebbe comunque funzionare senza ulteriore traffico se la VLAN non è compatibile.
• Se il floating non è abilitato, assicurarsi che il carico di lavoro sia pianificato sul worker a cui è collegata la VNI.
• Verificare che il bridge OVS dedicato e la mappatura siano presenti sui lavoratori. Controllare lo stato della risorsa NodeNetworkConfigurationPolicy.