Questo documento descrive come configurare la virtualizzazione di input/output single-root (SR-IOV) per Google Distributed Cloud. SR-IOV offre la virtualizzazione I/O rendere una scheda di interfaccia di rete (NIC), disponibile come dispositivi di rete in Linux in un kernel. Questo ti consente di gestire e assegnare le connessioni di rete ai pod. Le prestazioni vengono migliorate man mano che i pacchetti vengono spostati 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 Google Distributed Cloud ti consente di configurare le funzioni virtuali (VF) sul dei dispositivi supportati dai nodi del cluster. Puoi anche specificare per l'associazione alle VF.
Questa funzionalità è disponibile per i cluster che eseguono carichi di lavoro, ibrido, standalone, e di cluster utente. La funzionalità di networking SR-IOV richiede che il cluster abbia almeno due nodi.
La procedura di configurazione prevede i seguenti passaggi di alto livello:
- 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
NetworkAttachmentDefinitionpersonalizzata che fa riferimento a VF.
Requisiti
La funzionalità di networking SR-IOV richiede i driver ufficiali della rete
ai nodi del cluster. Installa i driver prima di utilizzare
l'operatore SR-IOV. Inoltre, per usare il modulo vfio-pci per i VF, assicurati
per rendere il modulo disponibile
sui nodi in cui deve essere usato.
Abilita il networking SR-IOV per un cluster
Per abilitare il networking SR-IOV per Google Distributed Cloud, aggiungi il
multipleNetworkInterfaces
e il
sriovOperator
alla sezione clusterNetwork dell'oggetto Cluster e imposta entrambi i campi
a 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
Funzionalità di networking SR-IOV. Questa risorsa personalizzata in bundle ha il nome default
e si trova nello spazio dei nomi gke-operators. La personalizzazione 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 risorsa personalizzata di 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 di SR-IOV
che l'operatore di rete può gestire. Nell'esempio precedente, l'operatore è limitato solo a
nodi con un'etichetta nodePool: withSriov. Se configDaemonNodeSelector
non viene 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 lo svuotamento dei nodi Kubernetes
prima che sia necessario riavviare il nodo o che venga eseguito prima di un VF specifico
viene modificata.
Crea criteri SR-IOV
Per configurare VF specifiche nel cluster, devi creare un
SriovNetworkNodePolicy risorsa personalizzata nello spazio dei nomi gke-operators.
Di seguito è riportato un file 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 ti consente di limitare ulteriormente i nodi su cui le VF
che è necessario creare. Questo limite si aggiunge ai selettori della
SriovOperatorConfig descritto nella sezione precedente.
Il campo deviceType specifica il modulo kernel da utilizzare per le VF. Disponibile
le opzioni per deviceType sono:
netdeviceper modulo kernel standard specifico per VFvfio-pciper il driver VFIO-PCI
L'resourceName definisce il nome con cui sono rappresentati i VF
nodo Kubernetes.
Al termine del processo di configurazione, i nodi cluster selezionati
contengono la risorsa definita come presentato nell'esempio che segue (nota come
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 definita
con SriovNetworkNodePolicy.
Specifica un selettore NIC
Affinché SriovNetworkNodePolicy funzioni correttamente, specifica almeno uno
selettore nella sezione nicSelector. Questo campo contiene più opzioni
come identificare funzioni fisiche specifiche (PF) nei nodi del cluster. La maggior parte di
vengono rilevate automaticamente le informazioni richieste da questo campo e salvate nel
SriovNetworkNodeState risorsa personalizzata. Ci sarà un oggetto per ogni nodo
gestibili da questo operatore.
Usa 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. Nella
oltre a definire il PF esatto da utilizzare, ti consente di specificare i VF esatti da
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 numerati da 3 a 6
e mostra solo quattro VF disponibili. Poiché i VF vengono sempre creati
zero, il numero di VF richiesti, numVfs, deve essere almeno pari
come 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 5.
Se il partizionamento non è specificato, numVfs definisce l'intervallo VF che
, che inizia sempre da zero. Ad esempio, se imposti numVfs=3
senza specificare il partizionamento, vengono utilizzati i VF 0-2.
Informazioni sulla priorità delle norme
Puoi specificare più oggetti SriovNetworkNodePolicy per gestire vari
o configurazioni VF diverse. Gestione di più oggetti e fornitori
potrebbe diventare problematico quando più criteri fanno riferimento allo stesso PF. Per gestire
situazioni di questo tipo, il campo priority risolve i conflitti su base per nodo.
Ecco la logica di assegnazione delle priorità per i criteri PF sovrapposti:
Un criterio con priorità più alta sostituisce uno con priorità più bassa soltanto se Il partizionamento PF si sovrappone.
I criteri con la stessa priorità vengono uniti:
- I criteri vengono 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
Un criterio con priorità elevata è quello con un valore numerico più basso in priority
. Ad esempio, la priorità è più alta per un criterio con priority: 10,
che per un criterio con priority: 20.
Le sezioni seguenti forniscono esempi di criteri per diverse partizioni configurazioni.
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 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 seguenti due manifest SriovNetworkNodePolicy comporta solo
la risorsa gke.io/dev-vfio è disponibile. L'intervallo VF policy-1 è
0-2, che si sovrappone a policy-2. A causa della denominazione, policy-2 viene elaborato
dopo il giorno policy-1. Di conseguenza, solo la risorsa specificata in policy-2,
gke.io/dev-vfio è disponibile.
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 che non si sovrappongono. Anche se policy-1 ha una priorità più alta
rispetto a policy-2, poiché il partizionamento PF non è sovrapposto, uniamo i due
criteri.
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 della configurazione dei criteri SR-IOV
Quando applichi i criteri SR-IOV, puoi monitorare e visualizzare quello finale
dei nodi nella risorsa personalizzata SriovNetworkNodeState
del nodo specifico. Nella sezione status, il campo syncStatus rappresenta
la fase attuale per il daemon di configurazione. Lo stato Succeeded indica
la configurazione è terminata. La sezione spec dell'
SriovNetworkNodeState risorsa personalizzata definisce lo stato finale delle VF
configurazione per quel nodo, in base al numero di criteri e
le priorità. Tutti i VF creati verranno elencati nella sezione status per
PF specificati.
Ecco un esempio di risorsa personalizzata di 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 NetworkAttachmentDefinition personalizzata
Dopo aver configurato correttamente le VF sul cluster, che saranno visibili
nodo Kubernetes come risorsa, devi creare
NetworkAttachmentDefinition che fa riferimento alla risorsa. Crea il riferimento
con un'annotazione k8s.v1.cni.cncf.io/resourceName.
Ecco un esempio di manifest NetworkAttachmentDefinition che fa riferimento
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 di cui è stato eseguito il deployment NetworkAttachmentDefinition nel tuo
con un'annotazione k8s.v1.cni.cncf.io/networks.
Ecco un esempio di come fare riferimento alla precedente
NetworkAttachmentDefinition risorsa personalizzata 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 della configurazione le definizioni delle risorse o il posizionamento
per 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 sezioni seguenti contengono informazioni per aiutarti a configurare SR-IOV networking.
Riavvii dei nodi
Quando l'operatore SR-IOV configura i nodi, questi potrebbero dover essere è stato riavviato. Durante la configurazione di VF o del kernel potrebbe essere necessario riavviare i nodi. La la configurazione del kernel prevede il supporto della funzionalità SR-IOV in tipo e quantità di spazio di archiviazione necessari e sistema operativo.
Adattatori di rete supportati
Nella tabella seguente sono elencati gli adattatori di rete supportati per la versione Cluster 1.29.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 ghiaccio Columbiaville E810-CQDA2 2CQDA2 | 8086 | 1592 | 1889 |
| Intel ghiaccio Columbiaville E810-XXVDA4 | 8086 | 1593 | 1889 |
| Intel ghiaccio Columbiaville E810-XXVDA2 | 8086 | 159b | 1889 |
| Nvidia MLX5 ConnectX-4 | 15b3 | 1013 | 1014 |
| Nvidia MLX 5 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 g | 101e |
| Nvidia MLX5 MT42822 BlueField-2 integrato ConnectX-6 Dx | 15b3 | a2d6 | 101e |
| Broadcom bnxt BCM57414 2x25G | 14e4 | 16 g 7 | 16dc |
| Broadcom bnxt BCM75508 2x100G | 14e4 | 1750 | 1806 |