Longhorn-opslag voor productie k3s-clusters: dynamische PVC-uitbreiding, replicatie en noodherstel

Opslag is het moeilijkste probleem in Kubernetes. Compute is staatloos en vervangbaar: dood een pod, plan een andere. Netwerken beschikt over volwassen CNI-plug-ins en service-meshes. Maar opslag? Opslag is waar de status leeft, waar gegevens blijven bestaan ​​na herstarts, waar een enkele verkeerde configuratie permanent gegevensverlies kan betekenen. Voor k3s-clusters met productieworkloads (databases, berichtenwachtrijen, applicatiestatus) hebt u een opslagoplossing nodig die gedistribueerd, veerkrachtig, uitbreidbaar en bruikbaar is. Longhorn is die oplossing.

Longhorn is een lichtgewicht, betrouwbaar en gebruiksvriendelijk gedistribueerd blokopslagsysteem voor Kubernetes. Oorspronkelijk ontwikkeld door Rancher Labs (nu onderdeel van SUSE), is het een CNCF-incubatieproject dat speciaal is gebouwd voor clusters waar eenvoud belangrijk is, maar de betrouwbaarheid van de productie niet onderhandelbaar is. In tegenstelling tot Ceph, dat specifieke opslagknooppunten en diepgaande expertise vereist, of een local-path provisioner, die geen redundantie biedt, vindt Longhorn precies de balans die k3s-clusters nodig hebben: gedistribueerde replicatie over knooppunten, dynamische volume-uitbreiding, geïntegreerde back-up naar objectopslag in de cloud, snapshot en noodherstel - allemaal beheerd via een schone gebruikersinterface en Kubernetes-native CRD's.

Deze handleiding behandelt alles wat u nodig hebt om Longhorn op k3s voor productie te implementeren: interne architectuur, installatiemethoden, StorageClass-configuratie, dynamische PVC-uitbreiding, replicatiestrategieën, back-up en noodherstel, volume-encryptie, prestatie-afstemming voor databases, monitoring en probleemoplossing. Elke aanbeveling wordt geleverd met een in productie geteste configuratie die u aan uw omgeving kunt aanpassen.

Longhorn-architectuur

Het begrijpen van de architectuur van Longhorn is essentieel voor het nemen van weloverwogen beslissingen over replicatie, prestaties en foutafhandeling. Longhorn bestaat uit drie kerncomponenten die samenwerken om gedistribueerde blokopslag te bieden bovenop de lokale schijven die aan uw Kubernetes-knooppunten zijn gekoppeld.

DeLonghorn Managerdraait als DaemonSet op elk knooppunt in het cluster. Het is het besturingsvlak van Longhorn: het verwerkt API-oproepen, orkestreert het maken van volumes, beheert de replicatie, coördineert snapshots en back-ups, en communiceert met de Kubernetes API-server om de levenscyclus van PersistentVolume en PersistentVolumeClaim te beheren. Wanneer u een PVC maakt die verwijst naar een Longhorn StorageClass, ontvangt de Longhorn Manager het verzoek via het CSI-stuurprogramma, richt het volume in en plant de replica's ervan over beschikbare knooppunten.

DeLonghorn Engineis een opslagcontroller per volume geïmplementeerd als een Linux-gebruikersruimteproces (gebaseerd op een vork van de Rancher Longhorn Engine). Voor elk volume wordt een eigen speciaal motorproces uitgevoerd op het knooppunt waaraan het volume is gekoppeld. De engine verwerkt alle lees- en schrijf-I/O voor dat volume, waarbij schrijfbewerkingen synchroon worden gerepliceerd naar alle geconfigureerde replica's voordat het schrijven naar de toepassing wordt bevestigd. Deze architectuur per volume betekent dat een crash of vastlopen in de engine van één volume geen invloed heeft op een ander volume - een kritische isolatie-eigenschap voor productie.

Replica'szijn de feitelijke gegevensopslagprocessen. Elke replica slaat een volledige kopie van de volumegegevens op de lokale schijf van het knooppunt waarop deze wordt uitgevoerd. Standaard maakt Longhorn drie replica's voor elk volume, verdeeld over verschillende knooppunten (en optioneel verschillende zones). Replica's gebruiken een copy-on-write-mechanisme voor snapshots, waardoor het maken van snapshots onmiddellijk mogelijk is, ongeacht de volumegrootte.

Deze architectuur levert verschillende belangrijke eigenschappen voor productiegebruik.Fouttolerantie:met drie replica's verdeeld over drie knooppunten, het volume overleeft twee gelijktijdige knooppuntstoringen.Isolatie:elk volume heeft zijn eigen engine-proces, dus een bug of vastloper in één volume kan niet in cascade plaatsvinden.Eenvoud:geen speciale opslagknooppunten, geen afzonderlijke Ceph- of GlusterFS-clusters - Longhorn draait op dezelfde werkknooppunten als uw applicatiepods, met behulp van hun lokale schijven.Kubernetes-native:alles wordt beheerd via CRDs, kubectl en de Kubernetes CSI-interface.

Longhorn installeren op k3s

Longhorn kan op drie manieren op k3s worden geïnstalleerd: Helm-grafiek (aanbevolen voor productie), Rancher App Marketplace (als Rancher uw cluster beheert) of directe kubectl-toepassing. Zorg ervoor dat uw knooppunten aan de vereisten voldoen voordat u met de installatie begint.

Vereisten

# 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.

Installatie via Helm (aanbevolen)

# 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

Hier is eenvalues.yamlvan productiekwaliteit met afgestemde standaardinstellingen:

# 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

Installatie via Rancher App Marketplace

Als Rancher uw k3s-cluster beheert, navigeert u naarApps & Marktplaats → Grafieken → Longhornin de Rancher-gebruikersinterface. Selecteer uw doelnaamruimte (longhorn-system), configureer de waarden via de formulierinterface en klik op Installeren. Rancher verwerkt het Helm-levenscyclusbeheer en het volgen van upgrades automatisch.

Installatie 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

Post-installatie: maak van Longhorn de standaard StorageClass

# 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

StorageClass-configuratie voor productie

De standaard Longhorn StorageClass werkt voor ontwikkeling, maar productieworkloads hebben specifieke configuraties nodig voor verschillende gebruiksscenario's: databases hebben een hoge replicatie en specifieke gegevenslocatie nodig, tijdelijke verwerking heeft snelle single-replica-volumes nodig en gedeelde volumes hebben RWX-ondersteuning nodig.

# 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

Dynamische PVC-uitbreiding

Een van de belangrijkste productiefuncties van Longhorn is de dynamische PVC-uitbreiding: de mogelijkheid om de omvang van een persistent volume te laten groeien zonder downtime, zonder gegevensverlies en zonder handmatige tussenkomst die verder gaat dan een enkele kubectl-opdracht of manifestwijziging. Dit is van cruciaal belang voor databases waar de gegevensgroei onvoorspelbaar is en een tekort aan schijfruimte een storing betekent.

Longhorn ondersteunt zowelonline uitbreiding(volume blijft aangesloten en gekoppeld terwijl het groeit) alsoffline uitbreiding(volume wordt eerst losgemaakt). Online uitbreiding is de standaard en aanbevolen aanpak voor productie, omdat hiermee downtime van applicaties wordt vermeden.

Maakt volume-uitbreiding mogelijk in StorageClass

De belangrijkste vereiste voor dynamische PVC-uitbreiding is dat de StorageClassallowVolumeExpansion: truemoet hebben. De standaard StorageClass van Longhorn bevat dit al, maar als u aangepaste StorageClasses heeft, controleer dan of dit veld is ingesteld.

# 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}'

Stap voor stap: een PVC dynamisch uitbreiden

# 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

Automatisering van PVC-uitbreiding met waarschuwingen

In productie moet u niet wachten tot een schijf voor 86% vol is om deze handmatig uit te breiden. Gebruik Prometheus-waarschuwingen om uitbreiding automatisch te activeren of waarschuw de technicus van wacht voordat de capaciteit kritiek wordt.

# 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"

Volumereplicatie en gegevenslocatie

Longhorn repliceert volumegegevens over meerdere knooppunten om te beschermen tegen hardwarefouten. De replicatiefactor en de gegevenslocatie-instellingen bepalen de afweging tussen duurzaamheid, prestaties en opslagefficiëntie.

Replicatiefactorbepaalt hoeveel kopieën van de gegevens er bestaan. De standaardwaarde is 3, wat betekent dat elke schrijfbewerking op drie verschillende knooppunten wordt opgeslagen. Voor productiedatabases is 3 de minimaal aanbevolen waarde. U kunt deze op 2 instellen voor minder kritieke werklasten om opslag te besparen, of op 1 laten staan ​​voor tijdelijke/cachevolumes waarbij gegevensverlies acceptabel is.

Gegevenslocatiebepaalt of Longhorn probeert een replica op hetzelfde knooppunt te houden als de pod die het volume gebruikt. Er zijn drie modi:

• uitgeschakeld— Replica's worden uitsluitend gepland op basis van beschikbare ruimte en anti-affiniteit. De pod kan lezen van een replica op een extern knooppunt, waardoor netwerklatentie aan elke I/O-bewerking wordt toegevoegd.
• beste poging— Longhorn probeert één replica op hetzelfde knooppunt te plaatsen als de consumerende pod. Als het lokale knooppunt geen ruimte meer heeft of de pod migreert, werkt het volume nog steeds, maar heeft het mogelijk een iets hogere latentie. Dit is de aanbevolen instelling voor de meeste werkbelastingen.
• strikt lokaal— Het volume kan alleen worden gebruikt op een knooppunt dat een lokale replica heeft. Als de pod is gepland op een knooppunt zonder een lokale replica, mislukt de volumebijlage. Gebruik dit alleen voor latentiegevoelige workloads met één replica waarbij u de duurzaamheidsafweging accepteert.

# 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

Snapshots en back-ups

Longhorn biedt twee verschillende mechanismen voor gegevensbescherming:snapshots(lokaal, direct, voor snel terugdraaien) enback-ups(op afstand, naar objectopslag, voor noodherstel). Het is van cruciaal belang dat u begrijpt wanneer u ze moet gebruiken.

Snapshots worden lokaal opgeslagen op dezelfde schijven als de volumereplica's. Ze worden onmiddellijk gemaakt met behulp van copy-on-write - er worden geen gegevens gekopieerd tijdens de momentopname, alleen nieuwe schrijfbewerkingen na de momentopname wijzen extra ruimte toe. Snapshots zijn uitstekend geschikt voor het snel terugdraaien vóór een risicovolle migratie of implementatie, maar bieden geen bescherming tegen knooppunt- of schijfstoringen omdat ze zich op dezelfde opslag bevinden als het volume.

-back-ups kopiëren de volumegegevens naar een extern back-updoel: S3, GCS, Azure Blob of een S3-compatibele winkel (MinIO, Wasabi). Back-ups zijn incrementeel op blokniveau: alleen blokken die sinds de laatste back-up zijn gewijzigd, worden overgedragen. Dit maakt terugkerende back-ups snel en opslagefficiënt. Back-ups beschermen tegen totaal clusterverlies omdat ze onafhankelijk bestaan.

Het back-updoel

# 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

VolumeSnapshot-klasse en Snapshot 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

Terugkerende back-upschema's

# 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

Noodherstel

Longhorn biedt een ingebouwd noodherstelmechanisme viaDR-volumes.: stand-byvolumes in een secundair cluster die voortdurend incrementele back-ups ophalen van het back-updoel van het primaire cluster. Wanneer zich een ramp voordoet, activeert u het DR-volume en wordt het een regulier lees-schrijfvolume, waardoor het secundaire cluster het overneemt.

DR-volumes instellen

# 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

Volume-encryptie

Longhorn ondersteunt versleuteling op volumeniveau met behulp van Linux LUKS2. Gecodeerde volumes beschermen gegevens die zich op de onderliggende schijf bevinden. Zelfs als iemand fysieke toegang krijgt tot de opslag van de server, kan hij of zij de volumegegevens niet lezen zonder de coderingssleutel.

# 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) Ondersteuning

Standaard zijn Longhorn-volumes ReadWriteOnce (RWO) - ze kunnen door een enkele pod op een enkel knooppunt worden gemonteerd. Voor workloads die gedeelde opslag over meerdere pods nodig hebben (bijvoorbeeld gedeelde media-uploads, configuratiebestanden, ML-modelartefacten), ondersteunt Longhorn ReadWriteMany (RWX) via een geïntegreerde NFS-server.

Wanneer een PVC de RWX-toegangsmodus aanvraagt, zet Longhorn automatisch een share-manager-pod in die een NFS-server draait, ondersteund door het Longhorn-volume. Meerdere pods kunnen het volume vervolgens gelijktijdig via NFS koppelen. Dit is eenvoudiger dan het inzetten van een aparte NFS-server, maar voegt een laag netwerkoverhead toe vergeleken met directe bloktoegang.

# 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

Database-workloads op Longhorn

Het uitvoeren van databases op Longhorn vereist zorgvuldige aandacht voor StorageClass-parameters, pod-affiniteit en back-upintegratie. De per-volume-engine en synchrone replicatie van Longhorn maken het zeer geschikt voor databaseworkloads, maar u moet het correct configureren om prestaties en betrouwbaarheid op productieniveau te verkrijgen.

PostgreSQL StatefulSet met 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 met 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

Prestatieafstemming voor databaseworkloads

Longhorn voegt een opslagreplicatielaag toe tussen de applicatie en de fysieke schijf, wat enige latentie introduceert in vergelijking met directe lokale schijftoegang. Voor de meeste workloads is deze overhead verwaarloosbaar, maar databaseworkloads met zware schrijfpatronen moeten worden afgestemd om optimale prestaties te bereiken.

Gebruik gegevenslocatie: beste inspanning.Dit zorgt ervoor dat één replica zich op hetzelfde knooppunt bevindt als de databasepod, wat betekent dat de lokale schijf wordt gelezen met NVMe/SSD-snelheid. Schrijfbewerkingen worden nog steeds gerepliceerd naar externe knooppunten, maar de lokale replica elimineert netwerkrondreizen voor leesbewerkingen.

Wijd schijven aan Longhorn.Deel de besturingssysteemschijf niet met Longhorn-gegevens. Voeg speciale NVMe- of SSD-schijven toe en configureer ze als Longhorn-schijven. Dit voorkomt I/O-conflicten tussen het besturingssysteem en de databasevolumes.

# 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 gegarandeerd motormanager CPU. De motorprocessen vanLonghorn gebruiken CPU voor I/O-verwerking en replicatie. DeguaranteedInstanceManagerCPU-instelling reserveert een percentage van knooppunt CPU voor Longhorn-instantiebeheerders, waardoor CPU-uithongering onder belasting wordt voorkomen.

Stem het aantal replica's af.Voor databases die al replicatie op applicatieniveau hebben (PostgreSQL-streamingreplicatie, MySQL-groepsreplicatie, MongoDB-replicasets), kunt u het aantal Longhorn-replica's terugbrengen tot 2 in plaats van 3. De eigen replicatie van de database biedt een extra laag gegevensbescherming, en minder Longhorn-replica's betekenen minder schrijfversterking en een betere schrijfdoorvoer.

Gebruik ext4 via xfs voor kleine willekeurige I/O.Hoewel xfs uitblinkt in grote sequentiële schrijfbewerkingen, presteert ext4 over het algemeen beter voor het kleine willekeurige I/O-patroon dat typisch is voor databasewerklasten. StelfsType: ext4in in uw StorageClass.

Knooppuntplanning en schijfbeheer

Longhorn biedt fijnmazige controle over welke knooppunten en schijven worden gebruikt voor volumeplanning. Dit is van cruciaal belang in heterogene clusters waar sommige knooppunten snelle NVMe-opslag hebben en andere langzamere SATA-schijven.

# 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

-bewaking met Prometheus en Grafana

Longhorn maakt Prometheus-statistieken zichtbaar via een ingebouwd metrisch eindpunt. Het monitoren van deze statistieken is essentieel voor capaciteitsplanning, prestatieanalyse en proactieve waarschuwingen.

# 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 }}"

Belangrijke Grafana-dashboardpanelen die u voor Longhorn-monitoring kunt maken, zijn onder meer: volume-IOPS (lezen/schrijven), volumedoorvoer (MB/s), volumelatentie (p50/p95/p99), voortgang van het opnieuw opbouwen van replica's, knooppuntopslagcapaciteit en -gebruik, back-upstatus en -leeftijd, en aantal snapshots per volume.

k3s Cluster met complete Longhorn Storage Stack

Het volgende diagram laat zien hoe Longhorn past in een complete k3s-productiestack, van bare metal-servers tot applicatiepods, met Rancher-beheer en Prometheus/Grafana-observatie.

Vergelijking met andere Kubernetes-opslagoplossingen

Longhorn is niet de enige opslagoptie voor Kubernetes. Als u begrijpt hoe het zich verhoudt tot alternatieven, kunt u de juiste keuze maken voor uw specifieke vereisten.

Longhorn versus Rook-Ceph:Ceph is het krachtigere systeem: het ondersteunt objectopslag, bestandsopslag en blokopslag met een geavanceerd CRUSH-plaatsingsalgoritme. Ceph vereist echter minimaal drie speciale OSD-nodes, aanzienlijk RAM (minimaal 4 GB per OSD-daemon) en diepgaande operationele expertise. Voor k3s-clusters met 3-10 knooppunten levert Longhorn 90% van de waarde tegen 10% van de operationele kosten.

Longhorn versus OpenEBS Mayastor:Mayastor gebruikt NVMe-over-Fabrics voor krachtige replicatie, waardoor een lagere latentie wordt bereikt dan de op TCP gebaseerde replicatie van Longhorn. Als onbewerkte IOPS en latentie van minder dan een milliseconde uw voornaamste zorg zijn en u over een NVMe-infrastructuur met RDMA-netwerken beschikt, is Mayastor wellicht de betere keuze. Voor de meeste k3s-implementaties wegen de geïntegreerde back-up, DR en operationele eenvoud van Longhorn zwaarder dan de prestatievoordelen van Mayastor.

Longhorn versus lokaal pad:-provisioner voor lokaal pad is de standaardopslag van k3s - het creëert eenvoudigweg mappen op het lokale bestandssysteem van het knooppunt. Geen replicatie, geen momentopnamen, geen back-upintegratie. Het is prima voor de ontwikkeling, maar onaanvaardbaar voor productiegegevens.

Beste productiepraktijken

Deze aanbevelingen zijn afgeleid van het functioneren van Longhorn over tientallen productie-k3s-clusters die databaseworkloads uitvoeren.

1. Stel resourcereserveringen in voor bijvoorbeeld managers.Longhorn-instantiebeheerders (engine- en replicabeheerders) hebben gegarandeerde CPU nodig om I/O-blokkeringen tijdens knooppuntdruk te voorkomen. StelguaranteedInstanceManagerCPUin op minimaal 12% in de Longhorn-instellingen.

2. Gebruik het terugvorderingsbeleid voor databasevolumes behouden.GebruikDeletenooit voor database PVCs. EenRetain-beleid bewaart de PV en de gegevens ervan, zelfs nadat de PVC is verwijderd, waardoor u een vangnet hebt tegen onbedoelde verwijdering.

3. Schakel replica zachte anti-affiniteit voor productie uit.StelreplicaSoftAntiAffinity: falsein om ervoor te zorgen dat replica's altijd over verschillende knooppunten worden verspreid. Met zachte anti-affiniteit kan Longhorn meerdere replica's op hetzelfde knooppunt plannen als er weinig ruimte is, waardoor het doel van replicatie teniet wordt gedaan.

4. Reserveer opslagruimte op elk knooppunt.StelstorageMinimalAvailablePercentagein op minimaal 15%. Dit voorkomt dat Longhorn alle schijfruimte in beslag neemt, wat problemen op knooppuntniveau zou veroorzaken die van invloed zijn op alle pods.

5. Schakel automatisch herstel in.De instellingautoSalvageherstelt automatisch volumes die in een defecte status terechtkomen wanneer ten minste één replica nog steeds in orde is. Dit vermindert handmatige tussenkomst tijdens knooppuntstoringen.

6. Stel de prioriteitsklasse in op systeemclusterkritiek. De manager- en drivercomponenten vanLonghorn mogen nooit worden verwijderd tijdens knooppuntdruk. Stel hun prioriteitsklasse in opsystem-cluster-criticalom ervoor te zorgen dat ze de uitzetting van de pod overleven.

7. Configureer terugkerende opdrachten voor alle productievolumes.Elk productievolume moet zowel snapshot- als back-up terugkerende taken hebben. Elke 4 uur snapshots voor snel terugdraaien, dagelijkse back-ups voor noodherstel.

8. Test regelmatig de activering van het DR-volume.Maak een maandelijks schema om DR-volumes in uw standby-cluster te activeren, de gegevensintegriteit te verifiëren en de failover-procedure te oefenen. Een DR-plan dat nooit is getest, is slechts documentatie.

9. Bewaak de volumestatus proactief.Stel Prometheus-waarschuwingen in voor gedegradeerde en defecte volumes, opslagcapaciteit van knooppunten, back-upleeftijd en herbouwstatus van replica's. Tegen de tijd dat een gebruiker een langzame database rapporteert, is het opslagprobleem al uren aan het toenemen.

10. Gebruik speciale opslagschijven.Scheid Longhorn-gegevens van de besturingssysteemschijf. Dit voorkomt I/O-conflicten, geeft u een schoner capaciteitsbeheer en vermijdt het risico dat de besturingssysteemschijf wordt gevuld met Longhorn-gegevens.

Cloudspecifieke implementatierichtlijnen

AWS — EC2 met NVMe-instantieopslag

Gebruik voor AWS-implementatiesi3.xlarge- ofi3en.xlarge-instanties die worden geleverd met NVMe-instantieopslag. Deze bieden onbewerkte NVMe-prestaties tegen een fractie van de kosten van ingerichte EBS IOPS. Formatteer de exemplaaropslag en configureer deze als een Longhorn-schijf.

# 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 — VM's met Ultra Disk

Gebruik op AzureStandard_L8s_v3- ofStandard_L16s_v3-VM's met lokale NVMe-opslag. U kunt ook Ultra Disks aansluiten voor een consistente latentie van minder dan een milliseconde. Met Ultra Disks kunt u IOPS en doorvoer onafhankelijk configureren.

# 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's met lokale SSD

GCP biedt lokale SSD gekoppeld aann2-standard- ofc3-standard-VM's. Lokale SSD's bieden 375 GB per schijf met maximaal 680.000 lees-IOPS. Sluit meerdere lokale SSD's aan en RAID ze voor grotere volumes.

# 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

Lokaal datacenter

Gebruik voor implementaties op locatie servers met speciale NVMe- of SAS SSD-schijven voor Longhorn. Scheid de besturingssysteemschijf van de opslagschijven. Gebruik een 10GbE- of 25GbE-netwerk tussen knooppunten om ervoor te zorgen dat replicatieverkeer geen knelpunt vormt: synchrone replicatie van Longhorn genereert netwerkverkeer dat proportioneel is aan de schrijfdoorvoer vermenigvuldigd met het aantal replica's.

# 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 UI-walkthrough

Longhorn wordt geleverd met een ingebouwde webinterface die een visuele interface biedt voor het beheren van volumes, snapshots, back-ups, knooppunten en instellingen. Krijg toegang via de Ingress die tijdens de installatie is geconfigureerd of via kubectl port-forward.

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

De gebruikersinterface biedt verschillende belangrijke weergaven:Dashboardtoont de opslagstatus voor het hele cluster, inclusief de totale capaciteit, gebruikte ruimte en volumestatus.Volumegeeft een overzicht van alle volumes met hun status (Gezond/Verslechterd/Fout), grootte, aantal replica's en aangesloten knooppunt. U kunt volumes rechtstreeks vanuit deze weergave uitbreiden, er een momentopname van maken, er een back-up van maken en deze herstellen.Knooppunttoont de opslagconfiguratie, schijftoewijzing en planningsstatus van elk knooppunt.Back-upgeeft een overzicht van alle back-ups die in het back-updoel zijn opgeslagen, met hun volume, grootte en aanmaaktijd.Instellinggeeft alle Longhorn-configuratieparameters met beschrijvingen weer.

Problemen oplossen Veelvoorkomende problemen

Verslechterde volumes

Een volume krijgt de status Verslechterd wanneer een of meer replica's niet in orde zijn, maar het volume nog steeds functioneel is. Veelvoorkomende oorzaken zijn onder meer een knooppuntstoring, een volle schijf of een netwerkpartitie.

# 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 zit vast bij het bevestigen/losmaken van

# 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

Ruimtedruk

# 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

-upgradeprocedures

Longhorn-upgrades moeten zorgvuldig worden uitgevoerd, omdat het opslagsysteem alle stateful workloads ondersteunt. Maak altijd back-ups van alle kritieke volumes voordat u een upgrade uitvoert.

# 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

Integratie met databaseoperatoren

Moderne Kubernetes-databaseoperators (CloudNativePG, Percona Operator, Zalando Postgres Operator) werken naadloos samen met Longhorn. De operator beheert de levenscyclus van de database, terwijl Longhorn de onderliggende opslag levert met replicatie, snapshots en back-up.

# 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

Conclusie

Longhorn transformeert k3s van een lichtgewicht Kubernetes-distributie die alleen geschikt is voor edge en ontwikkeling naar een productieklaar platform dat bedrijfskritische stateful workloads kan uitvoeren. De architectuur – per-volume-engines, synchrone replicatie van meerdere knooppunten, geïntegreerde snapshot en back-up naar objectopslag in de cloud, DR-volumes, volume-encryptie en online PVC-uitbreiding – levert opslag op bedrijfsniveau zonder complexiteit op bedrijfsniveau.

De sleutel tot succes met Longhorn in de productie is drieledig. Configureer het eerst vanaf het begin goed: gebruik speciale opslagschijven, stel de juiste replicatiefactoren en gegevenslocatie in en creëer speciaal gebouwde StorageClasses voor verschillende soorten werkbelasting. Ten tweede: integreer back-up vanaf dag één in uw architectuur: terugkerende snapshots voor snel terugdraaien, dagelijkse back-ups naar S3/GCS/Azure voor noodherstel en DR-volumes in een standby-cluster voor het ergste scenario. Ten derde moet u alles in de gaten houden: volumestatus, opslagcapaciteit van knooppunten, back-upleeftijd en reconstructiestatus van replica's. Problemen met opslag zijn onzichtbaar totdat ze catastrofaal worden.

Dynamische PVC-uitbreiding elimineert een van de meest voorkomende bronnen van productie-incidenten: onvoldoende schijfruimte. Met Longhorn is het uitbreiden van een databasevolume van 50Gi naar 500Gi een enkele kubectl-opdracht zonder downtime. Gecombineerd met Prometheus-waarschuwingen over capaciteitsdrempels kunt u volumes proactief uitbreiden voordat ze kritiek worden, of de uitbreiding volledig automatiseren.

Of u nu PostgreSQL, MySQL, MongoDB of Redis op k3s gebruikt (op bare metal-servers, AWS EC2, Azure VM's, GCP-instances of on-premise datacenterhardware) Longhorn biedt de opslagfundament waarmee u zich kunt concentreren op uw applicaties in plaats van u zorgen te hoeven maken over de duurzaamheid van gegevens. Installeer het, configureer het, monitor het en vertrouw het toe met uw productiegegevens.