
GP - Fotolia
Administration : les clés de la mise en réseau des containers
Les administrateurs doivent de plus en plus souvent mettre en place des réseaux de containers. Cet article explique comment assurer la connectivité entre les containers et travailler avec les outils dédiés.
La containerisation a révolutionné la façon dont les développeurs conçoivent, déploient et maintiennent les applications dans les systèmes logiciels modernes. Alors que de plus en plus d’entreprises adoptent l’architecture microservices, un nombre croissant d’ingénieurs réseau ont dû apprendre à travailler avec des containers.
Avant les containers, les ingénieurs chargés de déployer une application sur un serveur de production étaient confrontés à plusieurs problématiques :
– Compatibilité des systèmes d’exploitation.
– Incohérence avec les versions des bibliothèques.
– Permissions insuffisantes.
– Le dilemme « fonctionne sur ma machine ».
Ces difficultés se traduisaient par des cycles de déploiement lents, une augmentation des coûts d’exploitation et des comportements imprévisibles. Les containers regroupent tout ce qui est nécessaire à l’exécution des applications dans un seul paquet exécutable, le container. Ce processus garantit que l’application fonctionne de manière cohérente dans n’importe quel environnement, qu’il s’agisse de la machine d’un développeur, d’un serveur sur site ou d’un nuage, minimisant ainsi les risques de comportements inattendus et de problèmes spécifiques à la plateforme.
Même si les containers simplifient le déploiement, ils ne fonctionnent pas de manière isolée. Ils doivent communiquer sur des réseaux internes – entre différents containers – et des services externes dans plusieurs environnements. C’est là que la mise en réseau des containers joue un rôle crucial.
Concepts fondamentaux de la mise en réseau de containers
Les concepts suivants sont essentiels pour comprendre la mise en réseau des containers.
Espaces de noms du réseau (Network namespaces). Les containers fonctionnent dans des espaces isolés appelés espaces de noms. Chaque espace de noms possède ses propres tables de routage, interfaces réseau et règles de pare-feu. Cela empêche les différents containers d’accéder les uns aux autres, sauf s’ils sont configurés à cet effet. Un espace de noms crée des environnements réseau distincts par pod ou container.
Interfaces Ethernet virtuelles. Les interfaces Ethernet virtuelles (veth) créent des liens entre les espaces de noms et le réseau hôte. Chaque paire a deux extrémités : une extrémité reliée à l’espace de noms du container et l’autre au pont du réseau hôte. Cela permet aux données de passer entre l’hôte et le container pour la connectivité externe.
Découverte de services. La découverte de services facilite la communication entre les containers en établissant une correspondance entre les noms de containers et les adresses IP ou les noms DNS pour assurer l’évolutivité.
Interface réseau de container (Container Networking Interface, ou CNI). Les pilotes CNI sont un projet de la Cloud Native Computing Foundation (CNCF). Il s’agit d’une spécification et d’un ensemble de bibliothèques utilisées pour l’écriture de plug-ins et pour les configurations d’interfaces de containers Linux et Windows. La couche CNI alloue des ressources réseau lors de la création des containers. Il les retire ensuite lorsque les équipes n’ont plus besoin de ces ressources et les suppriment.
La couche CNI standardise la façon dont un runtime de container interagit avec divers plug-ins de réseau Kubernetes pour créer et activer des configurations de réseau pour les containers. CNI fournit également une normalisation pour les orchestrateurs de containers, tels que Kubernetes, afin qu’ils s’intègrent à divers outils et plugins de mise en réseau. Cette normalisation garantit une mise en réseau cohérente.
Lorsque les réseaux ont besoin d’un container, le runtime du container invoque la couche CNI, qui configure les interfaces, les routes et les espaces de noms du réseau. La couche CNI renvoie ensuite les configurations à l’exécution du container. L’exécution du container lance le container lorsqu’il est terminé ou supprimé et invoque à nouveau la couche CNI pour le nettoyage des ressources.

Quels sont les modèles de mise en réseau des containers ?
Les modèles courants de mise en réseau de containers que les équipes peuvent utiliser sont les suivants :
– Bridge networking (mise en réseau par pont), ou réseau local à espace de noms.
– Host networking, ou interface de l’hôte en direct.
– Overlay networking (réseau superposé), ou réseau multihôte.
Bridge networking. Dans ce modèle, un hôte isole un réseau de containers en créant un pont. Ce modèle est idéal pour le développement local, les environnements à hôte unique et les situations où le trafic entre containers n’a pas besoin de passer par plusieurs hôtes. Le mappage de port peut également étendre le pont pour exposer les services à l’extérieur.
Dans Kubernetes, le modèle Bridge networking n’est pas utilisé directement. Il fonctionne plutôt à un niveau d’abstraction plus élevé et est principalement géré par les plug-ins CNI.
Ainsi, l’exemple suivant explore comment créer un réseau de ponts isolés dans Docker. Docker crée un pont virtuel – docker0 – par défaut. Cela permet la communication interne par le biais d’adresses IP provenant d’un réseau privé et la traduction d’adresses réseau (NAT) pour le trafic sortant.
# Create a custom bridge network
docker network create --driver bridge my_bridge_network
# Run containers on the bridge
docker run -d --network my_bridge_network --name container1 nginx
docker run -d --network my_bridge_network --name container2 nginx
# Inspect the bridge network details
docker network inspect my_bridge_networks
Host networking. La mise en réseau de l’hôte élimine le besoin d’isolation que l’on trouve dans la mise en réseau des ponts. La mise en réseau de l’hôte fait correspondre le réseau du container directement à l’espace de noms du réseau de l’hôte, ce qui permet d’éviter la NAT. Ce modèle convient aux applications à hautes performances pour lesquelles une faible latence est cruciale et l’isolation n’est pas une préoccupation majeure.
Voici comment utiliser la mise en réseau d’hôtes dans Docker.
# Run container with host networking
docker run -d --network host --name web nginx
Dans Kubernetes, vous définissez la mise en réseau de l’hôte dans les spécifications du module. En définissant hostNetwork : true, le réseau du pod est directement relié au nœud.
apiVersion: v1
kind: Pod
metadata:
name: host-network-pod
spec:
hostNetwork: true
containers:
- name: nginx
image: nginx
Overlay networking. Cette mise en réseau permet la communication entre les containers sur plusieurs hôtes et encapsule le trafic à l’aide d’un réseau local extensible virtuel (Virtual Extensible LAN). Les clusters Kubernetes et Docker Swarm utilisent ce modèle pour les communications entre les containers situés sur différents nœuds.
Ce modèle est le mieux adapté aux applications hautement distribuées. Pour Kubernetes, les plug-ins CNI, tels que Cilium, gèrent le réseau superposé souvent au niveau de la couche 3.
Comment concevoir des réseaux de containers ?
Le processus de conception des réseaux de containers aligne les éléments de réseau traditionnels sur les besoins évolutifs des environnements containerisés. Ces éléments sont les suivants :
– L’infrastructure réseau existante.
– Les réseaux définis par logiciel (SDN).
– Les règles réseau.
Infrastructure réseau existante. Lors de la conception d’un réseau de containers, il est essentiel d’assurer une intégration harmonieuse avec l’infrastructure réseau préexistante. Cela est particulièrement important pour les systèmes existants et les autres services externes.
Lorsque des applications doivent communiquer avec des bases de données existantes ou des applications hébergées dans des centres de données sur site, les ingénieurs doivent configurer une technique d’acheminement plus efficace pour garantir des performances élevées. Parmi ces techniques, citons les tunnels VPN ou les interconnexions directes.
SDN. Le SDN fait abstraction de la couche réseau, ce qui permet aux équipes de disposer plus facilement d’un plan de contrôle programmable et centralisé. Le plan de contrôle centralisé gère le flux de données entre les containers, que ce soit au sein d’un cluster ou entre plusieurs clusters. Il découple le plan de contrôle du plan de données. Cette séparation permet aux DevOps et aux ingénieurs réseau de contrôler le trafic réseau de manière programmatique et de répondre aux changements de la demande réseau au fur et à mesure qu’ils se produisent.
Les contrôleurs SDN définissent le comportement du réseau par le biais de règles de haut niveau. Ils attribuent dynamiquement les adresses IP, appliquent les règles et gèrent les itinéraires dans l’ensemble des containers. Dans les environnements hybrides et multiclouds, le SDN gère le réseau à travers les infrastructures en faisant abstraction de la couche matérielle.
Règles réseau. Les règles réseau spécifient comment les pods communiquent entre eux et avec les services externes. Elles sont également cruciales pour la sécurité du réseau et sont particulièrement nécessaires lorsque les services se trouvent dans la même infrastructure de réseau physique.
Dans Kubernetes, les ingénieurs réseau appliquent des règles au niveau de l’espace de noms ou du pod. Les règles de réseau aident les ingénieurs à contrôler le flux de trafic entre les pods dans le cluster et à obtenir une architecture de confiance zéro dans les environnements containerisés. Des outils tels que Cilium ou Istio peuvent aider les containers à atteindre la confiance zéro, de sorte que les composants doivent être vérifiés et autorisés à communiquer, même en interne.
L’exemple suivant montre comment activer le trafic à partir de pods spécifiques uniquement. Supposons qu’il existe deux applications : app-frontend et app-backend. Toutes deux s’exécutent dans le même espace de noms Kubernetes. Vous trouverez ci-dessous un exemple de règle réseau Cilium qui autorise le trafic vers app-backend uniquement à partir de app-frontend.
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
name: "allow-frontend-to-backend"
spec:
description: "Allows traffic from app-frontend to app-backend."
endpointSelector:
matchLabels:
app: app-backend
ingress:
- fromEndpoints:
- matchLabels:
app: app-frontend
toPorts :
- ports:
- port: "80"
protocol: TCP
Enjeux et solutions pour la mise en réseau des containers
Si les containers offrent un certain niveau de flexibilité, ils posent également de nouveaux enjeux en matière de réseau. Voici quelques-uns des enjeux les plus courants et leurs solutions :
– La prolifération des adresses IP.
– Assurer l’isolation du réseau.
– Charges de travail dynamiques en containers.
La prolifération des adresses IP. L’espace de noms réseau d’un hôte attribue des adresses IP uniques aux containers après leur création. Au fur et à mesure que l’application gagne en complexité, elle peut avoir besoin de plus de containers. Elle a donc besoin d’un plus grand nombre d’adresses IP. Les containers sont dynamiques par nature – ils sont fréquemment créés et détruits – ce qui entraîne une allocation et une libération rapides des adresses IP. Cette situation peut rapidement devenir incontrôlable, entraînant l’épuisement des adresses IP et le chevauchement des sous-réseaux.
Ces enjeux font qu’il est difficile pour les ingénieurs réseau de suivre et de gérer les containers, en particulier dans les infrastructures à grande échelle. En fin de compte, il en résulte des performances de réseau médiocres et des échecs de communication.
Une façon de résoudre cette problématique est d’utiliser Cilium, qui prend en charge la gestion des adresses IP. Cilium propose la mise en commun des adresses IP, l’adressage IP à l’échelle du cluster et l’allocation en fonction du sous-réseau, autant d’éléments qui permettent de minimiser la fragmentation potentielle. Cela permet d’éviter l’épuisement des adresses IP, les conflits de sous-réseaux et les chevauchements d’adresses IP dans les environnements Kubernetes multiclusters à forte affluence. Cilium intègre également des plages d’IP de cloud privé virtuel, une surveillance en temps réel et un recyclage automatisé des IP.
Assurer l’isolation du réseau. Tous les containers fonctionnant sur le même réseau hôte partagent les ressources et l’infrastructure réseau sous-jacentes. Si la configuration n’est pas correcte, les utilisateurs peuvent accidentellement accéder aux données d’autres containers, qui sont censées être isolées. Cela constitue une menace de mouvement latéral dans laquelle des acteurs malveillants peuvent compromettre un container. Les ingénieurs réseau doivent configurer correctement les containers de manière à ce que seules les communications voulues aient lieu entre les containers, sans compromettre les performances.
Pour les environnements Kubernetes, la mise en œuvre des règles de réseau Kubernetes au niveau des containers permet d’isoler les charges de travail. Cilium peut aller plus loin et étendre la spécification de la règle réseau standard de Kubernetes via ses propres règles.
Ces règles sont basées sur l’identité et mettent en œuvre des règles à grain fin au niveau des couches 3, 4 et 7 du modèle OSI. Une fois mises en œuvre, elles permettent de contrôler la communication intercontainer en spécifiant explicitement quel pod, groupe de pods (avec les mêmes étiquettes), espaces de noms ou cluster peut communiquer. Envisagez d’intégrer des règles avec un maillage de services si la couche d’application nécessite une isolation de service à service.
Charges de travail dynamiques containerisées. En raison de la nature flexible et éphémère des containers, il est difficile de maintenir des connexions réseau stables entre les services. Les services peuvent ne pas connaître les adresses IP actuelles des autres périphériques, ce qui perturbe la communication.
La solution consiste à introduire des mécanismes de découverte de services si l’adresse IP d’un container change, afin que d’autres services puissent toujours l’atteindre en utilisant un nom DNS stable. Les répartiteurs de charge peuvent également aider à acheminer le trafic vers le bon container, quelle que soit l’adresse IP.
Quels sont les outils pour mettre des containers en réseau ?
Les outils de mise en réseau de containers suivants sont à la disposition des ingénieurs réseau.
Cilium. Cilium est une couche CNI basée sur eBPF pour Kubernetes, développée par Isovalent, lequel fait maintenant partie de Cisco. Cette solution fait partie de l’écosystème CNCF et dispose d’une version Open source, ainsi que d’une version payante. Cillium présente de nombreux cas d’utilisation différents, notamment les suivants :
– Fonctionne comme un maillage de services (alias Service mesh)
– Fournit un répartiteur de charge entre les services, y compris un répartiteur de charge basé sur le chemin de données express pour une faible latence.
– Permet le chiffrement.
– Fournit un réseau de couche 3 qui est également conscient du protocole de couche 7 et applique des règles réseau sur les couches 3, 4 et 7.
– Remplace kube-proxy.
– Gère la bande passante.

Calico. Calico est un outil de mise en réseau et de sécurité Kubernetes qui prend en charge plusieurs modèles de réseau. Grâce à son approche de réseau de couche 3, Calico est très évolutif dans les grands systèmes distribués où le trafic de diffusion de couche 2 est ingérable. Il utilise également eBPF pour réduire les frais généraux et augmenter le débit pour une mise en réseau plus rapide.
La règle réseau de Calico peut prendre en charge d’autres orchestrateurs de containers, tels qu’OpenShift. En matière de sécurité, Calico prend en charge les protocoles IPsec et WireGuard pour le chiffrement des données en transit.
Flannel. Flannel est un outil de réseau Overlay Kubernetes léger qui ne nécessite qu’une configuration minimale et une faible complexité opérationnelle. Conçues dans un souci de simplicité, ses fonctionnalités réseau de base constituent un point de départ idéal pour les déploiements de petite et moyenne taille. Par conséquent, il manque des fonctionnalités avancées nécessaires aux environnements à grande échelle, telles que les règles de réseau et le chiffrement.
Au fur et à mesure de l’évolution de leurs besoins, les entreprises pourront plus tard passer à des options plus riches en fonctionnalités.
Istio. Istio est un maillage de services (Mesh) Open source permettant de gérer les communications de service à service dans les microservices. Istio se concentre sur la gestion du trafic, la sécurité et l’observabilité. Ses caractéristiques sont les suivantes :
– Équilibrage automatique de la charge.
– Gestion du trafic.
– Une couche de règles interchangeable.
– Une observabilité et une surveillance complètes avec un minimum de changements, voire aucun, dans le code du service.
Istio est idéal pour les architectures complexes et fonctionne en tandem avec d’autres interfaces réseau de containers pour une stratégie de mise en réseau plus complète.
Quelles sont les performances des réseaux de containers ?
La surveillance du trafic est essentielle à la fiabilité et aux performances des réseaux de containers. La visibilité est nécessaire pour identifier les goulots d’étranglement et les défaillances potentielles du réseau qui pourraient affecter la production. Des outils tels que Prometheus et Grafana permettent de surveiller le trafic et de suivre la latence et l’utilisation de la bande passante.
Pour garantir la qualité de service, appliquez des règles qui donnent la priorité aux services critiques par rapport au trafic moins important. Grâce à une allocation efficace des ressources, les équipes peuvent éviter la dégradation des performances.