Le modèle CNI (Container Network Interface) : Comprendre le fonctionnement du réseau des Pods

La problématique : standardiser la connectivité des conteneurs

Au coeur de Kubernetes se trouve le Pod, l'unité de déploiement fondamentale qui héberge un ou plusieurs conteneurs. Chaque Pod doit obtenir sa propre adresse IP unique au sein du cluster et être capable de communiquer avec d'autres Pods, les Services et le monde extérieur. Comment cette connectivité est-elle établie de manière cohérente, quel que soit l'environnement d'exécution ou la solution réseau sous-jacente ? C'est là qu'intervient le CNI (Container Network Interface).

Le CNI n'est pas une implémentation réseau spécifique, mais plutôt une spécification promue par la Cloud Native Computing Foundation (CNCF). Son objectif est de définir une interface standard entre les orchestrateurs de conteneurs (comme Kubernetes) et les plugins réseau. Plutôt que d'intégrer une logique réseau complexe directement dans Kubernetes, le CNI permet de déléguer la configuration réseau des conteneurs à des plugins externes interchangeables.

Cette approche modulaire offre une flexibilité énorme, permettant aux utilisateurs de choisir le plugin CNI qui correspond le mieux à leurs besoins en termes de performance, de fonctionnalités (support des Network Policies, chiffrement), de modèle réseau (overlay, underlay/routage direct) et d'intégration avec leur infrastructure existante.

Les principes fondamentaux du CNI

La spécification CNI définit un ensemble simple d'opérations qu'un plugin réseau doit implémenter. Les principales opérations sont :

• ADD : Appelée lorsqu'un conteneur (ou plus précisément, un Pod dans Kubernetes) est ajouté au réseau. Le plugin est responsable de la création de l'interface réseau dans le namespace réseau du Pod, de l'attribution d'une adresse IP, de la configuration des routes nécessaires, et de la connexion de cette interface au réseau du noeud hôte.
• DEL : Appelée lorsqu'un conteneur/Pod est supprimé. Le plugin doit nettoyer toutes les ressources réseau allouées lors de l'opération ADD (interface, adresse IP, routes, etc.).
• CHECK : Permet de vérifier si le réseau du conteneur est toujours dans l'état attendu.
• VERSION : Permet à l'orchestrateur de découvrir les versions de la spécification CNI supportées par le plugin.

Les plugins CNI sont généralement des exécutables binaires. Kubernetes (via le Kubelet sur chaque noeud worker) découvre et exécute ces plugins en se basant sur des fichiers de configuration, typiquement situés dans le répertoire /etc/cni/net.d/ sur le noeud. Ces fichiers (souvent au format JSON) décrivent la configuration réseau à appliquer, y compris le type de plugin CNI à utiliser (ex: `calico`, `flannel`, `bridge`) et ses paramètres spécifiques.

Un aspect important est que la spécification CNI inclut également la gestion de l'allocation des adresses IP via des plugins IPAM (IP Address Management). Le plugin CNI principal peut déléguer l'obtention/libération des adresses IP à un plugin IPAM dédié (ex: `host-local`, `dhcp`, ou un IPAM spécifique fourni par le plugin CNI principal).

Le workflow de création d'un Pod avec CNI

Voyons comment le CNI intervient lors de la création d'un Pod sur un noeud worker Kubernetes :

1. Le Scheduler de Kubernetes décide sur quel noeud le Pod doit s'exécuter.
2. Le Kubelet sur le noeud choisi reçoit la spécification du Pod.
3. Le Kubelet interagit avec le Container Runtime (ex: Docker, containerd, CRI-O) pour créer l'infrastructure de base du Pod (comme le conteneur 'pause' qui détient le namespace réseau partagé).
4. Le Kubelet lit la configuration CNI dans /etc/cni/net.d/ pour déterminer quel plugin CNI utiliser et avec quels paramètres.
5. Le Kubelet invoque le plugin CNI principal avec l'opération ADD, en lui passant des informations comme l'ID du conteneur et le chemin vers son namespace réseau.
6. Le plugin CNI (potentiellement en appelant un plugin IPAM) :
   • Crée une paire d'interfaces réseau virtuelles (souvent une paire veth).
   • Place une extrémité de la paire (ex: eth0) dans le namespace réseau du Pod.
   • Attribue une adresse IP (obtenue via IPAM) et configure le masque de sous-réseau sur l'interface eth0 du Pod.
   • Configure la table de routage à l'intérieur du Pod (généralement une route par défaut via l'autre extrémité de la paire veth).
   • Connecte l'autre extrémité de la paire veth au réseau du noeud hôte. La manière dont cela est fait dépend du plugin CNI (ex: connexion à un bridge Linux, à un bridge Open vSwitch, configuration directe du routage BGP avec Calico, etc.). C'est cette étape qui assure la connectivité entre le Pod et le reste du réseau du cluster.
7. Le plugin CNI retourne les détails de la configuration (adresse IP assignée, informations DNS si fournies) au Kubelet.
8. Le Kubelet démarre les conteneurs applicatifs définis dans le Pod, qui héritent alors du namespace réseau configuré par le CNI.

Lorsqu'un Pod est supprimé, le Kubelet appelle le plugin CNI avec l'opération DEL, qui effectue les étapes inverses pour libérer l'adresse IP et supprimer les interfaces et configurations réseau.

L'écosystème des plugins CNI

La force du modèle CNI réside dans la diversité des plugins disponibles, chacun offrant des caractéristiques différentes :

• Flannel : Un plugin simple et populaire, souvent utilisé pour débuter. Il crée un réseau overlay (généralement VXLAN) pour connecter les Pods entre les noeuds.
• Calico : Très populaire en production, il utilise souvent le routage BGP (pas d'overlay nécessaire si l'infrastructure sous-jacente le permet) pour une haute performance. Il offre également une implémentation robuste des Network Policies.
• Cilium : Utilise eBPF (extended Berkeley Packet Filter) pour une performance élevée et des fonctionnalités avancées de sécurité et d'observabilité réseau, y compris l'application des Network Policies au niveau L7 (HTTP).
• Weave Net : Fournit un réseau overlay chiffré par défaut et une implémentation des Network Policies.
• Plugins spécifiques aux fournisseurs Cloud : AWS VPC CNI, Azure CNI, GKE CNI intègrent les réseaux de Pods plus directement avec l'infrastructure réseau du fournisseur cloud.
• Multus CNI : Un 'meta-plugin' qui permet d'attacher plusieurs interfaces réseau (provenant de différents plugins CNI) à un même Pod, utile pour des cas d'usage spécifiques (NFV, séparation trafic de contrôle/données).

Le choix du plugin CNI est une décision d'architecture importante lors de la mise en place d'un cluster Kubernetes, car il impacte la performance, la sécurité, la complexité et les fonctionnalités réseau disponibles.

En conclusion, le CNI est une spécification essentielle qui découple la logique réseau de l'orchestrateur. Il standardise la manière dont les Pods obtiennent leur connectivité IP, offrant aux utilisateurs la liberté de choisir parmi une large gamme de solutions réseau pour répondre à leurs exigences spécifiques.