C'est l'étape que tout le monde attend, et paradoxalement la plus courte : avec K3S, monter un cluster Kubernetes à trois nœuds en haute disponibilité demande trois commandes. Encore faut-il comprendre ce que chacune fait — et préparer correctement les machines.
K3S, Kubernetes en un binaire
K3S est une distribution Kubernetes certifiée, packagée par Rancher en un seul exécutable d'environ 70 Mo. Elle embarque tout ce qu'un cluster demande normalement d'assembler à la main : le moteur de conteneurs containerd, le DNS interne CoreDNS, un contrôleur d'entrée Traefik, un fournisseur de stockage local, et un datastore etcd embarqué.
Le « 3 » de K3S vient de là : c'est un Kubernetes allégé — la moitié de l'empreinte mémoire — obtenu en retirant les greffons d'anciens fournisseurs cloud et le code hérité. Ce n'est pas un Kubernetes au rabais : c'est le même Kubernetes, débarrassé de ce qui ne sert pas sur une infrastructure qu'on héberge soi-même.
Préparer les nœuds
Chaque nœud est une machine Ubuntu 24.04 avec deux disques. Trois points de préparation, tous nécessaires.
Adresse fixe et résolution
Les trois nœuds prennent des adresses fixes en 192.168.50.11, .12 et .13, avec la passerelle du lab comme routeur et comme serveur DNS. Un cluster dont les membres changent d'adresse au gré des baux DHCP est un cluster qui tombera un matin sans raison apparente.
Le second disque, préparé mais pas utilisé
parted /dev/vdb --script mklabel gpt mkpart primary ext4 0% 100% mkfs.ext4 /dev/vdb1 e2label /dev/vdb1 longhorn-data mkdir /opt/data
Le disque est monté sur /opt/data via /etc/fstab — de préférence par son UUID ou son label plutôt que par /dev/vdb1, l'ordre d'énumération des disques n'étant pas garanti d'un démarrage à l'autre. Ce volume restera vide jusqu'à l'installation de Longhorn.
Deux paquets
apt install -y curl ca-certificates
Le premier nœud initialise le cluster
curl -sfL https://get.k3s.io | sh -s - server \ --cluster-init \ --node-name kube-01 \ --tls-san 192.168.50.11
Trois options, trois rôles :
server: ce nœud fait partie du plan de contrôle (par opposition àagent, simple exécutant) ;--cluster-init: c'est l'option décisive. Elle démarre le datastore etcd embarqué en mode distribué, au lieu de la base SQLite mono-nœud utilisée par défaut. Sans elle, pas de haute disponibilité possible ensuite ;--tls-san: ajoute l'adresse IP au certificat de l'API, ce qui évite les erreurs de validation lorsqu'on s'y connecte autrement que par le nom.
Une minute plus tard, le cluster existe :
kubectl get nodes NAME STATUS ROLES AGE VERSION kube-01 Ready control-plane,etcd 2m5s v1.34.3+k3s1
Les deux autres rejoignent
Le premier nœud a généré un jeton d'adhésion :
cat /var/lib/rancher/k3s/server/node-token K10xxxxxxxxxxxxxxxx::server:xxxxxxxxxxxxxxxxxxxxxxxx
Ce jeton est un secret : il permet à n'importe quelle machine de rejoindre le plan de contrôle, donc de lire tout ce que contient le cluster. Il ne se met pas dans une documentation publique ni dans un dépôt — et s'il a fuité, on le régénère.
Sur kube-02 puis kube-03, la commande est la même à trois détails près :
curl -sfL https://get.k3s.io | sh -s - server \ --server https://192.168.50.11:6443 \ --token <le-jeton> \ --node-name kube-02 \ --tls-san 192.168.50.12
Noter le server conservé : les trois machines sont des nœuds de contrôle, pas de simples workers. C'est ce qui répartit le plan de contrôle et le datastore sur les trois.
Trois nœuds, trois rôles cumulés : plan de contrôle, datastore etcd et exécution des applications.
Ce que « haute disponibilité » veut dire ici
Les trois nœuds portent chacun un membre d'etcd, la base qui contient l'état du cluster. Etcd fonctionne au quorum : il lui faut la majorité stricte de ses membres pour accepter une écriture, soit deux sur trois.
Conséquences très concrètes :
- un nœud éteint, en panne ou en cours de mise à jour : le cluster continue, les applications qu'il portait sont réordonnancées ailleurs ;
- deux nœuds perdus : le quorum est rompu, l'API passe en lecture seule — le cluster ne se détruit pas, mais il n'accepte plus de changement ;
- c'est aussi pourquoi on monte trois nœuds et non deux : à deux membres, la majorité est de deux, et perdre une machine bloque tout. Deux nœuds sont moins disponibles qu'un seul.
Le nombre de membres etcd doit d'ailleurs rester impair — trois, cinq, sept — pour la même raison arithmétique.
Vérifier, puis éprouver
kubectl get nodes -o wide kubectl cluster-info kubectl get pods -n kube-system
Et surtout, la seule vérification qui vaille sur un lab : éteindre un nœud et regarder. Les pods qu'il hébergeait sont recréés ailleurs en quelques dizaines de secondes, l'API répond toujours, et le nœud revient dans le cluster à son redémarrage sans intervention. Tant qu'on n'a pas fait cette manipulation, la « haute disponibilité » reste une ligne dans un fichier de configuration.
Le pas à pas détaillé est sur le wiki
Cet article ne remplace pas la documentation : il en explique les choix. L'intégralité de la démarche — commandes, sorties d'écran, vérifications et captures — est publiée sur mon wiki, dans la section Datacenter / Cluster K3S. Pages correspondant à cet article :
La série « Lab Kubernetes maison »
Cet article fait partie d'une série qui monte, pas à pas, un cluster Kubernetes complet sur une seule machine physique :