SupportConsoleDéveloppeursCommencer un essaiContact

23.11. Utiliser la liaison au niveau du pod

Le bonding au niveau du pod est essentiel pour permettre aux charges de travail à l'intérieur des pods de bénéficier d'une haute disponibilité et d'un débit plus élevé. Avec le bonding au niveau du pod, vous pouvez créer une interface de bonding à partir de plusieurs interfaces de fonctions virtuelles de virtualisation d'E/S à racine unique (SR-IOV) dans une interface en mode noyau. Les fonctions virtuelles SR-IOV sont transférées dans le pod et attachées à un pilote de noyau.

Un scénario dans lequel le bonding au niveau du pod est nécessaire est la création d'une interface de bonding à partir de plusieurs fonctions virtuelles SR-IOV sur différentes fonctions physiques. La création d'une interface de liaison à partir de deux fonctions physiques différentes sur l'hôte peut être utilisée pour obtenir une haute disponibilité et un débit élevé au niveau du pod.

Pour obtenir des conseils sur des tâches telles que la création d'un réseau SR-IOV, les politiques de réseau, les définitions d'attachement au réseau et les pods, voir Configuration d'un dispositif de réseau SR-IOV.

23.11.1. Configuration d'une interface de liaison à partir de deux interfaces SR-IOV

Le bonding permet d'agréger plusieurs interfaces réseau en une seule interface logique. L'interface Bond Container Network Interface (Bond-CNI) intègre la capacité de liaison dans les conteneurs.

Bond-CNI peut être créé en utilisant des fonctions virtuelles SR-IOV (Single Root I/O Virtualization) et en les plaçant dans l'espace de noms du réseau de conteneurs.

OpenShift Container Platform ne supporte que Bond-CNI en utilisant les fonctions virtuelles SR-IOV. L'opérateur de réseau SR-IOV fournit le plugin CNI SR-IOV nécessaire pour gérer les fonctions virtuelles. D'autres CNI ou types d'interfaces ne sont pas pris en charge.

Conditions préalables

  • L'opérateur de réseau SR-IOV doit être installé et configuré pour obtenir des fonctions virtuelles dans un conteneur.
  • Pour configurer les interfaces SR-IOV, un réseau et une politique SR-IOV doivent être créés pour chaque interface.
  • L'opérateur de réseau SR-IOV crée une définition de l'attachement au réseau pour chaque interface SR-IOV, sur la base du réseau SR-IOV et de la politique définie.
  • Le site linkState est réglé sur la valeur par défaut auto pour la fonction virtuelle SR-IOV.

23.11.1.1. Création d'une définition d'attachement à un réseau de liens

Maintenant que les fonctions virtuelles SR-IOV sont disponibles, vous pouvez créer une définition d'attachement au réseau de liaison. 

apiVersion: "k8s.cni.cncf.io/v1"
    kind: NetworkAttachmentDefinition
    metadata:
      name: bond-net1
      namespace: demo
    spec:
      config: '{
      "type": "bond", 1
      "cniVersion": "0.3.1",
      "name": "bond-net1",
      "mode": "active-backup", 2
      "failOverMac": 1, 3
      "linksInContainer": true, 4
      "miimon": "100",
      "mtu": 1500,
      "links": [ 5
            {"name": "net1"},
            {"name": "net2"}
        ],
      "ipam": {
            "type": "host-local",
            "subnet": "10.56.217.0/24",
            "routes": [{
            "dst": "0.0.0.0/0"
            }],
            "gateway": "10.56.217.1"
        }
      }'
1
Le type cni- est toujours défini sur bond.
2
L'attribut mode spécifie le mode de liaison.
Note

Les modes de liaison pris en charge sont les suivants :

  • balance-rr - 0
  • active-backup - 1
  • balance-xor - 2

Pour les modes balance-rr ou balance-xor, vous devez définir le mode trust sur on pour la fonction virtuelle SR-IOV.

3
L'attribut failover est obligatoire pour le mode de sauvegarde active et doit être défini sur 1.
4
Le drapeau linksInContainer=true informe le Bond CNI que les interfaces requises doivent être trouvées à l'intérieur du conteneur. Par défaut, Bond CNI recherche ces interfaces sur l'hôte, ce qui ne fonctionne pas pour l'intégration avec SRIOV et Multus.
5
La section links définit les interfaces qui seront utilisées pour créer le lien. Par défaut, Multus nomme les interfaces attachées comme suit : \N "net\N", plus un nombre consécutif, en commençant par un.

23.11.1.2. Création d'un pod à l'aide d'une interface de liaison

  1. Testez la configuration en créant un pod avec un fichier YAML nommé par exemple podbonding.yaml avec un contenu similaire à ce qui suit : 

    apiVersion: v1
    kind: Pod
    metadata:
      name: bondpod1
      namespace: demo
      annotations:
        k8s.v1.cni.cncf.io/networks: demo/sriovnet1, demo/sriovnet2, demo/bond-net1 1
    spec:
      containers:
      - name: podexample
        image: quay.io/openshift/origin-network-interface-bond-cni:4.11.0
        command: ["/bin/bash", "-c", "sleep INF"]
    1
    Notez l'annotation du réseau : il contient deux attachements de réseau SR-IOV et un attachement de réseau de liaison. L'attachement de liaison utilise les deux interfaces SR-IOV comme interfaces de port liées.

  2. Appliquez le fichier yaml en exécutant la commande suivante : 

    $ oc apply -f podbonding.yaml

  3. Inspectez les interfaces du pod à l'aide de la commande suivante : 

    $ oc rsh -n demo bondpod1
sh-4.4#
sh-4.4# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
3: eth0@if150: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1450 qdisc noqueue state UP
link/ether 62:b1:b5:c8:fb:7a brd ff:ff:ff:ff:ff:ff
inet 10.244.1.122/24 brd 10.244.1.255 scope global eth0
valid_lft forever preferred_lft forever
4: net3: <BROADCAST,MULTICAST,UP,LOWER_UP400> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 9e:23:69:42:fb:8a brd ff:ff:ff:ff:ff:ff 1
inet 10.56.217.66/24 scope global bond0
valid_lft forever preferred_lft forever
43: net1: <BROADCAST,MULTICAST,UP,LOWER_UP800> mtu 1500 qdisc mq master bond0 state UP qlen 1000
link/ether 9e:23:69:42:fb:8a brd ff:ff:ff:ff:ff:ff 2
44: net2: <BROADCAST,MULTICAST,UP,LOWER_UP800> mtu 1500 qdisc mq master bond0 state UP qlen 1000
link/ether 9e:23:69:42:fb:8a brd ff:ff:ff:ff:ff:ff 3
    1
    L'interface de liaison est automatiquement nommée net3. Pour définir un nom d'interface spécifique, ajoutez le suffixe @name à l'annotation k8s.v1.cni.cncf.io/networks du pod.
    2
    L'interface net1 est basée sur une fonction virtuelle SR-IOV.
    3
    L'interface net2 est basée sur une fonction virtuelle SR-IOV.
    Note

    Si aucun nom d'interface n'est configuré dans l'annotation du pod, les noms d'interface sont attribués automatiquement sous la forme net<n>, <n> commençant par 1.

  4. Facultatif : si vous souhaitez définir un nom d'interface spécifique, par exemple bond0, modifiez l'annotation k8s.v1.cni.cncf.io/networks et définissez bond0 comme nom d'interface comme suit : 

    annotations:
        k8s.v1.cni.cncf.io/networks: demo/sriovnet1, demo/sriovnet2, demo/bond-net1@bond0
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.