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 sitenetns
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).
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.
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éeSriovNetworkNodeState
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.
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 :
Fabricant | Model | ID du vendeur | ID 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 |
- 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.
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.
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
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
- Installation de l'opérateur de réseau SR-IOV
- Optionnel : Configuration de l'opérateur de réseau SR-IOV
- Configuration d'un périphérique de réseau SR-IOV
- Si vous utilisez OpenShift Virtualization : Connexion d'une machine virtuelle à un réseau SR-IOV
- Configuration de l'attachement à un réseau SR-IOV
- Ajout d'un pod à un réseau supplémentaire SR-IOV