23.12. Configuration du délestage matériel
En tant qu'administrateur de cluster, vous pouvez configurer le délestage matériel sur les nœuds compatibles afin d'augmenter les performances de traitement des données et de réduire la charge sur les processeurs hôtes.
23.12.1. À propos du délestage matériel
Le déchargement matériel Open vSwitch est une méthode de traitement des tâches réseau qui consiste à les détourner de l'unité centrale et à les décharger sur un processeur dédié sur un contrôleur d'interface réseau. Les clusters peuvent ainsi bénéficier de vitesses de transfert de données plus rapides, d'une réduction de la charge de travail de l'unité centrale et d'une baisse des coûts informatiques.
L'élément clé de cette fonctionnalité est une classe moderne de contrôleurs d'interface réseau connus sous le nom de SmartNIC. Un SmartNIC est un contrôleur d'interface réseau capable de gérer des tâches de traitement réseau lourdes en termes de calcul. De la même manière qu'une carte graphique dédiée peut améliorer les performances graphiques, un SmartNIC peut améliorer les performances du réseau. Dans chaque cas, un processeur dédié améliore les performances pour un type spécifique de tâche de traitement.
Dans OpenShift Container Platform, vous pouvez configurer le délestage matériel pour les nœuds bare metal qui ont un SmartNIC compatible. Le délestage matériel est configuré et activé par l'opérateur du réseau SR-IOV.
Le délestage matériel n'est pas compatible avec toutes les charges de travail ou tous les types d'application. Seuls les deux types de communication suivants sont pris en charge :
- de pod à pod
- pod-to-service, où le service est un service ClusterIP soutenu par un pod régulier
Dans tous les cas, le délestage matériel n'a lieu que lorsque les pods et les services sont affectés à des nœuds dotés d'un SmartNIC compatible. Supposons, par exemple, qu'un module sur un nœud avec délestage matériel essaie de communiquer avec un service sur un nœud normal. Sur le nœud normal, tout le traitement a lieu dans le noyau, de sorte que les performances globales de la communication entre le pod et le service sont limitées aux performances maximales de ce nœud normal. Le déchargement matériel n'est pas compatible avec les applications DPDK.
Le fait d'activer le délestage matériel sur un nœud, mais de ne pas configurer les pods pour qu'ils l'utilisent, peut entraîner une diminution des performances de débit pour le trafic des pods. Vous ne pouvez pas configurer le délestage matériel pour les pods qui sont gérés par OpenShift Container Platform.
23.12.2. Dispositifs pris en charge
Le délestage matériel est pris en charge par les contrôleurs d'interface réseau suivants :
Fabricant | Model | ID du vendeur | ID de l'appareil |
---|---|---|---|
Mellanox | Famille MT27800 [ConnectX-5] | 15b3 | 1017 |
Mellanox | Famille MT28880 [ConnectX-5 Ex] | 15b3 | 1019 |
Fabricant | Model | ID du vendeur | ID de l'appareil |
---|---|---|---|
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 |
L'utilisation d'un périphérique ConnectX-6 Lx ou BlueField-2 en mode ConnectX-6 NIC est 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 de les utiliser 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.
23.12.3. Conditions préalables
- Votre cluster possède au moins une machine bare metal avec un contrôleur d'interface réseau pris en charge pour le délestage matériel.
- Vous avez installé l'opérateur de réseau SR-IOV.
- Votre cluster utilise le plugin réseau OVN-Kubernetes.
-
Dans la configuration de votre plugin réseau OVN-Kubernetes, le champ
gatewayConfig.routingViaHost
est défini surfalse
.
23.12.4. Configuration d'un pool de configuration de machines pour le délestage matériel
Pour activer le délestage matériel, vous devez d'abord créer un pool de configuration machine dédié et le configurer pour qu'il fonctionne avec l'opérateur de réseau SR-IOV.
Conditions préalables
-
Vous avez installé l'OpenShift CLI (
oc
). -
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin
.
Procédure
Créez un pool de configuration pour les machines sur lesquelles vous souhaitez utiliser le délestage matériel.
Créez un fichier, tel que
mcp-offloading.yaml
, dont le contenu ressemble à l'exemple suivant :apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool metadata: name: mcp-offloading 1 spec: machineConfigSelector: matchExpressions: - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,mcp-offloading]} 2 nodeSelector: matchLabels: node-role.kubernetes.io/mcp-offloading: "" 3
Appliquer la configuration pour le pool de configuration de la machine :
$ oc create -f mcp-offloading.yaml
Ajoutez des nœuds au pool de configuration de machines. Étiqueter chaque nœud avec l'étiquette de rôle de nœud de votre pool :
$ oc label node worker-2 node-role.kubernetes.io/mcp-offloading=""
Facultatif : Pour vérifier que le nouveau pool est créé, exécutez la commande suivante :
$ oc get nodes
Exemple de sortie
NAME STATUS ROLES AGE VERSION master-0 Ready master 2d v1.25.0 master-1 Ready master 2d v1.25.0 master-2 Ready master 2d v1.25.0 worker-0 Ready worker 2d v1.25.0 worker-1 Ready worker 2d v1.25.0 worker-2 Ready mcp-offloading,worker 47h v1.25.0 worker-3 Ready mcp-offloading,worker 47h v1.25.0
Ajouter ce pool de configuration machine à la ressource personnalisée
SriovNetworkPoolConfig
:Créez un fichier, tel que
sriov-pool-config.yaml
, dont le contenu ressemble à l'exemple suivant :apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkPoolConfig metadata: name: sriovnetworkpoolconfig-offload namespace: openshift-sriov-network-operator spec: ovsHardwareOffloadConfig: name: mcp-offloading 1
- 1
- Le nom du pool de configuration de la machine pour le délestage matériel.
Appliquer la configuration :
oc create -f <SriovNetworkPoolConfig_name>.yaml
NoteLorsque vous appliquez la configuration spécifiée dans un objet
SriovNetworkPoolConfig
, l'opérateur SR-IOV vide et redémarre les nœuds du pool de configuration de la machine.L'application des changements de configuration peut prendre plusieurs minutes.
23.12.5. Configuration de la politique des nœuds de réseau SR-IOV
Vous pouvez créer une configuration de dispositif de réseau SR-IOV pour un nœud en créant une stratégie de nœud de réseau SR-IOV. Pour activer le délestage matériel, vous devez définir le champ .spec.eSwitchMode
avec la valeur "switchdev"
.
La procédure suivante permet de créer une interface SR-IOV pour un contrôleur d'interface réseau avec délestage matériel.
Conditions préalables
-
Vous avez installé l'OpenShift CLI (
oc
). -
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin
.
Procédure
Créez un fichier, tel que
sriov-node-policy.yaml
, dont le contenu ressemble à l'exemple suivant :apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: sriov-node-policy <.> namespace: openshift-sriov-network-operator spec: deviceType: netdevice <.> eSwitchMode: "switchdev" <.> nicSelector: deviceID: "1019" rootDevices: - 0000:d8:00.0 vendor: "15b3" pfNames: - ens8f0 nodeSelector: feature.node.kubernetes.io/network-sriov.capable: "true" numVfs: 6 priority: 5 resourceName: mlxnics
<.> Nom de l'objet ressource personnalisé. <.> Requis. Le délestage matériel n'est pas pris en charge par
vfio-pci
<.> Requis.Appliquer la configuration de la politique :
$ oc create -f sriov-node-policy.yaml
NoteLorsque vous appliquez la configuration spécifiée dans un objet
SriovNetworkPoolConfig
, l'opérateur SR-IOV vide et redémarre les nœuds du pool de configuration de la machine.L'application d'une modification de configuration peut prendre plusieurs minutes.
23.12.5.1. Exemple de politique de nœuds de réseau SR-IOV pour OpenStack
L'exemple suivant décrit une interface SR-IOV pour un contrôleur d'interface réseau (NIC) avec déchargement matériel sur Red Hat OpenStack Platform (RHOSP).
Une interface SR-IOV pour une carte d'interface réseau avec délestage matériel sur RHOSP
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: ${name} namespace: openshift-sriov-network-operator spec: deviceType: switchdev isRdma: true nicSelector: netFilter: openstack/NetworkID:${net_id} nodeSelector: feature.node.kubernetes.io/network-sriov.capable: 'true' numVfs: 1 priority: 99 resourceName: ${name}
23.12.6. Création d'une définition de pièce jointe au réseau
Après avoir défini le pool de configuration machine et la stratégie de nœuds de réseau SR-IOV, vous pouvez créer une définition d'attachement réseau pour la carte d'interface réseau que vous avez spécifiée.
Conditions préalables
-
Vous avez installé l'OpenShift CLI (
oc
). -
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin
.
Procédure
Créez un fichier, tel que
net-attach-def.yaml
, dont le contenu ressemble à l'exemple suivant :apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: net-attach-def <.> namespace: net-attach-def <.> annotations: k8s.v1.cni.cncf.io/resourceName: openshift.io/mlxnics <.> spec: config: '{"cniVersion":"0.3.1","name":"ovn-kubernetes","type":"ovn-k8s-cni-overlay","ipam":{},"dns":{}}'
<.> Le nom de la définition de la pièce jointe au réseau. <.> L'espace de noms pour votre définition de pièce jointe au réseau. <.> Il s'agit de la valeur du champ
spec.resourceName
que vous avez spécifiée dans l'objetSriovNetworkNodePolicy
.Appliquer la configuration pour la définition de l'attachement au réseau :
$ oc create -f net-attach-def.yaml
Vérification
Exécutez la commande suivante pour vérifier si la nouvelle définition est présente :
$ oc get net-attach-def -A
Exemple de sortie
NAMESPACE NAME AGE net-attach-def net-attach-def 43h
23.12.7. Ajouter la définition de l'attachement réseau à vos pods
Après avoir créé le pool de configuration machine, les ressources personnalisées SriovNetworkPoolConfig
et SriovNetworkNodePolicy
et la définition de l'attachement au réseau, vous pouvez appliquer ces configurations à vos modules en ajoutant la définition de l'attachement au réseau aux spécifications de votre module.
Procédure
Dans la spécification du pod, ajoutez le champ
.metadata.annotations.k8s.v1.cni.cncf.io/networks
et indiquez la définition de l'attachement réseau que vous avez créée pour le déchargement matériel :.... metadata: annotations: v1.multus-cni.io/default-network: net-attach-def/net-attach-def <.>
<.> La valeur doit être le nom et l'espace de noms de la définition de l'attachement réseau que vous avez créée pour le déchargement matériel.