Guides Essentiels

Voir tous les articles de ce guide

Cet article fait partie de notre guide: Guide de l’administration stockage et réseau sous Kubernetes

Réseau : comment fonctionnent les pilotes CNI de Kubernetes

Cet article fait un point sur le fonctionnement des pilotes réseau CNI de Kubernetes et compare les plus populaires d’entre eux, dont Calico, Flannel, Weave Net, Cilium et Multus.

Stephen J. Bigelow

par

Stephen J. Bigelow, Senior Technology Editor

Publié le: 05 juin 2023

Kubernetes étant responsable du partage des machines entre les applications, il est essentiel d’empêcher deux applications d’utiliser les mêmes ports et de coordonner les ports entre plusieurs systèmes. Plutôt que de résoudre ces problèmes en interne, Kubernetes utilise des pilotes sous la forme de plugins, une conception modulaire qui réduit sa charge interne.

Ces plugins réseau sont appelés CNI (Container Network Interface). Ici, CNI n’est pas le nom du pilote, mais plutôt celui d’une spécification qui définit comment les pilotes réseau doivent communiquer et interopérer avec le runtime du container. Les cinq caractéristiques de cette spécification sont les suivantes :

Un format pour définir la configuration du réseau, laquelle comprend le nom des ressources sur le réseau, les pilotes à déployer, les clés et les noms des objets réseau ;
Un protocole à utiliser pour que les moteurs de containers – tels que runc, CRI-O et containerd – puissent interopérer ou communiquer avec les pilotes réseau ;
La procédure d’exécution des pilotes ;
La procédure permettant aux pilotes d’assigner des fonctions ou des tâches à d’autres pilotes ;
La définition des types de données qui permettent aux pilotes de renvoyer des résultats ou de transmettre des données au moment de l’exécution d’un container.

Un pod ou un container n’ont pas d’interface réseau lors de sa création. Les pilotes CNI insèrent des cartes réseau virtuelles dans l’espace de noms du réseau de containers. Ce réseau virtuel connecte ensuite les hôtes et les containers, attribue des adresses IP, configure le routage et effectue d’autres tâches pour définir l’environnement réseau et pour que les containers puissent communiquer. Les réseaux CNI peuvent utiliser un modèle de réseau encapsulé, tel que Virtual Extensible LAN (VXLAN), ou un modèle de réseau non encapsulé – également connu sous le nom de décapsulé – tel que Border Gateway Protocol (BGP).

Quatre types de communication sont pris en charge : de pod à pod, de pod à service, d’une entrée externe à un service et de container à container.

On trouve des dizaines de pilotes réseau qui adhèrent au standard CNI, notamment Calico, Cilium, Romana, Silk et Linen. La page du projet CNI sur GitHub contient une liste complète.

Par ailleurs, Kubernetes n’est qu’un des environnements d’exécution qui adhèrent à la spécification CNI. Les autres environnements d’exécution compatibles avec les pilotes CNI comprennent rkt, CRI-O, OpenShift, Cloud Foundry, Apache Mesos, Amazon Elastic Container Service, Singularity, OpenSVC.

Voici quelques-uns des avantages des pilotes réseau de type CNI :

Élasticité. Avec les pilotes CNI, les développeurs n’ont pas besoin de configurer un réseau pour chaque situation ou environnement de déploiement. Au lieu de cela, les entreprises peuvent simplement choisir un pilote par infrastructure ou par besoin.

Pas de verrouillage constructeur. L’approche par plugin évite que les fournisseurs verrouillent les entreprises sur leurs produits. Un cluster Kubernetes est compatible avec tous les pilotes CNI.

Changements faciles. Lorsque les besoins de déploiement ou les environnements changent, les entreprises peuvent modifier la plateforme en installant simplement de nouveaux pilotes CNI.

Cependant, les pilotes CNI ne sont pas exempts de défauts. Voici ceux le plus souvent rencontrés ;

Des bugs inattendus. Les développeurs de plateformes ne testent ou ne valident pas toujours les plug-ins, ce qui peut entraîner des défauts tels que des bugs, des performances médiocres et des problèmes de sécurité. Tout test ou validation d’une plateforme logicielle doit prendre en compte les pilotes prévus, y compris la revalidation de la plateforme en termes de stabilité et de performances lorsqu’un plug-in est mis à jour ou remplacé.

Des modules en plus pour l’administrateur. Les administrateurs réseau doivent suivre les mises à jour et les correctifs non seulement pour les plateformes telles que Kubernetes, mais aussi pour tous les plugins, ce qui peut compliquer le déploiement et la gestion des logiciels.

Des normes changeantes. Les spécifications CNI, tout comme celles des autres plug-ins, ne sont pas permanentes. Elles peuvent évoluer et nécessiter de changer de plug-ins. De même, il n’existe aucune garantie de rétrocompatibilité ou de mise à jour en temps voulu des pilotes essentiels pour adhérer aux nouvelles normes. Tout cela peut perturber les entreprises.

Comparer les pilotes CNI Kubernetes

Il existe de nombreux pilotes CNI pour Kubernetes. Chacun effectue des tâches similaires et est installé en tant que démon, mais les pilotes diffèrent dans leur conception et leur approche de l’encapsulation, du routage, des data stores, du chiffrement et du support.

Ce tableau compare les caractéristiques, avantages et inconvénients de quatre CNI pour Kubernetes : Calico, Flannel, Weave Net et Cilium.

Calico est un plugin CNI open source populaire conçu pour la flexibilité, la performance, l’administration avancée et la visibilité des connexions entre les pods et les hôtes. Calico utilise le routage BGP comme réseau sous-jacent, plus IP-in-IP ou VXLAN comme réseau superposé pour l’encapsulation et le routage. BGP n’encapsule pas le trafic IP, ce qui élimine le besoin d’une couche d’encapsulation et améliore les performances du réseau de containers. Calico gère le chiffrement des tunnels avec WireGuard.

Le plugin prend en charge le traçage et le débogage à l’aide de fonctions de gestion du réseau telles que la gestion des politiques et les listes de contrôle d’accès (ACL). Les politiques de réseau utilisent la correspondance autorisation/refus, qui peut être créée selon les besoins et affectée aux politiques d’entrée dans le réseau de pods. Calico offre une assistance aux entreprises par le biais de Calico Enterprise.

Flannel est un plug-in CNI open source mature et stable conçu autour d’un modèle de réseau superposé basé sur VXLAN et adapté à la plupart des cas d’utilisation de Kubernetes.

Flannel crée et gère des sous-réseaux avec un seul démon qui attribue un sous-réseau distinct à chaque nœud de cluster Kubernetes ainsi qu’une adresse IP interne. Le plugin utilise etcd pour stocker les mappages d’hôtes et d’autres éléments de configuration. Le chiffrement est pris en charge par le protocole IPsec standard.

Flannel est un bon choix pour s’initier aux CNI de Kubernetes et mieux en maîtriser les clusters. Cependant, Flannel ne prend pas en charge les règles de réseau, ne peut pas exécuter plusieurs hôtes via un seul démon et n’offre pas de support aux entreprises.

Weave Net, un produit de Weaveworks, propose l’installation et la configuration de pilotes CNI au sein des clusters Kubernetes. Weave crée un réseau maillé superposé capable de connecter tous les nœuds du cluster. La superposition utilise un système de noyau pour déplacer les paquets et fonctionne directement entre les pods au sein d’un même hôte, bien que ce ne soit pas une option pour déplacer le trafic entre les hôtes.

Le plug-in Weave gère d’autres fonctions du réseau, telles que la tolérance aux pannes, l’équilibrage des charges et la résolution des noms, par l’intermédiaire d’un serveur DNS Weave. Weave utilise IPsec pour le chiffrement et VXLAN comme protocole standard pour l’encapsulation et le routage.

Contrairement à de nombreux autres pilotes CNI, Weave n’utilise pas etcd, mais stocke les paramètres de configuration du réseau dans un fichier de base de données natif utilisé par Weave et partagé entre les pods. Le plugin prend en charge les politiques de réseau par le biais d’un container spécialisé weave-npc, qu’il installe et configure par défaut.

Cilium est une CNI Open source connue pour sa grande évolutivité et sa sécurité qui est installée en tant que démon sur chaque nœud d’un cluster Kubernetes. Cilium utilise VXLAN pour former un réseau superposé et Berkeley Packet Filter étendu pour gérer la connectivité réseau et les règles applicatives. Il prend en charge l’adressage IPv4 et IPv6 et utilise BGP pour le routage non encapsulé. Cilium peut prendre en charge plusieurs clusters Kubernetes et, comme Multus, offre des capacités multi-CNI.

Cilium gère les aspects de la gestion de réseau, tels que les politiques de réseau, par le biais de filtres de demande HTTP. Les politiques peuvent être écrites dans des fichiers YAML ou JSON, qui fournissent tous deux l’application du trafic réseau pour le trafic entrant et sortant.

Multus est un plugin CNI conçu pour prendre en charge plusieurs interfaces réseau pour les pods. Par défaut, chaque pod Kubernetes n’a qu’une interface réseau et un loopback. Multus agit comme un méta-plugin qui peut appeler d’autres pilotes CNI, permettant aux entreprises de déployer des pods avec plusieurs interfaces réseau.

Multus est utile dans plusieurs contextes, notamment la division du trafic, où les types de trafic doivent être soigneusement gérés pour garantir la qualité du service. Il peut également améliorer les performances de certains types de trafic qui bénéficient d’une augmentation des performances matérielles, y compris la virtualisation des E/S à racine unique, et améliorer la sécurité lorsque les réseaux multi-locataires nécessitent une isolation minutieuse.

Pour approfondir sur Administration de réseaux

Close