23.7. Ajout d'un pod à un réseau supplémentaire SR-IOV


Vous pouvez ajouter un pod à un réseau existant de virtualisation d'E/S à racine unique (SR-IOV).

23.7.1. Configuration de l'exécution pour une pièce jointe au réseau

Lors de l'attachement d'un module à un réseau supplémentaire, vous pouvez spécifier une configuration d'exécution afin d'effectuer des personnalisations spécifiques pour le module. Par exemple, vous pouvez demander une adresse matérielle MAC spécifique.

Vous spécifiez la configuration d'exécution en définissant une annotation dans la spécification du pod. La clé de l'annotation est k8s.v1.cni.cncf.io/networks, et elle accepte un objet JSON qui décrit la configuration d'exécution.

23.7.1.1. Configuration de l'exécution pour un attachement SR-IOV basé sur Ethernet

Le JSON suivant décrit les options de configuration de la durée d'exécution pour un accessoire de réseau SR-IOV basé sur Ethernet.

[
  {
    "name": "<name>", 1
    "mac": "<mac_address>", 2
    "ips": ["<cidr_range>"] 3
  }
]
1
Le nom du CR de définition de l'attachement au réseau SR-IOV.
2
Facultatif : L'adresse MAC de l'appareil SR-IOV qui est allouée à partir du type de ressource défini dans le CR de définition de l'attachement au réseau SR-IOV. Pour utiliser cette fonctionnalité, vous devez également spécifier { "mac": true } dans l'objet SriovNetwork.
3
Facultatif : adresses IP pour le périphérique SR-IOV allouées à partir du type de ressource défini dans la CR de définition de l'attachement au réseau SR-IOV. Les adresses IPv4 et IPv6 sont prises en charge. Pour utiliser cette fonctionnalité, vous devez également spécifier { "ips": true } dans l'objet SriovNetwork.

Exemple de configuration d'exécution

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {
          "name": "net1",
          "mac": "20:04:0f:f1:88:01",
          "ips": ["192.168.10.1/24", "2001::1/64"]
        }
      ]
spec:
  containers:
  - name: sample-container
    image: <image>
    imagePullPolicy: IfNotPresent
    command: ["sleep", "infinity"]

23.7.1.2. Configuration de l'exécution pour un attachement SR-IOV basé sur InfiniBand

Le JSON suivant décrit les options de configuration de la durée d'exécution pour un attachement réseau SR-IOV basé sur InfiniBand.

[
  {
    "name": "<network_attachment>", 1
    "infiniband-guid": "<guid>", 2
    "ips": ["<cidr_range>"] 3
  }
]
1
Le nom du CR de définition de l'attachement au réseau SR-IOV.
2
Le GUID InfiniBand pour le périphérique SR-IOV. Pour utiliser cette fonctionnalité, vous devez également spécifier { "infinibandGUID": true } dans l'objet SriovIBNetwork.
3
Les adresses IP pour le dispositif SR-IOV qui est alloué à partir du type de ressource défini dans le CR de définition de l'attachement au réseau SR-IOV. Les adresses IPv4 et IPv6 sont prises en charge. Pour utiliser cette fonctionnalité, vous devez également spécifier { "ips": true } dans l'objet SriovIBNetwork.

Exemple de configuration d'exécution

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {
          "name": "ib1",
          "infiniband-guid": "c2:11:22:33:44:55:66:77",
          "ips": ["192.168.10.1/24", "2001::1/64"]
        }
      ]
spec:
  containers:
  - name: sample-container
    image: <image>
    imagePullPolicy: IfNotPresent
    command: ["sleep", "infinity"]

23.7.2. Ajouter un pod à un réseau supplémentaire

Vous pouvez ajouter un module à un réseau supplémentaire. Le pod continue à envoyer le trafic réseau normal lié au cluster sur le réseau par défaut.

Lorsqu'un module est créé, des réseaux supplémentaires lui sont rattachés. Toutefois, si un module existe déjà, il n'est pas possible d'y attacher des réseaux supplémentaires.

Le pod doit se trouver dans le même espace de noms que le réseau supplémentaire.

Note

L'injecteur de ressources réseau SR-IOV ajoute automatiquement le champ resource au premier conteneur d'un module.

Si vous utilisez un contrôleur d'interface réseau (NIC) Intel en mode DPDK (Data Plane Development Kit), seul le premier conteneur de votre pod est configuré pour accéder au NIC. Votre réseau supplémentaire SR-IOV est configuré pour le mode DPDK si deviceType est défini sur vfio-pci dans l'objet SriovNetworkNodePolicy.

Vous pouvez contourner ce problème en vous assurant que le conteneur qui a besoin d'accéder au NIC est le premier conteneur défini dans l'objet Pod ou en désactivant l'injecteur de ressources réseau. Pour plus d'informations, voir BZ#1990953.

Conditions préalables

  • Installez le CLI OpenShift (oc).
  • Connectez-vous au cluster.
  • Installer l'opérateur SR-IOV.
  • Créez un objet SriovNetwork ou un objet SriovIBNetwork pour y attacher le pod.

Procédure

  1. Ajouter une annotation à l'objet Pod. Un seul des formats d'annotation suivants peut être utilisé :

    1. Pour attacher un réseau supplémentaire sans aucune personnalisation, ajoutez une annotation avec le format suivant. Remplacez <network> par le nom du réseau supplémentaire à associer au pod :

      metadata:
        annotations:
          k8s.v1.cni.cncf.io/networks: <network>[,<network>,...] 1
      1
      Pour spécifier plus d'un réseau supplémentaire, séparez chaque réseau par une virgule. N'incluez pas d'espace entre les virgules. Si vous spécifiez plusieurs fois le même réseau supplémentaire, plusieurs interfaces réseau seront attachées à ce pod.
    2. Pour joindre un réseau supplémentaire avec des personnalisations, ajoutez une annotation avec le format suivant :

      metadata:
        annotations:
          k8s.v1.cni.cncf.io/networks: |-
            [
              {
                "name": "<network>", 1
                "namespace": "<namespace>", 2
                "default-route": ["<default-route>"] 3
              }
            ]
      1
      Indiquer le nom du réseau supplémentaire défini par un objet NetworkAttachmentDefinition.
      2
      Spécifier l'espace de noms dans lequel l'objet NetworkAttachmentDefinition est défini.
      3
      Facultatif : Spécifiez un remplacement de l'itinéraire par défaut, tel que 192.168.17.1.
  2. Pour créer le module, entrez la commande suivante. Remplacez <name> par le nom du module.

    $ oc create -f <name>.yaml
  3. Facultatif : Pour confirmer que l'annotation existe dans le CR Pod, entrez la commande suivante, en remplaçant <name> par le nom du module.

    $ oc get pod <name> -o yaml

    Dans l'exemple suivant, le pod example-pod est rattaché au réseau supplémentaire net1:

    $ oc get pod example-pod -o yaml
    apiVersion: v1
    kind: Pod
    metadata:
      annotations:
        k8s.v1.cni.cncf.io/networks: macvlan-bridge
        k8s.v1.cni.cncf.io/networks-status: |- 1
          [{
              "name": "openshift-sdn",
              "interface": "eth0",
              "ips": [
                  "10.128.2.14"
              ],
              "default": true,
              "dns": {}
          },{
              "name": "macvlan-bridge",
              "interface": "net1",
              "ips": [
                  "20.2.2.100"
              ],
              "mac": "22:2f:60:a5:f8:00",
              "dns": {}
          }]
      name: example-pod
      namespace: default
    spec:
      ...
    status:
      ...
    1
    Le paramètre k8s.v1.cni.cncf.io/networks-status est un tableau JSON d'objets. Chaque objet décrit l'état d'un réseau supplémentaire attaché au pod. La valeur de l'annotation est stockée sous forme de texte brut.

23.7.3. Création d'un pod SR-IOV aligné sur un accès mémoire non uniforme (NUMA)

Vous pouvez créer un pod SR-IOV aligné NUMA en limitant le SR-IOV et les ressources CPU allouées à partir du même nœud NUMA avec restricted ou single-numa-node Topology Manager polices.

Conditions préalables

  • Vous avez installé l'OpenShift CLI (oc).
  • Vous avez configuré la politique du Gestionnaire de CPU sur static. Pour plus d'informations sur le gestionnaire de CPU, voir la section "Ressources supplémentaires".
  • Vous avez configuré la politique de Topology Manager sur single-numa-node.

    Note

    Lorsque single-numa-node n'est pas en mesure de satisfaire la demande, vous pouvez configurer la politique du gestionnaire de topologie pour restricted.

Procédure

  1. Créez la spécification de pod SR-IOV suivante, puis enregistrez le YAML dans le fichier <name>-sriov-pod.yaml. Remplacez <name> par un nom pour ce pod.

    L'exemple suivant montre une spécification de pod SR-IOV :

    apiVersion: v1
    kind: Pod
    metadata:
      name: sample-pod
      annotations:
        k8s.v1.cni.cncf.io/networks: <name> 1
    spec:
      containers:
      - name: sample-container
        image: <image> 2
        command: ["sleep", "infinity"]
        resources:
          limits:
            memory: "1Gi" 3
            cpu: "2" 4
          requests:
            memory: "1Gi"
            cpu: "2"
    1
    Remplacer <name> par le nom de la définition de l'attachement au réseau SR-IOV CR.
    2
    Remplacez <image> par le nom de l'image sample-pod.
    3
    Pour créer le pod SR-IOV avec une garantie de qualité de service, définissez memory limits égal à memory requests.
    4
    Pour créer le pod SR-IOV avec une qualité de service garantie, définissez cpu limits égal à cpu requests.
  2. Créez l'exemple de pod SR-IOV en exécutant la commande suivante :

    $ oc create -f <filename> 1
    1
    Remplacez <filename> par le nom du fichier que vous avez créé à l'étape précédente.
  3. Confirmez que le site sample-pod est configuré avec une qualité de service garantie.

    $ oc describe pod sample-pod
  4. Confirmez que le site sample-pod est doté d'unités centrales exclusives.

    $ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
  5. Confirmez que le dispositif SR-IOV et les CPU alloués à l'adresse sample-pod se trouvent sur le même nœud NUMA.

    $ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus

23.7.4. Un modèle de pod de test pour les clusters qui utilisent SR-IOV sur OpenStack

Le pod testpmd suivant illustre la création d'un conteneur avec des pages énormes, des unités centrales réservées et le port SR-IOV.

Un exemple de pod testpmd

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-sriov
  namespace: mynamespace
  annotations:
    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
# ...
spec:
  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
        openshift.io/sriov1: 1
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
        openshift.io/sriov1: 1
    volumeMounts:
      - mountPath: /dev/hugepages
        name: hugepage
        readOnly: False
  runtimeClassName: performance-cnf-performanceprofile 1
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

1
Cet exemple suppose que le nom du profil de performance est cnf-performance profile.

23.7.5. Ressources supplémentaires

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.