Un cluster Kubernetes sait redémarrer une application ailleurs quand un nœud tombe. Encore faut-il que les données suivent. Sans stockage partagé, une base de données déplacée sur un autre nœud retrouve un disque vide — ce qui, du point de vue de l'utilisateur, est indiscernable d'une perte de données. C'est le problème que résout Longhorn.
Le problème du stockage dans Kubernetes
Une application demande du stockage en déclarant un PersistentVolumeClaim : « il me faut 10 Gio ». Quelque chose doit répondre à cette demande en fournissant un volume. Sur un poste isolé, le fournisseur par défaut crée un répertoire local — simple, rapide, et attaché à un seul nœud. Le pod ne pourra plus jamais démarrer ailleurs.
Longhorn répond autrement : il crée un volume bloc répliqué sur plusieurs nœuds. Le pod peut démarrer sur n'importe quelle machine du cluster, ses données l'y attendent.
Ce qu'est Longhorn
Une solution de stockage bloc distribué, native Kubernetes, développée par Rancher et devenue projet de la CNCF. Elle s'installe dans le cluster, sous forme de pods, et ne demande ni matériel dédié ni serveur de stockage externe. Chaque nœud fournit un morceau de disque ; Longhorn se charge de la réplication, des instantanés et de la reconstruction.
Installation
Un prérequis souvent oublié : Longhorn expose ses volumes via le protocole iSCSI, donc chaque nœud doit disposer de l'initiateur correspondant.
apt install -y open-iscsi systemctl enable --now iscsid
Le déploiement lui-même tient en une commande :
kubectl create namespace longhorn-system kubectl apply -n longhorn-system \ -f https://raw.githubusercontent.com/longhorn/longhorn/v1.7.1/deploy/longhorn.yaml
Une trentaine de pods se déploient : les managers sur chaque nœud, les composants CSI qui font le lien avec Kubernetes, les gestionnaires d'instances, l'interface web. Il faut plusieurs minutes avant que tout passe en Running — c'est normal, et surveiller la progression est plus sain que de relancer la commande.
kubectl -n longhorn-system get pods
L'interface, et les trois réglages qui comptent
L'interface de Longhorn n'est pas exposée par défaut. Le temps de la configuration, une redirection de port suffit :
kubectl -n longhorn-system port-forward --address 0.0.0.0 svc/longhorn-frontend 8080:80
L'état du stockage en un écran : espace disponible, volumes sains, dégradés ou en reconstruction.
1. Retirer le disque système de l'ordonnancement
Par défaut, Longhorn propose de stocker les volumes sur le disque système du nœud. C'est exactement ce qu'il ne faut pas : un volume applicatif qui grossit finirait par remplir la partition racine et emporter le nœud. Sur chaque nœud, on désactive donc l'ordonnancement sur le disque système.
2. Déclarer le disque de données
On ajoute à la place le second disque, monté sur /opt/data — celui préparé lors de l'installation des nœuds. Type « File System », ordonnancement activé. À faire sur les trois machines.
3. Trois réplicas, et rien d'automatique
- Default Replica Count : 3 — chaque volume aura une copie complète sur chacun des trois nœuds ;
- Create Default Disk : désactivé — pour que Longhorn n'aille pas réutiliser le disque système d'un nouveau nœud ;
- Node Drain Policy : BlockIfContainsLastReplica — refuse de vider un nœud s'il porte la dernière copie d'un volume. Ce réglage, discret, est celui qui empêche de perdre des données pendant une maintenance.
Chaque volume, son état, sa taille et la répartition de ses trois réplicas sur les nœuds du cluster.
Ce que la réplication change vraiment
Une écriture applicative est propagée simultanément aux trois réplicas ; elle n'est confirmée que lorsque les copies sont cohérentes. En cas de perte d'un nœud, les deux réplicas restants assurent le service sans interruption, et Longhorn reconstruit automatiquement la troisième copie dès qu'un nœud redevient disponible.
Il faut en avoir conscience : cette garantie a un coût. Trois réplicas, c'est trois fois l'espace disque et une latence d'écriture supérieure à celle d'un disque local. Sur une base de données très sollicitée, ça se mesure. C'est un compromis, pas un repas gratuit.
Instantanés et sauvegardes : à ne pas confondre
Longhorn sait figer l'état d'un volume à un instant donné. Un instantané permet de revenir en arrière après une erreur applicative — une migration ratée, une suppression malheureuse — et se restaure en réattachant le volume, sans toucher au reste du cluster.
Mais un instantané vit dans le cluster. Il ne protège pas contre la perte du cluster lui-même. Pour cela, Longhorn sait exporter des sauvegardes vers une cible externe (NFS ou compatible S3) — et c'est un exercice à faire avant d'en avoir besoin, pas après.
Utiliser le stockage
Une fois en place, tout cela devient invisible : une application déclare simplement sa classe de stockage.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: wikijs-postgres-pvc
namespace: wikijs
spec:
accessModes: ["ReadWriteOnce"]
storageClassName: longhorn
resources:
requests:
storage: 10Gi
Le volume est créé, répliqué et attaché automatiquement. Et si le nœud qui l'héberge tombe, l'application redémarre ailleurs — avec ses données.
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 :