Kubernetes et K3S : ce que contient réellement un orchestrateur

Kubernetes Architecture Open Source

Kubernetes est devenu le vocabulaire commun de l'hébergement d'applications, au point qu'on l'emploie souvent sans savoir ce qu'il contient. Cette fiche décrit ce que fait réellement un cluster, quels composants s'en chargent, et ce que K3S change dans l'affaire.

Le problème que Kubernetes résout

Faire tourner un conteneur sur une machine est simple. Les difficultés arrivent ensuite : le redémarrer quand il meurt, le déplacer quand la machine tombe, lui donner une adresse stable alors qu'il change d'IP à chaque redémarrage, le mettre à jour sans coupure, lui attribuer du stockage qui le suive.

Kubernetes répond à tout cela par un principe unique : on ne donne pas d'ordres, on décrit un état voulu — « je veux trois exemplaires de cette image, exposés sur ce nom, avec ce volume » — et un ensemble de contrôleurs travaille en boucle pour que le réel corresponde à cette description. Un pod supprimé est recréé ; un nœud perdu voit ses charges réordonnancées ailleurs. Personne n'a rien demandé.

Les composants, et qui fait quoi

Composants d'un cluster Kubernetes

Le plan de contrôle décide, les composants de nœud exécutent — et K3S embarque tout cela dans un seul binaire.

Côté plan de contrôle :

l'API Server — la seule porte d'entrée du cluster. Tout passe par lui : kubectl, les contrôleurs, les nœuds eux-mêmes. C'est aussi le seul composant qui parle à etcd ;
le Scheduler — décide sur quel nœud placer un pod, en fonction des ressources demandées, des contraintes et de l'état des machines ;
le Controller Manager — un ensemble de boucles de réconciliation : contrôleur de déploiements, de nœuds, de services… chacune comparant sans cesse l'état voulu à l'état réel.

Sur chaque nœud :

kubelet — reçoit les pods qui lui sont assignés, demande au moteur de conteneurs de les démarrer, surveille leur santé et rend compte ;
containerd — le moteur de conteneurs. Il télécharge les images et exécute les conteneurs. Docker n'est plus nécessaire depuis longtemps ;
kube-proxy — programme les règles réseau qui font qu'une adresse de Service atteint effectivement les pods correspondants ;
CoreDNS — donne un nom à chaque service à l'intérieur du cluster.

Les objets qu'on manipule vraiment

Pod — l'unité d'exécution : un ou plusieurs conteneurs partageant réseau et volumes. On en crée rarement à la main.
Deployment — décrit combien d'exemplaires d'un pod doivent tourner, et gère les mises à jour progressives.
Service — une adresse interne stable devant un groupe de pods, avec répartition entre eux.
Ingress — les règles d'entrée HTTP depuis l'extérieur (fiche dédiée dans cette série).
PersistentVolumeClaim — une demande de stockage.
Namespace — un cloisonnement logique : les ressources d'une application ne voient pas celles d'une autre.
ConfigMap et Secret — la configuration et les données sensibles, séparées de l'image.

Ce que K3S change

K3S est une distribution Kubernetes certifiée conforme — même API, mêmes objets, mêmes comportements — packagée par Rancher en un binaire unique d'environ 70 Mo.

Ce qui a été retiré : les greffons d'anciens fournisseurs cloud, les pilotes de stockage historiques intégrés, du code de compatibilité obsolète. Ce qui a été ajouté : containerd, CoreDNS, un Ingress Controller (Traefik), un fournisseur de stockage local, un équilibreur simplifié, et un datastore SQLite en remplacement d'etcd pour les installations mono-nœud.

Résultat : une installation en une commande, une empreinte mémoire divisée par deux environ, et un service systemd unique à surveiller. Le « 3 » du nom fait référence à cet allègement.

Deux idées reçues à écarter. K3S n'est pas réservé à l'edge ou au Raspberry Pi : il fait tourner des charges de production sur des serveurs classiques. Et ce n'est pas un Kubernetes au rabais : ce que vous apprenez ici s'applique tel quel sur n'importe quel autre Kubernetes.

Quand ne pas en faire

Un point d'honnêteté : Kubernetes ajoute une couche de complexité qui doit être justifiée. Pour une application unique sur une machine unique, un conteneur derrière un reverse-proxy fait le travail avec un dixième du vocabulaire. L'orchestrateur devient rentable quand on veut plusieurs applications, la reprise automatique sur panne, et un mode de déploiement uniforme.

Voir la mise en pratique

Cette brique est installée et configurée pas à pas dans mon wiki, section Datacenter / Cluster K3S — la documentation de référence, avec les commandes et leurs sorties :

Et côté blog, l'étape correspondante du lab : Monter un lab Kubernetes chez soi (4) : le cluster K3S en haute disponibilité.