← Tous les articles
Mer. 4 mars 2026 · 3 min de lecture

☸️ k3s et k3d : un Kubernetes léger pour développer en local

# Kubernetes # k3s # DevOps # Docker
k3s

📚 Introduction

Pour développer une application destinée à tourner sur Kubernetes, monter un cluster complet sur sa machine semble disproportionné. Minikube fait le job depuis longtemps, mais il consomme beaucoup et il est lourd à démarrer.

k3s, créé par Rancher, est une distribution Kubernetes minimaliste : un binaire unique de moins de 100 Mo, conforme à l’API officielle, idéal pour les environnements contraints. k3d l’encapsule dans Docker, ce qui permet de monter un cluster multi-nœuds en quelques secondes sur n’importe quelle machine où Docker tourne déjà.

C’est aujourd’hui mon outil par défaut pour reproduire en local un environnement Kubernetes proche de la production.

🚀 Installation et premier cluster

# Installation de k3d
brew install k3d
 
# Création d'un cluster avec un nœud master et deux workers
k3d cluster create dev \
	--agents 2 \
	--port "8080:80@loadbalancer" \
	--port "8443:443@loadbalancer"

Quelques secondes plus tard, kubectl est automatiquement configuré pour pointer sur le nouveau cluster :

kubectl get nodes
# NAME                STATUS   ROLES                  AGE
# k3d-dev-server-0    Ready    control-plane,master   12s
# k3d-dev-agent-0     Ready    <none>                 10s
# k3d-dev-agent-1     Ready    <none>                 10s

Et c’est tout. Vous avez un vrai Kubernetes, multi-nœuds, accessible depuis votre poste de dev.

🧱 Ce que k3s embarque par défaut

C’est probablement l’argument principal en faveur de k3s : il vient avec une stack utilisable immédiatement, là où un Kubernetes “vanilla” demande beaucoup d’installations supplémentaires.

  • Traefik comme ingress controller, configuré et prêt à servir des routes HTTPS.
  • CoreDNS pour la résolution interne.
  • Flannel comme CNI par défaut, sans aucune configuration réseau à fournir.
  • Local Path Provisioner pour avoir des PersistentVolumes sans configurer Longhorn ou un CSI distant.
  • ServiceLB (Klipper-LB) pour exposer des services de type LoadBalancer même sans cloud sous-jacent.
  • metrics-server pour kubectl top pod et l’autoscaling.

Sur un cluster managé classique, chacune de ces briques se configure à la main. Sur k3s, tout est déjà là.

🧰 Workflows quotidiens

Quelques patterns que j’utilise au quotidien :

Tester un Helm chart en local avant de le pousser en staging :

helm upgrade --install api ./charts/api \
	--namespace staging --create-namespace \
	--values ./charts/api/values.local.yaml

Importer une image Docker locale dans le cluster sans passer par un registry distant :

k3d image import my-app:dev -c dev

Recréer un cluster propre en 30 secondes pour valider une procédure de bootstrap from scratch :

k3d cluster delete dev
k3d cluster create dev --agents 2

C’est la grande force du combo k3s + k3d : la fluidité du cycle “casse / recommence”. On peut tester des migrations de cluster, des changements de CRD, des upgrades, sans peur de tout casser.

🌐 Au-delà du dev : production single-node

k3s n’est pas qu’un outil de dev. Pour de la production single-node (petits services internes, sites de présentation, environnements de staging), il fait parfaitement l’affaire :

curl -sfL https://get.k3s.io | sh -

Cette commande installe un cluster Kubernetes complet sur un serveur. C’est ce que Rancher utilise sur des dizaines de milliers de déploiements en edge ou en IoT, et la philosophie de Kubernetes (manifests déclaratifs, opérateurs, GitOps) s’applique exactement comme sur EKS ou GKE.

⚠️ Les limites à connaître

  • SQLite par défaut comme datastore. C’est suffisant pour le dev et le single-node, mais pour un cluster multi-master en production, basculez sur etcd embarqué ou un Postgres externe.
  • Pas d’arm64 sur certaines stacks anciennes : vérifiez la compatibilité de vos images si vous déployez sur des Raspberry Pi.
  • Les composants par défaut peuvent être désactivés (--disable traefik, --disable servicelb…) si vous voulez gérer vous-même. C’est explicite, mais c’est à savoir.

🎉 Conclusion

Si Kubernetes est dans votre stack ou dans celle de vos clients, k3s et k3d font partie de la boîte à outils minimale. Pour le développement local, c’est l’expérience la plus proche d’un cluster managé qu’on puisse avoir gratuitement. Pour les petits déploiements ou les environnements de staging, c’est une solution de production crédible.

Et surtout, c’est un excellent terrain de jeu pour monter en compétences sur Kubernetes sans dépenser un euro de cloud. Pour les projets qui n’ont pas besoin de la complexité d’un cluster, Coolify reste mon premier réflexe ; k3s entre en scène dès qu’on a plusieurs services à orchestrer ou qu’on veut s’aligner sur la cible de production.

🔗 Liens utiles

/faq

Questions fréquentes

Quelle est la différence entre k3s et k3d ?

+

k3s est une distribution Kubernetes minimaliste créée par Rancher, un binaire unique de moins de 100 Mo conforme à l'API officielle. k3d l'encapsule dans Docker, ce qui permet de monter un cluster multi-nœuds en quelques secondes sur n'importe quelle machine où Docker tourne déjà.

Quels composants k3s embarque-t-il par défaut ?

+

k3s vient avec une stack utilisable immédiatement : Traefik comme ingress controller, CoreDNS, Flannel comme CNI, Local Path Provisioner pour les PersistentVolumes, ServiceLB (Klipper-LB) pour les services LoadBalancer et metrics-server.

Peut-on utiliser k3s en production ?

+

Oui, k3s convient à de la production single-node (petits services internes, sites de présentation, staging) et s'installe avec « curl -sfL https://get.k3s.io | sh - ». Pour un cluster multi-master en production, il faut toutefois basculer le datastore SQLite par défaut vers etcd embarqué ou un Postgres externe.