Ce qui définit Cilium n’est pas une fonctionnalité en particulier : le réseau, la sécurité et l’observabilité sont tous implémentés sous forme de programmes qui s’exécutent directement dans le noyau Linux, via eBPF, plutôt que greffés au moyen de règles iptables ou d’un proxy sidecar. Ce guide explique ce que cela signifie concrètement : ce qui se passe quand un Pod démarre, comment une décision de politique est prise, et pourquoi le chemin réseau de Cilium est plus rapide que les alternatives qu’il remplace.

eBPF en un paragraphe

eBPF permet de charger de petits programmes spécialisés dans le noyau Linux à l’exécution, sans écrire de module noyau ni modifier le noyau lui-même. Avant qu’un tel programme soit autorisé à se charger, un vérificateur intégré au noyau l’analyse statiquement : il confirme qu’il se termine (pas de boucles non bornées), qu’il reste dans des limites mémoire sûres, et qu’il ne peut ni faire planter ni bloquer le noyau. Un programme qui échoue à cette vérification est purement et simplement rejeté, ce qui permet de laisser des outils en espace utilisateur charger une logique arbitraire dans l’espace noyau. Chaque programme eBPF est compilé et chargé à la volée, et non livré sous forme de binaire de noyau précompilé.

Ce qui se passe quand un Pod démarre

Le kubelet de Kubernetes demande au plugin CNI configuré de mettre en place le réseau d’un nouveau Pod. Avec Cilium comme CNI :

1. Cilium attribue au Pod un network namespace et la configuration IP habituelle, le même travail de base que réalise n’importe quel CNI.
2. Cilium attribue au Pod une identité de sécurité, dérivée de ses labels Kubernetes, et non de son adresse IP. Tous les Pods partageant les mêmes labels pertinents (typiquement ceux du sélecteur de leur Deployment) partagent la même identité. C’est important parce que les IP de Pods sont éphémères et réattribuées en permanence ; une identité liée aux labels reste stable à travers les redémarrages et les replanifications, ce qu’une adresse IP ne pourrait jamais faire.
3. Cilium attache un programme eBPF au network namespace du Pod. À partir de ce moment, ce programme voit et peut agir sur chaque événement réseau impliquant ce Pod : une connexion qui s’ouvre, un paquet qui arrive, une requête qui part vers un autre service ou vers l’extérieur.

Les décisions de politique se prennent par paquet, pas par session

Les pare-feu traditionnels implémentent couramment un « allow established » : une fois qu’une connexion est autorisée, chaque paquet suivant passe sans être réévalué, seules les nouvelles connexions sont vérifiées par rapport à la politique. L’application basée sur eBPF de Cilium évalue chaque paquet individuellement par rapport à la politique en vigueur, et pas seulement l’établissement initial de la connexion.

La conséquence pratique : quand vous modifiez une politique réseau, le changement est immédiatement effectif sur tout le trafic, y compris sur les connexions déjà ouvertes. Il n’y a pas de fenêtre pendant laquelle une session déjà établie continue de circuler selon d’anciennes règles jusqu’à ce qu’elle se ferme puis se rouvre.

L’observabilité vient du même flux d’événements, gratuitement

La même instrumentation eBPF qui prend les décisions de politique génère aussi un événement pour chaque interaction réseau qu’elle observe : tentatives de connexion, trafic autorisé et refusé, requêtes vers des destinations externes. C’est aussi ce qui permet à Cilium d’attribuer le trafic au processus réel qui l’a généré, et pas seulement « ce Pod a parlé à ce Pod », mais quel processus précis à l’intérieur du Pod a ouvert la connexion, un niveau de détail que des approches comme l’inspection profonde de paquets en périphérie d’un sidecar ne peuvent généralement pas reconstituer après coup. Ce flux d’événements est la base de l’outil d’observabilité de Cilium, Hubble, présenté dans les concepts clés de la page d’accueil de cette technologie.

Répartition de charge au niveau du socket : éviter la réécriture de paquets

Atteindre un Service Kubernetes signifie traditionnellement qu’un paquet adressé à l’IP virtuelle du Service est réécrit (NAT) vers l’IP d’un Pod backend réel, une étape historiquement implémentée avec des règles iptables ou IPVS que chaque paquet doit traverser. Cilium effectue à la place cette traduction au niveau de la couche socket, au moment de la connexion, grâce à des hooks eBPF attachés là où un processus appelle connect() ou envoie des données. La connexion de l’application est établie dès le départ en pointant directement vers un backend choisi, plutôt que chaque paquet suivant soit réécrit individuellement en transit. Cela supprime une part significative de surcharge par paquet, particulièrement sensible pour le trafic de service à service à haut débit ou sensible à la latence.

Remplacer entièrement kube-proxy

kube-proxy, inclus dans les binaires Kubernetes standard, est ce qui implémente le routage des Services (ClusterIP, NodePort, etc.) à l’aide de règles iptables ou IPVS par défaut. Cilium peut remplacer kube-proxy purement et simplement, en implémentant cette même logique de routage des Services en eBPF. Au-delà de la performance brute, cela change une caractéristique opérationnelle à connaître : un grand jeu de règles iptables est une structure unique aux éléments interdépendants, et modifier une règle peut impliquer de recharger l’ensemble. Les règles eBPF de Cilium s’apparentent davantage à des entrées indépendantes et atomiques, de sorte qu’un changement sur l’une n’oblige pas à toucher aux autres.

Pourquoi c’est important au-delà de « c’est rapide »

La performance est l’argument phare, mais le point plus profond est architectural : comme Cilium opère au niveau du noyau plutôt qu’à travers une pile de règles iptables ou un sidecar par Pod, le réseau, la politique de sécurité, la répartition de charge et l’observabilité s’appuient tous sur le même flux d’événements et le même point d’application dans le noyau, au lieu de former quatre systèmes distincts qu’il faut chacun configurer, garder synchronisés et supposer d’accord entre eux. Le reste de cette série s’appuie sur ces fondations : préparation du cluster, Gateway API, rédaction de politiques réseau et annonce de routes BGP.