Déployer des applications de conteneur d'interfaces réseau compatibles SR-IOV sur OKE à l'aide du module d'extension Multus CNI

Introduction

Dans ce tutoriel, nous allons découvrir comment déployer des applications en conteneur sur des noeuds de processus actif d'instance virtuelle au sein d'Oracle Cloud Infrastructure Kubernetes Engine (OKE), en tirant parti des fonctionnalités réseau avancées. Plus précisément, nous activerons la virtualisation d'E/S à root unique (SR-IOV) pour les interfaces réseau de conteneur et configurerons le module d'extension Multus CNI pour activer la mise en réseau multiréseau pour vos conteneurs.

En combinant SR-IOV avec Multus, vous pouvez mettre en réseau hautes performances et à faible latence pour des charges de travail spécialisées telles que l'IA, le machine learning et le traitement des données en temps réel. Ce tutoriel fournit des instructions détaillées pour configurer votre environnement OKE, déployer des noeuds de processus actif avec des interfaces compatibles SR-IOV et utiliser Multus CNI pour gérer plusieurs interfaces réseau dans vos pods. Que vous visiez un traitement de paquets à haute vitesse ou que vous ayez besoin d'affiner votre réseau Kubernetes, ce tutoriel vous fournira les outils et les connaissances nécessaires pour commencer.

Remarque :

Lors de la publication de ce tutoriel, le CNI SR-IOV ne peut pas être utilisé par des pods ou des conteneurs sur une instance virtuelle qui fait partie d'un cluster OKE avec le module d'extension Multus CNI.

Dans ce tutoriel, nous allons vous montrer comment utiliser une interface compatible SR-IOV dans un pod exécuté sur des pods ou des conteneurs sur une instance virtuelle qui fait partie d'un cluster OKE en déplaçant le Cartes d'interface réseau virtuelles (VNIC) (qui se trouve sur une instance virtuelle) dans un pod et est utilisable à l'aide du module d'extension Multus CNI (où le module d'extension SR-IOV CNI n'est pas utilisé du tout).

Le module d'extension CNI SR-IOV est pris en charge sur une instance Bare Metal qui fait partie d'un cluster OKE avec le module d'extension CNI Multus. Ce tutoriel est hors de portée.

Objectifs

Déployez des applications de conteneur sur des noeuds de processus actif d'instance virtuelle dans OKE avec des interfaces réseau compatibles SR-IOV à l'aide du module d'extension Multus CNI.

Tâche 1 : déploiement d'OKE avec un bastion, un opérateur, trois noeuds VM Worker et le module d'extension CNI Flannel

Assurez-vous qu'OKE est déployé avec la configuration suivante :

Bastion
Opérateur
3 noeuds de processus actif de machine virtuelle
Plug-in CNI Flannel

Cette configuration est détaillée dans le tutoriel ici : Déploiement d'un cluster Kubernetes avec Terraform à l'aide d'Oracle Cloud Infrastructure Kubernetes Engine.

L'image suivante présente un aperçu visuel des composants avec lesquels nous allons travailler tout au long de ce tutoriel.

Tâche 2 : activer la mise en réseau SR-IOV (aide au matériel) sur chaque noeud de processus actif

Remarque : les étapes suivantes doivent être effectuées sur tous les noeuds de processus actifs qui font partie du cluster OKE.

L'image suivante présente un aperçu visuel de nos noeuds de processus actifs dans le cluster OKE avec lequel nous travaillerons tout au long de ce tutoriel.

Activer SR-IOV sur l'instance

Connectez-vous à l'instance ou au noeud de processus actif via SSH.
1. Exécutez la commande lspci pour vérifier quel pilote réseau est actuellement utilisé sur toutes les cartes d'interface réseau virtuelles.
2. Notez que le pilote réseau Virtio est utilisé.
1. Accédez à la page Détails de l'instance dans la console OCI.
2. Faites défiler vers le bas.
3. Notez que le type d'attachement de carte d'interface réseau est désormais PARAVIRTUALIZED.
1. Accédez à la page Détails de l'instance dans la console OCI.
2. Cliquez sur Actions supplémentaires.
3. Cliquez sur Modifier.
Cliquez sur Afficher les options avancées,
1. Cliquez sur Options de lancement et sélectionnez Mise en réseau assistée par le matériel (SR-IOV) comme type de mise en réseau.
2. Cliquez sur Sauvegarder les modifications.
Cliquez sur Réinitialiser l'instance pour confirmer le redémarrage de l'instance.
Le statut de l'instance est passé à STOPPING.
Le statut de l'instance est passé à STARTING.
Notez que le statut de l'instance est passé à RUNNING.
1. Faites défiler vers le bas.
2. Notez que le type d'attachement de carte d'interface réseau est désormais VFIO.
L'image suivante présente un aperçu visuel de ce que nous avons configuré jusqu'à présent.

Tâche 3 : création d'un sous-réseau pour les cartes d'interface réseau virtuelles compatibles SR-IOV

Nous allons créer un sous-réseau dédié que nos interfaces compatibles SR-IOV utiliseront.

Tâche 3.1 : créer une liste de sécurité

Comme nous utilisons déjà des listes de sécurité pour les autres sous-réseaux, nous avons également besoin d'une liste de sécurité dédiée pour le sous-réseau SR-IOV nouvellement créé.

Accédez à la console OCI.
1. Accédez à Réseaux cloud virtuels.
2. Cliquez sur le VCN existant.
1. Cliquez sur Listes de sécurité.
2. Cliquez sur Créer une liste de sécurité.
Pour la règle entrante 1, entrez les informations suivantes.
1. Entrez un nom.
2. Sélectionnez CIDR comme type de source.
3. Entrez 0.0.0.0/0 en tant que CIDR source.
4. Sélectionnez Tous les protocoles comme protocole IP.
5. Faites défiler vers le bas.
1. Pour la règle sortante 1, entrez les informations suivantes.
2. Sélectionnez CIDR comme type de source.
3. Entrez 0.0.0.0/0 en tant que CIDR source.
4. Sélectionnez Tous les protocoles comme protocole IP.
5. Cliquez sur Créer une liste de sécurité.
Notez que la nouvelle liste de sécurité est créée.

Tâche 3.2 : création d'un sous-réseau

Accédez à la page Détails du réseau cloud virtuel.
1. Cliquez sur Sous-réseaux.
2. Notez les sous-réseaux existants déjà créés pour l'environnement OKE.
3. Cliquez sur Créer un sous-réseau.
1. Entrez un nom.
2. Saisissez un bloc CIDRIPv4 CIDR IPv4.
3. Faites défiler vers le bas.
1. Sélectionnez sous-réseau privé.
2. Faites défiler vers le bas.
1. Sélectionnez Default DHCP Options dans le champ DHCP Options.
2. Sélectionnez Liste de sécurité créée dans la tâche 3.1.
3. Cliquez sur Créer un sous-réseau.
Le sous-réseau réseau est créé.
Remarque :
- Le sous-réseau lui-même ne comporte aucun composant technique compatible SR-IOV.
- Dans ce tutoriel, nous utilisons un sous-réseau OCI standard pour permettre le transport du trafic à l'aide de la technologie SR-IOV.
L'image suivante présente un aperçu visuel de ce que nous avons configuré jusqu'à présent.

Tâche 4 : ajouter un deuxième attachement de carte d'interface réseau virtuelle

L'image suivante montre un aperçu visuel de la façon dont les noeuds de processus actif disposent d'une carte d'interface réseau virtuelle unique connectée au sous-réseau des noeuds de processus actif avant l'ajout d'une deuxième carte d'interface réseau virtuelle.

Avant d'ajouter un deuxième attachement de carte d'interface réseau virtuelle aux noeuds de processus actif, créez un groupe de sécurité réseau.

Tâche 4.1 : création d'un groupe de sécurité réseau

Nous utilisons déjà un groupe de sécurité réseau pour les autres cartes d'interface réseau virtuelles, mais nous avons également besoin d'un groupe de sécurité réseau dédié pour la carte d'interface réseau virtuelle nouvellement créée que nous ajouterons à une instance virtuelle existante qui fait partie du cluster OKE et qui jouera son rôle de noeud de processus actif Kubernetes. Cette interface sera une carte d'interface réseau virtuelle sur laquelle SR-IOV est activé.

Accédez à la page Détails du réseau cloud virtuel.
1. Accédez à Groupes de sécurité réseau.
2. Cliquez sur Créer un groupe de sécurité réseau.
Ajoutez les règles suivantes.
1. Entrant:
  - Type de source autorisé : sélectionnez CIDR.
  - Source : entrez 0.0.0.0/0.
  - Destination : laissez la destination vide.
  - Protocole : autorise tous les protocoles.
2. Sortant:
  - Type de source autorisé : sélectionnez CIDR.
  - Source : laissez la source vide.
  - Destination : entrez 0.0.0.0/0.
  - Protocole : autorise tous les protocoles.
Notez que le groupe de sécurité réseau est créé. Nous l'appliquerons à la nouvelle VNIC (secondaire) que nous allons créer (sur chaque noeud de processus actif du cluster OKE).

Tâche 4.2 : ajouter la carte d'interface réseau virtuelle

Accédez à chaque instance de noeud de processus actif virtuel et ajoutez une deuxième VNIC à chaque noeud de processus actif.
1. Accédez à chaque instance de noeud de processus actif virtuel et cliquez sur VNIC attachées.
2. Notez qu'il existe déjà une carte d'interface réseau virtuelle.
3. Cliquez sur Créer une carte d'interface réseau virtuelle pour ajouter une deuxième carte.
1. Entrez un nom.
2. Sélectionnez le VCN.
3. Sélectionnez le sous-réseau créé dans la tâche 3.2.
4. Sélectionnez Utiliser les groupes de sécurité réseau pour contrôler le trafic.
5. Sélectionnez le NSG créé dans la tâche 4.1.
6. Faites défiler vers le bas.
1. Sélectionnez Affecter automatiquement une adresse IPv4 privée.
2. Cliquez sur Sauvegarder les modifications.
La deuxième carte d'interface réseau virtuelle est créée et attachée à l'instance de noeud de processus actif virtuel, ainsi qu'à notre sous-réseau.
Connectez-vous à l'instance ou au noeud de processus actif via SSH.
1. Exécutez la commande lspci pour vérifier quel pilote réseau est actuellement utilisé sur toutes les cartes d'interface réseau virtuelles.
2. Notez que le pilote réseau Mellanox Technologies ConnectX Family mlx5Gen Virtual Function est utilisé.
Le pilote réseau de la famille ConnectX Mellanox Technologies mlx5Gen Virtual Function est le pilote Virtual Function (VF) utilisé par SR-IOV. La VNIC est donc activée pour SR-IOV avec une fonction virtuelle.
L'image suivante présente un aperçu visuel de ce que nous avons configuré jusqu'à présent.

Tâche 5 : affectation d'une adresse IP à la nouvelle deuxième carte d'interface réseau virtuelle avec une passerelle par défaut

Maintenant que la deuxième carte d'interface réseau virtuelle a été créée dans la tâche 4 et attachée, nous devons lui affecter une adresse IP. Lorsque vous ajoutez une deuxième interface à une instance, vous pouvez l'affecter au même sous-réseau que la première interface, ou vous pouvez choisir un nouveau sous-réseau.

DHCP n'étant pas activé pour la deuxième interface, l'adresse IP doit être assignée manuellement.

Il existe différentes méthodes d'affectation de l'adresse IP pour la deuxième interface.

Méthode 1 : utilisez l'interface de ligne de commande Oracle Cloud Infrastructure (interface de ligne de commande OCI) (package oci-utils) pour affecter une adresse IP à la deuxième interface d'une instance OCI Compute à l'aide de la commande OCI-network-config.
Méthode 2 : utilisez l'interface de ligne de commande OCI (package oci-utils) pour affecter une adresse IP à la deuxième interface d'une instance OCI Compute à l'aide du démon ocid.
Méthode 3 : utilisez le script OCI_Multi_VNIC_Setup.
Méthode 4 : créez le fichier de configuration d'interface manuellement pour la nouvelle carte d'interface réseau virtuelle dans le dossier /etc/sysconfig/network-scripts/.

Pour tous les noeuds de processus actif, nous avons affecté une adresse IP à la vNIC secondaire (ens5). Nous avons utilisé la méthode 3 pour affecter une adresse IP à la vNIC secondaire (ens5). Pour plus d'informations sur l'affectation d'une adresse IP à la deuxième carte d'interface réseau virtuelle, reportez-vous à Affectation d'une adresse IP à une deuxième interface sur une instance Oracle Linux.

Une fois l'adresse IP affectée à une carte d'interface réseau virtuelle, nous devons vérifier si l'adresse IP sur les deuxièmes cartes d'interface réseau virtuelles est configurée correctement. Nous pouvons également vérifier si nous avons activé SR-IOV sur tous les noeuds de processus actif de pool de noeuds.

Notre cluster OKE se compose des éléments suivants :

Pool de noeuds
NP1	1 x noeud de processus actif
NP2	3 x noeuds de processus actif

Nous vérifierons tous les noeuds de processus actif dans tous les pools de noeuds.

Tâche 5.1 : vérifier tous les noeuds du pool de noeuds 1 (`np1`)

Dans le cluster OKE, cliquez sur Noeuds.
Cliquez sur le premier pool de noeuds (np1).
Cliquez sur le noeud de processus actif qui fait partie de ce pool de noeuds.
1. Notez que le type d'attachement de carte d'interface réseau est VFIO (ce qui signifie que SR-IOV est activé pour ce noeud de processus actif d'instance virtuelle).
2. La deuxième carte d'interface réseau virtuelle est créée et attachée pour ce noeud de processus actif.

Tâche 5.2 : vérifier tous les noeuds du pool de noeuds 2 (`np2`)

Cliquez un par un sur les noeuds et lancez la vérification.
1. Notez que le type d'attachement de carte d'interface réseau est VFIO (ce qui signifie que SR-IOV est activé pour ce noeud de processus actif d'instance virtuelle).
2. La deuxième carte d'interface réseau virtuelle est créée et attachée pour ce noeud de processus actif.
Accédez à la page récapitulative du pool de noeuds 2 (np2). Cliquez sur le second noeud de processus actif dans le pool de noeuds.
1. Notez que le type d'attachement de carte d'interface réseau est VFIO (ce qui signifie que SR-IOV est activé pour ce noeud de processus actif d'instance virtuelle).
2. La deuxième carte d'interface réseau virtuelle est créée et attachée pour ce noeud de processus actif.
Accédez à la page récapitulative du pool de noeuds 2 (np2). Cliquez sur le troisième noeud de processus actif dans le pool de noeuds.
1. Notez que le type d'attachement de carte d'interface réseau est VFIO (ce qui signifie que SR-IOV est activé pour ce noeud de processus actif d'instance virtuelle).
2. La deuxième carte d'interface réseau virtuelle est créée et attachée pour ce noeud de processus actif.

Connectez-vous à l'opérateur Kubernetes à l'aide de SSH.

Exécutez la commande kubectl get nodes pour extraire la liste et les adresses IP de tous les noeuds de processus actif.

[opc@o-sqrtga ~]$ kubectl get nodes
NAME           STATUS   ROLES   AGE   VERSION
10.0.112.134   Ready    node    68d   v1.30.1
10.0.66.97     Ready    node    68d   v1.30.1
10.0.73.242    Ready    node    68d   v1.30.1
10.0.89.50     Ready    node    68d   v1.30.1
[opc@o-sqrtga ~]$

Pour faciliter l'accès SSH à tous les noeuds de processus actif, nous avons créé le tableau suivant.

Nom du noeud de processus actif	Adresse IP ens3	Workernode SSH
cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0	10.0.112.134	`ssh -i id_rsa opc@10.0.112.134`
cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1	10.0.66.97	`ssh -i id_rsa opc@10.0.66.97`
cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0	10.0.73.242	`ssh -i id_rsa opc@10.0.73.242`
cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2	10.0.89.50	`ssh -i id_rsa opc@10.0.89.50`

Avant de pouvoir accéder via SSH à tous les noeuds de processus actif virtuels, assurez-vous que la clé privée appropriée est disponible.
Exécutez la commande ssh -i <private key> opc@<ip-address> pour utiliser SSH dans tous les noeuds de processus actif.

Exécutez la commande ip a sur le noeud de processus actif cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0.

Notez que lorsque l'adresse IP a été configurée avec succès, ens5 (deuxième carte d'interface réseau virtuelle) possède une adresse IP comprise dans la plage du sous-réseau créé dans la tâche 3.2 pour les interfaces SR-IOV.

[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 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
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:59:58 brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.112.134/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 85530sec preferred_lft 85530sec
   inet6 fe80::17ff:fe00:5958/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:d4:a2 brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.30/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::8106:c09e:61fa:1d2a/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether 3a:b7:fb:e6:2e:cf brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.0/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::38b7:fbff:fee6:2ecf/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether de:35:f5:51:85:5d brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.1/25 brd 10.244.1.127 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::dc35:f5ff:fe51:855d/64 scope link
      valid_lft forever preferred_lft forever
6: veth1cdaac17@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 76:e2:92:ad:37:40 brd ff:ff:ff:ff:ff:ff link-netns 1935ba66-34cc-4468-8abb-f66add46d08b
   inet6 fe80::74e2:92ff:fead:3740/64 scope link
      valid_lft forever preferred_lft forever
7: vethbcd391ab@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 9a:9a:0f:d6:48:17 brd ff:ff:ff:ff:ff:ff link-netns 3f02d5fd-596e-4b9f-8a35-35f2f946901b
   inet6 fe80::989a:fff:fed6:4817/64 scope link
      valid_lft forever preferred_lft forever
8: vethc15fa705@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 3a:d2:c8:66:d1:0b brd ff:ff:ff:ff:ff:ff link-netns f581b7f2-cfa0-46eb-b0aa-37001a11116d
   inet6 fe80::38d2:c8ff:fe66:d10b/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$

Exécutez la commande ip a sur le noeud de processus actif cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1.

Notez que lorsque l'adresse IP a été correctement configurée, ens5 (deuxième carte d'interface réseau virtuelle) possède une adresse IP comprise dans la plage du sous-réseau créé dans la tâche 3.2 pour les interfaces SR-IOV.

[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 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
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:16:ca brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.66.97/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 85859sec preferred_lft 85859sec
   inet6 fe80::17ff:fe00:16ca/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:7b:4f brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.15/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::87eb:4195:cacf:a6da/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether 02:92:e7:f5:8e:29 brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.128/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::92:e7ff:fef5:8e29/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether f6:08:06:e2:bc:9d brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.129/25 brd 10.244.1.255 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::f408:6ff:fee2:bc9d/64 scope link
      valid_lft forever preferred_lft forever
6: veth5db97290@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether c2:e0:b5:7e:ce:ed brd ff:ff:ff:ff:ff:ff link-netns 3682b5cd-9039-4931-aecc-b50d46dabaf1
   inet6 fe80::c0e0:b5ff:fe7e:ceed/64 scope link
      valid_lft forever preferred_lft forever
7: veth6fd818a5@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 3e:a8:7d:84:d3:b9 brd ff:ff:ff:ff:ff:ff link-netns 08141d6b-5ec0-4f3f-a312-a00b30f82ade
   inet6 fe80::3ca8:7dff:fe84:d3b9/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$

Exécutez la commande ip a sur le noeud de processus actif cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0.

[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 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
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:49:9c brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.73.242/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 86085sec preferred_lft 86085sec
   inet6 fe80::17ff:fe00:499c/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:b7:51 brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.14/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::bc31:aa09:4e05:9ab7/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether 9a:c7:1b:30:e8:9a brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.0/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::98c7:1bff:fe30:e89a/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether 2a:2b:cb:fb:15:82 brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.1/25 brd 10.244.0.127 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::282b:cbff:fefb:1582/64 scope link
      valid_lft forever preferred_lft forever
6: veth06343057@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether ca:70:83:13:dc:ed brd ff:ff:ff:ff:ff:ff link-netns fb0f181f-7c3a-4fb6-8bf0-5a65d39486c1
   inet6 fe80::c870:83ff:fe13:dced/64 scope link
      valid_lft forever preferred_lft forever
7: veth8af17165@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether c6:a0:be:75:9b:d9 brd ff:ff:ff:ff:ff:ff link-netns c07346e6-33f5-4e80-ba5e-74f7487b5daa
   inet6 fe80::c4a0:beff:fe75:9bd9/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$

Exécutez la commande ip a sur le noeud de processus actif cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2.

[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 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
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:ac:7c brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.89.50/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 86327sec preferred_lft 86327sec
   inet6 fe80::17ff:fe00:ac7c/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:4c:0d brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.16/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::91eb:344e:829e:35de/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether aa:31:9f:d0:b3:3c brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.128/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::a831:9fff:fed0:b33c/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether b2:0d:c0:de:02:61 brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.129/25 brd 10.244.0.255 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::b00d:c0ff:fede:261/64 scope link
      valid_lft forever preferred_lft forever
6: vethb37e8987@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 7a:93:1d:2a:33:8c brd ff:ff:ff:ff:ff:ff link-netns ab3262ca-4a80-4b02-a39f-4209d003f148
   inet6 fe80::7893:1dff:fe2a:338c/64 scope link
      valid_lft forever preferred_lft forever
7: veth73a651ce@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether ae:e4:97:89:ba:6e brd ff:ff:ff:ff:ff:ff link-netns 9307bfbd-8165-46bf-916c-e1180b6cbd83
   inet6 fe80::ace4:97ff:fe89:ba6e/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$

Nous avons vérifié que toutes les adresses IP sont configurées sur la deuxième VNIC (ens5), nous pouvons créer le tableau suivant avec les informations.

Adresse IP ens3	ens3 GW	Adresse IP ens5	ens5 GW
10.0.112.134	10.0.64.1	10.0.3.30/27	10.0.3.1
10.0.66.97	10.0.64.1	10.0.3.15/27	10.0.3.1
10.0.73.242	10.0.64.1	10.0.3.14/27	10.0.3.1
10.0.89.50	10.0.64.1	10.0.3.16/27	10.0.3.1

L'image suivante présente un aperçu visuel de ce que nous avons configuré jusqu'à présent.

Tâche 6 : installation d'un meta-plugin CNI (Multus CNI) sur le noeud de processus actif

Multus CNI est un module d'extension d'interface réseau de conteneur (CNI) Kubernetes qui vous permet d'attacher plusieurs interfaces réseau à un pod.

Comment fonctionne Multus CNI

Acte en tant que meta-plugin : Multus ne fournit pas de mise en réseau lui-même, mais appelle d'autres plug-ins CNI.
Crée plusieurs interfaces réseau : chaque pod peut avoir plusieurs interfaces réseau en combinant plusieurs modules d'extension CNI (par exemple, Flannel, Calico, SR-IOV).
Utilise un fichier de configuration : le réseau principal est configuré à l'aide du CNI par défaut et des réseaux supplémentaires sont attachés en fonction d'une définition de ressource personnalisée (CRD).

Pourquoi nous avons besoin de Multus CNI

Isolement réseau multiple : utile pour les charges globales nécessitant des plans de gestion et de données distincts.
Mise en réseau haute performance : permet un accès matériel direct à l'aide de SR-IOV ou DPDK.
Multihébergement pour pods : prend en charge la virtualisation des fonctions réseau (NFV) et les cas d'utilisation Telco dans lesquels plusieurs interfaces réseau sont essentielles.

Tâche 6.1 : installation de Multus CNI à l'aide de la méthode d'installation légère

Connectez-vous via SSH à l'opérateur Kubernetes.
1. Exécutez la commande suivante pour cloner la bibliothèque Multus Git.
```
git clone https://github.com/k8snetworkplumbingwg/multus-cni.git && cd multus-cni
```
2. Exécutez la commande suivante pour installer l'ensemble de démons Multus à l'aide de la méthode d'installation fine.
```
kubectl apply -f deployments/multus-daemonset.yml && cd ..
```

Fonctionnement de l'ensemble de démon Multus

Démarre un ensemble de démon Multus, qui exécute un pod sur chaque noeud qui place un binaire Multus sur chaque noeud dans /opt/cni/bin.
Lit le premier fichier de configuration lexicographiquement (par ordre alphabétique) dans /etc/cni/net.d et crée un nouveau fichier de configuration pour Multus sur chaque noeud en tant que /etc/cni/net.d/00-multus.conf. Cette configuration est générée automatiquement et est basée sur la configuration réseau par défaut (qui est supposée être la première configuration alphabétique).
Crée un répertoire nommé /etc/cni/net.d/multus.d sur chaque noeud avec des informations d'authentification permettant à Multus d'accéder à l'API Kubernetes.

Tâche 6.2 : valider l'installation de Multus

Exécutez la commande suivante (sur l'opérateur Kubernetes) pour vérifier si l'ensemble de démon Multus est installé sur tous les noeuds de processus actifs.
```
kubectl get pods --all-namespaces | grep -i multus
```
Vous pouvez également vérifier si l'ensemble de démons Multus est installé sur les noeuds de processus actifs eux-mêmes.
1. Exécutez la commande ssh -i id_rsa opc@10.0.112.134 pour accéder au noeud de processus actif via SSH à l'aide de la commande suivante.
2. Exécutez la commande cd /etc/cni/net.d/ pour modifier le répertoire à l'aide de la commande suivante.
3. Exécutez la commande ls -l pour répertorier la sortie du répertoire à l'aide de la commande suivante.
4. Notez que les fichiers 00-multus.conf et multus.d sont répertoriés.
1. Exécutez la commande sudo more 00-multus.conf pour visualiser le contenu du fichier 00-multus.conf.
2. Notez le contenu du fichier 00-multus.conf.

Tâche 7 : connexion d'interfaces réseau aux pods

Dans cette tâche, nous allons mapper ou attacher une interface de conteneur à cette carte d'interface réseau virtuelle.

Pour attacher des interfaces supplémentaires aux pods, nous avons besoin d'une configuration pour que l'interface soit attachée.

Il est encapsulé dans la ressource personnalisée de type NetworkAttachmentDefinition.
Cette configuration est essentiellement une configuration CNI packagée en tant que ressource personnalisée.

Il existe plusieurs plugins CNI qui peuvent être utilisés aux côtés de Multus pour y parvenir. Pour plus d'informations, reportez-vous à Présentation des modules d'extension.

Dans l'approche décrite ici, l'objectif est de fournir une fonction virtuelle SR-IOV (VF) exclusivement pour un seul pod, afin que le pod puisse tirer parti des capacités sans interférence ni aucune couche entre les deux.
Pour accorder à un pod un accès exclusif à la VF, nous pouvons tirer parti du plugin host-device qui vous permet de déplacer l'interface dans l'espace de noms du pod afin qu'il y ait un accès exclusif. Pour plus d'informations, reportez-vous à la section host-device.

L'exemple suivant présente les objets NetworkAttachmentDefinition qui configurent l'interface ens5 secondaire qui a été ajoutée aux noeuds.

La configuration du module d'extension ipam détermine la façon dont les adresses IP sont gérées pour ces interfaces.
Dans cet exemple, comme nous voulons utiliser les mêmes adresses IP que celles qui ont été affectées aux interfaces secondaires par OCI, nous utilisons la configuration statique ipam avec les routages appropriés.
La configuration ipam prend également en charge d'autres méthodes telles que host-local ou dhcp pour des configurations plus flexibles.

Tâche 7.1 : Créer une définition de document joint réseau

NetworkAttachmentDefinition permet de configurer l'attachement réseau, par exemple l'interface secondaire du pod.

Il existe deux façons de configurer NetworkAttachmentDefinition :

NetworkAttachmentDefinition avec la configuration CNI JSON.
NetworkAttachmentDefinition avec le fichier de configuration CNI.

Remarque : dans ce tutoriel, nous allons utiliser la méthode à l'aide du fichier de configuration CNI.

Nous avons 4 noeuds de processus actif et chaque noeud de processus actif dispose d'une deuxième carte d'interface réseau virtuelle que nous mettrons en correspondance avec une interface sur un conteneur (pod).

Exécutez les commandes suivantes pour créer les fichiers de configuration CNI pour tous les noeuds de processus actif et les cartes d'interface réseau virtuelles correspondantes.

ens3	ens5	name	réseau	commande nano
10.0.112.134	10.0.3.30/27	sriov-vnic-1	10.0.3.0/27	`sudo nano sriov-vnic-1.yaml`
10.0.66.97	10.0.3.15/27	sriov-vnic-2	10.0.3.0/27	`sudo nano sriov-vnic-2.yaml`
10.0.73.242	10.0.3.14/27	sriov-vnic-3	10.0.3.0/27	`sudo nano sriov-vnic-3.yaml`
10.0.89.50	10.0.3.16/27	sriov-vnic-4	10.0.3.0/27	`sudo nano sriov-vnic-4.yaml`

Effectuez les étapes suivantes sur l'opérateur Kubernetes. Créez un fichier YAML pour le premier noeud de processus actif à l'aide de la commande sudo nano sriov-vnic-1.yaml.
- Assurez-vous que le nom est unique et descriptif. Dans cet exemple, nous utilisons sriov-vnic-1.
- Utilisez l'adresse IP du deuxième adaptateur que vous venez d'ajouter (ens5).
- Assurez-vous que dst network est également correct. Il s'agit du même sous-réseau que celui créé dans la tâche 3.2.
sriov-vnic-1.yaml:
```
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-1
spec:
config: '{
  "cniVersion": "0.3.1",
  "type": "host-device",
  "device": "ens5",
  "ipam": {
  "type": "static",
  "addresses": [
  {
  "address": "10.0.3.30/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'
```

Créez un fichier YAML pour le second noeud de processus actif à l'aide de la commande sudo nano sriov-vnic-2.yaml.

sriov-vnic-2.yaml:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-2
spec:
config: '{
  "cniVersion": "0.3.1",
  "type": "host-device",
  "device": "ens5",
  "ipam": {
  "type": "static",
  "addresses": [
  {
  "address": "10.0.3.15/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'

Créez un fichier YAML pour le troisième noeud de processus actif à l'aide de la commande sudo nano sriov-vnic-3.yaml.

sriov-vnic-3.yaml:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-3
spec:
config: '{
  "cniVersion": "0.3.1",
  "type": "host-device",
  "device": "ens5",
  "ipam": {
  "type": "static",
  "addresses": [
  {
  "address": "10.0.3.14/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'

Créez un fichier YAML pour le quatrième noeud de processus actif à l'aide de la commande sudo nano sriov-vnic-4.yaml.

sriov-vnic-4.yaml:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-4
spec:
config: '{
  "cniVersion": "0.3.1",
  "type": "host-device",
  "device": "ens5",
  "ipam": {
  "type": "static",
  "addresses": [
  {
  "address": "10.0.3.16/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'

Appliquez NetworkAttachmentDefinition aux noeuds de processus actif.
- Exécutez la commande kubectl apply -f sriov-vnic-1.yaml pour le premier noeud.
- Exécutez la commande kubectl apply -f sriov-vnic-2.yaml pour le deuxième noeud.
- Exécutez la commande kubectl apply -f sriov-vnic-3.yaml pour le troisième noeud.
- Exécutez la commande kubectl apply -f sriov-vnic-4.yaml pour le quatrième noeud.
Si l'élément NetworkAttachmentDefinition est correctement appliqué, un résultat similaire à celui de la sortie apparaît.
```
[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-1.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1 created
[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-2.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2 created
[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-3.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3 created
[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-4.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4 created
[opc@o-sqrtga ~]$
```

Exécutez la commande kubectl get network-attachment-definitions.k8s.cni.cncf.io pour vérifier si l'élément NetworkAttachmentDefinitions est appliqué correctement.

[opc@o-sqrtga ~]$ kubectl get network-attachment-definitions.k8s.cni.cncf.io
NAME           AGE
sriov-vnic-1   96s
sriov-vnic-2   72s
sriov-vnic-3   60s
sriov-vnic-4   48s
[opc@o-sqrtga ~]$

Exécutez la commande kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1 -o yaml pour obtenir l'élément NetworkAttachmentDefinition appliqué au premier noeud de processus actif.

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-1","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.30/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:03:55Z"
generation: 1
name: sriov-vnic-1
namespace: default
resourceVersion: "22915413"
uid: 2d529130-2147-4f49-9d78-4e5aa12aea62
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.30/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'

Exécutez la commande kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2 -o yaml pour obtenir l'élément NetworkAttachmentDefinition appliqué au deuxième noeud de processus actif.

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-2","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.15/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:04:19Z"
generation: 1
name: sriov-vnic-2
namespace: default
resourceVersion: "22915508"
uid: aec5740c-a093-43d3-bd6a-2209ee9e5c96
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.15/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'

Exécutez la commande kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3 -o yaml pour obtenir l'élément NetworkAttachmentDefinition appliqué au troisième noeud de processus actif.

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-3","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.14/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:04:31Z"
generation: 1
name: sriov-vnic-3
namespace: default
resourceVersion: "22915558"
uid: 91b970ff-328f-4b6b-a0d8-7cdd07d7bca3
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.14/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'

Exécutez la commande kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4 -o yaml pour obtenir l'élément NetworkAttachmentDefinition appliqué au quatrième noeud de processus actif.

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-4","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.16/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:04:43Z"
generation: 1
name: sriov-vnic-4
namespace: default
resourceVersion: "22915607"
uid: 383fd3f0-7e5e-46ec-9997-29cbc9a2dcea
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.16/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'
[opc@o-sqrtga ~]$

L'image suivante présente un aperçu visuel de ce que nous avons configuré jusqu'à présent.

Tâche 7.2 : créer des pods avec `NetworkDefinitionAttachment` attaché

Dans cette tâche, nous allons lier NetworkAttachmentDefinitions à un conteneur ou pod réel.

Dans le tableau suivant, nous avons créé un mapping sur le pod que nous voulons héberger sur le noeud de processus actif.

Adresse IP du noeud de processus actif (principal)	ens5	name	nom de pod	terminé
10.0.112.134	10.0.3.30/27	sriov-vnic-1	testpod1	YES
10.0.66.97	10.0.3.15/27	sriov-vnic-2	testpod2	YES
10.0.73.242	10.0.3.14/27	sriov-vnic-3	testpod3	YES
10.0.89.50	10.0.3.16/27	sriov-vnic-4	testpod4	YES

Tâche 7.3 : créer des pods avec affinité de noeud

Par défaut, Kubernetes décidera où les pods seront placés (noeud de travail). Dans cet exemple, cela n'est pas possible car une adresse NetworkAttachmentDefinition est liée à une adresse IP et cette adresse IP est liée à une carte d'interface réseau virtuelle et cette carte d'interface réseau virtuelle est liée à un noeud de processus actif spécifique. Nous devons donc nous assurer que les pods que nous créons se retrouveront sur le noeud de processus actif souhaité. Cette opération est requise lorsque nous attachons NetworkAttachmentDefinition à un pod.

Si nous ne le faisons pas, il se peut qu'un pod se retrouve sur un autre emplacement où l'adresse IP est disponible pour le pod. Par conséquent, le pod ne pourra pas communiquer à l'aide de l'interface compatible SR-IOV.

Obtenez tous les noeuds disponibles à l'aide de la commande kubectl get nodes.

[opc@o-sqrtga ~]$ kubectl get nodes
NAME           STATUS   ROLES   AGE   VERSION
10.0.112.134   Ready    node    68d   v1.30.1
10.0.66.97     Ready    node    68d   v1.30.1
10.0.73.242    Ready    node    68d   v1.30.1
10.0.89.50     Ready    node    68d   v1.30.1
[opc@o-sqrtga ~]$

Affectez un libellé au noeud de processus actif 1 à l'aide de la commande kubectl label node 10.0.112.134 node_type=testpod1.
Affectez un libellé au noeud de processus actif 2 à l'aide de la commande kubectl label node 10.0.66.97 node_type=testpod2.
Affectez un libellé au noeud de processus actif 3 à l'aide de la commande kubectl label node 10.0.73.242 node_type=testpod3.
Affectez un libellé au noeud de processus actif 4 à l'aide de la commande kubectl label node 10.0.89.50 node_type=testpod4.

[opc@o-sqrtga ~]$ kubectl label node 10.0.112.134 node_type=testpod1
node/10.0.112.134 labeled
[opc@o-sqrtga ~]$ kubectl label node 10.0.73.242 node_type=testpod3
node/10.0.73.242 labeled
[opc@o-sqrtga ~]$ kubectl label node 10.0.66.97 node_type=testpod2
node/10.0.66.97 labeled
[opc@o-sqrtga ~]$ kubectl label node 10.0.89.50 node_type=testpod4
node/10.0.89.50 labeled
[opc@o-sqrtga ~]$

L'image suivante présente un aperçu visuel de ce que nous avons configuré jusqu'à présent.

Créez un fichier YAML pour testpod1 à l'aide de la commande sudo nano testpod1-v2.yaml.

La section annotations dans laquelle nous lions NetworkAttachmentDefinition que nous avons créée précédemment (sriov-vnic-1) à ce pod de test.
La section spec:affinity:nodeAffinity permet de lier le pod de test à un noeud de processus actif spécifique portant le libellé testpod1.

sudo nano testpod1-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod1
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-1
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod1
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

Créez un fichier YAML pour testpod2 à l'aide de la commande sudo nano testpod2-v2.yaml.

La section annotations dans laquelle nous lions NetworkAttachmentDefinition que nous avons créée précédemment (sriov-vnic-2) à ce pod de test.
La section spec:affinity:nodeAffinity permet de lier le pod de test à un noeud de processus actif spécifique portant le libellé testpod2.

sudo nano testpod2-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod2
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-2
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod2
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

Créez un fichier YAML pour testpod3 à l'aide de la commande sudo nano testpod3-v2.yaml.

La section annotations dans laquelle nous lions NetworkAttachmentDefinition que nous avons créée précédemment (sriov-vnic-3) à ce pod de test.
La section spec:affinity:nodeAffinity permet de lier le pod de test à un noeud de processus actif spécifique portant le libellé testpod3.

sudo nano testpod3-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod3
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-3
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod3
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

Créez un fichier YAML pour testpod4 à l'aide de la commande sudo nano testpod4-v2.yaml.
- La section annotations dans laquelle nous lions NetworkAttachmentDefinition que nous avons créée précédemment (sriov-vnic-4) à ce pod de test.
- La section spec:affinity:nodeAffinity permet de lier le pod de test à un noeud de processus actif spécifique portant le libellé testpod4.
```
sudo nano testpod4-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod4
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-4
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod4
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]
```
- Créez le fichier testpod1 en appliquant le fichier YAML à l'aide de la commande kubectl apply -f testpod1-v2.yaml.
- Créez le fichier testpod2 en appliquant le fichier YAML à l'aide de la commande kubectl apply -f testpod2-v2.yaml.
- Créez le fichier testpod3 en appliquant le fichier YAML à l'aide de la commande kubectl apply -f testpod3-v2.yaml.
- Créez le fichier testpod4 en appliquant le fichier YAML à l'aide de la commande kubectl apply -f testpod4-v2.yaml.
```
[opc@o-sqrtga ~]$ kubectl apply -f testpod1-v2.yaml
pod/testpod1 created
[opc@o-sqrtga ~]$ kubectl apply -f testpod2-v2.yaml
pod/testpod2 created
[opc@o-sqrtga ~]$ kubectl apply -f testpod3-v2.yaml
pod/testpod3 created
[opc@o-sqrtga ~]$ kubectl apply -f testpod4-v2.yaml
pod/testpod4 created
[opc@o-sqrtga ~]$
```

Vérifiez si les pods de test sont créés à l'aide de la commande kubectl get pod. Tous les pods de test sont créés et ont le Running STATUS.

[opc@o-sqrtga ~]$ kubectl get pod
NAME                       READY   STATUS    RESTARTS   AGE
my-nginx-576c6b7b6-6fn6f   1/1     Running   3          40d
my-nginx-576c6b7b6-k9wwc   1/1     Running   3          40d
my-nginx-576c6b7b6-z8xkd   1/1     Running   6          40d
mysql-6d7f5d5944-dlm78     1/1     Running   12         35d
testpod1                   1/1     Running   0          2m29s
testpod2                   1/1     Running   0          2m17s
testpod3                   1/1     Running   0          2m5s
testpod4                   1/1     Running   0          111s
[opc@o-sqrtga ~]$

Vérifiez si testpod1 s'exécute sur le noeud de processus actif 10.0.112.134 avec le libellé testpod1 à l'aide de la commande kubectl get pod testpod1 -o wide.

[opc@o-sqrtga ~]$ kubectl get pod testpod1 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP           NODE           NOMINATED NODE   READINESS GATES
testpod1   1/1     Running   0          3m41s   10.244.1.6   10.0.112.134   <none>           <none>

Vérifiez si testpod2 s'exécute sur le noeud de processus actif 10.0.66.97 avec le libellé testpod2 à l'aide de la commande kubectl get pod testpod2 -o wide.

[opc@o-sqrtga ~]$ kubectl get pod testpod2 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP             NODE         NOMINATED NODE   READINESS GATES
testpod2   1/1     Running   0          3m33s   10.244.1.133   10.0.66.97   <none>           <none>

Vérifiez si testpod3 s'exécute sur le noeud de processus actif 10.0.73.242 avec le libellé testpod3 à l'aide de la commande kubectl get pod testpod3 -o wide.

[opc@o-sqrtga ~]$ kubectl get pod testpod3 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP           NODE          NOMINATED NODE   READINESS GATES
testpod3   1/1     Running   0          3m25s   10.244.0.5   10.0.73.242   <none>           <none>

Vérifiez si testpod4 s'exécute sur le noeud de processus actif 10.0.89.50 avec le libellé testpod4 à l'aide de la commande kubectl get pod testpod4 -o wide.

[opc@o-sqrtga ~]$ kubectl get pod testpod4 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP             NODE         NOMINATED NODE   READINESS GATES
testpod4   1/1     Running   0          3m22s   10.244.0.133   10.0.89.50   <none>           <none>

L'image suivante présente un aperçu visuel de ce que nous avons configuré jusqu'à présent.

Tâche 7.4 : vérification de l'adresse IP sur les pods de test

Vérifiez l'adresse IP de testpod1 pour l'interface de pod net1 à l'aide de la commande kubectl exec -it testpod1 -- ip addr show.

Notez que l'adresse IP de l'interface net1 est 10.0.3.30/27.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 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
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether ca:28:e4:5f:66:c4 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.0.132/25 brd 10.244.0.255 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::c828:e4ff:fe5f:66c4/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:4c:0d brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.30/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:4c0d/64 scope link
	valid_lft forever preferred_lft forever

Vérifiez l'adresse IP de testpod2 pour l'interface de pod net1 à l'aide de la commande kubectl exec -it testpod2 -- ip addr show.

Notez que l'adresse IP de l'interface net1 est 10.0.3.15/27.

[opc@o-sqrtga ~]$ kubectl exec -it testpod2 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 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
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether da:ce:84:22:fc:29 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.1.132/25 brd 10.244.1.255 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::d8ce:84ff:fe22:fc29/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:7b:4f brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.15/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:7b4f/64 scope link
	valid_lft forever preferred_lft forever

Vérifiez l'adresse IP de testpod3 pour l'interface de pod net1 à l'aide de la commande kubectl exec -it testpod3 -- ip addr show.

Notez que l'adresse IP de l'interface net1 est 10.0.3.14/27.

[opc@o-sqrtga ~]$ kubectl exec -it testpod3 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 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
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether de:f2:81:10:04:b2 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.0.4/25 brd 10.244.0.127 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::dcf2:81ff:fe10:4b2/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:b7:51 brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.14/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:b751/64 scope link
	valid_lft forever preferred_lft forever

Vérifiez l'adresse IP de testpod4 pour l'interface de pod net1 à l'aide de la commande kubectl exec -it testpod4 -- ip addr show.

Notez que l'adresse IP de l'interface net1 est 10.0.3.16/27.

[opc@o-sqrtga ~]$ kubectl exec -it testpod4 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 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
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether ea:63:eb:57:9c:99 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.1.5/25 brd 10.244.1.127 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::e863:ebff:fe57:9c99/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:d4:a2 brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.16/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:d4a2/64 scope link
	valid_lft forever preferred_lft forever
[opc@o-sqrtga ~]$

Le tableau suivant présente toutes les adresses IP des interfaces net1 pour tous les pods de test.

nom de pod	Adresse IP net1
testpod1	10.0.3.30/27
testpod2	10.0.3.15/27
testpod3	10.0.3.14/27
testpod4	10.0.3.16/27

Remarque : ces adresses IP se trouvent dans la même plage que le sous-réseau OCI créé dans la tâche 3 pour placer nos cartes d'interface réseau virtuelles compatibles SR-IOV.

Tâche 7.5 : vérifier l'adresse IP sur les noeuds de processus actif

Maintenant que les interfaces de pod de test net1 ont une adresse IP, notez que cette adresse IP était l'adresse IP de l'interface ens5 sur les noeuds de processus actif. Cette adresse IP est désormais déplacée de l'interface de noeud de processus actif ens5 vers l'interface de pod de test net1.

Accédez via SSH au premier noeud de processus actif à l'aide de la commande ssh -i id_rsa opc@10.0.112.134.

Obtenez les adresses IP de toutes les interfaces à l'aide de la commande ip a.
L'interface ens5 a été enlevée du noeud de processus actif.

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.112.134
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 20:42:19 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 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
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:59:58 brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.112.134/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82180sec preferred_lft 82180sec
	inet6 fe80::17ff:fe00:5958/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether 3a:b7:fb:e6:2e:cf brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.0/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::38b7:fbff:fee6:2ecf/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether de:35:f5:51:85:5d brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.1/25 brd 10.244.1.127 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::dc35:f5ff:fe51:855d/64 scope link
	valid_lft forever preferred_lft forever
6: veth1cdaac17@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 76:e2:92:ad:37:40 brd ff:ff:ff:ff:ff:ff link-netns 1935ba66-34cc-4468-8abb-f66add46d08b
	inet6 fe80::74e2:92ff:fead:3740/64 scope link
	valid_lft forever preferred_lft forever
7: vethbcd391ab@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 9a:9a:0f:d6:48:17 brd ff:ff:ff:ff:ff:ff link-netns 3f02d5fd-596e-4b9f-8a35-35f2f946901b
	inet6 fe80::989a:fff:fed6:4817/64 scope link
	valid_lft forever preferred_lft forever
8: vethc15fa705@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 3a:d2:c8:66:d1:0b brd ff:ff:ff:ff:ff:ff link-netns f581b7f2-cfa0-46eb-b0aa-37001a11116d
	inet6 fe80::38d2:c8ff:fe66:d10b/64 scope link
	valid_lft forever preferred_lft forever
9: vethc663e496@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 7e:0b:bb:5d:49:8c brd ff:ff:ff:ff:ff:ff link-netns d3993135-0f2f-4b06-b16d-31d659f8230d
	inet6 fe80::7c0b:bbff:fe5d:498c/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$ exit
logout
Connection to 10.0.112.134 closed.

Connectez-vous via SSH au deuxième noeud de processus actif à l'aide de la commande ssh -i id_rsa opc@10.0.66.97.

Obtenez les adresses IP de toutes les interfaces à l'aide de la commande ip a.
L'interface ens5 a été enlevée du noeud de processus actif.

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.66.97
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 19:47:55 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 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
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:16:ca brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.66.97/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82502sec preferred_lft 82502sec
	inet6 fe80::17ff:fe00:16ca/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether 02:92:e7:f5:8e:29 brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.128/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::92:e7ff:fef5:8e29/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether f6:08:06:e2:bc:9d brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.129/25 brd 10.244.1.255 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::f408:6ff:fee2:bc9d/64 scope link
	valid_lft forever preferred_lft forever
6: veth5db97290@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether c2:e0:b5:7e:ce:ed brd ff:ff:ff:ff:ff:ff link-netns 3682b5cd-9039-4931-aecc-b50d46dabaf1
	inet6 fe80::c0e0:b5ff:fe7e:ceed/64 scope link
	valid_lft forever preferred_lft forever
7: veth6fd818a5@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 3e:a8:7d:84:d3:b9 brd ff:ff:ff:ff:ff:ff link-netns 08141d6b-5ec0-4f3f-a312-a00b30f82ade
	inet6 fe80::3ca8:7dff:fe84:d3b9/64 scope link
	valid_lft forever preferred_lft forever
8: veth26f6b686@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether ae:bf:36:ca:52:cf brd ff:ff:ff:ff:ff:ff link-netns f533714a-69be-4b20-be30-30ba71494f7a
	inet6 fe80::acbf:36ff:feca:52cf/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$ exit
logout
Connection to 10.0.66.97 closed.

Connectez-vous via SSH au troisième noeud de processus actif à l'aide de la commande ssh -i id_rsa opc@10.0.73.242.

Obtenez les adresses IP de toutes les interfaces à l'aide de la commande ip a.
L'interface ens5 a été enlevée du noeud de processus actif.

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.73.242
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 20:08:31 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 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
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:49:9c brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.73.242/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82733sec preferred_lft 82733sec
	inet6 fe80::17ff:fe00:499c/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether 9a:c7:1b:30:e8:9a brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.0/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::98c7:1bff:fe30:e89a/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether 2a:2b:cb:fb:15:82 brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.1/25 brd 10.244.0.127 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::282b:cbff:fefb:1582/64 scope link
	valid_lft forever preferred_lft forever
6: veth06343057@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether ca:70:83:13:dc:ed brd ff:ff:ff:ff:ff:ff link-netns fb0f181f-7c3a-4fb6-8bf0-5a65d39486c1
	inet6 fe80::c870:83ff:fe13:dced/64 scope link
	valid_lft forever preferred_lft forever
7: veth8af17165@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether c6:a0:be:75:9b:d9 brd ff:ff:ff:ff:ff:ff link-netns c07346e6-33f5-4e80-ba5e-74f7487b5daa
	inet6 fe80::c4a0:beff:fe75:9bd9/64 scope link
	valid_lft forever preferred_lft forever
8: veth170b8774@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether e6:c9:42:60:8f:e7 brd ff:ff:ff:ff:ff:ff link-netns edef0c81-0477-43fa-b260-6b81626e7d87
	inet6 fe80::e4c9:42ff:fe60:8fe7/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$ exit
logout
Connection to 10.0.73.242 closed.

Accédez au quatrième noeud de processus actif à l'aide de la commande ssh -i id_rsa opc@10.0.89.50.

Obtenez les adresses IP de toutes les interfaces à l'aide de la commande ip a.
L'interface ens5 a été enlevée du noeud de processus actif.

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.89.50
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 19:49:27 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 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
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:ac:7c brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.89.50/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82976sec preferred_lft 82976sec
	inet6 fe80::17ff:fe00:ac7c/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether aa:31:9f:d0:b3:3c brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.128/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::a831:9fff:fed0:b33c/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether b2:0d:c0:de:02:61 brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.129/25 brd 10.244.0.255 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::b00d:c0ff:fede:261/64 scope link
	valid_lft forever preferred_lft forever
6: vethb37e8987@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 7a:93:1d:2a:33:8c brd ff:ff:ff:ff:ff:ff link-netns ab3262ca-4a80-4b02-a39f-4209d003f148
	inet6 fe80::7893:1dff:fe2a:338c/64 scope link
	valid_lft forever preferred_lft forever
7: veth73a651ce@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether ae:e4:97:89:ba:6e brd ff:ff:ff:ff:ff:ff link-netns 9307bfbd-8165-46bf-916c-e1180b6cbd83
	inet6 fe80::ace4:97ff:fe89:ba6e/64 scope link
	valid_lft forever preferred_lft forever
8: veth42c3a604@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether f2:e6:ba:72:8f:b2 brd ff:ff:ff:ff:ff:ff link-netns a7eb561c-8182-49b2-9e43-7c52845620a7
	inet6 fe80::f0e6:baff:fe72:8fb2/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$ exit
logout
Connection to 10.0.89.50 closed.
[opc@o-sqrtga ~]$

L'image suivante présente un aperçu visuel de ce que nous avons configuré jusqu'à présent.

Tâche 8 : effectuer des tests ping entre plusieurs pods

Tous les pods ont une adresse IP du sous-réseau OCI auquel les cartes d'interface réseau virtuelles avec activation SR-IOV sont attachées. Nous pouvons effectuer des tests ping pour vérifier que la connectivité réseau fonctionne correctement.

Le tableau suivant fournit les commandes permettant de se connecter aux pods de test à partir de l'opérateur Kubernetes.

Nous devons effectuer une opération exec dans chaque pod pour effectuer un test ping ou examiner la table de routage.

ens3	net1	name	nom de pod	commande
10.0.112.134	10.0.3.30/27	sriov-vnic-1	testpod1	`kubectl exec -it testpod1 -- /bin/bash`
10.0.66.97	10.0.3.15/27	sriov-vnic-2	testpod2	`kubectl exec -it testpod2 -- /bin/bash`
10.0.73.242	10.0.3.14/27	sriov-vnic-3	testpod3	`kubectl exec -it testpod3 -- /bin/bash`
10.0.89.50	10.0.3.16/27	sriov-vnic-4	testpod4	`kubectl exec -it testpod4 -- /bin/bash`

Exécutez la commande kubectl exec -it testpod1 -- route -n pour consulter la table de routage directement à partir du terminal d'opérateur Kubernetes pour testpod1.

La table de routage de testpod1 dispose d'une passerelle par défaut pour eth0 et pour net1, notre interface compatible SR-IOV.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.0.129    0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      10.244.0.129    255.255.0.0     UG    0      0        0 eth0
10.244.0.128    0.0.0.0         255.255.255.128 U     0      0        0 eth0

Exécutez la commande kubectl exec -it testpod2 -- route -n pour consulter la table de routage directement à partir du terminal d'opérateur Kubernetes pour testpod2.

La table de routage de testpod2 dispose d'une passerelle par défaut pour eth0 et pour net1, notre interface compatible SR-IOV.

[opc@o-sqrtga ~]$ kubectl exec -it testpod2 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.1.129    0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      10.244.1.129    255.255.0.0     UG    0      0        0 eth0
10.244.1.128    0.0.0.0         255.255.255.128 U     0      0        0 eth0

Exécutez la commande kubectl exec -it testpod3 -- route -n pour consulter la table de routage directement à partir du terminal d'opérateur Kubernetes pour testpod3.

La table de routage de testpod3 dispose d'une passerelle par défaut pour eth0 et pour net1, notre interface compatible SR-IOV.

[opc@o-sqrtga ~]$ kubectl exec -it testpod3 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.0.1      0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      0.0.0.0         255.255.255.128 U     0      0        0 eth0
10.244.0.0      10.244.0.1      255.255.0.0     UG    0      0        0 eth0

Exécutez la commande kubectl exec -it testpod4 -- route -n pour consulter la table de routage directement à partir du terminal d'opérateur Kubernetes pour testpod4.

La table de routage de testpod4 dispose d'une passerelle par défaut pour eth0 et pour net1, notre interface compatible SR-IOV.

[opc@o-sqrtga ~]$ kubectl exec -it testpod4 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.1.1      0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      10.244.1.1      255.255.0.0     UG    0      0        0 eth0
10.244.1.0      0.0.0.0         255.255.255.128 U     0      0        0 eth0
[opc@o-sqrtga ~]$

Pour effectuer le test ping à partir de l'opérateur Kubernetes directement à partir des pods de test, nous avons besoin de la commande ping.

Dans le tableau suivant, nous avons fourni toutes les commandes ping pour tous les pods de test. La commande envoie une commande ping d'un pod de test particulier à tous les autres pods de test, y compris son adresse IP net1.

Nom du pod source	commande
testpod1	`kubectl exec -it testpod1 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod1 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod1 -- ping -I net1 10.0.3.14 -c 4` `kubectl exec -it testpod1 -- ping -I net1 10.0.3.16 -c 4`
testpod2	`kubectl exec -it testpod2 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod2 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod2 -- ping -I net1 10.0.3.14 -c 4` `kubectl exec -it testpod2 -- ping -I net1 10.0.3.16 -c 4`
testpod3	`kubectl exec -it testpod3 -- ping -I net1 10.0.3.14 -c 4` `kubectl exec -it testpod3 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod3 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod3 -- ping -I net1 10.0.3.16 -c 4`
testpod4	`kubectl exec -it testpod4 -- ping -I net1 10.0.3.16 -c 4` `kubectl exec -it testpod4 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod4 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod4 -- ping -I net1 10.0.3.14 -c 4`

Remarque : dans cet exemple, nous utilisons testpod1 pour envoyer une commande ping à toutes les autres adresses IP net1 des pods de test.

Exécutez la commande kubectl exec -it testpod1 -- ping -I net1 10.0.3.30 -c 4 pour envoyer la commande ping de testpod1 vers testpod1.

Le ping comporte 4 packets transmitted, 4 received, 0% packet loss. Donc le ping est réussi.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.30 -c 4
PING 10.0.3.30 (10.0.3.30) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.30: icmp_seq=1 ttl=64 time=0.043 ms
64 bytes from 10.0.3.30: icmp_seq=2 ttl=64 time=0.024 ms
64 bytes from 10.0.3.30: icmp_seq=3 ttl=64 time=0.037 ms
64 bytes from 10.0.3.30: icmp_seq=4 ttl=64 time=0.026 ms

--- 10.0.3.30 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3087ms
rtt min/avg/max/mdev = 0.024/0.032/0.043/0.009 ms

Exécutez la commande kubectl exec -it testpod1 -- ping -I net1 10.0.3.15 -c 4 pour envoyer la commande ping de testpod1 vers testpod2.

Le ping comporte 4 packets transmitted, 4 received, 0% packet loss. Donc le ping est réussi.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.15 -c 4
PING 10.0.3.15 (10.0.3.15) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.15: icmp_seq=1 ttl=64 time=0.383 ms
64 bytes from 10.0.3.15: icmp_seq=2 ttl=64 time=0.113 ms
64 bytes from 10.0.3.15: icmp_seq=3 ttl=64 time=0.114 ms
64 bytes from 10.0.3.15: icmp_seq=4 ttl=64 time=0.101 ms

--- 10.0.3.15 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3109ms
rtt min/avg/max/mdev = 0.101/0.177/0.383/0.119 ms

Exécutez la commande kubectl exec -it testpod1 -- ping -I net1 10.0.3.14 -c 4 pour envoyer la commande ping de testpod1 vers testpod3.

Le ping comporte 4 packets transmitted, 4 received, 0% packet loss. Donc le ping est réussi.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.14 -c 4
PING 10.0.3.14 (10.0.3.14) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.14: icmp_seq=1 ttl=64 time=0.399 ms
64 bytes from 10.0.3.14: icmp_seq=2 ttl=64 time=0.100 ms
64 bytes from 10.0.3.14: icmp_seq=3 ttl=64 time=0.130 ms
64 bytes from 10.0.3.14: icmp_seq=4 ttl=64 time=0.124 ms

--- 10.0.3.14 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3057ms
rtt min/avg/max/mdev = 0.100/0.188/0.399/0.122 ms

Exécutez la commande kubectl exec -it testpod1 -- ping -I net1 10.0.3.16 -c 4 pour envoyer la commande ping de testpod1 vers testpod4.

Le ping comporte 4 packets transmitted, 4 received, 0% packet loss. Donc le ping est réussi.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.16 -c 4
PING 10.0.3.16 (10.0.3.16) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.16: icmp_seq=1 ttl=64 time=0.369 ms
64 bytes from 10.0.3.16: icmp_seq=2 ttl=64 time=0.154 ms
64 bytes from 10.0.3.16: icmp_seq=3 ttl=64 time=0.155 ms
64 bytes from 10.0.3.16: icmp_seq=4 ttl=64 time=0.163 ms

--- 10.0.3.16 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3110ms
rtt min/avg/max/mdev = 0.154/0.210/0.369/0.092 ms
[opc@o-sqrtga ~]$

Remarque : nous n'avons pas inclus toutes les autres sorties ping pour tous les autres pods de test, mais vous avez une idée.

L'image suivante présente un aperçu visuel de ce que nous avons configuré jusqu'à présent.

Tâche 9 : (Facultatif) Déployer des pods avec plusieurs interfaces

Jusqu'à présent, nous n'avons préparé qu'une seule carte d'interface réseau virtuelle (qui prend en charge SR-IOV) et avons déplacé cette carte dans un pod. Nous l'avons fait pour quatre dosettes de test différentes.

Et si nous voulons ajouter ou déplacer d'autres VNIC dans un pod particulier ? Vous devez répéter ces étapes :

Créez un sous-réseau OCI.
Créez une carte d'interface réseau virtuelle et affectez-lui l'adresse IP.
Créez un élément NetworkAttachmentDefinitions.
Mettez à jour le fichier YAML du pod de test en ajoutant de nouvelles annotations.

Dans cette tâche, vous trouverez un exemple dans lequel nous allons créer un sous-réseau supplémentaire, la carte d'interface réseau virtuelle, affecter l'adresse IP, NetworkAttachmentDefinition et l'ajouter au fichier YAML de création de pod pour testpod1.

Il s'agit de NetworkAttachmentDefinition pour une nouvelle interface ens6 avec une adresse IP 10.0.4.29/27 sur le réseau 10.0.4.0/27.

Notez qu'il s'agit d'un autre NetworkAttachmentDefinition que celui que nous avions précédemment pour l'interface ens5 avec une adresse IP 10.0.3.30/27 sur le réseau 10.0.3.0/27.

sriov-vnic-2-new.yaml:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-2-new
spec:
config: '{
		"cniVersion": "0.3.1",
		"type": "host-device",
		"device": "ens6",
		"ipam": {
				"type": "static",
				"addresses": [
					{
						"address": "10.0.4.29/27",
						"gateway": "0.0.0.0"
					}
				],
				"routes": [
					{ "dst": "10.0.4.0/27", "gw": "0.0.0.0" }
				]
			}
		}'

Il s'agit du fichier YAML (mis à jour) pour testpod1.

Notez la ligne supplémentaire dans le fichier annotations où le nouveau fichier NetworkAttachmentDefinition ; sriov-vnic-2-new est référencé.

sudo nano testpod1-v3.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod1
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-1
	k8s.v1.cni.cncf.io/networks: sriov-vnic-2-new
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod1
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

Tâche 10 : enlever tous les déploiements de pod et `NetworkAttachmentDefinitions`

Pour recommencer ou nettoyer les conteneurs à l'aide de NetworkAttachmentDefinitions, procédez comme suit :

Obtenez tous les pods à l'aide de la commande kubectl get pod.

[opc@o-sqrtga ~]$ kubectl get pod
NAME                       READY   STATUS    RESTARTS   AGE
my-nginx-576c6b7b6-6fn6f   1/1     Running   3          105d
my-nginx-576c6b7b6-k9wwc   1/1     Running   3          105d
my-nginx-576c6b7b6-z8xkd   1/1     Running   6          105d
mysql-6d7f5d5944-dlm78     1/1     Running   12         100d
testpod1                   1/1     Running   0          64d
testpod2                   1/1     Running   0          64d
testpod3                   1/1     Running   0          64d
testpod4                   1/1     Running   0          64d
[opc@o-sqrtga ~]$

Supprimez les pods de test à l'aide des commandes suivantes.

kubectl delete -f testpod1-v2.yaml

kubectl delete -f testpod2-v2.yaml

kubectl delete -f testpod3-v2.yaml

kubectl delete -f testpod4-v2.yaml

Obtenez toutes les valeurs NetworkAttachmentDefinitions à l'aide de la commande kubectl get network-attachment-definitions.k8s.cni.cncf.io.

[opc@o-sqrtga ~]$ kubectl get network-attachment-definitions.k8s.cni.cncf.io
NAME           AGE
sriov-vnic-1   64d
sriov-vnic-2   64d
sriov-vnic-3   64d
sriov-vnic-4   64d
[opc@o-sqrtga ~]$

Supprimez NetworkAttachmentDefinitions avec les commandes suivantes.

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4

Configurer les interfaces SR-IOV pour les pods à l'aide des noeuds Oracle Container Engine for Kubernetes basés sur Multus for VM

Accusés de réception

Auteur - Iwan Hoogendoorn (spécialiste réseau OCI)

Ressources de formation supplémentaires

Explorez d'autres ateliers sur le site docs.oracle.com/learn ou accédez à d'autres contenus d'apprentissage gratuits sur le canal Oracle Learning YouTube. En outre, visitez le site education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

Pour obtenir de la documentation sur le produit, consultez Oracle Help Center.

Informations relatives au titre et au copyright

Deploy SR-IOV Enabled Network Interfaces Container Apps on OKE Using Multus CNI Plugin

G28056-02

Déployer des applications de conteneur d'interfaces réseau compatibles SR-IOV sur OKE à l'aide du module d'extension Multus CNI

Introduction

Objectifs

Tâche 1 : déploiement d'OKE avec un bastion, un opérateur, trois noeuds VM Worker et le module d'extension CNI Flannel

Tâche 2 : activer la mise en réseau SR-IOV (aide au matériel) sur chaque noeud de processus actif

Tâche 3 : création d'un sous-réseau pour les cartes d'interface réseau virtuelles compatibles SR-IOV

Tâche 3.1 : créer une liste de sécurité

Tâche 3.2 : création d'un sous-réseau

Tâche 4 : ajouter un deuxième attachement de carte d'interface réseau virtuelle

Tâche 4.1 : création d'un groupe de sécurité réseau

Tâche 4.2 : ajouter la carte d'interface réseau virtuelle

Tâche 5 : affectation d'une adresse IP à la nouvelle deuxième carte d'interface réseau virtuelle avec une passerelle par défaut

Tâche 5.1 : vérifier tous les noeuds du pool de noeuds 1 (np1)

Tâche 5.2 : vérifier tous les noeuds du pool de noeuds 2 (np2)

Tâche 6 : installation d'un meta-plugin CNI (Multus CNI) sur le noeud de processus actif

Tâche 6.1 : installation de Multus CNI à l'aide de la méthode d'installation légère

Tâche 6.2 : valider l'installation de Multus

Tâche 7 : connexion d'interfaces réseau aux pods

Tâche 7.1 : Créer une définition de document joint réseau

Tâche 7.2 : créer des pods avec NetworkDefinitionAttachment attaché

Tâche 7.3 : créer des pods avec affinité de noeud

Tâche 7.4 : vérification de l'adresse IP sur les pods de test

Tâche 7.5 : vérifier l'adresse IP sur les noeuds de processus actif

Tâche 8 : effectuer des tests ping entre plusieurs pods

Tâche 9 : (Facultatif) Déployer des pods avec plusieurs interfaces

Tâche 10 : enlever tous les déploiements de pod et NetworkAttachmentDefinitions

Liens connexes

Accusés de réception

Ressources de formation supplémentaires

Tâche 5.1 : vérifier tous les noeuds du pool de noeuds 1 (`np1`)

Tâche 5.2 : vérifier tous les noeuds du pool de noeuds 2 (`np2`)

Tâche 7.2 : créer des pods avec `NetworkDefinitionAttachment` attaché

Tâche 10 : enlever tous les déploiements de pod et `NetworkAttachmentDefinitions`