EBPF 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.

Migration du routage de cilium de iptables vers eBPF... à chaud !

Fri, 20 Oct 2023 06:00:00 +0200

Contexte

Il se pourrait que j’aie configuré des clusters Kubernetes de prod avec cilium en mode iptables et non pas eBPF. Mais vous n’avez aucune preuve…

Cependant, dans l’hypothèse hautement improbable où j’aurais pu faire une boulette pareille, voilà comment je m’y serai pris pour résoudre le problème.

#trollface

Imaginons donc qu’en vérifiant la configuration de Cilium, voici ce que vous avez trouvé :

kubectl -n cilium exec -it cilium-aaaaa -- cilium status
[...]
Host Routing: Legacy
Masquerading: IPTables [IPv4: Enabled, IPv6: Disabled]
[...]

Damned!

A y regarder de plus près, les containers cilium-agent dans vos pods cilium prennent beaucoup de CPU et de RAM et commencent à engorger vos workers…

C’est la cata.

Pourquoi ça ?

Les premières implémentations du réseau imaginaire de Kubernetes (les fameux CNI plugins) utilisaient iptables. Or, on sait depuis très longtemps, notamment dans le cas d’usage de Kubernetes, qu’iptables est assez mauvais pour gérer de grandes quantités de règles.

Dans le cas particulier de Kubernetes, le nombre de règles à tendance à augmenter de manière exponentielle avec la taille du cluster et le CPU consommé pour router des paquets réseaux avec…

À un moment donné, parcourir la liste des règles prend tout le CPU d’un nœud donné et le rend non réactif.

Allo patron ? On est mal.

C’est une des raisons pour lesquelles j’aime beaucoup cilium comme CNI plugin, les développeurs font partie des premiers à avoir misé sur eBPF comme remplacement d’iptables (même s’il existe d’autres implémentations / d’autres technos qui règles ce problème).

Comment en est on arrivé là ?

A vrai dire, j’ai juste lu la doc et fait confiance…

We introduced eBPF-based host-routing in Cilium 1.9 to fully bypass iptables and the upper host stack, and to achieve a faster network namespace switch compared to regular veth device operation. This option is automatically enabled if your kernel supports it. To validate whether your installation is running with eBPF host-routing, run cilium status in any of the Cilium pods and look for the line reporting the status for “Host Routing” which should state “BPF”.

Grosso modo, selon la doc officielle, si on dispose du kernel correct et des modules qui vont bien, l’installation de cilium est censée activer automatiquement le mode eBPF… Sauf qu’on voit bien un peu plus haut que ce n’est pas le cas, malgré un kernel récent (6.2).

En creusant un peu plus les logs, voilà ce qu’on peut trouver :

kubectl -n cilium logs cilium-7b5cp
[...]
level=info msg="BPF host routing requires enable-bpf-masquerade. Falling back to legacy host routing (enable-host-legacy-routing=true)." subsys=daemon

Bon… visiblement, il manque une option dans la chart Helm.

[...]
 kubeProxyReplacement: strict
+ bpf:
+ masquerade: true
[...]

Problem solved, fin de l’article ?

Problème

Alors oui, forcément, on peut modifier la chart comme un⋅e bourrin⋅e et fin de l’histoire.

Mais admettons qu’on ait pas envie de couper le trafic de production… Comment on fait ?

La solution la plus clean qui me vient en tête est la suivante :

on drain un node
on lui change sa configuration
on l’uncordon pour lui remettre un peu de trafic dessus
on vérifie que la nouvelle configuration fonctionne ET
on vérifie que les nodes peuvent se parler entre eux entre ceux en iptables et ceux en eBPF

Bah oui, ça serait dommage d’avoir la moitié du cluster qui peut pas communiquer avec l’autre moitié…

Vérifier la connectivité

Ce qui est cool avec cilium (je vous ai déjà dit que j’aime cilium ?), c’est qu’on a déjà du tooling pour tout tester.

La CLI cilium dispose d’une sous commande cilium connectivity test qui lance des dizaines de tests internes/externes pour tester que tout est OK.

➜ ~ cilium -n cilium connectivity test
ℹ️ Monitor aggregation detected, will skip some flow validation steps
✨ [node] Deploying echo-same-node service...
✨ [node] Deploying DNS test server configmap...
✨ [node] Deploying same-node deployment...
✨ [node] Deploying client deployment...
[...]
✅ All 32 tests (265 actions) successful, 2 tests skipped, 0 scenarios skipped.

Il existe aussi une commande cilium-health, embarquée dans le container cilium-agent, qui permet de remonter des statistiques périodiques de latences entre tous les nodes du cluster. Utile !

kubectl -n cilium exec -it cilium-ccccc -c cilium-agent -- cilium-health status
Probe time: 2023-09-12T14:47:03Z
Nodes:
 node-02 (localhost):
 Host connectivity to 172.31.0.152:
 ICMP to stack: OK, RTT=860.424µs
 HTTP to agent: OK, RTT=110.142µs
 Endpoint connectivity to 10.0.2.56:
 ICMP to stack: OK, RTT=783.861µs
 HTTP to agent: OK, RTT=256.419µs
 node-01:
 Host connectivity to 172.31.0.151:
 ICMP to stack: OK, RTT=813.324µs
 HTTP to agent: OK, RTT=553.445µs
 Endpoint connectivity to 10.0.1.53:
 ICMP to stack: OK, RTT=865.976µs
 HTTP to agent: OK, RTT=3.440655ms
[...]

Et enfin, on peut juste regarder la commande cilium status qui nous dit qui est “reachable” (là encore, dans le container cilium-agent)

➜ kubectl -n cilium exec -ti cilium-ddddd -- cilium status
[...]
Host Routing: Legacy
Masquerading: IPTables [IPv4: Enabled, IPv6: Disabled]
[...]
Cluster health: 5/5 reachable (2023-09-14T12:01:51Z)

Changer la configuration d’un node

On a de la chance, car, depuis la version 1.13 de cilium (la dernière en date est la 1.14), il est possible d’appliquer des configurations différentes pour un sous ensemble de nodes (documentation officielle du Per-node configuration).

Note : avant ça, c’était quand même possible, de manière temporaire, en éditant la ConfigMap de cilium à la main, puis en redémarrant les pods concernés pour prise en compte.

Il existe maintenant une CRD pour le faire, qui s’appelle CiliumNodeConfig. Les seules choses qu’on a à faire, c’est ajouter un label sur un node (io.cilium.enable-ebpf: “true”) et ajouter le manifest suivant sur notre cluster :

cat > cilium-fix.yaml << EOF
apiVersion: cilium.io/v2alpha1
kind: CiliumNodeConfig
metadata:
 namespace: cilium
 name: cilium-switch-from-iptables-ebpf
spec:
 nodeSelector:
 matchLabels:
 io.cilium.enable-ebpf: "true"
 defaults:
 enable-bpf-masquerade: "true"
EOF

kubectl apply -f cilium-fix.yaml

kubectl label node node-05 --overwrite 'io.cilium.enable-ebpf=true'

Si jamais on est en production, le plus propre est donc de kubectl drain le Node préalablement.

Par curiosité, j’ai quand même essayé de le faire “à chaud”, pour le fun.

J’ai déployé un daemonset contenant une app en V(lang) qui répond simplement le nom du container dans une page web :

cat > vhelloworld-daemonset.yaml << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: vhelloworld-daemonset
spec:
 selector:
 matchLabels:
 app: vhelloworld
 template:
 metadata:
 labels:
 app: vhelloworld
 spec:
 containers:
 - name: vhelloworld
 image: zwindler/vhelloworld:latest
 ports:
 - containerPort: 8081
 imagePullPolicy: Always
EOF

kubectl apply -f vhelloworld-daemonset.yaml

kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
vhelloworld-daemonset-q4h44 1/1 Running 0 3m31s 10.0.4.87 nodekube-05 <none> <none>
vhelloworld-daemonset-w97pv 1/1 Running 0 3m31s 10.0.3.85 nodekube-04 <none> <none>

Puis j’ai créé des containers contenant un shell et curl pour vérifier périodiquement et depuis plusieurs nodes que les containers sont bien accessibles :

kubectl run -it --image curlimages/curl:latest curler -- /bin/sh
If you don't see a command prompt, try pressing enter.
~ $ curl http://10.0.4.87:8081
hello from vhelloworld-daemonset-g2zdw
~ $ curl http://10.0.3.85:8081
hello from vhelloworld-daemonset-65k2n

~ $ while true; do
 date
 curl http://10.0.4.87:8081
 curl http://10.0.3.85:8081
 echo
 sleep 1
done

Une fois le label appliqué sur un node, son pod cilium tué (via un kubectl delete), les pods sont restés accessibles

Fri Sep 15 14:05:34 UTC 2023
hello from vhelloworld-daemonset-g2zdw
hello from vhelloworld-daemonset-65k2n

Fri Sep 15 14:05:35 UTC 2023
hello from vhelloworld-daemonset-g2zdw
hello from vhelloworld-daemonset-65k2n

Fri Sep 15 14:05:36 UTC 2023
hello from vhelloworld-daemonset-g2zdw
hello from vhelloworld-daemonset-65k2n

A un moment donné, cilium a redémarré, remarqué la présence de pods existants, et pris le relais avec eBPF !

evel=info msg="Rewrote endpoint BPF program" containerID=8b7be1b032 datapathPolicyRevision=0 desiredPolicyRevision=1 endpointID=1018 identity=4773 ipv4=10.0.3.85 ipv6= k8sPodName=default/vhelloworld-daemonset-w97pv subsys=endpoint
level=info msg="Restored endpoint" endpointID=1018 ipAddr="[10.0.3.85 ]" subsys=endpoint

Ca fonctionne, mais est ce que c’est mieux en termes de consommation de ressources ?

Ca, c’était la bonne nouvelle. Je m’attendais à des gains car le cluster était vraiment pas loin de souffrir.

Les containers cilium prenaient 10% des CPU de mes nodes, et plusieurs Go de RAM en mode iptables. Ca aurait rapidement pu monter bien plus haut, si j’avais agrandi le cluster au-delà des 50 nodes / 2000 pods.

Le passage au mode eBPF a permis de retrouver des niveaux totalement indolores (1% de CPU par node, 1-2% de RAM) par rapport aux configurations de mes machines.

Pas mal, hein ?

Bonus

Un tutoriel bien velu pour migrer totalement de CNI à chaud (de flannel à cilium)

k3s et cilium rapide et facile

Fri, 01 Sep 2023 10:00:00 +0200

Contexte

K3s est une distribution de Kubernetes éditée par Rancher (et certifiée par la CNCF) que je trouve super pratique car légère et supportant plusieurs plateformes (en particulier ARM):

x86_64
armhf
arm64/aarch64
s390x

Je l’ai déjà utilisée par le passé (ici) pour faire un cluster kubernetes avec des vieux Raspberry Pi. A l’époque, on pouvait même faire tourner les nodes “workers” sur des RPi 1 (je ne sais pas si c’est toujours possible).

La particularité de k3s est que tout est intégré dans un seul binaire. Nécessairement, des choix techniques ont été fais pour rendre l’installation et l’utilisation la plus légère possible. Parmi ces choix techniques, il y a l’utilisation de flannel comme “CNI plugin” (pour faire simple, le réseau virtuel qui permet aux containers de parler en eux).

Je ne suis vraiment PAS fan de flannel qui m’a posé beaucoup de soucis en production, qui ne supporte pas les “Network Policies”, qui a pendant plusieurs années utilisé comme backend etcd2 alors que ce logiciel était marqué comme obsolète (deprecated) depuis plusieurs années, …

A l’inverse, je suis très fan de cilium, qui a beaucoup de fonctionnalités sympa grâce à l’usage de eBPF en termes de performance et de sécurité et a pas mal de traction dans l’écosystème.

Prérequis

Dans ce tutoriel, je pars du principe que vous avez installé un serveur avec Ubuntu 22.04.

Cilium est très friand d’eBPF, dont il tire la plupart de ces fonctionnalités. Et comme eBPF est quelque chose d’assez récent dans le kernel Linux, le mieux est de mettre à jour notre serveur et de lui mettre un kernel plus récent :

$ sudo apt update -y
$ sudo apt upgrade -y
$ sudo apt install curl linux-image-generic-hwe-22.04 -y

Une fois que c’est fait, on reboot le serveur pour la prise en compte du nouveau kernel.

Installation de k3s

On installe donc k3s, en remplaçant flannel par cilium (voir documentation Installation - Network options). La doc conseille de retirer le support des network-policy. Je me demande comment c’est géré puisque flannel n’est pas censé les supporter :thinking_face:.

$ curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC='--flannel-backend=none --disable "traefik"' sh -s - --disable-network-policy

On vérifie que k3s est démarré et fonctionne :

$ systemctl status k3s
● k3s.service - Lightweight Kubernetes
 Loaded: loaded (/etc/systemd/system/k3s.service; enabled; vendor preset: enabled)
 Active: active (running) since Fri 2023-09-01 12:32:55 UTC; 1min 13s ago
 Docs: https://k3s.io
 Process: 1724 ExecStartPre=/bin/sh -xc ! /usr/bin/systemctl is-enabled --quiet nm-cloud-setup.service (code=exited, status=0/SUCCESS)
 Process: 1726 ExecStartPre=/sbin/modprobe br_netfilter (code=exited, status=0/SUCCESS)
 Process: 1727 ExecStartPre=/sbin/modprobe overlay (code=exited, status=0/SUCCESS)
[...]

Par défaut, le “kubeconfig” d’administration est déposé dans le fichier /etc/rancher/k3s/k3s.yaml, dont le propriétaire est root. Il existe un flag --write-kubeconfig-mode dans k3s pour modifier les droits de ce fichier mais cela le rendrait “world readable”.

Pour éviter de faire ça, on récupère le kube/config pour notre utilisateur “ubuntu”.

Comme le binaire k3s embarque tout, dont kubectl, on va aussi devoir lui dire de ne pas utiliser ce fichier en forçant la variable d’environnement $KUBECONFIG.

$ mkdir ~/.kube
$ sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
$ sudo chown ubuntu:ubuntu ~/.kube/config
$ chmod 600 ~/.kube/config
$ export KUBECONFIG=~/.kube/config

$ echo 'export KUBECONFIG=~/.kube/config' >> ~/.bashrc
$ echo 'source <(kubectl completion bash)' >> ~/.bashrc
$ echo 'alias k=kubectl' >> ~/.bashrc
$ source ~/.bashrc

$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
kube01 NotReady control-plane,master 70s v1.27.4+k3s1

Ici, kube01 est marqué NOTREADY. C’est normal car on a pas de CNI plugin (donc pas de réseau interne).

Ajout d’un second node

Sur le premier node, récupérez le token pour que le second puisse rejoindre le cluster :

cat /var/lib/rancher/k3s/server/node-token

Une fois que c’est fait, connectez vous sur le node à rajouter au cluster, installez le kernel hwe, rebootez

sudo apt update
sudo apt upgrade
sudo apt install curl linux-image-generic-hwe-22.04 -y
sudo reboot

Une fois que le node est à jour et prêt à rejoindre le cluster, lancez la commande suivante :

IP_MASTER=IP.DE.VOTRE.MASTER
K3STOKEN=le:token:du:master
curl -sfL https://get.k3s.io | K3S_URL=https://${IP_MASTER}:6443 K3S_TOKEN=${K3STOKEN} sh -

Au bout de quelques secondes, votre node va apparaître dans la liste des nodes.

CNI plugin + ingressController

Nos nodes sont toujours en “Not Ready”. On installe helm et on ajoute le CNI plugin :

$ curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
$ CILIUM_VERSION="1.14.2"
$ helm repo add cilium https://helm.cilium.io/
$ helm upgrade --install cilium cilium/cilium --version=${CILIUM_VERSION} \
 --set global.tag="v${CILIUM_VERSION}" --set global.containerRuntime.integration="containerd" \
 --set global.containerRuntime.socketPath="/var/run/k3s/containerd/containerd.sock" \
 --set global.kubeProxyReplacement="strict" \
 --set global.bpf.masquerade="true" \
 --set ingressController.enabled=true \
 --set ingressController.default=true \
 --namespace cilium \
 --create-namespace

Note: pour le fun, j’ai aussi ajouté le support de l’ingressController de cilium. Comme ça c’est fait :D.

Au bout de quelques secondes, notre cluster devrait devenir opérationnel. On a aussi metric server (pour les stats de base).

$ kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system cilium-operator-86dbc96dd6-hlgtt 1/1 Running 0 56s
kube-system cilium-operator-86dbc96dd6-h7sq6 1/1 Running 0 56s
kube-system cilium-pxrrz 1/1 Running 0 56s
kube-system cilium-psjr4 1/1 Running 0 56s
kube-system svclb-cilium-ingress-c27a13c6-x7tld 2/2 Running 0 32s
kube-system local-path-provisioner-957fdf8bc-5w9n9 1/1 Running 0 6m9s
kube-system coredns-77ccd57875-zlvpc 1/1 Running 0 6m9s
kube-system svclb-cilium-ingress-c27a13c6-8dbf6 2/2 Running 0 34s
kube-system metrics-server-648b5df564-xr29p 1/1 Running 0 6m9s

Conclusion

Voilà pour ce très court article sur k3s et cilium.

Ce setup, rapide à installer sur une install fraîche est ma base pour beaucoup d’expérimentations avec Kubernetes.

Kubecon Europe 2021 – Récap’ du jeudi

Thu, 06 May 2021 17:00:00 +0000

Deuxième jour de Kubecon

Hier, je vous faisais un petit résumé de la première journée de Kubecon !

Si vous ne l’avez pas lu, je vous conseille de commencer par là, car je ne vais pas refaire la petite intro avec le contexte.

Aujourd’hui, les talks ont été très condensés et j’ai fait un gros focus réseau / sécu, comme vous pourrez le voir dans la suite de l’article :)

Keynotes

Aujourd’hui, c’était moins dense en termes de nombre de keynotes.

La première keynote a été réalisée par Stephen Augustus, Co-Chair & Head of Open Source chez Cisco. Il a donné quelques nouvelles sur le projet Kubernetes. Le plus gros morceau est le fait qu’il ait été acté que la release cycle allait passer à 15 semaines, ce qui fait 3 releases par an maintenant au lieu de 4. Il a également parlé du fait que les SIGs doivent opt-in les modifications qu’ils veulent inclure dans chaque release et a aussi acté le retour des community meetings.

Les deux talks qui ont suivi étaient sans intérêt, avec un talk sponsorisé de Veeam très très basique sur la sécurité et un talk sur Linkerd qui sauve le monde du COVID-19, que j’ai trouvé plus que déplacé. Je ne me suis pas privé pour le dire sur Twitter d’ailleurs (lol).

Le talk suivant (sponsorisé aussi) rattrapait un peu le niveau, avec un focus sur Knative réalisé par Brenda Chan de chez VMware. Je n’ai pas encore regardé en détail ce qu’on pouvait faire avec knative et ce talk m’a donné envie de creuser le sujet.

La dernière keynote était assez intéressante, avec un REX sur l’intégration des projets cloud native par les équipes de Deutsche Telekom. Après avoir présenté les problèmes auxquels ses équipes ont du faire face, Vuk Gojnic a présenté Das schiff, la solution qu’ils ont implémenté pour déployer des clusters Kubernetes distribués (as a service).

What Do You Mean K8s Doesn’t Have Users? How Do I Manage User Access Then?

La journée a commencé plutôt soft avec un talk assez généraliste sur l’AuthN/AuthZ pr Jussi Nummelin de chez Mirantis. Il a pointé du doigt un vrai problème dans Kubernetes : il n’y a pas de gestion des utilisateurs humains a proprement parlé.

C’est d’ailleurs écrit noir sur blanc dans la documentation officielle de Kubernetes !

It is assumed that a cluster-independent service manages normal users –kubernetes.io/docs/reference/access-authn-authz/authentication/

Tout ce qui est authentification dans Kubernetes passe soit par certificat x509, soit par des tokens de service account soit par des webhook. Tout ceci est donc plutôt réservé aux pods, comptes de services et pas du tout adapté pour des personnes en chair et en os.

Je ne parlerai même pas de l’authentification ‘static token file’ qui est un réel scandale qui ne devrait même pas être utilisée en lab.

La seule option viable est donc bien l’implémentation d’une authentification tierce via un connecter OIDC comme Dex, par exemple.

github.com/dexidp/dex

FalcOMG That’s AWESOME - New Things, Fixed Things, and YOU Panel

Page de la session
[Slides](https://static.sched.com/hosted_files/kccnceu2021/a1/FalcOMG That)

Cette session avait pour but de présenter tout un tas de choses à propos du projet Falco. Pour rappel, Falco est un cloud-native security runtime, initié par Sysdig en 2016. Il utilise eBPF (encore lui) pour détecter voire empêcher les workloads suspects sur vos machines Linux (pas que Kubernetes donc). Les dernières parties qui manquaient ont été données par sysdig en février 2021 (kernel modules + ebpf probe + runtime security).

Après une longue introduction du projet (donné à la CNCF en 2018, accepté en tant qu’Incubating en 2020), deux mainteneurs (Leonardo Grasso et Leonardo Di Donato) ont présentés le processus de release ainsi que la façon dont les artefacts (cf falco open infra) sont générés automatiquement (plus de 3500).

L’équipe de falco est également très impliquée dans l’accès à cette technologie pour tous et recherche activement des traducteurs pour traduire le site et la documentation de falco dans le plus de langues possible. Le processus d’internationalisation a été présenté par Radhika Puthiyetath, technical writer chez sysdig. C’était assez intéressant de voir que le processus mis en place était assez simple et donc accessible au plus grand nombre.

Enfin, l’outil falco sidekick a été présenté par Thomas Labarussias, SRE chez Qonto. Il s’agit d’un démon permettant de collecter l’ensemble des événements transmis par falco (présent sur tous vos nodes kube par exemple) et de les forwarder à une 30aines d’outputs différents en fonction de certaines règles.

On peut ainsi mettre en place de l’alerting ou loguer les événements dans des SIEM ou des moteurs de recherche (Elasticsearch) pour traitements ultérieurs par exemple.

Uncovering a Sophisticated Kubernetes Attack in Real-Time

Troisième talk de la journée sur la sécurité !!! Natália Réka Ivánkó (Security Engineer chez Isovalent) et Jed Salazar (Manager, Platform Security chez Tesla) nous on présenté un panel assez large de risques de sécurité et de vecteurs d’attaques accessibles depuis un cluster Kubernetes.

Après avoir balayé très rapidement les solutions classiques pour réduire les risques (Distroless base images, OPA, pas de shells pour réduire la surface d’attaques, analyse statique des images et analyse au runtime), ils ont cherché à comprendre ce qu’on pouvait faire de plus.

On peut aussi appliquer à la sécurité le mindset « devops » (on parle parfois de devsecops) en considérant que ce qu’on a mis en place en termes de sécurité doit être (1) testé et (2) observé.

Et selon eux, le meilleur outil pour le faire, c’est eBPF. Ils nous ont donc ensuite présenté plusieurs scenarii d’attaques dans lesquels Cilium (eBPF-based Networking, Observability, and Security) était utilisé pour connecter, surveiller et sécuriser les événements sur le réseau de kubernetes.

Le talk était riche et dense et il est extrêmement dur pour moi de le résumer ici. Je serais probablement amené à en reparler sur le blog tant le sujet est pléthorique.

How to Break your Kubernetes Cluster with Networking

J’ai vraiment adoré le talk précédent mais alors celui là c’est le meilleur que j’ai vu depuis le début de cet Kubecon. Thomas Graf, en plus d’être un excellent pédagogue est un excellent speaker. C’est le CTO d’Isovalent (tiens tiens tiens, encore eux !) et il est core member du projet Cilium (encore lui !).

Là aussi, le talk était extrêmement dense et Thomas Graf s’est employé à brosser toutes les façons de casser son cluster Kubernetes avec le réseau. Cela va de bête erreurs DNS à l’utilisation de kube-proxy + iptables en passant par des CRD watchers qui DDoS votre API server et en finissant par des histoires d’horreur de changement de CNI (ou double run) qui cassent tout le réseau du cluster (kids, don’t do this at home).

Une fois de plus, le talk était tellement dense qu’il est difficile de le résumer. Ce qu’on peut en retenir simplement, c’est que le mieux est encore de rester le plus simple possible dans la limite de vos besoins et de ne pas ajouter trop de couches juste parce qu’elles sont « shiny ». (Et je suis évidemment à 100% d’accord).

Oooooooh! Shiny ones!

Les talks que j’aurai voulu voir

Je l’ai déjà dit hier, choisir c’est renoncer.

Si j’avais pu, je serai également allé voir BuildKit CLI for kubectl: A New Way to Build Container Images par curiosité pour l’outil, que je ne connais pas. Mais les dieux du scheduling en ont voulu autrement (c’était pendant la présentation sur Falco).

Fin de la journée

Si on peut appeler ça la fin de la journée puisque le dernier talk a fini vers 15h ;-) mais en vrai c’était tellement intense il y avait pas mal à débriefer.

Maintenant qu’on est au 2/3 de la Kubecon, je vois 2 sujets prioritaires qu’il va falloir que j’investigue sérieusement :

la partie eBPF, avec un vrai choix technique côté CNI (test de Cilium à faire absolument) et évaluation des outils de sécus basés sur des programmes BPF
la partie CI/CD avec flux, flagger, litmus (mais plutôt réservée pour mes copains ingés CI/CD, je ne ferai que suivre le mouvement)

On verra si la journée de demain changera un peu ces priorité ou pas (probablement que non).

Et en attendant, have fun :)