Cilium en production : eBPF, Gateway API et cluster mesh

Objectifs

1. Dire ce qu'eBPF change dans le noyau, et où Cilium s'y accroche.
2. Installer Cilium sur un cluster nu, choisir son IPAM et son mode de routage, et savoir lire ce qui a été chargé.
3. Retirer kube-proxy d'un cluster qui tourne, et mesurer ce que ça change.
4. Donner une adresse joignable à un Service, par LB-IPAM, par annonce L2 puis par BGP.
5. Exposer une application avec Gateway API : matching, filtres, poids, TLS, gRPC, et lire le status quand rien ne marche.
6. Cloisonner sur l'identité plutôt que sur l'adresse IP, sans couper les sondes du kubelet.
7. Autoriser un nom de domaine et non une adresse, et filtrer en HTTP, gRPC et Kafka.
8. Retrouver avec Hubble, et sur des mesures, l'endroit exact où un flux est bloqué.
9. Chiffrer tout le trafic est-ouest, et chiffrer ce que ça coûte.
10. Maîtriser l'adresse source que voit un partenaire extérieur.
11. Fédérer 2 clusters, partager des Service globaux, et mesurer la bascule quand l'un tombe.
12. Observer le runtime avec Tetragon, et passer de l'observation au blocage.
13. Monter Cilium de version sans coupure, et réparer un cluster dont l'agent ne démarre plus.

Comment cette formation est faite

Chaque commande publiée ici a été exécutée, et chaque sortie de terminal est réelle. Les versions aussi ont été vérifiées auprès de la source qui fait autorité plutôt que citées de mémoire : Cilium 1.20.1, Gateway API v1.6.1, Kubernetes 1.36.4, Tetragon 1.7.1.

Le lab n'est pas un cluster managé. Il est monté par kubeadm sur 4 machines nues, sans CNI et sans kube-proxy, parce que c'est le seul montage où l'on peut installer Cilium soi-même, choisir son mode de routage, passer en netkit, activer DSR et fédérer 2 clusters. Le premier kubectl get nodes de la formation répond NotReady sur les 4 machines, et c'est le point de départ, pas une panne.

Les résultats contrariants sont publiés comme les autres. Quand la documentation de Cilium épingle Gateway API v1.6.1 et qu'un cluster managé sort avec le bundle v1.5.1, la formation dit les 2 choses et montre comment le vérifier.

Tous les chapitres suivent la même trame : le problème, un tableau des termes à ne pas confondre, la démonstration mesurée, 2 exemples complets qu'on peut copier et exécuter en entier, les pièges, puis un travail pratique avec son corrigé.

On mesure d'abord, on installe ensuite

Le module 01 ne parle pas de Cilium. Il monte un cluster ordinaire, avec kube-proxy en iptables et un CNI simple, et il y prend 4 mesures : ce que coûte la résolution d'un Service quand il y en a 1000, ce qu'une NetworkPolicy standard ne sait pas exprimer, ce que devient un canary déclaré par annotation sur un Ingress, et combien de temps il faut pour diagnostiquer un flux bloqué avec kubectl et rien d'autre.

Ces 4 chiffres sont la référence. Chaque module suivant y revient et dit ce qu'il en a fait.

Gateway API, et ce que Cilium en implémente

Gateway API est l'API de trafic de la formation partout où elle couvre le besoin. Cilium 1.20 en implémente GatewayClass, Gateway, HTTPRoute, GRPCRoute, TLSRoute, TCPRoute, UDPRoute, BackendTLSPolicy, ReferenceGrant et ListenerSet, et y ajoute une ressource propre, CiliumGatewayClassConfig.

Ce qu'il n'implémente pas est dit aussi : le trafic est-ouest en L7 ne passe pas par Gateway API chez Cilium, mais par CiliumEnvoyConfig et les policies L7. Si vous cherchez un service mesh complet avec sidecar ou ambient mode, c'est la formation Istio qu'il vous faut.

Le fil rouge

Une application, Boutique, vous suit d'un bout à l'autre : un front, une API, un worker, un service gRPC, PostgreSQL et Redis. Elle est déployée sur le cluster ordinaire au module 00, bascule sous Cilium au module 03, s'expose au module 05, prend sa Gateway au module 06, se découpe en 3 namespaces cloisonnés au module 07, se chiffre au module 10 et finit répartie sur 2 clusters au module 12.

Chaque module la fait progresser d'un cran, et chaque travail pratique corrige un défaut réel qu'elle porte encore.

Le lab

4 machines pour le cluster principal, qui porte 14 modules sur 16 : 1 control plane et 3 workers, 4 vCPU et 8 Go de mémoire chacune. Un second cluster de 3 machines n'est nécessaire qu'au module 12 et peut être créé puis détruit ce jour-là. Une petite machine hors cluster sert de pair BGP au module 05.

Vous pouvez les créer sur CETIC Cloud Platform : à la création du compte, une fois l'adresse e-mail activée, 180 euros de crédit sont offerts, valables un mois, largement de quoi suivre toute la formation. Le chapitre « Le lab » détaille la marche à suivre et fournit les vérifications à passer avant d'aller plus loin.

Les machines de ce lab tournaient sous Ubuntu 26.04, kernel 7.0, containerd 2.2.2. Le kernel compte plus que la distribution : netkit demande au moins 6.8, et le chapitre 02.06 donne les contrôles à passer sur le vôtre.

Prérequis

Kubernetes au niveau du quotidien : Pod, Deployment, Service, ConfigMap, Secret, namespace, et l'usage courant de kubectl. Des notions de réseau : adressage, routage, TCP, DNS. La ligne de commande Linux, et un accès ssh avec sudo sur les machines du lab.

Aucune connaissance d'eBPF n'est supposée : le module 02 s'en charge.