Dossier K3s vs Kubernetes (K8s) : quelles différences et lequel choisir ?

K3s est souvent résumé à un « Kubernetes léger ». C’est juste, mais un peu court !

K3s n’est ni un concurrent de Kubernetes, ni une version simplifiée au point de changer son fonctionnement. C’est une distribution Kubernetes conforme, pensée pour faciliter le déploiement et réduire l’empreinte nécessaire au fonctionnement d’un cluster. Elle embarque notamment son runtime, son réseau, son Ingress Controller ou encore son mécanisme de Load Balancing avec des choix par défaut déjà réalisés.

La vraie question n’est donc pas tout à fait « K3s ou Kubernetes ? », mais plutôt : de quel niveau de simplicité, de personnalisation et de maîtrise opérationnelle votre plateforme Kubernetes a-t-elle besoin ?

Au moment de cette mise à jour, K3s suit toujours de près Kubernetes upstream : la version stable K3s v1.37.0+k3s1, publiée en septembre 2026, s’appuie sur Kubernetes v1.37.0.

K3s et K8s : de quoi parle-t-on exactement ?

Commençons par lever une ambiguïté fréquente. K8s est simplement l’abréviation de Kubernetes. Kubernetes est le projet open source d’orchestration de conteneurs porté par la CNCF. K3s est, lui, une distribution de Kubernetes. Le projet précise d’ailleurs qu’il ne s’agit pas d’un fork : l’objectif est de rester au plus proche de Kubernetes upstream, tout en ajoutant le packaging et les composants nécessaires à la création d’un cluster directement exploitable.

Dans la suite de cet article, lorsque nous comparons K3s à un « Kubernetes classique », nous prenons donc comme point de comparaison un cluster Kubernetes upstream que l’on construirait, par exemple, avec kubeadm.

Avec kubeadm, Kubernetes laisse volontairement de nombreux choix à l’administrateur. Il faut notamment installer un runtime de conteneurs et choisir un plugin réseau CNI avant d’obtenir un environnement complet.

K3s prend une autre direction : plusieurs de ces décisions sont déjà intégrées à la distribution. C’est précisément ce qui fait à la fois sa force et son principal compromis.

Pour élargir cette réflexion au choix d’une distribution, nous avons également détaillé les différences entre Kubernetes upstream, OpenShift, Talos et d’autres approches dans notre article Quel Kubernetes est fait pour vous ?

K3s vs Kubernetes : les principales différences

L’erreur serait toutefois d’en déduire que K3s est une sorte de « mini-Kubernetes » réservé aux Raspberry Pi.

Il partage les API et les mécanismes fondamentaux de Kubernetes. La différence se joue principalement dans le packaging, les choix techniques réalisés en amont et l’exploitation du cluster.

Parole d’expert

Kubernetes : quelle distribution choisir pour votre stratégie de conteneurisation ?

Télécharger notre guide

Pourquoi K3s est-il plus léger que Kubernetes ?

Le poids du binaire est la partie la plus visible, mais ce n’est pas forcément la plus intéressante.

K3s est distribué dans un binaire de moins de 100 Mo et rassemble les composants du control plane Kubernetes dans un nombre réduit de processus. Cette mutualisation diminue la surcharge liée à l’exécution séparée de nombreux composants.

Le projet réduit également son empreinte en ne conservant pas deux catégories historiques de composants Kubernetes upstream :

• les drivers de stockage in-tree ;
• les cloud providers in-tree.

Cela ne signifie pas que K3s ne peut pas utiliser du stockage externe ou être intégré à un environnement Cloud. Ces intégrations passent aujourd’hui par les interfaces prévues à cet effet, comme CSI pour le stockage et les Cloud Controller Managers externes.

Autrement dit : K3s ne retire pas arbitrairement des fonctions Kubernetes nécessaires aux applications. Il réduit surtout ce qu’il doit embarquer lui-même.

Quelles ressources faut-il réellement prévoir pour K3s ?

K3s est adapté aux infrastructures contraintes, mais « léger » ne signifie pas qu’un environnement de production peut être dimensionné au minimum sans réflexion.

La documentation K3s donne aujourd’hui les prérequis matériels suivants :

• serveur K3s : 2 cœurs CPU et 2 Go de RAM minimum ;
• agent K3s : 1 cœur CPU et 512 Mo de RAM minimum.

Ces valeurs correspondent à des minima techniques, pas à une recommandation universelle de dimensionnement.

Dès qu’un serveur héberge également etcd, des workloads, de l’observabilité ou d’autres services de plateforme, les besoins augmentent.

Le stockage est également déterminant. K3s recommande l’utilisation d’un SSD lorsque cela est possible. Ce point devient particulièrement important avec etcd, qui réalise de nombreuses opérations d’écriture. Sur Raspberry Pi ou équipements ARM similaires, la documentation recommande d’ailleurs un SSD externe plutôt qu’une carte SD ou de l’eMMC pour les environnements utilisant etcd.

C’est un point que nous regardons avec attention chez Inside : un orchestrateur léger ne compense pas une architecture sous-dimensionnée. Le choix d’une distribution Kubernetes doit rester cohérent avec le nombre de nœuds, les workloads, les besoins de résilience et le niveau de service attendu.

Que contient K3s aujourd’hui ?

K3s adopte une logique « batteries included » : les briques nécessaires à un cluster immédiatement utilisable sont fournies par défaut.

On retrouve notamment :

• containerd / cri-dockerd pour l’exécution des conteneurs ;
• Flannel comme CNI ;
• CoreDNS pour le DNS du cluster ;
• Traefik comme Ingress Controller ;
• ServiceLB pour les services de type LoadBalancer ;
• kube-router pour la gestion des Network Policies ;
• Local Path Provisioner pour le stockage local ;
• Metrics Server ;
• Helm Controller ;
• Kine pour permettre l’utilisation de différents datastores ;
• Spegel comme miroir distribué d’images de conteneurs.

Ces choix sont importants car ils changent l’expérience de démarrage.

Avec un Kubernetes construit via kubeadm, l’équipe doit par exemple sélectionner et installer son CNI. Dans K3s, Flannel fonctionne directement.

Même logique pour l’Ingress : Traefik est installé par défaut.

Ce fonctionnement ne signifie pas que l’architecture est figée. Une partie de ces composants peut être désactivée ou remplacée. Une équipe peut par exemple ne pas utiliser Traefik ou préférer une autre solution réseau.

C’est là que le positionnement de K3s est intéressant : des choix sont faits pour vous permettre de démarrer vite, sans vous empêcher de les remettre en question lorsque le contexte le justifie.

Comment fonctionne le datastore de K3s ?

C’est l’un des sujets qui différencient le plus K3s d’une installation Kubernetes classique.

Sur un serveur unique, K3s utilise SQLite par défaut.

Pour une architecture haute disponibilité, SQLite n’est plus adapté : la documentation K3s précise qu’il ne peut pas être utilisé avec plusieurs serveurs.

Deux grandes options existent alors.

Utiliser etcd embarqué

K3s peut créer directement un cluster etcd embarqué.

Une architecture haute disponibilité avec etcd intégré nécessite au minimum trois nœuds serveurs, avec un nombre impair de serveurs pour conserver le quorum.

Cette approche évite de devoir exploiter un datastore séparé.

Utiliser une base externe

K3s peut également s’appuyer sur :

• etcd ;
• MySQL ;
• MariaDB ;
• PostgreSQL.

Ce choix peut être pertinent lorsque l’entreprise possède déjà les compétences et les standards d’exploitation associés à ces technologies.

Il faut donc éviter une règle trop simpliste du type « K3s = SQLite ». SQLite est surtout une excellente option pour un cluster mono-serveur, du développement, de la CI ou certains environnements edge simples.

À partir du moment où la disponibilité du control plane devient critique, le choix du datastore redevient une décision d’architecture.

K3s est-il adapté à la production ?

Oui. Le projet K3s se présente aujourd’hui explicitement comme production-ready.

Cela ne veut pas dire qu’un cluster K3s installé avec les paramètres par défaut devient automatiquement une plateforme de production résiliente.

Comme pour n’importe quel Kubernetes, il faut traiter les sujets qui entourent l’orchestrateur :

• haute disponibilité du control plane ;
• stockage ;
• sauvegarde ;
• réseau ;
• load balancing ;
• sécurité ;
• observabilité ;
• politique de mises à jour ;
• reprise après incident ;
• capacité à reconstruire la plateforme.

La différence est que K3s automatise ou préconfigure une partie de ce travail.

C’est aussi pour cela que nous évitons chez Inside de réduire le choix d’un Kubernetes à une comparaison de fonctionnalités. Le coût réel apparaît dans le BUILD, mais surtout dans le RUN.

Sur des projets Kubernetes on-premise, nous avons par exemple mis en œuvre des approches de type Kubernetes as a Product, associant Cluster API, GitOps et automatisation. Sur une mission menée pour un acteur du transport, cette industrialisation a permis de provisionner un cluster certifié en moins de dix minutes et de réduire la dépendance aux opérations manuelles.

Ce retour est indépendant de K3s, mais il illustre un point essentiel : le choix de la distribution n’est qu’une partie du problème. La capacité à industrialiser son cycle de vie fait souvent davantage la différence.

Pour approfondir cette approche, voir notre accompagnement autour de la transformation DevOps et des plateformes Kubernetes.

Dans quels cas K3s est-il particulièrement pertinent ?

K3s reste très pertinent pour les environnements historiquement associés au projet, mais son périmètre est aujourd’hui plus large.

Edge computing et sites distribués

C’est probablement le terrain le plus naturel pour K3s.

Lorsqu’une entreprise doit déployer Kubernetes sur de nombreux sites disposant de peu de ressources, la réduction du nombre de composants et la simplicité d’installation prennent tout leur sens.

Cela concerne par exemple :

• l’industrie ;
• les équipements edge ;
• des points de vente ;
• des agences ;
• des sites techniques distants ;
• certains systèmes embarqués.

K3s supporte notamment les architectures ARM en plus de x86_64, ce qui élargit le choix des équipements.

Environnements isolés ou air-gapped

K3s propose un processus documenté spécifiquement pour les installations sans accès direct à Internet.

Les images peuvent notamment être chargées via un registre privé, manuellement ou en utilisant le mécanisme de registre miroir embarqué.

Pour des infrastructures industrielles, souveraines ou exposées à des contraintes de sécurité fortes, ce n’est pas un détail.

Développement, tests et CI

Un cluster qui doit être créé rapidement, utilisé pendant quelques heures puis supprimé n’a pas forcément besoin de toute la complexité d’une plateforme Kubernetes fortement industrialisée.

K3s permet de disposer rapidement d’un environnement Kubernetes réaliste avec un faible coût d’infrastructure.

C’est un cas d’usage particulièrement intéressant pour des environnements de CI, des plateformes de test ou certains besoins de développement.

Kubernetes on-premise avec une architecture compacte

K3s peut également convenir à des plateformes internes plus classiques.

Le sujet devient alors moins « peut-il tourner en production ? » que « ses choix d’architecture correspondent-ils à notre modèle d’exploitation ? ».

Inside accompagne régulièrement des organisations dans la modernisation de leurs infrastructures et la mise en place de plateformes Kubernetes on-premise. Sur ce type de projet, nous arbitrons la technologie à partir de l’existant, du niveau d’autonomie attendu, des contraintes de sécurité et de la capacité réelle des équipes à maintenir la plateforme.

Quand K3s n’est-il pas forcément le meilleur choix ?

La légèreté n’est pas un objectif en soi.

Si votre organisation dispose déjà d’une plateforme Kubernetes standardisée, d’une distribution de référence ou d’une équipe plateforme ayant défini son propre socle, remplacer cette architecture par K3s n’apportera pas nécessairement de valeur.

K3s peut aussi être moins naturel lorsque chaque composant de la plateforme doit être choisi indépendamment dès le départ.

Par exemple, si votre architecture impose :

• un CNI précis ;
• une solution Ingress déjà standardisée ;
• un modèle de stockage spécifique ;
• une gouvernance de plateforme très personnalisée ;
• une distribution Kubernetes imposée à l’échelle du groupe ;

les bénéfices liés aux composants prépackagés de K3s diminuent mécaniquement.

Cela ne veut pas dire que K3s ne peut pas être adapté. Beaucoup de composants intégrés peuvent être remplacés. Mais si l’on commence par désactiver presque tout ce que la distribution fournit, il devient pertinent de se demander si l’on exploite encore réellement son principal avantage.

Notre conseil : ne choisissez pas K3s parce qu’il est léger. Choisissez-le si son modèle d’exploitation simplifie réellement votre plateforme.

K3s est-il moins flexible pour le réseau et le stockage ?

Pas nécessairement.

K3s propose Flannel par défaut pour le réseau des pods, mais permet d’utiliser d’autres solutions CNI.

Traefik est également fourni par défaut comme Ingress Controller et ServiceLB gère les services de type LoadBalancer. Ces composants peuvent être désactivés ou adaptés.

Un point mérite cependant l’attention : lorsque Traefik et ServiceLB sont utilisés dans leur configuration par défaut, ServiceLB utilise les nœuds du cluster pour exposer Traefik sur les ports 80 et 443. Cela peut entrer en conflit avec d’autres usages de ces ports et doit donc être intégré à la conception réseau.

Pour le stockage, Local Path Provisioner facilite la création de volumes locaux.

Mais stockage local ne signifie évidemment pas stockage hautement disponible.

Pour des données critiques, il faut à nouveau raisonner architecture : CSI, stockage distribué, stockage externe ou service fourni par l’infrastructure sous-jacente.

Les manifests Kubernetes sont-ils compatibles entre K3s et K8s ?

Dans une grande majorité de cas, les mêmes ressources Kubernetes peuvent être déployées sur K3s et sur une autre distribution conforme.

Mais il faut éviter de transformer cette compatibilité en promesse de migration « sans aucune modification ».

Une application peut dépendre de ressources propres à son environnement :

• une StorageClass ;
• un Ingress Controller ;
• un type de LoadBalancer ;
• un driver CSI ;
• un cloud provider ;
• des contraintes d’architecture CPU ;
• des politiques réseau particulières.

Le Deployment ou le Service Kubernetes restera parfaitement standard tandis qu’une partie des ressources d’infrastructure pourra nécessiter une adaptation.

C’est une différence importante entre portabilité de l’API Kubernetes et portabilité complète d’une plateforme.

Comment gérer les mises à jour d’un cluster K3s ?

La simplicité de K3s ne s’arrête pas à l’installation.

Les clusters peuvent être mis à jour manuellement ou via le System Upgrade Controller, qui utilise des ressources Kubernetes pour décrire les politiques de mise à jour et les groupes de nœuds concernés.

Dans une architecture comportant plusieurs serveurs et agents, la recommandation est de mettre à niveau :

1. les nœuds serveurs ;
2. puis les nœuds agents.

Le projet suit également étroitement le cycle Kubernetes upstream : son objectif affiché est de publier les correctifs dans la semaine suivant upstream et les nouvelles versions mineures sous 30 jours.

C’est un aspect important lorsque K3s entre dans le périmètre d’une plateforme de production : la facilité d’installation ne doit jamais conduire à négliger le versioning, les tests de montée de version et le rollback.

C’est aussi là que l’Infrastructure as Code et GitOps prennent tout leur intérêt : la plateforme doit pouvoir être décrite, reconstruite et faire l’objet des mêmes exigences de versioning que le logiciel qu’elle héberge.

Comment sauvegarder et restaurer K3s ?

Dans les clusters utilisant etcd embarqué, K3s fournit directement des mécanismes de snapshot.

Les snapshots peuvent être :

• programmés ;
• déclenchés manuellement ;
• stockés localement ;
• répliqués vers un stockage objet compatible S3.

Les snapshots programmés sont activés par défaut dans les configurations concernées, mais cela ne constitue pas à lui seul un plan de reprise d’activité.

Une sauvegarde que l’on n’a jamais restaurée reste une hypothèse.

En production, nous recommandons donc de formaliser :

• la fréquence des sauvegardes ;
• leur rétention ;
• leur externalisation ;
• les procédures de restauration ;
• les tests réguliers de reprise.

Ce point est parfois oublié dans les comparatifs K3s vs K8s alors qu’il pèse beaucoup plus lourd dans la fiabilité réelle d’une plateforme que la taille de son binaire.

Qu’en est-il de la sécurité avec K3s ?

K3s automatise plusieurs éléments de sécurisation, notamment autour des certificats et de la connexion entre serveurs et agents.

Le projet utilise également des tunnels WebSocket entre les agents et les serveurs. Cela permet notamment au control plane d’accéder au kubelet sans imposer l’exposition directe de son API sur chaque nœud agent.

Pour les Secrets Kubernetes, K3s permet d’activer le chiffrement au repos. Celui-ci n’est toutefois pas activé par défaut : il doit faire partie des choix explicites de sécurisation du cluster.

K3s prend aujourd’hui en charge plusieurs mécanismes de chiffrement et propose également des fonctions de rotation des clés.

Une plateforme Kubernetes reste néanmoins un système complexe. Utiliser K3s ne dispense donc pas de travailler :

• les droits RBAC ;
• la gestion des Secrets ;
• les Network Policies ;
• les images de conteneurs ;
• la supply chain logicielle ;
• le durcissement des hôtes ;
• les sauvegardes ;
• la journalisation ;
• l’exposition réseau.

La sécurité doit rester intégrée à la conception de la plateforme et pas ajoutée à la fin.

K3s ou Kubernetes : comment faire le bon choix ?

Plutôt qu’une règle universelle, voici les questions que nous poserions avant de choisir.

Choisissez plus naturellement K3s si…

• vos ressources matérielles sont contraintes ;
• vous déployez Kubernetes sur des sites edge ou distribués ;
• ARM fait partie de vos architectures cibles ;
• vous recherchez un cluster rapidement opérationnel ;
• vous souhaitez limiter le nombre de composants à assembler vous-même ;
• les environnements air-gapped sont importants ;
• vous souhaitez des choix par défaut cohérents tout en conservant la possibilité de les remplacer ;
• votre équipe plateforme doit exploiter de nombreux clusters compacts.

Un Kubernetes plus personnalisé peut être préférable si…

• votre organisation possède déjà un socle Kubernetes de référence ;
• vous souhaitez sélectionner individuellement chaque composant ;
• vos équipes maîtrisent déjà l’exploitation de ces différentes briques ;
• une distribution ou une architecture précise est imposée par votre contexte ;
• les bénéfices des composants intégrés de K3s seraient annulés par leur remplacement systématique.

Et dans de nombreux projets, la décision ne se limite d’ailleurs pas à K3s ou Kubernetes upstream. OpenShift, Talos ou les Kubernetes managés des hyperscalers répondent à d’autres modèles opérationnels.

C’est pourquoi le choix d’une distribution ne devrait jamais commencer par une grille de fonctionnalités.

Il doit partir de l’organisation qui va la construire, l’exploiter et la maintenir pendant plusieurs années.

Notre regard chez Inside : le sujet n’est plus seulement Kubernetes, mais la plateforme

Nous avons vu Kubernetes passer progressivement du statut de technologie d’infrastructure à celui de socle de plateforme.

La question n’est plus uniquement de savoir comment installer un cluster. Elle devient : comment permettre aux équipes de disposer d’environnements standardisés, sécurisés et automatisés sans leur exposer toute la complexité de l’infrastructure ?

C’est précisément l’un des enjeux du Platform Engineering ! Au sein de notre Centre d’Excellence Digital Foundation, nos équipes travaillent sur Kubernetes, OpenShift, Talos, Cluster API, GitOps, Infrastructure as Code, CI/CD, observabilité et automatisation pour transformer ces briques techniques en plateformes réellement exploitables par les équipes.

Sur un autre projet mené pour un acteur public, Inside a par exemple conçu une plateforme Kubernetes managée en local avec un portail self-service pour le provisionnement des environnements. Le dispositif a permis de diviser par trois le délai de mise à disposition des environnements tout en conservant les contraintes d’hébergement on-premise.

Ces projets donnent une autre lecture du débat K3s vs K8s. Une distribution plus légère peut supprimer une partie de la complexité technique. Une bonne plateforme doit, elle, supprimer la complexité inutile pour ceux qui la consomment.

En résumé : K3s est-il vraiment un Kubernetes plus léger ?

Oui, mais sa valeur ne vient pas uniquement de sa faible empreinte. K3s propose surtout une manière plus intégrée et plus opinionated de déployer Kubernetes.

Son binaire compact, SQLite pour les petits clusters, etcd embarqué pour la haute disponibilité, containerd, Flannel, Traefik, ServiceLB ou encore ses mécanismes d’installation air-gap réduisent le nombre de décisions nécessaires pour obtenir une plateforme fonctionnelle.

C’est particulièrement intéressant pour l’edge, les infrastructures distribuées, les environnements contraints, le développement ou les équipes souhaitant limiter la charge opérationnelle.

Pour autant, un Kubernetes plus léger ne dispense jamais d’une vraie architecture de production.

Le datastore, le stockage, le réseau, la sécurité, les sauvegardes, la haute disponibilité, l’observabilité et le cycle de mise à jour restent des choix structurants.

La bonne question n’est donc pas : « K3s est-il meilleur que Kubernetes ? » Elle est plutôt : « Quel niveau de complexité Kubernetes avons-nous réellement besoin d’exploiter pour répondre à notre contexte ? »

C’est cette question qui doit guider le choix de K3s, d’une autre distribution ou d’une plateforme Kubernetes plus largement industrialisée.

Pour aller plus loin

• Documentation officielle de K3s
• Repository officiel K3s et principes d’architecture
• Documentation K3s sur les datastores et la haute disponibilité
• Documentation Kubernetes sur la création d’un cluster avec kubeadm