Armazenamento Longhorn para clusters k3s de produção: expansão, replicação e recuperação de desastres PVC dinâmicos

é o problema mais difícil no Kubernetes. A computação não tem estado e é fungível – mate um pod, agende outro. A rede possui plug-ins CNI e malhas de serviço maduros. Mas armazenamento? O armazenamento é onde reside o estado, onde os dados persistem durante as reinicializações, onde uma única configuração incorreta pode significar perda permanente de dados. Para clusters k3s que executam cargas de trabalho de produção (bancos de dados, filas de mensagens, estado de aplicativos), você precisa de uma solução de armazenamento que seja distribuída, resiliente, expansível e operável. Longhorn é essa solução.

Longhorn é um sistema de armazenamento em bloco distribuído leve, confiável e fácil de usar para Kubernetes. Originalmente desenvolvido pelo Rancher Labs (agora parte da SUSE), é um projeto de incubação CNCF desenvolvido especificamente para clusters onde a simplicidade é importante, mas a confiabilidade da produção não é negociável. Ao contrário do Ceph, que exige nós de armazenamento dedicados e profundo conhecimento, ou provisionador de caminho local, que oferece redundância zero, o Longhorn atinge o equilíbrio exato que os clusters k3s precisam: replicação distribuída entre nós, expansão dinâmica de volume, backup integrado para armazenamento de objetos em nuvem, instantâneos e recuperação de desastres – tudo gerenciado por meio de uma interface de usuário limpa e CRDs nativos do Kubernetes.

Este guia cobre tudo que você precisa para implantar o Longhorn no k3s para produção: arquitetura interna, métodos de instalação, configuração do StorageClass, expansão dinâmica do PVC, estratégias de replicação, backup e recuperação de desastres, criptografia de volume, ajuste de desempenho para bancos de dados, monitoramento e solução de problemas. Cada recomendação vem com configuração testada em produção que você pode adaptar ao seu ambiente.

Compreender a arquitetura do Longhorn é essencial para tomar decisões informadas sobre replicação, desempenho e tratamento de falhas. O Longhorn é composto por três componentes principais que trabalham juntos para fornecer armazenamento de blocos distribuídos sobre os discos locais anexados aos nós Kubernetes.

OLonghorn Manageré executado como um DaemonSet em cada nó do cluster. É o plano de controle do Longhorn — ele lida com chamadas API, orquestra a criação de volumes, gerencia replicação, coordena snapshots e backups e se comunica com o servidor Kubernetes API para gerenciar o ciclo de vida PersistentVolume e PersistentVolumeClaim. Quando você cria um PVC que faz referência a um Longhorn StorageClass, o Longhorn Manager recebe a solicitação por meio do driver CSI, provisiona o volume e agenda suas réplicas nos nós disponíveis.

OLonghorn Engineé um controlador de armazenamento por volume implementado como um processo de espaço de usuário Linux (baseado em um fork do Rancher Longhorn Engine). Cada volume obtém seu próprio processo de mecanismo dedicado em execução no nó ao qual o volume está anexado. O mecanismo lida com todas as E/S de leitura e gravação desse volume, replicando as gravações de forma síncrona para todas as réplicas configuradas antes de confirmar a gravação no aplicativo. Essa arquitetura por volume significa que uma falha ou travamento no mecanismo de um volume não afeta nenhum outro volume — uma propriedade de isolamento crítica para produção.

Réplicassão os processos reais de armazenamento de dados. Cada réplica armazena uma cópia completa dos dados do volume no disco local do nó onde é executada. Por padrão, o Longhorn cria três réplicas para cada volume, distribuídas em nós diferentes (e, opcionalmente, em zonas diferentes). As réplicas usam um mecanismo de cópia na gravação para instantâneos, tornando a criação de instantâneos instantânea, independentemente do tamanho do volume.

Esta arquitetura oferece diversas propriedades importantes para uso em produção.Tolerância a falhas:com três réplicas em três nós, o volume sobrevive a duas falhas simultâneas de nós. Isolamento:cada volume tem seu próprio processo de mecanismo, portanto, um bug ou travamento em um volume não pode ser transmitido em cascata. Simplicidade do:sem nós de armazenamento dedicados, sem clusters Ceph ou GlusterFS separados – o Longhorn é executado nos mesmos nós de trabalho que seus pods de aplicativo, usando seus discos locais.Kubernetes nativo:tudo é gerenciado por meio de CRDs, kubectl e da interface Kubernetes CSI.

Instalando Longhorn no k3s

Longhorn pode ser instalado no k3s por meio de três métodos: gráfico Helm (recomendado para produção), Rancher App Marketplace (se você tiver o Rancher gerenciando seu cluster) ou aplicação direta de kubectl. Antes de instalar, certifique-se de que seus nós atendam aos pré-requisitos.

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

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

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

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

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

via Helm (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

Aqui está umvalues.yamlde nível de produção com padrões 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

via Rancher App Marketplace

Se o Rancher gerenciar seu cluster k3s, navegue atéApps & Mercado → Gráficos → Longhornna IU do Rancher. Selecione seu namespace de destino (longhorn-system), configure os valores por meio da interface do formulário e clique em Instalar. O Rancher lida com o gerenciamento do ciclo de vida da Helm e o rastreamento de atualizações automaticamente.

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

: Torne o Longhorn o StorageClass padrão

# 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 produção

O Longhorn StorageClass padrão funciona para desenvolvimento, mas as cargas de trabalho de produção precisam de configurações específicas para diferentes casos de uso – os bancos de dados precisam de alta replicação e localidade de dados específica, o processamento temporário precisa de volumes rápidos de réplica única e os volumes compartilhados precisam de suporte 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

Expansão Dinâmica PVC

Um dos recursos de produção mais importantes do Longhorn é a expansão dinâmica do PVC — a capacidade de aumentar o tamanho de um volume persistente sem tempo de inatividade, sem perda de dados e sem intervenção manual além de um único comando kubectl ou alteração de manifesto. Isso é fundamental para bancos de dados onde o crescimento dos dados é imprevisível e a falta de espaço em disco significa uma interrupção.

Longhorn suporta a expansão online(o volume permanece conectado e montado enquanto cresce) e a expansão offline(o volume é desconectado primeiro). A expansão online é a abordagem padrão e recomendada para produção porque evita o tempo de inatividade do aplicativo.

Habilitando Expansão de Volume no StorageClass

O principal requisito para expansão dinâmica do PVC é que o StorageClass deve terallowVolumeExpansion: true. O StorageClass padrão do Longhorn já inclui isso, mas se você tiver StorageClasses customizados, verifique se esse campo está definido.

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

passo a passo: expandindo uma PVC dinamicamente

# 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

Automatizando Expansão PVC com Alertas

Em produção, você não deve esperar até que um disco esteja 86% cheio para expandi-lo manualmente. Use alertas Prometheus para acionar a expansão automaticamente ou alertar o engenheiro de plantão antes que a capacidade se torne 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"

Longhorn replica dados de volume em vários nós para proteção contra falhas de hardware. O fator de replicação e as configurações de localidade dos dados controlam a compensação entre durabilidade, desempenho e eficiência de armazenamento.

Fator de replicaçãodetermina quantas cópias dos dados existem. O padrão é 3, o que significa que cada gravação é armazenada em três nós diferentes. Para bancos de dados de produção, 3 é o valor mínimo recomendado. Você pode defini-lo como 2 para cargas de trabalho menos críticas para economizar armazenamento ou deixá-lo como 1 para volumes temporários/de cache onde a perda de dados é aceitável.

Localidade dos dadoscontrola se o Longhorn tenta manter uma réplica no mesmo nó que o pod que consome o volume. Existem três modos:

• desativado— As réplicas são agendadas exclusivamente com base no espaço disponível e na antiafinidade. O pod pode ler uma réplica em um nó remoto, adicionando latência de rede a cada operação de E/S.
• melhor esforço— Longhorn tenta colocar uma réplica no mesmo nó que o pod de consumo. Se o nó local ficar sem espaço ou o pod migrar, o volume ainda funcionará, mas poderá ter uma latência um pouco maior. Esta é a configuração recomendada para a maioria das cargas de trabalho.
• strict-local— O volume só pode ser usado em um nó que tenha uma réplica local. Se o pod estiver programado para um nó sem uma réplica local, a anexação do volume falhará. Use isso apenas para cargas de trabalho de réplica única sensíveis à latência, nas quais você aceita a compensação de durabilidade.

# 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

Longhorn fornece dois mecanismos distintos de proteção de dados: instantâneos(local, instantâneo, para reversão rápida) e backups(remotos, para armazenamento de objetos, para recuperação de desastres). Compreender quando usar cada um é fundamental.

são armazenados localmente nos mesmos discos que as réplicas de volume. Eles são criados instantaneamente usando copy-on-write — nenhum dado é copiado no momento do snapshot, apenas novas gravações após o snapshot alocam espaço adicional. Os instantâneos são excelentes para reversão rápida antes de uma migração ou implantação arriscada, mas não protegem contra falhas de nós ou discos porque residem no mesmo armazenamento que o volume.

copiam os dados do volume para um destino de backup externo – S3, GCS, Azure Blob ou qualquer armazenamento compatível com S3 (MinIO, Wasabi). Os backups são incrementais no nível do bloco: apenas os blocos que foram alterados desde o último backup são transferidos. Isso torna os backups recorrentes rápidos e eficientes em termos de armazenamento. Os backups protegem contra a perda total do cluster porque existem de forma independente.

Configurando o destino de backup

# 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

e instantâneo 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

# 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

Longhorn fornece um mecanismo integrado de recuperação de desastres por meio de volumes DR.— volumes de espera em um cluster secundário que extraem continuamente backups incrementais do destino de backup do cluster primário. Quando ocorre um desastre, você ativa o volume de DR e ele se torna um volume regular de leitura e gravação, permitindo que o cluster secundário assuma o controle.

Configurando volumes DR

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

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

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

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

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

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

Longhorn suporta criptografia em nível de volume usando Linux LUKS2. Os volumes criptografados protegem os dados em repouso no disco subjacente — mesmo que alguém obtenha acesso físico ao armazenamento do servidor, não poderá ler os dados do volume sem a chave de criptografia.

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

Por padrão, os volumes Longhorn são ReadWriteOnce (RWO) — eles podem ser montados por um único pod em um único nó. Para cargas de trabalho que precisam de armazenamento compartilhado em vários pods (por exemplo, uploads de mídia compartilhada, arquivos de configuração, artefatos de modelo de ML), o Longhorn oferece suporte a ReadWriteMany (RWX) por meio de um servidor NFS integrado.

Quando um PVC solicita o modo de acesso RWX, o Longhorn implanta automaticamente um pod de gerenciador de compartilhamento que executa um servidor NFS apoiado pelo volume Longhorn. Vários pods podem então montar o volume simultaneamente por NFS. Isso é mais simples do que implantar um servidor NFS separado, mas adiciona uma camada de sobrecarga de rede em comparação ao acesso direto ao bloco.

# 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

no Longhorn

A execução de bancos de dados no Longhorn requer atenção cuidadosa aos parâmetros do StorageClass, afinidade do pod e integração de backup. O mecanismo por volume e a replicação síncrona do Longhorn o tornam adequado para cargas de trabalho de banco de dados, mas você precisa configurá-lo corretamente para obter desempenho e confiabilidade de nível de produção.

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

para cargas de trabalho de banco de dados

Longhorn adiciona uma camada de replicação de armazenamento entre o aplicativo e o disco físico, o que introduz alguma latência em comparação ao acesso direto ao disco local. Para a maioria das cargas de trabalho, essa sobrecarga é insignificante, mas as cargas de trabalho de banco de dados com padrões de gravação pesados ​​precisam de ajuste para atingir o desempenho ideal.

Use localidade de dados: melhor esforço.Isso garante que uma réplica esteja no mesmo nó que o pod do banco de dados, o que significa que as leituras atingem o disco local na velocidade NVMe/SSD. As gravações ainda são replicadas para nós remotos, mas a réplica local elimina viagens de ida e volta da rede para leituras.

Discos dedicados ao Longhorn.Não compartilhe o disco do sistema operacional com dados do Longhorn. Adicione unidades NVMe ou SSD dedicadas e configure-as como discos Longhorn. Isso evita a contenção de E/S entre o sistema operacional e os volumes do banco de dados.

# 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

Definir gerenciador de motor garantido CPU. Os processos do mecanismoLonghorn consomem CPU para processamento e replicação de E/S. A configuraçãoguaranteedInstanceManagerCPUreserva uma porcentagem do nó CPU para gerenciadores de instâncias Longhorn, evitando a falta de CPU sob carga.

Ajuste a contagem de réplicas.Para bancos de dados que já possuem replicação em nível de aplicativo (replicação de streaming PostgreSQL, replicação de grupo MySQL, conjuntos de réplicas MongoDB), você pode reduzir a contagem de réplicas Longhorn para 2 em vez de 3. A própria replicação do banco de dados fornece uma camada adicional de proteção de dados, e menos réplicas Longhorn significa menos amplificação de gravação e melhor rendimento de gravação.

Use ext4 sobre xfs para pequenas E/S aleatórias.Embora o xfs seja excelente em grandes gravações sequenciais, o ext4 geralmente tem melhor desempenho para pequenos padrões de E/S aleatórios típicos de cargas de trabalho de banco de dados. DefinafsType: ext4em seu StorageClass.

Longhorn fornece controle refinado sobre quais nós e discos são usados para agendamento de volume. Isso é fundamental em clusters heterogêneos onde alguns nós possuem armazenamento NVMe rápido e outros possuem unidades SATA mais 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

com Prometheus e Grafana

Longhorn expõe métricas Prometheus por meio de um endpoint de métricas integrado. O monitoramento dessas métricas é essencial para planejamento de capacidade, análise de desempenho e alertas proativos.

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

a serem criados para monitoramento Longhorn incluem: IOPS de volume (leitura/gravação), taxa de transferência de volume (MB/s), latência de volume (p50/p95/p99), progresso de reconstrução de réplica, capacidade e uso de armazenamento de nó, status e idade de backup e contagem de snapshots por volume.

k3s com pilha de armazenamento Longhorn completa

O diagrama a seguir mostra como o Longhorn se encaixa em uma pilha de produção k3s completa, desde servidores bare metal até pods de aplicativos, com gerenciamento Rancher e observabilidade Prometheus/Grafana.

com outras soluções de armazenamento Kubernetes

Longhorn não é a única opção de armazenamento para o Kubernetes. Compreender como ele se compara às alternativas ajuda você a fazer a escolha certa para suas necessidades específicas.

Longhorn vs Rook-Ceph:Ceph é o sistema mais poderoso – ele suporta armazenamento de objetos, armazenamento de arquivos e armazenamento de blocos com um sofisticado algoritmo de posicionamento CRUSH. No entanto, o Ceph exige pelo menos três nós OSD dedicados, RAM significativa (mínimo de 4 GB por daemon OSD) e profundo conhecimento operacional. Para clusters k3s com 3 a 10 nós, o Longhorn fornece 90% do valor por 10% do custo operacional.

Longhorn vs OpenEBS Mayastor:Mayastor usa NVMe-over-Fabrics para replicação de alto desempenho, alcançando menor latência do que a replicação baseada em TCP do Longhorn. Se IOPS brutos e latência abaixo de um milissegundo forem sua principal preocupação e você tiver infraestrutura NVMe com rede RDMA, o Mayastor pode ser a melhor escolha. Para a maioria das implantações k3s, o backup integrado, DR e a simplicidade operacional do Longhorn superam a vantagem de desempenho do Mayastor.

Longhorn vs caminho local: o provisionador de caminho localé o armazenamento padrão do k3s - ele simplesmente cria diretórios no sistema de arquivos local do nó. Zero replicação, zero snapshots, zero integração de backup. É bom para o desenvolvimento, mas inaceitável para dados de produção.

Essas recomendações são extraídas da operação do Longhorn em dezenas de clusters k3s de produção que executam cargas de trabalho de banco de dados.

1. Configure reservas de recursos para gerenciadores de instâncias. Os gerenciadores de instâncias Longhorn(gerenciadores de mecanismo e de réplica) precisam de CPU garantido para evitar paralisações de E/S durante a pressão do nó. DefinaguaranteedInstanceManagerCPUpara pelo menos 12% nas configurações do Longhorn.

2. Use a política de recuperação Retain para volumes de banco de dados.Nunca useDeletepara bancos de dados PVCs. Uma políticaRetainmantém o PV e seus dados mesmo após a exclusão do PVC, proporcionando uma rede de segurança contra exclusão acidental.

3. Desative a antiafinidade suave da réplica para produção.ConfigurereplicaSoftAntiAffinity: falsepara garantir que as réplicas estejam sempre espalhadas por diferentes nós. Com a antiafinidade suave, o Longhorn pode agendar múltiplas réplicas no mesmo nó quando o espaço é limitado – anulando o propósito da replicação.

4. Reserve espaço de armazenamento em cada nó.DefinastorageMinimalAvailablePercentagepara pelo menos 15%. Isso evita que o Longhorn consuma todo o espaço em disco, o que causaria problemas no nível do nó que afetariam todos os pods.

5. Habilite o salvamento automático.A configuraçãoautoSalvagerecupera automaticamente volumes que entram em estado de falha quando pelo menos uma réplica ainda está íntegra. Isso reduz a intervenção manual durante falhas de nós.

6. Configure a classe de prioridade como crítica ao cluster do sistema. Os componentes do gerenciador e do driver doLonghorn nunca devem ser removidos durante a pressão do nó. Defina sua prioridadeClass comosystem-cluster-criticalpara garantir que eles sobrevivam ao despejo do pod.

7. Configure tarefas recorrentes para todos os volumes de produção.Cada volume de produção deve ter tarefas recorrentes de captura instantânea e de backup. Instantâneos a cada 4 horas para reversão rápida, backups diários para recuperação de desastres.

8. Teste a ativação do volume DR regularmente.Crie um planejamento mensal para ativar volumes de DR em seu cluster em espera, verificar a integridade dos dados e praticar o procedimento de failover. Um plano de DR que nunca foi testado é apenas documentação.

9. Monitore a integridade do volume de forma proativa.Configure alertas Prometheus para volumes degradados e com falha, capacidade de armazenamento do nó, idade do backup e status de reconstrução da réplica. No momento em que um usuário relata um banco de dados lento, o problema de armazenamento já vem crescendo há horas.

10. Use discos de armazenamento dedicados.Separe os dados do Longhorn do disco do sistema operacional. Isso evita a contenção de E/S, proporciona um gerenciamento de capacidade mais limpo e evita o risco de preencher o disco do sistema operacional com dados do Longhorn.

Orientação de implantação específica para nuvem

AWS — EC2 com armazenamento de instância NVMe

Para implantações AWS, use instânciasi3.xlargeoui3en.xlargeque vêm com armazenamento de instância NVMe. Eles fornecem desempenho NVMe bruto por uma fração do custo do IOPS EBS provisionado. Formate o armazenamento da instância e configure-o como um 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 — VMs com Ultra Disk

No Azure, use VMsStandard_L8s_v3ouStandard_L16s_v3com armazenamento NVMe local. Como alternativa, anexe Ultra Disks para obter latência consistente de menos de um milissegundo. Os Ultra Disks permitem que você configure IOPS e taxa de transferência de forma independente.

# 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 — VMs com SSD local

GCP oferece SSD local conectado a VMsn2-standardouc3-standard. Os SSDs locais fornecem 375 GB por disco com até 680.000 IOPS de leitura. Anexe vários SSDs locais e faça RAID deles para volumes maiores.

# 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

Para implantações locais, use servidores com unidades SSD NVMe ou SAS dedicadas para Longhorn. Separe o disco do sistema operacional dos discos de armazenamento. Use uma rede de 10 GbE ou 25 GbE entre nós para garantir que o tráfego de replicação não cause gargalos. A replicação síncrona do Longhorn gera tráfego de rede proporcional à taxa de transferência de gravação multiplicada pela contagem 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 vem com uma interface web integrada que fornece uma interface visual para gerenciar volumes, instantâneos, backups, nós e configurações. Acesse-o por meio do Ingress configurado durante a instalação ou 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

A UI fornece diversas visualizações principais: PainelOmostra a integridade do armazenamento em todo o cluster, incluindo capacidade total, espaço usado e status do volume. Volumelista todos os volumes com seu estado (íntegro/degradado/com falha), tamanho, contagem de réplicas e nó anexado. Você pode expandir, capturar instantâneos, fazer backup e restaurar volumes diretamente dessa visualização. Nómostra a configuração de armazenamento, alocação de disco e status de agendamento de cada nó. Backuplista todos os backups armazenados no destino de backup com seu volume, tamanho e hora de criação.A configuraçãoexpõe todos os parâmetros de configuração do Longhorn com descrições.

Solução de problemas comuns

Um volume entra no estado Degradado quando uma ou mais réplicas não estão íntegras, mas o volume ainda está funcional. As causas comuns incluem falha de nó, disco cheio ou partição de rede.

# 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

preso ao anexar/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

# 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 devem ser realizadas com cuidado, pois o sistema de armazenamento sustenta todas as cargas de trabalho com estado. Sempre faça backups de todos os volumes críticos antes de atualizar.

# 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

com Operadores de Banco de Dados

Operadores de banco de dados Kubernetes modernos (CloudNativePG, Operador Percona, Operador Zalando Postgres) funcionam perfeitamente com Longhorn. O operador gerencia o ciclo de vida do banco de dados enquanto o Longhorn fornece o armazenamento subjacente com replicação, instantâneos e backup.

# 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

Longhorn transforma o k3s de uma distribuição Kubernetes leve, adequada apenas para borda e desenvolvimento, em uma plataforma pronta para produção, capaz de executar cargas de trabalho com estado de missão crítica. Sua arquitetura — mecanismos por volume, replicação síncrona de vários nós, snapshot integrado e backup para armazenamento de objetos em nuvem, volumes de DR, criptografia de volume e expansão on-line PVC — oferece armazenamento de nível empresarial sem complexidade de nível empresarial.

A chave para o sucesso do Longhorn na produção é tripla. Primeiro, configure-o corretamente desde o início: use discos de armazenamento dedicados, defina fatores de replicação e localidade de dados apropriados e crie StorageClasses específicas para diferentes tipos de carga de trabalho. Em segundo lugar, integre o backup à sua arquitetura desde o primeiro dia: snapshots recorrentes para reversão rápida, backups diários para S3/GCS/Azure para recuperação de desastres e volumes de DR em um cluster de espera para o pior cenário. Terceiro, monitore tudo: integridade do volume, capacidade de armazenamento do nó, idade do backup e status de reconstrução da réplica — os problemas com o armazenamento são invisíveis até se tornarem catastróficos.

A expansão dinâmica do PVC elimina uma das fontes mais comuns de incidentes de produção: falta de espaço em disco. Com o Longhorn, expandir um volume de banco de dados de 50Gi para 500Gi é um único comando kubectl com tempo de inatividade zero. Combinado com alertas Prometheus sobre limites de capacidade, você pode expandir proativamente os volumes antes que se tornem críticos ou automatizar totalmente a expansão.

Esteja você executando PostgreSQL, MySQL, MongoDB ou Redis em k3s — em servidores bare metal, AWS EC2, VMs Azure, instâncias GCP ou hardware de datacenter local — o Longhorn fornece a base de armazenamento que permite que você se concentre em seus aplicativos em vez de se preocupar com a durabilidade dos dados. Instale-o, configure-o, monitore-o e confie-lhe seus dados de produção.