Chapitre 23. Réseaux matériels


23.1. À propos des réseaux matériels de virtualisation des E/S à racine unique (SR-IOV)

La spécification SR-IOV (Single Root I/O Virtualization) est une norme pour un type d'affectation de périphérique PCI qui peut partager un périphérique unique avec plusieurs pods.

SR-IOV peut segmenter un dispositif de réseau conforme, reconnu sur le nœud hôte comme une fonction physique (PF), en plusieurs fonctions virtuelles (VF). La VF est utilisée comme n'importe quel autre périphérique réseau. Le pilote de périphérique réseau SR-IOV pour le périphérique détermine comment la VF est exposée dans le conteneur :

  • netdevice pilote : Un périphérique réseau normal du noyau dans le site netns du conteneur
  • vfio-pci conducteur : Un dispositif de caractère monté dans le conteneur

Vous pouvez utiliser les périphériques réseau SR-IOV avec des réseaux supplémentaires sur votre cluster OpenShift Container Platform installé sur une infrastructure bare metal ou Red Hat OpenStack Platform (RHOSP) pour les applications qui nécessitent une bande passante élevée ou une faible latence.

Vous pouvez configurer des politiques multi-réseaux pour les réseaux SR-IOV. Il s'agit d'un aperçu technologique et les réseaux supplémentaires SR-IOV ne sont pris en charge qu'avec les cartes réseau du noyau. Ils ne sont pas pris en charge pour les applications du kit de développement du plan de données (DPDK).

Note

La création de politiques multi-réseaux sur les réseaux SR-IOV risque de ne pas offrir les mêmes performances aux applications que les réseaux SR-IOV sur lesquels aucune politique multi-réseaux n'est configurée.

Important

Les politiques multi-réseaux pour le réseau SR-IOV sont une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas leur utilisation en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

Vous pouvez activer le SR-IOV sur un nœud à l'aide de la commande suivante :

$ oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"

23.1.1. Composants qui gèrent les périphériques de réseau SR-IOV

L'opérateur de réseau SR-IOV crée et gère les composants de la pile SR-IOV. Il remplit les fonctions suivantes :

  • Orchestrer la découverte et la gestion des périphériques de réseau SR-IOV
  • Génère NetworkAttachmentDefinition des ressources personnalisées pour l'interface de réseau de conteneurs SR-IOV (CNI)
  • Crée et met à jour la configuration du plugin de l'appareil réseau SR-IOV
  • Crée des ressources personnalisées spécifiques au nœud SriovNetworkNodeState
  • Met à jour le champ spec.interfaces dans chaque ressource personnalisée SriovNetworkNodeState

L'opérateur fournit les éléments suivants :

Démon de configuration du réseau SR-IOV
Ensemble de démons déployés sur les nœuds de travail lors du démarrage de l'opérateur de réseau SR-IOV. Le démon est responsable de la découverte et de l'initialisation des périphériques réseau SR-IOV dans le cluster.
Webhook de l'opérateur de réseau SR-IOV
Un webhook de contrôleur d'admission dynamique qui valide la ressource personnalisée de l'opérateur et définit les valeurs par défaut appropriées pour les champs non définis.
SR-IOV Injecteur de ressources réseau
Un webhook de contrôleur d'admission dynamique qui fournit une fonctionnalité pour patcher les spécifications des pods Kubernetes avec des demandes et des limites pour les ressources réseau personnalisées telles que les VF SR-IOV. L'injecteur de ressources réseau SR-IOV ajoute automatiquement le champ resource au premier conteneur d'un pod.
Plugin de périphérique de réseau SR-IOV
Un plugin de périphérique qui découvre, annonce et alloue des ressources de fonction virtuelle (VF) de réseau SR-IOV. Les plugins de périphérique sont utilisés dans Kubernetes pour permettre l'utilisation de ressources limitées, généralement dans des dispositifs physiques. Les plugins de périphérique permettent au planificateur de Kubernetes de connaître la disponibilité des ressources, de sorte que le planificateur peut programmer des pods sur des nœuds disposant de ressources suffisantes.
SR-IOV Plugin CNI
Un plugin CNI qui attache les interfaces VF allouées par le plugin de périphérique réseau SR-IOV directement à un pod.
SR-IOV InfiniBand CNI plugin
Un plugin CNI qui attache les interfaces InfiniBand (IB) VF allouées par le plugin de périphérique réseau SR-IOV directement dans un pod.
Note

L'injecteur de ressources du réseau SR-IOV et le webhook de l'opérateur du réseau SR-IOV sont activés par défaut et peuvent être désactivés en modifiant le site default SriovOperatorConfig CR. Soyez prudent lorsque vous désactivez le webhook du contrôleur d'admission de l'opérateur de réseau SR-IOV. Vous pouvez désactiver le webhook dans des circonstances spécifiques, telles que le dépannage, ou si vous souhaitez utiliser des périphériques non pris en charge.

23.1.1.1. Plates-formes prises en charge

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

  • Métal nu
  • Plate-forme Red Hat OpenStack (RHOSP)

23.1.1.2. Dispositifs pris en charge

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

Tableau 23.1. Contrôleurs d'interface réseau pris en charge
FabricantModelID du vendeurID de l'appareil

Broadcom

BCM57414

14e4

16d7

Broadcom

BCM57508

14e4

1750

Intel

X710

8086

1572

Intel

XL710

8086

1583

Intel

XXV710

8086

158b

Intel

E810-CQDA2

8086

1592

Intel

E810-2CQDA2

8086

1592

Intel

E810-XXVDA2

8086

159b

Intel

E810-XXVDA4

8086

1593

Mellanox

Famille MT27700 [ConnectX-4]

15b3

1013

Mellanox

Famille MT27710 [ConnectX-4 Lx]

15b3

1015

Mellanox

Famille MT27800 [ConnectX-5]

15b3

1017

Mellanox

Famille MT28880 [ConnectX-5 Ex]

15b3

1019

Mellanox

Famille MT28908 [ConnectX-6]

15b3

101b

Mellanox

Famille MT2892 [ConnectX-6 Dx]

15b3

101d

Mellanox

Famille MT2894 [ConnectX-6 Lx]

15b3

101f

Mellanox

MT42822 BlueField-2 en mode NIC ConnectX-6

15b3

a2d6

Pensando [1]

DSC-25 carte de services distribués 25G à double port pour pilote ionique

0x1dd8

0x1002

Pensando [1]

DSC-100 carte de services distribués 100G à double port pour pilote ionique

0x1dd8

0x1003

Silicom

Famille STS

8086

1591

  1. OpenShift SR-IOV est pris en charge, mais vous devez définir une adresse MAC (media access control) statique, Virtual Function (VF), à l'aide du fichier de configuration CNI SR-IOV lorsque vous utilisez SR-IOV.
Note

Pour obtenir la liste la plus récente des cartes prises en charge et des versions compatibles d'OpenShift Container Platform, consultez la matrice de prise en charge des réseaux matériels SR-IOV (Single Root I/O Virtualization) et PTP d'OpenShift.

23.1.1.3. Découverte automatisée des dispositifs de réseau SR-IOV

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.

Important

Ne pas modifier un objet SriovNetworkNodeState. L'Opérateur crée et gère ces ressources automatiquement.

23.1.1.3.1. Exemple d'objet SriovNetworkNodeState

Le fichier YAML suivant est un exemple d'objet SriovNetworkNodeState créé par l'opérateur de réseau SR-IOV :

Un objet SriovNetworkNodeState

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

1
La valeur du champ name est identique au nom du nœud de travail.
2
La strophe interfaces comprend une liste de tous les dispositifs SR-IOV découverts par l'opérateur sur le nœud de travail.

23.1.1.4. Exemple d'utilisation d'une fonction virtuelle dans un pod

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 :

Pod qui utilise le 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 :

Pod spec qui utilise le 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

23.1.1.5. Bibliothèque DPDK à utiliser avec les applications de conteneurs

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 :

GetCPUInfo()
Cette fonction détermine quels sont les processeurs disponibles pour le conteneur et renvoie la liste.
GetHugepages()
Cette fonction détermine la quantité de mémoire de page énorme demandée dans la spécification Pod pour chaque conteneur et renvoie les valeurs.
GetInterfaces()
Cette fonction détermine l'ensemble des interfaces du conteneur et renvoie la liste. La valeur de retour comprend le type d'interface et les données spécifiques à chaque interface.

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.

23.1.1.6. Injection de ressources dans des pages volumineuses pour l'API descendante

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 :

  • /etc/podnetinfo/hugepages_1G_request_<container-name>
  • /etc/podnetinfo/hugepages_1G_limit_<container-name>
  • /etc/podnetinfo/hugepages_2M_request_<container-name>
  • /etc/podnetinfo/hugepages_2M_limit_<container-name>

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.

  • /etc/podnetinfo/hugepages_request
  • /etc/podnetinfo/hugepages_limit
  • /etc/podnetinfo/hugepages_1G_request
  • /etc/podnetinfo/hugepages_1G_limit
  • /etc/podnetinfo/hugepages_2M_request
  • /etc/podnetinfo/hugepages_2M_limit

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>.

23.1.2. Ressources supplémentaires

23.1.3. Prochaines étapes

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.