Questo documento descrive come configurare una rete di virtualizzazione di I/O (SR-IOV) a radice singola per GDCV per Bare Metal. SR-IOV fornisce la virtualizzazione I/O per rendere disponibile una scheda di interfaccia di rete (NIC) come dispositivi di rete nel kernel Linux. Questo ti consente di gestire e assegnare le connessioni di rete ai tuoi pod. Le prestazioni sono migliorate poiché i pacchetti si spostano direttamente tra il NIC e il pod.
Utilizza questa funzionalità se hai bisogno di un networking veloce per i carichi di lavoro dei pod. SR-IOV per GDCV per Bare Metal consente di configurare le funzioni virtuali (VF) sui dispositivi supportati dei nodi del cluster. Puoi anche specificare un particolare modulo del kernel da associare alle VF.
Questa funzionalità è disponibile per i cluster che eseguono carichi di lavoro, ad esempio i cluster ibridi, autonomo e utente. La funzionalità di networking SR-IOV richiede che il cluster abbia almeno due nodi.
La procedura di configurazione prevede i seguenti passaggi generali:
- Configura il cluster per abilitare il networking SR-IOV.
- Configura l'operatore SR-IOV, una risorsa personalizzata
SriovOperatorConfig
. - Imposta i criteri SR-IOV e configura le VF.
- Crea una risorsa personalizzata
NetworkAttachmentDefinition
che faccia riferimento alle tue VF.
Requisiti
La funzionalità di networking SR-IOV richiede la presenza dei driver ufficiali per la presenza degli adattatori di rete sui nodi del cluster. Installa i driver prima di
utilizzare l'operatore SR-IOV. Inoltre, al fine di utilizzare il modulo vfio-pci
per le VF, assicurati che il modulo sia disponibile sui nodi in cui deve essere utilizzato.
Abilita il networking SR-IOV per un cluster
Per abilitare il networking SR-IOV per GKE su Bare Metal, aggiungi i campi multipleNetworkInterfaces
e sriovOperator
alla sezione clusterNetwork
dell'oggetto Cluster e imposta entrambi i campi su true
.
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: cluster1
spec:
clusterNetwork:
multipleNetworkInterfaces: true
sriovOperator: true
...
Il campo sriovOperator
è modificabile e può essere modificato dopo la creazione del cluster.
Configurare l'operatore SR-IOV
La risorsa personalizzata SriovOperatorConfig
fornisce la configurazione globale per la funzionalità di networking SR-IOV. Questa risorsa personalizzata in bundle ha il nome default
e si trova nello spazio dei nomi gke-operators
. La risorsa personalizzata SriovOperatorConfig
viene rispettata solo per questo nome e spazio dei nomi.
Puoi modificare questo oggetto con il seguente comando:
kubectl -n gke-operators edit sriovoperatorconfigs.sriovnetwork.k8s.cni.cncf.io default
Ecco un esempio di configurazione di risorse personalizzate SriovOperatorConfig
:
apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
kind: SriovOperatorConfig
metadata:
name: default
namespace: gke-operators
spec:
configDaemonNodeSelector:
nodePool: "withSriov"
disableDrain: false
logLevel: 0
La sezione configDaemonNodeSelector
consente di limitare i nodi che l'operatore SR-IOV può gestire. Nell'esempio precedente, l'operatore è limitato solo ai nodi con un'etichetta nodePool: withSriov
. Se il campo configDaemonNodeSelector
non è specificato, vengono applicate le seguenti etichette predefinite:
beta.kubernetes.io/os: linux
node-role.kubernetes.io/worker: ""
Il campo disableDrain
consente di specificare se eseguire un'operazione di svuotamento dei nodi Kubernetes prima che sia necessario riavviare il nodo o prima di modificare una configurazione VF specifica.
Crea criteri SR-IOV
Per configurare VF specifiche nel tuo cluster, devi creare una risorsa personalizzata SriovNetworkNodePolicy
nello spazio dei nomi gke-operators
.
Ecco un manifest di esempio per una risorsa personalizzata SriovNetworkNodePolicy
:
apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
kind: SriovNetworkNodePolicy
metadata:
name: policy-1
namespace: gke-operators
spec:
deviceType: "netdevice"
mtu: 1600
nodeSelector:
baremetal.cluster.gke.io/node-pool: node-pool-1
nicSelector:
pfNames:
- enp65s0f0
deviceID: "1015"
rootDevices:
- 0000:01:00.0
vendor: "15b3"
numVfs: 4
priority: 80
resourceName: "mlnx"
La sezione nodeSelector
consente di limitare ulteriormente i nodi su cui devono essere create le VF. Questa limitazione si trova in cima ai selettori dell'elemento
SriovOperatorConfig
descritto nella sezione precedente.
Il campo deviceType
specifica il modulo kernel da utilizzare per le VF. Le opzioni
disponibili per deviceType
sono:
netdevice
per il modulo kernel standard specifico per VFvfio-pci
per il driver VFIO-PCI
resourceName
definisce il nome rappresentato dalle VF nel
nodo Kubernetes.
Al termine del processo di configurazione, i nodi del cluster selezionati contengono la risorsa definita, come presentato nell'esempio seguente (nota: gke.io/mlnx
:
apiVersion: v1
kind: Node
metadata:
name: worker-01
spec:
…
status:
allocatable:
cpu: 47410m
ephemeral-storage: "210725550141"
gke.io/mlnx: "4"
hugepages-1Gi: "0"
hugepages-2Mi: "0"
memory: 59884492Ki
pods: "250"
capacity:
cpu: "48"
ephemeral-storage: 228651856Ki
gke.io/mlnx: "4"
hugepages-1Gi: "0"
hugepages-2Mi: "0"
memory: 65516492Ki
pods: "250"
L'operatore aggiungerà sempre il prefisso gke.io/
a ogni risorsa che definisci con SriovNetworkNodePolicy
.
Specifica un selettore NIC
Affinché SriovNetworkNodePolicy
funzioni correttamente, specifica almeno un
selettore nella sezione nicSelector
. Questo campo contiene più opzioni su come identificare funzioni fisiche specifiche (PF) nei nodi del cluster. La maggior parte delle informazioni richieste in questo campo viene rilevata automaticamente e salvata nella risorsa personalizzata SriovNetworkNodeState
. Ci sarà un oggetto per ogni nodo
che questo operatore può gestire.
Utilizza il seguente comando per visualizzare tutti i nodi disponibili:
kubectl -n gke-operators get sriovnetworknodestates.sriovnetwork.k8s.cni.cncf.io -o yaml
Ecco un esempio di nodo:
apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
kind: SriovNetworkNodeState
metadata:
name: worker-01
namespace: gke-operators
spec:
dpConfigVersion: "6368949"
status:
interfaces:
- deviceID: "1015"
driver: mlx5_core
eSwitchMode: legacy
linkSpeed: 10000 Mb/s
linkType: ETH
mac: 1c:34:da:5c:2b:9c
mtu: 1500
name: enp1s0f0
pciAddress: "0000:01:00.0"
totalvfs: 4
vendor: 15b3
- deviceID: "1015"
driver: mlx5_core
linkSpeed: 10000 Mb/s
linkType: ETH
mac: 1c:34:da:5c:2b:9d
mtu: 1500
name: enp1s0f1
pciAddress: "0000:01:00.1"
totalvfs: 2
vendor: 15b3
syncStatus: Succeeded
Imposta il partizionamento delle funzioni fisiche
Presta particolare attenzione al campo pfNames
della sezione nicSelector
. Oltre a definire il PF esatto da utilizzare, consente di specificare le VF esatte da utilizzare per il PF specificato e la risorsa definita nel criterio.
Ecco un esempio:
apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
kind: SriovNetworkNodePolicy
metadata:
name: policy-1
namespace: gke-operators
spec:
deviceType: "netdevice"
mtu: 1600
nodeSelector:
baremetal.cluster.gke.io/node-pool: node-pool-1
nicSelector:
pfNames:
- enp65s0f0#3-6
deviceID: "1015"
rootDevices:
- 0000:01:00.0
vendor: "15b3"
numVfs: 7
priority: 80
resourceName: "mlnx"
Nell'esempio precedente, la risorsa gke.io/mlnx
utilizza solo VF numerate da 3 a 6 e mostra solo quattro VF disponibili. Poiché le VF vengono sempre create dall'indice zero, il numero di VF richiesto, numVfs
, deve essere almeno uguale al valore di chiusura dell'intervallo (contando da zero). Questa logica di numerazione è il motivo per cui numVfs
è impostato su 7
nell'esempio precedente. Se imposti un intervallo da 3 a 4
(enp65s0f0#3-4
), il valore di numVfs
deve essere almeno pari a 5
.
Quando il partizionamento non è specificato, numVfs
definisce l'intervallo di VF in uso, che parte sempre da zero. Ad esempio, se imposti numVfs=3
senza specificare il partizionamento, vengono utilizzate le VF 0-2
.
Informazioni sulla priorità dei criteri
Puoi specificare più oggetti SriovNetworkNodePolicy
per gestire vari
fornitori o configurazioni di VF diverse. La gestione di più oggetti e fornitori
potrebbe diventare problematica quando più criteri fanno riferimento allo stesso PF. Per gestire
queste situazioni, il campo priority
risolve i conflitti per nodo.
Ecco la logica di priorità per i criteri PF sovrapposti:
Un criterio con priorità più alta sovrascrive uno con priorità inferiore solo quando il partizionamento PF si sovrappone.
Vengono uniti i criteri con le stesse priorità:
- I criteri vengono ordinati per nome ed elaborati in quell'ordine
- I criteri con partizionamento PF sovrapposto vengono sovrascritti
- I criteri con partizionamento PF non sovrapposto vengono uniti e tutti presenti
Un criterio ad alta priorità è un criterio con un valore numerico più basso nel campo priority
. Ad esempio, la priorità è più elevata per un criterio con priority: 10
,
rispetto a un criterio con priority: 20
.
Le seguenti sezioni forniscono esempi di criteri per diverse configurazioni di partizionamento.
PF partizionato
Il deployment dei due manifest SriovNetworkNodePolicy
seguenti genera due
risorse disponibili: gke.io/dev-kernel
e gke.io/dev-vfio
. Ogni risorsa ha due VF non sovrapposte.
kind: SriovNetworkNodePolicy
metadata:
name: policy-1
spec:
deviceType: "netdevice"
nodeSelector:
baremetal.cluster.gke.io/node-pool: node-pool-1
nicSelector:
pfNames:
- enp65s0f0#0-1
numVfs: 2
priority: 70
resourceName: "dev-kernel"
kind: SriovNetworkNodePolicy
metadata:
name: policy-2
spec:
deviceType: "vfio-pci"
nodeSelector:
baremetal.cluster.gke.io/node-pool: node-pool-1
nicSelector:
pfNames:
- enp65s0f0#2-3
numVfs: 4
priority: 70
resourceName: "dev-vfio"
Partizionamento PF sovrapposto
Il deployment dei due manifest SriovNetworkNodePolicy
seguenti rende disponibile solo la risorsa gke.io/dev-vfio
. L'intervallo di VF policy-1
è 0-2
, che si sovrappone a policy-2
. A causa della denominazione, policy-2
viene elaborato dopo il giorno policy-1
. Pertanto, è disponibile solo la risorsa specificata in policy-2
,
gke.io/dev-vfio
.
kind: SriovNetworkNodePolicy
metadata:
name: policy-1
spec:
deviceType: "netdevice"
nodeSelector:
baremetal.cluster.gke.io/node-pool: node-pool-1
nicSelector:
pfNames:
- enp65s0f0
numVfs: 3
priority: 70
resourceName: "dev-kernel"
kind: SriovNetworkNodePolicy
metadata:
name: policy-2
spec:
deviceType: "vfio-pci"
nodeSelector:
baremetal.cluster.gke.io/node-pool: node-pool-1
nicSelector:
pfNames:
- enp65s0f0#2-3
numVfs: 4
priority: 70
resourceName: "dev-vfio"
Partizionamento PF non sovrapposto con priorità diverse
Il deployment dei due manifest SriovNetworkNodePolicy
seguenti genera due
risorse disponibili: gke.io/dev-kernel
e gke.io/dev-vfio
. Ogni risorsa ha due VF non sovrapposte. Anche se policy-1
ha una priorità più alta di policy-2
, poiché il partizionamento PF non è sovrapposto, i due criteri vengono uniti.
kind: SriovNetworkNodePolicy
metadata:
name: policy-1
spec:
deviceType: "netdevice"
nodeSelector:
baremetal.cluster.gke.io/node-pool: node-pool-1
nicSelector:
pfNames:
- enp65s0f0
numVfs: 2
priority: 10
resourceName: "dev-kernel"
kind: SriovNetworkNodePolicy
metadata:
name: policy-2
spec:
deviceType: "vfio-pci"
nodeSelector:
baremetal.cluster.gke.io/node-pool: node-pool-1
nicSelector:
pfNames:
- enp65s0f0#2-3
numVfs: 4
priority: 70
resourceName: "dev-vfio"
Controlla lo stato di configurazione dei criteri SR-IOV
Quando applichi i criteri SR-IOV, puoi monitorare e visualizzare la configurazione finale dei nodi nella risorsa personalizzata SriovNetworkNodeState
per il nodo specifico. Nella sezione status
, il campo syncStatus
rappresenta la fase attuale del daemon di configurazione. Lo stato Succeeded
indica
che la configurazione è terminata. La sezione spec
della risorsa personalizzata SriovNetworkNodeState
definisce lo stato finale della configurazione delle VF per il nodo in questione, in base al numero di criteri e alle loro priorità. Tutte le VF create saranno elencate nella sezione status
per i PF specificati.
Ecco un esempio di risorsa personalizzata SriovNetworkNodeState
:
apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
kind: SriovNetworkNodeState
metadata:
name: worker-02
namespace: gke-operators
spec:
dpConfigVersion: "9022068"
interfaces:
- linkType: eth
name: enp1s0f0
numVfs: 2
pciAddress: "0000:01:00.0"
vfGroups:
- deviceType: netdevice
policyName: policy-1
resourceName: mlnx
vfRange: 0-1
status:
interfaces:
- Vfs:
- deviceID: "1016"
driver: mlx5_core
mac: 96:8b:39:d8:89:d2
mtu: 1500
name: enp1s0f0np0v0
pciAddress: "0000:01:00.2"
vendor: 15b3
vfID: 0
- deviceID: "1016"
driver: mlx5_core
mac: 82:8e:65:fe:9b:cb
mtu: 1500
name: enp1s0f0np0v1
pciAddress: "0000:01:00.3"
vendor: 15b3
vfID: 1
deviceID: "1015"
driver: mlx5_core
eSwitchMode: legacy
linkSpeed: 10000 Mb/s
linkType: ETH
mac: 1c:34:da:5c:2b:9c
mtu: 1500
name: enp1s0f0
numVfs: 2
pciAddress: "0000:01:00.0"
totalvfs: 2
vendor: 15b3
- deviceID: "1015"
driver: mlx5_core
linkSpeed: 10000 Mb/s
linkType: ETH
mac: 1c:34:da:5c:2b:9d
mtu: 1500
name: enp1s0f1
pciAddress: "0000:01:00.1"
totalvfs: 2
vendor: 15b3
syncStatus: Succeeded
Crea una risorsa personalizzata NetworkAttachmentDefinition
Dopo aver configurato correttamente le VF sul cluster e che sono visibili nel nodo Kubernetes come risorsa, devi creare un elemento NetworkAttachmentDefinition
che faccia riferimento alla risorsa. Inserisci il riferimento
con un'annotazione k8s.v1.cni.cncf.io/resourceName
.
Ecco un esempio di manifest NetworkAttachmentDefinition
che fa riferimento alla risorsa gke.io/mlnx
:
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: gke-sriov-1
annotations:
k8s.v1.cni.cncf.io/resourceName: gke.io/mlnx
spec:
config: '{
"cniVersion": "0.3.0",
"name": "mynetwork",
"type": "sriov",
"ipam": {
"type": "whereabouts",
"range": "21.0.108.0/21",
"range_start": "21.0.111.16",
"range_end": "21.0.111.18"
}
}'
NetworkAttachmentDefinition
deve avere sriov
come tipo CNI.
Fai riferimento a qualsiasi risorsa personalizzata NetworkAttachmentDefinition
di cui hai eseguito il deployment nei tuoi pod con un'annotazione k8s.v1.cni.cncf.io/networks
.
Ecco un esempio di come fare riferimento alla precedente risorsa personalizzata NetworkAttachmentDefinition
in un pod:
apiVersion: v1
kind: Pod
metadata:
name: samplepod
annotations:
k8s.v1.cni.cncf.io/networks: gke-sriov-1
spec:
containers:
...
Quando fai riferimento a una risorsa NetworkAttachmentDefinition
personalizzata nei carichi di lavoro, non devi preoccuparti delle definizioni delle risorse dei pod o del posizionamento in nodi specifici, operazione che viene eseguita automaticamente.
L'esempio seguente mostra una risorsa personalizzata NetworkAttachmentDefinition
con
una configurazione VLAN. In questo esempio, ogni VF appartiene alla VLAN 100
:
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: gke-sriov-vlan-100
annotations:
k8s.v1.cni.cncf.io/resourceName: gke.io/mlnx
spec:
config: '{
"cniVersion": "0.3.0",
"name": "mynetwork",
"type": "sriov",
"vlan": 100,
"ipam": {
"type": "whereabouts",
"range": "21.0.100.0/21"
}
}'
Informazioni aggiuntive
Le seguenti sezioni contengono informazioni che consentono di configurare il networking SR-IOV.
Riavvii dei nodi
Quando l'operatore SR-IOV configura i nodi, questi potrebbero dover essere riavviati. Durante la configurazione VF o del kernel potrebbe essere necessario riavviare i nodi. La configurazione del kernel prevede l'abilitazione del supporto della funzionalità SR-IOV nel sistema operativo.
Schede di rete supportate
Nella tabella seguente sono elencate le schede di rete supportate per i cluster della versione 1.16.x:
Nome | ID fornitore | ID dispositivo | ID dispositivo VF |
---|---|---|---|
Intel i40e XXV710 | 8086 | 158 | 154c |
Intel i40e 25G SFP28 | 8086 | 158b | 154c |
Intel i40e 10G X710 SFP | 8086 | 1572 | 154c |
Intel i40e XXV710 N3000 | 8086 | 0d58 | 154c |
Intel i40e 40G XL710 QSFP | 8086 | 1583 | 154c |
Intel ghiaccio Columbiaville E810-CQDA2 2CQDA2 | 8086 | 1592 | 1889 |
Intel Columbiaville E810-XXVDA4 di ghiaccio | 8086 | 1593 | 1889 |
Intel Columbiaville E810-XXVDA2 di ghiaccio | 8086 | 159b | 1889 |
Nvidia mlx5 ConnectX-4 | 15b3 | 1013 | 1014 |
Nvidia mlx5 ConnectX-4LX | 15b3 | 1015 | 1016 |
Nvidia mlx5 ConnectX-5 | 15b3 | 1017 | 1018 |
Nvidia mlx5 ConnectX-5 Ex | 15b3 | 1019 | 101 |
Nvidia mlx5 ConnectX-6 | 15b3 | 101b | 101c |
Nvidia mlx5 ConnectX-6_Dx | 15b3 | 101 giorni | Guida introduttiva |
Nvidia mlx5 MT42822 BlueField-2 integrato ConnectX-6 Dx | 15b3 | A2D6 | Guida introduttiva |
Broadcom bnxt BCM57414 2x25G | 14e4 | 16 giorni 7 | 16dc |
Broadcom bnxt BCM75508 2x100G | 14e4 | 1750 | 1806 |