Zwindler's Reflection

101 façons de déployer Kubernetes : 125 solutions, des PRs communautaires et une UI qui s'améliore

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

Il bouge encore

Depuis la sortie de l’interface web du projet début février, le projet a continué à évoluer. Ajout de solutions manquantes, petites améliorations de l’UI, contributions externes, optimisations de performances… Bref, un bon petit mois bien rempli pour ce gros side project que j’aimerais faire grossir.

101-ways-to-deploy-kubernetes

Note : si vous n’avez pas suivi les épisodes précédents :

93 façons de déployer Kubernetes — le Google Sheet original
101 façons de déployer Kubernetes (v2) — passage sur GitHub
Une nouvelle UI pour explorer les 118+ solutions — l’appli Astro + Tailwind

7 nouvelles solutions

Le catalogue est passé de 118 à 125 solutions. Voici les ajouts depuis le dernier article :

Xen Orchestra - ajouté pendant un stream de Cuistops => Déploiement de clusters Kubernetes (MicroK8s) via les “recettes” de Xen Orchestra, la plateforme de management de Vates. Catégorie ManagementPlatform.
Charmed Kubernetes - suite à un commentaire sur LinkedIn, j’ai remplacé l’entrée “Juju” par Charmed Kubernetes, qui est le vrai nom du produit Canonical pour déployer Kubernetes via Juju.
kubeaver - découvert en scrollant bluesky sans but => un installateur Kubernetes offline/online avec une GUI, basé sur Kubespray et Ansible. Certifié CNCF conformance (pour ce que ça vaut…).
talos-bootstrap - script interactif de Cozystack pour bootstrapper des clusters Kubernetes sur Talos OS.
boot-to-talos - Outil de Cozystack (encore) qui convertit n’importe quel OS existant en Talos Linux, complètement depuis le userspace. Partiellement utilisé par Quentin dans un contexte que je ne peux révéler ;-)
TOPF - Talos Orchestrator by PostFinance, un CLI pour gérer des clusters Kubernetes basés sur Talos. Découvert sur le discord de Cuistops
Talhelper - Outil CLI pour créer des clusters Talos en mode GitOps, à partir d’un seul fichier YAML déclaratif. Je l’avais initialement mis de côté mais à y réfléchir, pourquoi pas le mettre.

On notera qu’au même titre que kubeadm et k3s, il y a beaucoup de solutions qui s’appuient sur Talos Linux. De mon point de vue, ça valide l’OS et ça confirme l’adoption croissante de cet OS immutable pour Kubernetes.

Refonte complète des tags

Un gros chantier a été la refonte de tous les tags du catalogue. Ils étaient incohérents : des noms d’outils utilisés comme tags (openshift, rancher…), des tags redondants (on-premise + self-hosted), des tags manquants ou parfois faux (par ex. “lightweight” sur des outils qui lancent des VMs).

J’ai nettoyé les tags de toutes les catégories :

Desktop : suppression des noms d’outils comme tags, ajout de gui pour Docker Desktop, Orbstack, Podman Desktop, Rancher Desktop
Selfhosted : suppression du tag redondant on-premise (29 solutions), ajout de tags pertinents (automation, edge, lightweight, bare-metal…)
ManagementPlatform : toutes les solutions ont maintenant 3 tags (multi-cloud, managed, gui, automation…)
KubernetesInKubernetes : correction de vcluster (virtualization → lightweight)

De nouveaux filtres dans l’UI

J’ai ajouté un filtre par nombre d’étoiles GitHub qui n’apparaît que quand le filtre “Open Source only” est activé. Plutôt pratique pour identifier rapidement les projets les plus populaires (> 100, > 1k, > 10k stars).

L’occasion aussi de réorganiser la barre de filtres : le sélecteur de statut (Active/Abandoned) est passé en dropdown compact, et le layout général a été retravaillé pour rester lisible même avec plus de filtres.

Dernier point, lorsque vous faites une recherche dans la barre principale, une variable vient d’ajouter à l’URL : pratique pour partager des solutions directement avec le lien.

Les contributions d’Antoine Caron (Slashgear)

Un grand merci à Antoine Caron (@slashgear) qui, au-delà de m’avoir aidé sur les performances et la sécurité de ce blog, a aussi contribué directement au projet 101 ways avec plusieurs PRs !

Hiérarchie des headings - les cartes utilisaient des <h3> sans <h2> dans la page. Antoine a corrigé ça pour une hiérarchie correcte (h1 → h2), ce qui améliore la navigation pour les lecteurs d’écran.
Accessibilité du champ de recherche - ajout d’un vrai <label> (en sr-only) et passage du type="text" à type="search" pour une meilleure sémantique.
Skip links - ajout de liens “skip to content” pour la navigation au clavier (WCAG 2.1, critère 2.4.1). Trois liens : vers la recherche, les filtres, et le contenu principal.

Amélioration des performances

En parlant de performances, le site s’est aussi amélioré côté PageSpeed. Voici un avant/après sur Lighthouse mobile :

De 82 à 99 en performances mobiles, avec du 100/100 en bonnes pratiques et SEO.

Ces gains viennent d’un ensemble de corrections, notamment la résolution du clipping des cartes au hover, un bug CSS assez vicieux lié à content-visibility: auto qui impliquait contain: paint et coupait le haut des cartes quand elles se soulevaient au survol. Antoine avait identifié le problème avec l’overflow-hidden, et Copilot a trouvé la cause racine dans le CSS containment.

Merci !

Un grand merci à tous ceux qui contribuent, que ce soit en me mentionnant les outils manquants, en soumettant des PRs, ou simplement en partageant le projet.

Merci spécial à Antoine Caron pour ses PRs sur l’accessibilité et la CI - c’est vraiment chouette de voir quelqu’un prendre le temps d’améliorer un projet open source qui n’est pas le sien. Et c’est d’autant plus appréciable qu’Antoine m’avait déjà aidé sur ce blog avec l’optimisation des images en AVIF et les security headers HTTP. 🙏

Le projet compte maintenant 125 solutions. Si vous en connaissez d’autres, n’hésitez pas à ouvrir une issue ou une PR (ou juste à me ping, en cas de flemme) !

👉 zwindler.github.io/101-ways-to-deploy-kubernetes

Décommission de kibana.zwindler.fr, le Kibana qui hébergeait les sondages Okiwi

Wed, 25 Mar 2026 12:00:00 +0100

La fin d’une époque ?

Si vous me suivez depuis quelques années, vous savez que parmis mes nombreux side projects, j’ai beaucoup participé à des sondages sur les salaires dans la tech Girondine, organisés par l’association Okiwi. C’est un projet qui a contribué à me rendre un peu “visible” (toute proportion gardée) dans l’écosystème local et qui m’a par ailleurs apporté beaucoup de statisfaction, car j’ai vraiment à coeur les sujets autour des salaires ou de la transparence salariale.

Au delà de la participation à la création et la diffusion du sondage, j’hébergeais un serveur Kibana pour permettre à tout le monde de consulter les résultats de manière interactive (et je dirais même ludique).

Ce serveur, kibana.zwindler.fr, a hébergé donc entre 2019 et 2025 pas moins de 6 éditions du sondage, plus une collaboration avec Shirley Almosni Chiche sur les salaires de l’IT à l’échelle nationale.

Et bien… c’est fini. Le serveur est décommissionné.

Pourquoi ?

Oui mais voilà, après une chouette campagne 2023-2024 avec 449 réponses (ce qui est énorme à l’échelle locale), le projet s’est essouflé en 2025 avec très peu de réponses (autour de 160, bien en deça des années précédentes). Le sondage 2025-2026 n’a du coup jamais été lancé. Ce gros side projet (j’y ai passé un paquet d’heures) est terminé.

Et faute de besoin, je ne maintenais donc plus ce serveur depuis bien longtemps. Il y a une semaine, en me connectant dessus pour la première fois depuis des mois, j’ai constaté qu’Elasticsearch et Kibana étaient down. Le serveur tournait, mais les services ne répondaient plus.

Personne ne s’en est plaint (moi inclus, d’ailleurs).

Ca faisait plus d’un mois que les dashboards étaient inaccessibles et je ne m’en étais même pas rendu compte. Si le mec qui héberge le truc ne remarque pas que c’est cassé, c’est probablement le signe qu’il est temps de tirer la prise.

Le serveur (un VPS Ubuntu chez nua.ge) accumulait les mises à jour non faites, tournait sur une version d’Elastic qui n’était plus à jour, et consommait des ressources (et de l’argent) pour un service que plus personne n’utilisait.

Ce que j’ai sauvegardé

Avant de tout supprimer, j’ai quand même pris le temps de sauvegarder l’intégralité des données et de faire des captures d’écran de chaque dashboard (c’est mon côté hoarder de la data). Parce que même si les dashboards interactifs n’existent plus, les données restent potentiellement intéressantes.

Captures d’écran des dashboards

Voici une capture de chaque édition du sondage Okiwi telle qu’elle apparaissait dans Kibana :

Étude Shirley Almosni Chiche (2020, national)

En 2020, Shirley Almosni Chiche (agent de carrière IT) avait lancé de son côté une étude sur les salaires de l’IT à l’échelle nationale. Elle avait récolté pas mal de réponses (plus de 400) et comme j’avais déjà l’infrastructure Kibana qui tournait pour Okiwi, je lui ai proposé d’héberger ses données sur mon serveur pour que ce soit plus ludique d’explorer les résultats qu’un simple Google Sheet.

Dashboard Shirley - Salaires IT national 2020

Offres d’emploi de recruteurs (2019-2025, données personnelles)

Celui-là n’a jamais été publié, mais tant qu’à sauvegarder, autant tout garder. Depuis 2019, je complète un Google Sheet avec toutes les offres d’emploi que m’envoient les recruteurs : fourchettes de salaires quand elles sont disponibles, type d’entreprise, remote ou non, étranger ou pas (et le pays concerné le cas échéant). J’avais importé tout ça dans Kibana pour avoir un dashboard interactif.

C’est subjectif (c’est uniquement ce que je reçois), mais ça me permet d’avoir mon propre point de vue sur le marché du travail dans l’IT et sur les pratiques de chasse des recruteurs. Je trouve ça intéressant comme données, même si c’est à prendre avec des pincettes (c’est le moins qu’on puisse dire).

Dashboard offres d’emploi recruteurs

Exports JSON des données brutes

Pour ceux qui voudraient retravailler les données (ou les importer dans un autre outil), j’ai exporté l’intégralité des index Elasticsearch au format JSON. Les noms d’index ne sont pas toujours très parlants (merci moi du passé), donc voici la correspondance :

Edition	Index Elasticsearch	Téléchargement
2019-2020	`import-1`	import-1.json
2020-2021	`okiwi21`	okiwi21.json
2021-2022	`okiwi-2022`	okiwi-2022.json
2022-2023	`okiwi-2023`	okiwi-2023.json
2023-2024	`okiwi-2024-2`	okiwi-2024-2.json
2024-2025	`okiwi-2025`	okiwi-2025.json
Étude Shirley (national)	`shirley`	shirley.json

Rétrospective

Ce Kibana aura quand même eu une belle vie. Lancé un peu sur un coup de tête en 2019 pour rendre les résultats du premier sondage Okiwi plus sexy qu’un Google Sheet, il a fini par devenir un rendez-vous annuel.

Les dashboards interactifs ont permis à des centaines de personnes de la tech Girondine de comparer leurs salaires, de repérer des tendances, et même de servir d’argument lors de négociations annuelles dans certaines entreprises. C’est pas rien.

Au fil des années, j’ai appris à nettoyer des données dégueulasses issues de Google Forms (puis framaforms), à me battre avec des aggrégations Elasticsearch, à découvrir Vega pour faire des nuages de points que Kibana ne proposait pas nativement, et à gérer un serveur Elastic en production (spoiler : c’est pas de tout repos).

Bientôt plus besoin de ce genre d’initiatives ?

Petit aparté pour finir sur une note positive : ce type de sondage artisanal pourrait bientôt devenir moins nécessaire. La directive européenne 2023/970 sur la transparence des rémunérations, adoptée en 2023, impose aux entreprises de plus de 100 salariés de publier des informations sur les écarts de rémunération et donne aux candidats le droit de connaître la fourchette salariale d’un poste avant l’entretien.

Les États membres ont jusqu’à juin 2026 pour la transposer dans leur droit national. La France n’a, à l’heure où j’écris ces lignes, toujours pas transposé cette directive… mais on peut espérer que ça finisse par arriver. Le jour où les fourchettes de salaires seront affichées sur les offres d’emploi et où les entreprises devront rendre des comptes sur les écarts de rémunération, nos petits sondages Okiwi auront fait leur temps. Et honnêtement, ce sera une bonne nouvelle.

Les articles liés

Pour ceux qui veulent retrouver le contexte de chaque édition :

Have fun !

GenAI et développement logiciel, épisode 2 : kubectl-debug-pvc, de l'idée à krew en 2x30 minutes

Tue, 17 Mar 2026 18:00:00 +0100

Précédemment, dans “GenAI et dev”

Dans mon article précédent, je vous parlais de mon retour d’expérience avec PodSweeper, un projet développé avec OpenCode et Claude Opus. Le bilan était nuancé : vitesse brute impressionnante, mais race conditions, gestion d’erreur laxiste, et nécessité constante de supervision humaine (entre autres déconvenues).

Aujourd’hui, je vous parle d’un deuxième projet, bien plus simple, né d’un vrai besoin en production. Et le constat est assez différent.

L’incident qui a tout déclenché

Vous connaissez peut-être cette situation : un pod en production, en état de fonctionnement, qui utilise un PVC en ReadWriteOnce. Vous avez besoin d’aller regarder le contenu de ce volume. Bonne pratique de production : le pod en question ne dispose pas de shell (on réduit la surface d’attaque). Pas de /bin/sh, pas de /bin/bash, rien.

Pas grave, on a kubectl debug pour ça, me direz-vous !

Ok, créons un conteneur éphémère dans le pod et… ah non. kubectl debug ne permet pas de monter les volumes du pod dans le conteneur éphémère. Il n’expose tout simplement pas l’option volumeMounts pour les conteneurs éphémères.

On pourrait couper le pod, ce qui permet de monter le PVC RWO dans un autre pod avec un shell, mais on n’a pas envie, c’est de la prod.

Mon collègue Maxime (encore lui !) me propose une méthode de contournement. La procédure manuelle, c’est :

Créer un conteneur éphémère sur le pod avec kubectl debug
Construire à la main un patch JSON pour ajouter des volumeMounts au conteneur éphémère qu’on vient de créer
Dans un autre terminal, se brancher ~~au cul du camion~~ sur l’API de kube en direct avec kubectl proxy
Appliquer le patch via un curl sur l’API Kubernetes
Attendre que le conteneur soit prêt, s’attacher au conteneur
Se dire qu’il y avait quand même plus simple comme métier que patcheur de container à coup de curl.

Pour ceux qui pensent que c’est jouable, “téma la gueule du patch” comme disent (disaient ?) les jeunes :

curl http://localhost:8001/api/v1/namespaces/<namespace>/pods/<pod>/ephemeralcontainers \
 -X PATCH \
 -H 'Content-Type: application/strategic-merge-patch+json' \
 -d '{
 "spec": {
 "ephemeralContainers": [
 {
 "name": "debugger",
 "image": "ubuntu",
 "command": ["/bin/sh"],
 "targetContainerName": "<target-container>",
 "stdin": true,
 "tty": true,
 "volumeMounts": [
 {
 "name": "<volume-name>",
 "mountPath": "/debug/<volume-name>"
 }
 ]
 }
 ]
 }
 }'

Si vous pensez que c’est error prone, vous avez raison. Et si vous pensez que c’est pénible à faire sous pression pendant un incident de prod, vous avez encore plus raison.

Side note

Les plus aguerri·es d’entre vous dans les versions récentes de Kubernetes ont peut être entendu parler du KEP-2590, qui introduit un (relativement) nouveau flag --subresource de kubectl. En effet, les containers éphémères créés par la commande kubectl debug ne sont pas des resources (un pod, un deployment, …) mais des subresources.

Jusqu’à cette version 1.33, il était littéralement impossible de réaliser des opérations sur les subresources avec kubectl, seulement les resources.

Kubernetes v1.33: Octarine apporte le support du flag –subresource, mais seulement pour 3 subresources pour l’instant status, scale and resize

Pas de solution de ce côté-là non plus…

Le prompt de réunion

J’avais cette idée en tête depuis l’incident. Lundi matin, au début d’une réunion (pendant que les gens faisaient encore des blagues), j’ai lancé OpenCode avec Claude Opus et j’ai tapé un prompt qui décrivait :

Le problème : kubectl debug ne monte pas les volumes PVC s’ils sont en RWO
La procédure manuelle que je faisais à la main (les étapes douloureuses décrites un peu plus haut)
Ce que je voulais : un outil qui automatise tout ça

OpenCode + Opus m’ont posé 2 questions (et j’ai ajouté une consigne) :

“Quel langage ?” → Go (je persiste)
“CLI seule ou TUI ?” → Les deux (mode non-interactif pour le scripting, TUI pour l’usage quotidien)
Et je lui ai demandé de toujours vérifier à chaque fois qu’il estime avoir fini de lancer le linter golangci-lint (trauma de mon précédent test avec opencode)

Il est parti de lui-même sur l’idée d’une TUI avec Bubble Tea. Puis j’ai arrêté de regarder & j’ai suivi ma réunion.

~30 minutes plus tard, fin de la réunion, j’ai regardé le résultat. Le POC était fonctionnel.

Ce qu’Opus a produit en 30 minutes

Sans aucune intervention de ma part, le LLM a scaffoldé un projet Go complet :

Structure propre : cmd/ pour le CLI Cobra, pkg/k8s/ pour toute l’interaction Kubernetes, pkg/tui/ pour la TUI Bubble Tea
Le coeur du sujet : un appel direct à l’API Kubernetes pour patcher le subresource ephemeralcontainers du pod avec un strategic merge patch incluant les volumeMounts
Mode non-interactif : -n namespace -p pod -v volume:/mount/path, prêt pour le scripting
TUI complète : navigation vim-style (j/k), filtrage fuzzy (/), multi-sélection de volumes, spinner de chargement…
Makefile avec tout un tas de targets (vet, lint, test, build, install)

Ce que je lui ai demandé d’ajouter :

Discovery intelligente : au lieu de scanner tous les pods de tous les namespaces (lent sur un de mes gros cluster), l’outil liste d’abord les PVCs cluster-wide (un seul appel API) pour identifier les namespaces pertinents, PUIS les pods dans le namespace sélectionné. On réduit drastiquement le nombre d’appels à l’API server de kube et la TUI ne montre que les namespaces et pods qui ont des volumes PVC
Héritage du SecurityContext : le conteneur éphémère copie le securityContext du conteneur cible, ce qui lui permet de passer les PodSecurity policies (restricted, baseline…). C’est un cas que je n’avais pas envisagé dans mon prompt initial et qui a planté immédiatement sur un cluster bien configuré.

Sans ces petites améliorations le tool était déjà utilisable (sauf pour le cas où vous avez configuré des SecurityContext), mais c’est nettement plus confortable à l’usage (parce que oui, je l’utilise).

Le code de la mécanique centrale (le patch de l’API) fait quelques centaines de lignes de Go propre. Il récupère le pod, construit le patch JSON avec le conteneur éphémère et ses volumeMounts, l’applique via Patch() sur le subresource, attend que le conteneur soit Running, puis lance kubectl attach. Rien de sorcier, c’est juste ce qu’il faut, bien fait du premier coup.

 ephemeralContainer := corev1.EphemeralContainer{
 EphemeralContainerCommon: corev1.EphemeralContainerCommon{
 Name: containerName,
 Image: opts.Image,
 Command: []string{"/bin/sh"},
 Stdin: true,
 TTY: true,
 VolumeMounts: mounts,
 SecurityContext: targetSecurityContext,
 },
 TargetContainerName: targetContainer,
 }
...
 _, err = c.Clientset.CoreV1().Pods(opts.Namespace).Patch(
 ctx,
 opts.PodName,
 types.StrategicMergePatchType,
 patchBytes,
 metav1.PatchOptions{},
 "ephemeralcontainers",
 )

Les itérations suivantes (30 minutes-ish)

Une fois le POC validé, j’ai enchaîné quelques prompts ciblés. Je lui ai demandé ce qu’on pouvait améliorer. Il a proposé (et implémenté) :

quelques corrections mineures de code qu’il avait mal codé (mais non bloquant)
Warnings : si le SecurityContext hérité a readOnlyRootFilesystem, runAsNonRoot, ou autre mesure de sécurité, l’outil prévient l’utilisateur avant l’attach
Ajouté une CI complète à base de goreleaser et de github actions
Ajouté de la documentation

La cerise sur le Macdo : publication sur Krew

Une fois que j’avais une version propre, j’ai demandé à Opus comment faciliter l’installation du plugin. Il m’a proposé brew, ou alors Krew, le gestionnaire de plugins kubectl.

Je lui ai demandé si le processus d’acceptation du plugin était complexe. Il a dit que non, je lui ai dit “chiche !”.

Il a réalisé l’intégralité du processus :

Création d’un fork de krew-index
Rédaction du manifeste Krew (le fichier .yaml qui décrit le plugin)
Prise en compte de toutes les bonnes pratiques demandées par les maintainers de krew-index (format des URLs de téléchargement, descriptions courtes, checksums SHA256, etc.)
Préparation de la PR, directement sur krew-index

J’ai juste regardé. La PR a été mergée 12 heures plus tard par les mainteneurs.

Résultat : kubectl krew install debug-pvc fonctionne.

Mini échec - déléguer aussi la démo

Fort de ce succès avec la PR pour krew-index, je me suis demandé si on ne pourrait pas faire une démo visuelle (un GIF à ajouter dans le README.md du projet qui montre comment ça fonctionne) avec le LLM.

Je lui ai demandé s’il pouvait le faire avec asciinema et le LLM m’a répondu que “oui” (oui, je discute avec le LLM comme avec mes collègues). Banco, on a essayé.

Le résultat était presque bon, j’aurais pu m’en contenter si j’étais pas quelqu’un de pénible : c’était un poil lent. J’ai l’impression la réactivité du LLM dans ses actions était inégale, ce qui rendait le rendu un peu désagréable au visionnage. J’aurais pu insister jusqu’à avoir quelque chose de correct, mais j’ai finalement enregistré moi-même une vidéo, convertie en GIF avec ffmpeg. C’était plus fluide et plus rapide que d’itérer.

Le diff avec PodSweeper

La différence de ressenti entre ce projet et PodSweeper est frappante. Là où PodSweeper était un combat constant (race conditions, amnésie du LLM, fonctionnalités hors-spécifications), kubectl-debug-pvc s’est déroulé sans accroc notable.

Pourquoi ? Je pense que ça tient à la nature du projet :

Une seule chose à faire, clairement définie : patcher un subresource Kubernetes avec des volumeMounts
Pas de logique concurrente : on fait une requête API, on attend, on s’attache
Un domaine bien documenté : l’API Kubernetes, Cobra, Bubble Tea. Le LLM connaît tout ça par coeur
Pas d’état partagé complexe : pas de goroutines qui se marchent dessus, pas de graceful shutdown à gérer, de microservices multiples
Scope limité : le projet entier tient dans une quinzaine de fichiers, CI et documentation incluses

C’est probablement le terrain de jeu idéal pour un LLM. Un problème bien cadré, un domaine technique bien balisé, une solution linéaire.

Qu’est-ce que j’en pense ?

Objectivement, ce genre de projet “simple” (une chose à faire, simple à comprendre) marche vraiment super bien avec OpenCode + Opus. Je pense que c’est ce genre à cause (grâce) de ce genre de petits projets que la hype est tellement forte autour du développement agentique. On a une idée en tête qu’on avait la flemme de dev, on teste, ça marche. “WOW”.

Mais je ne veux pas non plus minimiser le travail réalisé. Le fait qu’un outil fonctionnel, propre, publié sur Krew et utilisable par n’importe qui ait pu émerger d’un prompt lancé en début de réunion, c’est quand même assez dingue.

Un peu flippant aussi, de se dire qu’un nombre hallucinant de micro tools vont apparaître dans les prochains mois, avec un niveau de qualité probablement inégal.

Le projet

Le code est disponible ici :

https://github.com/zwindler/kubectl-debug-pvc

Installation :

# Via Krew (recommandé)
kubectl krew install debug-pvc

# Utilisation interactive (TUI)
kubectl debug-pvc

# Utilisation non-interactive
kubectl debug-pvc -n my-namespace -p my-pod-0 -v data:/debug/data

Si vous aussi vous avez déjà galéré à inspecter un PVC sur un pod sans shell, essayez. Et si vous trouvez des bugs, vous pourrez blâmer le LLM 😄.

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 :)

Refonte de la page Conférences : data-driven avec Hugo

Fri, 13 Mar 2026 20:00:00 +0100

Grosse refonte de ma page “Conférences” qui était un bazar sans nom, dans lequel j’avais aussi mélangé les podcasts, les publications écrites, etc. Maintenant tout est présenté avec des “cartes”, et bien séparé en 3 pages distinctes.

Tous les fichiers sources (YAML, layouts Hugo, CSS) sont disponibles dans /misc/conferences-refonte/ si vous voulez reproduire ou vous en inspirer.

Le problème

Ma page Conférences était un gros fichier Markdown monolithique. Talks, podcasts, publications, orga : tout mélangé dans des listes à puces, avec des doublons, et de plus en plus pénible à maintenir (surtout depuis le passage en multi-langue FR/EN).

L’approche : données + layouts + CSS

Plutôt que de continuer à maintenir du Markdown, je suis passé en data-driven, comme je l’ai fait pour mon side project “101 ways to deploy Kubernetes” :

Données dans des fichiers YAML (data/)
Présentation dans des layouts Hugo custom (layouts/page/)
Style dans des CSS dédiés (static/css/)
Pages Markdown réduites au strict minimum (front matter uniquement)

Et au passage, j’ai découpé une page fourre-tout en trois : Conférences, Podcasts & Lives, Publications.

Les données YAML

`data/conferences.yaml`

Le plus gros fichier. L’idée clé : un talk (sujet unique) peut être présenté à plusieurs events. Fini la duplication.

talks:
 - id: k8s-scheduling
 title:
 fr: "Limits, Requests, QoS, PriorityClasses, ..."
 en: "Limits, Requests, QoS, PriorityClasses: ..."
 cospeaker: "Quentin Joly"
 slides: "/talks/2025-lrqppobcqvpsslsdk/..."

events:
 - talk: k8s-scheduling  # référence l'id du talk
 event: "DevoxxFR 2026"
 date: 2026-03-22
 type: conference
 - talk: k8s-scheduling
 event: "TNT 26"
 date: 2026-02-12
 type: conference
 video: "https://www.youtube.com/watch?v=..."

organizer:
 - description:
 fr: "Membre de l'équipe d'organisation du Meetup CNCF Bordeaux"
 current: true

Les titres sont bilingues (FR/EN), Hugo sélectionne la bonne langue automatiquement. Les fichiers data/podcasts.yaml et data/publications.yaml suivent le même principe (voir les fichiers sources).

Les pages Markdown minimalistes

L’ancienne page content/page/conferences.md faisait 100+ lignes avec le contenu complet. Voici la nouvelle :

---
title: 'Conférences'
authors:
 - zwindler
type: page
layout: conferences
date: 2022-03-14T18:00:00+00:00
menu:
 main:
 weight: -40
 params:
 icon: messages
toc: false
---

Le point important, c’est layout: conferences dit à Hugo d’utiliser layouts/page/conferences.html au lieu du layout par défaut. Même chose pour podcasts et publications.

Le layout Hugo

Le layout charge les données YAML, calcule des stats, et génère du HTML. Si vous avez déjà manipulé du GoTemplate (helm notamment), ça vous semblera facile à comprendre.

Chargement et indexation des talks :

{{- $data := .Site.Data.conferences -}}
{{- $talks := dict -}}
{{- range $data.talks -}}
 {{- $talks = merge $talks (dict .id .) -}}
{{- end -}}

Compteur dynamique ex. combien de fois un talk a été présenté :

{{- $count := 0 -}}
{{- $talkId := .id -}}
{{- range $data.events -}}
 {{- if eq .talk $talkId -}}
 {{- $count = add $count 1 -}}
 {{- end -}}
{{- end -}}
<p class="talk-card-count">Présenté {{ $count }}x</p>

Événements groupés par année, les 2 plus récentes dépliées, le reste en archive pliable via <details> :

{{- range $i, $year := $sortedYears -}}
 {{- if lt $i 2 -}}
 <details class="year-group" open>
 {{- else -}}
 <details class="year-group">
 {{- end -}}

Les événements à venir (date dans le futur) reçoivent automatiquement un badge “à venir”. Les layouts complets sont dans les fichiers sources.

Le CSS : des cartes partout

Le design repose sur des cartes CSS grid, avec des badges colorés par type (conf, meetup, BBL), du responsive, et un support dark mode. L’essentiel :

.talks-grid {
 display: grid;
 grid-template-columns: repeat(auto-fill, minmax(280px, 1fr));
 gap: 1.2rem;
}

.talk-card {
 background: var(--card-background);
 border-radius: 10px;
 padding: 1.2rem;
 transition: border-color 0.2s ease, box-shadow 0.2s ease;
}

.type-conference { background: #dbeafe; color: #1e40af; }
.type-meetup { background: #dcfce7; color: #166534; }
.type-bbl { background: #fef9c3; color: #854d0e; }
.type-upcoming { background: #fee2e2; color: #991b1b; }

Les CSS complets gèrent aussi le dark mode et les breakpoints mobile. Ils sont dans les fichiers sources.

Bilan

Aspect	Avant	Après
Pages	1 fourre-tout	3 spécialisées
Données	Markdown libre	YAML structuré
Duplication	Oui	Non (relation talk → events)
Stats	Aucune	Automatiques
Design	Listes à puces	Cartes + badges
Multi-langue	Copier-coller	Titres FR/EN dans le YAML
Archives	Tout d’un bloc	Années pliables

C’était un gros morceau : 19 fichiers et ~2400 lignes (une grosse partie du taf, en particulier la traduction markdown => YAML et le CSS, a été faite par un LLM), mais la logique est simple : données dans YAML, présentation dans les layouts, style dans le CSS. Hugo fait le lien au build, sans JavaScript.

Pour ajouter un nouveau talk maintenant, il me suffit d’ajouter une entrée dans data/conferences.yaml et les stats se mettent à jour toutes seules.

Avouez que c’est quand même plus propre qu’un copier-coller dans plusieurs fichiers Markdown :).

Podcasts & Lives

Fri, 13 Mar 2026 00:00:00 +0000

Publications

Fri, 13 Mar 2026 00:00:00 +0000

KubeSolo sur Raspberry Pi Zero : mon article dans Sysops Pratique

Mon, 09 Mar 2026 18:00:00 +0200

Kubernetes sur 512 Mo de RAM, c’est possible

Après avoir teasé sur Bluesky, je peux enfin vous annoncer (fièrement) la publication de mon article dans le numéro de mars/avril de Sysops Pratique (le successeur de Linux Pratique, magazine bien connu des administrateurs système francophones).

Le sujet : faire tourner KubeSolo, une distribution extra-légère de Kubernetes développée par Portainer, sur un Raspberry Pi Zero 2 W et ses maigres 512 Mo de RAM.

KubeSolo, c’est quoi ?

KubeSolo est une distribution Kubernetes minimaliste, pensée pour les environnements très contraints (IoT, edge). Contrairement à K3s ou MicroK8s qui sont économes, mais tout de même pas assez pour un Pi Zero, KubeSolo vise le strict minimum pour faire tourner un kubelet et un runtime de conteneurs.

À vrai dire, même KubeSolo seul ne suffisait pas pour mon Raspberry Pi Zero. Il a fallu pas mal d’optimisations supplémentaires pour que tout rentre dans 512 Mo. Réduction de la mémoire allouée au GPU, configuration de zswap, ajustements du kernel… bref, de la bonne bidouille d’admin sys comme on les aime.

Si vous avez lu mon article de décembre sur l’installation d’Alpine Linux en mode headless sur Raspberry Pi, c’était en quelque sorte le préambule de cette expérimentation. J’y avais déjà exploré les optimisations mémoire possibles sur le Pi Zero.

Doom dans Kubernetes, parce que pourquoi pas ?

Et parce que faire tourner Kubernetes sur un nano-ordinateur c’est bien, mais que ce n’est pas suffisamment absurde à mon goût, j’ai aussi réussi à y faire tourner kubedoom : une version de Doom packagée pour Kubernetes avec un serveur VNC intégré.

Oui, c’est complètement inutile. Mais avouez que c’est beau.

Où trouver le magazine ?

Sysops Pratique est disponible en kiosque et en version numérique. Si le sujet vous intéresse (Kubernetes, Raspberry Pi, optimisation système, ou juste l’envie de voir jusqu’où on peut pousser le bouchon), je vous invite à aller y jeter un œil.

C’est aussi une bonne manière de soutenir la presse technique francophone, qui n’a pas la vie facile.

À propos de la rémunération

Je tiens à être transparent sur ce sujet. Écrire dans un magazine, c’est rémunéré. J’ai beaucoup de chance, je n’ai pas besoin de cet argent.

J’ai donc reversé la totalité des revenus nets de cet article (445€, donc) au Planning Familial de la Gironde.

Pourquoi ? Parce que nous vivons dans un monde de violences sexistes et sexuelles, et que nous assistons au recul des droits des femmes et des communautés LGBT (notamment des personnes transgenres et non binaires), attaqués par les mouvements d’extrême droite, masculinistes, identitaires et autres réactionnaires de tout poil.

Le Planning Familial fait un travail essentiel face à ces menaces (droit à l’information, éducation sexuelle, défense du droit à l’IVG, combat des stéréotypes de genre), et c’est une des meilleures façons que j’ai trouvées de contribuer à mon échelle.