Longhorn Storage для производственных кластеров k3s: динамическое расширение PVC, репликация и аварийное восстановление

Хранилище — самая сложная проблема в Kubernetes. Вычисления не сохраняют состояние и взаимозаменяемы — уничтожьте модуль, запланируйте другой. Networking имеет зрелые плагины CNI и сервисные сетки. Но хранение? Хранилище — это место, где живет состояние, где данные сохраняются после перезапуска, где единственная неправильная конфигурация может означать безвозвратную потерю данных. Для кластеров k3s, на которых выполняются производственные рабочие нагрузки — базы данных, очереди сообщений, состояние приложений — вам необходимо распределенное, отказоустойчивое, расширяемое и работоспособное решение для хранения данных. Longhorn – это решение.

Longhorn — это легкая, надежная и простая в использовании распределенная блочная система хранения данных для Kubernetes. Первоначально разработанный Rancher Labs (теперь часть SUSE), это инкубационный проект CNCF, специально созданный для кластеров, где простота имеет значение, но надежность производства не подлежит обсуждению. В отличие от Ceph, которому требуются выделенные узлы хранения и глубокий опыт, или поставщика локальных путей, который предлагает нулевую избыточность, Longhorn обеспечивает точный баланс, необходимый кластерам k3s: распределенная репликация между узлами, динамическое расширение тома, интегрированное резервное копирование в облачное хранилище объектов, моментальные снимки и аварийное восстановление — все это управляется через чистый пользовательский интерфейс и CRD, родные для Kubernetes.

В этом руководстве описывается все, что вам нужно для развертывания Longhorn на k3s для производства: внутренние характеристики архитектуры, методы установки, конфигурация StorageClass, динамическое расширение PVC, стратегии репликации, резервное копирование и аварийное восстановление, шифрование томов, настройка производительности баз данных, мониторинг и устранение неполадок. Каждая рекомендация сопровождается протестированной на производстве конфигурацией, которую вы можете адаптировать к своей среде.

Архитектура Longhorn

Понимание архитектуры Longhorn необходимо для принятия обоснованных решений относительно репликации, производительности и обработки сбоев. Longhorn состоит из трех основных компонентов, которые работают вместе, обеспечивая распределенное блочное хранилище поверх локальных дисков, подключенных к вашим узлам Kubernetes.

Longhorn Managerработает как DaemonSet на каждом узле кластера. Это плоскость управления Longhorn — она обрабатывает вызовы API, организует создание томов, управляет репликацией, координирует снимки и резервные копии, а также взаимодействует с сервером Kubernetes API для управления жизненным циклом PersistentVolume и PersistentVolumeClaim. Когда вы создаете PVC, который ссылается на Longhorn StorageClass, Longhorn Manager получает запрос через драйвер CSI, выделяет том и планирует его репликацию на доступных узлах.

Longhorn Engine— это контроллер хранилища для каждого тома, реализованный как процесс пользовательского пространства Linux (на основе ответвления Rancher Longhorn Engine). Каждый том получает свой собственный выделенный процесс ядра, работающий на узле, к которому подключен том. Механизм обрабатывает все операции чтения и записи для этого тома, синхронно реплицируя записи на все настроенные реплики перед подтверждением записи приложению. Такая потомная архитектура означает, что сбой или зависание механизма одного тома не влияет на другие тома — это критическое свойство изоляции для рабочей среды.

Реплики— это реальные процессы хранения данных. Каждая реплика хранит полную копию данных тома на локальном диске узла, на котором она работает. По умолчанию Longhorn создает три реплики для каждого тома, распределенные по разным узлам (и, возможно, по разным зонам). Реплики используют механизм копирования при записи для моментальных снимков, что делает создание моментальных снимков мгновенным, независимо от размера тома.

Эта архитектура обеспечивает несколько ключевых свойств для производственного использования.Отказоустойчивость:с тремя репликами на трех узлах позволяет тому выдерживать два одновременных сбоя узла. Изоляция: каждый томимеет свой собственный процесс ядра, поэтому ошибка или зависание в одном томе не могут возникнуть каскадно.Простота: внет выделенных узлов хранения, нет отдельных кластеров Ceph или GlusterFS — Longhorn работает на тех же рабочих узлах, что и модули ваших приложений, используя их локальные диски.Встроенный Kubernetes: ввсе управление осуществляется через CRD, kubectl и интерфейс Kubernetes CSI.

Установка Longhorn на k3s

Longhorn можно установить на k3s тремя способами: диаграмма Helm (рекомендуется для рабочей среды), магазин приложений Rancher (если вашим кластером управляет Rancher) или прямое применение kubectl. Перед установкой убедитесь, что ваши узлы соответствуют предварительным требованиям.

Предварительные требования

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

через Helm (рекомендуется)

# 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

Вот серийныйvalues.yamlс настроенными настройками по умолчанию:

# 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

через магазин приложений Rancher

Если Rancher управляет вашим кластером k3s, перейдите в разделApps & Торговая площадка → Графики → Longhornв пользовательском интерфейсе Rancher. Выберите целевое пространство имен (longhorn-system), настройте значения через интерфейс формы и нажмите «Установить». Rancher автоматически управляет жизненным циклом Helm и отслеживает обновления.

Установка через 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

После установки: сделайте Longhorn классом хранения по умолчанию

# 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

для производства

Стандартный класс Longhorn StorageClass подходит для разработки, но производственные рабочие нагрузки требуют определенных конфигураций для разных случаев использования: базам данных требуется высокая репликация и определенная локальность данных, временная обработка требует быстрых томов с одной репликой, а общие тома нуждаются в поддержке 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

Динамическое расширение PVC

Одной из наиболее важных производственных функций Longhorn является динамическое расширение PVC — возможность увеличивать размер постоянного тома без простоев, без потери данных и без ручного вмешательства, за исключением одной команды kubectl или изменения манифеста. Это критически важно для баз данных, где рост данных непредсказуем, а нехватка дискового пространства означает сбой.

Longhorn поддерживает как онлайн-расширение(том остается подключенным и смонтированным по мере роста), так и автономное расширение(том сначала отсоединяется). Онлайн-расширение — это стандартный и рекомендуемый подход для рабочей среды, поскольку он позволяет избежать простоя приложения.

Включение расширения тома в StorageClass

Ключевым требованием для динамического расширения PVC является то, что StorageClass должен иметьallowVolumeExpansion: true. Класс StorageClass по умолчанию в Longhorn уже включает его, но если у вас есть собственные классы StorageClass, убедитесь, что это поле установлено.

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

: шаг за шагом: динамическое расширение PVC

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

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

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

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

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

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

Автоматизация расширения PVC с помощью оповещений

В производственной среде не следует ждать, пока диск заполнится на 86 %, чтобы расширить его вручную. Используйте оповещения Prometheus для автоматического запуска расширения или оповещайте дежурного инженера до того, как емкость станет критической.

# 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 реплицирует данные тома на нескольких узлах для защиты от аппаратных сбоев. Коэффициент репликации и настройки локальности данных определяют компромисс между надежностью, производительностью и эффективностью хранения.

Коэффициент репликацииопределяет, сколько копий данных существует. Значение по умолчанию — 3, что означает, что каждая запись сохраняется на трех разных узлах. Для производственных баз данных минимальное рекомендуемое значение — 3. Вы можете установить значение 2 для менее критичных рабочих нагрузок для экономии места или оставить значение 1 для временных томов/кэша, где потеря данных допустима.

Локальность данныхконтролирует, пытается ли Longhorn хранить реплику на том же узле, что и модуль, потребляющий том. Есть три режима:

• отключен— планирование реплик осуществляется исключительно на основе доступного пространства и антисходства. Модуль может читать данные из реплики на удаленном узле, увеличивая задержку в сети для каждой операции ввода-вывода.
• Максимальное усилие— Longhorn пытается разместить одну реплику на том же узле, что и потребляющий модуль. Если на локальном узле заканчивается место или модуль мигрирует, том по-прежнему работает, но задержка может быть немного выше. Это рекомендуемая настройка для большинства рабочих нагрузок.
• строго локальный— том можно использовать только на узле, имеющем локальную реплику. Если модуль запланирован на узле без локальной реплики, присоединение тома не удастся. Используйте это только для чувствительных к задержке рабочих нагрузок с одной репликой, где вы принимаете компромисс между долговечностью.

# 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 предоставляет два различных механизма защиты данных: снимки(локальные, мгновенные, для быстрого отката) и резервные копии(удаленные, в объектное хранилище, для аварийного восстановления). Понимание того, когда использовать каждый из них, имеет решающее значение.

хранятся локально на тех же дисках, что и реплики томов. Они создаются мгновенно с использованием копирования при записи — во время снимка данные не копируются, только новые записи после снимка выделяют дополнительное пространство. Снимки отлично подходят для быстрого отката перед рискованной миграцией или развертыванием, но они не защищают от сбоя узла или диска, поскольку находятся в том же хранилище, что и том.

данные тома копируются на внешний целевой объект резервного копирования — S3, GCS, Azure Blob или любое хранилище, совместимое с S3 (MinIO, Wasabi). Резервные копии являются инкрементальными на уровне блоков: передаются только те блоки, которые изменились с момента последнего резервного копирования. Это делает повторяющиеся резервные копии быстрыми и эффективными для хранения. Резервные копии защищают кластер от полной потери, поскольку существуют независимо.

Настройка цели резервного копирования

# 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

и снимок 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 предоставляет встроенный механизм аварийного восстановления с помощью томов аварийного восстановления.— резервные тома во вторичном кластере, которые непрерывно извлекают инкрементные резервные копии из целевого объекта резервного копирования основного кластера. В случае аварии вы активируете том 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 поддерживает шифрование на уровне тома с использованием Linux LUKS2. Зашифрованные тома защищают данные, хранящиеся на базовом диске — даже если кто-то получит физический доступ к хранилищу сервера, он не сможет прочитать данные тома без ключа шифрования.

# 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) Поддержка

По умолчанию тома Longhorn имеют ReadWriteOnce (RWO) — их можно смонтировать одним модулем на одном узле. Для рабочих нагрузок, которым требуется общее хранилище для нескольких модулей (например, общая загрузка мультимедиа, файлы конфигурации, артефакты модели ML), Longhorn поддерживает ReadWriteMany (RWX) через интегрированный сервер NFS.

Когда PVC запрашивает режим доступа RWX, Longhorn автоматически развертывает модуль диспетчера общих ресурсов, на котором работает сервер NFS, поддерживаемый томом Longhorn. Затем несколько модулей могут одновременно монтировать том через NFS. Это проще, чем развертывание отдельного сервера NFS, но добавляет дополнительный уровень сетевых издержек по сравнению с прямым блочным доступом.

# 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

на Longhorn

Запуск баз данных на Longhorn требует пристального внимания к параметрам StorageClass, привязке модулей и интеграции резервного копирования. Потомный механизм Longhorn и синхронная репликация делают его хорошо подходящим для рабочих нагрузок баз данных, но вам необходимо правильно настроить его, чтобы получить производительность и надежность производственного уровня.

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

Настройка производительности для рабочих нагрузок баз данных

Longhorn добавляет уровень репликации хранилища между приложением и физическим диском, что приводит к некоторой задержке по сравнению с прямым доступом к локальному диску. Для большинства рабочих нагрузок эти накладные расходы незначительны, но рабочие нагрузки базы данных с тяжелыми шаблонами записи требуют настройки для достижения оптимальной производительности.

Использовать локальность данных: максимально возможное.Это гарантирует, что одна реплика находится на том же узле, что и модуль базы данных, а это означает, что операции чтения выполняются на локальном диске со скоростью NVMe/SSD. Записи по-прежнему реплицируются на удаленные узлы, но локальная реплика исключает повторные обращения по сети при чтении.

Выделите диски для Longhorn.Не используйте общий диск ОС с данными Longhorn. Добавьте выделенные диски NVMe или SSD и настройте их как диски Longhorn. Это предотвращает конфликт операций ввода-вывода между томами операционной системы и базы данных.

# 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

Установите гарантированный менеджер двигателя CPU. Процессы ядраLonghorn используют CPU для обработки и репликации ввода-вывода. ПараметрguaranteedInstanceManagerCPUрезервирует процент узла CPU для менеджеров экземпляров Longhorn, предотвращая «зависание» CPU под нагрузкой.

Настройте количество реплик.Для баз данных, в которых уже есть репликация на уровне приложения (потоковая репликация PostgreSQL, групповая репликация MySQL, наборы реплик MongoDB), вы можете уменьшить количество реплик Longhorn до 2 вместо 3. Собственная репликация базы данных обеспечивает дополнительный уровень защиты данных, а меньшее количество реплик Longhorn означает меньшее усиление записи и лучшую пропускную способность записи.

Используйте ext4 поверх xfs для небольших произвольных операций ввода-вывода.Хотя xfs превосходно справляется с большими последовательными операциями записи, ext4 обычно лучше работает с небольшими случайными шаблонами ввода-вывода, типичными для рабочих нагрузок базы данных. УстановитеfsType: ext4в свой StorageClass.

Планирование узлов и управление дисками

Longhorn обеспечивает детальный контроль над тем, какие узлы и диски используются для планирования томов. Это критически важно в гетерогенных кластерах, где некоторые узлы имеют быстрое хранилище NVMe, а другие — более медленные диски SATA.

# 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

Мониторинг с помощью Prometheus и Grafana

Longhorn предоставляет метрики Prometheus через встроенную конечную точку метрик. Мониторинг этих показателей необходим для планирования мощности, анализа производительности и упреждающего оповещения.

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

, которые необходимо создать для мониторинга Longhorn, включают в себя: IOPS тома (чтение/запись), пропускную способность тома (МБ/с), задержку тома (p50/p95/p99), ход восстановления реплики, емкость и использование хранилища узла, состояние и срок резервного копирования, а также количество снимков на том.

Кластер k3s с полным стеком хранения данных Longhorn

На следующей диаграмме показано, как Longhorn вписывается в полный производственный стек k3s, от «голых» серверов до модулей приложений, с управлением Rancher и возможностью наблюдения Prometheus/Grafana.

с другими решениями хранения данных Kubernetes

Longhorn — не единственный вариант хранения данных для Kubernetes. Понимание его сравнения с альтернативами поможет вам сделать правильный выбор в соответствии с вашими конкретными требованиями.

Longhorn против Rook-Ceph:Ceph — более мощная система — она поддерживает хранилище объектов, файлов и блоков со сложным алгоритмом размещения CRUSH. Однако Ceph требует как минимум 3 выделенных узла OSD, значительный объем оперативной памяти (минимум 4 ГБ на демон OSD) и глубокий опыт эксплуатации. Для кластеров k3s с 3–10 узлами Longhorn обеспечивает 90 % стоимости при 10 % эксплуатационных затрат.

Longhorn против OpenEBS Mayastor:Mayastor использует NVMe-over-Fabric для высокопроизводительной репликации, обеспечивая более низкую задержку, чем репликация Longhorn на основе TCP. Если вас больше всего беспокоят чистые IOPS и задержка менее миллисекунды, и у вас есть инфраструктура NVMe с сетью RDMA, Mayastor может быть лучшим выбором. Для большинства развертываний k3s интегрированное резервное копирование, аварийное восстановление и простота эксплуатации Longhorn перевешивают преимущества Mayastor в производительности.

Longhorn или local-path:— средство обеспечения локального пути — это хранилище по умолчанию для k3s — оно просто создает каталоги в локальной файловой системе узла. Нулевая репликация, нулевые снимки, нулевая интеграция резервного копирования. Это нормально для разработки, но неприемлемо для производственных данных.

Лучшие практики производства

Эти рекомендации основаны на опыте эксплуатации Longhorn на десятках производственных кластеров k3s, выполняющих рабочие нагрузки баз данных.

1. Настройте резервирование ресурсов для менеджеров экземпляров.Менеджерам экземпляров Longhorn (менеджерам механизмов и реплик) требуется гарантированный CPU, чтобы избежать остановок ввода-вывода во время нагрузки на узел. Установите дляguaranteedInstanceManagerCPUзначение не менее 12% в настройках Longhorn.

2. Используйте политику сохранения восстановления для томов базы данных.Никогда не используйтеDeleteдля баз данных PVC. ПолитикаRetainсохраняет PV и его данные даже после удаления PVC, обеспечивая защиту от случайного удаления.

3. Отключите мягкую антипривязку реплик для производства.УстановитеreplicaSoftAntiAffinity: false, чтобы реплики всегда распределялись по разным узлам. Благодаря мягкой антиаффинности Longhorn может планировать несколько реплик на одном узле, когда места мало, что противоречит цели репликации.

4. Зарезервируйте место для хранения на каждом узле.Установите дляstorageMinimalAvailablePercentageзначение не менее 15%. Это предотвращает использование Longhorn всего дискового пространства, что может вызвать проблемы на уровне узла, затрагивающие все модули.

5. Включите автоматическое восстановление.ПараметрautoSalvageавтоматически восстанавливает тома, которые переходят в состояние сбоя, если хотя бы одна реплика все еще работоспособна. Это уменьшает ручное вмешательство при сбоях узла.

6. Установите класс приоритета «критический для кластера системы». Компоненты менеджера и драйвераLonghorn никогда не следует удалять во время нагрузки на узел. Установите для их приоритетного класса значениеsystem-cluster-critical, чтобы гарантировать, что они выживут при вытеснении модуля.

7. Настройте повторяющиеся задания для всех объемов производства.Каждый рабочий том должен иметь повторяющиеся задания как моментального снимка, так и резервного копирования. Снимки каждые 4 часа для быстрого отката, резервное копирование ежедневно для аварийного восстановления.

8. Регулярно проверяйте активацию тома DR.Создайте ежемесячное расписание для активации томов аварийного восстановления в резервном кластере, проверки целостности данных и отработки процедуры аварийного переключения. План аварийного восстановления, который никогда не тестировался, — это всего лишь документация.

9. Проактивный мониторинг состояния тома.Настройте оповещения Prometheus о поврежденных и неисправных томах, емкости хранилища узла, сроке резервного копирования и состоянии восстановления реплики. К тому моменту, когда пользователь сообщает о медленной работе базы данных, проблема с хранилищем накапливается уже несколько часов.

10. Используйте выделенные диски хранения.Отделите данные Longhorn от диска ОС. Это предотвращает конфликты ввода-вывода, обеспечивает более чистое управление емкостью и позволяет избежать риска заполнения диска ОС данными Longhorn.

Руководство по развертыванию в облаке

AWS — EC2 с хранилищем экземпляров NVMe

Для развертываний AWS используйте экземплярыi3.xlargeилиi3en.xlarge, поставляемые с хранилищем экземпляров NVMe. Они обеспечивают чистую производительность NVMe за небольшую часть стоимости предоставленного EBS IOPS. Отформатируйте хранилище экземпляров и настройте его как диск 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 — виртуальные машины с Ultra Disk

На Azure используйте виртуальные машиныStandard_L8s_v3илиStandard_L16s_v3с локальным хранилищем NVMe. Альтернативно можно подключить Ultra Disks для обеспечения постоянной задержки менее миллисекунды. Ультра Диски позволяют самостоятельно настраивать IOPS и пропускную способность.

# 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 — виртуальные машины с локальным твердотельным накопителем

GCP предлагает локальный твердотельный накопитель, подключенный к виртуальным машинамn2-standardилиc3-standard. Локальные твердотельные накопители обеспечивают 375 ГБ на диск и скорость чтения до 680 000 операций ввода-вывода в секунду. Подключите несколько локальных твердотельных накопителей и создайте на них RAID для получения больших томов.

# 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

Локальный центр обработки данных

Для локальных развертываний используйте серверы с выделенными твердотельными накопителями NVMe или SAS для Longhorn. Отделите диск ОС от дисков хранения. Используйте сеть 10GbE или 25GbE между узлами, чтобы гарантировать, что трафик репликации не станет узким местом — синхронная репликация Longhorn генерирует сетевой трафик, пропорциональный пропускной способности записи, умноженной на количество реплик.

# 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

Longhorn поставляется со встроенным веб-интерфейсом, который обеспечивает визуальный интерфейс для управления томами, моментальными снимками, резервными копиями, узлами и настройками. Доступ к нему осуществляется через Ingress, настроенный во время установки, или через переадресацию портов kubectl.

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

Пользовательский интерфейс предоставляет несколько основных представлений: Панель мониторингаотображает состояние хранилища в масштабе всего кластера, включая общую емкость, используемое пространство и состояние тома. ТомВперечислены все тома с указанием их состояния (исправен/деградирован/неисправен), размера, количества реплик и подключенного узла. Вы можете расширять, делать снимки, создавать резервные копии и восстанавливать тома непосредственно из этого представления. Узелпоказывает конфигурацию хранилища каждого узла, распределение дисков и состояние планирования.Резервное копированиеперечисляет все резервные копии, хранящиеся в целевом хранилище, с указанием их тома, размера и времени создания. Настройкапредоставляет все параметры конфигурации Longhorn с описаниями.

Устранение распространенных проблем

Ухудшенные тома

Том переходит в состояние Degraded, когда одна или несколько реплик неработоспособны, но том все еще функционирует. Общие причины включают сбой узла, заполнение диска или сетевой раздел.

# 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

застрял при подключении/отсоединении

# 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 следует выполнять осторожно, поскольку система хранения данных поддерживает все рабочие нагрузки с отслеживанием состояния. Перед обновлением всегда делайте резервные копии всех критических томов.

# 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

с операторами баз данных

Современные операторы баз данных Kubernetes (CloudNativePG, Percona Оператор, Zalando Postgres Оператор) бесперебойно работают с Longhorn. Оператор управляет жизненным циклом базы данных, а Longhorn обеспечивает базовое хранилище репликацией, моментальными снимками и резервным копированием.

# 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 превращает k3s из легкого дистрибутива Kubernetes, подходящего только для периферии и разработки, в готовую к производству платформу, способную выполнять критически важные рабочие нагрузки с отслеживанием состояния. Его архитектура — механизмы по томам, синхронная репликация на нескольких узлах, встроенные снимки и резервное копирование в облачное объектное хранилище, тома аварийного восстановления, шифрование томов и онлайн-расширение PVC — обеспечивает хранилище корпоративного уровня без каких-либо сложностей.

Ключом к успеху производства Longhorn является тройной ключ. Во-первых, настройте его правильно с самого начала: используйте выделенные диски хранения, установите соответствующие коэффициенты репликации и локальность данных, а также создайте специальные классы StorageClass для разных типов рабочих нагрузок. Во-вторых, интегрируйте резервное копирование в свою архитектуру с первого дня: повторяющиеся снимки для быстрого отката, ежедневное резервное копирование на S3/GCS/Azure для аварийного восстановления и тома аварийного восстановления в резервном кластере на случай наихудшего сценария. В-третьих, следите за всем: состоянием тома, емкостью хранилища узла, возрастом резервной копии и состоянием восстановления реплики — проблемы с хранилищем незаметны, пока не станут катастрофическими.

Динамическое расширение PVC устраняет один из наиболее распространенных источников производственных инцидентов — нехватку дискового пространства. С помощью Longhorn расширение объема базы данных с 50Gi до 500Gi выполняется одной командой kubectl с нулевым временем простоя. В сочетании с оповещениями Prometheus о пороговых значениях емкости вы можете активно расширять тома до того, как они станут критически важными, или полностью автоматизировать расширение.

Независимо от того, используете ли вы PostgreSQL, MySQL, MongoDB или Redis на k3s — на голых металлических серверах, виртуальных машинах AWS EC2, Azure, экземплярах GCP или локальном оборудовании центра обработки данных — Longhorn предоставляет основу хранения, которая позволяет вам сосредоточиться на своих приложениях, а не беспокоиться о надежности данных. Установите его, настройте, отслеживайте и доверяйте ему свои производственные данные.