Un pod qui redémarre perd tout ce qu’il n’a pas écrit ailleurs : c’est le contrat de base d’un conteneur. Un PersistentVolumeClaim promet un stockage qui survit à ce redémarrage, mais cette promesse ne se tient que si quelque chose sait réellement provisionner un volume derrière. Sur EKS, GKE ou AKS, le StorageClass par défaut déclenche ce provisionnement via l’API du cloud. Sur un cluster on-premise, sans ce provisioner, une PersistentVolumeClaim reste en Pending, exactement comme un Service LoadBalancer sans MetalLB.

Ce qu’un PVC demande réellement

Une PersistentVolumeClaim ne décrit pas un disque physique, mais un besoin : combien d’espace, avec quel mode d’accès (ReadWriteOnce pour un seul pod à la fois, ReadWriteMany pour plusieurs pods simultanément).

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

Le storageClassName référence le provisioner responsable de satisfaire cette demande. Sans provisioner correspondant installé sur le cluster, cette référence pointe vers rien, et le PVC attend indéfiniment.

Longhorn : répliquer le disque local plutôt que centraliser

Longhorn transforme le stockage local de chaque nœud en volumes distribués et répliqués, sans matériel de stockage partagé (SAN, NAS) à opérer séparément. Chaque volume Longhorn est répliqué sur plusieurs nœuds (trois par défaut) : la perte d’un nœud ne perd pas les données, une réplique existe ailleurs. Le composant longhorn-manager qui pilote cette réplication sur chaque nœud tourne, comme le speaker de MetalLB, en DaemonSet : présent partout où du stockage local doit être géré, sans exception.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn
provisioner: driver.longhorn.io
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880"

Cette approche évite une dépendance à du matériel de stockage centralisé, souvent absent ou vieillissant précisément dans les infrastructures legacy candidates à une migration Kubernetes. Le compromis : la réplication consomme de l’espace disque sur chaque nœud participant (trois répliques par défaut signifient trois fois l’espace utilisé), et la performance dépend directement du réseau entre nœuds, sur lequel transite chaque écriture répliquée.

La réplication n’est pas une sauvegarde

La confusion la plus fréquente et la plus coûteuse : trois répliques protègent contre la panne d’un nœud, pas contre une suppression accidentelle, une corruption applicative, ou un pod qui écrase ses propres données par erreur. Une suppression malheureuse se réplique tout aussi fidèlement que n’importe quelle autre écriture, sur les trois nœuds à la fois. Longhorn propose des snapshots et des sauvegardes vers un stockage objet externe (S3 ou compatible) précisément pour cette raison : la réplication répond à une question de disponibilité, la sauvegarde répond à une question de recouvrement après erreur, et confondre les deux est une découverte qu’on ne veut pas faire pendant un incident.

Ce qui décide si Longhorn est le bon choix

Longhorn convient à des volumes de taille modeste avec des exigences de performance raisonnables (bases de données de PME, files de messages, caches persistants) : le cas d’usage le plus fréquent d’une migration depuis des VM avec disques locaux. Une charge exigeant des performances I/O extrêmes ou des volumes très volumineux trouve généralement une meilleure réponse dans une solution de stockage distribué plus mature sur ce terrain spécifique (Rook/Ceph), au prix d’une complexité opérationnelle nettement supérieure. Le critère n’est pas « Longhorn est-il assez bon en absolu » mais « le volume et la charge visés dépassent-ils ce qu’une réplication à trois nœuds absorbe confortablement ».

À retenir

Un PersistentVolumeClaim qui reste en Pending sur un cluster on-premise signale l’absence d’un provisioner de stockage, exactement comme un Service LoadBalancer signale l’absence de MetalLB. Longhorn comble ce vide en répliquant le disque local de chaque nœud plutôt qu’en dépendant d’un stockage centralisé, à condition de ne jamais confondre cette réplication avec une sauvegarde. Ce socle de stockage se pose aux mêmes premières étapes qu’une migration Kubernetes depuis une infrastructure sur VM.