Distribuisci applicazioni contenitore interfacce di rete abilitate per SR-IOV su OKE utilizzando il plugin Multus CNI

Introduzione

In questa esercitazione esploreremo come distribuire applicazioni containerizzate sui nodi di lavoro delle istanze virtuali all'interno di Oracle Cloud Infrastructure Kubernetes Engine (OKE), sfruttando funzionalità di rete avanzate. In particolare, abiliteremo la virtualizzazione SR-IOV (Single Root I/O Virtualization) per le interfacce di rete dei container e configureremo il plugin Multus CNI per abilitare la rete multihoming per i container.

Combinando SR-IOV con Multus, puoi ottenere reti ad alte prestazioni e a bassa latenza per carichi di lavoro specializzati come AI, Machine Learning ed elaborazione dei dati in tempo reale. Questa esercitazione fornisce istruzioni dettagliate per configurare l'ambiente OKE, distribuire i nodi di lavoro con interfacce abilitate per SR-IOV e utilizzare Multus CNI per gestire più interfacce di rete nei pod. Sia che tu stia puntando all'elaborazione di pacchetti ad alta velocità o abbia bisogno di perfezionare il tuo networking Kubernetes, questo tutorial ti fornirà gli strumenti e le conoscenze per iniziare.

Nota:

Al momento della pubblicazione di questa esercitazione, SR-IOV CNI non può essere utilizzato da pod o container su un'istanza virtuale che fa parte di un cluster OKE insieme al plugin Multus CNI.

In questa esercitazione verrà illustrato come utilizzare un'interfaccia abilitata per SR-IOV all'interno di un pod in esecuzione su pod o container su un'istanza virtuale che fa parte di un cluster OKE spostando Schede di interfaccia di rete virtuale (VNIC) (che si trova su un'istanza virtuale) in un pod ed è utilizzabile con l'aiuto del plugin Multus CNI (dove il plugin SR-IOV CNI non viene utilizzato affatto).

Il plugin CNI SR-IOV è supportato su un'istanza Bare Metal che fa parte di un cluster OKE insieme al plugin Multus CNI. Questa esercitazione non è inclusa nell'ambito.

immagine

Obiettivi

Distribuire applicazioni container sui nodi di lavoro delle istanze virtuali all'interno di OKE con interfacce di rete abilitate per SR-IOV utilizzando il plugin Multus CNI.

Task 1: Distribuire OKE con un bastion, un operatore, tre nodi di lavoro VM e il plugin CNI Flannel

Assicurarsi che OKE venga distribuito con l'impostazione seguente:

Bastion
Operatore
3 nodi di lavoro VM
Plugin CNI Flannel

Questa impostazione è descritta nel dettaglio nell'esercitazione qui: Distribuisci un cluster Kubernetes con Terraform utilizzando Oracle Cloud Infrastructure Kubernetes Engine.

L'immagine seguente mostra una panoramica visiva dei componenti con cui lavoreremo durante questo tutorial.

immagine

Task 2: Abilitare la rete SR-IOV (Hardware-Assisted) su ogni nodo lavoratore

Nota: è necessario eseguire i passi riportati di seguito su tutti i nodi di lavoro che fanno parte del cluster OKE.

La seguente immagine mostra una panoramica visiva dei nodi di lavoro all'interno del cluster OKE con cui lavoreremo durante questa esercitazione.

immagine

Abilita SR-IOV sull'istanza

Eseguire il login con SSH all'istanza o al nodo di lavoro.
1. Eseguire il comando lspci per verificare quale driver di rete viene attualmente utilizzato in tutte le VNIC.
2. Si noti che viene utilizzato il driver di rete Virtio.
1. Andare alla pagina Dettagli istanza in OCI Console.
2. scorrere in Basso.
3. Si noti che il tipo di allegato NIC è ora PARAVIRTUALIZED.
1. Andare alla pagina Dettagli istanza in OCI Console.
2. Fare clic su Altre azioni.
3. Fare clic su Modifica.
Fare clic su Visualizza opzioni avanzate.
1. Fare clic su Opzioni di avvio e selezionare Networking hardware assistito (SR-IOV) come Tipo di networking.
2. Fare clic su Salva modifiche
Fare clic su Riavvia istanza per confermare il riavvio dell'istanza.
Lo stato dell'istanza è stato modificato in STOPPING.
Tenere presente che lo stato dell'istanza è stato modificato in AVVIO.
Tenere presente che lo stato dell'istanza è stato modificato in RUNNING.
1. scorrere in Basso.
2. Si noti che il tipo di allegato NIC è ora VFIO.
L'immagine seguente mostra una panoramica visiva di ciò che abbiamo configurato finora.

Task 3: Creare una nuova subnet per le VNIC abilitate per SR-IOV

Creeremo una subnet dedicata che le nostre interfacce abilitate per SR-IOV utilizzeranno.

Task 3.1: Creare una lista di sicurezza

Poiché stiamo già utilizzando liste di sicurezza per le altre subnet, abbiamo anche bisogno di una lista di sicurezza dedicata per la subnet SR-IOV appena creata.

Andare a OCI Console.
1. Passare a Reti cloud virtuali.
2. Fare clic sulla VCN esistente.
1. Fare clic su Elenchi sicurezza.
2. Fare clic su Crea lista di sicurezza.
Per la Regola di entrata 1, immettere le seguenti informazioni.
1. Immettere un Nome.
2. Selezionare CIDR come Tipo di origine.
3. Immettere 0.0.0.0/0 come CIDR origine.
4. Selezionare Tutti i protocolli come Protocollo IP.
5. scorrere in Basso.
1. Per la Regola di uscita 1, immettere le seguenti informazioni.
2. Selezionare CIDR come Tipo di origine.
3. Immettere 0.0.0.0/0 come CIDR origine.
4. Selezionare Tutti i protocolli come Protocollo IP.
5. Fare clic su Crea lista di sicurezza.
Tenere presente che viene creata la nuova lista di sicurezza.

Task 3.2: Creare una subnet

Andare alla pagina Dettagli rete cloud virtuale.
1. Fare clic su Sottoreti.
2. Prendere nota delle subnet esistenti già create per l'ambiente OKE.
3. Fare clic su Crea subnet.
1. Immettere un Nome.
2. Immettere il blocco IPv4 CIDR.
3. scorrere in Basso.
1. Selezionare Subnet privata.
2. scorrere in Basso.
1. Selezionare Opzioni DHCP predefinite per le opzioni DHCP.
2. Selezionare l'elenco di sicurezza creato nel task 3.1.
3. Fare clic su Crea subnet.
Tenere presente che viene creata la subnet di rete.
Nota:
- Nella subnet non sono presenti componenti tecnici abilitati per SR-IOV.
- In questa esercitazione viene utilizzata una subnet OCI standard per consentire il trasporto del traffico utilizzando la tecnologia SR-IOV.
L'immagine seguente mostra una panoramica visiva di ciò che abbiamo configurato finora.

Task 4: Aggiungi un secondo allegato VNIC

L'immagine riportata di seguito mostra una panoramica visiva di come i nodi di lavoro dispongono di una singola VNIC connessa alla subnet dei nodi di lavoro prima di aggiungere una seconda VNIC.

immagine

Prima di aggiungere un secondo collegamento VNIC ai nodi di lavoro, creare un gruppo di sicurezza di rete.

Task 4.1: Creare un gruppo di sicurezza di rete (NSG)

Stiamo già utilizzando NSG per le altre VNIC, ma abbiamo anche bisogno di un gruppo NSG dedicato per la nuova VNIC creata che aggiungeremo a un'istanza virtuale esistente che fa parte del cluster OKE e che farà la sua parte come nodo di lavoro Kubernetes. Questa interfaccia sarà una VNIC in cui è abilitato SR-IOV.

Andare alla pagina Dettagli rete cloud virtuale.
1. Andare a Gruppi di sicurezza di rete.
2. Fare clic su Crea gruppo di sicurezza di rete.
Aggiungere le seguenti regole.
1. Ingresso:
  - Consenti tipo di origine: selezionare CIDR.
  - Origine: immettere 0.0.0.0/0.
  - Destinazione: lasciare vuota la destinazione.
  - Protocollo: consente tutti i protocolli.
2. Uscita:
  - Consenti tipo di origine: selezionare CIDR.
  - Origine: lasciare vuota l'origine.
  - Destinazione: immettere 0.0.0.0/0.
  - Protocollo: consente tutti i protocolli.
Tenere presente che il gruppo NSG viene creato. La applicheremo alla nuova VNIC (secondaria) che creeremo (su ogni nodo di lavoro nel cluster OKE).

Task 4.2: aggiungere la VNIC

Passare a ogni istanza del nodo di lavoro virtuale e aggiungere una seconda VNIC a ogni nodo di lavoro.
1. Andare a ciascuna istanza del nodo di lavoro virtuale e fare clic su VNIC collegate.
2. Tenere presente che esiste già una VNIC.
3. Fare clic su Crea VNIC per aggiungere una seconda VNIC.
1. Immettere un Nome.
2. Selezionare la VCN.
3. Selezionare la subnet creata nel task 3.2.
4. Selezionare Utilizza gruppi per la sicurezza della rete per controllare il traffico.
5. Selezionare il NSG creato nel task 4.1.
6. scorrere in Basso.
1. Selezionare Assegna automaticamente indirizzo IPv4 privato.
2. Fare clic su Salva modifiche
Tenere presente che la seconda VNIC viene creata e collegata all'istanza del nodo di lavoro virtuale e anche collegata alla nostra subnet.
Eseguire il login con SSH all'istanza o al nodo di lavoro.
1. Eseguire il comando lspci per verificare quale driver di rete viene attualmente utilizzato in tutte le VNIC.
2. Si noti che viene utilizzato il driver di rete Mellanox Technologies ConnectX Family mlx5Gen Virtual Function.
Il driver di rete Mellanox Technologies ConnectX Family mlx5Gen Virtual Function è il driver VF (Virtual Function) utilizzato da SR-IOV. Pertanto, la VNIC è abilitata per SR-IOV con VF.
L'immagine seguente mostra una panoramica visiva di ciò che abbiamo configurato finora.

Task 5: Assegnazione di un indirizzo IP alla nuova seconda VNIC con un gateway predefinito

Ora che la seconda VNIC è stata creata nel Task 4 e collegata, dobbiamo assegnarvi un indirizzo IP. Quando aggiungi una seconda interfaccia a un'istanza, puoi assegnarla alla stessa subnet della prima interfaccia oppure puoi scegliere una nuova subnet.

DHCP non è abilitato per la seconda interfaccia, pertanto l'indirizzo IP deve essere assegnato manualmente.

Esistono diversi metodi per assegnare l'indirizzo IP per la seconda interfaccia.

Metodo 1: utilizzare l'interfaccia della riga di comando (OCI CLI) di Oracle Cloud Infrastructure (pacchetto oci-utils) per assegnare un indirizzo IP alla seconda interfaccia di un'istanza di OCI Compute utilizzando il comando OCI-network-config.
Metodo 2: utilizzare l'interfaccia CLI OCI (package oci-utils) per assegnare un indirizzo IP alla seconda interfaccia di un'istanza di OCI Compute utilizzando il daemon OCI.
Metodo 3: utilizzare lo script OCI_Multi_VNIC_Setup.
Metodo 4: creare manualmente il file di configurazione dell'interfaccia per la nuova VNIC nella cartella /etc/sysconfig/network-scripts/.

Per tutti i nodi di lavoro, è stato assegnato un indirizzo IP alla vNIC secondaria (ens5). Abbiamo utilizzato il metodo 3 per assegnare un indirizzo IP alla vNIC secondaria (ens5). Per ulteriori informazioni sull'assegnazione di un indirizzo IP alla seconda VNIC, vedere Assign an IP Address to a Second Interface on an Oracle Linux Instance.

Una volta che l'indirizzo IP è stato assegnato a una VNIC, è necessario verificare se l'indirizzo IP della seconda VNIC è configurato correttamente. Possiamo anche verificare se abbiamo abilitato SR-IOV su tutti i nodi di lavoro del pool di nodi.

Il nostro cluster OKE è composto da:

Pool di nodi
NP1	1 x nodo di lavoro
NP2	3 x nodi di lavoro

Verificheremo tutti i nodi di lavoro in tutti i pool di nodi.

Task 5.1: Verifica tutti i nodi nel pool di nodi 1 (`np1`)

Nel cluster OKE fare clic su Nodi.
Fare clic sul primo pool di nodi (np1).
Fare clic sul nodo di lavoro che fa parte di questo pool di nodi.
1. Tenere presente che il tipo di allegato NIC è VFIO (ciò significa che SR-IOV è abilitato per questo nodo di lavoro dell'istanza virtuale).
2. Tenere presente che la seconda VNIC viene creata e collegata per questo nodo di lavoro.

Task 5.2: Verifica tutti i nodi nel pool di nodi 2 (`np2`)

Fare clic sui nodi uno alla volta e avviare la verifica.
1. Tenere presente che il tipo di allegato NIC è VFIO (ciò significa che SR-IOV è abilitato per questo nodo di lavoro dell'istanza virtuale).
2. Tenere presente che la seconda VNIC viene creata e collegata per questo nodo di lavoro.
Andare alla pagina di riepilogo del pool di nodi 2 (np2). Fare clic sul secondo nodo di lavoro nel pool di nodi.
1. Tenere presente che il tipo di allegato NIC è VFIO (ciò significa che SR-IOV è abilitato per questo nodo di lavoro dell'istanza virtuale).
2. Tenere presente che la seconda VNIC viene creata e collegata per questo nodo di lavoro.
Andare alla pagina di riepilogo del pool di nodi 2 (np2). Fare clic sul terzo nodo di lavoro nel pool di nodi.
1. Tenere presente che il tipo di allegato NIC è VFIO (ciò significa che SR-IOV è abilitato per questo nodo di lavoro dell'istanza virtuale).
2. Tenere presente che la seconda VNIC viene creata e collegata per questo nodo di lavoro.

Eseguire il login utilizzando SSH all'operatore Kubernetes.

Eseguire il comando kubectl get nodes per recuperare una lista e gli indirizzi IP di tutti i nodi di lavoro.

[opc@o-sqrtga ~]$ kubectl get nodes
NAME           STATUS   ROLES   AGE   VERSION
10.0.112.134   Ready    node    68d   v1.30.1
10.0.66.97     Ready    node    68d   v1.30.1
10.0.73.242    Ready    node    68d   v1.30.1
10.0.89.50     Ready    node    68d   v1.30.1
[opc@o-sqrtga ~]$

Per semplificare l'accesso SSH a tutti i nodi di lavoro, è stata creata la tabella seguente.

Nome nodo lavoratore	IP ens3	Workernode comando SSH
cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0	10.0.112.134	`ssh -i id_rsa opc@10.0.112.134`
cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1	10.0.66.97	`ssh -i id_rsa opc@10.0.66.97`
cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0	10.0.73.242	`ssh -i id_rsa opc@10.0.73.242`
cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2	10.0.89.50	`ssh -i id_rsa opc@10.0.89.50`

Prima di poter eseguire l'accesso SSH a tutti i nodi di lavoro virtuali, assicurarsi di disporre della chiave privata corretta.
Eseguire il comando ssh -i <private key> opc@<ip-address> per eseguire SSH in tutti i nodi di lavoro.

immagine

Eseguire il comando ip a sul nodo di lavoro cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0.

Tenere presente che quando l'indirizzo IP è stato configurato correttamente, ens5 (seconda VNIC) dispone di un indirizzo IP nell'intervallo della subnet creata nel task 3.2 per le interfacce SR-IOV.

[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:59:58 brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.112.134/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 85530sec preferred_lft 85530sec
   inet6 fe80::17ff:fe00:5958/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:d4:a2 brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.30/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::8106:c09e:61fa:1d2a/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether 3a:b7:fb:e6:2e:cf brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.0/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::38b7:fbff:fee6:2ecf/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether de:35:f5:51:85:5d brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.1/25 brd 10.244.1.127 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::dc35:f5ff:fe51:855d/64 scope link
      valid_lft forever preferred_lft forever
6: veth1cdaac17@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 76:e2:92:ad:37:40 brd ff:ff:ff:ff:ff:ff link-netns 1935ba66-34cc-4468-8abb-f66add46d08b
   inet6 fe80::74e2:92ff:fead:3740/64 scope link
      valid_lft forever preferred_lft forever
7: vethbcd391ab@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 9a:9a:0f:d6:48:17 brd ff:ff:ff:ff:ff:ff link-netns 3f02d5fd-596e-4b9f-8a35-35f2f946901b
   inet6 fe80::989a:fff:fed6:4817/64 scope link
      valid_lft forever preferred_lft forever
8: vethc15fa705@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 3a:d2:c8:66:d1:0b brd ff:ff:ff:ff:ff:ff link-netns f581b7f2-cfa0-46eb-b0aa-37001a11116d
   inet6 fe80::38d2:c8ff:fe66:d10b/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$

Eseguire il comando ip a sul nodo di lavoro cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1.

[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:16:ca brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.66.97/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 85859sec preferred_lft 85859sec
   inet6 fe80::17ff:fe00:16ca/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:7b:4f brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.15/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::87eb:4195:cacf:a6da/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether 02:92:e7:f5:8e:29 brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.128/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::92:e7ff:fef5:8e29/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether f6:08:06:e2:bc:9d brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.129/25 brd 10.244.1.255 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::f408:6ff:fee2:bc9d/64 scope link
      valid_lft forever preferred_lft forever
6: veth5db97290@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether c2:e0:b5:7e:ce:ed brd ff:ff:ff:ff:ff:ff link-netns 3682b5cd-9039-4931-aecc-b50d46dabaf1
   inet6 fe80::c0e0:b5ff:fe7e:ceed/64 scope link
      valid_lft forever preferred_lft forever
7: veth6fd818a5@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 3e:a8:7d:84:d3:b9 brd ff:ff:ff:ff:ff:ff link-netns 08141d6b-5ec0-4f3f-a312-a00b30f82ade
   inet6 fe80::3ca8:7dff:fe84:d3b9/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$

Eseguire il comando ip a sul nodo di lavoro cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0.

[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:49:9c brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.73.242/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 86085sec preferred_lft 86085sec
   inet6 fe80::17ff:fe00:499c/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:b7:51 brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.14/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::bc31:aa09:4e05:9ab7/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether 9a:c7:1b:30:e8:9a brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.0/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::98c7:1bff:fe30:e89a/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether 2a:2b:cb:fb:15:82 brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.1/25 brd 10.244.0.127 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::282b:cbff:fefb:1582/64 scope link
      valid_lft forever preferred_lft forever
6: veth06343057@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether ca:70:83:13:dc:ed brd ff:ff:ff:ff:ff:ff link-netns fb0f181f-7c3a-4fb6-8bf0-5a65d39486c1
   inet6 fe80::c870:83ff:fe13:dced/64 scope link
      valid_lft forever preferred_lft forever
7: veth8af17165@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether c6:a0:be:75:9b:d9 brd ff:ff:ff:ff:ff:ff link-netns c07346e6-33f5-4e80-ba5e-74f7487b5daa
   inet6 fe80::c4a0:beff:fe75:9bd9/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$

Eseguire il comando ip a sul nodo di lavoro cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2.

[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:ac:7c brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.89.50/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 86327sec preferred_lft 86327sec
   inet6 fe80::17ff:fe00:ac7c/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:4c:0d brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.16/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::91eb:344e:829e:35de/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether aa:31:9f:d0:b3:3c brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.128/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::a831:9fff:fed0:b33c/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether b2:0d:c0:de:02:61 brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.129/25 brd 10.244.0.255 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::b00d:c0ff:fede:261/64 scope link
      valid_lft forever preferred_lft forever
6: vethb37e8987@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 7a:93:1d:2a:33:8c brd ff:ff:ff:ff:ff:ff link-netns ab3262ca-4a80-4b02-a39f-4209d003f148
   inet6 fe80::7893:1dff:fe2a:338c/64 scope link
      valid_lft forever preferred_lft forever
7: veth73a651ce@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether ae:e4:97:89:ba:6e brd ff:ff:ff:ff:ff:ff link-netns 9307bfbd-8165-46bf-916c-e1180b6cbd83
   inet6 fe80::ace4:97ff:fe89:ba6e/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$

Abbiamo verificato che tutti gli indirizzi IP sono configurati nella seconda VNIC (ens5), possiamo creare la tabella seguente con le informazioni.

IP ens3	ens3 GW	IP ens5	ens5 GW
10.0.112.134	10.0.64.1	10.0.3.30/27	10.0.3.1
10.0.66.97	10.0.64.1	10.0.3.15/27	10.0.3.1
10.0.73.242	10.0.64.1	10.0.3.14/27	10.0.3.1
10.0.89.50	10.0.64.1	10.0.3.16/27	10.0.3.1

L'immagine seguente mostra una panoramica visiva di ciò che abbiamo configurato finora.

Task 6: Installare un CNI Meta-Plugin (Multus CNI) sul nodo di lavoro

Multus CNI è un plugin Container Network Interface (CNI) Kubernetes che consente di collegare più interfacce di rete a un pod.

Come funziona Multus CNI

Atti come meta-plugin: Multus non fornisce la rete stessa, ma chiama invece altri plugin CNI.
Crea più interfacce di rete: ogni pod può avere più interfacce di rete combinando più plugin CNI (ad esempio, Flannel, Calico, SR-IOV).
Utilizza un file di configurazione: la rete primaria viene impostata utilizzando la rete CNI predefinita e le reti aggiuntive vengono collegate in base a una definizione di risorsa personalizzata (CRD, Custom Resource Definition).

Perché abbiamo bisogno di Multus CNI

Isolamento di più reti: utile per i carichi di lavoro che richiedono piani di gestione e dati separati.
Networking ad alte prestazioni: consente l'accesso diretto all'hardware utilizzando SR-IOV o DPDK.
Multi-Homing per pod: supporta NFV (Network Function Virtualization) e casi d'uso di Telco in cui sono essenziali più interfacce di rete.

Task 6.1: Installare Multus CNI utilizzando il metodo di installazione sottile

SSH nell'operatore Kubernetes.
1. Eseguire il comando seguente per clonare la libreria Multus Git.
```
git clone https://github.com/k8snetworkplumbingwg/multus-cni.git && cd multus-cni
```
2. Eseguire il comando seguente per installare il set di daemon Multus utilizzando il metodo di installazione thin.
```
kubectl apply -f deployments/multus-daemonset.yml && cd ..
```

Cosa fa il set di daemon Multus

Avvia un set di daemon Multus, questo esegue un pod su ciascun nodo che posiziona un binario Multus su ciascun nodo in /opt/cni/bin.
Legge il primo file di configurazione lessicografico (alfabetico) in /etc/cni/net.d e crea un nuovo file di configurazione per Multus su ogni nodo come /etc/cni/net.d/00-multus.conf, questa configurazione viene generata automaticamente e si basa sulla configurazione di rete predefinita (che si presume sia la prima configurazione alfabetica).
Crea una directory denominata /etc/cni/net.d/multus.d su ogni nodo con informazioni di autenticazione per consentire a Multus di accedere all'API Kubernetes.

Task 6.2: Convalida installazione Multus

Eseguire il comando seguente (su Kubernetes Operator) per verificare se il set di daemon Multus è installato su tutti i nodi di lavoro.
```
kubectl get pods --all-namespaces | grep -i multus
```
È inoltre possibile verificare se il set di daemon Multus è installato sui nodi di lavoro stessi.
1. Eseguire il comando ssh -i id_rsa opc@10.0.112.134 per eseguire SSH nel nodo di lavoro con il comando seguente.
2. Eseguire il comando cd /etc/cni/net.d/ per cambiare la directory con il comando seguente.
3. Eseguire il comando ls -l per elencare l'output della directory con il comando seguente.
4. Si noti che i file 00-multus.conf e multus.d sono elencati.
1. Eseguire il comando sudo more 00-multus.conf per visualizzare il contenuto del file 00-multus.conf.
2. Si noti il contenuto del file 00-multus.conf.

Task 7: Collegamento delle interfacce di rete ai pod

Questa procedura consente di mappare o attaccare un'interfaccia contenitore a questa VNIC.

Per collegare interfacce aggiuntive ai pod, è necessaria una configurazione per collegare l'interfaccia.

Questo è incapsulato nella risorsa personalizzata di tipo NetworkAttachmentDefinition.
Questa configurazione è essenzialmente una configurazione CNI inclusa in un package come risorsa personalizzata.

Ci sono diversi plugin CNI che possono essere utilizzati insieme a Multus per farlo. Per ulteriori informazioni, vedere Panoramica dei plugin.

Nell'approccio qui descritto, l'obiettivo è quello di fornire una SR-IOV Virtual Function (VF) esclusivamente per un singolo pod, in modo che il pod possa sfruttare le capacità senza interferenze o eventuali livelli intermedi.
Per concedere a un pod l'accesso esclusivo al VF, possiamo sfruttare il plugin host-device che consente di spostare l'interfaccia nello spazio di nomi del pod in modo che abbia accesso esclusivo ad esso. Per maggiori informazioni, vedere host-device.

L'esempio seguente mostra 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é vogliamo utilizzare gli stessi indirizzi IP assegnati alle interfacce secondarie da OCI, utilizziamo la configurazione statica ipam con gli instradamenti appropriati.
La configurazione ipam supporta anche altri metodi come host-local o dhcp per configurazioni più flessibili.

Task 7.1: Crea definizione allegato di rete

Il comando NetworkAttachmentDefinition viene utilizzato per impostare il collegamento di rete, ad esempio l'interfaccia secondaria per il pod.

Sono disponibili due modi per configurare NetworkAttachmentDefinition:

NetworkAttachmentDefinition con configurazione CNI JSON.
NetworkAttachmentDefinition con il file di configurazione CNI.

Nota: in questa esercitazione verrà utilizzato il metodo utilizzando il file di configurazione CNI.

Abbiamo 4 nodi di lavoro x e ogni nodo di lavoro ha una seconda VNIC che mapperemo a un'interfaccia su un contenitore (pod).

Eseguire i comandi riportati di seguito per creare i file di configurazione CNI per tutti i nodi di lavoro e le VNIC corrispondenti.

ens3	ens5	name	rete	comando nano
10.0.112.134	10.0.3.30/27	sriov-vnic-1	10.0.3.0/27	`sudo nano sriov-vnic-1.yaml`
10.0.66.97	10.0.3.15/27	sriov-vnic-2	10.0.3.0/27	`sudo nano sriov-vnic-2.yaml`
10.0.73.242	10.0.3.14/27	sriov-vnic-3	10.0.3.0/27	`sudo nano sriov-vnic-3.yaml`
10.0.89.50	10.0.3.16/27	sriov-vnic-4	10.0.3.0/27	`sudo nano sriov-vnic-4.yaml`

Eseguire i passi riportati di seguito nell'operatore Kubernetes. Creare un nuovo file YAML per il primo nodo di lavoro utilizzando il comando sudo nano sriov-vnic-1.yaml.
- Assicurarsi che il nome sia univoco e descrittivo. In questo esempio viene utilizzato sriov-vnic-1.
- Utilizzare l'indirizzo IP del secondo adattatore appena aggiunto (ens5).
- Assicurarsi che anche dst network sia corretto, è uguale alla subnet creata nel task 3.2.
sriov-vnic-1.yaml:
```
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.3.30/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'
```

Creare un nuovo file YAML per il secondo nodo di lavoro utilizzando il comando sudo nano sriov-vnic-2.yaml.

sriov-vnic-2.yaml:

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.3.15/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'

Creare un nuovo file YAML per il terzo nodo di lavoro utilizzando il comando sudo nano sriov-vnic-3.yaml.

sriov-vnic-3.yaml:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-3
spec:
config: '{
  "cniVersion": "0.3.1",
  "type": "host-device",
  "device": "ens5",
  "ipam": {
  "type": "static",
  "addresses": [
  {
  "address": "10.0.3.14/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'

Creare un nuovo file YAML per il quarto nodo di lavoro utilizzando il comando sudo nano sriov-vnic-4.yaml.

sriov-vnic-4.yaml:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-4
spec:
config: '{
  "cniVersion": "0.3.1",
  "type": "host-device",
  "device": "ens5",
  "ipam": {
  "type": "static",
  "addresses": [
  {
  "address": "10.0.3.16/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'

Applicare NetworkAttachmentDefinition ai nodi di lavoro.

Eseguire il comando kubectl apply -f sriov-vnic-1.yaml per il primo nodo.
Eseguire il comando kubectl apply -f sriov-vnic-2.yaml per il secondo nodo.
Eseguire il comando kubectl apply -f sriov-vnic-3.yaml per il terzo nodo.
Eseguire il comando kubectl apply -f sriov-vnic-4.yaml per il quarto nodo.

Se il file NetworkAttachmentDefinition viene applicato correttamente, verrà visualizzato un messaggio simile all'output.

[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-1.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1 created
[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-2.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2 created
[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-3.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3 created
[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-4.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4 created
[opc@o-sqrtga ~]$

Eseguire il comando kubectl get network-attachment-definitions.k8s.cni.cncf.io per verificare se il file NetworkAttachmentDefinitions è stato applicato correttamente.

[opc@o-sqrtga ~]$ kubectl get network-attachment-definitions.k8s.cni.cncf.io
NAME           AGE
sriov-vnic-1   96s
sriov-vnic-2   72s
sriov-vnic-3   60s
sriov-vnic-4   48s
[opc@o-sqrtga ~]$

Eseguire il comando kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1 -o yaml per ottenere il valore NetworkAttachmentDefinition applicato per il primo nodo di lavoro.

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-1","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.30/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:03:55Z"
generation: 1
name: sriov-vnic-1
namespace: default
resourceVersion: "22915413"
uid: 2d529130-2147-4f49-9d78-4e5aa12aea62
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.30/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'

Eseguire il comando kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2 -o yaml per ottenere il valore NetworkAttachmentDefinition applicato per il secondo nodo di lavoro.

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-2","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.15/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:04:19Z"
generation: 1
name: sriov-vnic-2
namespace: default
resourceVersion: "22915508"
uid: aec5740c-a093-43d3-bd6a-2209ee9e5c96
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.15/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'

Eseguire il comando kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3 -o yaml per ottenere il valore NetworkAttachmentDefinition applicato per il terzo nodo di lavoro.

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-3","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.14/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:04:31Z"
generation: 1
name: sriov-vnic-3
namespace: default
resourceVersion: "22915558"
uid: 91b970ff-328f-4b6b-a0d8-7cdd07d7bca3
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.14/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'

Eseguire il comando kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4 -o yaml per ottenere il valore NetworkAttachmentDefinition applicato per il quarto nodo di lavoro.

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-4","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.16/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:04:43Z"
generation: 1
name: sriov-vnic-4
namespace: default
resourceVersion: "22915607"
uid: 383fd3f0-7e5e-46ec-9997-29cbc9a2dcea
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.16/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'
[opc@o-sqrtga ~]$

L'immagine seguente mostra una panoramica visiva di ciò che abbiamo configurato finora.

Task 7.2: Creare pod con `NetworkDefinitionAttachment` allegato

In questo task, legheremo NetworkAttachmentDefinitions a un contenitore o pod effettivo.

Nella tabella seguente, abbiamo creato un mapping su quale pod vogliamo ospitare sul nodo di lavoro.

IP nodo di lavoro (principale)	ens5	name	nome pod	terminato
10.0.112.134	10.0.3.30/27	sriov-vnic-1	testpod1	SÌ
10.0.66.97	10.0.3.15/27	sriov-vnic-2	testpod2	SÌ
10.0.73.242	10.0.3.14/27	sriov-vnic-3	testpod3	SÌ
10.0.89.50	10.0.3.16/27	sriov-vnic-4	testpod4	SÌ

Task 7.3: Crea pod con affinità nodo

Per impostazione predefinita, Kubernetes deciderà dove verranno posizionati i pod (nodo di lavoro). In questo esempio, questa operazione non è possibile perché un indirizzo NetworkAttachmentDefinition è associato a un indirizzo IP e questo indirizzo IP è associato a una VNIC e questa VNIC è associata a un nodo di lavoro specifico. Quindi dobbiamo assicurarci che i pod che creiamo finiscano sul nodo di lavoro che vogliamo e questo è necessario quando colleghiamo il NetworkAttachmentDefinition a un pod.

Se non lo facciamo può accadere che un pod finisca su un altro dove l'indirizzo IP è disponibile per il pod. Pertanto, il pod non sarà in grado di comunicare utilizzando l'interfaccia abilitata per SR-IOV.

Ottenere tutti i nodi disponibili utilizzando il comando kubectl get nodes.

[opc@o-sqrtga ~]$ kubectl get nodes
NAME           STATUS   ROLES   AGE   VERSION
10.0.112.134   Ready    node    68d   v1.30.1
10.0.66.97     Ready    node    68d   v1.30.1
10.0.73.242    Ready    node    68d   v1.30.1
10.0.89.50     Ready    node    68d   v1.30.1
[opc@o-sqrtga ~]$

Assegnare un'etichetta al nodo di lavoro 1 utilizzando il comando kubectl label node 10.0.112.134 node_type=testpod1.
Assegnare un'etichetta al nodo di lavoro 2 utilizzando il comando kubectl label node 10.0.66.97 node_type=testpod2.
Assegnare un'etichetta al nodo di lavoro 3 utilizzando il comando kubectl label node 10.0.73.242 node_type=testpod3.
Assegnare un'etichetta al nodo di lavoro 4 utilizzando il comando kubectl label node 10.0.89.50 node_type=testpod4.

[opc@o-sqrtga ~]$ kubectl label node 10.0.112.134 node_type=testpod1
node/10.0.112.134 labeled
[opc@o-sqrtga ~]$ kubectl label node 10.0.73.242 node_type=testpod3
node/10.0.73.242 labeled
[opc@o-sqrtga ~]$ kubectl label node 10.0.66.97 node_type=testpod2
node/10.0.66.97 labeled
[opc@o-sqrtga ~]$ kubectl label node 10.0.89.50 node_type=testpod4
node/10.0.89.50 labeled
[opc@o-sqrtga ~]$

L'immagine seguente mostra una panoramica visiva di ciò che abbiamo configurato finora.

Creare un file YAML per testpod1 utilizzando il comando sudo nano testpod1-v2.yaml.

Si noti la sezione annotations in cui è possibile associare il file NetworkAttachmentDefinition creato in precedenza (sriov-vnic-1) a questo pod di test.
Si noti la sezione spec:affinity:nodeAffinity in cui il pod di test viene associato a un nodo di lavoro specifico con l'etichetta testpod1.

sudo nano testpod1-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod1
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-1
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod1
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

Creare un file YAML per testpod2 utilizzando il comando sudo nano testpod2-v2.yaml.

Si noti la sezione annotations in cui è possibile associare il file NetworkAttachmentDefinition creato in precedenza (sriov-vnic-2) a questo pod di test.
Si noti la sezione spec:affinity:nodeAffinity in cui il pod di test viene associato a un nodo di lavoro specifico con l'etichetta testpod2.

sudo nano testpod2-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod2
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-2
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod2
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

Creare un file YAML per testpod3 utilizzando il comando sudo nano testpod3-v2.yaml.

Si noti la sezione annotations in cui è possibile associare il file NetworkAttachmentDefinition creato in precedenza (sriov-vnic-3) a questo pod di test.
Si noti la sezione spec:affinity:nodeAffinity in cui il pod di test viene associato a un nodo di lavoro specifico con l'etichetta testpod3.

sudo nano testpod3-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod3
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-3
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod3
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

Creare un file YAML per testpod4 utilizzando il comando sudo nano testpod4-v2.yaml.

Si noti la sezione annotations in cui è possibile associare il file NetworkAttachmentDefinition creato in precedenza (sriov-vnic-4) a questo pod di test.
Si noti la sezione spec:affinity:nodeAffinity in cui il pod di test viene associato a un nodo di lavoro specifico con l'etichetta testpod4

sudo nano testpod4-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod4
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-4
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod4
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

Creare testpod1 applicando il file YAML utilizzando il comando kubectl apply -f testpod1-v2.yaml.
Creare testpod2 applicando il file YAML utilizzando il comando kubectl apply -f testpod2-v2.yaml.
Creare testpod3 applicando il file YAML utilizzando il comando kubectl apply -f testpod3-v2.yaml.
Creare testpod4 applicando il file YAML utilizzando il comando kubectl apply -f testpod4-v2.yaml.

[opc@o-sqrtga ~]$ kubectl apply -f testpod1-v2.yaml
pod/testpod1 created
[opc@o-sqrtga ~]$ kubectl apply -f testpod2-v2.yaml
pod/testpod2 created
[opc@o-sqrtga ~]$ kubectl apply -f testpod3-v2.yaml
pod/testpod3 created
[opc@o-sqrtga ~]$ kubectl apply -f testpod4-v2.yaml
pod/testpod4 created
[opc@o-sqrtga ~]$

Verificare se i pod di test vengono creati utilizzando il comando kubectl get pod. Si noti che tutti i pod di test vengono creati e hanno lo Running STATUS.

[opc@o-sqrtga ~]$ kubectl get pod
NAME                       READY   STATUS    RESTARTS   AGE
my-nginx-576c6b7b6-6fn6f   1/1     Running   3          40d
my-nginx-576c6b7b6-k9wwc   1/1     Running   3          40d
my-nginx-576c6b7b6-z8xkd   1/1     Running   6          40d
mysql-6d7f5d5944-dlm78     1/1     Running   12         35d
testpod1                   1/1     Running   0          2m29s
testpod2                   1/1     Running   0          2m17s
testpod3                   1/1     Running   0          2m5s
testpod4                   1/1     Running   0          111s
[opc@o-sqrtga ~]$

Verificare se testpod1 è in esecuzione sul nodo di lavoro 10.0.112.134 con l'etichetta testpod1 utilizzando il comando kubectl get pod testpod1 -o wide.

[opc@o-sqrtga ~]$ kubectl get pod testpod1 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP           NODE           NOMINATED NODE   READINESS GATES
testpod1   1/1     Running   0          3m41s   10.244.1.6   10.0.112.134   <none>           <none>

Verificare se testpod2 è in esecuzione sul nodo di lavoro 10.0.66.97 con l'etichetta testpod2 utilizzando il comando kubectl get pod testpod2 -o wide.

[opc@o-sqrtga ~]$ kubectl get pod testpod2 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP             NODE         NOMINATED NODE   READINESS GATES
testpod2   1/1     Running   0          3m33s   10.244.1.133   10.0.66.97   <none>           <none>

Verificare se testpod3 è in esecuzione sul nodo di lavoro 10.0.73.242 con l'etichetta testpod3 utilizzando il comando kubectl get pod testpod3 -o wide.

[opc@o-sqrtga ~]$ kubectl get pod testpod3 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP           NODE          NOMINATED NODE   READINESS GATES
testpod3   1/1     Running   0          3m25s   10.244.0.5   10.0.73.242   <none>           <none>

Verificare se testpod4 è in esecuzione sul nodo di lavoro 10.0.89.50 con l'etichetta testpod4 utilizzando il comando kubectl get pod testpod4 -o wide.

[opc@o-sqrtga ~]$ kubectl get pod testpod4 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP             NODE         NOMINATED NODE   READINESS GATES
testpod4   1/1     Running   0          3m22s   10.244.0.133   10.0.89.50   <none>           <none>

L'immagine seguente mostra una panoramica visiva di ciò che abbiamo configurato finora.

Task 7.4: Verificare l'indirizzo IP sui pod di test

Verificare l'indirizzo IP di testpod1 per l'interfaccia pod net1 utilizzando il comando kubectl exec -it testpod1 -- ip addr show.

Si noti che l'indirizzo IP dell'interfaccia net1 è 10.0.3.30/27.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether ca:28:e4:5f:66:c4 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.0.132/25 brd 10.244.0.255 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::c828:e4ff:fe5f:66c4/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:4c:0d brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.30/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:4c0d/64 scope link
	valid_lft forever preferred_lft forever

Verificare l'indirizzo IP di testpod2 per l'interfaccia pod net1 utilizzando il comando kubectl exec -it testpod2 -- ip addr show.

Si noti che l'indirizzo IP dell'interfaccia net1 è 10.0.3.15/27.

[opc@o-sqrtga ~]$ kubectl exec -it testpod2 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether da:ce:84:22:fc:29 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.1.132/25 brd 10.244.1.255 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::d8ce:84ff:fe22:fc29/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:7b:4f brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.15/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:7b4f/64 scope link
	valid_lft forever preferred_lft forever

Verificare l'indirizzo IP di testpod3 per l'interfaccia pod net1 utilizzando il comando kubectl exec -it testpod3 -- ip addr show.

Si noti che l'indirizzo IP dell'interfaccia net1 è 10.0.3.14/27.

[opc@o-sqrtga ~]$ kubectl exec -it testpod3 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether de:f2:81:10:04:b2 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.0.4/25 brd 10.244.0.127 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::dcf2:81ff:fe10:4b2/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:b7:51 brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.14/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:b751/64 scope link
	valid_lft forever preferred_lft forever

Verificare l'indirizzo IP di testpod4 per l'interfaccia pod net1 utilizzando il comando kubectl exec -it testpod4 -- ip addr show.

Si noti che l'indirizzo IP dell'interfaccia net1 è 10.0.3.16/27.

[opc@o-sqrtga ~]$ kubectl exec -it testpod4 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether ea:63:eb:57:9c:99 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.1.5/25 brd 10.244.1.127 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::e863:ebff:fe57:9c99/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:d4:a2 brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.16/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:d4a2/64 scope link
	valid_lft forever preferred_lft forever
[opc@o-sqrtga ~]$

La tabella seguente mostra una panoramica di tutti gli indirizzi IP delle interfacce net1 per tutti i pod di test.

nome pod	IP net1
testpod1	10.0.3.30/27
testpod2	10.0.3.15/27
testpod3	10.0.3.14/27
testpod4	10.0.3.16/27

Nota: questi indirizzi IP si trovano nello stesso intervallo della subnet OCI creata nel task 3 per posizionare le nostre VNIC abilitate per SR-IOV.

Task 7.5: Verifica l'indirizzo IP sui nodi di lavoro

Ora che le interfacce net1 dei pod di test hanno un indirizzo IP, si noti che questo indirizzo IP era l'indirizzo IP dell'interfaccia ens5 sui nodi di lavoro. Questo indirizzo IP viene spostato dall'interfaccia del nodo di lavoro ens5 all'interfaccia del pod di test net1.

SSH nel primo nodo di lavoro utilizzando il comando ssh -i id_rsa opc@10.0.112.134.

Ottenere gli indirizzi IP di tutte le interfacce utilizzando il comando ip a.
Si noti che l'interfaccia ens5 è stata rimossa dal nodo di lavoro.

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.112.134
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 20:42:19 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:59:58 brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.112.134/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82180sec preferred_lft 82180sec
	inet6 fe80::17ff:fe00:5958/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether 3a:b7:fb:e6:2e:cf brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.0/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::38b7:fbff:fee6:2ecf/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether de:35:f5:51:85:5d brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.1/25 brd 10.244.1.127 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::dc35:f5ff:fe51:855d/64 scope link
	valid_lft forever preferred_lft forever
6: veth1cdaac17@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 76:e2:92:ad:37:40 brd ff:ff:ff:ff:ff:ff link-netns 1935ba66-34cc-4468-8abb-f66add46d08b
	inet6 fe80::74e2:92ff:fead:3740/64 scope link
	valid_lft forever preferred_lft forever
7: vethbcd391ab@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 9a:9a:0f:d6:48:17 brd ff:ff:ff:ff:ff:ff link-netns 3f02d5fd-596e-4b9f-8a35-35f2f946901b
	inet6 fe80::989a:fff:fed6:4817/64 scope link
	valid_lft forever preferred_lft forever
8: vethc15fa705@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 3a:d2:c8:66:d1:0b brd ff:ff:ff:ff:ff:ff link-netns f581b7f2-cfa0-46eb-b0aa-37001a11116d
	inet6 fe80::38d2:c8ff:fe66:d10b/64 scope link
	valid_lft forever preferred_lft forever
9: vethc663e496@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 7e:0b:bb:5d:49:8c brd ff:ff:ff:ff:ff:ff link-netns d3993135-0f2f-4b06-b16d-31d659f8230d
	inet6 fe80::7c0b:bbff:fe5d:498c/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$ exit
logout
Connection to 10.0.112.134 closed.

SSH nel secondo nodo di lavoro utilizzando il comando ssh -i id_rsa opc@10.0.66.97.

Ottenere gli indirizzi IP di tutte le interfacce utilizzando il comando ip a.
Si noti che l'interfaccia ens5 è stata rimossa dal nodo di lavoro.

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.66.97
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 19:47:55 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:16:ca brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.66.97/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82502sec preferred_lft 82502sec
	inet6 fe80::17ff:fe00:16ca/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether 02:92:e7:f5:8e:29 brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.128/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::92:e7ff:fef5:8e29/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether f6:08:06:e2:bc:9d brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.129/25 brd 10.244.1.255 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::f408:6ff:fee2:bc9d/64 scope link
	valid_lft forever preferred_lft forever
6: veth5db97290@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether c2:e0:b5:7e:ce:ed brd ff:ff:ff:ff:ff:ff link-netns 3682b5cd-9039-4931-aecc-b50d46dabaf1
	inet6 fe80::c0e0:b5ff:fe7e:ceed/64 scope link
	valid_lft forever preferred_lft forever
7: veth6fd818a5@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 3e:a8:7d:84:d3:b9 brd ff:ff:ff:ff:ff:ff link-netns 08141d6b-5ec0-4f3f-a312-a00b30f82ade
	inet6 fe80::3ca8:7dff:fe84:d3b9/64 scope link
	valid_lft forever preferred_lft forever
8: veth26f6b686@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether ae:bf:36:ca:52:cf brd ff:ff:ff:ff:ff:ff link-netns f533714a-69be-4b20-be30-30ba71494f7a
	inet6 fe80::acbf:36ff:feca:52cf/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$ exit
logout
Connection to 10.0.66.97 closed.

SSH nel terzo nodo di lavoro utilizzando il comando ssh -i id_rsa opc@10.0.73.242.

Ottenere gli indirizzi IP di tutte le interfacce utilizzando il comando ip a.
Si noti che l'interfaccia ens5 è stata rimossa dal nodo di lavoro.

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.73.242
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 20:08:31 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:49:9c brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.73.242/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82733sec preferred_lft 82733sec
	inet6 fe80::17ff:fe00:499c/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether 9a:c7:1b:30:e8:9a brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.0/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::98c7:1bff:fe30:e89a/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether 2a:2b:cb:fb:15:82 brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.1/25 brd 10.244.0.127 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::282b:cbff:fefb:1582/64 scope link
	valid_lft forever preferred_lft forever
6: veth06343057@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether ca:70:83:13:dc:ed brd ff:ff:ff:ff:ff:ff link-netns fb0f181f-7c3a-4fb6-8bf0-5a65d39486c1
	inet6 fe80::c870:83ff:fe13:dced/64 scope link
	valid_lft forever preferred_lft forever
7: veth8af17165@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether c6:a0:be:75:9b:d9 brd ff:ff:ff:ff:ff:ff link-netns c07346e6-33f5-4e80-ba5e-74f7487b5daa
	inet6 fe80::c4a0:beff:fe75:9bd9/64 scope link
	valid_lft forever preferred_lft forever
8: veth170b8774@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether e6:c9:42:60:8f:e7 brd ff:ff:ff:ff:ff:ff link-netns edef0c81-0477-43fa-b260-6b81626e7d87
	inet6 fe80::e4c9:42ff:fe60:8fe7/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$ exit
logout
Connection to 10.0.73.242 closed.

SSH nel quarto nodo di lavoro utilizzando il comando ssh -i id_rsa opc@10.0.89.50.

Ottenere gli indirizzi IP di tutte le interfacce utilizzando il comando ip a.
Si noti che l'interfaccia ens5 è stata rimossa dal nodo di lavoro.

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.89.50
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 19:49:27 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:ac:7c brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.89.50/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82976sec preferred_lft 82976sec
	inet6 fe80::17ff:fe00:ac7c/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether aa:31:9f:d0:b3:3c brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.128/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::a831:9fff:fed0:b33c/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether b2:0d:c0:de:02:61 brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.129/25 brd 10.244.0.255 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::b00d:c0ff:fede:261/64 scope link
	valid_lft forever preferred_lft forever
6: vethb37e8987@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 7a:93:1d:2a:33:8c brd ff:ff:ff:ff:ff:ff link-netns ab3262ca-4a80-4b02-a39f-4209d003f148
	inet6 fe80::7893:1dff:fe2a:338c/64 scope link
	valid_lft forever preferred_lft forever
7: veth73a651ce@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether ae:e4:97:89:ba:6e brd ff:ff:ff:ff:ff:ff link-netns 9307bfbd-8165-46bf-916c-e1180b6cbd83
	inet6 fe80::ace4:97ff:fe89:ba6e/64 scope link
	valid_lft forever preferred_lft forever
8: veth42c3a604@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether f2:e6:ba:72:8f:b2 brd ff:ff:ff:ff:ff:ff link-netns a7eb561c-8182-49b2-9e43-7c52845620a7
	inet6 fe80::f0e6:baff:fe72:8fb2/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$ exit
logout
Connection to 10.0.89.50 closed.
[opc@o-sqrtga ~]$

L'immagine seguente mostra una panoramica visiva di ciò che abbiamo configurato finora.

Task 8: Esecuzione di test di ping tra più pod

Tutti i pod dispongono di un indirizzo IP dalla subnet OCI in cui sono collegate le VNIC abilitate per SR-IOV, possiamo eseguire alcuni test di ping per verificare se la connettività di rete funziona correttamente.

La tabella seguente fornisce i comandi per connettersi ai pod di test dall'operatore Kubernetes.

Abbiamo bisogno di questo per exec in ogni pod per eseguire un ping test o per guardare la tabella di instradamento.

ens3	net1	name	nome pod	comando
10.0.112.134	10.0.3.30/27	sriov-vnic-1	testpod1	`kubectl exec -it testpod1 -- /bin/bash`
10.0.66.97	10.0.3.15/27	sriov-vnic-2	testpod2	`kubectl exec -it testpod2 -- /bin/bash`
10.0.73.242	10.0.3.14/27	sriov-vnic-3	testpod3	`kubectl exec -it testpod3 -- /bin/bash`
10.0.89.50	10.0.3.16/27	sriov-vnic-4	testpod4	`kubectl exec -it testpod4 -- /bin/bash`

Eseguire il comando kubectl exec -it testpod1 -- route -n per esaminare la tabella di instradamento direttamente dal terminale Kubernetes Operator per testpod1.

Si noti che la tabella di routing di testpod1 ha un gateway predefinito per eth0 e per net1, che è la nostra interfaccia abilitata per SR-IOV.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.0.129    0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      10.244.0.129    255.255.0.0     UG    0      0        0 eth0
10.244.0.128    0.0.0.0         255.255.255.128 U     0      0        0 eth0

Eseguire il comando kubectl exec -it testpod2 -- route -n per esaminare la tabella di instradamento direttamente dal terminale Kubernetes Operator per testpod2.

Si noti che la tabella di routing di testpod2 ha un gateway predefinito per eth0 e per net1, che è la nostra interfaccia abilitata per SR-IOV.

[opc@o-sqrtga ~]$ kubectl exec -it testpod2 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.1.129    0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      10.244.1.129    255.255.0.0     UG    0      0        0 eth0
10.244.1.128    0.0.0.0         255.255.255.128 U     0      0        0 eth0

Eseguire il comando kubectl exec -it testpod3 -- route -n per esaminare la tabella di instradamento direttamente dal terminale Kubernetes Operator per testpod3.

Si noti che la tabella di routing di testpod3 ha un gateway predefinito per eth0 e per net1, che è la nostra interfaccia abilitata per SR-IOV.

[opc@o-sqrtga ~]$ kubectl exec -it testpod3 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.0.1      0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      0.0.0.0         255.255.255.128 U     0      0        0 eth0
10.244.0.0      10.244.0.1      255.255.0.0     UG    0      0        0 eth0

Eseguire il comando kubectl exec -it testpod4 -- route -n per esaminare la tabella di instradamento direttamente dal terminale Kubernetes Operator per testpod4.

Si noti che la tabella di routing di testpod4 ha un gateway predefinito per eth0 e per net1, che è la nostra interfaccia abilitata per SR-IOV.

[opc@o-sqrtga ~]$ kubectl exec -it testpod4 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.1.1      0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      10.244.1.1      255.255.0.0     UG    0      0        0 eth0
10.244.1.0      0.0.0.0         255.255.255.128 U     0      0        0 eth0
[opc@o-sqrtga ~]$

Per eseguire il test ping dall'operatore Kubernetes direttamente dai pod di test, è necessario il comando ping.

Nella tabella seguente, abbiamo fornito tutti i comandi di ping per tutti i pod di test. Il comando eseguirà il ping da un determinato pod di test a tutti gli altri pod di test, incluso il relativo indirizzo IP net1.

Nome pod di origine	comando
testpod1	`kubectl exec -it testpod1 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod1 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod1 -- ping -I net1 10.0.3.14 -c 4` `kubectl exec -it testpod1 -- ping -I net1 10.0.3.16 -c 4`
testpod2	`kubectl exec -it testpod2 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod2 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod2 -- ping -I net1 10.0.3.14 -c 4` `kubectl exec -it testpod2 -- ping -I net1 10.0.3.16 -c 4`
testpod3	`kubectl exec -it testpod3 -- ping -I net1 10.0.3.14 -c 4` `kubectl exec -it testpod3 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod3 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod3 -- ping -I net1 10.0.3.16 -c 4`
testpod4	`kubectl exec -it testpod4 -- ping -I net1 10.0.3.16 -c 4` `kubectl exec -it testpod4 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod4 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod4 -- ping -I net1 10.0.3.14 -c 4`

Nota: in questo esempio viene utilizzato testpod1 per eseguire il ping di tutti gli altri pod di test net1 indirizzi IP.

Eseguire il comando kubectl exec -it testpod1 -- ping -I net1 10.0.3.30 -c 4 per eseguire il ping da testpod1 a testpod1.

Si noti che il ping ha 4 packets transmitted, 4 received, 0% packet loss. Quindi il ping ha successo.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.30 -c 4
PING 10.0.3.30 (10.0.3.30) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.30: icmp_seq=1 ttl=64 time=0.043 ms
64 bytes from 10.0.3.30: icmp_seq=2 ttl=64 time=0.024 ms
64 bytes from 10.0.3.30: icmp_seq=3 ttl=64 time=0.037 ms
64 bytes from 10.0.3.30: icmp_seq=4 ttl=64 time=0.026 ms

--- 10.0.3.30 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3087ms
rtt min/avg/max/mdev = 0.024/0.032/0.043/0.009 ms

Eseguire il comando kubectl exec -it testpod1 -- ping -I net1 10.0.3.15 -c 4 per eseguire il ping da testpod1 a testpod2.

Si noti che il ping ha 4 packets transmitted, 4 received, 0% packet loss. Quindi il ping ha successo.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.15 -c 4
PING 10.0.3.15 (10.0.3.15) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.15: icmp_seq=1 ttl=64 time=0.383 ms
64 bytes from 10.0.3.15: icmp_seq=2 ttl=64 time=0.113 ms
64 bytes from 10.0.3.15: icmp_seq=3 ttl=64 time=0.114 ms
64 bytes from 10.0.3.15: icmp_seq=4 ttl=64 time=0.101 ms

--- 10.0.3.15 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3109ms
rtt min/avg/max/mdev = 0.101/0.177/0.383/0.119 ms

Eseguire il comando kubectl exec -it testpod1 -- ping -I net1 10.0.3.14 -c 4 per eseguire il ping da testpod1 a testpod3.

Si noti che il ping ha 4 packets transmitted, 4 received, 0% packet loss. Quindi il ping ha successo.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.14 -c 4
PING 10.0.3.14 (10.0.3.14) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.14: icmp_seq=1 ttl=64 time=0.399 ms
64 bytes from 10.0.3.14: icmp_seq=2 ttl=64 time=0.100 ms
64 bytes from 10.0.3.14: icmp_seq=3 ttl=64 time=0.130 ms
64 bytes from 10.0.3.14: icmp_seq=4 ttl=64 time=0.124 ms

--- 10.0.3.14 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3057ms
rtt min/avg/max/mdev = 0.100/0.188/0.399/0.122 ms

Eseguire il comando kubectl exec -it testpod1 -- ping -I net1 10.0.3.16 -c 4 per eseguire il ping da testpod1 a testpod4.

Si noti che il ping ha 4 packets transmitted, 4 received, 0% packet loss. Quindi il ping ha successo.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.16 -c 4
PING 10.0.3.16 (10.0.3.16) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.16: icmp_seq=1 ttl=64 time=0.369 ms
64 bytes from 10.0.3.16: icmp_seq=2 ttl=64 time=0.154 ms
64 bytes from 10.0.3.16: icmp_seq=3 ttl=64 time=0.155 ms
64 bytes from 10.0.3.16: icmp_seq=4 ttl=64 time=0.163 ms

--- 10.0.3.16 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3110ms
rtt min/avg/max/mdev = 0.154/0.210/0.369/0.092 ms
[opc@o-sqrtga ~]$

Nota: non sono stati inclusi tutti gli altri output di ping per tutti gli altri pod di test, ma l'idea è chiara.

L'immagine seguente mostra una panoramica visiva di ciò che abbiamo configurato finora.

Task 9: (Facoltativo) Distribuzione di pod con più interfacce

Fino ad ora abbiamo preparato una sola VNIC (che supporta SR-IOV) e spostato questa VNIC in un pod. Abbiamo fatto questo per quattro diversi test pod.

Ora cosa succede se vogliamo aggiungere o spostare più VNIC in un particolare pod? È necessario ripetere questi passi:

Creare una nuova subnet OCI.
Creare una nuova VNIC e assegnare l'indirizzo IP.
Creare un nuovo NetworkAttachmentDefinitions.
Aggiornare il file YAML del pod di test aggiungendo nuove annotazioni.

In questa attività, troverai un esempio in cui creeremo una subnet aggiuntiva, VNIC, assegneremo l'indirizzo IP, NetworkAttachmentDefinition e lo aggiungeremo al file YAML di creazione pod per testpod1.

Questo è il NetworkAttachmentDefinition per una nuova interfaccia ens6 con un indirizzo IP 10.0.4.29/27 sulla rete 10.0.4.0/27.

Si noti che questo è un altro NetworkAttachmentDefinition rispetto a prima per l'interfaccia ens5 con un indirizzo IP 10.0.3.30/27 sulla rete 10.0.3.0/27.

sriov-vnic-2-new.yaml:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-2-new
spec:
config: '{
		"cniVersion": "0.3.1",
		"type": "host-device",
		"device": "ens6",
		"ipam": {
				"type": "static",
				"addresses": [
					{
						"address": "10.0.4.29/27",
						"gateway": "0.0.0.0"
					}
				],
				"routes": [
					{ "dst": "10.0.4.0/27", "gw": "0.0.0.0" }
				]
			}
		}'

File YAML (aggiornato) per testpod1.

Si noti la riga aggiuntiva nel file annotations in cui si fa riferimento al nuovo file NetworkAttachmentDefinition; sriov-vnic-2-new.

sudo nano testpod1-v3.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod1
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-1
	k8s.v1.cni.cncf.io/networks: sriov-vnic-2-new
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod1
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

Task 10: Rimuovi tutte le distribuzioni pod e `NetworkAttachmentDefinitions`

Se si desidera ricominciare da capo o pulire i contenitori con NetworkAttachmentDefinitions, attenersi alla procedura riportata di seguito.

Ottenere tutti i pod utilizzando il comando kubectl get pod.

[opc@o-sqrtga ~]$ kubectl get pod
NAME                       READY   STATUS    RESTARTS   AGE
my-nginx-576c6b7b6-6fn6f   1/1     Running   3          105d
my-nginx-576c6b7b6-k9wwc   1/1     Running   3          105d
my-nginx-576c6b7b6-z8xkd   1/1     Running   6          105d
mysql-6d7f5d5944-dlm78     1/1     Running   12         100d
testpod1                   1/1     Running   0          64d
testpod2                   1/1     Running   0          64d
testpod3                   1/1     Running   0          64d
testpod4                   1/1     Running   0          64d
[opc@o-sqrtga ~]$

Eliminare i pod di test utilizzando i comandi seguenti.

kubectl delete -f testpod1-v2.yaml

kubectl delete -f testpod2-v2.yaml

kubectl delete -f testpod3-v2.yaml

kubectl delete -f testpod4-v2.yaml

Ottenere tutto il file NetworkAttachmentDefinitions utilizzando il comando kubectl get network-attachment-definitions.k8s.cni.cncf.io.

[opc@o-sqrtga ~]$ kubectl get network-attachment-definitions.k8s.cni.cncf.io
NAME           AGE
sriov-vnic-1   64d
sriov-vnic-2   64d
sriov-vnic-3   64d
sriov-vnic-4   64d
[opc@o-sqrtga ~]$

Eliminare NetworkAttachmentDefinitions con i seguenti comandi.

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4

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

Conferme

Autore: Iwan Hoogendoorn (esperto della rete OCI)

Altre risorse di apprendimento

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

Per la documentazione del prodotto, visitare Oracle Help Center.

Titolo e informazioni sul copyright

Deploy SR-IOV Enabled Network Interfaces Container Apps on OKE Using Multus CNI Plugin

G28057-02

Distribuisci applicazioni contenitore interfacce di rete abilitate per SR-IOV su OKE utilizzando il plugin Multus CNI

Introduzione

Obiettivi

Task 1: Distribuire OKE con un bastion, un operatore, tre nodi di lavoro VM e il plugin CNI Flannel

Task 2: Abilitare la rete SR-IOV (Hardware-Assisted) su ogni nodo lavoratore

Task 3: Creare una nuova subnet per le VNIC abilitate per SR-IOV

Task 3.1: Creare una lista di sicurezza

Task 3.2: Creare una subnet

Task 4: Aggiungi un secondo allegato VNIC

Task 4.1: Creare un gruppo di sicurezza di rete (NSG)

Task 4.2: aggiungere la VNIC

Task 5: Assegnazione di un indirizzo IP alla nuova seconda VNIC con un gateway predefinito

Task 5.1: Verifica tutti i nodi nel pool di nodi 1 (np1)

Task 5.2: Verifica tutti i nodi nel pool di nodi 2 (np2)

Task 6: Installare un CNI Meta-Plugin (Multus CNI) sul nodo di lavoro

Task 6.1: Installare Multus CNI utilizzando il metodo di installazione sottile

Task 6.2: Convalida installazione Multus

Task 7: Collegamento delle interfacce di rete ai pod

Task 7.1: Crea definizione allegato di rete

Task 7.2: Creare pod con NetworkDefinitionAttachment allegato

Task 7.3: Crea pod con affinità nodo

Task 7.4: Verificare l'indirizzo IP sui pod di test

Task 7.5: Verifica l'indirizzo IP sui nodi di lavoro

Task 8: Esecuzione di test di ping tra più pod

Task 9: (Facoltativo) Distribuzione di pod con più interfacce

Task 10: Rimuovi tutte le distribuzioni pod e NetworkAttachmentDefinitions

Collegamenti correlati

Conferme

Altre risorse di apprendimento

Task 5.1: Verifica tutti i nodi nel pool di nodi 1 (`np1`)

Task 5.2: Verifica tutti i nodi nel pool di nodi 2 (`np2`)

Task 7.2: Creare pod con `NetworkDefinitionAttachment` allegato

Task 10: Rimuovi tutte le distribuzioni pod e `NetworkAttachmentDefinitions`