Chapitre 23. Réseaux matériels

L'opérateur de réseau SR-IOV est pris en charge sur les plates-formes suivantes :

OpenShift Container Platform prend en charge les contrôleurs d'interface réseau suivants :

L'opérateur de réseau SR-IOV recherche dans votre cluster les périphériques réseau compatibles SR-IOV sur les nœuds de travail. L'opérateur crée et met à jour une ressource personnalisée (CR) SriovNetworkNodeState pour chaque nœud de travailleur qui fournit un périphérique réseau SR-IOV compatible.

Le CR porte le même nom que le nœud de travail. La liste status.interfaces fournit des informations sur les périphériques réseau d'un nœud.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodeState
metadata:
  name: node-25 1
  namespace: openshift-sriov-network-operator
  ownerReferences:
  - apiVersion: sriovnetwork.openshift.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: SriovNetworkNodePolicy
    name: default
spec:
  dpConfigVersion: "39824"
status:
  interfaces: 2
  - deviceID: "1017"
    driver: mlx5_core
    mtu: 1500
    name: ens785f0
    pciAddress: "0000:18:00.0"
    totalvfs: 8
    vendor: 15b3
  - deviceID: "1017"
    driver: mlx5_core
    mtu: 1500
    name: ens785f1
    pciAddress: "0000:18:00.1"
    totalvfs: 8
    vendor: 15b3
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens817f0
    pciAddress: 0000:81:00.0
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens817f1
    pciAddress: 0000:81:00.1
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens803f0
    pciAddress: 0000:86:00.0
    totalvfs: 64
    vendor: "8086"
  syncStatus: Succeeded

Vous pouvez exécuter une application d'accès direct à la mémoire à distance (RDMA) ou un kit de développement du plan de données (DPDK) dans un pod auquel est attaché un SR-IOV VF.

Cet exemple montre un pod utilisant une fonction virtuelle (VF) en mode RDMA :

apiVersion: v1
kind: Pod
metadata:
  name: rdma-app
  annotations:
    k8s.v1.cni.cncf.io/networks: sriov-rdma-mlnx
spec:
  containers:
  - name: testpmd
    image: <RDMA_image>
    imagePullPolicy: IfNotPresent
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"]
    command: ["sleep", "infinity"]

L'exemple suivant montre un pod avec un VF en mode DPDK :

apiVersion: v1
kind: Pod
metadata:
  name: dpdk-app
  annotations:
    k8s.v1.cni.cncf.io/networks: sriov-dpdk-net
spec:
  containers:
  - name: testpmd
    image: <DPDK_image>
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"]
    volumeMounts:
    - mountPath: /dev/hugepages
      name: hugepage
    resources:
      limits:
        memory: "1Gi"
        cpu: "2"
        hugepages-1Gi: "4Gi"
      requests:
        memory: "1Gi"
        cpu: "2"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

Une bibliothèque optionnelle, app-netutil, fournit plusieurs méthodes API pour collecter des informations réseau sur un pod à partir d'un conteneur s'exécutant dans ce pod.

Cette bibliothèque peut aider à intégrer les fonctions virtuelles SR-IOV (VF) en mode DPDK (Data Plane Development Kit) dans le conteneur. La bibliothèque fournit à la fois une API Golang et une API C.

Actuellement, trois méthodes API sont mises en œuvre :

Le dépôt de la bibliothèque comprend un exemple de fichier Docker pour construire une image de conteneur, dpdk-app-centos. L'image de conteneur peut exécuter l'un des exemples d'applications DPDK suivants, en fonction d'une variable d'environnement dans la spécification du pod : l2fwd l3wd testpmd l'image de conteneur fournit un exemple d'intégration de la bibliothèque app-netutil dans l'image de conteneur elle-même. La bibliothèque peut également être intégrée dans un conteneur d'initialisation. Ce dernier peut collecter les données requises et les transmettre à une charge de travail DPDK existante.

Lorsqu'une spécification de pod inclut une demande de ressources ou une limite pour les pages volumineuses, l'injecteur de ressources réseau ajoute automatiquement des champs API descendants à la spécification de pod afin de fournir les informations sur les pages volumineuses au conteneur.

L'injecteur de ressources réseau ajoute un volume nommé podnetinfo et monté sur /etc/podnetinfo pour chaque conteneur du module. Le volume utilise l'API Downward et inclut un fichier pour les demandes de pages énormes et les limites. La convention de dénomination des fichiers est la suivante :

Les chemins spécifiés dans la liste précédente sont compatibles avec la bibliothèque app-netutil. Par défaut, la bibliothèque est configurée pour rechercher des informations sur les ressources dans le répertoire /etc/podnetinfo. Si vous choisissez de spécifier manuellement les éléments du chemin d'accès à l'API descendante, la bibliothèque app-netutil recherche les chemins d'accès suivants en plus des chemins d'accès de la liste précédente.

Comme pour les chemins que l'injecteur de ressources réseau peut créer, les chemins de la liste précédente peuvent éventuellement se terminer par un suffixe _<container-name>.