Longhorn : stockage persistant distribué natif pour Kubernetes

Spoiler alert : si vous avez déjà essayé de gérer du stockage persistant sur Kubernetes, vous savez que c'est un peu comme assembler un meuble suédois sans notice. Longhorn change la donne en proposant une solution de stockage bloc distribué, cloud-native, pensée dès le départ pour Kubernetes. Projet CNCF incubé, maintenu par SUSE/Rancher, il s'installe en une commande Helm et offre réplication, snapshots, backups S3 et disaster recovery sans vous arracher les cheveux.

On ne va pas se mentir : le stockage dans Kubernetes, c'est le parent pauvre de l'écosystème. Les hostPath et local-path font le job en dev, mais en production, on a besoin de réplication, de snapshots et de backups. Longhorn répond à ces besoins avec une approche radicalement simple.

Chaque volume Longhorn est un contrôleur iSCSI indépendant avec ses propres réplicas distribués sur les nœuds du cluster. Pas de pool centralisé, pas de daemon monolithique : chaque volume vit sa vie. C'est comme si chaque conteneur avait son propre mini-SAN.

Les points forts en un coup d'œil :

• Réplication synchrone configurable (1 à 3 réplicas par défaut)
• Snapshots incrémentaux quasi instantanés
• Backups vers S3 ou NFS pour le disaster recovery
• UI web intégrée pour visualiser l'état des volumes
• Installation Helm en moins de 5 minutes

Avant de foncer tête baissée, vérifiez ces points :

• Cluster Kubernetes 1.25+ (K3s, RKE2, EKS, AKS, etc.)
• open-iscsi installé sur chaque nœud worker
• Au moins 3 nœuds pour une réplication correcte
• Disques ou partitions dédiés (recommandé, pas obligatoire)
• Helm 3 installé

# Vérifier que open-iscsi est bien présent
sudo systemctl status iscsid

# Si absent (Debian/Ubuntu)
sudo apt install -y open-iscsi
sudo systemctl enable --now iscsid

L'installation de Longhorn via Helm est d'une simplicité déconcertante :

helm repo add longhorn https://charts.longhorn.io
helm repo update

helm install longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --create-namespace \
  --set defaultSettings.defaultReplicaCount=3 \
  --set defaultSettings.defaultDataLocality=best-effort \
  --set defaultSettings.backupTarget="s3://longhorn-backups@eu-west-1/" \
  --set defaultSettings.backupTargetCredentialSecret=longhorn-s3-secret

Vérifiez que tout tourne :

kubectl -n longhorn-system get pods

Tous les pods doivent être en Running. Comptez environ 2 minutes pour un déploiement complet.

Accéder à l'UI web

Longhorn embarque une interface web accessible via un Service de type ClusterIP par défaut :

kubectl -n longhorn-system port-forward svc/longhorn-frontend 8080:80

Rendez-vous sur http://localhost:8080 pour visualiser vos volumes, nœuds et réplicas. En production, exposez-la via un Ingress avec authentification.

Longhorn crée automatiquement un StorageClass nommé longhorn. Utilisez-le dans vos PVC :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-postgres
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn
  resources:
    requests:
      storage: 20Gi

Pour définir Longhorn comme StorageClass par défaut :

kubectl patch storageclass longhorn \
  -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

Par défaut, Longhorn réplique chaque volume sur 3 nœuds distincts. Si un nœud tombe, les réplicas restants continuent de servir les données sans interruption.

Le paramètre dataLocality mérite qu'on s'y arrête :

• disabled : les réplicas sont placés n'importe où (défaut)
• best-effort : Longhorn tente de placer un réplica sur le nœud qui consomme le volume
• strict-local : le volume est exclusivement sur le nœud local (pas de réplication)

Pour les workloads sensibles à la latence (bases de données), best-effort est le bon compromis : une copie locale pour la performance, des réplicas distants pour la résilience.

Les snapshots Longhorn sont incrémentaux et ne consomment que l'espace des blocs modifiés. Créez-en manuellement ou automatisez-les :

apiVersion: longhorn.io/v1beta2
kind: RecurringJob
metadata:
  name: snapshot-every-hour
  namespace: longhorn-system
spec:
  cron: '0 * * * *'
  task: snapshot
  groups:
    - default
  retain: 24
  concurrency: 2

Ce RecurringJob prend un snapshot toutes les heures et conserve les 24 derniers. Pour restaurer un volume à partir d'un snapshot, passez par l'UI ou l'API Longhorn.

Spoiler alert : les snapshots ne suffisent pas. Si vous perdez le cluster entier, vos snapshots partent avec. Les backups Longhorn stockent les données hors cluster, sur un bucket S3 compatible (AWS S3, MinIO, Wasabi, etc.).

Configurer le secret S3

apiVersion: v1
kind: Secret
metadata:
  name: longhorn-s3-secret
  namespace: longhorn-system
type: Opaque
stringData:
  AWS_ACCESS_KEY_ID: 'votre-access-key'
  AWS_SECRET_ACCESS_KEY: 'votre-secret-key'
  AWS_ENDPOINTS: 'https://s3.eu-west-1.amazonaws.com'

Automatiser les backups

apiVersion: longhorn.io/v1beta2
kind: RecurringJob
metadata:
  name: backup-daily
  namespace: longhorn-system
spec:
  cron: '0 2 * * *'
  task: backup
  groups:
    - default
  retain: 7
  concurrency: 1

Un backup quotidien à 2h du matin, avec rétention de 7 jours. Combiné avec Velero pour les ressources Kubernetes elles-memes, vous avez une stratégie de DR solide.

Disaster recovery cross-cluster

Pour un vrai DR cross-cluster, la procédure est la suivante :

1. Le cluster principal pousse ses backups vers S3
2. Le cluster secondaire est configuré avec le meme backup target S3
3. En cas de sinistre, on restaure les volumes depuis les backups sur le cluster secondaire

C'est moins élégant qu'une réplication synchrone cross-cluster (que Longhorn ne propose pas nativement), mais c'est fonctionnel et éprouvé. Pour un RPO proche de zéro, combinez avec des backups fréquents.

Longhorn expose des métriques Prometheus nativement. Ajoutez un ServiceMonitor si vous utilisez l'opérateur Prometheus :

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: longhorn
  namespace: longhorn-system
spec:
  selector:
    matchLabels:
      app: longhorn-manager
  endpoints:
    - port: manager

Les métriques clés à surveiller :

• longhorn_volume_actual_size_bytes : espace réellement utilisé
• longhorn_volume_robustness : état de santé des réplicas
• longhorn_node_storage_capacity_bytes : capacité disponible par nœud

C'est LA question que tout le monde se pose. Voici un comparatif honnête :

Longhorn brille par sa simplicité et ses backups intégrés. C'est le choix idéal pour les clusters de petite et moyenne taille (moins de 20 nœuds) ou quand l'équipe n'a pas de spécialiste stockage.

Ceph/Rook est le poids lourd : multi-protocole, performances supérieures, scalabilité quasi illimitée. Mais le coût d'entrée est élevé en compétences et en ressources. Consultez notre guide Ceph pour un déploiement détaillé.

OpenEBS Mayastor se positionne entre les deux : meilleures performances que Longhorn grace à NVMe-oF, mais sans l'écosystème backup intégré.

Ma recommandation : commencez par Longhorn si vous débutez avec le stockage Kubernetes. Migrez vers Ceph/Rook quand vos besoins en performance ou en multi-protocole le justifient.

Quelques conseils pour un déploiement Longhorn serein :

1. Dédier des disques aux données Longhorn (pas le disque système)
2. Surveiller l'espace : Longhorn refuse de créer des volumes si l'espace disponible passe sous 25 %
3. Tester les restaurations régulièrement, pas juste les backups
4. Limiter le nombre de réplicas à 2 sur les clusters de 3 nœuds pour éviter la sur-réplication
5. Activer le node drain correctement : Longhorn migre les réplicas automatiquement si le PodDisruptionBudget est respecté

Pour un cluster hautement disponible, Longhorn s'intègre naturellement dans la stack : stockage répliqué, backups automatisés, restauration testée.

Longhorn ne révolutionne pas le stockage distribué, il le rend accessible. Là où Ceph demande des semaines de montée en compétence, Longhorn offre un stockage bloc répliqué, des snapshots et des backups S3 en quelques minutes. Pour la majorité des clusters Kubernetes en production, c'est exactement ce qu'il faut.

• Documentation officielle Longhorn 1.11
• Longhorn vs OpenEBS vs Rook-Ceph sur k3s en 2025
• Kubernetes Storage Comparison: Ceph, Longhorn, OpenEBS et GlusterFS