Activer des pods avec plusieurs interfaces réseau

Cloud-Native Contrail® Networking™ (CN2) prend en charge plusieurs interfaces réseau pour un pod dans Kubernetes.

Cloud-Native Contrail Networking prend en charge en natif plusieurs interfaces réseau pour un pod.

Vous pouvez également activer plusieurs interfaces réseau dans Cloud-Native Contrail Networking à l’aide de Multus. Multus est un plug-in d’interface réseau de conteneur (CNI) pour Kubernetes développé par le Kubernetes Network Plumbing Working Group. Cloud-Native Contrail peut interagir avec Multus pour prendre en charge plusieurs interfaces fournies par plusieurs CIN dans un pod.

Ce document présente les étapes à suivre pour activer plusieurs interfaces pour un pod dans des environnements utilisant la version 22.1 ou une version ultérieure dans les environnements orchestrés par Kubernetes. Il comprend des informations sur le moment et la manière d’activer plusieurs interfaces réseau.

Avantages de multiples interfaces réseau dans le cloud-native Contrail

La prise en charge de plusieurs interfaces réseau est utile ou nécessaire dans de nombreux environnements de mise en réseau cloud. Quelques exemples courants :

• Les pods ont généralement besoin d’une interface de données pour transporter le trafic de données et d’une interface distincte pour le trafic de gestion.

• Les fonctions réseau virtualisées (VNF) ont généralement besoin de trois interfaces (une gauche, une droite et une interface de gestion) pour fournir des fonctions réseau. Souvent, une VNF ne peut pas fournir sa fonction avec une interface réseau unique.

• Les topologies de réseau cloud doivent généralement prendre en charge deux interfaces réseau ou plus pour isoler les réseaux de gestion des réseaux locataires.

• Dans les environnements de mise en réseau cloud personnalisés ou à grande échelle, vous devez souvent utiliser un produit de mise en réseau cloud qui prend en charge plusieurs interfaces réseau pour répondre à une variété d’exigences spécifiques à l’environnement.

Un pod dans un cluster Kubernetes utilisant le CNI par défaut dispose d’une interface réseau unique pour l’envoi et la réception du trafic réseau. Cloud-Native Contrail Networking offre une prise en charge native de plusieurs interfaces réseau. Cloud-Native Contrail prend également en charge l’intégration de Multus, permettant aux environnements utilisant Cloud-Native Contrail pour la mise en réseau de prendre en charge plusieurs interfaces réseau à l’aide de Multus.

Présentation des interfaces réseau multiples dans Contrail cloud-native

Vous pouvez activer plusieurs interfaces réseau dans Cloud-Native Contrail à l’aide de Multus et sans multus. Multus est un plug-in d’interface réseau de conteneur (CNI) pour Kubernetes qui permet de prendre en charge plusieurs interfaces réseau sur un pod ainsi que le multihébergement entre les pods. Multus peut simultanément prendre en charge les interfaces de plusieurs CN déléguées, ce qui permet de créer des environnements de mise en réseau cloud interconnectés à l’aide de CN fournies par différents fournisseurs, y compris Cloud-Native Contrail. Multus est souvent appelé un « méta-plugin » en raison de cette prise en charge multifournisseur.

Vous devez activer plusieurs interfaces réseau à l’aide de la prise en charge native de Contrail Networking cloud-native pour plusieurs interfaces pour les raisons suivantes ;

• Vous ne voulez pas avoir à activer et à maintenir Multus dans votre environnement.

• Vous utilisez Cloud-Native Contrail Networking comme seule interface de mise en réseau de conteneur (CNI).

• Vous ne voulez pas créer et maintenir des objets NAD (Network Attachment Definition) pour prendre en charge plusieurs interfaces réseau dans votre environnement.

  Vous devez créer un objet NAD pour activer plusieurs interfaces réseau avec Multus. Vous n’avez pas besoin de configurer un objet NAD pour activer plusieurs interfaces réseau si vous n’utilisez pas Multus.

  Chaque objet NAD, notamment, crée un réseau virtuel et un sous-réseau qui doivent être surveillés et maintenus.

Vous devez activer plusieurs interfaces réseau à l’aide de Multus pour les raisons suivantes :

• Vous utilisez Cloud-Native Contrail dans un environnement qui utilise déjà Multus. Le multus est particulièrement courant dans les environnements utilisant l’orchestration Openshift.

• Vous avez besoin des fonctionnalités de « méta-plugin » fournies par Multus. Vous utilisez Cloud-Native Contrail dans un environnement où un pod utilise plusieurs interfaces et les multiples interfaces sont gérées par Cloud-Native Contrail et d’autres CN.

• Vous avez besoin d’autres fonctionnalités Multus dans votre environnement.

Présentation de l’intégration cloud-native de Contrail avec Multus

Un vRouter Contrail est nativement multi-conscient. Aucune configuration Cloud-Native Contrail Networking n’est requise pour permettre l’interopérabilité de Multus avec Cloud-Native Contrail.

Cette liste résume les options d’interopérabilité de Cloud-Native Contrail avec Multus.

• Cloud-Native Contrail est compatible avec Multus CNI version 0.3.1.

• Cloud-Native Contrail est pris en charge en tant que CNI principal avec Multus. Il n’est pas pris en charge avec Multus comme CNI secondaire.

• Cloud-Native Contrail est pris en charge en tant que CNI délégué pour Multus. Cloud-Native Contrail doit fonctionner comme le CNI par défaut ou comme l’un des CNI délégués lorsqu’il interopérait dans un cluster avec Multus.

• Cloud-Native Contrail prend en charge l’interopérabilité avec Multus en mode noyau vRouter ou DPDK.

Multus est un plugin tiers. Vous activez et configurez Multus au sein de Kubernetes, mais entièrement en dehors de Cloud-Native Contrail. Pour activer Multus, vous pouvez appliquer les fichiers multus-daemonset.yml fournis par le groupe de travail Kubernetes Network Plumbing. Kubernetes Network Plumbing Working Group est le groupe open-source qui développe Multus.

Pour obtenir des informations détaillées sur Multus, consultez le guide d’utilisation du CNI Multus du groupe de travail Kubernetes sur la plomberie réseau.

Créer un objet de définition de pièce jointe réseau

Vous n’avez pas besoin de créer un objet NAD (NetworkAttachmentDefinition ) pour activer plusieurs interfaces à l’aide de la prise en charge native de plusieurs interfaces dans Cloud-Native Contrail Networking. Vous pouvez ignorer cette section si vous n’utilisez pas Multus pour activer plusieurs interfaces réseau dans votre environnement. Si vous n’utilisez pas d’objets NAD, mais que vous devez créer un réseau virtuel, consultez https://www.juniper.net/documentation/us/en/software/cn-cloud-native22/cn-cloud-native-feature-guide/cn-cloud-native-network-feature/topics/concept/Contrail_Network_Policy_Implementation_in_CN2.html.

Cette section illustre comment créer un objet NAD à l’aide d’un fichier YAML. Vous configurez Cloud-Native Contrail dans l’objet NAD à l’aide de la juniper.net/networks Annotation. Nous fournissons un exemple représentatif du fichier YAML qui crée l’objet NAD et une table de descriptions de champs plus loin dans cette section.

Assurez-vous d’inclure l’annotation juniper.net/networks lorsque vous créez l’objet NetworkAttachmentDefinition . Si vous définissez le fichier YAML pour créer l’objet NetworkAttachmentDefinition sans utiliser l’annotation juniper.net/networks , l’objet NetworkAttachmentDefinition est traité comme un objet tiers. Aucun objet lié à Contrail ne sera créé dans le réseau, y compris l’objet VirtualNetwork et l’objet Sous-réseau .

Vous créez l’objet NetworkAttachmentDefinition dans un environnement Kubernetes à l’aide du contrôleur NAD (Network Attachment Definition). Le contrôleur NAD s’exécute dans kube-manager et crée un objet VirtualNetwork ou met à jour un objet VirtualNetwork existant lorsqu’une redéfinition du réseau est créée avec succès. Le contrôleur NAD est activé par défaut, mais vous pouvez le désactiver ; voir Désactiver le contrôleur de définition des pièces jointes réseau.

Voici un exemple représentatif du fichier YAML utilisé pour créer un objet NetworkAttachmentDefinition :

Le tableau NetworkAttachmentDefinition Object Fields fournit les détails d’utilisation des variables du fichier objet NetworkAttachmentDefinition .

Tableau 1 : champs d’objets de définition de l’attachement au réseau

Utilisation variable
ipamV4Subnet	(Facultatif) Spécifie l’adresse de sous-réseau IPv4 du réseau virtuel.
ipamV6Subnet	(Facultatif) Spécifie l’adresse de sous-réseau IPv6 du réseau virtuel.
routeTargetList	(Facultatif) Fournit une liste de cibles de routage utilisées à la fois comme routes d’importation et d’exportation.
importRouteTargetList	(Facultatif) Fournit une liste de cibles de routage utilisées comme routes d’importation.
exportRouteTargetList	(Facultatif) Fournit une liste de cibles de routage utilisées comme routes d’exportation.
fabricSNAT	(Facultatif) Spécifie si vous souhaitez basculer la connectivité vers le réseau sous-jacent à l’aide des fonctionnalités de mappage de ports fournies par nat source de la structure. Définissez ce paramètre sur true ou false. Il est défini sur false par défaut.

Vous devez noter les activités réseau suivantes liées à l’objet NetworkAttachmentDefinition :

• Le contrôleur de définition des pièces jointes réseau fonctionne dans kube-manager et gère le traitement de tous les objets de définition des pièces jointes réseau.
• Vous pouvez surveiller les mises à jour du contrôleur de définition des pièces jointes dans juniper.net/network-status.
• Les mises à jour IPAM ne sont pas autorisées à l’objet de définition des pièces jointes du réseau.

L’objet de définition des pièces jointes du réseau crée un réseau virtuel. Le tableau Network Attachment Definition Object Impact on Virtual Networks fournit une vue d’ensemble de l’impact des événements liés à l’objet de définition des pièces jointes réseau sur les réseaux virtuels.

Tableau 2 : Impact de l’objet de définition des pièces jointes réseau sur les réseaux virtuels

Si vous définissez	, alors
Espace de noms pour un objet de définition de pièce jointe réseau dans une topologie de cluster unique,	Un réseau virtuel est créé dans le même espace de noms que la définition des pièces jointes du réseau. Ce réseau virtuel aura le même nom que l’objet Network Attachment Definition. L’objet NAD est nommé à l’aide du champ nom: dans la hiérarchie des métadonnées .
Espace de noms pour un objet de définition de pièce jointe réseau dans une topologie multi-cluster,	L’espace de noms VirtualNetwork est cluster-name-ns.
Si un espace de noms n’est pas défini pour un objet de définition de pièce jointe réseau dans une topologie multi-cluster,	L’espace de noms VirtualNetwork est cluster-name-default.
Si vous supprimez une ressource de définition de pièce jointe réseau,	L’objet VirtualNetwork associé est également supprimé.
Si vous supprimez un réseau virtuel créé par la ressource de définition des pièces jointes,	Le contrôleur de définition des pièces jointes du réseau réconcilie le problème et recrée le réseau virtuel.

Configurer un pod pour utiliser plusieurs interfaces

Vous configurez plusieurs interfaces dans l’objet pod. Si vous utilisez Multus, vous devez également configurer l’objet NAD comme indiqué dans Créer un objet de définition de pièce jointe réseau.

Dans l’exemple suivant, vous créez deux interfaces pour le trafic réseau dans le pod juniper-pod-1 ; tap1 et tap2.

Désactiver le contrôleur de définition des pièces jointes réseau

Le contrôleur de définition des pièces jointes réseau fait partie de l’objet kube-manager. Vous activez et désactivez ce contrôleur à l’aide de la variable enableNad : dans le fichier YAML qui définit l’objet kubemanager . Le contrôleur de définition des pièces jointes du réseau est activé par défaut.

Vous pouvez désactiver le contrôleur de définition des pièces jointes du réseau pour empêcher l’application des objets NetworkAttachmentDefinion .

Dans l’exemple suivant, le contrôleur de définition des pièces jointes réseau est désactivé :