MicroK8s, K3s, Kubernetes managé, kubeadm : il n'existe pas de distribution universelle. Le bon choix dépend de votre contexte : budget, souveraineté, performance, exploitation et criticité.

Plutôt que de désigner un « meilleur Kubernetes », cet article détaille pour chaque distribution ce que l'on gagne, ce que l'on perd et les cas où nous la déconseillons. C'est précisément ce niveau de compromis technique qui compte lorsqu'on s'adresse à des architectes, des CTO ou des équipes SRE.

Voici, en un coup d'œil, les quatre familles que nous déployons le plus souvent chez WeFactorIT :

K3s : le Kubernetes minimaliste

K3s est développé par Rancher (désormais SUSE) avec un objectif simple : proposer un Kubernetes conforme tout en supprimant tout ce qui n'est pas indispensable. Contrairement à Kubernetes classique, il remplace certains composants lourds afin de réduire drastiquement l'empreinte mémoire.

Ce que l'on gagne :

• Très faible consommation. Un control plane K3s fonctionne facilement avec 2 vCPU, 2 Go de RAM et quelques centaines de Mo au repos, là où kubeadm ou MicroK8s demandent généralement davantage. Sur des Raspberry Pi, Mini-PC, Intel NUC ou serveurs edge, la différence est énorme.
• Installation extrêmement rapide. Un cluster HA est disponible en quelques minutes : aucun kubeadm, aucune initialisation complexe, très peu de configuration. Pour un laboratoire ou un POC, c'est probablement la meilleure expérience Kubernetes aujourd'hui.
• SQLite intégré. Pour un cluster mono-nœud, pas d'etcd ni de base externe. On peut ensuite migrer vers etcd embarqué ou externe sans tout reconstruire.
• Distribution CNCF conforme. Malgré sa légèreté, l'API Kubernetes standard, kubectl, Helm, ArgoCD, Istio, cert-manager ou Prometheus fonctionnent normalement.
• Idéal pour le Edge. Très utilisé en usine, IoT, retail, magasins, télémétrie et sites distants, car les contraintes matérielles y sont faibles.

Une installation tient littéralement en une ligne :

# Nœud serveur (control plane + worker)
curl -sfL https://get.k3s.io | sh -

# Ajouter un nœud agent
curl -sfL https://get.k3s.io | K3S_URL=https://<server>:6443 K3S_TOKEN=<token> sh -

Ce que l'on perd :

• Des composants remplacés par défaut. K3s embarque Traefik, Local Path Provisioner, ServiceLB et Flannel. Beaucoup d'entreprises les remplacent rapidement par Istio, MetalLB, Longhorn ou Cilium : il faut prévoir cette étape.
• Une distribution « opinionated ». K3s fait certains choix techniques. Pour obtenir un cluster totalement neutre ou identique à kubeadm, il faut désactiver plusieurs composants.
• Moins adapté aux très gros clusters. Même si K3s supporte plusieurs centaines de nœuds, les très grands clusters (> 500 à 1000 nœuds) restent davantage le terrain de Kubernetes standard.

Nous recommandons K3s pour : les laboratoires personnels, les clusters edge, les petites plateformes internes et les environnements de développement. À déconseiller dès que l'on vise un cluster upstream strictement neutre ou une très grande échelle.

MicroK8s : le Kubernetes upstream simplifié

MicroK8s est développé par Canonical avec un objectif très différent de K3s : rester extrêmement proche du Kubernetes officiel. On retrouve donc une architecture beaucoup plus fidèle à kubeadm.

Ce que l'on gagne :

• Très proche du Kubernetes officiel. Les composants restent proches de ceux des distributions classiques, ce qui facilite les formations, les certifications Kubernetes, la migration vers kubeadm et la compréhension des internes.
• Dqlite. Il remplace etcd dans les petits clusters HA et apporte moins de RAM, moins de maintenance et une réplication automatique. Pour des clusters de 3 à 10 nœuds, c'est extrêmement intéressant.
• Gestion des addons. Canonical fournit une bibliothèque officielle installable en une commande (dns, ingress, metrics-server, prometheus, grafana, rook-ceph, cert-manager, observability...). Un vrai gain de temps pour un lab ou une plateforme interne.
• Très bon support ARM. MicroK8s fonctionne aussi bien sur Raspberry Pi, ARM64 qu'AMD64 ; Canonical investit énormément sur cette architecture.
• Canonical derrière le projet. Pour les entreprises visant Ubuntu Pro, un support entreprise ou un cycle de vie long, cela peut être un avantage important.

# Installation et addons essentiels
sudo snap install microk8s --classic
sudo microk8s enable dns hostpath-storage ingress
sudo microk8s status --wait-ready

Ce que l'on perd :

• Dépendance aux Snap. C'est le reproche principal : toute l'installation repose sur Snap. Les organisations qui désactivent Snap ou standardisent sur RHEL, Rocky ou Debian écartent parfois MicroK8s pour cette raison.
• Moins modulaire. De nombreux composants sont pilotés via MicroK8s, ce qui éloigne un peu de la philosophie « chaque composant est indépendant ».
• Communauté plus petite. Comparé à K3s : moins de tutoriels, de blogs et de vidéos, même si la documentation officielle reste excellente.
• Dqlite n'est pas etcd. Dqlite fonctionne très bien, mais au-delà de plusieurs centaines de nœuds ou d'un très grand nombre d'objets Kubernetes, la majorité des très gros clusters continuent d'utiliser etcd.

Nous l'utilisons régulièrement pour : les infrastructures privées, les environnements de démonstration, les laboratoires cloud et les plateformes de formation. À déconseiller sur les OS où Snap est proscrit, ou pour les clusters à très grande échelle.

Kubernetes managé : la meilleure option pour la production

Lorsque l'objectif est d'héberger des applications critiques ou de construire une plateforme SaaS à grande échelle, nous privilégions généralement les offres Kubernetes managées. Le fournisseur prend en charge le control plane, etcd, les sauvegardes, les mises à jour et la disponibilité ; l'utilisateur gère essentiellement ses applications, ses nœuds, son réseau et ses workloads.

Ce que l'on gagne :

• Plus de maintenance du control plane. Plus besoin de maintenir etcd, l'API Server, le Scheduler ou le Controller Manager : tout est pris en charge. C'est le gain principal.
• Très forte disponibilité. Le control plane est généralement répliqué sur plusieurs zones, un niveau très difficile à atteindre en interne.
• Sécurité. Rotation automatique des certificats, mises à jour et patchs critiques : le risque opérationnel diminue fortement.
• Intégration cloud. Load Balancer, volumes, IAM, DNS, monitoring, registry et autoscaling sont disponibles immédiatement, sans installation supplémentaire.
• Scalabilité. Créer un cluster supplémentaire prend quelques minutes, et l'ajout de centaines de nœuds est entièrement automatisé.

Ce que l'on perd :

• Coût. Le control plane est parfois facturé, auxquels s'ajoutent Load Balancer, volumes, trafic sortant et IP publiques. Le coût réel dépasse souvent largement celui des VM.
• Vendor lock-in. Chaque fournisseur ajoute ses propres services (IAM, CSI, CNI, autoscaler, monitoring), rendant la migration progressivement plus difficile.
• Moins de contrôle. Impossible de modifier l'API Server, etcd ou certains paramètres système : le fournisseur garde la main.
• Souveraineté. Pour certaines organisations (administrations, défense, santé, industries sensibles), un cloud public n'est pas acceptable, même si les offres européennes répondent mieux à ces exigences.

Cette approche permet aux équipes de se concentrer sur les applications plutôt que sur la maintenance du cluster. À déconseiller lorsque la souveraineté totale, le contrôle bas niveau ou la maîtrise des coûts d'infrastructure priment.

Kubernetes vanilla (kubeadm) : la quatrième famille souvent oubliée

Il manque souvent une distribution pourtant fondamentale dans ce type de comparatif : Kubernetes standard déployé avec kubeadm. C'est la base de nombreuses plateformes privées, et c'est fréquemment la meilleure solution lorsqu'on veut un cloud privé souverain, un contrôle total de l'infrastructure, des clusters de grande taille et aucune dépendance à une distribution spécifique.

Ce que l'on gagne :

• Kubernetes 100 % upstream, aucun composant imposé.
• Compatible avec tous les CNI (Cilium, Calico, Flannel...) et tous les CSI.
• Très forte communauté et documentation officielle abondante.
• Référence pour les certifications Kubernetes.

Ce que l'on perd :

• Installation plus complexe que K3s ou MicroK8s.
• Gestion d'etcd à prévoir : sauvegardes, restauration, surveillance.
• Davantage d'opérations quotidiennes : montées de version, rotation des certificats, maintenance du control plane.
• Courbe d'apprentissage plus élevée pour les équipes peu expérimentées.

Nous recommandons kubeadm pour : les entreprises qui construisent un cloud privé durable, souverain et à grande échelle, avec une équipe capable d'assumer l'exploitation du control plane. À déconseiller pour un simple lab ou une petite plateforme, où K3s ou MicroK8s seront bien plus rapides à opérer.

Notre retour d'expérience terrain

Ces recommandations ne sortent pas d'un tableau comparatif : elles reposent sur plusieurs années d'exploitation en production.

• MicroK8s sur Proxmox : 3 ans en production. Nous avons opéré pendant trois ans un cluster MicroK8s virtualisé sur Proxmox. La haute disponibilité via Dqlite, la gestion des addons et la proximité avec Kubernetes upstream se sont révélées solides pour une infrastructure privée sur le long terme.
• K3s en bare metal chez plusieurs clients. Nous avons déployé K3s directement sur du bare metal chez plusieurs clients. Son empreinte minimale et son installation en une commande en font un choix idéal pour tirer le maximum du matériel sans la surcharge d'une distribution complète.
• Dqlite fiable en réseau contraint (< 1 Gb/s). Nous avons pu constater la fiabilité de Dqlite, le moteur de MicroK8s, dans des environnements à débit réseau limité (moins d'1 Gb/s), avec des résultats très concluants. Autrement dit, malgré une empreinte un peu plus gourmande que K3s, MicroK8s reste un très bon choix pour les environnements IoT et edge où le réseau n'est pas garanti.

Ces retours confirment notre matrice de décision : K3s brille dès qu'il faut de la légèreté sur du matériel dédié, tandis que MicroK8s excelle sur les infrastructures privées durables, y compris en edge, grâce à la robustesse de Dqlite sur des liens réseau contraints.

Une matrice de décision plus complète

Notre approche chez WeFactorIT

Nous ne considérons pas qu'il existe une distribution Kubernetes universelle. Chaque projet possède ses propres contraintes en matière de budget, de sécurité, de souveraineté, de performance et d'exploitation.

Notre matrice de décision par cas d'usage est généralement la suivante :

Aujourd'hui, notre vision va au-delà du simple cluster Kubernetes. Nous construisons des plateformes complètes intégrant GitOps, observabilité, sécurité, automatisation et intelligence artificielle afin d'offrir une expérience cloud moderne, souveraine et durable.

Le cluster n'est plus la finalité : il devient la fondation d'une plateforme numérique capable d'évoluer avec les besoins de l'entreprise.