Kubernetes on 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

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

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.

GenAI et développement logiciel : retour d'expérience avec PodSweeper

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

La GenAI, c’est fantastique ?

Pas mal de gens ont sorti leur avis sur la Gen AI pour dev en très peu de temps, alors je me rends compte qu’il est plus que temps que je poste ce brouillon commencé il y a plus de deux semaines 🙃.

Pour le travail, j’utilise de plus en plus d’assistants IA pour m’épauler dans mes tâches du quotidien. En 2024, c’était surtout pour automatiser des tâches pénibles (scripter des trucs, faire une liste pénible de tâches répétitives sans coder ça proprement). Courant 2025, j’ai testé plusieurs fois de lui faire faire de l’Ops et, à chaque fois, les résultats étaient moyens, tant pour concevoir une infra cohérente, fiable et efficiente que pour de l’assistance à la résolution d’incident (cf. mon article sur le sujet).

En 2026, sur ce dernier point, je trouve qu’on n’a toujours pas avancé, même si je reconnais qu’il existe des outils spécialisés que je n’ai pas encore suffisamment testés, open source ou non. Je peux citer k8sgpt et HolmesGPT en open source, et Anyshift avec son agent SRE pour la détection de root cause et la résolution d’incident.

Note : fun fact, dans son post “Mon positionnement sur l’Intelligence Artificielle Générative” posté juste avant moi, Alex cite une longue liste de métiers qui vont profiter de l’IA Gen, et les ops ont le droit à rien d’autre qu’un argument de plus pour passer sur Kube 😭.

J’ai en revanche commencé à utiliser la GenAI pour réaliser plusieurs projets de sites web à 100% (vibe coding ?), dont je vous ai d’ailleurs déjà parlé :

Convertir un blog de Bloggrify à Hugo
Créer un site “joli” (largement au-delà de mes compétences) pour héberger les recherches que j’ai faites sur les différentes façons de déployer Kubernetes
Améliorer la sécurité de mon site web en automatisant la modification du thème Hugo que j’utilise, de manière à avoir la meilleure note sur Mozilla HTTP Observatory

Dans les 3 cas, le résultat est là. Ou plutôt, il semble l’être pour le béotien que je suis.

Je n’ai jamais caché que je n’ai aucune compétence en front, et peut-être que pour un expert du domaine, ce que j’ai fait avec l’IA est horrible (ou non ?). Dans tous les cas, ça ne peut pas être pire que les UIs que j’ai faites sans. Petit exemple 😄 :

ou alors : la GêneAI ?

C’est le genre de retours qu’on voit fleurir de la part de toutes les personnes qui sont vraiment expertes d’un domaine quand elles voient des novices s’extasier. On a de bons exemples avec les vidéos générées par IA : si on ne fait pas attention, on a l’impression que c’est incroyable. Mais n’importe qui avec un œil un peu critique voit tout de suite de GROS problèmes de cohérence. Pareil pour la génération d’image, ou de musique.

C’est aussi vrai pour le code, et on a de très bons exemples de projets vibe codés qui sont d’immondes plats de spaghetti, et des passoires en termes de cybersécurité. Bref, vous l’aurez compris, j’ai beau être utilisateur (quotidien), je ne suis pas “incroyablé” (comme disent mes enfants) par les LLMs, même les meilleurs.

Pourtant, j’ai plusieurs copains qui ne jurent que par ça, notamment des gens bien plus brillants / intelligents (appelez ça comme vous voulez) que moi. Donc je me dis “OK, peut-être que je m’y prends mal. Essayons avec ce qui se fait de mieux” : un IDE type “Claude Code” et un modèle Opus.

L’éditeur

Après avoir fait une petite étude de marché rapide, on se rend compte que les options sont pléthoriques : Claude Code, OpenCode, Amp Code, …

Le problème de Claude Code, c’est le ticket d’entrée. Je ne suis pas encore prêt à lâcher 100 ou 200 € par mois pour l’usage que j’en ai aujourd’hui. Je ne sais pas si l’offre à 20€ me suffirait ou non. Au-delà de rares side projects perso que j’ai cités plus haut, je code peu. Le gros de mes geekeries, c’est de l’infra : installer des Kube et des OS de virtualisation. Des trucs difficiles à automatiser avec un LLM.

On (Pierre surtout) m’a conseillé Amp Code pour du perso, notamment parce que de base, il y a un tier gratuit avec un certain nombre de tokens et que si on n’est pas trop gourmand, c’est assez efficace. J’ai préféré n’en faire qu’à ma tête et tester plutôt sur OpenCode, qui a l’avantage d’être plus flexible sur les providers de LLM et la consommation de tokens. Il est d’ailleurs possible de profiter de modèles locaux (gratuits, donc) ou des modèles inclus gratuitement (en tout cas pour l’instant) tels que GLM 5 Free, qui est plutôt bien placé dans les modèles de dev (surtout, c’est gratuit…).

OK, on a l’éditeur. Maintenant, le code ?

Pour me faire une idée de la pertinence du code généré par mon LLM favori (Sonnet et Opus, depuis un moment), il me faut donc un langage et un cas d’usage que je maîtrise, pour être capable de lui dire “non mais là, c’est n’importe quoi !?”.

Cas d’usage que je maîtrise… vous vous en doutez, il y aura forcément du Kubernetes dedans.

Langage que je maîtrise : j’ai appris Go en 2022 grâce à un collègue de chez Deezer (encore merci Martial !) et j’ai publié quelques outils et fait des contributions mineures. J’ai écrit une grande partie de l’outil GroROTI et aussi commencé (mais jamais terminé) le développement d’un RPG en Go, fortement inspiré de Castle of the Winds, un jeu de mon enfance : gocastle. Et j’ai une capacité professionnelle (même si ce n’est pas le coeur de mon métier) dans mon travail de tous les jours.

Après le contexte, le projet

OK, on a le contexte technique : Kube + Go. Reste donc l’idée à implémenter. Il faut un projet suffisamment volumineux pour que le test soit pertinent, suffisamment rigolo pour que j’aie envie d’y passer du temps perso, mais quand même un peu utile pour que j’aie envie d’en parler et de montrer l’avancement. Et surtout, un projet dont la logique métier reste à ma portée : pour évaluer honnêtement la qualité du code produit par l’IA, il faut que je sois capable de le relire et de le critiquer.

Et là, dans mes tiroirs à idées débiles qui débordent de mon cerveau, je me suis souvenu de ce “pitch” de 2023-2024, que j’avais laissé moisir faute de temps :

PodSweeper : la manière la plus complexe, over-engineerée et chaotique de jouer au démineur.

Partez pas, vous allez voir c’est rigolo. Si !

Au lieu d’une grille visuelle où on clique sur des cases en espérant ne pas tomber sur une “mine”, on a une “grille” virtuelle où chaque case est un Pod et le clic est un kubectl delete.

Oui, c’est débile. Ça me plaît donc beaucoup :).

Au-delà du troll assumé (over-engineering des enfers) de ce jeu, il y a quand même un objectif pédagogique derrière.

Si, si, vraiment.

J’ai pensé le jeu comme une introduction à la sécurité dans Kubernetes, avec des niveaux de difficulté à débloquer, façon CTF de cybersécurité.

Au début, vous pouvez tout faire. Vous pouvez bien sûr jouer normalement (delete un Pod, voir s’il y a des mines à côté) pour vous faire la main. Vous pouvez aussi automatiser les actions (un script qui “clique sur une case” au hasard, récupère les hints de proximité de mines, clique à un endroit safe, …).

Mais vous pouvez aussi tricher.

Et c’est tout l’intérêt du jeu. Dans les premiers niveaux de difficulté, les manifests Kubernetes du jeu sont volontairement vulnérables. On peut donc gagner sans effort, si on sait où chercher.

Cependant, très vite, les niveaux s’enchaînent et les restrictions avec. Assez rapidement, on arrive dans des bonnes pratiques de production qui empêchent toute “triche”. Et si vous trouvez des vulnérabilités non prévues dans le code du jeu lui-même… eh bien, c’est du bonus 😈.

Le processus initial

C’est probablement une erreur, mais j’ai fait toute la phase d’idéation avec Gemini avant de lancer OpenCode. L’expérience aurait probablement été meilleure (a minima plus représentative) si j’avais commencé directement avec OpenCode.

J’ai pondu tout ce que j’avais dans la tête, ainsi qu’un gros pavé informe de dizaines de lignes provenant de mes notes de quand j’ai eu l’idée en 2023, et je lui ai demandé de me sortir un fichier SPECIFICATIONS.md avec toutes les infos importantes, remises dans l’ordre.

Une fois les specs écrites, je lui ai demandé de détailler les différents niveaux et les difficultés que nous allions progressivement ajouter, dans GAMEPLAY.md.

Enfin, j’ai demandé de faire un découpage du projet par “issues” et par priorité, de manière à avoir un MVP rapidement : ISSUES_PRIORITY.md. Mon idée était de donner le plan de bataille très détaillé et découpé finement à OpenCode et de lui laisser dérouler.

Première déconvenue : Gemini 3 Pro est assez mauvais pour ça. Les tâches étaient crédibles(-ish) mais ordonnées n’importe comment (dépendances entre tâches non respectées). J’ai donc lancé pour la première fois OpenCode dans mon repo et je lui ai dit “voilà le contexte, voilà ce qu’on a imaginé comme tâches. Qu’est-ce que tu en penses ?”.

Le bon (open)code…

Dans les trucs assez chouettes : OpenCode + Claude Opus a tout de suite vu que le plan imaginé par Gemini était bancal, et m’a posé des questions et proposé un découpage encore imparfait mais déjà plus cohérent. C’est probablement là le gros de l’intérêt de ces logiciels. Ils embarquent des connaissances pour guider le développement logiciel et surtout (SURTOUT) apportent du cadre.

Assez vite, on finit par se mettre d’accord sur un plan qui me plaît. OpenCode met à jour les documents et se met à développer (scaffolding, création des pipelines, premiers binaires et images Docker vides). On a un projet prêt à développer en un claquement de doigt, c’est assez enthousiasmant, de prime abord.

Les assistants LLMs ont très envie de se jeter dans le code, ça reste vrai avec OpenCode+Opus. Alors même qu’on n’avait pas fini de discuter du plan et des options possibles, il me proposait de lui-même de passer au code. Cela dit, c’était pareil (voire pire) pour Gemini (à qui j’avais dit spécifiquement qu’on n’allait pas faire de code du tout).

Très vite, les créations de fichiers s’enchaînent. J’ai du mal à suivre et à chaque pause (quand le LLM a fini une tâche et qu’il me demande s’il peut passer à la suivante), je prends de longues minutes à lire ce que le LLM a produit. C’est à la fois grisant et épuisant (relire tout ça, c’est dur pour mon cerveau rouillé).

La vitesse brute est impressionnante. En 3 sessions de 1 à 2h, j’ai un MVP fonctionnel. Je comprends qu’on parle régulièrement de 10x engineering quand on parle de génération de code avec les LLMs récents. Si on ne parle pas de génération de code brute (ce qui n’a pas vraiment de sens), à la louche, le code fonctionnel est généré entre 3x et 10x plus rapidement que ce que j’aurais pu faire seul. Des features qui mises bout à bout m’auraient pris des heures à implémenter (génération de la grille, logique de reveal, gestion des états de jeu) tombent en quelques minutes. Vous l’avez déjà lu ailleurs, je dis pareil - le goulot d’étranglement, ce n’est plus le code que je tape : c’est le code que je dois relire.

De ce que j’ai lu, le code est correct, en particulier lors des premières itérations, un peu moins au bout d’un moment. Mais quand je dis “correct”, je sous-vends peut-être le truc : le code produit est du Go idiomatique. Bonne structure en packages, conventions de nommage respectées, gestion d’erreur dans le style Go (quand elle est là…), utilisation appropriée des interfaces. Ce n’est pas juste du code qui compile : c’est du code qu’un reviewer Go ne rejetterait pas d’emblée. On a pour objectif un MVP donc ça reste de la logique “métier” très simple, mais le socle est propre.

Tout est testé, très vite le projet contient une couverture parfaite et 100+ tests alors qu’on ne fait encore rien. Si c’était du code généré par un humain, je ne saurais pas dire si c’est une bonne chose. On est pas du tout dans du TDD, beaucoup de code teste des choses inutiles. Dans le cas du code généré par le LLM, c’est probablement pour le mieux, car le LLM a tendance à ajouter très régulièrement des régressions (on en reparlera). C’est donc intéressant ici, car :

ça ne coûte quasiment rien en temps de dev (ça va tellement vite à générer)
cela permet au LLM de se rendre compte que son code introduit une régression, et de fixer de lui-même, sans attendre.

… et le mauvais (open)code

Côté outil et modèle d’abord, quelques irritants :

Par défaut, OpenCode n’incite pas le LLM à lancer golangci-lint à chaque commit. On corrige ça avec un pre-commit hook et/ou les fameux AGENTS.md / skills, mais ça aurait DÛ faire partie du kit de base d’un projet golang (il y a bien les tests…).
Le LLM (Claude Opus sur OpenCode, mais c’est un biais habituel même en dehors) adore les versions de logiciels qui existaient au moment de son entraînement. Il faut continuellement lui répéter que les versions qu’il suggère sont obsolètes. C’est vrai pour tout : le code Go, les dépendances, les versions des actions GitHub.
On tombe très souvent dans la limite des 100k tokens. On perd du temps à “compacter” et on perd de la précision. Typiquement : le LLM me demande s’il peut git commit des modifs, le contexte se compacte avant que je réponde, et il commit sans mon autorisation en redéroulant le contexte. Sur du code aussi peu sensible, ça va. Mais sur de la prod, ça serait un vrai problème.
Le LLM est souvent amnésique : il oublie qu’il a accès à un cluster kind pour faire des tests réels (alors qu’il l’a fait juste avant la précédente compaction, par exemple).

Côté qualité du code produit, c’est plus préoccupant :

Gestion d’erreur laxiste. Certaines erreurs qui auraient dû retourner un FATAL (controller qui n’arrive pas à s’initialiser correctement !) sont simplement logguées comme ERROR. On se retrouve à ship des versions qui échouent silencieusement. Là encore, ça doit pouvoir se fine tuner avec un AGENTS.md.
Race conditions. Je suis tombé très vite sur des race conditions assez bêtes. Dans mon cas, des pods bloqués en terminating impactaient le jeu suivant (graceful shutdown mal géré). Opus est parti en boucle sans comprendre la source du problème. J’ai dû le stopper et lui spécifier qu’il ne fallait jamais lancer une nouvelle partie sans s’être assuré que la précédente était terminée.
Génération de code en dehors des clous. Parfois, sans crier gare, le LLM ajoute une fonctionnalité qui n’est pas demandée, inutile, voire qui va à l’encontre de la SPECIFICATION écrite précédemment. On est obligé de lui remettre un taquet derrière la tête.

Une fois remis sur les rails, le LLM déroule à nouveau, mais ces épisodes montrent bien que sur du code concurrent ou en dehors de user stories hyper strictes (ce qui sort du workflow de base d’opencode), la supervision humaine reste indispensable.

On me répondra que je débute avec ces outils, et que j’aurais pu éviter certains écueils en configurant mieux mon environnement (AGENTS.md, pre-commit hooks, etc.). C’est vrai.

Mais c’est justement là que le bât blesse : une des promesses vantées de la GenAI appliquée au dev, c’est de permettre à des non-développeurs (ou des débutants) de produire du logiciel de qualité à grande vitesse, de manière à pouvoir ship des logiciels complets. Si pour en tirer le meilleur, il faut déjà être un développeur expérimenté qui sait configurer un environnement complexe (avec les spécificités de ces outils IA), anticiper les race conditions et relire du code concurrent… on n’a pas démocratisé le développement, on a juste donné un outil de plus aux gens qui savaient déjà coder. Mon profil (ops qui code, pas dev pur jus) était précisément le public cible de cette promesse. Et aujourd’hui, “les calculs sont pas bons, Kévin”.

Où j’en suis ?

Depuis tout à l’heure, je vous parle de PodSweeper. Mais il en est où, ce projet ?

Après 3 sessions de 1 à 2h max, sans compter l’idéation, j’ai un MVP fonctionnel. Comme je l’ai dit plus haut, le gain de productivité est indéniable, pour quelqu’un qui n’est pas “dev” de métier.

Le code est probablement “globalement” de meilleure qualité que le code golang que j’aurais pu écrire, mais le LLM laisse passer des trous béants dans la logique métier (tout simplement parce qu’il ne réfléchit pas, alors que moi, oui. Enfin, normalement). Dur pour la confiance… Il faut vraiment rester très méfiant de tout ce qui est produit.

Le code est disponible à l’adresse suivante :

https://github.com/zwindler/PodSweeper/tree/main

Vous pouvez aller voir le code pour vous faire une idée. Si vous n’avez pas peur de vous spoiler, vous pouvez lire la SPECIFICATION.md (spoilers), voire GAMEPLAY.md (j’y détaille tous les niveaux donc c’est giga spoilers).

Vous pouvez (normalement) jouer aux premiers niveaux de difficulté. Ça reste assez basique, si vous avez déjà manipulé kubectl vous devriez trouver la solution très rapidement. Mon but est de rajouter des niveaux au fur et à mesure, j’en ai déjà imaginé 10, certains bien retors 😈 et d’autres viendront peut-être ensuite.

Le code est en MPL v2.0 parce que c’est une licence copyleft que j’aime bien, car elle est à la fois assez peu restrictive, OSI compliant et oblige quand même à reverser les modifs si on en fait dans son coin.

Voilà :) si vous aussi vous trouvez ça rigolo, n’hésitez pas à tester et/ou à me faire des retours.

$ kubectl apply -k https://github.com/zwindler/podsweeper//deploy/base?ref=v0.1.4
namespace/podsweeper-game created
...

$ kubectl wait --for=condition=ready pod -l app.kubernetes.io/name=podsweeper \
 -n podsweeper-game --timeout=60s
pod/gamemaster-54f4dddcc4-6m88z condition met

Have fun !

Kyverno a tué mon API Server. Encore.

Thu, 26 Feb 2026 08:00:00 +0200

Le retour de la vengeance

Vous avez peut-être lu mon article précédent sur etcd il y a 3 ans. Si vous vous en souvenez bien, le crash, c’était etcd, mais le vrai coupable, c’était Kyverno. J’adore Kyverno. C’est vraiment un logiciel que j’aime beaucoup. Notamment parce que c’est puissant(issime). J’ai d’ailleurs écrit un article d’intro et un second qui va plus loin sur le sujet.

Mais le nombre d’incidents et de side effects chelou que ça provoque. Mamamia… C’est pas le premier incident de l’année que j’ai avec Kyverno (oui, on est en février) mais comme celui-là est rigolo, je vous le partage.

Lors d’une opération de maintenance de routine pour mettre à jour un cluster Kubernetes vers la version 1.34 (depuis la 1.32), on s’est retrouvé face au scénario redouté par tout admin kube : un API Server totalement injoignable au redémarrage des nœuds du Control Plane.

Ce qui ressemblait initialement à une erreur réseau classique s’est avéré être un deadlock subtil entre les nouvelles fonctionnalités réseau natives de Kubernetes et notre cher Kyverno 😘.

Spoiler : c’était pas un problème réseau. C’est jamais un problème réseau. Enfin si, des fois. Mais pas cette fois.

L’upgrade qui commence bien

Bon, un upgrade de Kubernetes, c’est devenu assez banal à ce stade. On fait ça régulièrement, on a nos procédures, on est des pros (si si). On passe de la 1.32 à la 1.34 en un seul commit, sans faire le petit saut par la 1.33 comme recommandé.

TKT FRR.

Dans le contexte technique dont je parle, tout est géré as code. De la création des machines jusqu’au déploiement de Talos, en passant par les MachineConfig (les CustomResources pour modifier… et bien, la machine).

Pour plus d’infos, voir la documentation Talos sur les Machine Configs.

Le premier cluster qu’on teste n’a qu’un seul control plane (me demandez pas pourquoi, ça n’aurait probablement rien changé). Talos relance l’API Server dans la nouvelle version et là… rien.

Les logs de l’API Server “chelous” (terme technique) parlent d’eux-mêmes :

I0224 15:32:50.979280 1 default_servicecidr_controller.go:166] Creating default ServiceCIDR with CIDRs: [10.1.0.0/20]
W0224 15:32:50.984784 1 dispatcher.go:225] rejected by webhook "validate.kyverno.svc-fail":
admission webhook "validate.kyverno.svc-fail" denied the request:
Get "https://10.1.0.1:443/api": dial tcp 10.1.0.1:443: connect: operation not permitted
I0224 15:32:50.985342 1 event.go:389] "Event occurred" kind="ServiceCIDR"
apiVersion="networking.k8s.io/v1" type="Warning"
reason="KubernetesDefaultServiceCIDRError"
message="The default ServiceCIDR can not be created"

😬😬😬

La root cause : un magnifique cercle vicieux

Après investigation, on a découvert que l’incident était le résultat d’une collision entre une évolution du core de Kubernetes et notre configuration Kyverno. Un beau cas d’école de deadlock.

Décomposons le mécanisme :

Le nouveau Kind ServiceCIDR

Dans les versions récentes (v1.33+), Kubernetes migre la gestion des plages d’IP de services vers des objets dédiés nommés ServiceCIDR. Au premier démarrage après l’upgrade, l’API Server tente de créer automatiquement l’objet par défaut (par exemple 10.1.0.0/20).

Pour les curieux, la KEP-1880 et la documentation officielle du ServiceCIDR détaillent cette évolution.

C’est nouveau, c’est propre, c’est bien pensé. Sauf que…

Interception par le Webhook Kyverno

Kyverno, configuré avec une failurePolicy: Fail (parce qu’on est des gens sérieux qui ne laissent pas passer n’importe quoi en prod), est programmé pour intercepter les créations de ressources afin de les valider, et faire échouer le call si Kyverno ne répond pas.

Y compris le ServiceCIDR fraîchement créé par l’API Server lui-même.

Deadlock

Et c’est là que ça devient magnifique (“la douleur peut être une source de plaisir” - Mozinor) :

L’API Server suspend la création du ServiceCIDR en attendant le “OK” de Kyverno
Pour contacter le service Kyverno, l’API Server doit router la requête via l’IP du service Kubernetes (en général 10.1.0.1)
Sauf que la couche réseau (routage vers les services) ne peut pas s’initialiser tant que l’objet ServiceCIDR n’est pas validé et créé

C’est l’œuf et la poule, version “j’ai les clés de la voiture dans la voiture fermée à clé”.

PTSD. Oui ça m’est arrivé. Dans le désert. Sans réseau.

Profit.

L’API Server tombe en timeout ou renvoie une erreur connect: operation not permitted en tentant de joindre le webhook, bloquant ainsi sa propre initialisation. CrashLoopBackOff sur l’API Server. :D

Sortir du deadlock

Pour sortir de ce deadlock, il faut bypasser temporairement la couche d’admission. Facile, non ?

Le workaround “habituel” : inutile

Les deadlocks avec Kyverno, on a l’habitude à ce stade. Normalement, comme kube-system est ignoré, on peut simplement se connecter avec un kube-config de secours (breaking glass, on est en OIDC normalement) qui a le cluster role cluster-admin et supprimer les validating webhooks de Kyverno :

kubectl delete validatingwebhookconfiguration kyverno-resource-validating-webhook-cfg

Sauf que là, c’est l’API Server qui ne démarre même pas. Mon kubectl ne risque pas de fonctionner !

Le vrai workaround : désactiver les webhooks au boot

La solution qu’on a choisie a été de modifier la configuration de l’API Server pour désactiver temporairement les webhooks de validation au démarrage. Mon éminent collègue Maxime a édité à chaud le machine config (avec un accès talosctl breaking glass) pour ajouter le flag suivant directement dans les extraArgs de l’API server :

--disable-admission-plugins=ValidatingAdmissionWebhook

Pour ceux qui ne savent pas trop comment ça fonctionne l’admission control dans Kubernetes, sachez juste qu’il y a une liste de plugins “par défaut” mais que tout est débrayable. Je ferai peut-être un jour un deep dive sur l’admission control dans Kubernetes, c’est fascinant ;).

Avec ce flag, l’API Server peut enfin créer ses objets ServiceCIDR sans demander la permission à personne (on bypass complètement tous les mécanismes de validation que Kyverno ou assimilé enforce), le réseau s’initialise, Kyverno démarre, et on peut ensuite retirer le flag et relancer proprement.

L’option “golri” qu’on n’a pas testée

Personnellement, je trouvais très rigolo l’idée d’aller modifier directement la base etcd pour supprimer la clé du webhook qui posait problème (là aussi en passant par talosctl) :

# Exemple via etcdctl
etcdctl del /registry/admissionregistration.k8s.io/validatingwebhookconfigurations/kyverno-resource-validating-webhook-cfg

Mes collègues étaient moins chauds : “Ouais mais tu comprends, si on casse etcd ça va être pénible”. On a joué la sécurité avec le flag. Je suis super déçu, on n’a pas testé 😂.

La solution permanente : les MatchConditions

OK, maintenant que le cluster est reparti, comment on s’assure que ça ne se reproduise pas au prochain upgrade ?

La solution propre consiste à utiliser les matchConditions (introduites en Kubernetes 1.27) au niveau de la ValidatingWebhookConfiguration. Ça permet d’exclure les ressources critiques de bootstrap réseau avant même que la requête ne tente de sortir de l’API Server vers le pod Kyverno.

Voir la doc officielle sur les matchConditions.

On utilisait déjà cette option pour limiter le trafic parfois abusif de Kyverno (si vous administrez du Kyverno, vous savez de quoi je parle) sur un certain nombre d’événements (on écroule l’API server et/ou Kyverno en CPU ou RAM, selon les cas). Il a suffi d’ajouter les exclusions pour les nouveaux types :

# Exclusion des ressources de bootstrap réseau pour éviter le deadlock
matchConditions:
 - name: 'exclude-ServiceCIDR'
 expression: '!(request.kind.kind == "ServiceCIDR")'
 - name: 'exclude-IPAddress'
 expression: '!(request.kind.kind == "IPAddress")'

Avec ça, quand l’API Server crée un ServiceCIDR au boot, la requête ne passe même plus par le webhook Kyverno. Pas de dépendance circulaire, pas de deadlock, tout le monde est content.

Conclusion

Comme dirait notre cher (non) président :

qui aurait pu prévoir ?

Bon ok, il suffisait de lire les release notes de Kubernetes 1.33. Cela étant dit, on a un cluster de staging, il sert à ça. On a cassé staging, no big deal

Peut-être qu’on lira quand même, la prochaine fois ?

Touraine Tech 2026 - Récap du jour 1

Thu, 12 Feb 2026 18:00:00 +0200

De retour à Touraine Tech !

Pour la 2ème fois, j’ai participé à la conférence Touraine Tech (la première fois c’était en 2022).

Contrairement à 2022, la conférence a maintenant lieu à l’Université de Sciences de Tours (et non plus à Polytech) et se déroule sur 2 jours. L’occasion de revenir profiter des tourangelles et des tourangeux qui nous reçoivent toujours si bien.

Keynote d’ouverture - La guerre informationnelle

Clément Hammel-Cazenave d’Agoratlas nous a proposé une keynote percutante sur les ingérences numériques et la guerre informationnelle en cours.

Son point de départ : la crise agricole autour de l’abattage des troupeaux bovins à cause de la dermatose nodulaire. En analysant 500k tweets fournis par Visibrain, son équipe a reconstruit le graphe des interactions sur les réseaux sociaux. En utilisant la méthode de Louvain (maximiser les liens intra-communauté et minimiser les liens inter-communautés), puis en labellisant manuellement les communautés, ils ont pu mettre en évidence un phénomène inquiétant : l’exclusion de la parole experte, cantonnée à sa petite bulle, pendant que le débat se polarise entre extrêmes (droites).

Clément a aussi présenté D3lta, un outil open source créé par Viginum, permettant de détecter les contenus dupliqués dans l’objectif de repérer les tentatives d’ingérences numériques.

Point important soulevé : les réseaux sociaux impactent Internet de manière générale, y compris les LLMs qui sont entraînés en partie sur ces contenus. C’est une stratégie délibérée pour transformer les LLMs en “machines à narratif (russe)”.

Mais ils ont aussi des impacts parfois importants sur “la vraie vie”. L’exemple des élections en Roumanie est frappant : un “inconnu” est arrivé au second tour grâce à des ingérences russes sur TikTok. L’élection a été annulée par la Cour constitutionnelle.

Comment riposter ?

Viginum : réseau de coordination et de protection des élections, créé après l’assassinat de Samuel Paty. La France est très en avance sur ce sujet
L’Arcom : manque malheureusement de moyens et de soutien politique
DMA / DSA : les régulations européennes
Nous : quitter X (openportability.org, non mais sérieux, vous attendez quoi ?), faire de l’analyse soi-même (NodeXL, Python, Gephi), éducation, contribuer aux outils comme ATProto ou Gephi

Une keynote qui fait réfléchir sur notre responsabilité collective face à ces enjeux.

Mes trains Jouef passent au numérique, avec des Raspberry et TinyGo !

Un talk bonbon, qui parle d’une belle histoire de side project tech intergénérationnel ! Les speakers nous ont raconté comment ils ont modernisés les trains analogiques du grand-père.

Le problème de base : les trains analogiques fonctionnent en 14V/-14V (pour avant/arrière), mais il est difficile d’en faire circuler plus de 3 simultanément sans collisions. La solution professionnelle, le DCC, permet d’envoyer de la data dans le courant pour gérer plusieurs trains.

La solution DIY en 2024 : TinyGo sur Raspberry Pi Pico W (version Wireless).

L’implémentation a été semée d’embûches techniques :

Pont abaisseur de tension (14V → 5V) + contrôleur PWM pour la vitesse
Problèmes de stabilité du réseau électrique
Stack réseau WiFi absente de TinyGo, donc à recoder !
Watchdog pour reboot automatique en cas de deadlock

Pour réduire encore la taille et rentrer dans certains trains, il a dû changer de carte. Exit le WiFi/TCP-IP, bonjour le Bluetooth ! Résultat : latence passée de 300ms à 1ms. L’inconvénient : cette carte n’a qu’un seul core, donc il a fallu ruser avec des channels pour avoir des boucles non bloquantes. Fini le REST, place aux WebSockets.

Un side project comme on les aime, avec ses galères et ses victoires !

Notre talk : Limits, Requests, QoS, PriorityClasses

C’était notre tour avec Quentin Joly ! Nous avions amélioré le talk par rapport au DevFest Nantes, j’avais rajouté une démo et changé une autre qui devait être un peu stable. Enfin ça c’était sur le papier

Spoiler : les deux nouvelles démos ont échoué… et nous n’avions pas de backup 🙈.

Ce n’est pas grave en soi, les 6 autres démos ont parfaitement fonctionné et le public a été indulgent. Nous avons eu de très bons retours sur OpenFeedback, avec des commentaires très cools mettant en avant que le talk était accessible même aux “non sachants” Kube :

Je rejoins les autres commentaires, côté développement je n’avais qu’une brève connaissance de kubernetes et j’ai pu suivre la conf’ et apprendre plein de choses ! Beau challenge pour les démos c’était au top ! Bravo et merci !

La leçon à retenir : même quand on est sûr de la démo et qu’on la lancée 10 fois sans incident, toujours avoir un plan B !

Pause déjeuner

On souffle, on profite du créneau du midi pour déguster un super potage ainsi qu’un très bon burger au pulled pork. Le traiteur était excellent, et malgré le nombre de personnes à nourrir les plats sortaient très vite. Chapeau !

Metal-As-A-Service : Gérer votre bare-metal comme une machine virtuelle !

Julien Briault continue de nous émerveiller avec la prouesse qu’il a lancé (au début seul, maintenant avec la petite 20aine de bénévoles) en réinternalisant l’informatique des 113 associations, en mutualisant sur une plateforme commune “le cloud du coeur”, entièrement construite sur des dons et des produits open source.

La philosophie : “Tout doit être API”. Ça me rappelle un peu le fameux Bezos API Mandate, mais je ne suis pas sûr que Julien apprécierait la comparaison 😉.

L’infrastructure est répartie sur 3 régions (Paris, Chartres, Marseille), avec pour chaque région 3 datacenters proches pour la haute disponibilité. Le choix du bare-metal permet d’éviter les dépendances centralisées (on se souvient tous de la panne US-EAST-1 qui a fait tomber les 3/4 d’Internet…).

Pourquoi MAAS (Metal-As-A-Service de Canonical) ?

Ironic (OpenStack) : mauvaise UX, nécessite un OpenStack complet
Tinkerbell : a besoin de Kubernetes
MAAS : existe depuis 2012, AGPL, supporte tous les vieux serveurs

Le cycle de vie : boot PXE, récupération des paramètres BMC, remontée dans l’inventaire, configuration BMC pour le power control managé par MAAS. Tout est API : les calls sont envoyés à Netbox et Slack.

Point FinOps intéressant : grâce à Open Baremetal (écrit en Rust) qui utilise RAPL (Running Average Power Limit) via Scaphandre et VictoriaMetrics, ils allument et éteignent les machines en fonction de seuils. Résultat : division par 3 de la consommation électrique et 300 000€ économisés par an (soit 300 000 repas !).

Pause et discussions avec les sponsors

J’ai longuement discuté avec Horacio et Yannick (akanoa) de Clever Cloud. Au menu : développement à l’ère de la GenAI, ordonnancement d’agents IA, et… Kubernetes managé chez Clever Cloud. Je n’en dis pas plus 😏.

Les Agents : l’ordre dans le chaos des IA

Thierry Chantier nous a fait un état des lieux du monde des agents IA.

Rappel sur les LLMs : ce sont des modèles statistiques entraînés sur des montagnes de texte. On est passé du “texte only” à des systèmes “agentic” qui bougent très vite. Un agent, c’est une entité autonome avec la capacité de décomposer des tâches et de s’auto-évaluer.

Conseil important : spécialiser les agents pour optimiser les outils, réduire le domaine et être plus performant. On peut même utiliser des SLM voire des TinyLM pour des cas d’usage spécifiques.

Les différents types de workflows :

Séquentiel : les agents s’enchaînent
Routeur : route vers le bon agent
Hand-offs : comme le routeur, mais les agents peuvent déléguer s’ils s’estiment incapables de répondre
Superviseur : comme le routeur, mais vérifie que l’objectif est atteint

Côté frameworks, Thierry a mentionné :

LangGraph (de LangChain) : un peu trop couplé
ADK (Agent Development Kit)
Strands Agent : beaucoup plus agnostique
Crew.ai

J’ai aimé la mention de l’option Tracing=true dans crew.ai. Si je comprend bien, ce sont des traces OpenTelemetry et pour pouvoir debug un workflow, ça me parait hyper intéressant.

KO technique

J’avais prévu de voir le talk de Stéphane Philippart sur les CLI boostées à l’IA avec Picocli, ou celui de Laurent Grangeau sur la protection de la mémoire.

Mais la fatigue de la soirée “before” passant par là, j’ai décidé de rentrer un peu plus tôt à mon hôtel, en attendant la soirée speaker. Celle-ci a eu lieu dans un bar à jeux privatisé, l’occasion de rencontrer d’autres speakers autour de tapas et d’une bière bien fraîche.

À suivre…

La suite au prochain épisode avec le récap du jour 2 ! Stay tuned 🎉

101 façons de déployer Kubernetes : une nouvelle UI pour explorer les 118+ solutions

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

De Google Sheet à une vraie application web

Vous vous souvenez peut-être de mes précédents articles sur ce projet : d’abord un simple Google Sheet avec 93 méthodes, puis un dépôt GitHub avec plus de 100 entrées.

Aujourd’hui, je peux présenter la dernière itération de ce projet : une vraie interface web pour explorer toutes ces solutions !

👉 101-ways-to-deploy-kubernetes

Pourquoi une UI ?

Le tableau Markdown sur GitHub, c’était déjà mieux que le Google Sheet pour la collaboration, mais à peine. Difficile à parser, difficile de rajouter des colonnes sans que ça devienne trop le bazar (c’était déjà le cas, ahah), et surtout, ultra MOCHE.

J’ai donc décidé de transformer tout ça en une interface moderne et intuitive, avec l’aide d’un LLM.

Stack technique : Astro + Tailwind

Pour ce projet, j’ai choisi une stack simple mais efficace :

Astro : un framework moderne qui génère des sites statiques ultra-rapides
Tailwind CSS : pour un design responsive sans prise de tête

Le résultat ? Un site léger, plutôt rapide, et qui fonctionne aussi bien sur desktop que sur mobile (même si l’expérience desktop reste plus confortable vu la quantité de données).

Les fonctionnalités

Des cartes pour chaque solution

Fini le tableau digne d’un dev back (non, pire, un ingé kube…) ! Chaque outil dispose maintenant de sa propre “carte” animée avec :

Le logo du projet
Le type de licence (OSS ou propriétaire)
Le nombre d’étoiles GitHub
Des liens directs vers le projet et des ressources tierces (blogs indépendants, REX, tutos…)

Des filtres puissants

Vous cherchez uniquement des solutions open source ? Des outils pour le développement local ? Des plateformes de management ?

Les filtres par catégories permettent de naviguer facilement :

Desktop (développement local)
Managed (offres cloud)
Self-hosted (automatisation on-premise)
Infra As Code
Kubernetes OS (systèmes spécialisés)
Management Platform
Kubernetes in Kubernetes

Et vous pouvez aussi filtrer par statut (actif, abandonné) ou afficher uniquement les solutions open source ou production ready.

Une barre de recherche

Vous savez ce que vous cherchez ? Tapez directement le nom dans la barre de recherche pour trouver la solution en un instant.

Des tags pour affiner

Au-delà des catégories, les tags permettent d’identifier rapidement les technologies sous-jacentes (kubeadm, k3s, k0s…).

Le saviez-vous ? Au moins 18 outils utilisent kubeadm !

En compilant toutes ces données, j’ai découvert quelque chose de fascinant : au moins 18 outils utilisent kubeadm comme backend pour déployer Kubernetes ! 🤯

Et ce n’est même pas en comptant les offres managées des cloud providers !

C’est typiquement le genre d’information qu’on peut maintenant visualiser instantanément grâce à cette nouvelle interface.

Un projet collaboratif

Le projet reste 100% open source et collaboratif. Les données sont toujours stockées dans le dépôt GitHub, et l’UI est générée automatiquement à partir de ces données (j’ai même rajouté des previews pour les PRs).

Il manque un outil ou un provider ? Vous avez repéré un bug ? N’hésitez pas à ouvrir une issue ou à soumettre une Pull Request !

Le projet compte maintenant 118 solutions (et je sais qu’il en manque certainement), avec pour chacune :

Des liens à jour
Le statut du projet
Des références externes (tutoriels, retours d’expérience…)

Essayez, commentez, partagez

Rendez-vous sur zwindler.github.io/101-ways-to-deploy-kubernetes pour explorer toutes ces solutions !

OK, c’est un infâme “call to action” comme on en voit sur tous les réseaux sociaux. Soit.

Cependant, je ne peux pas savoir si c’est utile (ou non) si vous ne le faites pas. Je peux le laisser en l’état (ça n’est pas génant en soit, j’ai plein d’autres side projects qui n’attendent que mon temps libre) ou le faire vivre, si ça vous plait / sert.

Et si vous trouvez ce projet utile, n’hésitez pas à :

Star le projet sur GitHub
Partager avec vos collègues de la communauté Cloud Native
Contribuer en ajoutant des outils manquants ou en corrigeant des erreurs

Merci d’avance ! 🙏