En résumé : K3s est une distribution Kubernetes certifiée CNCF, optimisée pour les environnements contraints (edge, IoT, labs). K8s désigne le projet Kubernetes originel, conçu pour des clusters de production à grande échelle. Le choix dépend de vos ressources disponibles, de votre contexte de déploiement et de votre charge opérationnelle.

K8s : le Kubernetes standard entreprise

K8s est l'abréviation de Kubernetes, le « 8 » représentant les huit lettres entre le « K » et le « s ». Il s'agit du projet open source original, maintenu par la Cloud Native Computing Foundation (CNCF) et initialement développé par Google.

Kubernetes est conçu pour des environnements de production à grande échelle : clusters multi-nœuds, haute disponibilité, intégration avec les clouds publics (AWS, GCP, Azure) ou des datacenters on-premises. Son plan de contrôle comprend plusieurs composants distincts : API server, scheduler, controller manager, etcd, déployés séparément, ce qui offre une flexibilité maximale mais requiert une expertise opérationnelle significative.

Prérequis typiques pour un nœud control plane en production : 2 vCPU et 2 Go de RAM au minimum pour les composants Kubernetes seuls, sans compter etcd ni les charges applicatives.

K3s : une distribution Kubernetes certifiée CNCF, pas un fork

K3s est une distribution certifiée de Kubernetes, pas une version allégée non officielle ni un fork. Créé par Rancher Labs, il a été donné à la CNCF en juin 2020 et passe les mêmes tests de conformité Sonobuoy que toutes les distributions certifiées. Tout manifeste Kubernetes valide fonctionne sur K3s.

Son objectif principal : réduire drastiquement les ressources nécessaires pour faire tourner Kubernetes sur des environnements contraints (edge, IoT, CI/CD, labs)  sans renoncer à la compatibilité API.

Ce que K3s change par rapport à K8s

• Binary unique de moins de 70 Mo (x86, ARM64, ARMv7 et S390X supportés), incluant le runtime containerd, le CNI Flannel, un Ingress Traefik et un load balancer Klipper.
• SQLite comme datastore par défaut en single-node, au lieu d'etcd. En configuration haute disponibilité (3 nœuds serveur minimum), K3s peut utiliser etcd embarqué ou un datastore externe (MySQL, PostgreSQL, etcd externe).
• Composants alpha/beta retirés pour réduire la surface d'attaque et l'empreinte mémoire.

Point important : K3s ne supprime pas etcd ; il le rend optionnel. En single-node, SQLite suffit. En haute disponibilité, etcd embarqué ou externe est supporté - mais ce dernier n'est pas officiellement pris en charge par l'équipe K3s.

Empreinte ressources

K3s fonctionne à partir de 512 Mo de RAM sur un nœud agent. Un server node (control plane) requiert 2 Go de RAM et 2 cœurs CPU selon la documentation officielle (mise à jour mai 2026), hors charge applicative. Un profil mesuré à la charge est disponible dans le guide de resource profiling K3s. À noter : en test sur du matériel avec 1 Go de RAM total, les distributions K3s, k0s et MicroK8s ont montré des instabilités lors du déploiement de charges applicatives réelles (un seul cluster Kubernetes, même léger, consomme des ressources de contrôle non négligeables).

Différences techniques clés

Datastore

Runtime et packaging

K8s ne fournit pas de runtime par défaut depuis la suppression de dockershim (v1.24, 2022). À partir de Kubernetes 1.24, vous devez installer un runtime CRI-compatible (containerd ou CRI-O). K3s embarque containerd directement dans son binaire.

Architecture du plan de contrôle

Dans K8s, les composants du plan de contrôle (API server, scheduler, controller manager) sont des processus séparés. Dans K3s, ils sont fusionnés en un seul binaire, ce qui réduit l'overhead mais limite certaines configurations avancées d'isolation.

Scalabilité

K3s est adapté à des clusters de taille modérée. En configuration haute disponibilité (3 server nodes, 4 vCPU / 8 Go de RAM), la documentation officielle indique une capacité d'environ 1 200 agents. Pour des clusters de très grande taille (plusieurs milliers de nœuds), K8s  reste la référence.

Tableau comparatif K3s vs K8s

Cas d'usage : lequel choisir ?

Choisissez K3s si :

• Vous déployez sur du matériel contraint (Raspberry Pi, appliances industrielles, serveurs edge avec peu de RAM).
• Vous gérez des clusters IoT ou edge distants, potentiellement en mode déconnecté.
• Vous avez besoin d'un cluster de développement ou de CI démarrant rapidement, y compris sur matériel modeste.
• Vous souhaitez un cluster opérationnel avec un minimum de configuration initiale.

Choisissez K8s (ou une distribution enterprise) si :

• Vous orchestrez des centaines ou milliers de nœuds en production.
• Vos workloads requièrent des intégrations cloud-natives avancées (stockage, load balancers, IAM) fournies par les hyperscalers.
• Vous avez besoin de composants API en alpha/beta non disponibles dans K3s.
• Votre organisation dispose d'une équipe SRE dédiée à l'exploitation de clusters.

Cas hybrides : K3s et K8s ensemble

K3s et K8s ne sont pas mutuellement exclusifs. Plusieurs architectures hybrides sont documentées en production :

Fleet management avec Rancher

Des clusters K3s edge sont pilotés depuis un plan de contrôle central tournant sur K8s ou RKE2. The Home Depot (grande distribution américaine, plus de 2 300 magasins) gère ainsi ses sites avec K3s supervisé depuis Rancher.

Clusters de dev et staging K3s, prod K8s

La compatibilité API garantit que les manifests et charts Helm testés sur K3s fonctionnent en production sur un cluster enterprise. Cette parité réduit les surprises en promotion d'environnements.

CI/CD

Des pipelines de test tournent sur K3s (faible coût, démarrage rapide) pendant que les environnements de production utilisent un cluster K8s managé.

Kubernetes managé : une troisième voie

Ni K3s ni K8s ne résolvent la question de l'opération quotidienne : mises à jour, certificats, surveillance du plan de contrôle, gestion des défaillances. C'est précisément ce que couvrent les solutions de Kubernetes managé.

Les hyperscalers (EKS, GKE, AKS) proposent cette gestion dans leurs propres clouds. Mais des solutions managées existent aussi en dehors de ces écosystèmes, notamment pour des organisations qui souhaitent conserver la maîtrise de leurs données et opter pour un Kubernetes souverain, voire un Kubernetes français.

Clever Kubernetes Engine (CKE) est le service Kubernetes managé de Clever Cloud, conçu pour des équipes qui utilisent déjà Kubernetes et souhaitent déléguer la gestion du plan de contrôle (updates, haute disponibilité, monitoring) sans être contraints dans un seul hyperscaler. CKE s'adresse explicitement aux équipes que le modèle PaaS traditionnel ne couvre pas (cas multi-runtime, workloads non-twelve-factor, ou besoin de contrôle granulaire sur les ressources).

FAQ

K3s est-il un fork de Kubernetes ?

Non. K3s est une distribution certifiée CNCF de Kubernetes. Il passe les tests de conformité Sonobuoy et respecte les mêmes APIs que K8s Il n'est pas maintenu en parallèle de Kubernetes : il suit les releases du projet originel.

Peut-on utiliser K3s en production ?

Oui, avec des nuances. K3s est documenté pour des charges de production dans des environnements contraints (edge, IoT). Pour des clusters à grande échelle ou des workloads critiques avec des exigences de SLA élevées, le K8s  (ou une distribution enterprise comme RKE2) est plus adapté.

K3s supporte-t-il Helm ?

Oui. K3s inclut un contrôleur Helm intégré et est compatible avec toute chart Helm valide.

Quelle est la différence entre K3s et K3d ?

K3d est un outil qui fait tourner K3s dans des conteneurs Docker. Il simplifie encore davantage la création de clusters K3s locaux pour le développement, mais n'est pas destiné à la production.

K3s fonctionne-t-il sur ARM ?

Oui. ARM64 et ARMv7 sont nativement supportés, ce qui explique sa popularité sur Raspberry Pi et les appliances industrielles.

Kubernetes managé vs K3s auto-hébergé : quoi choisir ?

K3s auto-hébergé vous donne un contrôle total mais vous rend responsable des opérations (updates, sécurité, haute disponibilité). Un Kubernetes managé délègue cette responsabilité à un opérateur, au prix d'une dépendance envers ce fournisseur. Le choix dépend de vos ressources opérationnelles et de vos exigences de contrôle.