Déployer les applications conteneur d'interfaces réseau SR-IOV sur OKE à l'aide du plugiciel Multus CNI
Présentation
Dans ce tutoriel, nous allons explorer comment déployer des applications en conteneur sur des noeuds de travail d'instance virtuelle dans Oracle Cloud Infrastructure Kubernetes Engine (OKE), en tirant parti des capacités de réseau avancées. Plus précisément, nous activerons la virtualisation à E/S racine unique (SR-IOV) pour les interfaces réseau de conteneur et configurerons le plugiciel Multus CNI pour activer le réseau multi-hôte pour vos conteneurs.
En combinant SR-IOV et Multus, vous pouvez réaliser un réseau haute performance à faible latence pour des charges de travail spécialisées telles que l'IA, l'apprentissage automatique et le traitement de données en temps réel. Ce tutoriel fournit des instructions étape par étape pour configurer votre environnement OKE, déployer des noeuds de travail avec des interfaces activées pour SR-IOV et utiliser Multus CNI pour gérer plusieurs interfaces réseau dans vos pods. Que vous cherchiez à traiter des paquets à grande 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.
Note :
- Au moment 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'une grappe OKE avec le plugiciel CNI Multus.
- Dans ce tutoriel, nous allons vous montrer comment utiliser une interface SR-IOV activée dans un pod s'exécutant sur des pods ou des conteneurs sur une instance virtuelle faisant partie d'une grappe OKE en déplaçant le Cartes d'interface de réseau virtuel (VNIC) (qui se trouve sur une instance virtuelle) dans un pod et est utilisable à l'aide du plugiciel Multus CNI (où le plugiciel SR-IOV CNI n'est pas utilisé du tout).
- Le plugiciel CNI SR-IOV est pris en charge sur une instance sans système d'exploitation qui fait partie d'une grappe OKE avec le plugiciel CNI Multus. Ceci est hors de portée pour ce tutoriel.
Objectifs
- Déployez des applications conteneur sur des noeuds de travail d'instance virtuelle dans OKE avec des interfaces réseau activées pour SR-IOV à l'aide du plugiciel CNI Multus.
Tâche 1 : Déployer OKE avec un hôte bastion, un opérateur, trois noeuds de travail de machine virtuelle et le plugiciel CNI Flannel
Assurez-vous que OKE est déployé avec la configuration suivante :
- Hôte bastion
- Opérateur
- 3 noeuds de travail de machine virtuelle
- Flannel CNI Plugin
Cette configuration est détaillée dans le tutoriel ici : Déployer une grappe Kubernetes avec Terraform à l'aide d'Oracle Cloud Infrastructure Kubernetes Engine.
L'image suivante présente un aperçu visuel des composants que nous allons utiliser tout au long de ce tutoriel.
Tâche 2 : Activer le réseau SR-IOV (assistance matérielle) sur chaque noeud de travail
Note : Les étapes suivantes doivent être effectuées sur tous les noeuds de travail qui font partie de la grappe OKE.
L'image suivante présente un aperçu visuel de nos noeuds de travail dans la grappe OKE que nous allons utiliser tout au long de ce tutoriel.
Activer SR-IOV sur l'instance
-
Connectez-vous avec SSH à l'instance ou au noeud de travail.
- Exécutez la commande
lspci
pour vérifier quel pilote de réseau est actuellement utilisé sur toutes les cartes vNIC. - Notez que le pilote de réseau
Virtio
est utilisé.
- Allez à la page Détails de l'instance dans la console OCI.
- Faire défiler vers le bas.
- Notez que le type d'attachement de carte réseau est maintenant PARAVIRTUALISÉ.
- Allez à la page Détails de l'instance dans la console OCI.
- Cliquez sur Actions supplémentaires.
- Cliquez sur Modifier.
- Exécutez la commande
-
Cliquez sur Voir les options avancées.
- Cliquez sur Options de lancement et sélectionnez Réseau assisté par matériel (SR-IOV) comme type de réseau.
- Cliquez sur enregistrer les modifications.
-
Cliquez sur Redémarrer l'instance pour confirmer le redémarrage de l'instance.
-
Notez que le statut de l'instance est passé à STOPPING.
-
Notez que le statut de l'instance est passé à STARTING.
-
Notez que le statut de l'instance est passé à RUNNING.
- Faire défiler vers le bas.
- Notez que le type d'attachement de carte d'interface réseau est maintenant VFIO.
-
L'image suivante présente un aperçu visuel de ce que nous avons configuré jusqu'à présent.
Tâche 3 : Créer un sous-réseau pour les cartes vNIC SR-IOV activées
Nous allons créer un sous-réseau dédié que nos interfaces 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éé.
-
Allez à la console OCI.
- Naviguez jusqu'à Réseaux en nuage virtuels.
- Cliquez sur le VCN existant.
- Cliquez sur Listes de sécurité.
- Cliquez sur Créer une liste de sécurité.
-
Pour la règle de trafic entrant 1, entrez les informations suivantes.
- Entrez un nom.
- Sélectionnez un CIDR comme type de source.
- Entrez
0.0.0.0/0
comme CIDR source. - Sélectionnez Tous les protocoles comme protocole IP.
- Faire défiler vers le bas.
- Pour Règle de trafic sortant 1, entrez les informations suivantes.
- Sélectionnez un CIDR comme type de source.
- Entrez
0.0.0.0/0
comme CIDR source. - Sélectionnez Tous les protocoles comme protocole IP.
- 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éer un sous-réseau
-
Accédez à la page Détails du réseau en nuage virtuel.
- Cliquez sur sous-réseaux.
- Notez les sous-réseaux existants qui sont déjà créés pour l'environnement OKE.
- Cliquez sur Créer un sous-réseau.
- Entrez un nom.
- Entrer un bloc IPv4 CIDR.
- Faire défiler vers le bas.
- Sélectionnez Sous-réseau privé.
- Faire défiler vers le bas.
- Sélectionnez Options DHCP par défaut pour Options DHCP.
- Sélectionnez Liste de sécurité créée dans la tâche 3.1.
- Cliquez sur Créer un sous-réseau.
-
Notez que le sous-réseau net est créé.
Note :
- Le sous-réseau lui-même ne comporte aucun composant technique SR-IOV activé.
- 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 VNIC
L'image suivante présente un aperçu visuel de la façon dont les noeuds de travail ont une seule carte VNIC connectée au sous-réseau des noeuds de travail avant d'ajouter une deuxième carte VNIC.
Avant d'ajouter un deuxième attachement de carte VNIC aux noeuds de travail, créez un groupe de sécurité de réseau.
Tâche 4.1 : Créer un groupe de sécurité de réseau
Nous utilisons déjà un groupe de sécurité de réseau pour les autres cartes VNIC, mais nous avons également besoin d'un groupe dédié pour la nouvelle carte VNIC que nous ajouterons à une instance virtuelle existante qui fait partie de la grappe OKE et qui jouera son rôle de noeud de travail Kubernetes. Cette interface sera une carte VNIC pour laquelle SR-IOV est activé.
-
Accédez à la page Détails du réseau en nuage virtuel.
- Naviguez jusqu'à Groupes de sécurité de réseau.
- Cliquez sur Créer un groupe de sécurité de réseau.
-
Ajoutez les règles suivantes.
- Entrant :
- Autoriser le type de source : Sélectionnez CIDR.
- Source : Entrez
0.0.0.0/0
. - Destination : Laissez la destination vide.
- Protocole : Autorisez tous les protocoles.
- Trafic sortant :
- Autoriser le type de source : Sélectionnez CIDR.
- Source : Laissez la source vide.
- Destination : Entrez
0.0.0.0/0
. - Protocole : Autorisez tous les protocoles.
- Entrant :
-
Notez que le groupe de sécurité de réseau est créé. Nous l'appliquerons à la nouvelle carte VNIC (secondaire) que nous créerons (sur chaque noeud de travail de la grappe OKE).
Tâche 4.2 : Ajouter la carte VNIC
-
Accédez à chaque instance de noeud de travail virtuel et ajoutez une deuxième carte VNIC à chaque noeud de travail.
- Naviguez jusqu'à chaque instance de noeud de travail virtuel et cliquez sur Cartes vNIC attachées.
- Notez qu'il existe déjà une carte VNIC.
- Cliquez sur Créer une carte VNIC pour ajouter une deuxième carte VNIC.
- Entrez un nom.
- Sélectionnez le VCN.
- Sélectionnez le sous-réseau créé dans la tâche 3.2.
- Sélectionnez Utiliser les groupes de sécurité de réseau pour contrôler le trafic.
- Sélectionnez le groupe de sécurité de réseau créé dans la tâche 4.1.
- Faire défiler vers le bas.
- Sélectionnez Affecter automatiquement une adresse IPv4 privée.
- Cliquez sur enregistrer les modifications.
-
Notez que la deuxième carte VNIC est créée et attachée à l'instance de noeud de travail virtuel, ainsi qu'à notre sous-réseau.
-
Connectez-vous avec SSH à l'instance ou au noeud de travail.
- Exécutez la commande
lspci
pour vérifier quel pilote de réseau est actuellement utilisé sur toutes les cartes vNIC. - Notez que le pilote de réseau Mellanox Technologies ConnectX Family mlx5Gen Virtual Function est utilisé.
Le pilote réseau Mellanox Technologies ConnectX Family mlx5Gen Virtual Function est le pilote Virtual Function (VF) utilisé par SR-IOV. Ainsi, la carte VNIC est activée pour SR-IOV avec un VF.
- Exécutez la commande
-
L'image suivante présente un aperçu visuel de ce que nous avons configuré jusqu'à présent.
Tâche 5 : Affecter une adresse IP à la nouvelle deuxième carte VNIC avec une passerelle par défaut
Maintenant que la deuxième carte VNIC 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'est pas activé pour la deuxième interface, l'adresse IP doit donc être affecté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) (
oci-utils
) pour affecter une adresse IP à la deuxième interface d'une instance de calcul OCI à l'aide de la commande OCI-network-config. -
Méthode 2 : Utilisez l'interface de ligne de commande OCI (ensemble
oci-utils
) pour affecter une adresse IP à la deuxième interface d'une instance de calcul OCI à l'aide du démon d'OCID. -
Méthode 3 : Utilisez le script OCI_Multi_VNIC_Setup.
-
Méthode 4 : Créez manuellement le fichier de configuration de l'interface pour la nouvelle carte VNIC dans le dossier
/etc/sysconfig/network-scripts/
.
Pour tous les noeuds de travail, nous avons affecté une adresse IP à la carte vNIC secondaire (ens5
). Nous avons utilisé la méthode 3 pour affecter une adresse IP à la carte vNIC secondaire (ens5
). Pour plus d'informations sur l'affectation d'une adresse IP à la deuxième carte VNIC, voir Affecter une adresse IP à une deuxième interface sur une instance Oracle Linux.
Une fois l'adresse IP affectée à une carte VNIC, nous devons vérifier si l'adresse IP des deuxièmes cartes VNIC est configurée correctement. Nous pouvons également vérifier si nous avons activé SR-IOV sur tous les noeuds de travail du groupe de noeuds.
Notre cluster OKE se compose de :
Groupe de noeuds | |
---|---|
NP1 | 1 x noeud de travail |
NP2 | 3 x noeuds de travail |
Nous vérifierons tous les noeuds de travail de tous les groupes de noeuds.
Tâche 5.1 : Vérifier tous les noeuds du groupe de noeuds 1 (np1
)
-
Dans la grappe OKE, cliquez sur Noeuds.
-
Cliquez sur le premier groupe de noeuds (
np1
). -
Cliquez sur le noeud de travail qui fait partie de ce groupe de noeuds.
- Notez que le type d'attachement de carte d'interface réseau est VFIO (cela signifie que SR-IOV est activé pour ce noeud de travail d'instance virtuelle).
- Notez que la deuxième carte VNIC est créée et attachée pour ce noeud de travail.
Tâche 5.2 : Vérifier tous les noeuds du groupe de noeuds 2 (np2
)
-
Cliquez sur les noeuds un par un et lancez la vérification.
- Notez que le type d'attachement de carte d'interface réseau est VFIO (cela signifie que SR-IOV est activé pour ce noeud de travail d'instance virtuelle).
- Notez que la deuxième carte VNIC est créée et attachée pour ce noeud de travail.
-
Allez à la page Sommaire du groupe de noeuds 2 (
np2
). Cliquez sur le deuxième noeud de travail du groupe de noeuds.- Notez que le type d'attachement de carte d'interface réseau est VFIO (cela signifie que SR-IOV est activé pour ce noeud de travail d'instance virtuelle).
- Notez que la deuxième carte VNIC est créée et attachée pour ce noeud de travail.
-
Allez à la page Sommaire du groupe de noeuds 2 (
np2
). Cliquez sur le troisième noeud de travail du groupe de noeuds.- Notez que le type d'attachement de carte d'interface réseau est VFIO (cela signifie que SR-IOV est activé pour ce noeud de travail d'instance virtuelle).
- Notez que la deuxième carte VNIC est créée et attachée pour ce noeud de travail.
-
Connectez-vous à l'aide de SSH à l'opérateur Kubernetes.
Exécutez la commande
kubectl get nodes
pour extraire une liste et des adresses IP de tous les noeuds de travail.[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'utilisation de SSH sur tous les noeuds de travail, nous avons créé le tableau suivant.
Nom du noeud de travail Adresse IP ens3 Nœud de travail de bande passante 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 utiliser SSH pour tous les noeuds de travail virtuels, assurez-vous que vous disposez de la clé privée appropriée.
- Exécutez la commande
ssh -i <private key> opc@<ip-address>
pour SSH sur tous les noeuds de travail.
-
Exécutez la commande
ip a
sur le noeud de travailcwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0
.Notez que lorsque l'adresse IP a été configurée avec succès,
ens5
(deuxième carte VNIC) a une adresse IP dans l'intervalle 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 travailcwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1
.Notez que lorsque l'adresse IP a été configurée,
ens5
(deuxième carte VNIC) a une adresse IP dans l'intervalle 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 travailcwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0
.Notez que lorsque l'adresse IP a été configurée,
ens5
(deuxième carte VNIC) a une adresse IP dans l'intervalle du sous-réseau créé dans la tâche 3.2 pour les interfaces SR-IOV.[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 travailcwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2
.Notez que lorsque l'adresse IP a été configurée,
ens5
(deuxième carte VNIC) a une adresse IP dans l'intervalle du sous-réseau créé dans la tâche 3.2 pour les interfaces SR-IOV.[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 carte 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 : Installer un CNI Meta-Plugin (Multus CNI) sur le noeud de travail
Multus CNI est un plugiciel d'interface réseau de conteneurs Kubernetes qui vous permet d'attacher plusieurs interfaces réseau à un pod.
Comment fonctionne Multus CNI
-
Agit en tant que méta-plugin : Multus ne fournit pas lui-même de réseau, mais appelle plutôt d'autres plugiciels CNI.
-
Crée plusieurs interfaces réseau : Chaque pod peut avoir plusieurs interfaces réseau en combinant plusieurs plugiciels 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 de réseau multiple : Utile pour les charges de travail qui nécessitent une gestion et des plans de données distincts.
-
Réseau haute performance : Active l'accès matériel direct à l'aide de SR-IOV ou DPDK.
-
Multi-Homing pour les pods : Prend en charge la virtualisation des fonctions de réseau (NFV) et les cas d'utilisation de Telco où plusieurs interfaces réseau sont essentielles.
Tâche 6.1 : Installer Multus CNI à l'aide de la méthode d'installation mince
-
Accédez par SSH à l'opérateur Kubernetes.
-
Exécutez la commande suivante pour cloner la bibliothèque Multus Git.
git clone https://github.com/k8snetworkplumbingwg/multus-cni.git && cd multus-cni
-
Exécutez la commande suivante pour installer le démon Multus défini à l'aide de la méthode d'installation fine.
kubectl apply -f deployments/multus-daemonset.yml && cd ..
-
Ce que fait le démon Multus
-
Démarre un jeu de démons Multus, ce 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 lexicographique (alphabétiquement) 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 pour que Multus puisse 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 valider si le jeu de démons Multus est installé sur tous les noeuds de travail.
kubectl get pods --all-namespaces | grep -i multus
-
Vous pouvez également vérifier si le démon Multus est installé sur les noeuds de travail eux-mêmes.
- Exécutez la commande
ssh -i id_rsa opc@10.0.112.134
pour accéder au noeud de travail par SSH avec la commande suivante. - Exécutez la commande
cd /etc/cni/net.d/
pour modifier le répertoire à l'aide de la commande suivante. - Exécutez la commande
ls -l
pour lister la sortie du répertoire avec la commande suivante. - Notez que les fichiers
00-multus.conf
etmultus.d
sont listés.
- Exécutez la commande
sudo more 00-multus.conf
pour voir le contenu du fichier00-multus.conf
. - Notez le contenu du fichier
00-multus.conf
.
- Exécutez la commande
Tâche 7 : Attacher des interfaces réseau à des pods
Dans cette tâche, nous mapperons ou attacherons une interface de conteneur à cette carte VNIC.
Pour attacher des interfaces supplémentaires aux pods, nous avons besoin d'une configuration pour attacher l'interface.
-
Ceci 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 avec Multus pour y parvenir. Pour plus d'informations, voir Aperçu des plugiciels.
-
Dans l'approche décrite ici, l'objectif est de fournir une fonction virtuelle SR-IOV (VF) exclusivement pour un seul pod, de sorte que le pod peut tirer parti des capacités sans interférence ou des couches intermédiaires.
-
Pour accorder à un pod un accès exclusif au VF, nous pouvons tirer parti du plug-in hôte-appareil 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, voir host-device.
L'exemple suivant présente les objets NetworkAttachmentDefinition
qui configurent l'interface ens5
secondaire ajoutée aux noeuds.
-
La configuration du plugiciel
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 qui ont été affectées aux interfaces secondaires par OCI, nous utilisons la configuration statique
ipam
avec les routes appropriées. -
La configuration
ipam
prend également en charge d'autres méthodes telles quehost-local
oudhcp
pour des configurations plus flexibles.
Tâche 7.1 : Créer une définition de fichier joint au réseau
NetworkAttachmentDefinition
est utilisé pour configurer l'attachement de réseau, par exemple, l'interface secondaire pour le pod.
Il existe deux façons de configurer NetworkAttachmentDefinition
:
NetworkAttachmentDefinition
avec configuration CNI JSON.NetworkAttachmentDefinition
avec le fichier de configuration CNI.
Note : Dans ce tutoriel, nous allons utiliser la méthode à l'aide du fichier de configuration CNI.
Nous avons 4 noeuds de travail et chaque noeud de travail a une deuxième carte VNIC que nous mapperons à une interface sur un conteneur (pod).
-
Exécutez les commandes suivantes pour créer les fichiers de configuration CNI pour tous les noeuds de travail et les cartes vNIC correspondantes.
ens3 ens5 nom 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 travail à 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 deuxième noeud de travail à 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 travail à 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 travail à 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 travail.- 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
NetworkAttachmentDefinition
est correctement appliqué, vous verrez quelque chose de similaire à la sortie.[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
-
Exécutez la commande
kubectl get network-attachment-definitions.k8s.cni.cncf.io
pour vérifier siNetworkAttachmentDefinitions
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 la valeurNetworkAttachmentDefinition
appliquée pour le premier noeud de travail.[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 la valeurNetworkAttachmentDefinition
appliquée au deuxième noeud de travail.[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 la valeurNetworkAttachmentDefinition
appliquée au troisième noeud de travail.[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 la valeurNetworkAttachmentDefinition
appliquée pour le quatrième noeud de travail.[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 un pod réel.
Dans le tableau suivant, nous avons créé un mappage sur le pod que nous voulons héberger sur le noeud de travail.
Adresse IP du noeud du travailleur (principal) | ens5 | nom | nom du module de service | terminé |
---|---|---|---|---|
10.0.112.134 | 10.0.3.30/27 | sriov-vnic-1 | testpod1 | OUI |
10.0.66.97 | 10.0.3.15/27 | sriov-vnic-2 | testpod2 | OUI |
10.0.73.242 | 10.0.3.14/27 | sriov-vnic-3 | testpod3 | OUI |
10.0.89.50 | 10.0.3.16/27 | sriov-vnic-4 | testpod4 | OUI |
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 NetworkAttachmentDefinition
est lié à une adresse IP et cette adresse IP est liée à une carte VNIC et cette carte VNIC est liée à un noeud de travail spécifique. Nous devons donc nous assurer que les pods que nous créons se retrouveront sur le noeud de travail que nous voulons et cela est requis lorsque nous attachons NetworkAttachmentDefinition
à un pod.
Si nous ne le faisons pas, il peut arriver qu'un pod se retrouve sur un autre endroit où l'adresse IP est disponible pour le pod. Par conséquent, le pod ne pourra pas communiquer à l'aide de l'interface SR-IOV activée.
-
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 une étiquette au noeud de travail 1 à l'aide de la commande
kubectl label node 10.0.112.134 node_type=testpod1
. - Affectez une étiquette au noeud de travail 2 à l'aide de la commande
kubectl label node 10.0.66.97 node_type=testpod2
. - Affectez une étiquette au noeud de travail 3 à l'aide de la commande
kubectl label node 10.0.73.242 node_type=testpod3
. - Affectez une étiquette au noeud de travail 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 ~]$
- Affectez une étiquette au noeud de travail 1 à l'aide de la commande
-
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 commandesudo nano testpod1-v2.yaml
.-
Notez la section
annotations
dans laquelle nous lionsNetworkAttachmentDefinition
que nous avons créé précédemment (sriov-vnic-1
) à ce pod de test. -
Notez la section
spec:affinity:nodeAffinity
dans laquelle nous lions le pod de test à un noeud de travail spécifique portant l'étiquettetestpod1
.
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 commandesudo nano testpod2-v2.yaml
.-
Notez la section
annotations
dans laquelle nous lionsNetworkAttachmentDefinition
que nous avons créé précédemment (sriov-vnic-2
) à ce pod de test. -
Notez la section
spec:affinity:nodeAffinity
dans laquelle nous lions le pod de test à un noeud de travail spécifique portant l'étiquettetestpod2
.
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 commandesudo nano testpod3-v2.yaml
.-
Notez la section
annotations
dans laquelle nous lionsNetworkAttachmentDefinition
que nous avons créé précédemment (sriov-vnic-3
) à ce pod de test. -
Notez la section
spec:affinity:nodeAffinity
dans laquelle nous lions le pod de test à un noeud de travail spécifique portant l'étiquettetestpod3
.
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 commandesudo nano testpod4-v2.yaml
.-
Notez la section
annotations
dans laquelle nous lionsNetworkAttachmentDefinition
que nous avons créé précédemment (sriov-vnic-4
) à ce pod de test. -
Notez la section
spec:affinity:nodeAffinity
dans laquelle nous lions le pod de test à un noeud de travail spécifique avec l'étiquettetestpod4
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
testpod1
en appliquant le fichier YAML à l'aide de la commandekubectl apply -f testpod1-v2.yaml
. - Créez
testpod2
en appliquant le fichier YAML à l'aide de la commandekubectl apply -f testpod2-v2.yaml
. - Créez
testpod3
en appliquant le fichier YAML à l'aide de la commandekubectl apply -f testpod3-v2.yaml
. - Créez
testpod4
en appliquant le fichier YAML à l'aide de la commandekubectl 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
. Notez que tous les pods de test sont créés et ont le statutRunning
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
est en cours d'exécution sur le noeud de travail10.0.112.134
avec l'étiquettetestpod1
à l'aide de la commandekubectl 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
est en cours d'exécution sur le noeud de travail10.0.66.97
avec l'étiquettetestpod2
à l'aide de la commandekubectl 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
est en cours d'exécution sur le noeud de travail10.0.73.242
avec l'étiquettetestpod3
à l'aide de la commandekubectl 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
est en cours d'exécution sur le noeud de travail10.0.89.50
avec l'étiquettetestpod4
à l'aide de la commandekubectl 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érifier l'adresse IP des pods de test
-
Vérifiez l'adresse IP de
testpod1
pour l'interface de podnet1
à l'aide de la commandekubectl exec -it testpod1 -- ip addr show
.Notez que l'adresse IP de l'interface
net1
est10.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 podnet1
à l'aide de la commandekubectl exec -it testpod2 -- ip addr show
.Notez que l'adresse IP de l'interface
net1
est10.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 podnet1
à l'aide de la commandekubectl exec -it testpod3 -- ip addr show
.Notez que l'adresse IP de l'interface
net1
est10.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 podnet1
à l'aide de la commandekubectl exec -it testpod4 -- ip addr show
.Notez que l'adresse IP de l'interface
net1
est10.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 un aperçu de toutes les adresses IP des interfaces
net1
pour tous les pods de test.nom du module de service 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 Note : Ces adresses IP se trouvent dans le même intervalle que le sous-réseau OCI créé dans la tâche 3 pour placer nos cartes vNIC SR-IOV activées.
Tâche 7.5 : Vérifier l'adresse IP sur les noeuds de travail
-
Maintenant que les interfaces
net1
des pods de test ont une adresse IP, notez que cette adresse IP était l'adresse IP de l'interfaceens5
sur les noeuds de travail. Cette adresse IP est maintenant déplacée de l'interface de noeud de travailens5
vers l'interface de pod de testnet1
. -
Accédez par SSH au premier noeud de travail à 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
. -
Notez que l'interface
ens5
a été supprimée du noeud de travail.
[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.
-
-
Accédez par SSH au deuxième noeud de travail à 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
. -
Notez que l'interface
ens5
a été supprimée du noeud de travail.
[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.
-
-
Accédez par SSH au troisième noeud de travail à 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
. -
Notez que l'interface
ens5
a été supprimée du noeud de travail.
[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 par SSH au quatrième noeud de travail à 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
. -
Notez que l'interface
ens5
a été supprimée du noeud de travail.
[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 vNIC SR-IOV sont attachées. Nous pouvons effectuer des tests ping pour vérifier si 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 avons besoin de
exec
dans chaque pod pour effectuer un test ping ou pour consulter la table de routage.ens3 net1 nom nom du module de service 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 de l'opérateur Kubernetes pourtestpod1
.Notez que la table de routage de
testpod1
comporte une passerelle par défaut poureth0
et pournet1
, qui est notre interface SR-IOV activée.[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 de l'opérateur Kubernetes pourtestpod2
.Notez que la table de routage de
testpod2
comporte une passerelle par défaut poureth0
et pournet1
, qui est notre interface SR-IOV activée.[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 de l'opérateur Kubernetes pourtestpod3
.Notez que la table de routage de
testpod3
comporte une passerelle par défaut poureth0
et pournet1
, qui est notre interface SR-IOV activée.[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 de l'opérateur Kubernetes pourtestpod4
.Notez que la table de routage de
testpod4
comporte une passerelle par défaut poureth0
et pournet1
, qui est notre interface SR-IOV activée.[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 effectuera une commande ping à partir d'un pod de test particulier vers 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
Note : Dans cet exemple, nous utilisons
testpod1
pour effectuer une commande ping sur toutes les autres adresses IPnet1
des pods de test.
-
Exécutez la commande
kubectl exec -it testpod1 -- ping -I net1 10.0.3.30 -c 4
pour effectuer une commande ping detestpod1
àtestpod1
.Notez que le ping contient
4 packets transmitted, 4 received, 0% packet loss
. 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 effectuer une commande ping detestpod1
àtestpod2
.Notez que le ping contient
4 packets transmitted, 4 received, 0% packet loss
. 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 effectuer une commande ping detestpod1
àtestpod3
.Notez que le ping contient
4 packets transmitted, 4 received, 0% packet loss
. 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 effectuer une commande ping detestpod1
àtestpod4
.Notez que le ping contient
4 packets transmitted, 4 received, 0% packet loss
. 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 ~]$
Note : Nous n'avons pas inclus toutes les autres sorties ping pour tous les autres pods de test, mais vous avez l'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 VNIC (qui prend en charge SR-IOV) et déplacé cette carte VNIC dans un pod. Nous l'avons fait pour quatre tests différents.
Que se passe-t-il maintenant si nous voulons ajouter ou déplacer plus de cartes vNIC dans un module de réseautage particulier? Vous devez répéter les étapes suivantes :
- Créez un sous-réseau OCI.
- Créez une nouvelle carte VNIC et affectez l'adresse IP.
- Créer une nouvelle
NetworkAttachmentDefinitions
. - Mettez à jour le fichier YAML du module de test en ajoutant de nouvelles annotations.
Dans cette tâche, vous trouverez un exemple où nous allons créer un sous-réseau supplémentaire, une carte VNIC, 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 interfaceens6
avec une adresse IP10.0.4.29/27
sur le réseau10.0.4.0/27
.Notez qu'il s'agit d'un autre
NetworkAttachmentDefinition
que nous avions précédemment pour l'interfaceens5
avec une adresse IP10.0.3.30/27
sur le réseau10.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
annotations
où le nouveauNetworkAttachmentDefinition
;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 : Supprimer tous les déploiements de pod et NetworkAttachmentDefinitions
Si vous voulez recommencer ou nettoyer les conteneurs avec 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 tous les éléments
NetworkAttachmentDefinitions
à l'aide de la commandekubectl 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
Liens connexes
Remerciements
- Auteur - Iwan Hoogendoorn (spécialiste du réseau OCI)
Ressources d'apprentissage supplémentaires
Explorez d'autres laboratoires sur le site docs.oracle.com/learn ou accédez à plus de contenu d'apprentissage gratuit sur le canal Oracle Learning YouTube. De plus, visitez education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.
Pour obtenir la documentation sur le produit, visitez Oracle Help Center.
Deploy SR-IOV Enabled Network Interfaces Container Apps on OKE Using Multus CNI Plugin
G28055-02
Copyright ©2025, Oracle and/or its affiliates.