Skip to content Skip to sidebar Skip to footer

Dossier K3s : un Kubernetes (K8s) léger

Qu’est-ce que K3s ? Qui en est le concepteur ? Quelle est son utilité ?

K3s est une distribution de Kubernetes proposée par Rancher qui vise à permettre une intégration de Kubernetes sur des systèmes contraints (ressources limitées, isolées …).

Il est certifié par la CNCF –  Cloud Native Computing Foundation (ce qui signifie que des fichiers YAML peuvent théoriquement être transposés de K8s à K3s sans modification) et distribué par Rancher sous licence Apache V2 (donc largement redistribuable à des tiers et intégrable).

K3s est distribué sous la forme d’un binaire d’une cinquantaine de méga-octets, pour en arriver à ce résultat, Rancher a épuré la liste des fonctionnalités de K8s tout en conservant une implémentation complète de l’API.

Comment K3s arrive-t-il à être plus léger que K8s ?

K3s conserve les fonctionnalités essentielles de Kubernetes tout en supprimant ou remplaçant certains composants pour alléger le système. Par exemple, etcd, la base de données clé/valeur par défaut de Kubernetes, est remplacée par sqlite en configuration single-master, ou dqlite en multi-master pour les déploiements haute disponibilité. Ce choix permet une empreinte mémoire réduite, idéale pour des environnements contraints en ressources. K3s est ainsi plus léger que Kubernetes, autant sur le plan de la taille du binaire à déployer pour obtenir un cluster fonctionnel que sur le plan de l’empreinte mémoire. Concernant la réduction de la taille du binaire, comme spécifié sur le Github du projet, au fil du temps K3s a supprimé puis réintégré diverses fonctionnalités de Kubernetes.

A ce jour, la différence réside dans le fait que nativement, K3s n’est pas fourni avec les drivers de stockage et les drivers pour le déploiement sur du cloud.

Toutefois, ces éléments peuvent être, au besoin, et au cas par cas, réintégrés via l’installation de CSI (Container Storage Interface) et de CCM (Cloud Controller Manager).

La réduction de l’empreinte système est quant à elle atteinte en mutualisant l’exécution de différents composants dans un seul processus afin d’éviter le surcoût en terme de ressources lié à la multiplication des processus.

Que contient la distribution K3s ?

La distribution K3s contient :


icône puce bleue inside Containerd & runc
icône puce bleue inside Flannel en tant que CNI
icône puce bleue inside CoreDNS
icône puce bleue inside Metrics Server
icône puce bleue inside Traefik pour gérer les ingress
icône puce bleue inside Klipper-lb comme load-balancer intégré
icône puce bleue inside Kube-router pour la gestion des règles réseau
icône puce bleue inside Helm-controller pour le déploiement de chartes Helm
icône puce bleue inside Kine (pour Kine Is Not Etcd) qui permet de traduire l’API etcd en vue d’utiliser d’autres moteurs de BDD (sqlite, Postgres, Mysql, et dqlite)
icône puce bleue inside Local-path-provisioner pour provisionner des volumes sur du stockage local
icône puce bleue inside Host utilities iptables/nftables, ebtables, ethtool, & socat

Il est très important de remarquer que si ces éléments font partie de la distribution K3s, cette dernière n’est pas pour autant figée et ils peuvent être désactivés ou remplacés par d’autres.

Techniquement, en quoi est-il différent d’un Kubernetes ?

Comme vu précédemment, la différence avec Kubernetes est marquée par l’absence des drivers de stockage et cloud ainsi que par une empreinte mémoire plus faible du fait de la mutualisation des processus mais ce ne sont pas là les seules différences.

Ainsi la présence de Kine dans la distribution n’est pas anodine puisque K3s remplace etcd par sqlite (en mode single master) et dqlite (en mode multi master). Toutefois d’autres moteurs de base de données sont  supportés, à savoir Etcd3, MySQL et PostgreSQL.

De même, K3s est packagé en un seul binaire et n’a que très peu d’adhérence avec le système d’exploitation (un noyau sain et des montages cgroup).

K3s, contrairement à Kubernetes utilise un tunnel WebSocket pour exposer l’API kubelet au control panel , ce qui en pratique évite d’avoir à ouvrir un port spécifique sur les noeuds agent du cluster.

Par défaut, K3s est packagé avec containerd et runc, l’utilisation de Docker n’est pas proscrite mais nécessitera une installation supplémentaire (et aura un impact en terme de consommation de ressources).

Pourquoi utiliser K3s ?

K3s, du fait de sa faible empreinte système est particulièrement indiqué pour les systèmes disposant de peu de ressources, de plus, il est optimisé sur les architectures ARM64 et ARMv7 (ce qui n’empêche pas la présence d’une distribution x86_64).

Cela fait qu’il est particulièrement indiqué pour tout ce qui est IoT, Edge Computing, K8s embarqué, développement, déploiement sur des Single Board Computers (type Raspberry Pi, Odroid …) ou même test sur du Cloud (il peut fonctionner sur des machines disposant d’ un vCPU et 500 Mo de RAM).

La question de la mise en production d’un tel système se pose, le projet est clairement encore jeune (2 ans, première release au 14/07/2018) mais semble bénéficier d’un certain intérêt de la communauté (1700 contributeurs).

De plus, la release de la v 1.0.0 fin 2019 semble aller dans ce sens avec l’implémentation de la haute disponibilité (notamment le support de cluster multi-master).

Pour aller plus loin autour de Kubernetes k3s et k8s

En conclusion, que vous envisagiez un déploiement Kubernetes classique avec k8s ou que vous cherchiez une solution légère comme K3s pour des environnements spécifiques, le choix de la distribution dépendra de vos besoins en termes de ressources et de contraintes techniques. Pour discuter de la meilleure stratégie pour votre projet Kubernetes, contactez nos experts Inside, et découvrez comment nous pouvons vous accompagner dans l’adoption de K3s pour vos projets IoT, Edge Computing, ou tout autre déploiement critique.

Envie d’échanger avec des experts autour de ce sujet ou de vos enjeux de DevOps et d’infrastructures ?