cluster on Zwindler's Reflection

Test de CKE, le Kubernetes managé chez Clever Cloud (partie 1)

Tue, 12 May 2026 12:00:00 +0200

La suite de ma saga avec Clever Cloud

Ça fait maintenant quelques années que je teste les produits de Clever Cloud sur ce blog. En 2022, j’avais testé le Clever Kubernetes Operator, qui permet de provisionner des services managés (MySQL, Redis, Pulsar…) directement depuis un cluster Kubernetes via des CRDs. En 2025, j’ai réessayé leur offre d’hébergement de sites statiques, et j’ai même poussé le délire jusqu’à déployer un control plane Kubernetes sur leurs apps Linux, pour rigoler en attendant leur offre managée.

Bref, à la fin de cet article, je concluais avec un trollface et un “j’attends mon accès au k8s managé de Clever Cloud”. Et bien… c’est maintenant !

Clever Cloud a lancé CKE (Clever Kubernetes Engine) en bêta publique. J’ai eu accès en avant-première pour tester et je leur ai fait quelques retours. Maintenant que le produit est public, j’ai enfin le droit de vous partager mes impressions.

CKE c’est quoi exactement ?

CKE est l’offre Kubernetes managée de Clever Cloud. Le positionnement est clair : Vanilla Kubernetes, pas de lock-in, le plus standard possible dans l’usage du cluster.

Ce qui distingue CKE des offres plus conventionnelles, c’est ça :

Materia etcd : leur implémentation maison de l’API etcd, construite sur FoundationDB (pas d’etcd VM à provisionner ou dimensionner, c’est serverless). C’était pas gagné, cf cet article de Pierre Zemb “Diving into Kubernetes’ Watch Cache”
Infrastructure souveraine et isolée des autres clients : tout tourne sur des VMs dédiées, en France. Rien de mutualisé entre tenants.
Cilium + eBPF natif, avec WireGuard pour le chiffrement inter-nodes.

Activation : c’est un peu caché

CKE est en bêta publique, mais l’accès n’est pas actif par défaut. Il faut l’activer, soit via la CLI :

clever features enable k8s

Note : les commandes clever k8s sont disponibles dans la CLI à partir d’une version récente de leur CLI, idéalement version 4.9+.

Soit depuis l’interface web, dans l’onglet Labs de votre compte : https://console.clever-cloud.com/users/me/feature-list

L’onglet Labs n’est pas particulièrement mis en avant dans la console (il faut savoir où chercher). Une fois le feature flag activé, un nouveau menu apparaît dans la console.

Création d’un cluster

Depuis la CLI, voici la commande minimale pour créer un cluster :

clever k8s create moncluster --watch

--watch suit le déploiement jusqu’à ce que le cluster soit ACTIVE. En pratique, ça ressemble à ça :

⏳ Cluster status: DEPLOYING. Waiting for 10s before checking again...
✓ Cluster moncluster (kubernetes_01KRDDW6YNMDE7ZT0RYD3MY0GE) deployed successfully

On peut passer tout un tas d’options : version K8s (--cluster-version 1.36), topology, flavor du control plane, replication factor, autoscaling, CSI… On y reviendra.

Mais il est aussi possible, depuis peu, de créer un cluster via formulaire de création, avec un récapitulatif en temps réel.

On y retrouve tous les paramètres : version K8s, topology, flavor, replication factor, autoscaling, persistent storage. C’est bien fait, les topologies sont expliquées inline. Le nom de cluster est généré aléatoirement (style cunning-arcane-runic-corsair, modifiable bien sûr).

Les 3 topologies : Essential, Business, Enterprise

C’est l’un des aspects les plus inhabituel de CKE. Trois topologies sont disponibles à la création (et immutables après, ce qui oblige à bien choisir dès le départ).

Topology	Offre	Ce que vous payez	Usage typique
`ALL_IN_ONE`	Essential	rf (replication factor) × VM bundle (CP + worker intégré)	Dev, test, petits clusters
`DEDICATED_COMPUTE`	Business	rf × VM CP + chaque worker VM	Prod avec isolation CP/workers
`DISTRIBUTED`	Enterprise	5 composants × rf × VM + workers	Prod HA fine par composant

ALL_IN_ONE est la topologie par défaut. Le control plane et un worker node partagent la même VM (c’est le mode k3s-style, pour reprendre la description de la console). Ça a une conséquence concrète : kubectl get nodes liste le node du control plane comme worker disponible pour les pods.

DEDICATED_COMPUTE isole le CP sur ses propres VMs, les workers sont dans des node groups séparés. Avec un replication factor de 3, les VMs sont réparties sur les 3 datacenters parisiens de Clever Cloud (un datacenter peut tomber sans impacter le control plane).

DISTRIBUTED pousse l’isolation plus loin : chaque composant du CP (apiserver, controller-manager, scheduler, cloud-controller-manager, node-group-operator) tourne sur sa propre VM, avec sa propre flavor et son propre replication factor. J’ai du mal à voir dans quel cas c’est utile, mais pourquoi pas.

Un mot sur la tarification

Contrairement à certains cloud providers (de moins en moins cela dit…) qui offrent parfois le control plane quand il est mutualisé et ne facturent que les workers, Clever Cloud facture une vraie VM dédiée par cluster (rien de mutualisé entre tenants).

En ALL_IN_ONE, cette VM fait aussi office de worker, ce qui en fait paradoxalement l’option la moins chère. La flavor S (8 vCPU / 12 GB RAM) revient à 64 €/mois, CP et workers inclus sur la même machine. L’isolation se paye davantage : DEDICATED_COMPUTE commence à 96 €/mois pour le CP seul (+ workers séparés), DISTRIBUTED à 180 €/mois minimum pour 5 composants CP en 2XS.

Ce n’est pas donné pour du dev, mais le prix s’explique par le choix architectural : vous avez vraiment 8 vCPU / 12 GB de RAM rien que pour vous, pas un dixième de VM partagée entre dix clients.

Note : pendant la bêta publique, le CSI (Ceph) et les LoadBalancers ne sont pas encore facturés. Seuls le CP et les workers le sont.

Récupérer le kubeconfig

clever k8s get-kubeconfig moncluster > ~/.kube/clever.yaml
kubectl --kubeconfig ~/.kube/clever.yaml get nodes

Un détail à noter : l’API server écoute sur un port non standard (1032 ou 1022 selon les clusters). Ce n’est pas bloquant dans la plupart des environnements, mais j’ai eu la surprise de me retrouver bloqué depuis un réseau qui filtre les ports non-standards. À garder en tête si vous devez accéder au cluster depuis un réseau d’entreprise restrictif.

Anatomie du cluster

Une fois connecté, quelques observations :

$ kubectl get nodes -o wide
NAME STATUS VERSION OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
control-plane-be4e3383-...-node Ready v1.36.0 Exherbo Linux 6.19.14-clevercloud-vm-dirty (amd64) containerd://2.3.0

Exherbo Linux : on retrouve bien la marque de fabrique de Clever Cloud. Pour celleux qui ne connaissent pas, Exherbo est une distro minimaliste et source-based, peu connue en dehors de cercles très spécialisés. Le kernel est un build custom Clever Cloud (clevercloud-vm-dirty), et le container runtime est containerd 2.3.0.

Les composants pré-installés dans kube-system :

$ kubectl get pods -A
NAMESPACE NAME READY
kube-system cilium-tv9m7 1/1 # CNI
kube-system cilium-operator-7db7f998d7-z5zq8 1/1
kube-system coredns-5986bf5c44-wkzb9 1/1
kube-system konnectivity-agent-l26kl 2/2 # proxy CP->workers
kube-system kube-state-metrics-75b86d74f6-6slx8 2/2
kube-system kubelet-csr-approver-68d5bfcb6b-kgz5c 1/1
kube-system metrics-server-559c9b85f9-wflvk 1/1
kube-system cc-collector-wwpld 1/1 # collecteur OTel Clever Cloud

Quelques absences notables par rapport à une install classique : pas de kube-proxy (remplacé par Cilium en mode eBPF kube-proxy replacement).

Pour la petite histoire, les premiers teasers de CKE avaient montré l’usage de flannel. Heureusement que les équipes de clever ont écouté la communauté et migré vers cilium.

Konnectivity : l’isolation réseau du control plane

Le pod konnectivity-agent mérite une mention. C’est un composant qu’on retrouve assez souvent sur les Kubernetes managés et certaines distribution de Kubernetes. Il tourne sur chaque node (2 containers : proxy-agent + haproxy) et sert de proxy entre le control plane et les workers. Le CP ne parle pas directement aux pods : tout le trafic CP->workers (logs, exec, port-forward, métriques) passe par ce tunnel.

Pour un service managé, c’est la bonne pratique : le control plane n’a pas besoin d’accès réseau direct aux pods, et les workers n’ont pas besoin d’exposer kubelet directement au CP.

Materia etcd

Pas de pod etcd dans le cluster : c’est normal. Clever Cloud utilise Materia etcd, leur implémentation serverless de l’API etcd construite sur FoundationDB. C’est transparent pour vous.

Cilium

Le CNI est Cilium v1.19.1. Pour aller plus loin sur l’intégration Cilium/CKE, je vous recommande l’article de Joseph qui est le premier à en avoir parlé publiquement et qui s’y connaît bien mieux que moi sur le sujet.

Les NodeGroups

Les workers sont gérés via une CRD custom NodeGroup (groupe api.clever-cloud.com/v1).

apiVersion: api.clever-cloud.com/v1
kind: NodeGroup
metadata:
 name: mes-workers
spec:
 flavor: S
 nodeCount: 3

kubectl apply -f nodegroup.yaml

Les nodes apparaissent dans kubectl get nodes environ 35-40 secondes après la création du NodeGroup. La CRD supporte le subresource scale, ce qui permet de faire :

kubectl scale nodegroup mes-workers --replicas=5

Les flavors disponibles en ALL_IN_ONE : S (8 vCPU / 12 GB), M (10 vCPU / 16 GB), L (12 vCPU / 24 GB), XL (16 vCPU / 32 GB). Un quota global s’applique au niveau de l’organisation (40 vCPU / 40 GB RAM par défaut, tous clusters confondus). Ca peut probablement être augmenté en faisant une demande au support, mais j’ai pas assez d’argent à crâmer pour justifier une telle demande 😅.

En cas de dépassement de quota, le NodeGroup passe en phase QuotaExceeded avec un message d’erreur très lisible :

'Quota exceeded: RAM max: limit = 40.0 GB | actual = 48.0 GB | excess = 8.0 GB'

C’est appréciable : on sait exactement ce qui bloque et de combien.

La CLI propose aussi une gestion des node groups :

clever k8s nodegroups create moncluster workers M:3
clever k8s nodegroups update moncluster workers --count 5
clever k8s nodegroups update moncluster workers --autoscaling --min 2 --max 10

Combien de temps pour booter ?

Un des points forts mis en avant par Clever Cloud. J’ai mesuré avec un script de benchmark (3 runs) et via la commande clever k8s activity qui expose les timestamps précis de chaque étape :

clever k8s activity moncluster --format json

[
 { "operation": "CREATE", "stepName": "Deploy Control Plane", "status": "STARTED", "createdAt": "2026-05-12T06:27:11Z" },
 { "operation": "CREATE", "stepName": "Deploy Control Plane", "status": "COMPLETED", "createdAt": "2026-05-12T06:27:28Z" },
 { "operation": "CREATE", "stepName": "Install Plugins", "status": "STARTED", "createdAt": "2026-05-12T06:27:28Z" },
 { "operation": "CREATE", "stepName": "Install Plugins", "status": "COMPLETED", "createdAt": "2026-05-12T06:28:01Z" }
]

activity détaille chaque étape du bootstrap : création du réseau, déploiement de Materia LogicalDB, déploiement du control plane, configuration du load balancer, installation des plugins. Elle couvre aussi les opérations sur les NodeGroups.

Résultats mesurés (K8s 1.35, 3 runs, 5 nodes S) :

Étape	Moyenne
Cluster DEPLOYING -> ACTIVE	~57s
NodeGroup -> 1er node Ready	~38s
NodeGroup -> tous les nodes Ready	~46s (donc 8s après le premier node)
Suppression du cluster (API)	~244ms

Pour comparaison, SKS d’Exoscale bootstrappe le control plane en ~2 minutes (on me souffle dans l’oreille que ça a peut être baissé depuis). Et à la bonne époque où je faisais du AKS, c’était carrément 20+ minutes (j’espère qu’ils se sont améliorés depuis). Clever Cloud se place très haut sur ce critère.

Réseau, services, sécurité

LoadBalancer: chaque service de type LoadBalancer provisionne un L4 LB avec deux IPs publiques dédiées.

Ingress : pas d’ingress controller préinstallé. Traefik s’installe sans problème via Helm.

NetworkPolicies : Cilium étant le CNI natif, les NetworkPolicies sont enforced nativement. Pas besoin d’installer quoi que ce soit en plus.

Note pour ceux qui auraient lu mon article de mars sur le CNI chaining Flannel/Cilium : cet article était né des tests sur la bêta privée de CKE, qui utilisait Flannel à l’époque. Depuis le passage en bêta publique, CKE livre Cilium nativement (les NetworkPolicies fonctionnent out of the box).

Pod Security Admission : aucun namespace n’a de labels PSA par défaut (ni kube-system, ni default). Ça signifie que les pods sont en mode privileged implicite, sans restriction. On peut bien sûr configurer ça soi-même, mais sur un cluster managé on s’attendrait à avoir au minimum des profils baseline ou restricted préconfigurés sur les namespaces utilisateur.

RBAC : pas de surprise, le kubeconfig fourni donne un accès cluster-admin. A ne pas utiliser au delà de l’administration initiale ;-).

Stockage (CSI)

Le CSI n’est pas activé par défaut. Pour l’activer :

clever k8s add-persistent-storage moncluster

Activation en ~1 minute. Une StorageClass csi-rbd-sc (défaut) est créée, provisionnée par rbd.csi.ceph.com (Ceph RBD), filesystem XFS, volume expansion activée.

Les tests complets du cycle de vie (PVC, resize, snapshots) feront l’objet de la partie 2.

Un vrai déploiement : GroROTI

Histoire de valider que tout fonctionne de bout en bout, j’ai déployé GroROTI (ma propre application web en golang de ROTI) via Helm, avec Traefik en ingress controller et un certificat TLS.

helm install traefik traefik/traefik -n traefik --create-namespace
helm install groroti oci://ghcr.io/zwindler/groroti-chart \
 -f values-clever.yaml \
 --namespace groroti --create-namespace

Au bout de quelques minutes, l’application tourne sur groroti.zwindler.fr, accessible publiquement, TLS inclus. Ça fonctionne.

Bugs rencontrés (alpha / bêta oblige)

LoadBalancer : lors de mes premiers tests (alpha / bêta privée), j’avais eu un cas où l’EXTERNAL-IP restait en <pending> pendant… 32 heures. Ce problème semble avoir disparu en bêta publique.

Cluster FAILED sans diagnostic : lors de mes tests, j’ai eu plusieurs clusters qui passaient en FAILED ~25 secondes après la création, sans aucun message d’erreur exploitable. clever k8s get <ID> retourne juste Status: FAILED, même avec --verbose. Aucune commande logs ou events pour un cluster n’existe dans la CLI.

C’est d’autant plus frustrant que le status QuotaExceeded des NodeGroups est, lui, extrêmement bien documenté dans le message d’erreur. Il y a une belle asymétrie là.

Le bug a été résolu côté Clever Cloud dans la nuit. Mais le manque de diagnostic reste un point à améliorer. L’UI est aussi encore clairement en bêta, avec un petit bug graphique que j’ai pu remonter.

Conclusion (partie 1)

Première impression globalement positive. CKE est impressionnant pour une bêta :

Boot time excellent : ~57s pour le cluster (CP à part ou All in one), ~38s pour le premier node quand on ajoute des NodeGroups (dans le haut du panier des Kubernetes managés que j’ai testé au fil des années)
Cilium natif avec WireGuard inter-nodes, NetworkPolicies out of the box
Materia etcd sur FoundationDB : une approche originale pour gérer les problématiques etcd (scalabilité, multi tenancy) d’un cloud provider
Design CRD propre pour les NodeGroups, compatible kubectl scale
Konnectivity : isolation réseau du CP comme chez les grands cloud providers

Les points à améliorer : diagnostic du status FAILED, PSA non configurée par défaut, pas d’ingress controller inclus.

J’ai aussi une petite feature que j’ai demandé à Antoine chez Clever, l’audit logging, c’est en cours. Wait and see ;-).

La tarification du control plane me parait un poil élevée, typiquement face à des concurrents européens comme SKS ou Kapsule (mode mutualisé), mais elle s’explique par le choix architectural (VMs dédiées, rien de mutualisé). Pour une équipe déjà sur Clever Cloud, l’intégration avec le Clever Kubernetes Operator et les add-ons managés est un vrai argument.

Dans la partie 2, on creusera sûrement plus de fonctionnalités, comme le CSI (lifecycle PVC, resize, snapshots), les upgrades de cluster, l’intégration avec Clever Cloud operator (justement). Peut être aussi qu’on testera vCluster ou k3k ?

UserNamespaces dans Kubernetes : la feature géniale qui sert (presque) à rien

Tue, 28 Apr 2026 10:00:00 +0200

L’infographie qui m’a trigger

Depuis quelques jours, les infographies se suivent (et se ressemblent) sur Linkedin. Kubernetes 1.36 est sorti et une des features qui fait le plus parler, c’est la sortie en GA des UserNamespaces.

C’est un sujet que je suis depuis 2018 (talk The Route to rootless container à la kubecon EU de 2018) donc je peux dire que je suis content de voir l’aboutissement de ce long chemin. Cependant, je suis “profondément choqué” de voir la façon dont c’est présenté sur LinkedIn, visiblement par des gens qui n’ont aucune idée de comment ça fonctionne (et qui probablement, s’en fichent).

“Kubernetes just made root safer. Just add hostUsers: false to your Pod spec.”

Le visuel : un roi tout-puissant “inside the container” et un mendiant impuissant “outside on the host”. La promesse : “No Host Access. No Privilege Escalation. No Lateral Movement. No Node Takeover.”

C’est accrocheur.

Mais c’est surtout hyper grave de le présenter comme ça, parce que ça occulte des pans entiers de sécurité applicative et opérationnelle. Vendre hostUsers: false comme le remède universel au problème du “root dans les containers”, c’est une simplification dramatique qui va pousser des équipes à ignorer les vraies priorités de sécurité.

Ce que les UserNamespaces font réellement, sans bullshit

Le threat model : le container escape

Avant tout, de quoi parle-t-on exactement ? Un container escape (évasion de container), c’est quand un attaquant réussit à sortir de son container et à accéder directement au kernel ou au système de fichiers de l’hôte, en bypassant complètement les mécanismes d’isolation habituels.

Ce type de vulnérabilité est rare, mais des exemples bien réels existent :

CVE-2019-5736 (runc) : écriture dans /proc/self/exe du process hôte depuis le container
CVE-2022-0492 (cgroups v1) : escape via unshare dans certaines configurations
CVE-2024-21626 (runc, “Leaky Vessels”) : fuite de file descriptor vers le répertoire de travail de l’hôte

S’il y a une faille de ce type sur votre Node ET qu’un process est compromis ET s’il tourne en root dans le container ET qu’il n’a pas les UserNamespaces, l’attaquant obtient root sur l’hôte, c’est game over. Accès à tous les fichiers du Node, à tous les secrets montés par les autres pods, possibilité d’installer un rootkit ou d’exfiltrer les données de tous les tenants présents sur le Node.

Ca reste possible, mais ça fait beaucoup de “si”. Quoiqu’il en soit, c’est exactement ce scénario que les UserNamespaces adressent. Ils introduisent un mapping d’UID :

L’UID 0 dans le container est mappé vers un UID non-privilégié sur l’hôte (ex: 100000, propre à chaque pod)
Si un attaquant réussit à s’échapper du container via un exploit kernel, il se retrouve nobody sur le node, l’escape réussit, mais l’impact post-escape est dramatiquement réduit

C’est le scénario “Breakouts Lose Impact” de l’infographie, et là-dessus, l’infographie dit vrai. C’est le vrai apport de la feature.

Cas particulier : le multi-tenant même en non-root

Même sans container root, les UserNamespaces apportent aussi quelque chose dans un contexte vraiment multi-tenant (plusieurs clients différents sur le même cluster). Sans UserNamespaces, si deux pods de clients différents tournent tous les deux avec runAsUser: 1000, ils partagent le même UID 1000 sur le node. En cas d’escape sur l’un, l’attaquant peut accéder aux fichiers de l’autre pod qui ont le même propriétaire. Le mapping UID de UserNamespaces, en donnant un offset unique à chaque pod, isole les UID entre pods même à valeur identique dans le container.

Pour les clusters internes où vous contrôlez tous les workloads, ce scénario est théorique. Pour une plateforme SaaS multi-tenant ou un service de build public, c’est une vraie ligne de défense.

Prérequis techniques

Pour pouvoir bénéficier de cette feature, il y a quelques prérequis, mais la majorité des clusters à jour devraient pouvoir se qualifier.

Kernel Linux ≥ 5.19
Runtime compatible (containerd ≥ 1.7, CRI-O ≥ 1.25)
Support des idmapped mounts pour les volumes persistants (XFS, ext4, mais pas NFS dans tous les cas par exemple)
Kubernetes ≥ 1.33 (Beta), ≥ 1.36 (GA)

Ce que l’infographie exagère (et ce qu’elle oublie)

L’infographie a donc raison sur un point précis : UserNamespaces réduit l’impact d’un container escape réussi. C’est réel. Le problème, c’est qu’elle vend la feature comme solution universelle au “root dans les containers”, et là c’est n’importe quoi.

1. L’isolation de l’UID n’est pas une isolation des privilèges applicatifs

L’infographie promet “No Lateral Movement”. C’est faux (et archi faux).

Un container root avec hostUsers: false peut toujours lire le ServiceAccount Token monté dans /var/run/secrets/kubernetes.io/serviceaccount/token. Si ce token a des permissions RBAC étendues (ce qui arrive, on en reparlera peut être dans un autre article prochainement), l’attaquant peut appeler l’API Server, énumérer les ressources du cluster, et se déplacer latéralement, le tout sans jamais toucher le Node hôte.

Le mapping d’UID protège l’hôte. Il ne protège pas le cluster.

2. Un container root reste root dans le container

“Install Anything ✅” — c’est littéralement écrit dans l’infographie, présenté comme un avantage 😖.

Dans un container root (même avec UserNS), un attaquant qui prend la main peut :

Installer nmap, curl, nc pour scanner le réseau interne
Modifier les fichiers de l’application, les binaires, les configurations
Lire tous les fichiers montés en volume
Persister dans le container entre les redémarrages si le filesystem est writable

Les UserNamespaces ne retirent aucun de ces vecteurs d’attaque. Pouvoir ajouter des logiciels, c’est la garantie d’un mouvement latéral rapide (là encore).

3. C’est pas si facile, surtout pour le sto

Activer hostUsers: false casse le stockage existant dans la plupart des cas.

L’UID 0 du container est mappé sur l’UID 100000+ sur l’hôte (chaque container a son propre “offset”). Si un volume persistant (NFS, EBS, Ceph RBD) appartient à l’UID 1000, le container root ne peut ni lire ni écrire dessus. Le résultat : des Permission Denied contre intuitifs, potentiellement complexes à diagnostiquer car l’application n’a probablement pas été conçue, si elle est root, pour ne pas avoir accès à ses propres fichiers.

La solution technique existe (idmapped mounts), mais elle nécessite un kernel récent et un filesystem compatible. Voir la documentation officielle des idmapped mounts pour les détails.

4. Idem, mais pour le réseau

hostUsers: false est incompatible avec hostNetwork: true. C’est un détail, mais il piège les workloads réseau (agents de monitoring, CNI plugins, etc.).

Note : cela dit, avoir des containers en hostNetwork est un autre souci de sécurité, donc bon…

Comparaison sans bullshit : UserNS vs les alternatives existantes

Vecteur d’attaque	UserNS (root inside)	Non-root (UID 1000)	Distroless / Scratch
Impact post-escape si container escape réussi	✅ Nobody sur l’hôte	⚠️ UID 1000 sur l’hôte	⚠️ UID 1000 sur l’hôte
Isolation UID entre pods (multi-tenant)	✅ Offset unique par pod	❌ UID partagé sur le node	❌ UID partagé sur le node
Installation de malwares dans le container	❌ Trivial	❌ Possible	✅ Quasi impossible
Périmètre d’écriture dans le FS éphémère du container	❌ Tout le FS	❌ Répertoire de l’app	✅ Quasi impossible
Mouvement latéral via SA Token	❌ Possible	❌ Possible	⚠️ Potentiellement difficile
Complexité opérationnelle	❌ Parfois élevée	✅ Souvent quasi nulle	✅ Souvent faible
Compatibilité stockage existant	❌ Parfois problématique	✅ Standard	✅ Standard

La lecture de la table révèle la vraie nature d’UserNamespaces, il excelle sur exactement deux lignes :

l’impact post-escape
l’isolation UID en multi-tenant.

Sur tout le reste, non-root + distroless fait mieux, ou aussi bien, sans la complexité opérationnelle. Et ce sont ces “tout le reste” (périmètre d’écriture dans le FS, installation de malwares, mouvement latéral via SA Token) qui représentent la grande majorité des vecteurs d’attaque réels, bien plus fréquents qu’un container escape. On en reparlera dans la section Où investir son budget sécurité.

Les vrais cas d’usage

Ce serait malhonnête de tout rejeter. Il existe trois scénarios où les UserNamespaces ne sont pas une option “fainéante” mais une nécessité technique (et encore, ça se discute).

1. Build-as-a-Service (Buildah, rootless Podman)

Pour construire une image Docker, le moteur de build doit pouvoir faire des chown, chmod et mknod. Ces opérations nécessitent CAP_CHOWN et CAP_FOWNER. Avant les UserNamespaces, la solution était de lancer le pod en --privileged, ce qui est évidemment une porte ouverte sur l’hôte.

Avec hostUsers: false, le moteur de build a l’illusion d’être root pour manipuler ses fichiers, mais il est incapable d’impacter l’hôte. C’est le seul cas où “root inside” est une contrainte technique et non de la dette.

Note : Kaniko, longtemps la référence pour le build in-cluster, est archivé depuis juin 2025 et ne reçoit plus de mises à jour de sécurité. Buildah ou rootless Podman sont les alternatives actives.

Mon avis : ça peut être éventuellement utile pour les plateformes CI/CD mutualisées (GitLab Runners, Tekton) qui refusent les pods privilégiés. Mais si l’isolation est critique (plateforme publique, multi-tenant agressif), les microVMs (Kata Containers, Firecracker) offrent une garantie bien supérieure pour un overhead devenu raisonnable.

2. Multi-tenancy hostile (plateformes de code utilisateur)

Si votre métier est de faire tourner du code fourni par des inconnus (PaaS, éditeur de code en ligne, CI/CD publique), vous savez d’avance que l’utilisateur va essayer d’escalader ses privilèges. Dans ce contexte, l’UserNS est une barrière supplémentaire contre les 0-day kernel.

Mon avis : honnêtement, si l’environnement est vraiment hostile, l’UserNS seul n’est pas suffisant. Les microVMs (Kata Containers, Firecracker) offrent une isolation matérielle réelle et sont le choix correct pour ce cas. L’UserNS peut être un complément, pas un substitut.

3. Legacy “hard-coded” (Postfix, Dovecot, BIND)

Certains vieux démons UNIX démarrent en root pour ouvrir un port < 1024 ou lire des fichiers de config sensibles, puis “drop” leurs privilèges via setuid(). Ce mécanisme échoue dans un container non-root classique.

Les UserNamespaces permettent à ces processus de croire qu’ils peuvent faire leurs appels système de gestion d’identité, car ils sont root dans leur namespace.

Voici un exemple concret écrit par un collègue (thanks Louis 😘) :

apiVersion: v1
kind: Pod
metadata:
 name: postfix
spec:
 hostUsers: false # mapping UID : root dans le container → nobody sur l'hôte
 securityContext:
 runAsNonRoot: false # autorisé en PSS Restricted *uniquement* grâce à hostUsers: false
 fsGroup: 103 # GID postfix
 containers:
 - name: postfix
 image: postfix:latest
 securityContext:
 runAsNonRoot: false # idem, cf. https://kubernetes.io/docs/concepts/workloads/pods/user-namespaces/#integration-with-pod-security-admission-checks
 allowPrivilegeEscalation: false
 readOnlyRootFilesystem: true
 seccompProfile:
 type: RuntimeDefault
 capabilities:
 drop: ["ALL"] # d'abord, on drop tout
 add:
 - SETUID  # on ajoute SETUID mais le drop de privilèges via setuid() 
 # est fait par postfix lui-même au démarrage 
 - SETGID  # idem pour les groupes
 - CHOWN  # chown sur les queues au démarrage
 - FOWNER  # opérations sur fichiers sans être propriétaire
 - FSETID  # conserver le setuid bit après écriture
 - DAC_OVERRIDE # OBLIGATOIRE : root dans UserNS n'est pas "vrai" root,
 # les vérifications DAC ne sont pas contournées automatiquement

Ce manifest illustre plusieurs choses importantes.

D’abord, c’est très pénible de rendre une application legacy secure avec les UserNS, et il faut faire des compromis, notamment sur les capabilities (on est loin de la feature magique qui sécurise les apps root).

Ensuite, on remarque des trucs rigolos. Normalement, la policy Restricted (Pod Security Standard) interdit runAsNonRoot: false. Kubernetes fait une exception quand hostUsers: false est présent. C’est documenté ici. Sans UserNamespaces, ce pod serait rejeté par l’admission controller.

De plus, on doit ajouter la capacité DAC_OVERRIDE, ce qui est contre-intuitif. root dans un UserNS n’est pas un vrai root du point de vue du kernel pour les vérifications DAC (Discretionary Access Control). Quand Postfix essaie de faire set-permissions pour chown ses queues, le kernel vérifie quand même les permissions ; et les refuse si DAC_OVERRIDE n’est pas là. C’est exactement le genre de surprise opérationnelle invisible jusqu’au premier déploiement en production.

On notera malgré tout qu’on a pu garder readOnlyRootFilesystem: true et allowPrivilegeEscalation: false ; le legacy ne justifie pas de tout sacrifier.

Mon avis : c’est le seul cas d’usage où l’UserNS est vraiment acceptable. Pas de code tiers non maîtrisé, pas de plateforme hostile, juste du legacy bien identifié avec un plan de migration ultérieur. Les deux autres cas sont “acceptables sous conditions”, le legacy reste le plus propre des trois.

Quelques contre-arguments

Je vous vois arriver avec quelques contre arguments, donc pour gagner du temps à tout le monde, je vais faire les questions et les réponses :

“C’est de la défense en profondeur.” “Vrai, mais”… La défense en profondeur suppose qu’on a déjà posé les couches de base. Si vous n’avez pas encore migré vos images vers un user non-root, mettre de l’énergie sur l’UserNS est un non-sens. Et une fois en non-root, le gain marginal de l’UserNS est négligeable face à la complexité qu’il introduit.

“On ne contrôle pas les images tierces.” Argument un peu faible, à mon avis : si vous avez une image blackbox de votre éditeur propriétaire, qui est codée pour tourner en root, il y a de fortes chances :

soit qu’elle en ait réellement besoin pour fonctionner (typiquement, le cas pour certains outils de sécurité propriétaires)
soit qu’elle gère mal le mapping d’UID (cf. le problème de stockage). L’UserNS n’est pas une baguette magique qui rend n’importe quelle image tierce compatible et sécurisée.

“C’est un garde-fou contre les erreurs humaines.” Il est aussi facile d’oublier hostUsers: false que d’oublier runAsNonRoot: true. La vraie solution centralisée, ce sont les Pod Security Standards ou un Admission Controller (Kyverno, OPA) qui rejettent purement et simplement les pods root. C’est plus simple, plus fiable, et ça ne casse pas le stockage.

“On en a besoin pour la compliance SOC2/PCI-DSS/…” Si votre compliance exige une isolation stricte entre tenants, l’UserNS sera probablement jugé insuffisant par vos auditeurs. Les VMs ou microVMs restent le standard. Utiliser l’UserNS pour la compliance, c’est choisir l’outil le plus complexe à maintenir pour un résultat discutable.

Où investir son budget sécurité ?

Si on met de côté le marketing, voici où l’effort paye vraiment, du plus impactant au plus niche :

Priorité 1 — Images non-root + nobody (UID 65534) Passer les images en non-root, idéalement vers l’utilisateur nobody (le moins privilégié du système). Si une application est compromise sous nobody, l’attaquant ne peut pratiquement rien faire, même sur le filesystem du container. À combiner avec readOnlyRootFilesystem: true et capabilities: drop: ["ALL"].

spec:
 securityContext:
 runAsNonRoot: true
 runAsUser: 65534 # nobody
 seccompProfile:
 type: RuntimeDefault
 containers:
 - name: app
 image: my-app:distroless
 securityContext:
 allowPrivilegeEscalation: false
 capabilities:
 drop: ["ALL"]
 readOnlyRootFilesystem: true

Priorité 2 — Pod Security Standards (PSS) en mode Baseline ou Restricted Bloquer le root et les privilèges sans rien casser au niveau infra. Ça nécessite d’avoir déjà fait le point n°1, mais c’est gratuit, standard, et ça s’applique à tout le cluster via un label de namespace (et ça peut s’overrider par namespace si nécessaire). Plus de risque d’oubli possible. C’est déjà configuré par défaut sur plusieurs types de Kubernetes (je pense à Talos, mais ce n’est pas le seul).

Priorité 3 — MicroVMs (Kata Containers, Firecracker) Pour les workloads vraiment non-fiables. Isolation matérielle réelle, overhead devenu raisonnable sur les générations récentes.

Priorité 4 — UserNamespaces When all else fail. Uniquement pour les cas légitimes identifiés ci-dessus (build, legacy, multi-tenancy hostile). C’est vraiment littéralement la dernière chose à faire.

Conclusion

Les UserNamespaces dans Kubernetes 1.36 sont l’aboutissement d’un chantier qui aura pris “officiellement” cinq ans (KEP-127 date de 2021) et dont on parle quasiment depuis la genèse de Kubernetes. Pour les plateformes de build mutualisées et les SaaS multi-tenants qui font tourner du code utilisateur, c’est une brique potentiellement intéressante (notamment pour éviter qu’une app d’un client lise les apps d’un autre en cas de container escape sans élévation de privilège).

Pour le reste (c’est-à-dire 99% des clusters de production) ce n’est pas là que commence la sécurité container — et c’est précisément le problème avec ce genre d’infographie.

Les infographies LinkedIn qui vendent une sécurité sans effort sont dangereuses : “gardez votre image root de 800 Mo pleine d’outils, ajoutez juste hostUsers: false, et vous êtes protégés”. C’est exactement l’inverse de la bonne démarche. La vraie sécurité container se construit dans le Dockerfile, pas dans le PodSpec.

Si vous activez les UserNamespaces pour sécuriser une application dont vous possédez le code source, vous avez probablement raté une étape dans votre cycle de développement sécurisé.

Références

KEP-127 : Support for User Namespaces
Kubernetes docs — User Namespaces
Pod Security Standards
CVE-2019-5736 — runc : écriture dans /proc/self/exe du process hôte depuis le container
CVE-2022-0492 — cgroups v1 : escape via unshare, UserNS aide mais runAsNonRoot aussi
CVE-2024-21626 — runc “Leaky Vessels” : fuite de file descriptor vers le répertoire de travail de l’hôte
Distroless containers — GoogleContainerTools

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

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.

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 ! 🙏

Installation d'un Cluster HAT avec Raspberry Pi 5 et Pi Zero

Tue, 27 Jan 2026 18:00:00 +0200

Introduction, c’est quoi un Cluster Hat ?

Qu’est ce que tu nous as encore trouvé ???

Vous m’avez vu jouer avec des Raspberry Pi et y installer Kubernetes dessus, ou juste simplement Alpine Linux.

Alors de quoi diantre (oui, “diantre” carrément, n’ayons pas peur des mots) s’agit-il aujourd’hui ???

En cherchant dans les tréfonds des Internets s’il était possible d’installer un cluster Kubernetes sur des Raspberry Pi zero, je suis tombé sur 3 personnes différentes qui avaient échoué dans cette tâche :

Setting up a Kubernetes cluster using Raspberry Pi Zero 2 W’s et l’article reddit associé avec une photo (importante pour la suite de l’article)
github.com/abelperezok/kubernetes-raspberry-pi-cluster-hat
A tiny cluster based on 4x Raspberry Pi Zero 2 W

Dans les 3 cas, les gens ont tous essayé d’installer un cluster de RPi zero, plantés sur une sorte de carte additionnelle dont j’ignorais l’existence : le Cluster HAT

Site officiel du Cluster HAT clusterhat.com

The Cluster HAT (Hardware Attached on Top) which interfaces a (Controller) Raspberry Pi A+/B+/2/3 with 4 Raspberry Pi Zeros configured to use USB Gadget mode is an ideal tool for teaching, testing or simulating small scale clusters.

The Cluster HAT can be used with any mix of Pi Zero 1.2, Pi Zero 1.3 and Pi Zero W.

USB Gadget Mode: Ethernet and Serial Console.

Onboard 4 port USB 2.0 hub.

Raspberry Pi Zeros powered via Controller Pi GPIO (USB optional).

Individual Raspberry Pi Zero power controlled via Controller Pi GPIO (I2C).

Connector for Controller Serial Console (FTDI Basic).

Controller Pi can be rebooted without interrupting power to Pi Zeros, network recovers on boot.

Problème(s)

Bon, forcément, c’est absurde, c’est donc un énième projet pour moi !!

Premier problème : le Cluster HAT ne peut en théorie pas supporter les Pi Zero 2W. C’est en tout cas ce qu’on lit partout (sur les sites des revendeurs, et ce qu’on peut déduire de l’introduction que j’ai mise juste au dessus). Et c’est super dommage parce que c’est le modèle que j’ai (j’en ai deux) et j’ai un peu la flemme d’en acheter 4 en version 1.3 juste pour être sûr que ça fonctionne.

Heureusement :

Plusieurs commentaires trouvés sur le net indiquent qu’en réalité, ça fonctionne si l’alim (27w pour l’officielle) du Pi 5 était suffisamment puissante ; de plus, la FAQ dit qu’en fait, c’est bon
Quentin m’en a gentiment passé 2 Pi Zero 1.3, ce qui complète ma collection. J’en aurais 2 de chaque, ça devrait le faire niveau alim.

Deuxième problème, en trouver un (Cluster HAT) ! La dernière version de ce produit a été produite il y a plusieurs années déjà. Le site officiel ne livre pas en France, le produit n’existe plus sur Kubii.fr. J’en ai trouvé encore quelques uns sur The Pi Hut (au Royaume-Uni et il n’y en a plus aujourd’hui), pour une quarantaine d’euros, livraison incluse.

Dernier point, il a fallu trouver un Pi 5 à un prix raisonnable et ça fait mal d’avoir de lâcher 70€ pour un Pi 5 d’occasion avec seulement 4 Go.

On en est donc, avec les accessoires (cartes SDs) et les différentes cartes à un side project à peu près 200€.

Ça fait un peu cher pour un projet absurde, mais je finance ça avec un article (sur un autre sujet) qui va sortir dans un magazine dans quelques semaines. Ceux qui savent, savent ;-P.

Installation matérielle

Probablement la partie la plus rigolote quand on aime (comme moi) bidouiller des composants informatiques et des cartes électroniques.

Mettez les petites vis pour surélever le “Hat”
Insérez le Cluster HAT sur les ports GPIO du Raspberry Pi 5
Insérez les 4 Pi Zero dans les ports USB du HAT

Alimentation : Utilisez impérativement une alimentation suffisamment puissante, idéalement l’alimentation officielle du Pi 5 (27W USB-C). Le Cluster HAT tire son énergie du Pi 5 pour alimenter les 4 Zéros.

Cartes SD : Il vous faut 5 cartes MicroSD au total (1 pour le Pi 5, 4 pour les Zéros). Le site parle de booter les pi zero sans carte MicroSDs (fonctionnalité expérimentale). Je regarderai peut être ?

Bon OK, c’était trivial. Mais ça prouve que le produit est bien conçu !

Boîtier 3D

Comme j’ai une imprimante 3D, j’ai modifié un modèle existant pour les RPi avec un “M.2 hat” (une autre carte additionnelle, celle-ci pour connecter un SSD M.2) en faisant des gros TROUS partout pour que les pi zero puissent rentrer.

Raspberry Pi 5 AI/M.2 Hat+ Snap Case

Je ne peux malheureusement pas partager le profil modifié car c’est contraire à la licence du fichier 3D (Standard Digital File License, qui interdit les modifications).

Note : j’ai passé plus de temps à chercher des modèles, les modifier et tester des prototypes, qu’à jouer avec le cluster hat lui-même.

Préparation de l’installation

La première chose à faire pour commencer à profiter de ce magnifique cluster de Raspberry est de commencer par installer et configurer notre Pi 5.

Même s’il est théoriquement possible de tout faire soi-même, le fabricant du cluster hat conseille de partir sur les images préconfigurées disponibles sur son site 8086.net. La dernière version disponible est téléchargeable ici :

dist1.8086.net/clusterctrl/bookworm/2025-11-24/

En parcourant la liste, on note qu’il existe :

6 versions pour le RPi “maître” (Bookworm lite, normal et full, avec un mode CNAT ou CBRIDGE pour chaque)
des images préconfigurées Rpi OS lite pour les Pi Zero (appelées Px, x étant la position sur le cluster hat), là aussi avec des variantes CBRIDGE / CNAT, armhf (32 bits) et arm64

Par flemme, j’ai juste branché le Pi 5 sur le courant, je n’ai pas de câble Ethernet à portée de main. Dans ce cas, si comme moi vous connectez votre Pi en WiFi, il faut partir sur le mode CNAT (NATé). Au contraire, le mode CBRIDGE (bridgé, qui nécessite donc le port Ethernet) est que vous verrez sur votre LAN les 5 machines.

Deuxième info (rappel), dans mon cas, j’ai un mix de machines 32 et 64 bits, il faut donc que je fasse attention à bien sélectionner le bon OS pour les bonnes machines.

Installation du Raspberry Pi 5 (notre contrôleur)

Pour le Raspberry Pi 5, dans mon cas le fichier est donc 2025-11-24-2-bookworm-ClusterCTRL-arm64-lite-CNAT.img.xz

wget https://dist1.8086.net/clusterctrl/bookworm/2025-11-24/2025-11-24-2-bookworm-ClusterCTRL-arm64-lite-CNAT.img.xz

Le problème du mode headless

Même si c’est possible, je ne veux pas brancher le Pi à un écran (faut sortir un clavier et un écran… fatiguant) alors je vais tout faire de manière à être en headless. Et manque de bol, les dernières versions du Raspberry Pi Imager (2.0.0) ne permettent pas (plus ?) de faire de customisation des OS tiers.

En théorie, il va donc falloir, une fois l’image flashée sur la microSD, configurer manuellement :

le WiFi
un utilisateur de base
activer SSH

J’ai essayé, ça a échoué, malgré un fichier wpa_supplicant.conf, un userconf.txt correctement formatté et un fichier ssh vide.

La solution : Raspberry Pi Imager 1.9.6

Après avoir pas mal ragé, je suis tout simplement retourné sur la version précédente de l’imager (1.9.6) qui fonctionne très bien avec l’image fournie par 8086.net.

Note : cependant, pour installer les OS RPi OS récents, j’ai eu pas mal d’échecs. Donc à utiliser avec parcimonie.

Installation des 4 Raspberry Pi Zero (Les Nœuds)

Ici, c’est un poil plus simple côté réseau, car en mode CNAT, les Pi Zero vont communiquer via le câble USB du Cluster HAT. MAIS il faut faire attention aux problématiques d’architecture 32 vs 64 bits, dans mon cas un peu hybride :

P1 (un Pi Zero 2) : ...arm64-lite-CNAT-p1.img.xz
P2 (un Pi Zero 1.3) : ...armhf-lite-CNAT-p2.img.xz
P3 (un Pi Zero 1.3) : ...armhf-lite-CNAT-p3.img.xz
P4 (un Pi Zero 2) : ...arm64-lite-CNAT-p4.img.xz

Niveau customization, on laisse donc SSH et le user/password, mais pas la peine de mettre le WiFi. On pourra d’ailleurs modifier les paramètres de boot pour supprimer côté kernel les modules Bluetooth et WiFi histoire de gagner quelques Mo de RAM.

Démarrage

Une fois que tout est prêt, que le RPi 5 fonctionne, on peut se logger en SSH et exécuter la commande :

sudo clusterctrl on

À partir de là, les LEDs du cluster hat devraient se mettre à s’exciter, et les RPi Zero devraient s’allumer progressivement. Ça fait un peu guirlande de Noël mais j’aime bien.

Si on veut en allumer que certaines, c’est possible avec les commandes :

sudo clusterctrl on p1 # pour n'allumer que p1
sudo clusterctrl off p2 p3 p4 # pour éteindre p2, p3 et p4

Configuration réseau

Dans le mode NAT, les adresses IP des Pi Zero sont affectées de la manière suivante :

côté RPi 5 (le contrôleur) on a un bridge br0 avec pour adresse 172.19.181.254/24
côté Pi Zero, 172.19.181.x avec x allant de 1 à 4

C’est aussi simple que ça. Depuis le contrôleur, on peut donc tenter de se logger en SSH :

p1 a beau être NATé, le NAT fonctionne puisqu’on a bien accès à Internet :

zwindler@p1:~ $ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=12.5 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=17.1 ms

Conclusion

J’ai perdu pas mal de temps à flasher les images jusqu’à trouver le bon moyen d’avoir à la fois la ROM custom du cluster HAT et les customizations OS pour tourner en headless.

Mais une fois que j’avais ça, c’était relativement trivial de faire fonctionner ce petit cluster.

Maintenant, il reste à trouver ce que je vais faire tourner dessus ;) j’ouvre les paris !

Sources

101 façons de déployer Kubernetes (v2) : maintenant sur Github avec plus de méthodes, plus de détails, plus de tout

Sun, 04 Jan 2026 10:00:00 +0200

Une nouvelle version, une nouvelle maison

Il y a quelques mois, je vous présentais mon tableau recensant 93 façons différentes de déployer Kubernetes, sur Google Sheets.

À la suite de la remarque de Ludovic Piot qui aurait aimé contribuer un ou deux outils manquants, j’ai pris un peu (beaucoup, en vrai) de temps pendant ces vacances pour déménager tout ça sur Github : 101-ways-to-deploy-kubernetes

Pourquoi sur un dépôt git plutôt que sur un Google Sheet comme au début ? Parce que ça me permet facilement de rendre ce projet vraiment collaboratif, notamment via des PRs (et surtout leur validation ou non).

Google Sheets, c’était bien pour commencer, quand c’était un outil perso pour m’aider à écrire mon livre, mais pour la collaboration, c’était pas viable.

Quoi de neuf dans cette v2 ?

Contributions facilitées

Le projet dispose maintenant d’un CONTRIBUTING.md qui explique comment participer.

Vous connaissez une solution qui n’est pas listée ? Vous avez repéré une erreur ? Un lien cassé ? Il vous suffit de faire une Pull Request !

De nombreuses nouvelles méthodes (j’ai pas compté mais probablement une douzaine)

Le projet est passé de 93 à plus de 100 méthodes ! J’ai continué mes explorations et ajouté une douzaine de nouvelles solutions, dont certaines que vous m’aviez suggérées.

Informations sur les licences

J’ai enrichi le tableau avec des détails sur les licences de chaque projet. C’est particulièrement important pour identifier d’un coup d’oeil si un produit est réellement open source ou si c’est une solution à licence propriétaire ou commerciale.

J’ai eu le débat avec Ludovic justement, qui voulait comprendre pourquoi je n’avais pas listé “MKE (Mirantis Kubernetes Engine)”. Je lui avais répondu à l’époque que c’était parce que je ne pouvais pas avoir accès à une version d’essai en tant que “random des Internets” sans passer par un commercial, mais l’argument n’était pas hyper solide.

Pour trouver une règle “unique” à indiquer dans le CONTRIBUTING.md, j’ai donc réintégré une partie des solutions que j’avais “censurées”.

While the heart of the cloud native ecosystem is open source, both open source and closed source (proprietary) tools are accepted in this list. What matters is whether the tool helps deploy Kubernetes clusters, not its licensing model.

Nombreuses références externes

J’ai fait un important travail sur la partie “références externes”. L’idée du répo, au delà de juste fournir une liste à la prévert, est de référencer des articles de tiers indiquant comment mettre en place ces solutions et bénéficier des retours d’expérience de la communauté.

Dans l’idée de rendre le projet plus international (ça sera tout aussi utile aux anglophones qu’aux petits frenchies de ma communauté), j’ai récupéré en priorité des liens en anglais, pour le plus de solutions possibles de cette liste. Il en reste encore qui n’en ont pas, mais ça progresse.

Note importante : au-delà de la documentation officielle (qui existe très souvent pour la grande majorité des projets), j’ai en priorité voulu recenser :

Des tutoriels de qualité de la communauté
Des articles de blog détaillés
Des retours d’expérience concrets

Un projet toujours sous CC BY-SA 4.0

Le contenu reste sous licence CC BY-SA 4.0 (Attribution - Share Alike).

Cela signifie que vous êtes libre de :

Partager : copier et redistribuer le contenu
Adapter : remixer, transformer et créer à partir de ce matériel

Sous les conditions suivantes :

Attribution : vous devez créditer le projet
Partage dans les mêmes conditions : si vous adaptez le contenu, vous devez le distribuer sous la même licence

Comment contribuer ?

C’est simple :

Forkez le dépôt 101-ways-to-deploy-kubernetes
Ajoutez ou modifiez le contenu (en suivant le format du tableau)
Soumettez une Pull Request

Lisez le CONTRIBUTING.md pour plus de détails sur le processus et les bonnes pratiques.

Toutes les contributions sont les bienvenues : nouvelles entrées, corrections, enrichissements, suggestions…

Et la suite ?

Le projet va continuer à évoluer au fil des découvertes et de vos contributions.

Je continue aussi à explorer de nouvelles solutions et à enrichir les informations existantes. Et qui sait, peut-être qu’on dépassera les 150 méthodes d’ici la fin de l’année ? 😄

C’est le moment où je fais mon influenceur et que je vous demande de ne pas hésiter à :

Star le projet sur Github si vous le trouvez utile ⭐⭐⭐
Contribuer en ajoutant vos découvertes
Partager autour de vous si vous le trouvez utile

Rendez-vous sur github.com/zwindler/101-ways-to-deploy-kubernetes !

Transformer Proxmox VE en node Kubernetes avec LXC et lxcri

Mon, 17 Nov 2025 18:00:00 +0200

Il ne savait pas que c’était complètement stupide, alors il l’a fait

Quel mensonge… Bien sûr, je sais très bien que c’est débile. Raison pour laquelle cette idée est donc irrésistible.

Si vous suivez le blog, vous savez que j’utilise beaucoup Proxmox VE (les articles qui attirent le plus sur le blog sont d’ailleurs des articles sur cette technologie de virtualisation).

Proxmox VE, c’est très cool ; on peut faire des VMs (QEMU) avec, mais aussi, si on n’a pas de VT-x ou qu’on veut des “lightweight VMs” (terme dont on a abusé à outrance), on peut installer des OS complets dans des containers avec LXC.

Mais au delà de ces deux solutions, les devs du projet Proxmox VE sont assez rigides (et pas que là dessus). C’est d’ailleurs pour ça que j’ai posté quelques “hacks” pour contourner les limitations de Proxmox, notamment cet article où j’explique comment lancer des containers Docker (via LXC) dans Proxmox VE (normalement pas possible).

Et si on allait encore plus loin dans le hack idiot ?

Et si, non seulement on exécutait des containers OCI dans Proxmox VE, mais qu’EN PLUS, on transformait nos hôtes Proxmox VE en ✨️ Nodes Kubernetes ✨️ ???

On s’y prend comment ?

Le but n’est évidemment pas d’installer Kubernetes à côté de Proxmox VE, mais réutiliser le plus de choses possibles. Typiquement, je vais réutiliser la techno de “virtu”.

Proxmox VE supportant 2 technos de virtualisation différentes (qemu et LXC), il faut choisir. Et comme j’aime bien LXC et que j’ai déjà expérimenté sur le hack Docker => LXC sur Proxmox VE, la question était vite répondue.

Toute la difficulté de l’exercice est de trouver comment rendre LXC “CRI-compatible”. Et on a de la chance, Linux Containers, la fondation qui chapeaute LXC et Incus (ex LXD, “refermé” par Canonical), a écrit il y a quelques années un CRI pour LXC appelé lxcri. Et bien sûr, comme c’est un projet à l’utilité discutable, le truc n’est plus maintenu depuis 2021.

J’avais d’ailleurs essayé de l’utiliser, passé pas mal de temps dessus en février 2024 (j’ai essuyé bug sur bug, suis passé par des forks, …) pour échouer lamentablement sur un problème de compatibilité avec ma version de LXC (5+ sous Proxmox 8, 6 en Proxmox 9), entre autres bugs.

lxcri is a wrapper around LXC which can be used as a drop-in container runtime replacement for use by CRI-O.

On va donc quand même avoir besoin de 3 trucs en plus sur notre serveur Proxmox pour que mon idée débile fonctionne :

lxcri comme container runtime de base niveau
cri-o comme container runtime de haut niveau
kubelet pour piloter le runtime et communiquer avec le control plane

C’est parti

OK. lxcri s’appuie donc sur cri-o, le container runtime de Red Hat. On commence donc par installer cri-o :

https://github.com/cri-o/cri-o/blob/main/install.md

Note : mon serveur Proxmox VE 8 de l’époque utilisait Debian 12 comme OS de base. On devrait donc se baser là-dessus pour la variable $OS (comme l’indique la doc). Cependant, à l’heure où j’ai testé la première fois, les dépôts de CRI-O étaient en cours de migration, avec une documentation pas à jour et des releases manquantes. Le répo download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o n’avait pas le PATH Debian_12, ni la version 1.29 de Kubernetes… J’avais BIEN ragé.

On ne devrait plus avoir de soucis maintenant :

export KUBERNETES_VERSION=v1.32
export CRIO_VERSION=v1.32

# créer un répertoire pour les keyrings (il n'existe pas toujours sur une install fraiche)
sudo mkdir -p /usr/share/keyrings

# répo de kubernetes
curl -fsSL https://pkgs.k8s.io/core:/stable:/$KUBERNETES_VERSION/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/$KUBERNETES_VERSION/deb/ /" |
 sudo tee /etc/apt/sources.list.d/kubernetes.list

# répo de crio
curl -fsSL https://download.opensuse.org/repositories/isv:/cri-o:/stable:/$CRIO_VERSION/deb/Release.key |
 sudo gpg --dearmor -o /etc/apt/keyrings/cri-o-apt-keyring.gpg

echo "deb [signed-by=/etc/apt/keyrings/cri-o-apt-keyring.gpg] https://download.opensuse.org/repositories/isv:/cri-o:/stable:/$CRIO_VERSION/deb/ /" |
 sudo tee /etc/apt/sources.list.d/cri-o.list

sudo apt update
sudo apt install cri-o

A partir de là, on a cri-o. On pourrait le configurer mais si on fait ça, il utilisera runc et on n’utiliserait pas LXC en tant que runtime.

Ce n’est pas le but de ce hack !

C’est donc à ce moment là qu’on rebascule sur la documentation de lxcri :

github.com/lxc/lxcri

Ya pas de release

Et oui… il faut préalablement builder le binaire lxcri et le déposer dans le /usr/local de notre serveur Proxmox VE. Il n’y a pas de binaire précompilé dans le projet, c’est une issue ouverte juste avant qu’il ne soit abandonné 😬😬.

Et pour que ce soit encore plus fun, le processus de build passe par un Dockerfile, ce qui est rigolo puisqu’on n’a pas Docker sur notre node Proxmox…

J’ai donc essayé de builder lxcri depuis une machine avec Docker, en suivant la commande indiquée sur le GitHub. Patatra. (Déjà, il manque un “.” en fin de commande docker build dans la doc) ça fail misérablement à la compilation…

Note : je n’ai plus l’erreur en question, probablement un problème de dépendances. C’est relou parce qu’on va devoir faire plein de choses à la main… Mais ne vous embêtez pas à git clone, on va partir sur un fork (d’un fork).

En allant jeter un œil au Dockerfile, on se rend vite compte qu’on ne fait que lancer un script (install.sh)…

Quand on appelle Docker avec le buildarg installcmd=install_runtime, on lance la fonction install_runtime, qui appelle install_runtime_noclean, qui lance add_lxc puis add_lxcri.

Je veux juste compiler lxc (pour les bindings) et lxcri. Je vais donc le faire à la main. Pour ça, il faut golang 1.16 (ça date…).

Il y a pas mal de code pété un peu partout et plusieurs issues ouvertes dans lesquelles les mainteneurs conseillent de partir sur un fork :

https://github.com/drachenfels-de/lxcri

J’ai passé pas mal de temps à le débugger, et au final j’ai fait mon propre fork (https://github.com/zwindler/lxcri), qui nécessite golang 1.22+ et qui ajoute un gros paquet de fixes.

Prérequis pour builder lxcri

On va installer un paquet de trucs :

sudo apt update
sudo apt install curl git meson pkg-config cmake libdbus-1-dev docbook2x

On installe Golang si on ne l’a pas (peu de chance que vous ayez Golang sur un node Proxmox VE) :

wget https://go.dev/dl/go1.25.4.linux-amd64.tar.gz
sudo rm -rf /usr/local/go && sudo tar -C /usr/local -xzf go1.25.4.linux-amd64.tar.gz
export PATH=$PATH:/usr/local/go/bin
go version
 go version go1.25.4 linux/amd64

Je vais aussi devoir récupérer et compiler lxc. Pendant un moment, j’étais bloqué sur la version 4.0.12 (très précisément) car la 4.0.6 qu’on trouve sur Debian 11 ne fonctionne pas avec le code de lxcri (j’ai mangé plein de bugs).

Mais la bonne nouvelle, c’est que comme je suis un try-harder de l’espace, à force de fixes sur mon fork, celui-ci fonctionne avec la dernière version de lxc (6.x), ce qui tombe bien parce que c’est la version sur mon Proxmox VE 9 à jour.

git clone https://github.com/lxc/lxc
cd lxc

meson setup -Dprefix=/usr -Dsystemd-unitdir=PATH build
 Build targets in project: 30

 lxc 6.0.0

 User defined options
 prefix : /usr
 systemd-unitdir: PATH

 Found ninja-1.12.1 at /usr/bin/ninja

meson compile -C build
 INFO: autodetecting backend as ninja
 INFO: calculating backend command to run: /usr/bin/ninja -C /root/lxc/build
 ninja: Entering directory `/root/lxc/build'
 [544/544] Linking target src/lxc/tools/lxc-monitor

Ça a buildé plein de trucs, c’est cool. Mais les fichiers qui m’intéressent sont ici :

find . -name "lxc.pc"
./build/meson-private/lxc.pc

ls build/*lxc*
build/liblxc.so build/liblxc.so.1 build/liblxc.so.1.8.0 build/lxc.spec

build/liblxc.so.1.8.0.p:
liblxc.so.1.8.0.symbols

Je mets ça aux bons endroits dans mon Proxmox VE avec un :

sudo make install
sudo ldconfig

Builder comme jamais

Ok, c’est parti pour jouer avec mon fork :

git clone https://github.com/zwindler/lxcri.git lxcri.zwindler
cd lxcri.zwindler

make build
 go build -ldflags '-X main.version=8805687-dirty -X github.com/lxc/lxcri.defaultLibexecDir=/usr/local/libexec/lxcri' -o lxcri ./cmd/lxcri
 cc -Werror -Wpedantic -o lxcri-start cmd/lxcri-start/lxcri-start.c $(pkg-config --libs --cflags lxc)
 CGO_ENABLED=0 go build -o lxcri-init ./cmd/lxcri-init
 # this is paranoia - but ensure it is statically compiled
 ! ldd lxcri-init 2>/dev/null
 go build -o lxcri-hook ./cmd/lxcri-hook
 go build -o lxcri-hook-builtin ./cmd/lxcri-hook-builtin

ls -alrt
 total 15288
 [...]
 -rwxr-xr-x 1 debian debian 7108288 Nov 16 20:06 lxcri
 -rwxr-xr-x 1 debian debian 17520 Nov 16 20:06 lxcri-start
 -rwxr-xr-x 1 debian debian 2942584 Nov 16 20:06 lxcri-init
 -rwxr-xr-x 1 debian debian 2834743 Nov 16 20:06 lxcri-hook
 -rwxr-xr-x 1 debian debian 2519097 Nov 16 20:06 lxcri-hook-builtin

Si on était sur une machine de dev, on pourrait envoyer les binaires sur le serveur Proxmox VE (lxcri dans /usr/local/bin, le reste dans /usr/local/libexec/lxcri).

Dans mon cas, je suis directement sur la machine qui build et qui run, je fais donc :

$ sudo make install
 mkdir -p /usr/local/bin
 cp -v lxcri /usr/local/bin
 'lxcri' -> '/usr/local/bin/lxcri'
 mkdir -p /usr/local/libexec/lxcri
 cp -v lxcri-start lxcri-init lxcri-hook lxcri-hook-builtin /usr/local/libexec/lxcri
 'lxcri-start' -> '/usr/local/libexec/lxcri/lxcri-start'
 'lxcri-init' -> '/usr/local/libexec/lxcri/lxcri-init'
 'lxcri-hook' -> '/usr/local/libexec/lxcri/lxcri-hook'
 'lxcri-hook-builtin' -> '/usr/local/libexec/lxcri/lxcri-hook-builtin'

et on peut continuer :

$ /usr/local/bin/lxcri help
NAME:
 lxcri - lxcri is a OCI compliant runtime wrapper for lxc

USAGE:
 lxcri [global options] command [command options] [arguments...]

VERSION:
 8805687
[...]

On reprend crio

Ok, on a buildé lxcri et on a toutes les dépendances pour l’utiliser. On peut donc repartir sur la doc officielle de lxcri “setup.md” dans l’idée de configurer CRI-O, pour qu’il n’utilise pas runc, uniquement lxcri.

sudo tee /etc/crio/crio.conf.d/10-crio.conf > /dev/null <<'EOF'
[crio.image]
signature_policy = "/etc/crio/policy.json"

[crio.runtime]
default_runtime = "lxcri"

[crio.runtime.runtimes.lxcri]
runtime_path = "/usr/local/bin/lxcri"
runtime_type = "oci"
runtime_root = "/var/lib/lxc" #proxmox lxc folder
inherit_default_runtime = false
runtime_config_path = ""
container_min_memory = ""
monitor_path = "/usr/libexec/crio/conmon"
monitor_cgroup = "system.slice"
monitor_exec_cgroup = ""
privileged_without_host_devices = false
EOF

A noter, la doc d’installation setup.md nous dit générer une conf propre avec le binaire crio et la commande config, mais ça ne marche pas vraiment et on se retrouve à lancer runc ou crun sans le vouloir. J’écrase tout, c’est plus simple.

Et maintenant, on peut lancer crio :

sudo systemctl enable crio && sudo systemctl start crio

A partir de là, on a un serveur disposant d’un CRI a priori fonctionnel.

systemctl status crio
● crio.service - Container Runtime Interface for OCI (CRI-O)
 Loaded: loaded (/lib/systemd/system/crio.service; enabled; vendor preset: enabled)
 Active: active (running) since Mon 2025-11-17 12:02:37 UTC; 12s ago

journalctl -u crio
Nov 17 20:29:43 instance-2025-11-16-15-31-55 systemd[1]: Starting Container Runtime Interface for OCI (CRI-O)...
[...]
Nov 17 20:29:43 instance-2025-11-16-15-31-55 crio[11906]: time="2025-11-17T20:29:43.61758425Z" level=info msg="Using runtime handler lxcri version 8805687"

Yeeees :D

On peut donc installer kubelet, puis l’ajouter à un cluster Kubernetes existant

Fast forward

J’avais la flemme de monter un cluster propre avec kubeadm ou autre, et d’enrôler ensuite un node à la main avec le token+sha. J’aurais aussi pu rejouer avec mon PoC rigolo des workers “linux” de Clever Cloud pour créer un control plane chez Clever, puis enrôler à la main avec le node bootstrap token (j’ai fait les choses plutôt bien dans ce PoC).

J’ai donc rejoué à l’arrache avec mon projet demystifions-kubernetes, qui permet de monter un cluster mono node à la main en lançant juste des binaires.

Une fois le control plane bootstrapé (etcd, api-server, controller-manager, scheduler), on s’arrête AVANT la partie containerd (on a déjà configuré CRI-O) et on lance le kubelet à la main :

sudo bin/kubelet --kubeconfig admin.conf --container-runtime-endpoint --container-runtime-endpoint=unix:///var/run/crio/crio.sock --fail-swap-on=false --cgroup-driver="systemd"
[...]
I1117 13:41:58.741561 88434 kubelet_node_status.go:78] "Successfully registered node" node="instance-2025-11-16-15-31-55"

On progresse ! Essayons de voir l’état de santé du cluster et de déployer un pod :

$ export KUBECONFIG=admin.conf
$ kubectl get nodes
 NAME STATUS ROLES AGE VERSION
 instance-2025-11-16-15-31-55 Ready <none> 13m v1.34.2

$ kubectl create deployment web --image=zwindler/vhelloworld
 deployment.apps/web created


$ kubectl get pods
 NAME READY STATUS RESTARTS AGE
 web-6c8cc48c68-cdbtj 1/1 Running 0 4m17s

$ kubectl logs web-6c8cc48c68-cdbtj
 [Vweb] Running app on http://localhost:8081/
 [Vweb] We have 3 workers

Great success!

Conclusion

A partir de là, CRI-O partage le moteur LXC de Proxmox VE de manière fonctionnelle.

Pour s’en convaincre, on peut lancer la commande lxc-ls, qui nous affichera un mix de “vrais” containers LXC (créés avec Proxmox, les 151 et 200) et de containers de pods (les STOPPED sont les init containers de cilium) :

$ lxc-ls -f
NAME STATE AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED
151 STOPPED 0 - - - true
200 STOPPED 0 - - - true
3045d1f3abcc069b1009acc869a27b09cf9531d0701a3f9d5a760213d57c7b20 STOPPED 0 - - - false
78057100e5d0613944c2be859dfd09f790eeba88bceebea0e04970841c9bd950 RUNNING 0 - 10.0.0.90 - false
8e5506beea9a50214c46f31fa7fa6d04397963cb912aa397261359865d40a0cd RUNNING 0 - 10.0.0.167, 10.244.0.1, 203.0.113.42, 192.168.1.10 2001:db8::1 false
abdcd5be0a27417aa9e11cc2b27882bc86a63d94f547f909332ca7470a5e075a STOPPED 0 - - - false
aeaed9c2f56328bb6196ede4a78f06c4bb2d3edf5dca7912cf38407b9bf6610a STOPPED 0 - - - false
ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d RUNNING 0 - 10.0.0.167, 10.244.0.1, 203.0.113.42, 192.168.1.10 2001:db8::1 false
edb9d42e35a4029cfec5bed5597746bdf67fbe438f21446230252265ed1c849d STOPPED 0 - - - false
$ ps -ef |grep ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d
root 2674943 1 0 22:32 ? 00:00:00 /usr/libexec/crio/conmon -b /run/containers/storage/overlay-containers/ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d/userdata -c ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d --exit-dir /var/run/crio/exits -l /var/log/pods/kube-system_cilium-operator-56d6cd6767-dps78_6082ea2d-331e-4262-b8b3-d3f88eb4e446/cilium-operator/1.log --log-level info -n k8s_cilium-operator_cilium-operator-56d6cd6767-dps78_kube-system_6082ea2d-331e-4262-b8b3-d3f88eb4e446_1 -P /run/containers/storage/overlay-containers/ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d/userdata/conmon-pidfile -p /run/containers/storage/overlay-containers/ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d/userdata/pidfile --persist-dir /var/lib/containers/storage/overlay-containers/ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d/userdata -r /usr/local/bin/lxcri --runtime-arg --root=/var/lib/lxc --socket-dir-path /var/run/crio --syslog -u ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d -s
root 2674951 2674943 0 22:32 ? 00:00:00 /usr/local/libexec/lxcri/lxcri-start ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d /var/lib/lxc /var/lib/lxc/ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d/config

Rien ne nous empêcherait ensuite de pousser le vice, et de faire un petit script qui récupère toutes les informations des containers, et crée les fichiers /etc/pve/lxc/xxx.conf associés de manière à les afficher dans l’UI, comme je l’avais fait dans l’article :

Lancer des containers Docker avec Proxmox VE (et LXC)

En théorie, si cette étape avait du sens, je pourrais créer les releases moi-même sur mon fork pour faciliter l’installation.

Enfin, je pourrais essayer de contribuer mes modifications pour que tout soit mergé sur le projet principal, à ceci près que les mainteneurs refusent les PRs car le projet n’est plus maintenu.

Mais j’avoue qu’après probablement une quinzaine d’heures de debug, de Golang, de compilation C, réparties sur 2 ans, j’ai un peu été au bout de ma patience pour cette “blague”.

OK, c’était débile, maintenant que j’ai réussi, dodo X_X.