Almacenamiento Longhorn para clústeres k3s de producción: expansión, replicación y recuperación ante desastres dinámicas de PVC

es el problema más difícil en Kubernetes. La computación no tiene estado y es fungible: elimine un módulo y programe otro. La creación de redes tiene complementos CNI maduros y mallas de servicios. ¿Pero el almacenamiento? El almacenamiento es donde vive el estado, donde los datos persisten tras los reinicios, donde una sola configuración incorrecta puede significar una pérdida permanente de datos. Para los clústeres k3s que ejecutan cargas de trabajo de producción (bases de datos, colas de mensajes, estado de las aplicaciones), necesita una solución de almacenamiento que sea distribuida, resistente, ampliable y operable. Longhorn es esa solución.

Longhorn es un sistema de almacenamiento en bloques distribuido liviano, confiable y fácil de usar para Kubernetes. Desarrollado originalmente por Rancher Labs (ahora parte de SUSE), es un proyecto de incubación de CNCF diseñado específicamente para clústeres donde la simplicidad importa pero la confiabilidad de la producción no es negociable. A diferencia de Ceph, que exige nodos de almacenamiento dedicados y una amplia experiencia, o un aprovisionador de ruta local, que ofrece redundancia cero, Longhorn logra el equilibrio exacto que necesitan los clústeres k3s: replicación distribuida entre nodos, expansión dinámica del volumen, respaldo integrado en el almacenamiento de objetos en la nube, instantáneas y recuperación ante desastres, todo administrado a través de una interfaz de usuario limpia y CRD nativos de Kubernetes.

Esta guía cubre todo lo que necesita para implementar Longhorn en k3s para producción: arquitectura interna, métodos de instalación, configuración de StorageClass, expansión dinámica de PVC, estrategias de replicación, respaldo y recuperación ante desastres, cifrado de volúmenes, ajuste del rendimiento para bases de datos, monitoreo y solución de problemas. Cada recomendación viene con una configuración probada en producción que puede adaptar a su entorno.

Arquitectura de cuernos largos

Comprender la arquitectura de Longhorn es esencial para tomar decisiones informadas sobre replicación, rendimiento y manejo de fallas. Longhorn se compone de tres componentes principales que trabajan juntos para proporcionar almacenamiento en bloques distribuido encima de los discos locales conectados a sus nodos Kubernetes.

ElLonghorn Managerse ejecuta como DaemonSet en cada nodo del clúster. Es el plano de control de Longhorn: maneja llamadas API, organiza la creación de volúmenes, administra la replicación, coordina instantáneas y copias de seguridad y se comunica con el servidor Kubernetes API para administrar el ciclo de vida de PersistentVolume y PersistentVolumeClaim. Cuando crea un PVC que hace referencia a Longhorn StorageClass, Longhorn Manager recibe la solicitud a través del controlador CSI, aprovisiona el volumen y programa sus réplicas en los nodos disponibles.

Longhorn Enginees un controlador de almacenamiento por volumen implementado como un proceso de espacio de usuario de Linux (basado en una bifurcación de Rancher Longhorn Engine). Cada volumen tiene su propio proceso de motor dedicado que se ejecuta en el nodo al que está conectado el volumen. El motor maneja todas las E/S de lectura y escritura para ese volumen, replicando las escrituras sincrónicamente en todas las réplicas configuradas antes de reconocer la escritura en la aplicación. Esta arquitectura por volumen significa que una falla o un bloqueo en el motor de un volumen no afecta a ningún otro volumen, una propiedad de aislamiento crítica para la producción.

Las réplicas deson los procesos de almacenamiento de datos reales. Cada réplica almacena una copia completa de los datos del volumen en el disco local del nodo donde se ejecuta. De forma predeterminada, Longhorn crea tres réplicas para cada volumen, distribuidas en diferentes nodos (y, opcionalmente, en diferentes zonas). Las réplicas utilizan un mecanismo de copia en escritura para instantáneas, lo que hace que la creación de instantáneas sea instantánea independientemente del tamaño del volumen.

Esta arquitectura ofrece varias propiedades clave para uso en producción.Tolerancia a fallos:con tres réplicas en tres nodos, el volumen sobrevive a dos fallos de nodo simultáneos. Aislamiento:cada volumen tiene su propio proceso de motor, por lo que un error o bloqueo en un volumen no puede ocurrir en cascada.Simplicidad:sin nodos de almacenamiento dedicados, sin clústeres Ceph o GlusterFS separados: Longhorn se ejecuta en los mismos nodos trabajadores que sus módulos de aplicaciones, utilizando sus discos locales.Kubernetes-nativo:todo se administra a través de CRDs, kubectl y la interfaz Kubernetes CSI.

Instalación de Longhorn en k3s

Longhorn se puede instalar en k3s a través de tres métodos: gráfico Helm (recomendado para producción), Rancher App Marketplace (si tiene Rancher administrando su clúster) o aplicación directa de kubectl. Antes de instalar, asegúrese de que sus nodos cumplan con los requisitos previos.

Requisitos previos

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

mediante Helm (recomendado)

# 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

Aquí hay unvalues.yamlde producción con valores predeterminados ajustados:

# 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

a través de Rancher App Marketplace

Si Rancher administra su clúster k3s, navegue hasta Aplicaciones y accesorios. Mercado → Gráficos → Longhornen la interfaz de usuario de Rancher. Seleccione su espacio de nombres de destino (longhorn-system), configure los valores a través de la interfaz del formulario y haga clic en Instalar. Rancher maneja automáticamente la gestión del ciclo de vida de Helm y el seguimiento de actualizaciones.

mediante 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-instalación: Haga que Longhorn sea la clase de almacenamiento predeterminada

# 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

para producción

El Longhorn StorageClass predeterminado funciona para el desarrollo, pero las cargas de trabajo de producción necesitan configuraciones específicas para diferentes casos de uso: las bases de datos necesitan una alta replicación y una localidad de datos específica, el procesamiento temporal necesita volúmenes rápidos de una sola réplica y los volúmenes compartidos necesitan soporte 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

Expansión dinámica PVC

Una de las características de producción más importantes de Longhorn es la expansión dinámica PVC: la capacidad de aumentar el tamaño de un volumen persistente sin tiempo de inactividad, sin pérdida de datos y sin intervención manual más allá de un solo comando kubectl o cambio de manifiesto. Esto es fundamental para las bases de datos donde el crecimiento de los datos es impredecible y quedarse sin espacio en disco significa una interrupción.

Longhorn admite tanto la expansión en línea(el volumen permanece conectado y montado mientras crece) como la expansión fuera de línea(el volumen se desconecta primero). La expansión en línea es el enfoque predeterminado y recomendado para la producción porque evita el tiempo de inactividad de las aplicaciones.

Habilitación de la expansión de volumen en StorageClass

El requisito clave para la expansión dinámica de PVC es que StorageClass debe tenerallowVolumeExpansion: true. La StorageClass predeterminada de Longhorn ya incluye esto, pero si tiene StorageClasses personalizadas, verifique que este campo esté configurado.

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

paso a paso: expandir un PVC dinámicamente

# 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

Automatización de la expansión PVC con alertas

En producción, no debe esperar hasta que un disco esté lleno al 86% para expandirlo manualmente. Utilice las alertas Prometheus para activar la expansión automáticamente o alertar al ingeniero de guardia antes de que la capacidad se vuelva crítica.

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

Replicación de volumen y localidad de datos

Longhorn replica datos de volúmenes en múltiples nodos para proteger contra fallas de hardware. El factor de replicación y la configuración de la localidad de los datos controlan el equilibrio entre durabilidad, rendimiento y eficiencia del almacenamiento.

Factor de replicacióndetermina cuántas copias de los datos existen. El valor predeterminado es 3, lo que significa que cada escritura se almacena en tres nodos diferentes. Para bases de datos de producción, 3 es el valor mínimo recomendado. Puede configurarlo en 2 para cargas de trabajo menos críticas para ahorrar almacenamiento, o dejarlo en 1 para volúmenes temporales/de caché donde la pérdida de datos es aceptable.

Localidad de datoscontrola si Longhorn intenta mantener una réplica en el mismo nodo que el pod que consume el volumen. Hay tres modos:

• deshabilitado: las réplicas se programan únicamente en función del espacio disponible y la antiafinidad. El pod podría leer desde una réplica en un nodo remoto, agregando latencia de red a cada operación de E/S.
• mejor esfuerzo: Longhorn intenta colocar una réplica en el mismo nodo que el módulo consumidor. Si el nodo local se queda sin espacio o el pod migra, el volumen aún funciona pero puede tener una latencia ligeramente mayor. Esta es la configuración recomendada para la mayoría de las cargas de trabajo.
• estricto local: el volumen solo se puede utilizar en un nodo que tenga una réplica local. Si el pod está programado para un nodo sin una réplica local, la conexión del volumen falla. Úselo solo para cargas de trabajo de réplica única sensibles a la latencia en las que acepta la compensación de durabilidad.

# 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

Instantáneas y copias de seguridad

Longhorn proporciona dos mecanismos distintos de protección de datos: instantáneas,(locales, instantáneas, para una reversión rápida) y copias de seguridad,(remotas, para almacenamiento de objetos, para recuperación ante desastres). Comprender cuándo utilizar cada uno es fundamental.

se almacenan localmente en los mismos discos que las réplicas de volumen. Se crean instantáneamente mediante copia en escritura: no se copian datos en el momento de la instantánea, solo las nuevas escrituras después de la instantánea asignan espacio adicional. Las instantáneas son excelentes para una reversión rápida antes de una migración o implementación riesgosa, pero no protegen contra fallas de nodo o disco porque se encuentran en el mismo almacenamiento que el volumen.

copian los datos del volumen a un destino de copia de seguridad externo: S3, GCS, Azure Blob o cualquier almacén compatible con S3 (MinIO, Wasabi). Las copias de seguridad son incrementales a nivel de bloque: solo se transfieren los bloques que cambiaron desde la última copia de seguridad. Esto hace que las copias de seguridad recurrentes sean rápidas y eficientes en el almacenamiento. Las copias de seguridad protegen contra la pérdida total del clúster porque existen de forma independiente.

Configuración del destino de la copia de seguridad

# 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

Clase de instantánea de volumen y instantánea 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

Programaciones de copias de seguridad recurrentes

# 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

Recuperación ante desastres

Longhorn proporciona un mecanismo de recuperación ante desastres integrado a través de volúmenes DR: volúmenes en espera en un clúster secundario que extraen continuamente copias de seguridad incrementales del destino de copia de seguridad del clúster principal. Cuando ocurre un desastre, activa el volumen DR y se convierte en un volumen de lectura y escritura normal, permitiendo que el clúster secundario asuma el control.

Configuración de volúmenes 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

Cifrado de volumen

Longhorn admite cifrado a nivel de volumen mediante Linux LUKS2. Los volúmenes cifrados protegen los datos en reposo en el disco subyacente; incluso si alguien obtiene acceso físico al almacenamiento del servidor, no puede leer los datos del volumen sin la clave de cifrado.

# 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

Soporte ReadWriteMany (RWX)

De forma predeterminada, los volúmenes Longhorn son ReadWriteOnce (RWO): se pueden montar mediante un solo módulo en un solo nodo. Para cargas de trabajo que necesitan almacenamiento compartido entre varios pods (por ejemplo, cargas de medios compartidos, archivos de configuración, artefactos de modelo ML), Longhorn admite ReadWriteMany (RWX) a través de un servidor NFS integrado.

Cuando un PVC solicita el modo de acceso RWX, Longhorn implementa automáticamente un pod de administrador compartido que ejecuta un servidor NFS respaldado por el volumen Longhorn. Luego, varios pods pueden montar el volumen simultáneamente a través de NFS. Esto es más simple que implementar un servidor NFS separado, pero agrega una capa de sobrecarga de red en comparación con el acceso directo al bloque.

# 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

en Longhorn

La ejecución de bases de datos en Longhorn requiere especial atención a los parámetros de StorageClass, la afinidad de pods y la integración de copias de seguridad. El motor por volumen y la replicación sincrónica de Longhorn lo hacen ideal para cargas de trabajo de bases de datos, pero es necesario configurarlo correctamente para obtener rendimiento y confiabilidad de nivel de producción.

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

Ajuste del rendimiento para cargas de trabajo de bases de datos

Longhorn agrega una capa de replicación de almacenamiento entre la aplicación y el disco físico, lo que introduce cierta latencia en comparación con el acceso directo al disco local. Para la mayoría de las cargas de trabajo, esta sobrecarga es insignificante, pero las cargas de trabajo de bases de datos con patrones de escritura intensos necesitan ajustes para lograr un rendimiento óptimo.

Usar localidad de datos: mejor esfuerzo.Esto garantiza que una réplica esté en el mismo nodo que el pod de la base de datos, lo que significa que las lecturas llegan al disco local a velocidad NVMe/SSD. Las escrituras aún se replican en nodos remotos, pero la réplica local elimina los viajes de ida y vuelta de la red para las lecturas.

Dedicar discos a Longhorn.No comparta el disco del sistema operativo con datos de Longhorn. Agregue unidades NVMe o SSD dedicadas y configúrelas como discos Longhorn. Esto evita la contención de E/S entre el sistema operativo y los volúmenes de la base de datos.

# 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

Conjunto gestor de motor garantizado CPU. Los procesos del motorLonghorn consumen CPU para el procesamiento y la replicación de E/S. La configuraciónguaranteedInstanceManagerCPUreserva un porcentaje del nodo CPU para los administradores de instancias de Longhorn, lo que evita que CPU muera bajo carga.

Ajuste el recuento de réplicas.Para las bases de datos que ya tienen replicación a nivel de aplicación (replicación de transmisión PostgreSQL, replicación de grupo MySQL, conjuntos de réplicas MongoDB), puede reducir el recuento de réplicas Longhorn a 2 en lugar de 3. La replicación propia de la base de datos proporciona una capa adicional de protección de datos, y menos réplicas Longhorn significan menos amplificación de escritura y mejor rendimiento de escritura.

Utilice ext4 sobre xfs para pequeñas E/S aleatorias.Si bien xfs sobresale en escrituras secuenciales grandes, ext4 generalmente funciona mejor para el patrón de E/S aleatorio pequeño típico de las cargas de trabajo de bases de datos. ConfigurefsType: ext4en su StorageClass.

Programación de nodos y administración de discos

Longhorn proporciona un control detallado sobre qué nodos y discos se utilizan para la programación de volúmenes. Esto es fundamental en clústeres heterogéneos donde algunos nodos tienen almacenamiento NVMe rápido y otros tienen unidades SATA más lentas.

# 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

con Prometheus y Grafana

Longhorn expone las métricas Prometheus a través de un punto final de métricas integrado. Monitorear estas métricas es esencial para la planificación de la capacidad, el análisis del desempeño y las alertas proactivas.

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

Los paneles de panel clave de Grafana que se deben crear para el monitoreo de Longhorn incluyen: IOPS de volumen (lectura/escritura), rendimiento de volumen (MB/s), latencia de volumen (p50/p95/p99), progreso de reconstrucción de réplicas, capacidad y uso de almacenamiento de nodos, estado y antigüedad de la copia de seguridad y recuento de instantáneas por volumen.

Clúster k3s con pila de almacenamiento Longhorn completa

El siguiente diagrama muestra cómo Longhorn encaja en una pila de producción k3s completa, desde servidores básicos hasta módulos de aplicaciones, con administración Rancher y observabilidad Prometheus/Grafana.

con otras soluciones de almacenamiento Kubernetes

Longhorn no es la única opción de almacenamiento para Kubernetes. Comprender cómo se compara con las alternativas le ayudará a tomar la decisión correcta para sus necesidades específicas.

Longhorn vs Rook-Ceph:Ceph es el sistema más potente: admite almacenamiento de objetos, almacenamiento de archivos y almacenamiento en bloques con un sofisticado algoritmo de colocación CRUSH. Sin embargo, Ceph exige al menos 3 nodos OSD dedicados, una RAM significativa (mínimo 4 GB por demonio OSD) y una profunda experiencia operativa. Para los clústeres k3s con entre 3 y 10 nodos, Longhorn proporciona el 90 % del valor al 10 % del costo operativo.

Longhorn vs OpenEBS Mayastor:Mayastor utiliza NVMe-over-Fabrics para una replicación de alto rendimiento, logrando una latencia más baja que la replicación basada en TCP de Longhorn. Si su principal preocupación son IOPS sin procesar y una latencia inferior a milisegundos y tiene una infraestructura NVMe con redes RDMA, Mayastor puede ser la mejor opción. Para la mayoría de las implementaciones de k3s, el respaldo integrado, la recuperación ante desastres y la simplicidad operativa de Longhorn superan la ventaja de rendimiento de Mayastor.

Longhorn vs ruta local: el aprovisionador de ruta locales el almacenamiento predeterminado de k3s; simplemente crea directorios en el sistema de archivos local del nodo. Cero replicación, cero instantáneas, cero integración de respaldo. Está bien para el desarrollo pero es inaceptable para los datos de producción.

Mejores prácticas de producción

Estas recomendaciones se derivan del funcionamiento de Longhorn en docenas de clústeres k3s de producción que ejecutan cargas de trabajo de bases de datos.

1. Establecer reservas de recursos, por ejemplo administradores.Los administradores de instancias Longhorn (administradores de motores y réplicas) necesitan CPU garantizado para evitar paradas de E/S durante la presión del nodo. ConfigureguaranteedInstanceManagerCPUal menos al 12% en la configuración de Longhorn.

2. Utilice la política de recuperación de retención para volúmenes de bases de datos.Nunca utiliceDeletepara bases de datos PVC. Una políticaRetainmantiene el PV y sus datos incluso después de que se elimine el PVC, lo que le brinda una red de seguridad contra la eliminación accidental.

3. Desactive la antiafinidad suave de réplica para producción.ConfigurereplicaSoftAntiAffinity: falsepara garantizar que las réplicas siempre estén distribuidas en diferentes nodos. Con una antiafinidad suave, Longhorn puede programar múltiples réplicas en el mismo nodo cuando el espacio es reducido, frustrando el propósito de la replicación.

4. Reserve espacio de almacenamiento en cada nodo.ConfigurestorageMinimalAvailablePercentageal menos al 15%. Esto evita que Longhorn consuma todo el espacio en disco, lo que causaría problemas a nivel de nodo que afectarían a todos los pods.

5. Habilite el rescate automático.La configuraciónautoSalvagerecupera automáticamente volúmenes que entran en un estado de error cuando al menos una réplica aún está en buen estado. Esto reduce la intervención manual durante fallas de nodos.

6. Establezca la clase de prioridad en crítica para el clúster del sistema. Los componentes del controlador y del administrador deLonghorn nunca deben ser desalojados durante la presión del nodo. Establezca su clase de prioridad ensystem-cluster-criticalpara garantizar que sobrevivan al desalojo del pod.

7. Configure trabajos recurrentes para todos los volúmenes de producción.Cada volumen de producción debe tener trabajos recurrentes de instantáneas y de copia de seguridad. Instantáneas cada 4 horas para una reversión rápida, copias de seguridad diarias para recuperación ante desastres.

8. Pruebe la activación del volumen DR con regularidad.Cree una programación mensual para activar volúmenes de DR en su clúster en espera, verificar la integridad de los datos y practicar el procedimiento de conmutación por error. Un plan de recuperación ante desastres que nunca ha sido probado es sólo documentación.

9. Supervisar el estado del volumen de forma proactiva.Configure alertas Prometheus para volúmenes degradados y con errores, capacidad de almacenamiento de nodos, antigüedad de la copia de seguridad y estado de reconstrucción de réplicas. Cuando un usuario informa que la base de datos es lenta, el problema de almacenamiento ya lleva horas acumulándose.

10. Utilice discos de almacenamiento dedicados.Separe los datos de Longhorn del disco del sistema operativo. Esto evita la contención de E/S, brinda una administración de capacidad más limpia y evita el riesgo de llenar el disco del sistema operativo con datos de Longhorn.

Guía de implementación específica de la nube

AWS — EC2 con almacenamiento de instancia NVMe

Para implementaciones AWS, use instanciasi3.xlargeoi3en.xlargeque vienen con almacenamiento de instancias NVMe. Estos proporcionan rendimiento NVMe bruto a una fracción del costo de las IOPS de EBS aprovisionadas. Formatee el almacenamiento de la instancia y configúrelo como un disco 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: máquinas virtuales con Ultra Disk

En Azure, use máquinas virtualesStandard_L8s_v3oStandard_L16s_v3con almacenamiento NVMe local. Alternativamente, conecte Ultra Disks para obtener una latencia consistente de menos de milisegundos. Los Ultra Disks le permiten configurar IOPS y rendimiento de forma independiente.

# 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: máquinas virtuales con SSD local

GCP ofrece SSD local conectado a máquinas virtualesn2-standardoc3-standard. Los SSD locales proporcionan 375 GB por disco con hasta 680 000 IOPS de lectura. Conecte varios SSD locales y realice RAID para volúmenes más grandes.

# 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

Centro de datos local

Para implementaciones locales, utilice servidores con unidades SSD NVMe o SAS dedicadas para Longhorn. Separe el disco del sistema operativo de los discos de almacenamiento. Utilice una red de 10 GbE o 25 GbE entre nodos para garantizar que el tráfico de replicación no genere cuellos de botella: la replicación síncrona Longhorn genera tráfico de red proporcional al rendimiento de escritura multiplicado por el recuento 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 se entrega con una interfaz de usuario web incorporada que proporciona una interfaz visual para administrar volúmenes, instantáneas, copias de seguridad, nodos y configuraciones. Acceda a él a través del Ingress configurado durante la instalación o mediante el reenvío de puerto kubectl.

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

La interfaz de usuario proporciona varias vistas clave:Panelmuestra el estado del almacenamiento de todo el clúster, incluida la capacidad total, el espacio utilizado y el estado del volumen.Volumenenumera todos los volúmenes con su estado (correcto/degradado/con errores), tamaño, recuento de réplicas y nodo adjunto. Puede expandir, crear instantáneas, realizar copias de seguridad y restaurar volúmenes directamente desde esta vista. El nodomuestra la configuración de almacenamiento, la asignación de disco y el estado de programación de cada nodo.Copia de seguridadenumera todas las copias de seguridad almacenadas en el destino de la copia de seguridad con su volumen, tamaño y hora de creación.La configuraciónexpone todos los parámetros de configuración de Longhorn con descripciones.

Solución de problemas problemas comunes

Volúmenes degradados

Un volumen entra en estado Degradado cuando una o más réplicas no están en buen estado pero el volumen sigue funcionando. Las causas comunes incluyen falla del nodo, disco lleno o partición de red.

# 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

Volumen atascado al conectar/desconectar

# 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

Presión de espacio

# 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 deben realizarse con cuidado, ya que el sistema de almacenamiento sustenta todas las cargas de trabajo con estado. Realice siempre copias de seguridad de todos los volúmenes críticos antes de actualizar.

# 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

con operadores de bases de datos

Los operadores de bases de datos Kubernetes modernos (CloudNativePG, Percona Operador, Zalando Postgres Operador) funcionan perfectamente con Longhorn. El operador gestiona el ciclo de vida de la base de datos, mientras que Longhorn proporciona el almacenamiento subyacente con replicación, instantáneas y copias de seguridad.

# 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

Conclusión

Longhorn transforma k3s de una distribución Kubernetes liviana adecuada solo para el borde y el desarrollo a una plataforma lista para producción capaz de ejecutar cargas de trabajo con estado de misión crítica. Su arquitectura (motores por volumen, replicación sincrónica de múltiples nodos, instantáneas integradas y respaldo en almacenamiento de objetos en la nube, volúmenes de recuperación ante desastres, cifrado de volúmenes y expansión PVC en línea) ofrece almacenamiento de nivel empresarial sin complejidad de nivel empresarial.

La clave del éxito de Longhorn en la producción es triple. Primero, configúrelo correctamente desde el principio: use discos de almacenamiento dedicados, establezca factores de replicación y localidad de datos adecuados y cree StorageClasses diseñadas específicamente para diferentes tipos de cargas de trabajo. En segundo lugar, integre el respaldo en su arquitectura desde el primer día: instantáneas recurrentes para una reversión rápida, respaldos diarios en S3/GCS/Azure para recuperación ante desastres y volúmenes de recuperación ante desastres en un clúster en espera para el peor de los casos. En tercer lugar, supervise todo: el estado del volumen, la capacidad de almacenamiento del nodo, la antigüedad de la copia de seguridad y el estado de reconstrucción de la réplica; los problemas con el almacenamiento son invisibles hasta que se vuelven catastróficos.

La expansión dinámica PVC elimina una de las fuentes más comunes de incidentes de producción: quedarse sin espacio en disco. Con Longhorn, expandir un volumen de base de datos de 50Gi a 500Gi es un único comando kubectl sin tiempo de inactividad. Combinado con alertas Prometheus sobre umbrales de capacidad, puede expandir volúmenes de manera proactiva antes de que se vuelvan críticos o automatizar la expansión por completo.

Ya sea que esté ejecutando PostgreSQL, MySQL, MongoDB o Redis en k3s (en servidores bare metal, máquinas virtuales AWS EC2, Azure, instancias de GCP o hardware de centro de datos local), Longhorn proporciona la base de almacenamiento que le permite centrarse en sus aplicaciones en lugar de preocuparse por la durabilidad de los datos. Instálelo, configúrelo, monitorícelo y confíele sus datos de producción.