Kubernetes déplace les applications d'un nœud à l'autre sans prévenir. C'est sa qualité principale — et le problème central du stockage : une application déplacée doit retrouver ses données. Longhorn apporte cette garantie sans matériel dédié ni baie de stockage.
Le problème posé
Une application demande du stockage par un PersistentVolumeClaim. Un fournisseur de stockage répond en créant un volume. Le fournisseur par défaut d'un cluster léger crée un répertoire local sur le nœud : c'est rapide, simple, et cela cloue définitivement le pod à cette machine. Si le nœud tombe, l'application ne redémarre pas ailleurs — ou redémarre avec un disque vide, ce qui est pire.
Longhorn fournit à la place des volumes bloc répliqués sur plusieurs nœuds, avec instantanés et sauvegardes.
Comment c'est construit
Longhorn est un projet de la CNCF, initié par Rancher. Il s'installe dans le cluster, sous forme de pods, et se compose de :
- un manager sur chaque nœud, qui pilote volumes et réplicas ;
- un engine par volume : un processus dédié qui reçoit les écritures et les propage aux réplicas ;
- des réplicas, copies complètes des données réparties sur les nœuds ;
- un greffon CSI, l'interface standard par laquelle Kubernetes demande du stockage ;
- une interface web de supervision et d'administration.
Le volume est exposé au nœud via iSCSI — d'où le prérequis open-iscsi sur chaque machine, oublié une fois sur deux.
État du stockage : capacité, volumes sains, dégradés ou en reconstruction, et santé de chaque nœud.
La réplication, et son prix
Chaque écriture est envoyée simultanément à tous les réplicas et n'est confirmée que lorsqu'ils sont cohérents. Avec trois réplicas sur trois nœuds :
- la perte d'un nœud n'interrompt pas le service — les deux copies restantes suffisent ;
- Longhorn reconstruit automatiquement la troisième copie dès qu'un nœud redevient disponible ;
- un pod redémarré sur une autre machine retrouve ses données.
La contrepartie doit être connue : trois réplicas consomment trois fois l'espace, et la latence d'écriture est supérieure à celle d'un disque local, puisqu'une écriture n'est acquittée qu'après propagation. Sur une base de données très sollicitée, cela se mesure. Ce n'est pas un défaut, c'est le prix de la garantie.
Chaque volume, son état de santé et l'emplacement de ses réplicas sur les nœuds du cluster.
Les réglages qui évitent les ennuis
- Un disque dédié, pas le disque système. Laisser Longhorn stocker sur la partition racine, c'est accepter qu'un volume qui grossit finisse par saturer le système d'exploitation du nœud. On désactive l'ordonnancement sur le disque système et on déclare un second disque monté à part.
- Le nombre de réplicas par défaut doit correspondre au nombre de nœuds prêts à en accueillir — trois, ici.
- La politique de vidange des nœuds (Node Drain Policy) réglée pour refuser de vider un nœud qui porte la dernière copie d'un volume. Ce réglage discret est celui qui évite une perte de données pendant une maintenance de routine.
Instantané n'est pas sauvegarde
Un instantané fige l'état d'un volume à un moment donné. Il permet de revenir en arrière après une migration ratée ou une suppression malheureuse, et se restaure en réattachant le volume. Mais il vit dans le cluster : il ne protège ni de la destruction du cluster, ni de la perte du site.
Une sauvegarde exporte les données vers une cible externe — NFS ou compatible S3. C'est le seul mécanisme qui protège d'un sinistre, et il se teste avant d'en avoir besoin : une sauvegarde jamais restaurée n'est pas une sauvegarde.
Longhorn, Ceph ou NFS ?
- NFS : simple, permet l'accès partagé en écriture depuis plusieurs pods, mais introduit un point de défaillance unique — sauf à monter une infrastructure NFS hautement disponible, ce qui n'est plus simple du tout.
- Ceph (via Rook) : la solution de référence à grande échelle, très riche — bloc, fichier et objet — mais exigeante en ressources, en nœuds et en compétence.
- Longhorn : conçu pour Kubernetes, léger, administrable par une interface web, adapté de quelques nœuds à quelques dizaines. C'est le bon compromis pour un lab et pour beaucoup de petites infrastructures.
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 :
- 5. Mise en place du stockage persistant Longhorn
- 3. Installation des nœuds (préparation du disque de données)
Et côté blog, l'étape correspondante du lab : Monter un lab Kubernetes chez soi (5) : Longhorn, le stockage distribué.