Si l'API Server est la porte d'entrée d'un cluster Kubernetes, etcd en est la mémoire. Tout ce que contient le cluster — objets, configurations, secrets, état courant — y est stocké. C'est aussi le composant qui dicte le nombre de nœuds d'un cluster en haute disponibilité, et la raison pour laquelle « deux, c'est pire qu'un ».
Ce que c'est
etcd est une base de données clé-valeur distribuée, conçue pour stocker des données de configuration critiques. Ses caractéristiques :
- distribuée : plusieurs membres détiennent une copie complète des données ;
- fortement cohérente : une lecture renvoie toujours la dernière écriture confirmée — pas de « cohérence à terme » ;
- observable : un client peut s'abonner aux changements d'une clé. C'est précisément ce dont les contrôleurs Kubernetes ont besoin pour réagir immédiatement.
Dans Kubernetes, seul l'API Server parle à etcd. Aucun autre composant, aucun outil, aucun administrateur n'y accède directement en fonctionnement normal — c'est une règle d'or.
Le consensus, ou comment plusieurs machines se mettent d'accord
etcd utilise l'algorithme de consensus Raft. Le principe, réduit à l'essentiel :
- les membres élisent un leader ;
- toutes les écritures passent par lui ;
- il ne confirme une écriture au client qu'après l'avoir fait accepter par la majorité stricte des membres ;
- si le leader disparaît, les membres restants en élisent un nouveau — à condition d'être encore en majorité.
Cette exigence de majorité — le quorum — est ce qui garantit qu'on ne se retrouve jamais avec deux moitiés de cluster qui divergent chacune de leur côté.
Le quorum est la majorité stricte : avec trois membres, il en faut deux — d'où la tolérance à la perte d'un nœud.
L'arithmétique qui décide de votre architecture
- 1 membre : quorum de 1. Aucune tolérance à la panne.
- 2 membres : quorum de 2. Perdre une machine bloque les écritures — on a doublé le risque de panne sans rien gagner.
- 3 membres : quorum de 2. Tolère la perte d'un nœud. C'est le minimum utile, et la configuration du lab.
- 5 membres : quorum de 3. Tolère la perte de deux nœuds, au prix d'écritures un peu plus lentes.
D'où la règle : un nombre impair de membres, et rarement plus de cinq — au-delà, le coût du consensus dépasse le gain de disponibilité.
Ce que « quorum perdu » veut dire concrètement
Sur un cluster à trois nœuds dont deux sont tombés, le cluster ne s'efface pas : l'API passe en lecture seule. Les pods déjà lancés continuent de tourner, mais plus rien ne peut être créé, modifié ni réordonnancé. Le cluster est figé jusqu'au retour d'un second membre.
Ce comportement est volontaire. Accepter des écritures sans majorité produirait deux historiques divergents — le fameux split-brain — et une réconciliation impossible.
Les points d'attention en exploitation
- Le disque : etcd écrit son journal de façon synchrone. Une latence élevée provoque des élections de leader intempestives et des erreurs sporadiques de l'API. C'est de loin la première cause de cluster « lent » sans raison apparente.
- La sauvegarde : sauvegarder etcd, c'est sauvegarder tout le cluster. K3S sait produire des instantanés automatiques du datastore.
- Les secrets : par défaut, les objets Secret y sont stockés en base64, c'est-à-dire en clair. Le chiffrement au repos se configure explicitement.
- Les latences réseau : le consensus suppose des membres proches. Étaler un etcd entre deux sites distants est une mauvaise idée classique.
Dans K3S, tout ceci est déclenché par une seule option — --cluster-init — qui démarre l'etcd embarqué au lieu du SQLite mono-nœud. Le reste est automatique.
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é.
Les autres briques du lab
- Kubernetes et K3S
- etcd, la mémoire du cluster — vous y êtes
- L'Ingress
- Traefik
- MetalLB
- Longhorn
- Prometheus, Grafana et Helm