Remarque :

Ce tutoriel nécessite un accès à Oracle Cloud. Pour vous inscrire à un compte gratuit, reportez-vous à Introduction à Oracle Cloud Infrastructure Free Tier.
Il utilise des exemples de valeur pour les informations d'identification Oracle Cloud Infrastructure, la location et les compartiments. A la fin de votre atelier, remplacez ces valeurs par celles propres à votre environnement cloud.

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

Introduction

Lorsque des charges de travail fortement orientées réseau nécessitent la configuration d'interfaces réseau secondaires au sein des pods, nous pouvons utiliser une méta CNI comme Multus pour y parvenir. Les interfaces réseau secondaires généralement connectées dans ces cas auront des fonctionnalités ou des propriétés réseau spécialisées telles que la virtualisation d'E/S à root unique (SR-IOV).

Dans un tutoriel précédent : configurez les interfaces SR-IOV pour les pods à l'aide de Multus pour les noeuds OKE Bare Metal (vous pouvez accéder au lien à partir de la section Liens associés). Nous avons expliqué comment y parvenir sur les noeuds Kubernetes Bare Metal sur Oracle Cloud Infrastructure (OCI), où vous pouvez créer directement des fonctions virtuelles (VF) sur le matériel attaché à l'instance Bare Metal.

Ce tutoriel suit une approche similaire pour les noeuds de machine virtuelle dans un cluster Oracle Container Engine for Kubernetes (OKE), et adopte une approche similaire, avec différentes configurations et plug-ins que ceux utilisés sur les noeuds sans système d'exploitation. Il existe des différences importantes dans la façon dont les interfaces sont créées et gérées entre Bare Metal, où vous disposez d'un contrôle total sur le matériel et les machines virtuelles où un hyperviseur abstrait votre accès au matériel sous-jacent et vous n'avez pas autant de contrôle sur celui-ci.

L'approche décrite ici utilise Multus pour fournir plusieurs interfaces à un pod, mais la carte CNI SR-IOV et le plug-in de périphérique associé ne sont pas utilisés. En effet, la SR-IOV CNI nécessite l'accès au matériel sous-jacent, la fonction physique (PF), qui pose évidemment un problème sur les machines virtuelles. Pour relever ce défi, nous pouvons utiliser les API de réseau OCI pour les VNIC, pour créer une fonction virtuelle (VF) sur la fonction physique (PF), comme dans le scénario Bare Metal, et accorder à la machine virtuelle un accès direct et non structuré à cette VF. Ces VF peuvent être attachées à une instance de calcul, y compris les noeuds OKE, en tant qu'interfaces réseau. Ces interfaces/FV peuvent être déplacées vers les espaces de noms réseau des pods, ce qui permet au pod d'utiliser directement et exclusivement la fonction virtuelle en tant qu'interface réseau. Du point de vue des Pods, il ne sera pas en mesure de distinguer les deux, et dans les deux cas aura accès à une VF qu'ils peuvent utiliser directement.

Pour accorder un accès direct à une machine virtuelle à une fonction virtuelle, nous devons lancer la machine virtuelle avec le mode d'attachement réseau VFIO par opposition au mode par défaut paravirtualized. Ce choix est contrôlé par le mode de lancement de l'instance de calcul. Une fois le mode d'attachement réseau défini sur VFIO, nous pouvons créer des attachements réseau à l'aide des API OCI, ce qui crée des VF sur le PF sous-jacent et fournit le VF directement à la machine virtuelle. Le système d'exploitation de l'hôte les reconnaît comme des interfaces réseau. Une fois que la fonction virtuelle est disponible pour la machine virtuelle, elle peut être déplacée vers l'espace de noms de pod. Dans ce modèle, les VF sont créées à l'aide des API OCI plutôt que des commandes système dans le scénario Bare Metal.

VF déplacées vers les espaces de noms réseau du pod

Objectif

Configurez les interfaces SR-IOV pour les pods à l'aide de Multus pour les noeuds Oracle Container Engine for Kubernetes basés sur une machine virtuelle.

Prérequis

Cluster OKE avec un pool de noeuds composé d'au moins deux machines virtuelles.

Remarque : ce tutoriel a été validé sur les clusters OKE avec réseau flanel (Flannel en tant que CNI principal).

Tâche 1 : configurer les noeuds

Chaque noeud nécessitant un accès aux interfaces SR-IOV doit être préparé pour les attachements réseau assistés par le matériel avant qu'ils puissent être utilisés par les pods.

Initialiser les noeuds en mode VFIO
- Créez un pool de noeuds et un ensemble de noeuds dans votre cluster.
- Une fois les noeuds créés, modifiez les propriétés de l'instance.
- Dans les propriétés de l'instance, cliquez sur Afficher les options avancées pour afficher les propriétés supplémentaires. Dans l'onglet Options de lancement, sélectionnez Mise en réseau assistée par matériel (SR-IOV) pour le type de mise en réseau.
  
  Remarque : une fois qu'une instance est passée en mode paravirtualisé, les attachements réseau en mode matériel assisté (SR-IOV ou VFIO) ne sont plus éligibles à la migration en direct pour la maintenance de l'infrastructure.
- Le workflow de mise à jour vous invite à redémarrer l'instance. Après le redémarrage, l'instance dispose d'attachements réseau VFIO. Cela peut être vérifié sur la console.
- Une autre méthode pour vérifier si vos instances utilisent des attachements réseau SR-IOV consiste à se connecter via SSH au noeud et à utiliser lspci pour répertorier les périphériques PCI sur la machine virtuelle. Vous devriez pouvoir voir la fonction virtuelle sous-jacente directement sur la machine virtuelle plutôt qu'un périphérique à l'aide d'un pilote virtio (comme le contrôleur de stockage dans l'image ci-dessous).
- A ce stade, le noeud dispose d'un seul attachement de carte d'interface réseau virtuelle, qui est la carte d'interface réseau virtuelle principale utilisée pour toutes les communications avec le noeud. Etant donné que l'instance utilise des attachements réseau assistés par le matériel, l'attachement réseau est visible par le noeud en tant que fonction virtuelle sur le matériel sous-jacent. Pour que les pods utilisent exclusivement une fonction virtuelle, nous avons besoin de VF supplémentaires sur la machine virtuelle. Vous pouvez le fournir à l'aide de la console ou de l'API afin d'ajouter des attachements de VNIC supplémentaires à l'instance. Ces attachements VNIC sont des VF sur le PF sous-jacent. Vous pouvez les vérifier avec lspci.
Ajout d'attachements de carte d'interface réseau virtuelle supplémentaires
- Sur la page de l'instance, choisissez VNIC attachées et cliquez sur Créer une VNIC.
- Configurez la carte d'interface réseau virtuelle à l'aide du VCN et du sous-réseau requis.
- Vérifiez si la VNIC peut être vue sur l'hôte comme une fonction virtuelle comme précédemment, en effectuant une connexion SSH sur le noeud et en exécutant lspci.
- Lorsque vous ajoutez une carte d'interface réseau virtuelle secondaire à une instance de machine virtuelle Linux, une nouvelle interface (c'est-à-dire un périphérique Ethernet) est ajoutée à l'instance et automatiquement reconnue par le système d'exploitation. Toutefois, DHCP n'est pas actif pour la VNIC secondaire et vous devez configurer l'interface avec l'adresse IP statique et la route par défaut.
Configuration du système d'exploitation pour les cartes d'interface réseau virtuelles secondaires
- OCI fournit une documentation et un script pour configurer le système d'exploitation pour les cartes d'interface réseau virtuelles secondaires. Pour configurer la carte d'interface réseau virtuelle secondaire, téléchargez le script sur le noeud et exécutez-le en fonction des instructions fournies dans la documentation OCI.
  
  Remarque : les VNIC secondaires sur chaque noeud doivent être configurées en répétant ces étapes pour chaque noeud. Ces étapes peuvent éventuellement être automatisées à l'aide d'un script cloud_init personnalisé pour les noeuds.
- Vérifiez que l'interface est maintenant connectée, avec son adresse IP et sa route par défaut. Pour vérifier, utilisez la commande ip addr ou nmcli.
- Vérifiez éventuellement le routage à l'aide d'une commande ping pour atteindre les adresses IP secondaires les unes des autres. Dans les images ci-dessous, 10.0.10.238 est l'adresse IP secondaire sur un deuxième noeud du cluster.

Tâche 2 : installation d'un CNI Meta-Plugin (Multus)

Multus est un module d'extension méta qui peut fournir les informations VF à un CNI en aval comme le module d'extension CNI SR-IOV pour qu'il gère la plomberie des ressources réseau tout en activant les pods ou pods " multiréseau " avec plusieurs interfaces réseau.

Remarque : à partir de plusieurs versions 4.0, Multus a introduit un nouveau déploiement de type client-serveur appelé "plug-in épais". Le nouveau plug-in épais prend en charge des fonctionnalités supplémentaires telles que des mesures qui n'étaient pas prises en charge précédemment. Ce document utilise le module d'extension "fin" car il consomme moins de ressources.

Pour installer Multus, exécutez les commandes suivantes.

git clone https://github.com/k8snetworkplumbingwg/multus-cni.git && cd multus-cni
kubectl apply -f deployments/multus-daemonset.yml && cd ..

Remarque : lors de l'installation, l'image par défaut utilisée par le démon marqué stable nécessite que le kubelet soit v1.20.x. Si vous effectuez l'installation sur un cluster plus ancien, modifiez le fichier deamonset dans le manifeste et utilisez la balise d'image multus v3.7.1.

Ce manifeste crée un CRD pour kind:NetworkAttachmentDefinition et fournit le binaire Multus sur tous les noeuds via un ensemble de démons. Vous pouvez vérifier l'installation en vous assurant que le démon Multus est en cours d'exécution sur vos noeuds.

Tâche 3 : attachement de plusieurs interfaces aux pods

Pour connecter des interfaces supplémentaires aux pods, nous avons besoin d'une configuration pour que l'interface soit connectée. 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 plug-ins CNI qui peuvent être utilisés à côté de Multus pour y parvenir. Dans l'approche décrite ici, l'objectif est de fournir une fonction virtuelle SR-IOV exclusivement pour un seul pod, de sorte que le pod peut tirer parti des capacités sans interférence ou des couches entre elles. Pour accorder à un pod un accès exclusif à la fonction virtuelle, nous pouvons tirer parti du module d'extension hôte-périphérique qui vous permet de déplacer l'interface vers l'espace de noms du pod afin qu'il dispose d'un accès exclusif à celui-ci.

Les exemples ci-dessous montrent les objets NetworkAttachmentDefinition qui configurent l'interface ens5 secondaire qui a été ajoutée aux noeuds. La configuration du plug-in ipam détermine la manière 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 affectées aux interfaces secondaires par OCI, nous utilisons la configuration ipam statique 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.

## network attachment for the first node. Note the IPaddress assignment in the `ipam` configuration.

cat << EOF | kubectl create -f -
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.10.93/24",
                        "gateway": "0.0.0.0"
                    }
                ],
                "routes": [
                    { "dst": "10.0.10.0/24", "gw": "0.0.0.0" }
                ]
            }
          }'
EOF

## network attachment for the second node. Note the IPaddress assignment in the `ipam` configuration.

cat << EOF | kubectl create -f -
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.10.238/24",
                        "gateway": "0.0.0.0"
                    }
                ],
                "routes": [
                    { "dst": "10.0.10.0/24", "gw": "0.0.0.0" }
                ]
            }
          }'
EOF

Tâche 4 : déploiement de pods avec plusieurs interfaces et test

Les pods peuvent désormais demander des interfaces supplémentaires à l'aide d'une annotation. L'annotation permet au meta-plug-in (Multus) de savoir quel NetworkAttachmentDefinition (configuration CNI) utiliser pour fournir des interfaces supplémentaires lors de la création du pod.

Remarque : lors de l'utilisation d'une configuration statique comme celle présentée dans cet exemple, les pods doivent avoir une affinité de noeud définie, de sorte que le pod soit planifié sur le noeud où le périphérique hôte souhaité est disponible.

Voici un exemple avec un pod de test :

## Create the first pod
cat << EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: testpod1
  annotations:
    k8s.v1.cni.cncf.io/networks: sriov-vnic-1
spec:
  containers:
  - name: appcntr1
    image: centos/tools
    imagePullPolicy: IfNotPresent
    command: [ "/bin/bash", "-c", "--" ]
    args: [ "while true; do sleep 300000; done;" ]

EOF

## Create a second pod
cat << EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: testpod2
  annotations:
    k8s.v1.cni.cncf.io/networks: sriov-vnic
spec:
  containers:
  - name: appcntr1
    image: centos/tools
    imagePullPolicy: IfNotPresent
    command: [ "/bin/bash", "-c", "--" ]
    args: [ "while true; do sleep 300000; done;" ]

EOF

Lorsque deux pods sont créés, nous devons voir qu'ils sont en cours d'exécution. Nous devrions pouvoir voir que des interfaces réseau supplémentaires ont été créées lors de la création des pods. Multus fournira l'interface eth0 qui est soutenue par le CNI par défaut (Flannel dans cet exemple) et une interface net1 supplémentaire qui est la fonction virtuelle SR-IOV. Vous pouvez describe les pods et observer la section Events de la sortie pour voir les différents événements, y compris les interfaces attachées au pod.

Une fois les pods démarrés, nous pouvons effectuer un test rapide.

## Verify that both pods have two interfaces. An `eth0` on the overlay and a `net1` which is the VF, along with the IP address for the secondary VNIC.
kubectl exec -it testpod1 -- ip addr show
kubectl exec -it testpod2 -- ip addr show

La sortie doit ressembler aux images suivantes.

Nous pouvons également vérifier la communication entre les deux pods sur ces interfaces secondaires.

## test communication
kubectl exec -it testpod1 -- ping -I net1  <ip address for secondary vnic on the other pod/node>
kubectl exec -it testpod2 -- ping -I net1  <ip address for secondary vnic on the other pod/node>

La sortie doit ressembler aux images suivantes.
Nous pouvons également valider que les pods sont routables à l'aide de leurs attachements réseau, en essayant de les atteindre à partir des machines virtuelles ou de toute autre source dans le VCN.
```
## Test that the pod is routable from outside Kubernetes. This is executed from node1.
ping 10.0.10.238

## similarly, from node 2
ping 10.0.10.93
```
La sortie doit ressembler aux images suivantes.

Remerciements

Auteur - Jeevan Joseph (chef de produit principal)

Ressources de formation supplémentaires

Explorez d'autres ateliers sur docs.oracle.com/learn ou accédez à davantage de contenu de formation gratuit sur le canal Oracle Learning YouTube. En outre, accédez à education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

Pour consulter la documentation produit, consultez Oracle Help Center.

Informations relatives au titre et au copyright

Configure SR-IOV interfaces for pods using Multus for VM-based Oracle Container Engine for Kubernetes nodes

F80585-01

May 2023