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.
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.
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.
Abilita SR-IOV sull'istanza
-
Eseguire il login con SSH all'istanza o al nodo di lavoro.
- Eseguire il comando
lspci
per verificare quale driver di rete viene attualmente utilizzato in tutte le VNIC. - Si noti che viene utilizzato il driver di rete
Virtio
.
- Andare alla pagina Dettagli istanza in OCI Console.
- scorrere in Basso.
- Si noti che il tipo di allegato NIC è ora PARAVIRTUALIZED.
- Andare alla pagina Dettagli istanza in OCI Console.
- Fare clic su Altre azioni.
- Fare clic su Modifica.
- Eseguire il comando
-
Fare clic su Visualizza opzioni avanzate.
- Fare clic su Opzioni di avvio e selezionare Networking hardware assistito (SR-IOV) come Tipo di networking.
- 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.
- scorrere in Basso.
- 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.
- Passare a Reti cloud virtuali.
- Fare clic sulla VCN esistente.
- Fare clic su Elenchi sicurezza.
- Fare clic su Crea lista di sicurezza.
-
Per la Regola di entrata 1, immettere le seguenti informazioni.
- Immettere un Nome.
- Selezionare CIDR come Tipo di origine.
- Immettere
0.0.0.0/0
come CIDR origine. - Selezionare Tutti i protocolli come Protocollo IP.
- scorrere in Basso.
- Per la Regola di uscita 1, immettere le seguenti informazioni.
- Selezionare CIDR come Tipo di origine.
- Immettere
0.0.0.0/0
come CIDR origine. - Selezionare Tutti i protocolli come Protocollo IP.
- 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.
- Fare clic su Sottoreti.
- Prendere nota delle subnet esistenti già create per l'ambiente OKE.
- Fare clic su Crea subnet.
- Immettere un Nome.
- Immettere il blocco IPv4 CIDR.
- scorrere in Basso.
- Selezionare Subnet privata.
- scorrere in Basso.
- Selezionare Opzioni DHCP predefinite per le opzioni DHCP.
- Selezionare l'elenco di sicurezza creato nel task 3.1.
- 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.
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.
- Andare a Gruppi di sicurezza di rete.
- Fare clic su Crea gruppo di sicurezza di rete.
-
Aggiungere le seguenti regole.
- Ingresso:
- Consenti tipo di origine: selezionare CIDR.
- Origine: immettere
0.0.0.0/0
. - Destinazione: lasciare vuota la destinazione.
- Protocollo: consente tutti i protocolli.
- Uscita:
- Consenti tipo di origine: selezionare CIDR.
- Origine: lasciare vuota l'origine.
- Destinazione: immettere
0.0.0.0/0
. - Protocollo: consente tutti i protocolli.
- Ingresso:
-
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.
- Andare a ciascuna istanza del nodo di lavoro virtuale e fare clic su VNIC collegate.
- Tenere presente che esiste già una VNIC.
- Fare clic su Crea VNIC per aggiungere una seconda VNIC.
- Immettere un Nome.
- Selezionare la VCN.
- Selezionare la subnet creata nel task 3.2.
- Selezionare Utilizza gruppi per la sicurezza della rete per controllare il traffico.
- Selezionare il NSG creato nel task 4.1.
- scorrere in Basso.
- Selezionare Assegna automaticamente indirizzo IPv4 privato.
- 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.
- Eseguire il comando
lspci
per verificare quale driver di rete viene attualmente utilizzato in tutte le VNIC. - 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.
- Eseguire il comando
-
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.
- Tenere presente che il tipo di allegato NIC è VFIO (ciò significa che SR-IOV è abilitato per questo nodo di lavoro dell'istanza virtuale).
- 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.
- Tenere presente che il tipo di allegato NIC è VFIO (ciò significa che SR-IOV è abilitato per questo nodo di lavoro dell'istanza virtuale).
- 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.- Tenere presente che il tipo di allegato NIC è VFIO (ciò significa che SR-IOV è abilitato per questo nodo di lavoro dell'istanza virtuale).
- 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.- Tenere presente che il tipo di allegato NIC è VFIO (ciò significa che SR-IOV è abilitato per questo nodo di lavoro dell'istanza virtuale).
- 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.
-
Eseguire il comando
ip a
sul nodo di lavorocwe6rhf2leq-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 lavorocwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1
.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-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 lavorocwe6rhf2leq-ng556bw23ra-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-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 lavorocwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2
.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-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.
-
Eseguire il comando seguente per clonare la libreria Multus Git.
git clone https://github.com/k8snetworkplumbingwg/multus-cni.git && cd multus-cni
-
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.
- Eseguire il comando
ssh -i id_rsa opc@10.0.112.134
per eseguire SSH nel nodo di lavoro con il comando seguente. - Eseguire il comando
cd /etc/cni/net.d/
per cambiare la directory con il comando seguente. - Eseguire il comando
ls -l
per elencare l'output della directory con il comando seguente. - Si noti che i file
00-multus.conf
emultus.d
sono elencati.
- Eseguire il comando
sudo more 00-multus.conf
per visualizzare il contenuto del file00-multus.conf
. - Si noti il contenuto del file
00-multus.conf
.
- Eseguire il comando
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 comehost-local
odhcp
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
-
Eseguire il comando
kubectl get network-attachment-definitions.k8s.cni.cncf.io
per verificare se il fileNetworkAttachmentDefinitions
è 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 valoreNetworkAttachmentDefinition
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 valoreNetworkAttachmentDefinition
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 valoreNetworkAttachmentDefinition
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 valoreNetworkAttachmentDefinition
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 ~]$
- Assegnare un'etichetta al nodo di lavoro 1 utilizzando il comando
-
L'immagine seguente mostra una panoramica visiva di ciò che abbiamo configurato finora.
-
Creare un file YAML per
testpod1
utilizzando il comandosudo nano testpod1-v2.yaml
.-
Si noti la sezione
annotations
in cui è possibile associare il fileNetworkAttachmentDefinition
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'etichettatestpod1
.
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 comandosudo nano testpod2-v2.yaml
.-
Si noti la sezione
annotations
in cui è possibile associare il fileNetworkAttachmentDefinition
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'etichettatestpod2
.
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 comandosudo nano testpod3-v2.yaml
.-
Si noti la sezione
annotations
in cui è possibile associare il fileNetworkAttachmentDefinition
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'etichettatestpod3
.
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 comandosudo nano testpod4-v2.yaml
.-
Si noti la sezione
annotations
in cui è possibile associare il fileNetworkAttachmentDefinition
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'etichettatestpod4
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 comandokubectl apply -f testpod1-v2.yaml
. - Creare
testpod2
applicando il file YAML utilizzando il comandokubectl apply -f testpod2-v2.yaml
. - Creare
testpod3
applicando il file YAML utilizzando il comandokubectl apply -f testpod3-v2.yaml
. - Creare
testpod4
applicando il file YAML utilizzando il comandokubectl 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 loRunning
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 lavoro10.0.112.134
con l'etichettatestpod1
utilizzando il comandokubectl 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 lavoro10.0.66.97
con l'etichettatestpod2
utilizzando il comandokubectl 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 lavoro10.0.73.242
con l'etichettatestpod3
utilizzando il comandokubectl 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 lavoro10.0.89.50
con l'etichettatestpod4
utilizzando il comandokubectl 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 podnet1
utilizzando il comandokubectl 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 podnet1
utilizzando il comandokubectl 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 podnet1
utilizzando il comandokubectl 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 podnet1
utilizzando il comandokubectl 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'interfacciaens5
sui nodi di lavoro. Questo indirizzo IP viene spostato dall'interfaccia del nodo di lavoroens5
all'interfaccia del pod di testnet1
. -
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 pertestpod1
.Si noti che la tabella di routing di
testpod1
ha un gateway predefinito pereth0
e pernet1
, 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 pertestpod2
.Si noti che la tabella di routing di
testpod2
ha un gateway predefinito pereth0
e pernet1
, 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 pertestpod3
.Si noti che la tabella di routing di
testpod3
ha un gateway predefinito pereth0
e pernet1
, 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 pertestpod4
.Si noti che la tabella di routing di
testpod4
ha un gateway predefinito pereth0
e pernet1
, 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 testnet1
indirizzi IP.
-
Eseguire il comando
kubectl exec -it testpod1 -- ping -I net1 10.0.3.30 -c 4
per eseguire il ping datestpod1
atestpod1
.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 datestpod1
atestpod2
.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 datestpod1
atestpod3
.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 datestpod1
atestpod4
.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 interfacciaens6
con un indirizzo IP10.0.4.29/27
sulla rete10.0.4.0/27
.Si noti che questo è un altro
NetworkAttachmentDefinition
rispetto a prima per l'interfacciaens5
con un indirizzo IP10.0.3.30/27
sulla rete10.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 fileNetworkAttachmentDefinition
;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 comandokubectl 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
Collegamenti correlati
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.
Deploy SR-IOV Enabled Network Interfaces Container Apps on OKE Using Multus CNI Plugin
G28057-02
Copyright ©2025, Oracle and/or its affiliates.