Configurare il networking SR-IOV

Questo documento descrive come configurare il networking per la virtualizzazione di input/output con radice singola (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. In questo modo puoi gestire e assegnare le connessioni di rete ai tuoi pod. Le prestazioni migliorano man mano che i pacchetti passano direttamente tra la 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 il particolare modulo del kernel da associare 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 è costituita dai seguenti passaggi di alto livello:

  1. Configura il cluster per abilitare il networking SR-IOV.
  2. Configura l'operatore SR-IOV, una risorsa personalizzata SriovOperatorConfig.
  3. Configura i criteri SR-IOV e configura le VF.
  4. Crea una risorsa personalizzata NetworkAttachmentDefinition che faccia riferimento alle tue VM.

Requisiti

La funzionalità di rete SR-IOV richiede che i driver ufficiali per gli adattatori di rete siano presenti 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 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 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 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 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 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 configDaemonNodeSelector non viene 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 del nodo Kubernetes prima che il nodo debba essere riavviato o prima che venga modificata una configurazione VF specifica.

Creare criteri SR-IOV

Per configurare VF specifiche nel cluster, devi creare un SriovNetworkNodePolicy risorsa personalizzata 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 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 del kernel da utilizzare per le VF. Le opzioni disponibili per deviceType sono:

  • netdevice per modulo kernel standard specifico per VF
  • vfio-pci per 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 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 e salvata nella risorsa personalizzata SriovNetworkNodeState. Esiste 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

Impostare la partizione della funzione fisica

Presta particolare attenzione al campo pfNames della sezione nicSelector. Oltre a definire il PF esatto da utilizzare, consente di specificare i VF esatti 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 numerati da 3 a 6 e mostra solo quattro VF disponibili. Poiché le VF vengono sempre create dall'indice zero, il numero richiesto di VF, numVfs, deve essere almeno uguale al valore di chiusura dell'intervallo (contando da zero). È per questa logica di numerazione che numVfs è impostato su 7 nell'esempio precedente. Se imposti un intervallo da 3 a 4 (enp65s0f0#3-4), numVfs deve essere almeno 5.

Quando la suddivisione non è specificata, numVfs definisce l'intervallo di VF in uso, che inizia sempre da zero. Ad esempio, se imposti numVfs=3 senza specificare il partizionamento, vengono utilizzate le 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:

  1. Un criterio con priorità più alta sostituisce uno con priorità più bassa soltanto se Il partizionamento PF si sovrappone.

  2. I criteri con la stessa priorità vengono uniti:

    1. I criteri vengono ordinati per nome ed elaborati in questo ordine
    2. I criteri con partizionamento PF sovrapposto vengono sovrascritti
    3. I criteri con partizionamento PF non sovrapposto vengono uniti e tutti presenti

Un criterio con priorità elevata ha un valore numerico inferiore nel campo 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 seguenti due manifest SriovNetworkNodePolicy 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 comporta la disponibilità solo della 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 non sovrapposte. Anche se policy-1 ha una priorità più elevata rispetto a policy-2, poiché la suddivisione in partizioni del piano di fatturazione non si sovrappone, 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 la configurazione finale dei nodi nella risorsa personalizzata SriovNetworkNodeState per il nodo specifico. Nella sezione status, il campo syncStatus rappresenta la fase attuale per il daemon di configurazione. Lo stato Succeeded indica che la configurazione è stata completata. 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 i PP 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 personalizzata NetworkAttachmentDefinition

Dopo aver configurato correttamente le VF sul cluster e averle visualizzate nel nodo Kubernetes come risorsa, devi creare un 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 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 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 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, potrebbe essere necessario riavviarli. Potrebbe essere necessario riavviare i nodi durante la configurazione del VF o del kernel. 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

La tabella seguente elenca gli adattatori di rete supportati per i cluster della versione 1.30.x:

Nome ID fornitore ID dispositivo ID dispositivo VF
Intel i40e XXV710 8086 158a 154c
Intel i40e 25 G SFP28 8086 158b 154c
Intel i40e 10 G 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 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 integrato ConnectX-6 Dx 15b3 a2d6 101e
Broadcom bnxt BCM57414 2x25 G 14e4 16d7 16dc
Broadcom bnxt BCM75508 2x100G 14e4 1750 1806