Cilium : le CNI eBPF pour Kubernetes

Cilium est le CNI qui remplace iptables par eBPF : il route le trafic des pods, applique les politiques réseau et raisonne par identité plutôt que par adresse IP. C'est aujourd'hui le réseau de référence pour Kubernetes, adopté par les grands fournisseurs managés. Cette page l'installe sur un cluster, montre son état réel, et démontre une politique réseau qui bloque vraiment, avec des sorties capturées sur un cluster k3d (Cilium v1.19.5). Pour le socle eBPF, voir le hub eBPF.

Ce que vous allez apprendre

Comprendre ce qu'est un CNI et ce que Cilium change
Installer Cilium comme réseau d'un cluster
Vérifier l'état du datapath eBPF
Saisir l'identité de sécurité, le concept clé de Cilium
Appliquer une politique réseau et constater le blocage

Ce qu'est un CNI, et pourquoi Cilium

Kubernetes ne fournit pas le réseau des pods : il délègue à un CNI (Container Network Interface), un composant qui attribue les adresses, route le trafic entre pods et applique les règles. Les CNI classiques (comme flannel) s'appuient souvent sur iptables, dont les performances se dégradent quand le nombre de règles explose.

Cilium remplace cette mécanique par eBPF : le routage, l'équilibrage de charge et le filtrage se font par des programmes chargés dans le noyau, au plus près des paquets. Le gain n'est pas que la performance : Cilium introduit un modèle de sécurité par identité, bien plus adapté à un cluster où les adresses IP changent en permanence.

Prérequis

Un cluster Kubernetes sans CNI par défaut : Cilium doit être le réseau. Sur k3d, on crée le cluster en désactivant flannel (--flannel-backend=none).
kubectl et helm configurés.
Un noyau avec BTF sur les nœuds (voir CO-RE et BTF).

Installer Cilium

On installe Cilium par Helm. Sur un cluster fraîchement créé sans CNI, les nœuds sont NotReady tant que le réseau n'est pas en place : c'est normal, Cilium va les faire passer Ready.

helm repo add cilium https://helm.cilium.io
helm install cilium cilium/cilium -n kube-system --set operator.replicas=1

Une fois les pods Cilium démarrés, les nœuds passent Ready :

kubectl get nodes

NAME                      STATUS   ROLES                  VERSION
k3d-cilium-lab-agent-0    Ready    <none>                 v1.31.5+k3s1
k3d-cilium-lab-server-0   Ready    control-plane,master   v1.31.5+k3s1

Vérifier le datapath

Cilium fournit un état de santé complet, lisible depuis un agent. C'est le premier réflexe pour confirmer que le réseau eBPF fonctionne :

kubectl exec -n kube-system ds/cilium -c cilium-agent -- cilium status

Extrait réel :

Cilium:                 Ok   1.19.5 (v1.19.5-20eaccfe)
Cilium health daemon:   Ok
IPAM:                   IPv4: 8/254 allocated from 10.0.0.0/24
Controller Status:      44/44 healthy
Hubble:                 Ok   Current/Max Flows: 2010/4095 (49.08%), Flows/s: 12.22

L'agent est Ok, l'attribution d'adresses (IPAM) fonctionne, et Hubble (l'observabilité réseau) est actif. Le cluster est opérationnel sous Cilium.

L'identité de sécurité, le concept clé

Voici ce qui distingue vraiment Cilium. Dans un cluster, les pods vont et viennent, leurs adresses IP changent sans cesse : filtrer par IP est fragile. Cilium attribue donc à chaque groupe de pods une identité de sécurité, dérivée de ses étiquettes Kubernetes, et applique les politiques par identité, pas par adresse.

On voit ces identités dans les flux réseau (les nombres ID:...) :

default/client (ID:10135)  <>  default/backend (ID:8803)

Le client a l'identité 10135, le backend 8803. Une politique qui dit « le backend accepte le frontend » se traduit en « l'identité 8803 accepte l'identité du frontend », et reste valable quels que soient les pods créés ou détruits ensuite. C'est stable là où une règle par IP casserait au premier redémarrage de pod.

Appliquer une politique réseau

Mettons l'identité en pratique. On déploie un backend (nginx) et un client, et on vérifie d'abord qu'ils communiquent :

kubectl exec client -- curl -s -o /dev/null -w "HTTP %{http_code}\n" http://backend

HTTP 200

Sans politique, tout le monde parle à tout le monde. On applique alors une CiliumNetworkPolicy qui n'autorise le backend qu'aux pods portant l'étiquette role: frontend :

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: backend-autorise-frontend
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        role: frontend

Le client n'a pas cette étiquette. On relance la même requête :

kubectl exec client -- curl -s -o /dev/null -w "HTTP %{http_code}\n" --max-time 5 http://backend

HTTP 000   (la connexion expire : le trafic est bloqué)

La connexion échoue : Cilium a refusé le trafic du client, tout en laissant passer celui d'un pod role: frontend. La politique est appliquée par le noyau, par identité, sans toucher aux pods eux-mêmes. Pour voir ce blocage se produire en temps réel, c'est le rôle de Hubble, qui affiche chaque flux et son verdict.

Sécurité et points de vigilance

Cilium est le cœur du réseau. Une politique trop restrictive peut couper des services légitimes ; une politique absente laisse tout ouvert. On avance par étapes, en observant avec Hubble avant de resserrer.
Composant privilégié. Les agents Cilium chargent des programmes eBPF sur chaque nœud : ils font partie de la surface sensible à maintenir à jour.
Politiques par défaut. Sans politique, le trafic est autorisé par défaut. Adopter une posture de moindre exposition (default-deny, puis autorisations explicites) est une bonne pratique, à introduire progressivement.
Compatibilité noyau. Certaines fonctions avancées (remplacement complet de kube-proxy, chiffrement) exigent des versions de noyau récentes ; vérifier les prérequis avant de les activer.

Dépannage

Symptôme	Cause probable	Solution
Nœuds `NotReady` après install	CNI pas encore prêt	Attendre les pods Cilium ; `cilium status`
Deux CNI en conflit	flannel non désactivé	Recréer le cluster sans flannel
Une politique ne bloque pas	Mauvais sélecteur d'étiquettes	Vérifier `endpointSelector` et les labels des pods
Trafic bloqué à tort	Politique trop large	Observer avec Hubble, ajuster les `fromEndpoints`

À retenir

Un CNI fournit le réseau des pods ; Cilium le fait avec eBPF au lieu d'iptables.
Les nœuds sont NotReady tant que Cilium n'est pas installé : c'est lui le réseau.
cilium status confirme le datapath, l'IPAM et Hubble.
Cilium raisonne par identité de sécurité (dérivée des étiquettes), pas par adresse IP : stable dans un cluster mouvant.
Une CiliumNetworkPolicy applique le filtrage par identité dans le noyau (HTTP 200 sans politique, blocage avec).
Pour voir les flux et les verdicts, on utilise Hubble.

Prochaines étapes

Hubble : observer le réseau du cluster Voir chaque flux et chaque verdict de politique en temps réel.

Les NetworkPolicies Kubernetes Le standard portable, et ce que Cilium y ajoute.

Le hub eBPF La technologie qui rend ce datapath possible.

Tetragon : sécurité runtime eBPF Le pendant sécurité de l'écosystème Cilium.