Questo documento descrive come configurare il networking con virtualizzazione di input/output a radice singola (SR-IOV) per Google Distributed Cloud. SR-IOV fornisce la virtualizzazione I/O per rendere una scheda di interfaccia di rete (NIC) disponibile come dispositivi di rete nel kernel Linux. In questo modo potrai gestire e assegnare le connessioni di rete ai tuoi pod. Le prestazioni migliorano perché i pacchetti si spostano direttamente tra la NIC e il pod.
Utilizza questa funzionalità se hai bisogno di una rete veloce per i carichi di lavoro dei pod. SR-IOV per Google Distributed Cloud ti consente di configurare le funzioni virtuali (VF) sui dispositivi supportati dei nodi del cluster. Puoi anche specificare il modulo del kernel specifico a cui associare le funzioni virtuali.
Questa funzionalità è disponibile per i cluster che eseguono workload, come i cluster ibridi, autonomi e utente. La funzionalità di rete SR-IOV richiede che il cluster abbia almeno due nodi.
La procedura di configurazione è costituita dai seguenti passaggi di alto livello:
- Configura il cluster per abilitare il networking SR-IOV.
- Configura l'operatore SR-IOV, una risorsa personalizzata
SriovOperatorConfig. - Configura i criteri SR-IOV e le VF.
- Crea una risorsa personalizzata
NetworkAttachmentDefinitionche fa riferimento ai tuoi VF.
Requisiti
La funzionalità di rete SR-IOV richiede la presenza dei driver ufficiali per le schede di rete sui nodi del cluster. Installa i driver prima di utilizzare
l'operatore SR-IOV. Inoltre, per utilizzare il modulo vfio-pci per le VF, assicurati
che il modulo sia disponibile sui nodi in cui deve essere utilizzato.
Abilitare il networking SR-IOV per un cluster
Per abilitare il networking SR-IOV per Google Distributed Cloud, aggiungi il campo
multipleNetworkInterfaces
e il campo
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.
Configura l'operatore SR-IOV
La risorsa personalizzata SriovOperatorConfig fornisce la configurazione globale per la funzionalità di rete 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 defaultEcco un esempio di configurazione di una risorsa personalizzata 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 ti 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 specifica se eseguire un'operazione di svuotamento dei nodi Kubernetes
prima che il nodo debba essere riavviato o prima che venga modificata una specifica configurazione VF.
Crea policy SR-IOV
Per configurare VF specifiche nel cluster, devi creare una risorsa personalizzata SriovNetworkNodePolicy nello spazio dei nomi gke-operators.
Ecco un esempio di manifest 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 aggiunge ai selettori di
SriovOperatorConfig descritti nella sezione precedente.
Il campo deviceType specifica il modulo del kernel da utilizzare per le VF. Le opzioni disponibili per deviceType sono:
netdeviceper il modulo kernel standard specifico per VFvfio-pciper il driver VFIO-PCI
resourceName definisce il nome con cui le VF sono rappresentate nel nodo Kubernetes.
Al termine della procedura di configurazione, i nodi del cluster selezionati
contengono la risorsa definita, come mostrato nell'esempio seguente (nota il
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 (PF) specifiche nei nodi del cluster. La maggior parte delle informazioni richieste da questo campo viene rilevata automaticamente e salvata nella risorsa personalizzata SriovNetworkNodeState. Ci sarà un oggetto per ogni nodo
che questo operatore può gestire.
Utilizza questo comando per visualizzare tutti i nodi disponibili:
kubectl -n gke-operators get sriovnetworknodestates.sriovnetwork.k8s.cni.cncf.io -o yamlEcco 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
Impostare il partizionamento della funzione fisica
Presta particolare attenzione al campo pfNames della sezione nicSelector. Oltre a definire la PF esatta da utilizzare, consente di specificare le VF esatte da utilizzare per la PF specificata 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 i VF numerati da 3 a 6
e mostra solo quattro VF disponibili. Poiché i VF vengono sempre creati dall'indice zero, il numero di VF richiesto, numVfs, deve essere almeno pari al valore di chiusura dell'intervallo (a partire 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 tuo numVfs deve essere almeno 5.
Quando il partizionamento non è specificato, numVfs definisce l'intervallo di VF utilizzato, che inizia sempre da zero. Ad esempio, se imposti numVfs=3
senza specificare il partizionamento, vengono utilizzati i VF 0-2.
Informazioni sulla priorità dei criteri
Puoi specificare più oggetti SriovNetworkNodePolicy per gestire vari fornitori o diverse configurazioni di VF. La gestione di più oggetti e fornitori
potrebbe diventare problematica quando più criteri fanno riferimento alla stessa PF. Per gestire
queste situazioni, il campo priority risolve i conflitti in base al nodo.
Ecco la logica di assegnazione della priorità per le norme PF sovrapposte:
Una policy con priorità più elevata sovrascrive una con priorità inferiore solo quando il partizionamento PF è sovrapposto.
Le norme con la stessa priorità vengono unite:
- I criteri sono ordinati per nome ed elaborati in questo ordine
- I criteri con partizionamento PF sovrapposto vengono sovrascritti
- I criteri con partizionamento PF non sovrapposto vengono uniti e tutti presenti
Una policy con priorità elevata è quella con un valore numerico inferiore nel campo priority. Ad esempio, la priorità è maggiore per una policy con priority: 10 rispetto a una policy con priority: 20.
Le seguenti sezioni forniscono esempi di norme per diverse configurazioni di partizionamento.
PF partizionato
Il deployment dei seguenti due manifest SriovNetworkNodePolicy genera due risorse disponibili: gke.io/dev-kernel e gke.io/dev-vfio. Ogni risorsa
ha due VF che non si sovrappongono.
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 comporta la disponibilità
della sola risorsa gke.io/dev-vfio. L'intervallo VF policy-1 è
0-2, che si sovrappone a policy-2. A causa della denominazione, policy-2 viene elaborato
dopo 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 seguenti due manifest SriovNetworkNodePolicy genera due risorse disponibili: gke.io/dev-kernel e gke.io/dev-vfio. Ogni risorsa
ha due VF che non si sovrappongono. Anche se policy-1 ha una priorità maggiore
rispetto a policy-2, poiché il partizionamento PF non si sovrappone, uniamo le due
norme.
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"
Controllare lo stato di configurazione delle norme 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 quel nodo, in base al numero di criteri e alle relative priorità. Tutti i VF creati verranno elencati 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 averle rese visibili nel nodo Kubernetes come risorsa, devi creare un NetworkAttachmentDefinition che faccia riferimento alla risorsa. Crea il riferimento
con un'annotazione k8s.v1.cni.cncf.io/resourceName.
Ecco un esempio di file 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 di CNI.
Fai riferimento a qualsiasi risorsa personalizzata NetworkAttachmentDefinition di cui è stato eseguito il deployment nei tuoi
pod con un'annotazione k8s.v1.cni.cncf.io/networks.
Ecco un esempio di come fare riferimento alla risorsa personalizzata
NetworkAttachmentDefinition precedente 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 personalizzata NetworkAttachmentDefinition nei carichi di lavoro,
non devi preoccuparti delle definizioni delle risorse dei pod o del posizionamento in
nodi specifici, perché questa operazione 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 sezioni seguenti contengono informazioni utili per configurare il networking SR-IOV.
Riavvii del nodo
Quando l'operatore SR-IOV configura i nodi, potrebbe essere necessario riavviarli. Il riavvio dei nodi potrebbe essere necessario durante la configurazione di VF o del kernel. La configurazione del kernel prevede l'abilitazione del supporto della funzionalità SR-IOV nel sistema operativo.
Adattatori di rete supportati
La tabella seguente elenca gli adattatori di rete supportati per i cluster della versione 1.33.x:
| Nome | ID fornitore | ID dispositivo | ID dispositivo VF |
|---|---|---|---|
| Intel i40e XXV710 | 8086 | 158a | 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 ice Columbiaville E810-CQDA2 2CQDA2 | 8086 | 1592 | 1889 |
| Intel ice Columbiaville E810-XXVDA4 | 8086 | 1593 | 1889 |
| Intel ice Columbiaville E810-XXVDA2 | 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 | 101a |
| Nvidia mlx5 ConnectX-6 | 15b3 | 101b | 101c |
| Nvidia mlx5 ConnectX-6_Dx | 15b3 | 101 giorni | 101e |
| Nvidia mlx5 MT42822 BlueField-2 ConnectX-6 Dx integrato | 15b3 | a2d6 | 101e |
| Broadcom bnxt BCM57414 2x25G | 14e4 | 16d7 | 16dc |
| Broadcom bnxt BCM75508 2x100G | 14e4 | 1750 | 1806 |