Configurare il networking SR-IOV

Questo documento descrive come configurare il networking SR-IOV (Input/Output Virtualization) per i cluster Anthos su 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 permette di gestire e assegnare le connessioni di rete ai tuoi pod. Le prestazioni sono migliorate quando i pacchetti si spostano direttamente tra il NIC e il pod.

Usa questa funzionalità se hai bisogno di una rete veloce per i tuoi carichi di lavoro pod. SR-IOV per i cluster Anthos su Bare Metal consente di configurare le funzioni virtuali (VF) sui dispositivi supportati dei nodi del cluster. Puoi inoltre specificare il modulo del kernel da associare alle VF.

Questa funzionalità è disponibile per cluster che eseguono carichi di lavoro, come cluster ibridi, standalone e utente.

Il processo di configurazione è costituito dai seguenti passaggi generali:

  1. Configura il cluster per abilitare il networking SR-IOV.
  2. Configura l'operatore SR-IOV, una risorsa personalizzata SriovOperatorConfig.
  3. Imposta i criteri SR-IOV e i tuoi VF.
  4. Crea una risorsa personalizzata NetworkAttachmentDefinition che faccia riferimento ai tuoi VF.

Requisiti

La funzionalità di networking SR-IOV richiede i driver ufficiali per rendere disponibili gli adattatori di rete sui nodi del cluster. Installa i driver prima di utilizzare l'operatore SR-IOV. Inoltre, per utilizzare il modulo vfio-pci per i 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, aggiungi l'annotazione baremetal.cluster.gke.io/enable-sriov-networking alla risorsa personalizzata del cluster. Inoltre, imposta il campo multipleNetworkInterfaces nella sezione clusterNetwork della risorsa personalizzata del cluster su true.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  annotations:
    baremetal.cluster.gke.io/enable-sriov-networking: "true"
spec:
  clusterNetwork:
    multipleNetworkInterfaces: true
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/12

Configura l'operatore SR-IOV

La risorsa personalizzata SriovOperatorConfig fornisce una 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 questo spazio dei nomi.

Puoi modificare questo oggetto con il comando seguente:

kubectl -n gke-operators edit sriovoperatorconfigs.sriovnetwork.k8s.cni.cncf.io default

Ecco un esempio di una configurazione di 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: 2

La sezione configDaemonNodeSelector consente di limitare i nodi che l'operatore SR-IOV può gestire. Nell'esempio precedente, l'operatore è limitato ai soli 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 del nodo Kubernetes prima del riavvio del nodo o della modifica di una configurazione VF specifica.

Crea criteri SR-IOV

Per configurare VM 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 è necessario creare le VF. Questa limitazione si applica 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:

  • netdevice per modulo kernel standard specifico per VF
  • vfio-pci per il driver VFIO-PCI

resourceName definisce il nome rappresentato dalle VF nel nodo Kubernetes.

Al termine della procedura di configurazione, i nodi del cluster selezionati contengono la risorsa definita, come mostrato nell'esempio seguente (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é il SriovNetworkNodePolicy funzioni correttamente, specifica almeno un selettore nella sezione nicSelector. Questo campo contiene più opzioni su come identificare funzioni fisiche specifiche nei nodi del cluster. La maggior parte delle informazioni richieste da questo campo viene trovata per te e salvata nella risorsa personalizzata SriovNetworkNodeState. Ci sarà un oggetto per ogni nodo che questo operatore può gestire.

Utilizza il comando seguente per visualizzare tutti i nodi disponibili:

kubectl -n gke-operators get sriovnetworknodestates.sriovnetwork.k8s.cni.cncf.io -o yaml

Ecco un esempio di un 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 partizionamento di funzioni fisiche

Presta particolare attenzione al campo pfNames della sezione nicSelector. Oltre a indicare esattamente quale PF utilizzare, ti 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é i VF vengono sempre creati dall'indice zero, il tuo numero richiesto di VF, numVfs, deve essere almeno pari al valore di chiusura dell'intervallo (conteggiando uno 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.

Quando il partizionamento non è specificato, numVfs definisce l'intervallo VF che viene utilizzato, che parte sempre da zero. Ad esempio, se imposti numVfs=3 senza specificare il partizionamento, viene utilizzato il VF0-2.

Informazioni sulla priorità dei criteri

Puoi specificare più oggetti SriovNetworkNodePolicy per gestire vari fornitori o diverse configurazioni VF. La gestione di più oggetti e fornitori potrebbe creare problemi quando più criteri fanno riferimento allo stesso PF. Per gestire queste situazioni, il campo priority risolve i conflitti in base al nodo.

Ecco la logica di priorità per i criteri PF sovrapposti:

  1. Un criterio con priorità più alta sovrascrive sempre uno con priorità più bassa.

  2. I criteri con priorità uguale vengono uniti:

    1. I criteri vengono ordinati per nome ed elaborati in tale ordine.
    2. I criteri con VF sovrapposti vengono sovrascritti.
    3. I criteri con partizionamento PF non sovrapposti vengono uniti e sono tutti presenti.

Un criterio ad alta priorità è quello con un valore numerico più basso nel campo priority. Ad esempio, la priorità è più alta 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 partizionata

Il deployment dei due manifest SriovNetworkNodePolicy riportati di seguito 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"

Intervalli VF sovrapposti

Il deployment dei due manifest SriovNetworkNodePolicy riportati di seguito rende disponibile solo la risorsa gke.io/dev-vfio. L'intervallo policy-1 VF è 0-2, che si sovrappone a policy-2. A causa della denominazione, policy-2 viene elaborato per ultimo. Di conseguenza, è 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"

Verifica lo stato della configurazione del criterio SR-IOV

Quando applichi i criteri SR-IOV, puoi tenere traccia 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 della risorsa personalizzata SriovNetworkNodeState definisce lo stato finale della configurazione VF per quel nodo, in base al numero di criteri e alle loro priorità. Tutti i VF creati verranno elencati nella sezione status per i 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 personalizzata NetworkAttachmentDefinition

Dopo aver configurato correttamente i VF sul cluster, che saranno visibili nel nodo Kubernetes come risorsa, dovrai creare un NetworkAttachmentDefinition che faccia riferimento alla risorsa. Fai riferimento con un'annotazione k8s.v1.cni.cncf.io/resourceName.

Ecco un manifest NetworkAttachmentDefinition di esempio 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 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 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 o del posizionamento nei pod specifici, che viene eseguito 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 la rete SR-IOV.

Riavvii dei nodi

Quando l'operatore SR-IOV configura i nodi, i nodi 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.

Adattatori di rete supportati

Nella tabella seguente sono elencate le schede di rete supportate per i cluster della versione 1.10.x:

Nome ID fornitore ID dispositivo ID dispositivo VF
Intel i40e XXV710 8086 158a 154 C
Intel i40e 25G SFP28 8086 158b 154 C
Intel i40e 10G X710 SFP 8086 1572 154 C
Intel i40e XXV710 N3000 8086 0d58 154 C
Intel i40e 40G XL710 QSFP 8086 1583 154 C
Intel Columbiaville E810-CQDA2 2CQDA2 8086 1592 1889
Intel Columbiaville E810-XXVDA4 8086 1593 1889
Intel 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 Guida introduttiva
Nvidia mlx5 ConnectX-6 15b3 Guida introduttiva Guida introduttiva
Nvidia mlx5 ConnectX-6_Dx 15b3 Guida introduttiva Guida introduttiva
Nvidia mlx5 MT42822 BlueField-2 integrato ConnectX-6 Dx 15b3 A2D6 Guida introduttiva