CNI on Zwindler's Reflection

Flannel et NetworkPolicies : comment ajouter le support avec Cilium en CNI chaining

Sun, 15 Mar 2026 18:00:00 +0200

Flannel, flannel, flannel…

Flannel est un CNI simple et populaire 😢.

C’est le CNI par défaut de k3s, celui que la moitié des tutos kubeadm utilisent, et on le retrouve aussi dans pas mal d’offres managées.

OK, il est simple, il route les paquets entre les pods, il supporte VXLAN et WireGuard, il se configure en 2 minutes. Que demander de plus ?

Ben justement. Il y a un truc que flannel ne fait pas : les NetworkPolicies. (Et c’est très grave).

Flannel is focused on networking. For network policy, other projects such as Calico can be used.

[Edit] Contrairement à ce que j’écris ici, flannel supporte en fait les NetworkPolicies depuis au moins 2 ans, via l’implémentation de référence kube-network-policies du projet Kubernetes. L’option n’est pas mise en avant dans le README et ce n’est probablement pas plus recommandé en production, mais elle existe. Voir la documentation officielle.

Et le piège, c’est que si vous n’avez pas lu cette petite ligne dans le README.md, rien ne vous le dit explicitement.

Vous pouvez parfaitement créer des objets NetworkPolicy dans votre cluster, kubectl apply ne bronchera pas, kubectl get netpol vous les listera gentiment. Sauf que… elles ne sont pas enforced. Le trafic passe quand même. Votre deny-all ne deny rien du tout.

On vérifie pour être bien sûr

Avant de résoudre quoi que ce soit, vérifions que le problème existe. En partant du prérequis qu’on a un cluster Kubernetes qui a flannel comme CNI et que tout est fonctionnel, on va déployer deux pods dans deux namespaces différents : un client (curl) et un serveur (nginx).

On vérifie que le client peut joindre le serveur :

kubectl exec -n netpol-test-a client -- \
 curl -s --max-time 5 http://server.netpol-test-b.svc.cluster.local

On obtient la page d’accueil nginx. Jusque-là, tout est normal. Maintenant, on applique une NetworkPolicy deny-all sur le namespace du serveur :

# 01-deny-all-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: deny-all-ingress
 namespace: netpol-test-b
spec:
 podSelector: {}
 policyTypes:
 - Ingress

kubectl apply -f 01-deny-all-ingress.yaml

Et on re-teste :

kubectl exec -n netpol-test-a client -- \
 curl -s --max-time 5 http://server.netpol-test-b.svc.cluster.local

Résultat : la page nginx s’affiche toujours. La NetworkPolicy est bien créée (kubectl get netpol -n netpol-test-b la montre), mais elle n’est pas enforced. Le trafic passe comme si de rien n’était.

C’est le comportement attendu avec flannel (par défaut). Flannel ne fait que du routage L3 (overlay VXLAN ou WireGuard). Il n’implémente pas de contrôleur NetworkPolicy. Les objets existent dans etcd, mais personne ne les traduit en règles de filtrage.

On nettoie la policy avant de passer à la suite :

kubectl delete -f 01-deny-all-ingress.yaml

Les alternatives pour ajouter le support

Pendant longtemps j’ai pensé que c’était une fatalité. Je pense toujours que n’est pas un bon choix pour n’importe quelle production.

MAIS récemment, j’ai découvert qu’il était possible de chaîner les CNI au sein d’un même cluster, et ainsi d’avoir un CNI qui gère la majorité des tâches (ici Flannel) et un autre qui se charge d’autres tâches, comme par exemple enforcer des Netpols.

C’est d’ailleurs le principe de Canal, que je connaissais de nom mais que je n’avais jamais exploré. En fait, c’est ni plus ni moins qu’un manifeste qui déploie Flannel comme CNI principal avec Calico pour l’enforcing des NetOK fine, it’s truepols !

Canal was the name of Tigera and CoreOS’s project to integrate Calico and flannel.

Note : le projet GitHub a été archivé en octobre 2025 mais en théorie ça devrait encore fonctionner, si on trouve la doc correcte (pas trouvé, les liens sont KO, mais j’ai pas vraiment cherché non plus).

Vous avez donc compris le principe, on va ajouter un composant qui va watch les objets NetworkPolicy et les traduire en règles de filtrage effectives (iptables, eBPF, nftables…), sans toucher au flannel existant. C’est ce qu’on appelle le “CNI chaining” ou le mode “policy-only”.

Il existe plusieurs solutions :

Calico (Canal), Historiquement, la combinaison flannel + Calico s’appelle “Canal”, dont je viens de parler. Mais le manifeste Canal officiel embarque son propre flannel dans le même DaemonSet que calico-node. Si votre flannel est déjà installé et géré (par vous, par un opérateur, par un provider…), vous ne voulez probablement pas le remplacer. Et l’opérateur Tigera (la méthode Helm “officielle”) ne supporte pas non plus le déploiement en mode policy-only sur un flannel existant. Bref, c’est faisable mais ça nécessite un peu d’effort. Flemme.

kube-router, kube-router peut fonctionner en mode firewall-only (--run-firewall=true) et n’a besoin que d’iptables/ipset. C’est d’ailleurs ce que k3s utilise par défaut pour les NetworkPolicies. C’est la solution la plus légère (a priori ~50 Mo de RAM par node). Vérifiez que votre kernel dispose du module ip_set, sinon ça ne fonctionnera pas.

Cilium en mode CNI chaining, C’est la solution que j’ai retenue et qu’on va détailler. Cilium s’attache aux interfaces veth créées par flannel et ajoute ses programmes eBPF pour le policy enforcement. Pas de dépendance à iptables ou ipset, et en bonus on récupère Hubble pour l’observabilité réseau.

Installer Cilium en mode CNI chaining

Prérequis

Un cluster Kubernetes fonctionnel avec flannel
helm v3+
Un kernel >= 4.19 (idéalement >= 5.10 pour toutes les features eBPF)

Récupérer la configuration CNI de flannel

Cilium en mode chaining doit connaître la configuration CNI existante. On va la récupérer depuis un node :

kubectl debug node/$(kubectl get nodes -o jsonpath='{.items[0].metadata.name}') \
 -it --image=busybox -- cat /host/etc/cni/net.d/10-flannel.conflist

Sur mon cluster, ça donne :

{
 "name": "cbr0",
 "cniVersion": "0.3.1",
 "plugins": [
 {
 "type": "flannel",
 "delegate": {
 "hairpinMode": true,
 "isDefaultGateway": true
 }
 },
 {
 "type": "portmap",
 "capabilities": {
 "portMappings": true
 }
 }
 ]
}

Notez le champ name (ici cbr0). On en aura besoin.

Créer le ConfigMap de chaining

On va créer un ConfigMap qui reprend la config flannel et y ajoute le plugin cilium-cni en chaining :

apiVersion: v1
kind: ConfigMap
metadata:
 name: cni-configuration
 namespace: kube-system
data:
 cni-config: |-
 {
 "name": "cbr0",
 "cniVersion": "0.3.1",
 "plugins": [
 {
 "type": "flannel",
 "delegate": {
 "hairpinMode": true,
 "isDefaultGateway": true
 }
 },
 {
 "type": "portmap",
 "capabilities": {
 "portMappings": true
 }
 },
 {
 "type": "cilium-cni",
 "chaining-mode": "generic-veth"
 }
 ]
 }

Attention : le champ name doit correspondre à celui de votre conflist flannel. Si le vôtre s’appelle cni0 ou autre chose, adaptez.

Avant d’appliquer, vérifiez aussi que votre CNI utilise bien des interfaces veth (c’est le cas par défaut avec flannel, mais mieux vaut s’en assurer). Depuis un node :

ip -d link | grep veth

Vous devriez voir des interfaces de type veth correspondant à vos pods, par exemple :

103: lxcb3901b7f9c02@if102: <BROADCAST,MULTICAST,UP,LOWER_UP> ...
veth addrgenmode eui64 numtxqueues 1 numrxqueues 1

Si c’est bien le cas, le mode generic-veth de Cilium fonctionnera. On applique :

kubectl apply -f cilium-cni-configmap.yaml

Installer Cilium via Helm

helm repo add cilium https://helm.cilium.io/
helm repo update

Voici les values pour le mode chaining :

# cilium-values.yaml
cni:
 chainingMode: generic-veth
 customConf: true
 configMap: cni-configuration
 install: true

routingMode: native
enableIPv4Masquerade: false
enableIPv6Masquerade: false

hubble:
 enabled: true
 relay:
 enabled: true
 ui:
 enabled: true

Les points importants :

cni.chainingMode: generic-veth, c’est le mode chaining, Cilium s’attache aux interfaces veth existantes
cni.customConf: true + cni.configMap, on fournit notre propre config CNI
routingMode: native, flannel gère le routage, pas Cilium
enableIPv4Masquerade: false, flannel gère le masquerading
hubble.enabled: true, l’observabilité réseau, c’est le gros bonus de Cilium

helm install cilium cilium/cilium --version 1.19.1 \
 --namespace kube-system \
 -f cilium-values.yaml

On attend que tout soit prêt :

kubectl rollout status daemonset/cilium -n kube-system --timeout=120s

Vérification

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

Ce qui nous intéresse :

Kubernetes: Ok 1.35 (v1.35.0) [linux/amd64]
CNI Chaining: generic-veth
Cilium: Ok 1.19.1
Hubble: Ok

La ligne CNI Chaining: generic-veth confirme que Cilium fonctionne en mode chaining et ne remplace pas flannel.

Important : les pods qui existaient avant l’installation de Cilium ne sont pas automatiquement gérés par Cilium. Il faut les redémarrer pour que Cilium attache ses programmes eBPF. Pensez à faire un kubectl rollout restart de vos workloads de test (ou à les recréer).

Tester les NetworkPolicies

C’est le moment de vérité. On re-applique notre deny-all :

kubectl apply -f 01-deny-all-ingress.yaml

kubectl exec -n netpol-test-a client -- \
 curl -s --max-time 5 http://server.netpol-test-b.svc.cluster.local

Résultat : timeout ! Cette fois, la NetworkPolicy est bien enforced. Le trafic est bloqué.

J’ai enchaîné avec les autres scénarios classiques de NetworkPolicy, et tout fonctionne :

Allow ingress sélectif par namespace, en ajoutant une policy qui autorise le trafic depuis netpol-test-a uniquement, le curl passe depuis ce namespace mais reste bloqué depuis default. L’isolation par namespace fonctionne.
Deny-all egress, en bloquant tout le trafic sortant du client, même la résolution DNS est bloquée (timeout immédiat).
Allow egress sélectif, en autorisant uniquement le DNS (port 53) et le serveur (port 80 dans le namespace netpol-test-b), le curl vers le serveur passe mais curl http://example.com reste bloqué.

Bref, ingress, egress, sélectif par namespace, tout marche comme attendu.

Bonus : Hubble, l’observabilité réseau

C’est pour moi le vrai atout de Cilium par rapport aux alternatives. Hubble permet de voir en temps réel les flux réseau et les verdicts de policy :

kubectl exec -n kube-system ds/cilium -- \
 hubble observe --namespace netpol-test-b --last 5

Mar 15 13:20:42.287: netpol-test-a/client:40066 (ID:9745) ->
netpol-test-b/server:80 (ID:22271)
policy-verdict:none ALLOWED (TCP Flags: SYN)

On voit le pod source, le pod destination, le port, l’identité Cilium, et le verdict de policy. Quand vous debuggez une NetworkPolicy qui ne se comporte pas comme prévu, c’est vraiment pratique.

Combien ça coûte en ressources ?

Sur mon cluster (3 nodes), voici ce que Cilium consomme juste après installation :

Composant	Par node	RAM
cilium agent	oui (DaemonSet)	~160 Mo
cilium-envoy	oui (DaemonSet)	~22 Mo
cilium-operator	non (2 replicas)	~42 Mo
hubble-relay	non (1 replica)	~16 Mo
hubble-ui	non (1 replica)	~21 Mo

Soit environ 180 Mo par node pour l’agent + envoy. J’ai pas de point de comparaison par rapport à Calico ou kube-router, mais ça me semble acceptable, et le fait de pouvoir avoir une vision complète sur la totalité des flux avec Hubble justifie largement le surcoût (à mon avis).

Conclusion

Si jamais vous n’avez pas le choix et que vous devez composer avec flannel, et que vous voulez boucher le trou béant de sécurité que représente l’absence d’enforcement des Netpols, sachez donc qu’il est maintenant possible :

d’activer l’ajout de l’implémentation officielle (même si je ne l’ai pas testée, ça doit marcher)
de chaîner un autre CNI pour le faire

À défaut de l’avoir en CNI pour tout (tout bon cluster Kubernetes a Cilium comme CNI), Cilium en mode CNI chaining (generic-veth) est une solution plutôt sympa pour combler ce manque. Il ne touche pas au flannel existant, il s’y greffe. Et en bonus, vous récupérez Hubble pour l’observabilité réseau, ce qui est franchement appréciable.

Have fun :)

J'ai testé pour vous : k8e (Kubernetes Easy Engine)

Fri, 19 Sep 2025 16:00:00 +0000

Tu ne faisais pas un livre sur Kubernetes, toi ?

Oui ! Et j’ai une bonne nouvelle : mon livre “Kubernetes : 50 solutions pour les postes de développement et les clusters de production”, édité par Eyrolles, sortira le 16 octobre 2025 ! Vous pouvez suivre l’état d’avancement du projet sur 50ndk.zwindler.fr. Je ferai une annonce propre quand j’aurai la couverture définitive à vous montrer :3.

En attendant la sortie, je “libère” un autre chapitre qui avait été abandonné lors de la sélection finale du livre : celui sur k8e (Kubernetes Easy Engine). Si vous suivez le blog attentivement, vous vous souviendrez peut-être que j’avais fait pareil pour k8s-tew (K8S : the easier way), qui n’avait aussi pas eu la chance de figurer dans la liste des 50 méthodes qui ont leur place dans mon livre :-P.

Mais revenons à k8e !

k8e est un wrapper pour k3s qui permet d’installer facilement un cluster multi-nodes avec Cilium configuré comme CNI et en mode kube-proxy replacement. Dans la philosophie, c’est vraiment pas beaucoup plus que k3s avec un gros preflight check. On est même pas sur le niveau fonctionnel d’un k3sup ou d’un k0ctl…

Les développeurs mettent en avant plusieurs fonctionnalités clés :

✅ Key Features

Supports airgap images package for k8s components

10-year valid certificate, supports cluster backup and upgrade

No dependency on Ansible, HAProxy, or Keepalived; a binary tool with zero dependencies

Natively supports Cilium network

No kube-proxy component

Le projet se présente donc comme une alternative simplifiée pour déployer k3s avec Cilium directement intégré, ce qui évite les étapes manuelles de configuration post-installation. J’ai d’ailleurs écrit un article fin 2023 sur ces fameuses opérations manuelles, toujours disponible ici : k3s et cilium rapide et facile

Prérequis

Comme k8e s’appuie sur k3s, les prérequis sont globalement les mêmes que pour k3s. Cependant, il y a une exigence supplémentaire importante : Cilium utilisant eBPF pour ses fonctionnalités de bas niveau, il faut un noyau Linux relativement récent

Bon, ça c’était ce qu’on disait pour les premières versions de cilium. Maintenant Linux kernel >= 4.19.57 c’est un vieux vieux kernel !

Pour mes tests, j’ai utilisé 4 machines virtuelles dans le même LAN :

k8e1 (control plane, 192.168.1.11)
k8e2 (control plane, 192.168.1.12)
k8e3 (control plane, 192.168.1.13)
k8e4 (worker, 192.168.1.14)

L’installation nécessite un accès SSH avec des privilèges sudo/root sur tous les nœuds.

Installation du premier nœud

Le Getting started est un peu rude car on tombe sur une page en chinois simplifié par défaut…

L’installation de k8e se fait via un script bash, comme beaucoup d’outils de la CNCF (RIP la sécurité). Pour le premier nœud (qui sera notre premier node control plane), on utilise la commande suivante :

denis@k8e1:~$ curl -sfL https://getk8e-site.pages.dev/install.sh | API_SERVER_IP=192.168.1.11 K8E_TOKEN=superSecureToken INSTALL_K8E_EXEC="server --cluster-init" sh -

Le script réalise plusieurs vérifications préalables (“preflight checks”) pour s’assurer que l’environnement est compatible. C’est notamment là qu’il vérifie la version du noyau Linux pour la compatibilité eBPF.

[2025-09-19 12:28:45] [WARN] System memory is less than 4GB. This may affect performance.
Finding latest version from GitHub
v1.31.2+k8e1
Downloading package https://github.com/xiaods/k8e/releases/download/v1.31.2+k8e1/k8e as /home/denis/k8e
...

À la fin du processus, on obtient un message de confirmation :

[...]
[2025-09-19 12:35:33] [INFO] systemd: Starting k8e
[2025-09-19 12:35:41] [INFO] Installing cilium network cni/operator
ℹ️ Using Cilium version 1.15.6
🔮 Auto-detected cluster name: default
🔮 Auto-detected kube-proxy has not been installed
ℹ️ Cilium will fully replace all functionalities of kube-proxy
[2025-09-19 12:35:42] [INFO] Installation completed successfully
[2025-09-19 12:35:42] [INFO] Performing cleanup...

Point qui a été amélioré depuis la dernière fois que j’avais testé, k8e copie lui-même le kubeconfig, il n’y a plus besoin d’aller le récupérer dans /etc/k8e/k8e.yaml (idem k3s, il est traditionnellement dans /etc/rancher/k3s/k3s.yaml)

denis@k8e1:~$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8e1 Ready control-plane,etcd,master 62m v1.31.2+k8e1

Cependant, un rapide coup d’œil permet de voir “comment” k8e le fait :

denis@k8e1:~$ env
...
KUBECONFIG=/etc/k8e/k8e.yaml

denis@k8e1:~$ ls -l /etc/k8e/k8e.yaml
-rw-r--r-- 1 root root 2961 Sep 19 12:35 /etc/k8e/k8e.yaml

Et là, je suis désolé, mais c’est :

Le kubeconfig cluster-admin à poil en 644, c’est NON. La doc de k8e est même encore pire, elle conseille du 666 (toujours plus).

Ajout des nœuds supplémentaires

Une fois le premier nœud installé, on peut ajouter les autres membres du control plane. Pour les nœuds supplémentaires du control plane :

denis@k8e2:~$ curl -sfL https://getk8e-site.pages.dev/install.sh | K8E_TOKEN=superSecureToken K8E_URL=https://192.168.1.11:6443 INSTALL_K8E_EXEC="server" sh -s -

denis@k8e3:~$ curl -sfL https://getk8e.com/install.sh | K8E_TOKEN=superSecureToken K8E_URL=https://192.168.1.11:6443 INSTALL_K8E_EXEC="server" sh -s -

Et pour le worker node :

denis@k8e4:~$ curl -sfL https://getk8e-site.pages.dev/install.sh | K8E_TOKEN=superSecureToken K8E_URL=https://192.168.1.11:6443 sh -

On peut ensuite vérifier que tous les nœuds sont bien présents :

denis@k8e1:~$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8e1 Ready control-plane,etcd,master 72m v1.31.2+k8e1
k8e2 Ready control-plane,etcd,master 2m30s v1.31.2+k8e1
k8e3 Ready control-plane,etcd,master 2m18s v1.31.2+k8e1
k8e4 Ready <none> 75s v1.31.2+k8e1

Vérification de Cilium

Une des particularités de k8e est donc l’intégration native de Cilium. On peut vérifier que Cilium fonctionne correctement en utilisant sa CLI directement sur un des nœuds du control plane (installée par défaut) :

denis@k8e1:~$ cilium status
 /¯¯\
 /¯¯\__/¯¯\  Cilium: OK
 \__/¯¯\__/ Operator: OK
 /¯¯\__/¯¯\  Envoy DaemonSet: disabled (using embedded mode)
 \__/¯¯\__/ Hubble Relay: disabled
 \__/ ClusterMesh: disabled

DaemonSet cilium Desired: 4, Ready: 4/4, Available: 4/4
Deployment cilium-operator Desired: 1, Ready: 1/1, Available: 1/1
Containers: cilium Running: 4
 cilium-operator Running: 1
Cluster Pods: 3/3 managed by Cilium
Helm chart version: 1.15.6
Image versions cilium quay.io/cilium/cilium:v1.15.6: 4
 cilium-operator quay.io/cilium/operator-generic:v1.15.6: 1

Avantages et Inconvénients

Les plus	Les moins
➕ Installation automatisée de Cilium sur k3s	➖ Permissions `/etc/k8e/k8e.yaml` en “world readable” dans la doc officielle (dangereux !)
	➖ Version de Kubernetes en retard par rapport aux dernières versions
	➖ N’apporte pas énormément de valeur ajoutée par rapport à k3s seul
	➖ Documentation limitée par rapport aux projets plus matures

Conclusion

Dans les points positifs, le projet, sans être populaire, est quand même plutôt suivi avec pas mal de contributions externes et une “vie” (commits réguliers). k8e est un outil pour les fainéants qui veulent installer un cluster k3s avec Cilium plus rapidement (oui c’est un point positif).

Mais, à quel prix ?

Un kubeconfig à 644, lisible par tous les utilisateurs unix des control planes
Une installation en curl | bash (exactement comme k3s, à ceci près que j’ai plus confiance en Rancher labs qu’en xiaods)
Des versions datées (kube 1.31, cilium 1.15)

Pas la peine que je vous dise ce que j’en pense, je pense que vous avez compris.