Nota:

• Questa esercitazione richiede l'accesso a Oracle Cloud. Per iscriversi a un account gratuito, consulta Inizia a utilizzare Oracle Cloud Infrastructure Free Tier.
• Utilizza valori di esempio per le credenziali, la tenancy e i compartimenti di Oracle Cloud Infrastructure. Al termine del laboratorio, sostituisci questi valori con quelli specifici del tuo ambiente cloud.

Configura interfacce SR-IOV per i pod utilizzando Multus per nodi Oracle Container Engine for Kubernetes basati su VM

Introduzione

Quando carichi di lavoro altamente orientati alla rete richiedono la configurazione di interfacce di rete secondarie all'interno dei pod, possiamo utilizzare una meta CNI come Multus per raggiungere questo obiettivo. Le interfacce di rete secondarie generalmente collegate in questi casi avranno funzionalità o proprietà di rete specializzate come la virtualizzazione SR-IOV (Single Root IO Virtualization).

In una esercitazione precedente: configurare le interfacce SR-IOV per i pod che utilizzano Multus per i nodi OKE Bare Metal (è possibile accedere al collegamento dalla sezione Collegamenti correlati), abbiamo descritto come farlo sui nodi Kubernetes Bare Metal su Oracle Cloud Infrastructure (OCI), in cui è possibile creare direttamente le funzioni virtuali (VF) nell'hardware collegato all'istanza Bare Metal.

Questa esercitazione segue un approccio simile per i nodi Virtual Machine in un cluster OKE (Oracle Container Engine for Kubernetes) e adotta un approccio simile, con configurazioni e plugin diversi da quelli utilizzati sui nodi Bare Metal. Esistono differenze significative nel modo in cui le interfacce vengono create e gestite tra Bare Metal in cui hai il controllo completo sull'hardware e sulle Virtual Machine in cui un hypervisor sottrae l'accesso all'hardware sottostante e non ne hai tanto controllo.

L'approccio descritto qui utilizza Multus per fornire più interfacce a un pod, tuttavia il CNI SR-IOV e il plugin dispositivo associato non vengono utilizzati. Questo perché l'SR-IOV CNI richiede l'accesso all'hardware sottostante, la funzione fisica (PF), che ovviamente pone una sfida sulle macchine virtuali. Per superare questa sfida, possiamo utilizzare le API di networking OCI per le VNIC, per creare una funzione virtuale (VF) nella funzione fisica (PF), come nello scenario Bare Metal e fornire alla VM un accesso diretto e libero a questo VF. Questi VF possono essere collegati a un'istanza di computazione, inclusi i nodi OKE, come interfacce di rete. Queste interfacce/VF possono essere spostate negli spazi di nomi di rete per i pod, che consentono al pod di utilizzare in modo diretto ed esclusivo VF come interfaccia di rete. Dal punto di vista dei Pod, non sarà in grado di distinguere tra i due, e in entrambi i casi avrà accesso a un VF che possono utilizzare direttamente.

Per concedere a una VM l'accesso diretto a una VF, è necessario avviare la VM con la modalità di collegamento di rete VFIO anziché con la modalità predefinita paravirtualizzata. Questa scelta è controllata dalla modalità di avvio per l'istanza di computazione. Una volta impostata la modalità di collegamento di rete come VFIO, è possibile creare collegamenti di rete utilizzando le API OCI, che crea VF sul PF di base e fornisce il VF direttamente alla VM. Il sistema operativo dell'host riconoscerà questi elementi come interfacce di rete. Una volta disponibile, il VF può essere spostato nello spazio di nomi pod. In questo modello, le VF vengono create utilizzando le API OCI invece dei comandi di sistema nello scenario bare-metal.

Obiettivo

Configura le interfacce SR-IOV per i pod che utilizzano Multus per i nodi Oracle Container Engine for Kubernetes basati su VM.

Prerequisiti

• Cluster OKE con un pool di nodi costituito da almeno due VM.

Nota: questa esercitazione è stata convalidata su cluster OKE con la rete Flannel (Flannel come CNI principale).

Task 1: impostazione dei nodi

Ogni nodo che richiede l'accesso alle interfacce SR-IOV deve essere preparato per i collegamenti di rete assistiti da hardware prima che possano essere utilizzati dai pod.

1. Avviare i nodi in modalità VFIO

   • Creare un pool di nodi e un set di nodi nel cluster.

   • Una volta creati i nodi, modificare le proprietà dell'istanza.

     

   • Nelle proprietà dell'istanza fare clic su Mostra opzioni avanzate per visualizzare le proprietà aggiuntive. Nella scheda Opzioni di avvio scegliere Networking assistito dall'hardware (SR-IOV) per il tipo di rete.

     

     Nota: dopo aver passato un'istanza ai collegamenti di rete paravirtualizzati in modalità assistita da hardware (SR-IOV o VFIO), questi non saranno più idonei per la migrazione attiva per la manutenzione dell'infrastruttura.

   • Il workflow di aggiornamento richiederà il riavvio dell'istanza. Dopo il riavvio dell'istanza saranno presenti collegamenti di rete VFIO. Ciò può essere verificato nella console.

     

   • Un altro metodo per verificare se le istanze utilizzano i collegamenti di rete SR-IOV è SSH sul nodo e utilizzare lspci per elencare i dispositivi PCI nella VM. Dovresti essere in grado di visualizzare la funzione virtuale di base direttamente sulla VM, al contrario di un dispositivo che utilizza un driver virtio (ad esempio il controller di storage nell'immagine seguente).

     

   • A questo punto, il nodo dispone di un singolo collegamento VNIC, che è la VNIC primaria utilizzata per tutte le comunicazioni al nodo. Poiché l'istanza utilizza collegamenti di rete assistiti da hardware, il collegamento di rete è visibile al nodo come funzione virtuale sull'hardware di base. Affinché i pod possano utilizzare esclusivamente una funzione virtuale (VF), abbiamo bisogno di VF aggiuntivi sulla VM. Questa operazione può essere fornita mediante la console o l'API per aggiungere collegamenti VNIC aggiuntivi all'istanza. Questi collegamenti VNIC sono VF nel PF di base. Questi possono essere verificati con lspci.

2. Aggiungi altri collegamenti VNIC

   • Nella pagina dell'istanza scegliere VNIC collegate e fare clic su Crea VNIC.

     

   • Configura la VNIC utilizzando la VCN e la subnet necessarie.

     

   • Verificare se la VNIC può essere visualizzata nell'host come funzione virtuale precedente mediante l'applicazione SSH sul nodo e l'esecuzione di lspci.

     

   • Quando aggiungi una VNIC secondaria a un'istanza di VM Linux, all'istanza viene aggiunta una nuova interfaccia (ovvero un dispositivo Ethernet) e viene riconosciuta automaticamente dal sistema operativo. Tuttavia, DHCP non è attivo per la VNIC secondaria ed è necessario configurare l'interfaccia con l'indirizzo IP statico e l'instradamento predefinito.

3. Configurare il sistema operativo per le VNIC secondarie

   • OCI fornisce documentazione e uno script per la configurazione del sistema operativo per le VNIC secondarie. Per configurare la VNIC secondaria, scaricare lo script sul nodo ed eseguirlo in base alle istruzioni fornite nella documentazione OCI.

     Nota: le VNIC secondarie su ciascun nodo devono essere impostate ripetendo questi passi per ogni nodo. Questi passi possono essere facoltativi e automatizzati mediante uno script personalizzato cloud_init per i nodi.

   • Verificare che l'interfaccia sia ora connessa, con il relativo indirizzo IP e la route predefinita. Per controllare, utilizzare il comando ip addr o nmcli.

     

   • Se si desidera, verificare il routing utilizzando un ping per raggiungere gli indirizzi IP secondari. Nelle immagini seguenti, 10.0.10.238 è l'IP secondario su un secondo nodo del cluster.

     

     

Task 2: Installare un CNI Meta-Plugin (Multus)

Multus è un meta plug-in che può fornire le informazioni VF a un CNI a valle come il plugin SR-IOV CNI per gestire l'attivazione delle risorse di rete abilitando pod "Multi-homed" o pod con più interfacce di rete.

Nota: a partire da Multus 4.0, Multus ha introdotto una nuova distribuzione dello stile client-server denominata "thick plug-in". Il nuovo plug-in spesso supporta funzioni aggiuntive come le metriche non supportate in precedenza. Questo documento utilizza il plugin 'thin' in quanto consuma meno risorse.

1. Per installare Multus, eseguire i comandi seguenti.

   git clone https://github.com/k8snetworkplumbingwg/multus-cni.git && cd multus-cni
   kubectl apply -f deployments/multus-daemonset.yml && cd ..
   

Nota: durante l'installazione, l'immagine predefinita utilizzata dal daemon contrassegnato con stable richiede che il kubelet sia v1.20.x. Se si esegue l'installazione in un cluster precedente, modificare il deamonset nel file manifesto e utilizzare il tag immagine multus v3.7.1.

Questo file manifesto crea una nuova CRD per kind:NetworkAttachmentDefinition e fornisce il file binario Multus su tutti i nodi tramite un daemon. È possibile verificare l'installazione verificando che Multus daemonset sia in esecuzione sui nodi.

Task 3: collegare più interfacce ai pod

• Per collegare interfacce aggiuntive ai pod, è necessaria una configurazione che consenta di collegare l'interfaccia. Incapsulato nella risorsa personalizzata di tipo NetworkAttachmentDefinition. Questa configurazione è essenzialmente una configurazione CNI confezionata come risorsa personalizzata.

• Esistono versi plugin CNI che possono essere utilizzati insieme a Multus per raggiungere questo obiettivo. Nell'approccio descritto qui, l'obiettivo è quello di fornire una funzione virtuale SR-IOV esclusivamente per un singolo pod, in modo che il pod possa sfruttare le funzionalità senza interferenze o livelli tra loro. Per concedere a un pod l'accesso esclusivo al VF, possiamo utilizzare il plugin host-device che ti consente di spostare l'interfaccia nello spazio di nomi del pod in modo che disponga dell'accesso esclusivo al pod.

• Gli esempi riportati di seguito mostrano gli oggetti NetworkAttachmentDefinition che configurano l'interfaccia ens5 secondaria aggiunta ai nodi. La configurazione del plugin ipam determina la modalità di gestione degli indirizzi IP per queste interfacce. In questo esempio, poiché si desidera utilizzare gli stessi indirizzi IP assegnati alle interfacce secondarie da OCI, viene utilizzata la configurazione ipam statica con gli instradamenti appropriati. La configurazione ipam supporta anche altri metodi come host-local o dhcp per configurazioni più flessibili.

  
  ## network attachment for the first node. Note the IPaddress assignment in the `ipam` configuration.
  
  cat << EOF | kubectl create -f -
  apiVersion: "k8s.cni.cncf.io/v1"
  kind: NetworkAttachmentDefinition
  metadata:
    name: sriov-vnic-1
  spec:
    config: '{
          "cniVersion": "0.3.1",
          "type": "host-device",
          "device": "ens5",
          "ipam": {
                  "type": "static",
                  "addresses": [
                      {
                          "address": "10.0.10.93/24",
                          "gateway": "0.0.0.0"
                      }
                  ],
                  "routes": [
                      { "dst": "10.0.10.0/24", "gw": "0.0.0.0" }
                  ]
              }
            }'
  EOF
  
  ## network attachment for the second node. Note the IPaddress assignment in the `ipam` configuration.
  
  cat << EOF | kubectl create -f -
  apiVersion: "k8s.cni.cncf.io/v1"
  kind: NetworkAttachmentDefinition
  metadata:
    name: sriov-vnic-2
  spec:
    config: '{
          "cniVersion": "0.3.1",
          "type": "host-device",
          "device": "ens5",
          "ipam": {
                  "type": "static",
                  "addresses": [
                      {
                          "address": "10.0.10.238/24",
                          "gateway": "0.0.0.0"
                      }
                  ],
                  "routes": [
                      { "dst": "10.0.10.0/24", "gw": "0.0.0.0" }
                  ]
              }
            }'
  EOF
  

Task 4: Distribuisci pod con più interfacce e test

I pod possono ora richiedere interfacce aggiuntive utilizzando un'annotazione. L'annotazione consente al meta-plug-in (Multus) di sapere quale NetworkAttachmentDefinition (configurazione CNI) utilizzare per fornire interfacce aggiuntive quando viene creato il pod.

Nota: quando si utilizza una configurazione statica simile a quella illustrata in questo esempio, è necessario impostare l'affinità dei nodi, in modo che il pod sia pianificato sul nodo in cui è disponibile il dispositivo host desiderato.

• Ecco un esempio con un pod di test:

  ## Create the first pod
  cat << EOF | kubectl create -f -
  apiVersion: v1
  kind: Pod
  metadata:
    name: testpod1
    annotations:
      k8s.v1.cni.cncf.io/networks: sriov-vnic-1
  spec:
    containers:
    - name: appcntr1
      image: centos/tools
      imagePullPolicy: IfNotPresent
      command: [ "/bin/bash", "-c", "--" ]
      args: [ "while true; do sleep 300000; done;" ]
  
  EOF
  
  ## Create a second pod
  cat << EOF | kubectl create -f -
  apiVersion: v1
  kind: Pod
  metadata:
    name: testpod2
    annotations:
      k8s.v1.cni.cncf.io/networks: sriov-vnic
  spec:
    containers:
    - name: appcntr1
      image: centos/tools
      imagePullPolicy: IfNotPresent
      command: [ "/bin/bash", "-c", "--" ]
      args: [ "while true; do sleep 300000; done;" ]
  
  EOF
  
  

• Con due pod creati, dovremmo vedere che sono entrambi in esecuzione. Dovremmo essere in grado di vedere che sono state create ulteriori interfacce di rete durante la creazione dei pod. Multus fornirà l'interfaccia eth0 supportata dal CNI predefinito (Flanella in questo esempio) e un'interfaccia net1 aggiuntiva, ovvero la funzione virtuale SR-IOV. È possibile describe i pod e osservare la sezione Eventi dell'output per visualizzare i vari eventi, incluse le interfacce collegate al pod.

  

• Una volta avviati i pod, possiamo eseguire un test rapido.

  ## Verify that both pods have two interfaces. An `eth0` on the overlay and a `net1` which is the VF, along with the IP address for the secondary VNIC.
  kubectl exec -it testpod1 -- ip addr show
  kubectl exec -it testpod2 -- ip addr show
  

• L'output deve essere simile alle immagini seguenti.

  

  

• Possiamo anche verificare la comunicazione tra i due pod su queste interfacce secondarie.

  ## test communication
  kubectl exec -it testpod1 -- ping -I net1  <ip address for secondary vnic on the other pod/node>
  kubectl exec -it testpod2 -- ping -I net1  <ip address for secondary vnic on the other pod/node>
  
  

• L'output deve essere simile alle immagini seguenti.

  

  

• Possiamo anche verificare che i pod siano instradabili utilizzando i relativi collegamenti di rete, tentando di raggiungerli dalle VM o da qualsiasi altra origine all'interno della VCN.

  ## Test that the pod is routable from outside Kubernetes. This is executed from node1.
  ping 10.0.10.238
  
  ## similarly, from node 2
  ping 10.0.10.93
  
  

• L'output dovrebbe essere simile alle seguenti immagini.

  

  

Collegamenti correlati

• Configurare le interfacce SR-IOV per i pod che utilizzano Multus per i nodi OKE Bare Metal

• Multus

• SRIOV-CNI

• Plugin CNI in ambienti virtuali

Approvazioni

• Autore - Jeevan Joseph (Principal Product Manager)

Altre risorse di apprendimento

Esplora altri laboratori su docs.oracle.com/learn o accedi a contenuti di formazione gratuiti sul canale YouTube di Oracle Learning. Inoltre, visitare education.oracle.com/learning-explorer per diventare Explorer di Oracle Learning.

Per la documentazione sul prodotto, visitare il sito Oracle Help Center.

---

Titolo e informazioni sul copyright

Configure SR-IOV interfaces for pods using Multus for VM-based Oracle Container Engine for Kubernetes nodes

F80585-01

May 2023

Copyright © 2023, Oracle and/or its affiliates.