Stockage Longhorn pour les clusters de production k3s : extension, réplication et reprise après sinistre dynamiques PVC

est le problème le plus difficile de Kubernetes. Le calcul est apatride et fongible : tuez un pod, planifiez-en un autre. La mise en réseau dispose de plugins CNI et de maillages de services matures. Mais le stockage ? Le stockage est le lieu où réside l'état, où les données persistent après les redémarrages, où une seule mauvaise configuration peut entraîner une perte permanente de données. Pour les clusters k3s exécutant des charges de travail de production (bases de données, files d'attente de messages, état des applications), vous avez besoin d'une solution de stockage distribuée, résiliente, extensible et exploitable. Longhorn est cette solution.

Longhorn est un système de stockage par blocs distribué léger, fiable et facile à utiliser pour Kubernetes. Développé à l'origine par Rancher Labs (qui fait désormais partie de SUSE), il s'agit d'un projet d'incubation CNCF spécialement conçu pour les clusters où la simplicité compte mais où la fiabilité de la production n'est pas négociable. Contrairement à Ceph, qui nécessite des nœuds de stockage dédiés et une expertise approfondie, ou un provisionneur de chemin local, qui n'offre aucune redondance, Longhorn atteint l'équilibre exact dont les clusters k3s ont besoin : réplication distribuée sur les nœuds, expansion dynamique des volumes, sauvegarde intégrée sur le stockage d'objets cloud, instantané et reprise après sinistre, le tout géré via une interface utilisateur propre et des CRD natifs Kubernetes.

Ce guide couvre tout ce dont vous avez besoin pour déployer Longhorn sur k3s pour la production : composants internes de l'architecture, méthodes d'installation, configuration StorageClass, expansion dynamique de PVC, stratégies de réplication, sauvegarde et reprise après sinistre, chiffrement de volume, réglage des performances des bases de données, surveillance et dépannage. Chaque recommandation est accompagnée d'une configuration testée en production que vous pouvez adapter à votre environnement.

Architecture Longhorn

Comprendre l'architecture de Longhorn est essentiel pour prendre des décisions éclairées concernant la réplication, les performances et la gestion des pannes. Longhorn est composé de trois composants principaux qui fonctionnent ensemble pour fournir un stockage en bloc distribué au-dessus des disques locaux connectés à vos nœuds Kubernetes.

LeLonghorn Managers'exécute en tant que DaemonSet sur chaque nœud du cluster. Il s'agit du plan de contrôle de Longhorn : il gère les appels API, orchestre la création de volumes, gère la réplication, coordonne les instantanés et les sauvegardes et communique avec le serveur Kubernetes API pour gérer le cycle de vie de PersistentVolume et PersistentVolumeClaim. Lorsque vous créez un PVC qui fait référence à un Longhorn StorageClass, le Longhorn Manager reçoit la demande via le pilote CSI, provisionne le volume et planifie ses réplicas sur les nœuds disponibles.

Le moteur Longhornest un contrôleur de stockage par volume implémenté en tant que processus d'espace utilisateur Linux (basé sur un fork du moteur Rancher Longhorn). Chaque volume dispose de son propre processus de moteur dédié s'exécutant sur le nœud auquel le volume est connecté. Le moteur gère toutes les E/S de lecture et d'écriture pour ce volume, répliquant les écritures de manière synchrone sur toutes les répliques configurées avant d'accuser réception de l'écriture dans l'application. Cette architecture par volume signifie qu'un crash ou un blocage du moteur d'un volume n'affecte aucun autre volume — une propriété d'isolation essentielle pour la production.

Les répliquessont les véritables processus de stockage de données. Chaque réplica stocke une copie complète des données du volume sur le disque local du nœud sur lequel il s'exécute. Par défaut, Longhorn crée trois répliques pour chaque volume, réparties sur différents nœuds (et éventuellement différentes zones). Les répliques utilisent un mécanisme de copie sur écriture pour les instantanés, ce qui rend la création d'instantanés instantanée quelle que soit la taille du volume.

Cette architecture offre plusieurs propriétés clés pour une utilisation en production.Tolérance aux pannes :avec trois répliques sur trois nœuds, le volume survit à deux pannes de nœuds simultanées. Isolation:, chaque volume possède son propre processus moteur, de sorte qu'un bug ou un blocage dans un volume ne peut pas se répercuter. Simplicité du:pas de nœuds de stockage dédiés, pas de clusters Ceph ou GlusterFS séparés – Longhorn s'exécute sur les mêmes nœuds de travail que vos pods d'application, en utilisant leurs disques locaux.Kubernetes natif :tout est géré via CRDs, kubectl et l'interface Kubernetes CSI.

Installation de Longhorn sur k3s

Longhorn peut être installé sur k3s via trois méthodes : graphique Helm (recommandé pour la production), Rancher App Marketplace (si Rancher gère votre cluster) ou application directe de Kubectl. Avant l'installation, assurez-vous que vos nœuds répondent aux conditions préalables.

Conditions préalables

# Verify prerequisites on each node
# Required: open-iscsi (for iSCSI support)
sudo apt-get install -y open-iscsi
sudo systemctl enable iscsid
sudo systemctl start iscsid

# Required: NFSv4 client (for backup/restore to NFS targets)
sudo apt-get install -y nfs-common

# Recommended: check all prerequisites with Longhorn's environment check script
curl -sSfL https://raw.githubusercontent.com/longhorn/longhorn/v1.7.2/scripts/environment_check.sh | bash

# Verify kernel modules
lsmod | grep -E "iscsi_tcp|dm_crypt|nfs"

# On k3s specifically, local-path-provisioner is the default.
# We will make Longhorn the default StorageClass after installation.

via Helm (recommandé)

# Add the Longhorn Helm repository
helm repo add longhorn https://charts.longhorn.io
helm repo update

# Create the namespace
kubectl create namespace longhorn-system

# Install with production values
helm install longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --version 1.7.2 \
  --values longhorn-values.yaml

Voici unvalues.yamlde qualité production avec des paramètres par défaut réglés :

# longhorn-values.yaml — Production configuration
persistence:
  defaultClass: true
  defaultFsType: ext4
  defaultClassReplicaCount: 3
  defaultDataLocality: best-effort
  reclaimPolicy: Retain

defaultSettings:
  backupTarget: s3://longhorn-backups@eu-west-1/
  backupTargetCredentialSecret: longhorn-backup-s3-secret
  createDefaultDiskLabeledNodes: true
  defaultDataPath: /var/lib/longhorn/
  defaultReplicaCount: 3
  defaultDataLocality: best-effort
  replicaSoftAntiAffinity: false
  replicaAutoBalance: best-effort
  storageOverProvisioningPercentage: 150
  storageMinimalAvailablePercentage: 15
  guaranteedInstanceManagerCPU: 12
  upgradeChecker: false
  autoSalvage: true
  autoDeletePodWhenVolumeDetachedUnexpectedly: true
  disableSchedulingOnCordonedNode: true
  replicaZoneSoftAntiAffinity: true
  volumeAttachmentRecoveryPolicy: wait
  snapshotDataIntegrity: fast-check
  snapshotDataIntegrityCronjob: "0 7 * * *"
  concurrentAutomaticEngineUpgradePerNodeLimit: 1

longhornManager:
  priorityClass: system-cluster-critical
  tolerations:
    - key: "node-role.kubernetes.io/storage"
      operator: "Exists"
      effect: "NoSchedule"

longhornDriver:
  priorityClass: system-cluster-critical
  tolerations:
    - key: "node-role.kubernetes.io/storage"
      operator: "Exists"
      effect: "NoSchedule"

longhornUI:
  replicas: 2

ingress:
  enabled: true
  ingressClassName: nginx
  host: longhorn.internal.example.com
  tls: true
  tlsSecret: longhorn-tls
  annotations:
    nginx.ingress.kubernetes.io/auth-type: basic
    nginx.ingress.kubernetes.io/auth-secret: longhorn-basic-auth
    nginx.ingress.kubernetes.io/auth-realm: "Longhorn UI"

resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 100m
    memory: 128Mi

via le marché de l'application Rancher

Si Rancher gère votre cluster k3s, accédez aux applications et applications. Marché → Graphiques → Longhorndans l'interface utilisateur de Rancher. Sélectionnez votre espace de noms cible (longhorn-system), configurez les valeurs via l'interface du formulaire et cliquez sur Installer. Rancher gère automatiquement la gestion du cycle de vie du Helm et le suivi des mises à niveau.

via kubectl

# Direct manifest installation
kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.7.2/deploy/longhorn.yaml

# Verify all pods are running
kubectl -n longhorn-system get pods -w

: faire de Longhorn la classe de stockage par défaut

# Remove default annotation from k3s local-path
kubectl patch storageclass local-path -p '{"metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'

# Verify Longhorn is now default
kubectl get storageclass
# NAME                 PROVISIONER          RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
# longhorn (default)   driver.longhorn.io   Retain          Immediate           true                   5m
# local-path           rancher.io/local-path Delete         WaitForFirstConsumer false                 30d

pour la production

Le Longhorn StorageClass par défaut fonctionne pour le développement, mais les charges de travail de production nécessitent des configurations spécifiques pour différents cas d'utilisation : les bases de données nécessitent une réplication élevée et une localisation de données spécifique, le traitement temporaire nécessite des volumes rapides à réplique unique et les volumes partagés nécessitent la prise en charge de RWX.

# StorageClass for database workloads — maximum durability
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-db
  annotations:
    storageclass.kubernetes.io/is-default-class: "false"
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Retain
volumeBindingMode: Immediate
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880"
  fromBackup: ""
  fsType: ext4
  dataLocality: best-effort
  recurringJobSelector: '[{"name":"db-snapshot","isGroup":true},{"name":"db-backup","isGroup":true}]'
---
# StorageClass for general workloads — balanced
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-standard
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate
parameters:
  numberOfReplicas: "2"
  staleReplicaTimeout: "2880"
  fsType: ext4
  dataLocality: best-effort
---
# StorageClass for temporary/cache workloads — performance
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-fast
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate
parameters:
  numberOfReplicas: "1"
  staleReplicaTimeout: "2880"
  fsType: ext4
  dataLocality: strict-local
---
# StorageClass for RWX (ReadWriteMany) shared volumes
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-rwx
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Retain
volumeBindingMode: Immediate
parameters:
  numberOfReplicas: "3"
  nfsOptions: "vers=4.1,hard,timeo=50,retrans=3"
  staleReplicaTimeout: "2880"
  fsType: ext4

Extension dynamique PVC

L'une des fonctionnalités de production les plus importantes de Longhorn est l'expansion dynamique du PVC : la possibilité d'augmenter la taille d'un volume persistant sans temps d'arrêt, sans perte de données et sans intervention manuelle au-delà d'une seule commande kubectl ou d'un changement de manifeste. Ceci est essentiel pour les bases de données où la croissance des données est imprévisible et où un manque d’espace disque entraîne une panne.

Longhorn prend en charge à la fois l'extension en ligne(le volume reste attaché et monté pendant sa croissance) et l'extension hors ligne(le volume est détaché en premier). L'expansion en ligne est l'approche par défaut et recommandée pour la production, car elle évite les temps d'arrêt des applications.

Activation de l'expansion du volume dans StorageClass

La condition essentielle pour l'expansion dynamique du PVC est que la StorageClass doit avoirallowVolumeExpansion: true. La StorageClass par défaut de Longhorn l'inclut déjà, mais si vous disposez de StorageClasses personnalisées, vérifiez que ce champ est défini.

# Verify your StorageClass supports expansion
kubectl get storageclass longhorn -o yaml | grep allowVolumeExpansion
# allowVolumeExpansion: true

# If not set, patch it
kubectl patch storageclass longhorn -p '{"allowVolumeExpansion": true}'

étape par étape : extension dynamique d'un PVC

# 1. Check current PVC size
kubectl get pvc pg-data-postgresql-0 -n database
# NAME                    STATUS   VOLUME       CAPACITY   ACCESS MODES   STORAGECLASS   AGE
# pg-data-postgresql-0    Bound    pvc-abc123   50Gi       RWO            longhorn-db    30d

# 2. Check current usage inside the pod
kubectl exec -n database postgresql-0 -- df -h /var/lib/postgresql/data
# Filesystem      Size  Used Avail Use% Mounted on
# /dev/longhorn   49G   42G  7.0G  86% /var/lib/postgresql/data

# 3. Expand the PVC (online — no downtime)
kubectl patch pvc pg-data-postgresql-0 -n database --type merge -p '{
  "spec": {
    "resources": {
      "requests": {
        "storage": "100Gi"
      }
    }
  }
}'

# 4. Watch the expansion progress
kubectl get pvc pg-data-postgresql-0 -n database -w
# Wait for CAPACITY to update from 50Gi to 100Gi

# 5. Verify the filesystem expanded inside the pod
kubectl exec -n database postgresql-0 -- df -h /var/lib/postgresql/data
# Filesystem      Size  Used Avail Use% Mounted on
# /dev/longhorn   99G   42G   57G  43% /var/lib/postgresql/data

# 6. Verify via Longhorn volume status
kubectl -n longhorn-system get volumes.longhorn.io -o wide

Automatisation de l'extension PVC avec alertes

En production, vous ne devez pas attendre qu'un disque soit plein à 86 % pour l'étendre manuellement. Utilisez les alertes Prometheus pour déclencher automatiquement l’expansion ou alerter l’ingénieur de garde avant que la capacité ne devienne critique.

# PrometheusRule for PVC capacity alerts
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: pvc-capacity-alerts
  namespace: monitoring
spec:
  groups:
    - name: pvc-capacity
      rules:
        - alert: PVCCapacityWarning
          expr: |
            (kubelet_volume_stats_used_bytes / kubelet_volume_stats_capacity_bytes) > 0.80
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "PVC {{ $labels.persistentvolumeclaim }} at {{ $value | humanizePercentage }} capacity"
            runbook: "Expand the PVC using: kubectl patch pvc {{ $labels.persistentvolumeclaim }} -n {{ $labels.namespace }} --type merge -p '{\"spec\":{\"resources\":{\"requests\":{\"storage\":\"NEW_SIZE\"}}}}'"
        - alert: PVCCapacityCritical
          expr: |
            (kubelet_volume_stats_used_bytes / kubelet_volume_stats_capacity_bytes) > 0.90
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "CRITICAL: PVC {{ $labels.persistentvolumeclaim }} at {{ $value | humanizePercentage }}"
            description: "Immediate expansion required to prevent application failure"

Réplication de volume et localisation des données

Longhorn réplique les données de volume sur plusieurs nœuds pour se protéger contre les pannes matérielles. Le facteur de réplication et les paramètres de localisation des données contrôlent le compromis entre durabilité, performances et efficacité du stockage.

Facteur de réplicationdétermine le nombre de copies des données existantes. La valeur par défaut est 3, ce qui signifie que chaque écriture est stockée sur trois nœuds différents. Pour les bases de données de production, 3 est la valeur minimale recommandée. Vous pouvez le définir sur 2 pour les charges de travail moins critiques afin d'économiser du stockage, ou le laisser sur 1 pour les volumes temporaires/de cache où la perte de données est acceptable.

Localité des donnéescontrôle si Longhorn essaie de conserver une réplique sur le même nœud que le pod consommant le volume. Il existe trois modes :

• désactivé— Les répliques sont planifiées uniquement en fonction de l'espace disponible et de l'anti-affinité. Le pod peut lire à partir d'une réplique sur un nœud distant, ajoutant ainsi une latence réseau à chaque opération d'E/S.
• au mieux— Longhorn essaie de placer une réplique sur le même nœud que le pod consommateur. Si le nœud local manque d'espace ou si le pod migre, le volume fonctionne toujours mais peut avoir une latence légèrement plus élevée. Il s'agit du paramètre recommandé pour la plupart des charges de travail.
• strict-local— Le volume ne peut être utilisé que sur un nœud doté d'une réplique locale. Si le pod est planifié sur un nœud sans réplica local, l'attachement du volume échoue. Utilisez-le uniquement pour les charges de travail à réplica unique sensibles à la latence pour lesquelles vous acceptez le compromis en matière de durabilité.

# Change replication factor on an existing volume
kubectl -n longhorn-system patch volumes.longhorn.io pvc-abc123 \
  --type merge -p '{"spec":{"numberOfReplicas":3}}'

# Set data locality on existing volume
kubectl -n longhorn-system patch volumes.longhorn.io pvc-abc123 \
  --type merge -p '{"spec":{"dataLocality":"best-effort"}}'

# Replica auto-balancing (spreads replicas evenly across nodes)
# Set via Longhorn settings
kubectl -n longhorn-system edit settings.longhorn.io replica-auto-balance
# Set value to: best-effort

Instantanés et sauvegardes

Longhorn fournit deux mécanismes de protection des données distincts : les instantanés(locaux, instantanés, pour une restauration rapide) et les sauvegardes(à distance, vers le stockage objet, pour la reprise après sinistre). Comprendre quand utiliser chacun est essentiel.

sont stockés localement sur les mêmes disques que les répliques de volume. Ils sont créés instantanément à l'aide de la copie sur écriture : aucune donnée n'est copiée au moment de l'instantané, seules les nouvelles écritures après l'instantané allouent de l'espace supplémentaire. Les instantanés sont excellents pour une restauration rapide avant une migration ou un déploiement risqué, mais ils ne protègent pas contre les pannes de nœuds ou de disques car ils résident sur le même stockage que le volume.

copient les données du volume vers une cible de sauvegarde externe : S3, GCS, Azure Blob ou tout magasin compatible S3 (MinIO, Wasabi). Les sauvegardes sont incrémentielles au niveau des blocs : seuls les blocs modifiés depuis la dernière sauvegarde sont transférés. Cela rend les sauvegardes récurrentes rapides et efficaces en matière de stockage. Les sauvegardes protègent contre la perte totale du cluster car elles existent indépendamment.

Configuration de la cible de sauvegarde

# Create the S3 credentials secret
kubectl create secret generic longhorn-backup-s3-secret \
  -n longhorn-system \
  --from-literal=AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE \
  --from-literal=AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY \
  --from-literal=AWS_ENDPOINTS=https://s3.eu-west-1.amazonaws.com

# Set the backup target in Longhorn settings
kubectl -n longhorn-system edit settings.longhorn.io backup-target
# Set value to: s3://longhorn-backups@eu-west-1/

kubectl -n longhorn-system edit settings.longhorn.io backup-target-credential-secret
# Set value to: longhorn-backup-s3-secret

# For GCS backup target
# value: s3://longhorn-backups@us/  (GCS is S3-compatible via interop)
# Or use the GCS JSON key:
kubectl create secret generic longhorn-backup-gcs-secret \
  -n longhorn-system \
  --from-literal=GOOGLE_APPLICATION_CREDENTIALS=/var/longhorn-backup/gcs-key.json \
  --from-file=gcs-key.json=./service-account-key.json

# For Azure Blob backup target
kubectl create secret generic longhorn-backup-azure-secret \
  -n longhorn-system \
  --from-literal=AZBLOB_ACCOUNT_NAME=prodbackupstorage \
  --from-literal=AZBLOB_ACCOUNT_KEY=base64encodedkeyhere

Classe VolumeSnapshot et instantané YAML

# VolumeSnapshotClass for Longhorn
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: longhorn-snapshot-vsc
driver: driver.longhorn.io
deletionPolicy: Delete
parameters:
  type: snap
---
# Create a VolumeSnapshot
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: pg-data-snap-before-migration
  namespace: database
spec:
  volumeSnapshotClassName: longhorn-snapshot-vsc
  source:
    persistentVolumeClaimName: pg-data-postgresql-0
---
# Restore a PVC from a snapshot
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pg-data-restored
  namespace: database
spec:
  storageClassName: longhorn-db
  dataSource:
    name: pg-data-snap-before-migration
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi

Planifications de sauvegarde récurrentes

# Recurring snapshot job — every 4 hours, retain 6
apiVersion: longhorn.io/v1beta2
kind: RecurringJob
metadata:
  name: db-snapshot-4h
  namespace: longhorn-system
spec:
  cron: "0 */4 * * *"
  task: snapshot
  retain: 6
  concurrency: 2
  groups:
    - db-volumes
  labels:
    tier: database
---
# Recurring backup job — daily at 02:00, retain 14 days
apiVersion: longhorn.io/v1beta2
kind: RecurringJob
metadata:
  name: db-backup-daily
  namespace: longhorn-system
spec:
  cron: "0 2 * * *"
  task: backup
  retain: 14
  concurrency: 2
  groups:
    - db-volumes
  labels:
    tier: database
---
# Recurring backup job — weekly full, retain 8 weeks
apiVersion: longhorn.io/v1beta2
kind: RecurringJob
metadata:
  name: db-backup-weekly
  namespace: longhorn-system
spec:
  cron: "0 3 * * 0"
  task: backup
  retain: 8
  concurrency: 1
  groups:
    - db-volumes
  labels:
    tier: database
---
# Assign recurring jobs to a volume via labels
# Label the PVC or volume with: recurring-job-group.longhorn.io/db-volumes: enabled
kubectl label pvc pg-data-postgresql-0 -n database \
  recurring-job-group.longhorn.io/db-volumes=enabled

Reprise après sinistre

Longhorn fournit un mécanisme intégré de reprise après sinistre via les volumesDR— des volumes de secours dans un cluster secondaire qui extraient en permanence des sauvegardes incrémentielles à partir de la cible de sauvegarde du cluster principal. En cas de sinistre, vous activez le volume DR et il devient un volume en lecture-écriture standard, laissant le cluster secondaire prendre le relais.

Configuration des volumes DR

# On the DR cluster: create a DR volume from the primary's backup
# This is done via the Longhorn UI or API

# 1. Configure the DR cluster's backup target to point to the same S3 bucket
kubectl -n longhorn-system edit settings.longhorn.io backup-target
# value: s3://longhorn-backups@eu-west-1/

# 2. Create a DR volume from the latest backup
# Via Longhorn UI: Backup → Select volume → Create DR Volume
# Via kubectl:
apiVersion: longhorn.io/v1beta2
kind: Volume
metadata:
  name: pg-data-dr
  namespace: longhorn-system
spec:
  size: "107374182400"  # 100Gi in bytes
  numberOfReplicas: 3
  fromBackup: "s3://longhorn-backups@eu-west-1/?backup=backup-abc123&volume=pg-data"
  standby: true
  frontend: ""

# 3. The DR volume auto-syncs incremental backups from S3
# Monitor sync status:
kubectl -n longhorn-system get volumes.longhorn.io pg-data-dr -o jsonpath='{.status.lastBackup}'

# 4. During failover — activate the DR volume:
kubectl -n longhorn-system patch volumes.longhorn.io pg-data-dr \
  --type merge -p '{"spec":{"standby":false,"frontend":"blockdev"}}'

# 5. Create a PVC bound to the activated DR volume
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pg-data-postgresql-0
  namespace: database
spec:
  storageClassName: longhorn-db
  volumeName: pg-data-dr
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi

Chiffrement de volumes

Longhorn prend en charge le chiffrement au niveau du volume à l'aide de Linux LUKS2. Les volumes chiffrés protègent les données au repos sur le disque sous-jacent : même si quelqu'un accède physiquement au stockage du serveur, il ne peut pas lire les données du volume sans la clé de chiffrement.

# Create a Kubernetes secret with the encryption passphrase
kubectl create secret generic longhorn-crypto \
  -n longhorn-system \
  --from-literal=CRYPTO_KEY_VALUE="a-very-long-and-random-passphrase-here" \
  --from-literal=CRYPTO_KEY_PROVIDER=secret \
  --from-literal=CRYPTO_KEY_CIPHER=aes-xts-plain64 \
  --from-literal=CRYPTO_KEY_HASH=sha256 \
  --from-literal=CRYPTO_KEY_SIZE=256 \
  --from-literal=CRYPTO_PBKDF=argon2i

# StorageClass with encryption enabled
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-encrypted
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Retain
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880"
  fromBackup: ""
  encrypted: "true"
  csi.storage.k8s.io/provisioner-secret-name: longhorn-crypto
  csi.storage.k8s.io/provisioner-secret-namespace: longhorn-system
  csi.storage.k8s.io/node-publish-secret-name: longhorn-crypto
  csi.storage.k8s.io/node-publish-secret-namespace: longhorn-system
  csi.storage.k8s.io/node-stage-secret-name: longhorn-crypto
  csi.storage.k8s.io/node-stage-secret-namespace: longhorn-system

ReadWriteMany (RWX) prend en charge

Par défaut, les volumes Longhorn sont ReadWriteOnce (RWO) : ils peuvent être montés par un seul pod sur un seul nœud. Pour les charges de travail nécessitant un stockage partagé sur plusieurs modules (par exemple, téléchargements de médias partagés, fichiers de configuration, artefacts de modèle ML), Longhorn prend en charge ReadWriteMany (RWX) via un serveur NFS intégré.

Lorsqu'un PVC demande le mode d'accès RWX, Longhorn déploie automatiquement un module de gestion de partage qui exécute un serveur NFS soutenu par le volume Longhorn. Plusieurs pods peuvent ensuite monter le volume simultanément via NFS. C'est plus simple que de déployer un serveur NFS distinct, mais cela ajoute une couche de surcharge réseau par rapport à l'accès direct par bloc.

# PVC with ReadWriteMany access mode
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: shared-media
  namespace: application
spec:
  storageClassName: longhorn-rwx
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 50Gi

sur Longhorn

L'exécution de bases de données sur Longhorn nécessite une attention particulière aux paramètres StorageClass, à l'affinité des pods et à l'intégration des sauvegardes. Le moteur par volume et la réplication synchrone de Longhorn le rendent bien adapté aux charges de travail de bases de données, mais vous devez le configurer correctement pour obtenir des performances et une fiabilité de niveau production.

PostgreSQL StatefulSet avec Longhorn

# PostgreSQL StatefulSet using Longhorn PVC
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgresql
  namespace: database
spec:
  serviceName: postgresql
  replicas: 3
  selector:
    matchLabels:
      app: postgresql
  template:
    metadata:
      labels:
        app: postgresql
    spec:
      terminationGracePeriodSeconds: 120
      securityContext:
        fsGroup: 999
        runAsUser: 999
      containers:
        - name: postgresql
          image: postgres:16-alpine
          ports:
            - containerPort: 5432
          env:
            - name: POSTGRES_DB
              value: production
            - name: POSTGRES_USER
              valueFrom:
                secretKeyRef:
                  name: pg-credentials
                  key: username
            - name: POSTGRES_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: pg-credentials
                  key: password
            - name: PGDATA
              value: /var/lib/postgresql/data/pgdata
          resources:
            requests:
              cpu: "1"
              memory: 2Gi
            limits:
              cpu: "4"
              memory: 8Gi
          volumeMounts:
            - name: pg-data
              mountPath: /var/lib/postgresql/data
          livenessProbe:
            exec:
              command: ["pg_isready", "-U", "$(POSTGRES_USER)"]
            initialDelaySeconds: 30
            periodSeconds: 10
          readinessProbe:
            exec:
              command: ["pg_isready", "-U", "$(POSTGRES_USER)"]
            initialDelaySeconds: 5
            periodSeconds: 5
  volumeClaimTemplates:
    - metadata:
        name: pg-data
        labels:
          recurring-job-group.longhorn.io/db-volumes: enabled
      spec:
        storageClassName: longhorn-db
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 100Gi

MySQL StatefulSet avec Longhorn

# MySQL StatefulSet using Longhorn PVC
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
  namespace: database
spec:
  serviceName: mysql
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      terminationGracePeriodSeconds: 60
      containers:
        - name: mysql
          image: mysql:8.0
          ports:
            - containerPort: 3306
          env:
            - name: MYSQL_ROOT_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: mysql-credentials
                  key: root-password
            - name: MYSQL_DATABASE
              value: production
          args:
            - "--default-authentication-plugin=mysql_native_password"
            - "--innodb-buffer-pool-size=4G"
            - "--innodb-log-file-size=1G"
            - "--innodb-flush-log-at-trx-commit=1"
            - "--sync-binlog=1"
          resources:
            requests:
              cpu: "1"
              memory: 4Gi
            limits:
              cpu: "4"
              memory: 8Gi
          volumeMounts:
            - name: mysql-data
              mountPath: /var/lib/mysql
  volumeClaimTemplates:
    - metadata:
        name: mysql-data
        labels:
          recurring-job-group.longhorn.io/db-volumes: enabled
      spec:
        storageClassName: longhorn-db
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 200Gi

Optimisation des performances pour les charges de travail de bases de données

Longhorn ajoute une couche de réplication de stockage entre l'application et le disque physique, ce qui introduit une certaine latence par rapport à l'accès direct au disque local. Pour la plupart des charges de travail, cette surcharge est négligeable, mais les charges de travail de bases de données avec des modèles d'écriture lourds doivent être ajustées pour obtenir des performances optimales.

Utiliser la localité des données : au mieux.Cela garantit qu'une réplique se trouve sur le même nœud que le pod de base de données, ce qui signifie que les lectures atteignent le disque local à la vitesse NVMe/SSD. Les écritures sont toujours répliquées sur les nœuds distants, mais la réplique locale élimine les allers-retours réseau pour les lectures.

Dédiez des disques à Longhorn.Ne partagez pas le disque du système d'exploitation avec les données Longhorn. Ajoutez des disques NVMe ou SSD dédiés et configurez-les en tant que disques Longhorn. Cela évite les conflits d'E/S entre le système d'exploitation et les volumes de base de données.

# Configure dedicated disks on a node
# Via kubectl (Longhorn node CRD)
kubectl -n longhorn-system edit nodes.longhorn.io worker-01

# Add the dedicated disk under spec.disks:
spec:
  disks:
    default-disk:
      allowScheduling: false  # disable OS disk for Longhorn
      path: /var/lib/longhorn/
      storageReserved: 0
    nvme-data:
      allowScheduling: true
      path: /mnt/nvme-longhorn/
      storageReserved: 10737418240  # 10Gi reserved
      tags:
        - nvme
        - database

Set gestionnaire moteur garanti CPU. Les processus du moteurLonghorn consomment CPU pour le traitement des E/S et la réplication. Le paramètreguaranteedInstanceManagerCPUréserve un pourcentage du nœud CPU aux gestionnaires d'instances Longhorn, empêchant ainsi la famine CPU sous charge.

Ajustez le nombre de répliques.Pour les bases de données qui disposent déjà d'une réplication au niveau de l'application (réplication en streaming PostgreSQL, réplication de groupe MySQL, jeux de réplicas MongoDB), vous pouvez réduire le nombre de réplicas Longhorn à 2 au lieu de 3. La réplication de la base de données fournit une couche supplémentaire de protection des données, et moins de réplicas Longhorn signifie moins d'amplification d'écriture et un meilleur débit d'écriture.

Utilisez ext4 sur xfs pour les petites E/S aléatoires.Alors que xfs excelle dans les écritures séquentielles volumineuses, ext4 fonctionne généralement mieux pour les petits modèles d'E/S aléatoires typiques des charges de travail de bases de données. DéfinissezfsType: ext4dans votre StorageClass.

Planification des nœuds et gestion des disques

Longhorn offre un contrôle précis sur les nœuds et les disques utilisés pour la planification des volumes. Ceci est essentiel dans les clusters hétérogènes où certains nœuds disposent d'un stockage NVMe rapide et d'autres ont des disques SATA plus lents.

# Tag nodes for storage scheduling
kubectl label node worker-01 node.longhorn.io/storage=nvme
kubectl label node worker-02 node.longhorn.io/storage=nvme
kubectl label node worker-03 node.longhorn.io/storage=nvme
kubectl label node worker-04 node.longhorn.io/storage=sata

# Use node selector in StorageClass to target NVMe nodes
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-nvme
provisioner: driver.longhorn.io
allowVolumeExpansion: true
parameters:
  numberOfReplicas: "3"
  nodeSelector: "node.longhorn.io/storage=nvme"
  diskSelector: "nvme,database"
  dataLocality: best-effort

avec Prometheus et Grafana

Longhorn expose les métriques Prometheus via un point de terminaison de métriques intégré. La surveillance de ces mesures est essentielle pour la planification des capacités, l'analyse des performances et les alertes proactives.

# ServiceMonitor for Longhorn metrics
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: longhorn-prometheus
  namespace: monitoring
  labels:
    release: prometheus
spec:
  selector:
    matchLabels:
      app: longhorn-manager
  namespaceSelector:
    matchNames:
      - longhorn-system
  endpoints:
    - port: manager
      path: /metrics
      interval: 30s
---
# PrometheusRule for Longhorn alerts
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: longhorn-alerts
  namespace: monitoring
spec:
  groups:
    - name: longhorn-storage
      rules:
        - alert: LonghornVolumeStatusCritical
          expr: longhorn_volume_robustness == 3
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "Longhorn volume {{ $labels.volume }} is Faulted"
        - alert: LonghornVolumeStatusDegraded
          expr: longhorn_volume_robustness == 2
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "Longhorn volume {{ $labels.volume }} is Degraded"
        - alert: LonghornNodeStorageWarning
          expr: |
            (longhorn_node_storage_usage_bytes / longhorn_node_storage_capacity_bytes) > 0.80
          for: 15m
          labels:
            severity: warning
          annotations:
            summary: "Longhorn node {{ $labels.node }} storage at {{ $value | humanizePercentage }}"
        - alert: LonghornBackupFailed
          expr: longhorn_backup_state == 3
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "Longhorn backup failed for volume {{ $labels.volume }}"

Cluster k3s avec pile de stockage complète Longhorn

Le diagramme suivant montre comment Longhorn s'intègre dans une pile de production k3s complète, des serveurs nus jusqu'aux modules d'applications, avec gestion Rancher et observabilité Prometheus/Grafana.

avec d'autres solutions de stockage Kubernetes

Longhorn n'est pas la seule option de stockage pour Kubernetes. Comprendre comment cela se compare aux alternatives vous aide à faire le bon choix pour vos besoins spécifiques.

Longhorn vs Rook-Ceph :Ceph est le système le plus puissant : il prend en charge le stockage d'objets, le stockage de fichiers et le stockage de blocs avec un algorithme de placement CRUSH sophistiqué. Cependant, Ceph nécessite au moins 3 nœuds OSD dédiés, une RAM importante (minimum 4 Go par démon OSD) et une expertise opérationnelle approfondie. Pour les clusters k3s comportant 3 à 10 nœuds, Longhorn fournit 90 % de la valeur à 10 % du coût opérationnel.

Longhorn vs OpenEBS Mayastor :Mayastor utilise NVMe-over-Fabrics pour une réplication hautes performances, obtenant une latence inférieure à celle de la réplication basée sur TCP de Longhorn. Si les IOPS brutes et la latence inférieure à la milliseconde sont votre principale préoccupation et que vous disposez d'une infrastructure NVMe avec réseau RDMA, Mayastor peut être le meilleur choix. Pour la plupart des déploiements k3s, la sauvegarde intégrée, la reprise après sinistre et la simplicité opérationnelle de Longhorn l'emportent sur les performances de Mayastor.

Longhorn vs chemin local : le fournisseur de chemin localest le stockage par défaut du k3s : il crée simplement des répertoires sur le système de fichiers local du nœud. Zéro réplication, zéro instantané, zéro intégration de sauvegarde. C'est bien pour le développement mais inacceptable pour les données de production.

Meilleures pratiques de production

Ces recommandations sont issues de l'exploitation de Longhorn sur des dizaines de clusters de production k3s exécutant des charges de travail de base de données.

1. Définissez les réservations de ressources pour les gestionnaires d'instance. Les gestionnaires d'instancesLonghorn (gestionnaires de moteurs et de réplicas) ont besoin d'un CPU garanti pour éviter les blocages d'E/S pendant la pression des nœuds. RéglezguaranteedInstanceManagerCPUsur au moins 12 % dans les paramètres Longhorn.

2. Utilisez la stratégie de récupération Conserver pour les volumes de base de données.N'utilisez jamaisDeletepour la base de données PVC. Une politiqueRetainconserve le PV et ses données même après la suppression du PVC, vous offrant ainsi un filet de sécurité contre toute suppression accidentelle.

3. Désactivez l'anti-affinité logicielle de la réplique pour la production.DéfinissezreplicaSoftAntiAffinity: falsepour garantir que les réplicas sont toujours répartis sur différents nœuds. Avec l'anti-affinité douce, Longhorn peut planifier plusieurs répliques sur le même nœud lorsque l'espace est restreint, ce qui va à l'encontre de l'objectif de la réplication.

4. Réservez de l'espace de stockage sur chaque nœud.RéglezstorageMinimalAvailablePercentagesur au moins 15 %. Cela empêche Longhorn de consommer tout l'espace disque, ce qui entraînerait des problèmes au niveau des nœuds affectant tous les pods.

5. Activez la récupération automatique.Le paramètreautoSalvagerécupère automatiquement les volumes qui entrent dans un état défectueux lorsqu'au moins une réplique est encore saine. Cela réduit les interventions manuelles en cas de pannes de nœuds.

6. Définissez la classe de priorité sur critique du cluster système. Les composants du gestionnaire et du pilote duLonghorn ne doivent jamais être évincés pendant la pression du nœud. Définissez leur prioritéClass sursystem-cluster-criticalpour garantir qu'ils survivent à l'expulsion du pod.

7. Configurez les tâches récurrentes pour tous les volumes de production.Chaque volume de production doit comporter des tâches récurrentes d'instantanés et de sauvegarde. Instantanés toutes les 4 heures pour une restauration rapide, sauvegardes quotidiennes pour la reprise après sinistre.

8. Testez régulièrement l'activation du volume DR.Créez un planning mensuel pour activer les volumes DR dans votre cluster de secours, vérifier l'intégrité des données et pratiquer la procédure de basculement. Un plan de reprise après sinistre qui n'a jamais été testé n'est qu'une simple documentation.

9. Surveillez l'état du volume de manière proactive.Configurez des alertes Prometheus pour les volumes dégradés et défaillants, la capacité de stockage des nœuds, l'âge de la sauvegarde et l'état de reconstruction du réplica. Au moment où un utilisateur signale une base de données lente, le problème de stockage s'accumule depuis des heures.

10. Utilisez des disques de stockage dédiés.Séparez les données Longhorn du disque du système d'exploitation. Cela évite les conflits d'E/S, vous offre une gestion plus propre de la capacité et évite le risque de remplir le disque du système d'exploitation avec des données Longhorn.

Guide de déploiement spécifique au cloud

AWS — EC2 avec stockage d'instance NVMe

Pour les déploiements AWS, utilisez les instancesi3.xlargeoui3en.xlargefournies avec le stockage d'instance NVMe. Ceux-ci fournissent des performances NVMe brutes à une fraction du coût des IOPS EBS provisionnées. Formatez le stockage de l'instance et configurez-le en tant que disque Longhorn.

# On each EC2 i3.xlarge instance
sudo mkfs.ext4 /dev/nvme0n1
sudo mkdir -p /mnt/longhorn-nvme
sudo mount /dev/nvme0n1 /mnt/longhorn-nvme
echo '/dev/nvme0n1 /mnt/longhorn-nvme ext4 defaults,nofail 0 2' | sudo tee -a /etc/fstab

# Configure as Longhorn disk (via node CRD or UI)
# Path: /mnt/longhorn-nvme/

Azure — Machines virtuelles avec Ultra Disk

Sur Azure, utilisez les machines virtuellesStandard_L8s_v3ouStandard_L16s_v3avec un stockage NVMe local. Vous pouvez également connecter des disques Ultra pour une latence constante inférieure à la milliseconde. Les disques Ultra vous permettent de configurer indépendamment les IOPS et le débit.

# Attach Ultra Disk to Azure VM (Azure CLI)
az vm disk attach \
  --vm-name k3s-worker-01 \
  --resource-group k3s-cluster \
  --name longhorn-ultra-01 \
  --size-gb 512 \
  --sku UltraSSD_LRS \
  --disk-iops-read-write 10000 \
  --disk-mbps-read-write 300 \
  --new

GCP — VM avec SSD local

GCP propose un SSD local connecté aux VMn2-standardouc3-standard. Les SSD locaux fournissent 375 Go par disque avec jusqu'à 680 000 IOPS en lecture. Connectez plusieurs disques SSD locaux et mettez-les en RAID pour des volumes plus importants.

# Create VM with local SSDs (gcloud)
gcloud compute instances create k3s-worker-01 \
  --machine-type=n2-standard-8 \
  --local-ssd=interface=NVME \
  --local-ssd=interface=NVME \
  --zone=europe-west1-b

# RAID two local SSDs for 750GB Longhorn disk
sudo mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/nvme0n1 /dev/nvme0n2
sudo mkfs.ext4 /dev/md0
sudo mkdir -p /mnt/longhorn-nvme
sudo mount /dev/md0 /mnt/longhorn-nvme

Pour les déploiements sur site, utilisez des serveurs avec des disques SSD NVMe ou SAS dédiés pour Longhorn. Séparez le disque du système d'exploitation des disques de stockage. Utilisez un réseau 10 GbE ou 25 GbE entre les nœuds pour garantir que le trafic de réplication ne crée pas de goulot d'étranglement : la réplication synchrone Longhorn génère un trafic réseau proportionnel au débit d'écriture multiplié par le nombre de réplicas.

# Typical on-premises server spec for Longhorn k3s node
# CPU: 8+ cores (Xeon or EPYC)
# RAM: 32+ GB
# OS Disk: 256GB SATA SSD (mirrored)
# Longhorn Disk: 2x 1TB NVMe (RAID-1 or individual Longhorn disks)
# Network: 2x 25GbE (bonded, one for application, one for storage)

# Configure dedicated storage network (optional but recommended)
# In Longhorn settings:
# storage-network: kube-system/storage-network-attachment

Longhorn est livré avec une interface utilisateur Web intégrée qui fournit une interface visuelle pour la gestion des volumes, des instantanés, des sauvegardes, des nœuds et des paramètres. Accédez-y via l'entrée configurée lors de l'installation ou via le transfert de port kubectl.

# Quick access via port-forward
kubectl -n longhorn-system port-forward svc/longhorn-frontend 8080:80
# Open http://localhost:8080 in your browser

L'interface utilisateur propose plusieurs vues clés :Tableau de bordaffiche l'état du stockage à l'échelle du cluster, notamment la capacité totale, l'espace utilisé et l'état du volume. Volumerépertorie tous les volumes avec leur état (sain/dégradé/en panne), leur taille, le nombre de réplicas et le nœud connecté. Vous pouvez développer, prendre des instantanés, sauvegarder et restaurer des volumes directement à partir de cette vue. Nœudaffiche la configuration de stockage, l'allocation de disque et l'état de planification de chaque nœud. Sauvegarderépertorie toutes les sauvegardes stockées dans la cible de sauvegarde avec leur volume, leur taille et leur heure de création.Le paramètreexpose tous les paramètres de configuration Longhorn avec des descriptions.

Dépannage des problèmes courants

Volumes dégradés

Un volume passe à l'état Dégradé lorsqu'une ou plusieurs répliques ne sont pas saines mais que le volume est toujours fonctionnel. Les causes courantes incluent une défaillance du nœud, un disque plein ou une partition réseau.

# Check volume status
kubectl -n longhorn-system get volumes.longhorn.io -o wide

# Describe the volume for detailed status
kubectl -n longhorn-system describe volumes.longhorn.io pvc-abc123

# Check replica status
kubectl -n longhorn-system get replicas.longhorn.io -l longhornvolume=pvc-abc123

# If a replica is stuck in error state, delete it to trigger rebuild
kubectl -n longhorn-system delete replicas.longhorn.io pvc-abc123-r-12345

# Monitor rebuild progress
kubectl -n longhorn-system get volumes.longhorn.io pvc-abc123 \
  -o jsonpath='{.status.conditions}' | jq

Volume bloqué lors de la fixation/déconnexion du

# Check engine status
kubectl -n longhorn-system get engines.longhorn.io -l longhornvolume=pvc-abc123

# Check for stuck VolumeAttachment objects
kubectl get volumeattachments | grep pvc-abc123

# Force detach a stuck volume (use cautiously)
kubectl -n longhorn-system patch volumes.longhorn.io pvc-abc123 \
  --type merge -p '{"spec":{"nodeID":""}}'

# If attachment is truly stuck, delete the VolumeAttachment
kubectl delete volumeattachment csi-abc123def456

Pression d'espace

# Check node storage usage
kubectl -n longhorn-system get nodes.longhorn.io -o wide

# Identify large snapshots consuming space
kubectl -n longhorn-system get snapshots.longhorn.io -l longhornvolume=pvc-abc123

# Purge old snapshots to reclaim space
# Via Longhorn UI: Volume → Snapshots → Delete unneeded snapshots
# Old snapshots consume space because COW data cannot be freed until the snapshot is deleted

# Check for snapshot data integrity issues
kubectl -n longhorn-system get settings.longhorn.io snapshot-data-integrity

Longhorn doivent être effectuées avec précaution, car le système de stockage prend en charge toutes les charges de travail avec état. Effectuez toujours des sauvegardes de tous les volumes critiques avant la mise à niveau.

# 1. Back up all volumes before upgrade
for vol in $(kubectl -n longhorn-system get volumes.longhorn.io -o jsonpath='{.items[*].metadata.name}'); do
  echo "Backing up $vol"
  kubectl -n longhorn-system patch volumes.longhorn.io $vol \
    --type merge -p '{"spec":{"lastBackupAt":"'$(date -u +"%Y-%m-%dT%H:%M:%SZ")'"}}'
done

# 2. Check current version
kubectl -n longhorn-system get daemonset longhorn-manager -o jsonpath='{.spec.template.spec.containers[0].image}'

# 3. Upgrade via Helm
helm repo update
helm upgrade longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --version 1.7.2 \
  --values longhorn-values.yaml

# 4. Monitor the rolling upgrade
kubectl -n longhorn-system rollout status daemonset/longhorn-manager
kubectl -n longhorn-system rollout status deployment/longhorn-driver-deployer

# 5. Verify all volumes are healthy after upgrade
kubectl -n longhorn-system get volumes.longhorn.io -o custom-columns=NAME:.metadata.name,STATE:.status.state,ROBUSTNESS:.status.robustness

# 6. Longhorn automatically upgrades engines — monitor progress
kubectl -n longhorn-system get engines.longhorn.io -o wide

avec les opérateurs de base de données

Les opérateurs de bases de données Kubernetes modernes (CloudNativePG, Percona Operator, Zalando Postgres Operator) fonctionnent de manière transparente avec Longhorn. L'opérateur gère le cycle de vie de la base de données tandis que Longhorn fournit le stockage sous-jacent avec réplication, instantanés et sauvegarde.

# CloudNativePG cluster using Longhorn storage
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: production-pg
  namespace: database
spec:
  instances: 3
  storage:
    size: 100Gi
    storageClass: longhorn-db
    pvcTemplate:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 100Gi
  walStorage:
    size: 20Gi
    storageClass: longhorn-fast

  postgresql:
    parameters:
      shared_buffers: "2GB"
      effective_cache_size: "6GB"
      maintenance_work_mem: "512MB"
      wal_buffers: "64MB"
      max_connections: "200"

  backup:
    barmanObjectStore:
      destinationPath: s3://pg-backups/cnpg/
      endpointURL: https://s3.eu-west-1.amazonaws.com
      s3Credentials:
        accessKeyId:
          name: aws-creds
          key: ACCESS_KEY_ID
        secretAccessKey:
          name: aws-creds
          key: SECRET_ACCESS_KEY
      wal:
        compression: gzip
    retentionPolicy: "30d"

  resources:
    requests:
      cpu: "2"
      memory: 4Gi
    limits:
      cpu: "4"
      memory: 8Gi

# Percona XtraDB Cluster with Longhorn storage
apiVersion: pxc.percona.com/v1
kind: PerconaXtraDBCluster
metadata:
  name: production-mysql
  namespace: database
spec:
  crVersion: "1.14.0"
  pxc:
    size: 3
    image: percona/percona-xtradb-cluster:8.0
    resources:
      requests:
        cpu: "2"
        memory: 4Gi
    volumeSpec:
      persistentVolumeClaim:
        storageClassName: longhorn-db
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 200Gi
  backup:
    image: percona/percona-xtradb-cluster-operator:1.14.0-pxc8.0-backup-pxb8.0.35
    storages:
      s3-backup:
        type: s3
        s3:
          bucket: mysql-backups
          region: eu-west-1
          credentialsSecret: aws-creds
    schedule:
      - name: daily-full
        schedule: "0 2 * * *"
        keep: 14
        storageName: s3-backup

Conclusion

Longhorn transforme k3s d'une distribution Kubernetes légère adaptée uniquement à la périphérie et au développement en une plate-forme prête pour la production, capable d'exécuter des charges de travail avec état critiques. Son architecture (moteurs par volume, réplication multi-nœuds synchrone, instantané intégré et sauvegarde sur le stockage d'objets cloud, volumes DR, chiffrement de volume et extension PVC en ligne) offre un stockage de niveau entreprise sans complexité de niveau entreprise.

La clé du succès du Longhorn en production est triple. Tout d'abord, configurez-le correctement dès le départ : utilisez des disques de stockage dédiés, définissez les facteurs de réplication et la localisation des données appropriés, et créez des StorageClasses spécialement conçues pour différents types de charge de travail. Deuxièmement, intégrez la sauvegarde dans votre architecture dès le premier jour : des instantanés récurrents pour une restauration rapide, des sauvegardes quotidiennes sur S3/GCS/Azure pour la reprise après sinistre et des volumes DR dans un cluster de secours pour le pire des cas. Troisièmement, surveillez tout : l’état du volume, la capacité de stockage des nœuds, l’âge des sauvegardes et l’état de reconstruction des réplicas : les problèmes de stockage sont invisibles jusqu’à ce qu’ils deviennent catastrophiques.

L'extension dynamique du PVC élimine l'une des sources les plus courantes d'incidents de production : le manque d'espace disque. Avec Longhorn, l'extension d'un volume de base de données de 50Gi à 500Gi est une seule commande kubectl sans temps d'arrêt. En combinaison avec les alertes Prometheus sur les seuils de capacité, vous pouvez augmenter les volumes de manière proactive avant qu'ils ne deviennent critiques, ou automatiser entièrement l'expansion.

Que vous exécutiez PostgreSQL, MySQL, MongoDB ou Redis sur k3s — sur des serveurs nus, des machines virtuelles AWS EC2, Azure, des instances GCP ou du matériel de centre de données sur site — Longhorn fournit la base de stockage qui vous permet de vous concentrer sur vos applications au lieu de vous soucier de la durabilité des données. Installez-le, configurez-le, surveillez-le et confiez-lui vos données de production.