Attachement de plusieurs cartes VNIC secondaires pour la mise en réseau de pods

Etape 1 : vérification des noms et de la capacité des ressources étendues sur un noeud

Une fois que le pool de noeuds comporte des noeuds de processus actif, vérifiez les noms et la capacité des ressources étendues sur un noeud.

1. Consultez les ressources étendues annoncées du noeud :

   kubectl describe node <node-name>

2. Dans la section Capacity de la sortie, identifiez les ressources étendues qui correspondent aux ressources d'application (par exemple, oke-application-resource.oci.oraclecloud.com/frontend) et confirmez qu'elles ont une capacité différente de zéro.

Les noeuds qui exposent les ressources d'application sont endommagés par oci.oraclecloud.com/application-resource-only:NoSchedule afin d'empêcher les pods qui n'ont pas de demandes de ressources d'application explicites de se poser dessus.

Ajoutez une tolérance correspondante à la spécification de pod (sur spec.tolerations pour un pod ou sur spec.template.spec.tolerations dans un déploiement) :

tolerations:
  - key: "oci.oraclecloud.com/application-resource-only"
    operator: "Exists"
    effect: "NoSchedule"

Sans cette tolérance, le planificateur rejettera le placement même s'il existe une capacité de ressource.

Dans la spécification de pod, demandez la ressource étendue qui correspond au profil de carte d'interface réseau virtuelle secondaire que le pod doit utiliser (par exemple, dans un déploiement sur spec.template.spec.containers[].resources). Demandez et limitez exactement une unité afin que le planificateur réserve la capacité de manière cohérente.

Par exemple :

containers:
  - name: myapp
    image: <image>
    resources:
      requests:
        oke-application-resource.oci.oraclecloud.com/frontend: "1"
      limits:
        oke-application-resource.oci.oraclecloud.com/frontend: "1"

Etape 4 : (facultatif) ciblez les pools de noeuds corrects

Si votre organisation utilise une convention de libellé/sélecteur de noeud pour ces noeuds (par exemple, gva_vnic: "yes"), incluez-la afin que les pods n'atterrissent pas sur des pools de noeuds qui ne disposent pas des ressources requises :

nodeSelector:
  gva_vnic: "yes"

Un sélecteur de noeud est facultatif lorsque les demandes et les tolérances de ressource d'application limitent déjà la planification. N'utilisez un sélecteur de noeud que si vous avez étiqueté les noeuds cible (par exemple via des libellés Kubernetes de pool de noeuds).

Après le déploiement :

1. Entrez :

   kubectl get pods -o wide

2. Pour un pod qui vous intéresse, entrez :

   kubectl describe pod <pod-name>

3. Vérifiez que le pod est en cours d'exécution et qu'il n'y a aucune erreur de planification (par exemple, capacité insuffisante pour la ressource demandée).

Installez Multus avant de créer des NAD ou de déployer des pods multi-interface. Pour plus d'informations sur l'installation de Multus, reportez-vous à la documentation Multus-CNI sur GitHub.

Suivez le processus standard de votre organisation pour le déploiement de Multus, puis vérifiez qu'il est sain :

kubectl get pod -l app=multus -n kube-system

Les exemples de cette section utilisent le module d'extension CNI ipvlan pour l'interface de pod supplémentaire. Assurez-vous que le binaire ipvlan est présent dans /opt/cni/bin/ipvlan sur chaque noeud de processus actif pouvant exécuter des pods multi-interface.

Oracle recommande d'installer le module d'extension ipvlan à l'aide d'un script cloud-init de pool de noeuds afin qu'il soit installé lors de la création, du remplacement ou de la mise à l'échelle des noeuds. Épinglez le module d'extension à une version validée pour l'environnement cible plutôt que de suivre un chemin de téléchargement flottant. L'exemple suivant utilise la version v1.9.0.

Par exemple :

#!/bin/bash

CNI_VERSION="v1.9.0"
CNI_ARCH="amd64"
CNI_TARBALL="cni-plugins-linux-${CNI_ARCH}-${CNI_VERSION}.tgz"
CNI_URL="https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/${CNI_TARBALL}"
CNI_BIN_DIR="/opt/cni/bin"

wget --fail -O "/tmp/${CNI_TARBALL}" "${CNI_URL}" && \
  tar xvzf "/tmp/${CNI_TARBALL}" -C "${CNI_BIN_DIR}" && \
  rm -f "/tmp/${CNI_TARBALL}"

curl --fail -H "Authorization: Bearer Oracle" -L0 \
  http://169.254.169.254/opc/v2/instance/metadata/oke_init_script \
  | base64 --decode > /var/run/oke-init.sh

bash /var/run/oke-init.sh

Si les noeuds de processus actif ne peuvent pas accéder à GitHub, préparez l'archive de modules d'extension CNI requise dans OCI Object Storage ou dans un autre emplacement interne approuvé, et mettez à jour l'URL de téléchargement dans le script cloud-init.

Les NAD doivent cibler les noms d'interface hôte réels créés par les cartes d'interface réseau virtuelles attachées (par exemple, enp1s0, enp2s0). Vérifiez-les sur un noeud de processus actif à l'aide de la méthode d'accès standard de votre organisation.

Créer :

• un NAD pour le réseau de pod par défaut (pour contrôler l'interface hôte qui sauvegarde eth0)
• un ou plusieurs NAD pour des interfaces supplémentaires (par exemple, net1).

Votre configuration NAD peut sélectionner un périphérique à l'aide d'une valeur deviceSelector (par exemple, par interfaceName ou par nom de ressource d'application à l'aide de la valeur appResource si elle est prise en charge dans votre environnement).

Les exemples de NAD suivants utilisent intentionnellement différents espaces de noms. oci-vcn-native-network est défini dans kube-system, tandis que ipvlan-network est défini dans default. Si la charge globale est exécutée dans un autre espace de noms, créez ipvlan-network dans cet espace de noms ou mettez à jour l'annotation de pod pour référencer le nom NAD qualifié complet.

NAD réseau par défaut épinglé sur enp1s0 :

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: oci-vcn-native-network
  namespace: kube-system
spec:
  config: |
    {
      "name": "oci",
      "cniVersion": "0.3.1",
      "plugins": [
        {
          "cniVersion": "0.3.1",
          "type": "oci-ipvlan",
          "mode": "l2",
          "ipam": {
            "type": "oci-ipam",
            "deviceSelector": {
              "interfaceName": "enp1s0"
            }
          }
        },
        {
          "cniVersion": "0.3.1",
          "type": "oci-ptp",
          "containerInterface": "ptp-veth0",
          "mtu": 9000
        }
      ]
    }

NAD du réseau secondaire épinglé à enp2s0 :

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: ipvlan-network
  namespace: default
spec:
  config: |
    {
      "cniVersion": "0.3.1",
      "plugins": [
        {
          "type": "ipvlan",
          "mode": "l2",
          "master": "enp2s0",
          "ipam": {
            "type": "oci-ipam",
            "deviceSelector": {
              "interfaceName": "enp2s0"
            }
          }
        }
      ]
    }

Le NAD par défaut utilise les modules d'extension oci-ipvlan et oci-ptp propres à OCI car cette interface participe au chemin de réseau par défaut natif OKE VCN. Le NAD supplémentaire utilise le module d'extension ipvlan standard car Multus attache une interface supplémentaire à une carte d'interface réseau hôte spécifique, tandis qu'OCI IPAM fournit toujours l'allocation d'adresses IP prenant en charge les sous-réseaux.

deviceSelector peut cibler des interfaces avec des champs tels que :

{
  "appResource": "blue",
  "interfaceName": "enp2s0",
  "interfaceNamePrefix": "enp",
  "macAddress": "02:00:17:08:E3:07"
}

Le bloc deviceSelector permet à OCI IPAM de choisir l'interface cible ou la carte d'interface réseau virtuelle utilisée pour l'allocation d'adresses IP de pod. Il peut sélectionner un périphérique en utilisant un ou plusieurs des champs suivants :

• appResource : sélectionne le profil de carte d'interface réseau virtuelle GVA par nom de ressource d'application.

• interfaceName : sélectionne une interface hôte spécifique, telle que enp1s0.

• interfaceNamePrefix : sélectionne une interface par préfixe, tel que enp.

• macAddress : sélectionne une interface par adresse MAC.

Lorsque appResource est défini dans le sélecteur de périphérique NAD, le module d'extension IPAM OCI utilise cette ressource d'application pour décider quel profil de carte d'interface réseau virtuelle GVA doit fournir l'adresse IP du pod et agir en tant que périphérique parent pour cette interface. Ainsi, différents NAD du même pod peuvent être mis en correspondance avec différents profils VNIC, par exemple :

• NAD1 -> Application Resource: vnic-a

• NAD2 -> Application Resource: vnic-b

• NAD3 -> Application Resource: vnic-c

Si un pod utilise les trois NAD, chaque interface peut être attachée via le profil VNIC correspondant.

Dans les exemples de nom d'interface présentés dans ce document :

• Le NAD oci-vcn-native-network utilise interfaceName: enp1s0 afin qu'OCI IPAM alloue l'adresse IP de réseau par défaut du pod à partir de l'interface enp1s0 de l'hôte.

• Le NAD ipvlan-network utilise interfaceName: enp2s0 afin qu'OCI IPAM alloue l'adresse IP d'interface supplémentaire à partir de l'interface enp2s0 de l'hôte.

C'est également la raison pour laquelle l'exemple de pod est défini :

annotations:
  v1.multus-cni.io/default-network: kube-system/oci-vcn-native-network
  k8s.v1.cni.cncf.io/networks: default/ipvlan-network

L'annotation v1.multus-cni.io/default-network garantit que eth0 utilise le NAD oci-vcn-native-network. Sans sélectionner explicitement ce réseau par défaut, OCI IPAM peut effectuer une allocation à partir de n'importe quelle interface hôte éligible, ce qui rend l'interface de pod principal moins prévisible. La définition du NAD par défaut garantit que eth0 utilise l'interface prévue et la maintient isolée de l'attachement réseau supplémentaire.

Ne combinez pas ces annotations de pod Multus avec des demandes de ressource d'application de niveau pod dans la même spécification de pod. Si un pod multi-interface a besoin d'une sélection de carte d'interface réseau virtuelle GVA, définissez cette sélection dans la configuration NAD deviceSelector.appResource pour chaque interface au lieu d'utiliser une demande de ressource d'application au niveau du pod.

Appliquez les NAD :

kubectl apply -f oci-vcn-native-network-nad.yaml

kubectl apply -f ipvlan-network.yaml

Annotez le pod pour sélectionner le NAD réseau par défaut et connectez des NAD réseau supplémentaires, par exemple :

metadata:
  annotations:
    v1.multus-cni.io/default-network: kube-system/oci-vcn-native-network
    k8s.v1.cni.cncf.io/networks: default/ipvlan-network

1. Décrivez le pod et vérifiez les annotations de statut réseau Multus (le cas échéant) :

   kubectl describe pod <pod-name>

2. Si cela est autorisé dans votre environnement, exécutez-le dans le pod et examinez les interfaces (par exemple, ifconfig ou ip addr) pour vérifier que le pod dispose des interfaces attendues (eth0, net1, …) et des adresses IP.