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

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

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 seul binaire de moins de 70 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.
  • Local Path Provisioner pour avoir des PersistentVolumes sans configurer Longhorn ou un CSI distant.
  • ServiceLB 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.

🔗 Liens utiles