Les plugins CNI

Pourquoi

À la leçon précédente, nous avons vu que Kubernetes demande un réseau plat et sans NAT entre pods, mais n'en contient pas l'implémentation. Quelqu'un doit, à chaque naissance de pod, créer une interface, lui donner une adresse, installer les routes. Quelqu'un doit aussi faire en sorte que le nœud B sache joindre les pods du nœud A. Ce quelqu'un est le plugin CNI.

Sans plugin, un cluster ne fonctionne pas : les nœuds restent NotReady, les pods restent en ContainerCreating. Avec un mauvais plugin, il fonctionne mal : trop lent à grande échelle, incapable d'appliquer les NetworkPolicies, ou impossible à diagnostiquer. Et comme le plugin se choisit à la création du cluster et se change très difficilement ensuite, il vaut mieux le choisir en connaissance de cause.

Cette leçon décrit le contrat entre le moteur de conteneurs et le plugin, les techniques de transport entre nœuds, les plugins les plus répandus, puis fait l'expérience concrète : un cluster kind sans plugin, sur lequel on installe Cilium, celui que Scaleway installe par défaut sur Kapsule.

Les concepts

La spécification CNI

CNI (Container Network Interface) est une spécification maintenue par le projet containernetworking, dont la version actuelle est la 1.1.0. Elle est volontairement minuscule : un plugin CNI est un exécutable. Le moteur de conteneurs (containerd, CRI-O) le lance à chaque événement du cycle de vie d'un pod, lui passe des paramètres par variables d'environnement et sa configuration en JSON sur l'entrée standard, puis lit le résultat en JSON sur la sortie standard.

Les opérations, annoncées par CNI_COMMAND :

Les variables d'environnement identifient le pod : CNI_CONTAINERID (l'identifiant du sandbox), CNI_NETNS (le chemin de son espace de noms réseau), CNI_IFNAME (le nom de l'interface à créer, en pratique eth0), CNI_ARGS (arguments supplémentaires, dont le nom et le namespace du pod côté Kubernetes), CNI_PATH (les répertoires où chercher d'autres binaires).

La configuration est une liste de plugins (fichier .conflist) exécutés en chaîne : un plugin « principal » crée l'interface, puis des plugins « méta » complètent (limitation de bande passante, réglage des ports, etc.). Voici un exemple minimal, illustratif et non celui d'un plugin réel :

{
  "cniVersion": "1.1.0",
  "name": "reseau-exemple",
  "plugins": [
    {
      "type": "bridge",
      "bridge": "cni0",
      "isGateway": true,
      "ipMasq": false,
      "ipam": {
        "type": "host-local",
        "ranges": [[{ "subnet": "10.244.1.0/24" }]]
      }
    },
    { "type": "portmap", "capabilities": { "portMappings": true } }
  ]
}

Où cela se trouve sur un nœud

Par convention, le moteur de conteneurs lit :

• /etc/cni/net.d/ : les fichiers de configuration. Quand plusieurs fichiers existent, le moteur utilise le premier dans l'ordre alphabétique (c'est pourquoi les installeurs préfixent leur fichier d'un nombre, 05-cilium.conflist). Retirer ce fichier, ou le renommer, est une façon de désactiver un plugin ;
• /opt/cni/bin/ : les binaires, par nom de plugin (bridge, host-local, portmap, cilium-cni...).

Ces chemins se règlent dans la configuration du moteur de conteneurs. Quand les pods restent en ContainerCreating avec un message qui mentionne le réseau, les deux premières vérifications portent sur ces répertoires : le fichier existe-t-il, et le binaire qu'il nomme est-il présent ?

L'IPAM

L'attribution des adresses s'appelle IPAM (IP Address Management). Dans CNI, c'est une responsabilité qu'un plugin principal peut déléguer à un plugin d'IPAM, appelé avec les mêmes variables et la même configuration : « le plugin d'IPAM doit déterminer l'adresse de l'interface, la passerelle et les routes, et les renvoyer au plugin principal », dit la spécification. Le plugin d'IPAM classique, host-local, pioche dans le sous-réseau du nœud et mémorise les adresses attribuées dans des fichiers locaux.

Deux grandes organisations existent pour les sous-réseaux de nœuds :

• Piloté par Kubernetes : le contrôleur du plan de contrôle attribue un podCIDR à chaque nœud (leçon 1), et le plugin le lit (mode ipam.mode=kubernetes de Cilium, par exemple) ;
• Piloté par le plugin : le plugin tient son propre registre, souvent dans des objets personnalisés (CRD), et attribue des sous-réseaux ou des adresses plus souplement, parfois à l'adresse près. Le mode par défaut de Cilium (cluster-pool) fonctionne ainsi, de même que Calico, avec ses IPPool.

Joindre des pods sur d'autres nœuds : trois familles

C'est la décision d'architecture principale d'un plugin. Le pod a du nœud 1 envoie un paquet vers le pod b du nœud 2. Le réseau des nœuds ne connaît pas, a priori, l'adresse de b. Trois solutions.

1. Routage direct (native routing). On apprend au réseau où sont les sous-réseaux de pods. Soit tous les nœuds sont sur un même réseau de niveau 2, et chacun reçoit une route par sous-réseau voisin (« 10.244.2.0/24 via l'adresse du nœud 2 ») ; soit le réseau sous-jacent (routeur, fournisseur cloud) est informé. Avantage : aucune enveloppe, donc ni surcoût de taille ni travail d'encapsulation. Contrainte : le réseau doit accepter de transporter des paquets dont l'adresse source ou destination n'est pas celle d'un nœud, et connaître les routes. Chez Cilium, c'est routingMode=native avec ipv4NativeRoutingCIDR ; l'option autoDirectNodeRoutes installe les routes entre nœuds qui partagent un réseau de niveau 2.

2. Encapsulation (overlay). Le paquet du pod est enveloppé dans un paquet UDP entre nœuds, que le réseau sous-jacent transporte sans rien savoir des pods. Les deux protocoles courants :

• VXLAN (Virtual eXtensible LAN) : une trame Ethernet est enveloppée dans un paquet UDP ; port 8472 chez Cilium (le port IANA est 4789) ;
• Geneve : un format plus extensible, car il porte des options arbitraires, que certains plugins utilisent pour transmettre des métadonnées (identité de sécurité) ; port 6081.

Avantage : fonctionne partout, sur n'importe quel réseau, sans configuration préalable. Coûts : un en-tête supplémentaire (environ 50 octets pour VXLAN, d'après la documentation de Cilium) qui réduit la MTU utile, et un peu de travail pour le noyau. C'est le mode par défaut de Cilium : « quand aucune configuration n'est fournie, Cilium fonctionne dans ce mode », avec VXLAN. Voir ICMP et MTU : l'encapsulation est le cas d'école du trou noir PMTU, et il faut que la MTU des pods tienne compte du surcoût (les plugins la calculent généralement seuls). Voir aussi le glossaire.

3. BGP. Les nœuds (ou le plugin) échangent les routes de pods avec les routeurs du réseau par le protocole BGP (glossaire) : le réseau apprend « 10.244.2.0/24 est derrière le nœud 2 ». Pas d'enveloppe, et les pods deviennent joignables depuis l'extérieur du cluster si le réseau le permet. C'est l'approche traditionnelle de Calico, utile dans un centre de données où l'on contrôle les routeurs ; inapplicable sur la plupart des clouds publics, où on ne peut pas parler BGP au réseau virtuel.

    flowchart LR
  subgraph N1["Nœud 1 (192.0.2.11)"]
    A["Pod a<br/>10.244.1.5"]
  end
  subgraph N2["Nœud 2 (192.0.2.12)"]
    B["Pod b<br/>10.244.2.7"]
  end
  A -- "routage direct : paquet 10.244.1.5 vers 10.244.2.7" --> B
  A -. "encapsulation : UDP 192.0.2.11 vers 192.0.2.12, contenant le paquet du pod" .-> B
  

Les adresses du schéma sont des adresses de documentation (RFC 5737) : on y voit que, avec l'encapsulation, le réseau sous-jacent ne voit que des paquets entre nœuds.

Le panorama

Quatre plugins couvrent la plupart des situations ; tous respectent CNI, et sont décrits ici d'après leur documentation.

Cilium (glossaire). Un plugin construit sur eBPF (glossaire), la technique qui permet d'exécuter de petits programmes vérifiés dans le noyau Linux, sans modifier le noyau. Cilium s'en sert pour le transfert des paquets, la répartition de charge des Services (il peut remplacer kube-proxy, leçon 4), les NetworkPolicies, le chiffrement, l'observabilité (Hubble). Routage : encapsulation VXLAN par défaut, Geneve possible, ou routage natif. Il applique les NetworkPolicies Kubernetes et ses propres politiques (CiliumNetworkPolicy), plus fines (couche 7, noms DNS). C'est le plugin par défaut chez Scaleway pour Kapsule.

Calico. Le plus ancien des plugins à politiques de sécurité. Historiquement construit sur le routage et BGP : il installe une route par sous-réseau de pod, et peut distribuer ces routes par BGP. Il propose aussi les encapsulations IP-in-IP (IPv4 seulement) et VXLAN, avec un mode CrossSubnet qui n'encapsule que le trafic qui franchit une frontière de sous-réseau. Sa mise en œuvre des politiques passe par iptables ou nftables, et il propose un plan de données eBPF en option. Ses objets IPPool portent le choix d'encapsulation.

Flannel. Le plus simple : il donne à chaque nœud un sous-réseau et assure le transport entre nœuds, par défaut en VXLAN. Il n'applique pas de NetworkPolicies. Adapté à un petit cluster de laboratoire ou à une distribution légère, pas à un cluster où l'on cloisonne les applications.

kindnet. Le plugin par défaut de kind : minimal, il crée les interfaces des pods et installe sur chaque nœud les routes vers les sous-réseaux des autres nœuds, qui partagent un même réseau Docker. Conçu pour des clusters de test, pas pour la production.

En pratique

On reconstruit le cluster formation sans plugin par défaut, puis on installe Cilium. Les commandes sont celles de la documentation de Cilium (version 1.20.2 au moment de la rédaction) ; les sorties ne sont pas reproduites, seulement décrites.

Un cluster kind sans plugin

La configuration reprend notre topologie (1 plan de contrôle, 2 nœuds de travail), avec le champ disableDefaultCNI de kind. Enregistrez-la dans kind-cilium.yaml :

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
  - role: worker
  - role: worker
networking:
  disableDefaultCNI: true

$ kind delete cluster --name formation
$ kind create cluster --name formation --config kind-cilium.yaml
$ kubectl get nodes

disableDefaultCNI: true empêche kind d'installer kindnet. Après la création, kubectl get nodes affiche les trois nœuds en NotReady : la documentation de Cilium le dit, « les nœuds restent NotReady tant que Cilium n'est pas déployé ». kubectl describe node formation-worker signale dans sa condition Ready que le réseau n'est pas prêt (plugin CNI non initialisé). Les pods de kube-system qui ne dépendent pas du réseau du pod (ceux en hostNetwork) tournent ; CoreDNS, lui, reste Pending ou ContainerCreating.

Installer Cilium avec Helm

$ helm repo add cilium https://helm.cilium.io/
$ helm install cilium cilium/cilium --version 1.20.2 \
    --namespace kube-system \
    --set image.pullPolicy=IfNotPresent \
    --set ipam.mode=kubernetes

• --version 1.20.2 épingle la version : un chart non épinglé installerait la dernière, et deux installations successives ne donneraient pas le même cluster ;
• --namespace kube-system : Cilium est une infrastructure, il vit avec les composants système ;
• image.pullPolicy=IfNotPresent évite de retélécharger les images si elles sont déjà présentes (utile avec kind, qui permet de les précharger avec kind load docker-image pour ne pas dépendre du réseau) ;
• ipam.mode=kubernetes : Cilium utilise les podCIDR que le plan de contrôle a attribués à chaque nœud (leçon 1), au lieu de tenir son propre registre d'adresses (mode cluster-pool, le défaut). Sur kind, la documentation recommande ce réglage.

Helm installe un DaemonSet cilium (l'agent, un pod par nœud), un Deployment cilium-operator, et dépose sur chaque nœud la configuration CNI et le binaire. Le DaemonSet démarre, écrit son fichier dans /etc/cni/net.d/, et les nœuds passent à Ready.

$ kubectl -n kube-system rollout status ds/cilium
$ kubectl get nodes

Les trois nœuds sont maintenant Ready, et CoreDNS peut démarrer.

Installer avec la CLI cilium

La CLI cilium propose une alternative qui choisit des réglages adaptés à l'environnement détecté :

$ cilium install --version 1.20.2
$ cilium status --wait

cilium status --wait attend que l'agent et l'opérateur soient prêts et affiche un résumé de chaque composant. Les deux méthodes (Helm et CLI) installent les mêmes composants. Pour un déploiement versionné dans Git (GitOps), préférez Helm avec un fichier de valeurs, qui s'intègre à Argo CD ; la CLI sert aux essais et au diagnostic.

Valider

$ cilium status
$ cilium connectivity test

cilium connectivity test déploie un namespace de test (cilium-test-1) avec des clients et des serveurs, et lance une batterie de scénarios : pod à pod sur le même nœud, entre nœuds, vers des Services, vers l'extérieur, avec des politiques. Il dure plusieurs minutes et dépend de l'accès à Internet. C'est le moyen le plus rapide de savoir que le réseau tient ses promesses ; sur kind, certains scénarios (ceux qui supposent un équilibreur externe, par exemple) peuvent être ignorés.

Puis, du côté nœud :

$ docker exec formation-worker ls /etc/cni/net.d/
$ docker exec formation-worker ls /opt/cni/bin/

Vous y retrouvez le fichier de configuration de Cilium (dans net.d) et son binaire cilium-cni (dans bin), à côté des binaires standard du projet CNI (host-local, portmap, loopback...).

Sur Kapsule

Chez Scaleway, Cilium est le plugin par défaut d'un cluster Kapsule ; Calico est proposé en option, par le champ cni de la création du cluster (dans le fournisseur Terraform : cni = "cilium" ou "calico"). Le choix se fait à la création : un cluster existant ne change pas de plugin. Vous n'installez donc rien soi-même, mais tout ce qui précède s'applique : l'agent est un DaemonSet de kube-system, cilium status se lance par kubectl -n kube-system exec ds/cilium -- cilium-dbg status, et les plages de pods et de Services sont celles que Scaleway attribue (à relever dans la console avant d'interconnecter un réseau).

Sous le capot

Ce que fait l'ADD de Cilium. Quand le kubelet crée un pod, containerd exécute le binaire cilium-cni. Celui-ci ne fait presque rien lui-même : il transmet la demande à l'agent Cilium du nœud, par une socket locale. L'agent crée la paire veth, place une extrémité dans l'espace de noms du pod (eth0) et laisse l'autre sur le nœud (un nom en lxc...), attribue l'adresse par l'IPAM, puis attache des programmes eBPF à l'extrémité côté nœud. À partir de là, les paquets du pod sont traités par ces programmes, qui décident de les livrer à un pod local, de les encapsuler vers un autre nœud, ou de les traduire pour un Service. Il n'y a pas de pont Linux ni de règle iptables par pod : les décisions sont dans des tables (des maps eBPF) que l'agent met à jour.

Ce que fait un plugin à base de pont. Un plugin plus classique (le plugin bridge du projet CNI, ou celui d'un Flannel) crée une paire veth, branche l'extrémité nœud sur un pont Linux (cni0) qui sert de passerelle aux pods du nœud, et laisse la table de routage et iptables faire le reste. C'est plus simple à observer avec les outils habituels (ip, brctl), plus lent à grande échelle, car chaque Service ajoute des règles linéaires (leçon 4).

Pourquoi un DEL fiable compte. Quand un pod disparaît, DEL libère l'adresse. Un DEL perdu (le nœud tombe, le plugin est indisponible) laisse une adresse marquée prise dans l'IPAM : à force, le sous-réseau du nœud se remplit d'adresses fantômes et les nouveaux pods ne démarrent plus. La nouveauté GC de la spécification 1.1 existe pour ce cas : le moteur indique la liste des pods valides, et le plugin purge le reste.

La cohabitation de plusieurs fichiers. Parce que le moteur lit le premier fichier de /etc/cni/net.d, installer un second plugin sans retirer le premier n'en active pas deux : le plus ancien dans l'ordre alphabétique gagne. Les installeurs soigneux désactivent ou renomment les fichiers des autres plugins (Cilium propose une option pour cela).

Pièges courants

Des nœuds NotReady juste après la création. Normal sur un cluster sans plugin, et bloquant tant que le plugin n'est pas installé. Le message du kubelet (kubectl describe node) mentionne NetworkPluginNotReady ou cni plugin not initialized.

failed to find plugin "cilium-cni" in path [/opt/cni/bin]. Dans les événements d'un pod : le fichier de configuration référence un binaire absent. L'agent n'a pas fini de s'installer, ou le répertoire de binaires du moteur n'est pas celui que le plugin remplit (cas de distributions qui déplacent /opt/cni/bin).

Deux plugins installés l'un sur l'autre. On ajoute Cilium à un cluster qui a déjà Flannel. Les pods anciens gardent le réseau de l'ancien plugin, les nouveaux celui du nouveau, et ils ne se joignent plus. Le remède propre est de recréer le cluster ; une migration en place existe (Cilium la documente, nœud par nœud) mais demande une préparation.

Une MTU trop grande avec l'encapsulation. Les petits appels passent, les gros transferts bloquent : c'est le trou noir PMTU de la leçon ICMP et MTU, avec un tunnel qui retire environ 50 octets. Les plugins ajustent la MTU des pods, mais un réseau sous-jacent particulier (VPN, interconnexion) peut la réduire davantage ; on la règle alors explicitement.

Un pare-feu qui bloque le tunnel. L'encapsulation passe par un port UDP entre nœuds (8472 pour le VXLAN de Cilium, 6081 pour Geneve). Sur un fournisseur dont les groupes de sécurité filtrent le trafic entre nœuds, il faut l'autoriser ; sinon les pods d'un même nœud se parlent, mais pas ceux de nœuds différents. Symptôme classique : tout marche tant que les pods sont sur le même nœud.

Un cluster kind qui ne démarre pas de pods de CoreDNS. C'est le comportement attendu avant l'installation du plugin : ne cherchez pas du côté de CoreDNS.

Choisir Flannel puis réclamer des NetworkPolicies. L'API les accepte, rien n'est filtré (leçon 1). Ce choix ne se découvre qu'en testant le filtrage, ce que la leçon 8 propose.

Sécurité

• Le plugin CNI est un composant privilégié. Il s'exécute en root sur chaque nœud, programme le noyau et manipule les espaces de noms de tous les pods : une compromission de l'agent donne la main sur le réseau du nœud. Maintenez-le à jour (les failles sont corrigées dans des versions de maintenance, comme le montre le rythme de publication de Cilium 1.20.x), et limitez qui peut modifier ses objets (CRD, ConfigMap) par le RBAC.
• Les politiques ne valent que si le plugin les applique : choisissez un plugin à politiques, et testez-les (leçon 8).
• Le chiffrement entre nœuds est optionnel. Cilium propose WireGuard et IPsec ; Calico, WireGuard. Sans cela, le trafic des pods circule en clair sur le réseau des nœuds (ou dans les tunnels VXLAN, qui n'ajoutent aucun chiffrement). Sur un cloud souverain où l'on s'engage sur la confidentialité, c'est un point à décider.
• Vérifiez les images et les versions que vous installez : épinglez la version du chart, vérifiez la provenance des images (les projets CNCF signent leurs images, à vérifier avec cosign), et ne déployez pas un manifeste récupéré par curl | kubectl apply sans le relire.
• L'API du plugin (socket de l'agent, Hubble) expose beaucoup d'informations sur le trafic : n'exposez pas l'interface de Hubble sans authentification.

En production

• Choisir, c'est arbitrer. Cilium : fonctionnalités et observabilité maximales, mais une technologie plus profonde (eBPF) à comprendre pour diagnostiquer, et des exigences de noyau récentes. Calico : mature, très répandu dans les centres de données, BGP naturel. Flannel : à réserver aux laboratoires. Sur Kapsule, le choix par défaut (Cilium) est celui que Lyneko suit : on bénéficie de l'intégration, de la documentation et du support du fournisseur.
• Prévoir le mode de routage selon le réseau sous-jacent. L'encapsulation, c'est « ça marche partout » avec un surcoût modéré. Le routage natif, c'est de meilleures performances quand le réseau transporte les routes de pods (un fournisseur qui sait les router, ou une session BGP). Mesurez avant de basculer : le gain dépend de la charge.
• Contrôler la version comme tout composant d'infrastructure. Mettez la version du plugin dans Git, mettez-le à jour nœud par nœud, lisez les notes de version avant chaque montée (changements de valeurs par défaut). Pour Cilium, la documentation distingue les versions stables des versions de développement : n'installez que les stables.
• Superviser le plugin. L'agent expose des métriques Prometheus ; surveillez le nombre de pods sans adresse, les erreurs d'attribution, la pression sur les tables eBPF (cilium-dbg status en résume l'état).
• Prévoir le retour arrière. Changer de plugin sur un cluster existant n'est pas une opération courante ; la plupart des équipes recréent un cluster et migrent les applications, ce qui suppose que tout soit décrit dans Git.

Exercices

1. Lire une configuration (niveau 100). Dans le fichier .conflist d'illustration de la leçon, dites ce que fait chaque plugin, quel sous-réseau est utilisé et qui attribue les adresses.

2. Choisir le transport (niveau 200). Lyneko héberge un cluster auto-géré sur des machines virtuelles Scaleway placées dans un réseau privé. Le réseau privé n'accepte que des paquets dont la source est l'adresse d'une machine. Routage natif ou encapsulation ? Que faut-il ouvrir ?

3. Le cluster qui ne se réveille pas (niveau 200). Après kind create cluster --config kind-cilium.yaml, kubectl get pods -A montre CoreDNS en Pending et les trois nœuds NotReady. Est-ce une panne ? Quelle est la suite ?

4. Les pods qui se parlent à moitié (niveau 300). Sur un cluster neuf avec Cilium en VXLAN, deux pods du même nœud se joignent, mais un pod du nœud 1 ne joint jamais un pod du nœud 2, même par ping direct d'adresse. Donnez deux causes probables et deux vérifications.

Récapitulatif

• Un plugin CNI est un exécutable lancé par le moteur de conteneurs : ADD à la création d'un pod, DEL à sa suppression, CHECK et GC pour la vérification et le nettoyage. La configuration (JSON) est dans /etc/cni/net.d, les binaires dans /opt/cni/bin.
• L'IPAM attribue les adresses, piloté par Kubernetes (podCIDR des nœuds) ou par le plugin.
• Entre nœuds : routage direct (rapide, demande un réseau coopératif), encapsulation VXLAN ou Geneve (marche partout, environ 50 octets de surcoût, attention à la MTU), BGP (routes échangées avec le réseau).
• Cilium (eBPF, VXLAN par défaut, remplace kube-proxy), Calico (routage et BGP, politiques), Flannel (simple, sans politiques), kindnet (tests).
• Sur kind : disableDefaultCNI: true, puis Cilium par Helm (--version épinglée, ipam.mode=kubernetes) ou cilium install. Sur Kapsule : Cilium par défaut, Calico en option, choix à la création.

Pour aller plus loin

• La spécification CNI 1.1.0, pour la forme exacte des configurations et des résultats.
• Le guide de Cilium Getting Started Using Kind et la page Routing de sa documentation.
• La documentation de Calico sur IP-in-IP et VXLAN, pour comparer les modes d'encapsulation.
• La leçon suivante, Le chemin d'un paquet, qui suit un paquet à travers tout ce qui vient d'être installé.