Cilium : réseau, sécurité et observabilité Kubernetes portés par un plan de données eBPF
Mise en réseau, sécurité et observabilité basées sur eBPF
En bref
- De quoi s’agit-il ?
- Analyse de cilium/cilium : CNI eBPF qui remplace kube-proxy, politiques L3-L7 par identité, modes overlay VXLAN/Geneve et routage natif BGP, SBOM SPDX sur toutes les images et trois branches stables maintenues.
- À qui s’adresse-t-il ?
- Cilium s'adresse aux équipes Kubernetes qui veulent un CNI capable de remplacer kube-proxy, d'appliquer des politiques L3-L7 par identité et d'observer le trafic, avec le prix d'une dépendance forte aux capacités eBPF du noyau Linux hôte.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Le dépôt a reçu de nouveaux commits au cours des dernières 24 heures.
- En quel langage est-il écrit ?
- Principalement Go, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
eBPF au fondement : du bytecode injecté aux points d'intégration du noyau
Cilium repose sur eBPF, technologie du noyau Linux qui permet l'insertion dynamique de bytecode à divers points d'intégration : entrées-sorties réseau, sockets applicatifs et tracepoints. C'est là que la logique de sécurité, de réseau et de visibilité s'exécute, décrite par le README comme efficace et flexible. Le projet est écrit en Go et affiche 25019 étoiles et 3999 forks au moment de l'indexation.
Cette base technique définit à la fois la force et le périmètre du produit : tout ce que Cilium promet, de l'équilibrage de charge aux politiques de réseau, s'exécute dans le noyau, ce qui explique les performances revendiquées mais aussi l'exigence sur les capacités eBPF de l'hôte. Le README renvoie à eBPF.io pour comprendre la technologie, et ne documente pas dans ses premières pages les versions minimales de noyau, un point à vérifier dans la documentation avant tout déploiement.
Remplacer kube-proxy par des tables de hachage eBPF
L'une des fonctions les plus citées du projet est le remplacement complet de kube-proxy : l'équilibrage de charge distribué, du trafic entre pods comme vers les services externes, s'appuie sur des tables de hachage eBPF décrites comme permettant une échelle presque illimitée. La couche réseau elle-même se présente comme un L3 plat, capable de s'étendre sur plusieurs clusters en routage natif ou en mode overlay.
S'y ajoutent des fonctions avancées annoncées : passerelles ingress et egress intégrées, gestion de bande passante, service mesh, et une visibilité réseau et sécurité approfondie. Le fait de supprimer kube-proxy change la chaîne de dépendances d'un cluster : une composante de moins à mettre à jour, en échange d'une logique de service portée par le démon Cilium lui-même.
Sécurité par identité : des politiques L3-L7 découplées des adresses IP
Le modèle de sécurité de Cilium est présenté comme fondé sur l'identité, découplée de l'adressage réseau : les politiques s'appliquent du L3 au L7, avec une connaissance des protocoles applicatifs. Concrètement, une règle peut viser un type de charge plutôt qu'une plage d'adresses, ce qui résiste aux reprogrammations de pods et aux changements d'échelle.
L'identité est la réponse du projet au problème classique des politiques réseau Kubernetes, dont les règles CIDR vieillissent mal quand les adresses changent. Le README n'entre pas dans le détail du format des politiques dans ses premières sections, la documentation dédiée portant ce contenu. Pour une équipe qui migre depuis des NetworkPolicies standard, le chantier réel consiste à traduire ses règles vers ce modèle par identité, travail que le README invite implicitement à planifier.
CNI : overlay VXLAN et Geneve, ou routage natif avec apprentissage BGP
Comme plugin CNI, Cilium propose plusieurs options de déploiement. Le mode overlay construit un réseau virtuel par encapsulation, VXLAN ou Geneve, couvrant tous les hôtes, avec pour seule exigence une connectivité IP entre eux, condition généralement déjà remplie. Le mode de routage natif utilise la table de routage ordinaire de l'hôte Linux et suppose que le réseau sait router les adresses des conteneurs, avec intégration aux routeurs cloud, aux démons de routage et aux infrastructures IPv6 natives.
Entre les deux, des options flexibles automatisent l'apprentissage et l'annonce des routes dans les topologies courantes : découverte de voisins L2 quand les nœuds partagent un domaine de niveau 2, BGP quand le routage traverse le niveau 3. Ce choix de mode est la première décision d'un déploiement : l'overlay est le chemin le plus court, le routage natif le plus performant là où le réseau le permet, et la documentation de référence détaille les arbitrages.
Trois branches mineures maintenues, les autres déclarées EOL
La politique de support est écrite sans ambiguïté : la communauté maintient les trois dernières versions mineures, les versions stables antérieures étant considérées en fin de vie. Le README tient une table des branches actives avec leur dernier patch, leurs tags d'images et leurs notes de version : v1.20 patchée au 29 juillet 2026, v1.19 et v1.18 au 16 juillet.
Les métadonnées de releases confirment la simultanéité des maintenues : v1.20.1, v1.19.7 et v1.18.13 publiées le même 18 août 2026. Une branche de développement v1.21.0-pre.0 datée du 3 août préfigure la suivante, avec des snapshots quotidiennes de main et des images CI explicitement réservées au test, jamais à la production. Pour un opérateur, la conséquence est directe : votre version doit appartenir à la fenêtre des trois mineures, et toute migration passe par le Cilium Upgrade Guide cité, dont le README recommande la lecture avant chaque montée.
SBOM SPDX sur toutes les images et builds AMD64 et AArch64
Depuis la version 1.13.0, toutes les images Cilium embarquent une nomenclature logicielle, générée au format SPDX, la référence du secteur pour ces documents. Cette pièce de chaîne d'approvisionnement répond aux exigences croissantes de conformité, une politique de sécurité pouvant vérifier le contenu exact d'une image avant admission dans un cluster.
Les images sont distribuées pour AMD64 et AArch64, ce qui couvre les serveurs x86 classiques et l'armement ARM, instances cloud Graviton ou serveurs on-premise. Le canal de distribution officiel est quay.io, sous l'organisation cilium, avec des tags par version correspondant aux branches stables. Pour un environnement régulé, le trio image signée, SBOM vérifiable et version figée se compose directement depuis ce que le dépôt publie, sans outillage additionnel du projet.
Projet CNCF gradué sous Apache-2.0 : lire l'écosystème avant d'installer
Les badges du README placent Cilium parmi les projets gradués de la CNCF, statut atteint après une trajectoire d'incubation et une gouvernance de fondation, avec licence Apache-2.0, des badges BSD et GPL apparaissant également parmi ses métadonnées. Les 1085 tickets ouverts dessinent l'activité d'un projet de cette taille, porté par une communauté Slack et une documentation sur docs.cilium.io.
Avant l'installation, trois vérifications servent de socle : confirmer que vos noyaux hôtes supportent les fonctions eBPF utilisées par la version visée, en consultant la documentation de configuration plutôt que le README ; choisir le mode réseau, overlay ou natif, selon la capacité de votre infrastructure à router les adresses de pods ; et planifier le rythme de mise à jour, puisque la politique des trois mineures impose un passage de version au moins annuel. Les tests de connectivité documentés dans le guide d'installation closent la mise en service.
Conclusion éditoriale
Cilium s'adresse aux équipes Kubernetes qui veulent un CNI capable de remplacer kube-proxy, d'appliquer des politiques L3-L7 par identité et d'observer le trafic, avec le prix d'une dépendance forte aux capacités eBPF du noyau Linux hôte. Avant l'adoption, vérifiez la compatibilité de vos noyaux avec la version visée, choisissez une des trois branches stables maintenues, v1.18 à v1.20, lisez le Cilium Upgrade Guide avant toute montée de version mineure, et tirez les images depuis quay.io en contrôlant leur SBOM SPDX.
Notes de la communauté