Aller au contenu
Retour au glossaire
Réseau Kubernetes

Qu'est-ce que Cilium ?

Cilium est un plugin CNI Kubernetes basé sur eBPF qui gère le réseau des pods, les politiques de sécurité et l'observabilité L7. Standard de facto sur les clusters production récents.

À quoi sert Cilium

Cilium est un projet open-source créé par Isovalent en 2017, donné à la CNCF en 2021, qui a atteint le statut Graduated en octobre 2023. C'est aujourd'hui le plugin CNI (Container Network Interface) le plus déployé sur les nouveaux clusters Kubernetes d'entreprise, devant Calico et Flannel. Son originalité technique : utiliser eBPF (Extended Berkeley Packet Filter), un mécanisme du noyau Linux qui permet d'exécuter du code dans le kernel sans modifier le noyau lui-même.

Concrètement, Cilium remplit trois fonctions critiques d'un cluster Kubernetes : il assigne des IP aux pods et route le trafic entre eux (rôle CNI classique), il applique les NetworkPolicies pour autoriser ou bloquer les communications, et il fournit une observabilité réseau profonde (qui parle à qui, en HTTP, gRPC, Kafka).

Pourquoi eBPF change la donne

Les plugins CNI traditionnels (Calico, Weave) s'appuient sur iptables, un système de filtrage réseau Linux des années 2000. À l'échelle d'un cluster avec 1 000 pods et des règles dynamiques, iptables devient le goulot d'étranglement : règles évaluées séquentiellement, latence accrue, complexité de debug.

eBPF remplace cette évaluation linéaire par des programmes compilés et chargés dans le kernel. Les conséquences pratiques observées en production :

  • Latence réseau intra-cluster réduite de 30 à 50% sur les workloads à fort trafic est-ouest (microservices, bases de données distribuées).
  • Politiques L7 : Cilium peut filtrer au niveau HTTP (autoriser GET mais bloquer DELETE) sans sidecar additionnel. Avant, c'était impossible sans service mesh.
  • Visibilité réseau granulaire via Hubble, l'interface d'observabilité de Cilium : flux DNS, requêtes HTTP, latences gRPC, sans modifier les applications.

Cilium et le service mesh

Depuis 2022, Cilium propose une version service mesh sans sidecar Envoy : les fonctions L7 (mTLS, routing avancé, observabilité HTTP/gRPC) sont implémentées directement par eBPF dans le kernel. Le bénéfice : pas de sidecar à déployer, moins de RAM consommée, performances supérieures. Le compromis : encore quelques fonctionnalités Istio absentes (politiques d'authentification fines, routing très spécifique).

Pour une équipe qui démarre avec Kubernetes en 2026, le choix Cilium CNI + Cilium Service Mesh évite la complexité d'Istio dans 80% des cas.

En pratique chez Hidora

Sur Hikube, nous avons standardisé Cilium comme CNI depuis 2023. Les clients qui migrent depuis des clusters Calico observent en moyenne :

  • Latence p95 inter-services réduite de 28%.
  • CPU des noeuds réduit de 8 à 12% (libéré du surcoût iptables).
  • Time-to-detect d'un problème réseau divisé par 4 grâce à Hubble.

La migration depuis Calico vers Cilium prend typiquement 1 à 3 jours par cluster, avec un mode de coexistence pendant la transition.

Quand Cilium n'est pas optimal

Sur des kernels Linux anciens (< 5.4), les fonctionnalités eBPF avancées de Cilium sont indisponibles. Cilium fonctionne toujours mais perd ses différenciateurs. Le prérequis pratique : RHEL 8.5+, Ubuntu 20.04+, kernel 5.4 minimum (5.10+ recommandé).

Pour les clusters très petits (< 10 noeuds) ou les usages strictement bureautiques, un CNI plus simple comme Flannel reste viable.

Services Hidora associés