Постоянное хранение в Kubernetes: CSI, Longhorn, Rook и выбор бэкенда в 2026 году

Постоянное хранение в Kubernetes строится на четырёх сущностях: CSI-драйвер, StorageClass, PersistentVolume (PV) и PersistentVolumeClaim (PVC). Приложение описывает запрос в PVC (размер и режим доступа), StorageClass задаёт, как этот запрос превратить в реальный том, PV представляет сам том в системе хранения, а CSI-драйвер соединяет kubelet с бэкендом: локальными NVMe, Ceph, NFS или внешним SAN. Уберите любое звено, и PVC останется в статусе Pending.

Короткий ответ по выбору бэкенда. Кластер из трёх-пяти нод и нагрузки среднего размера закрывает Longhorn: быстрый старт, встроенный UI, репликация на уровне тома. Для крупных кластеров и нагруженных баз данных берут Rook/Ceph. Когда критична задержка на локальных NVMe, смотрят на OpenEBS Mayastor или CSI-драйвер для LVM. Если в инфраструктуре уже работает NAS или SAN, дешевле подключить его через csi-driver-nfs или iSCSI. Portworx выбирают enterprise-команды, которым нужны шифрование, миграция между кластерами и поддержка вендора.

Ниже: абстракции с манифестами, критерии сравнения, сценарии для stateful-нагрузок, типичные ошибки и итоговая матрица выбора.

Как устроено постоянное хранение в Kubernetes: CSI, StorageClass, PV и PVC

CSI (Container Storage Interface) задаёт стандартный набор gRPC-вызовов между Kubernetes и системой хранения: CreateVolume, DeleteVolume, ControllerPublishVolume, NodeStageVolume, NodePublishVolume, CreateSnapshot. Драйвер работает как обычное приложение в кластере, поэтому вендор обновляет его независимо от версии платформы.

Чем CSI-драйвер отличается от старого in-tree плагина

In-tree плагины жили внутри исходного кода Kubernetes: поддержка AWS EBS, GCE PD или Cinder компилировалась в бинарники kube-controller-manager и kubelet и выходила вместе с релизом платформы. Баг в плагине ждал следующего релиза Kubernetes, а вендор не мог выпустить исправление сам. CSI вынес драйверы за пределы платформы.

Типичный драйвер состоит из двух частей: контроллера (Deployment с sidecar-контейнерами external-provisioner, external-attacher, external-snapshotter, external-resizer) и node-плагина (DaemonSet с node-driver-registrar). kubelet вызывает драйвер по gRPC через сокет вида /var/lib/kubelet/plugins/driver.longhorn.io/csi.sock, а каталог /var/lib/kubelet/plugins_registry/ сообщает kubelet о появлении нового драйвера. На 2026 год миграция завершена: in-tree плагины основных облаков удалены, транслирующий слой CSI migration больше не используется. Актуальные имена драйверов: ebs.csi.aws.com, pd.csi.storage.gke.io, rbd.csi.ceph.com, driver.longhorn.io, nfs.csi.k8s.io. Поле provisioner в StorageClass должно точно совпадать с зарегистрированным именем, иначе провижионер не найдётся.

К CSI прилагается отдельная спецификация снапшотов: CRD VolumeSnapshot, VolumeSnapshotClass и VolumeSnapshotContent, которые обслуживает sidecar external-snapshotter. Наличие снапшотов у бэкенда проверяется по объекту VolumeSnapshotClass с тем же provisioner. Снапшот даёт быстрый откат, но бэкап не заменяет: он лежит в той же системе хранения и исчезнет вместе с пулом.

StorageClass, PV и PVC: кто за что отвечает

Цепочка выглядит так. Инженер создаёт PVC с размером, accessModes и storageClassName. external-provisioner передаёт параметры StorageClass в CSI-драйвер, драйвер создаёт том в системе хранения, Kubernetes создаёт объект PV и связывает его с PVC. kubelet на нужной ноде выполняет NodeStageVolume и NodePublishVolume и монтирует файловую систему в под. Статический вариант: администратор создаёт PV вручную, а PVC с подходящими параметрами связывается с ним.

Режимы доступа: ReadWriteOnce (RWO) монтируется на одну ноду для чтения и записи, ReadOnlyMany (ROX) даёт многим нодам чтение, ReadWriteMany (RWX) разрешает чтение и запись с нескольких нод, ReadWriteOncePod (RWOP) привязывает том к одному поду в кластере. RWX умеют NFS, CephFS и Longhorn (через share-manager на NFS). Блочные бэкенды вроде RBD или локальных NVMe RWX не отдают: попытка создать такой PVC закончится Pending или ошибкой провижионинга.

volumeBindingMode определяет момент создания тома. Immediate создаёт PV сразу после создания PVC. WaitForFirstConsumer ждёт появления пода и учитывает топологию ноды. Для локальных дисков, зональных облачных томов и Ceph с привязкой к нодам подходит только WaitForFirstConsumer: при Immediate том может оказаться в зоне, куда под не сможет приехать.

reclaimPolicy задаёт судьбу тома после удаления PVC. Delete удаляет том в системе хранения, Retain оставляет его и переводит PV в статус Released. Для баз данных и всего, что нельзя быстро восстановить, ставьте Retain. Recycle устарел.

Минимальный StorageClass с PVC, который создаст динамический том на SSD-дисках:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: driver.longhorn.io
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
parameters:
  numberOfReplicas: '3'
  diskSelector: 'ssd'
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast-ssd
  resources:
    requests:
      storage: 10Gi

Эта связка применима к большинству драйверов: меняются provisioner и блок parameters. Полный разбор динамического выделения томов с командами диагностики собран в материале про интеграцию СХД с Kubernetes через CSI и Persistent Volumes.

Не путайте хранилище данных приложений с etcd. По умолчанию kubeadm запускает локальный экземпляр etcd на каждом узле control plane, а внешний etcd-кластер требует трёх хостов, которые видят друг друга по TCP-портам 2379 и 2380; dual-stack etcd не поддерживает. В etcd лежит состояние кластера (объекты API), а таблицы баз данных, очереди и артефакты сборки живут в PV.

Критерии выбора бэкенда: производительность, отказоустойчивость, сложность сопровождения

Longhorn, Rook/Ceph, OpenEBS, Portworx и внешние NAS/SAN сравнивают по шести параметрам, а не по одному показателю скорости. Порядок такой: сначала профиль нагрузки, затем топология, режим доступа, отказоустойчивость, стоимость сопровождения и цена.

• Профиль нагрузки: транзакционные операции требуют тысяч IOPS при задержке в доли миллисекунды, потоковая запись и чтение требуют пропускной способности.
• Топология: одна нода, три ноды, десятки нод в нескольких зонах.
• Режим доступа: RWO закрывает большинство баз данных, RWX нужен для общих каталогов, CI/CD-кэшей и сборок, которые читают одни данные из нескольких подов.
• Отказоустойчивость: число реплик, наличие кворума, значения RPO и RTO при потере ноды или стойки.
• Сопровождение: сколько инженеров нужно, есть ли SRE, готовы ли вы обновлять Ceph и разбираться с картой размещения данных.
• Цена: диски, сеть 10 или 25 GbE, лицензии, стоимость облачных IOPS и снапшотов.

Бенчмарки из статей не воспроизводятся на другом железе: результат определяют модель диска, кэш контроллера, размер блока, MTU и профиль ввода-вывода. Готовьте тест сами: fio с реалистичным блоком (4K для баз данных, 1M для потоковых задач) и числом параллельных потоков, близким к рабочему. Развёрнутое сравнение с цифрами по IOPS и разбором режимов доступа есть в обзоре Local PV, NFS, Ceph RBD, Longhorn и OpenEBS.

Longhorn: когда он закрывает задачу и где упирается

Longhorn - распределённое блочное хранилище, которое ставится в кластер Helm-чартом или набором манифестов и не требует внешней СХД. Каждый том реплицируется на несколько нод (по умолчанию 3 реплики), данные ложатся на локальные диски, доступ идёт через iSCSI. На каждой ноде должны работать iscsid и open-iscsi: без них поды томов не поднимутся, а PVC застрянет в Pending. Механику iSCSI, LVM и разбор ошибок FailedMount подробно разбирает материал про блочные СХД, CSI, LVM и типичные ошибки.

В комплект входят снапшоты и бэкапы томов в S3-совместимое хранилище или NFS, встроенный UI, перестройка реплик после отказа ноды, RWX через share-manager: на каждый RWX-том поднимается отдельный под с NFS-сервером. Версии и матрицу совместимости сверяйте с релизными нотами проекта, ветка развивается быстро.

Границы применимости видны из арифметики. Три реплики на трёх нодах дают примерно треть полезной ёмкости от сырой: 3 ТБ дисков превращаются в 1 ТБ доступного пространства. Репликация идёт по сети, поэтому на 1 GbE задержка заметно растёт, а транзакционные базы теряют в скорости; для серьёзных нагрузок нужен интерконнект 10 GbE и выше. Потеря пакетов и перегрузка сети запускают перестройку реплик, которая сама потребляет полосу.

Сценарии, где Longhorn уместен: stateful-приложения среднего размера, CI/CD-кэши, dev и staging, базы данных с умеренным числом транзакций. Для тысяч транзакций в секунду и аналитики на ClickHouse сеть становится узким местом. Пример StorageClass с отбором SSD-дисков и томом под PostgreSQL:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-ssd
provisioner: driver.longhorn.io
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
parameters:
  numberOfReplicas: '3'
  staleReplicaTimeout: '30'
  diskSelector: 'ssd'
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pg-data
  namespace: prod
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn-ssd
  resources:
    requests:
      storage: 100Gi

Проверьте numberOfReplicas до запуска нагрузки. Если нод три, а реплик три, кластер теряет запас на перестройку при отказе одной ноды, и том становится уязвимым. Практичный вариант: 2 реплики на трёх нодах с бэкапом в S3.

Rook/Ceph: мощно, но требует экспертизы

Rook - оператор, который разворачивает Ceph внутри Kubernetes: MON (кворум и карта кластера), OSD (диски с данными), MGR (метрики и модули), MDS (CephFS), RGW (S3-шлюз). Один кластер отдаёт три типа хранилища: блочное RBD, файловое CephFS и объектное через CephObjectStore.

OSD создаются на сырых устройствах, диск отдаётся целиком, без разделов и файловых систем. Размещение данных описывает карта CRUSH: правило failure domain (host, rack, zone) определяет, сколько отказов переживёт пул. Пул с size 3 и min_size 2 продолжает принимать запись при потере одной ноды и уходит в read-only при потере двух.

Производительность на NVMe высокая, кластер масштабируется до сотен нод, но порог входа серьёзный: нужен опыт работы с Ceph, понимание пулов, pg_num, recovery и порядка обновлений. При потере кворума MON кластер переходит в режим только для чтения и перестаёт выдавать новые тома. Обновление идёт по шагам: MON, затем MGR, затем OSD, с проверкой состояния между этапами. Планируйте отдельную сеть для репликации OSD, не смешивайте её с трафиком приложений: одна сеть на трёх нодах превращает отказ ноды в риск потери кворума.

apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
  name: replicapool
  namespace: rook-ceph
spec:
  replicated:
    size: 3
    requireSafeReplicaSize: true
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ceph-rbd-nvme
provisioner: rook-ceph.rbd.csi.ceph.com
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
parameters:
  clusterID: rook-ceph
  pool: replicapool
  imageFormat: '2'
  imageFeatures: layering
  csi.storage.k8s.io/fstype: xfs
  csi.storage.k8s.io/provisioner-secret-name: rook-csi-rbd-provisioner
  csi.storage.k8s.io/provisioner-secret-namespace: rook-ceph
  csi.storage.k8s.io/node-stage-secret-name: rook-csi-rbd-node
  csi.storage.k8s.io/node-stage-secret-namespace: rook-ceph

Обратите внимание на поле fstype: смена файловой системы на существующем томе приводит к нечитаемым данным, поэтому ext4 и xfs выбирают один раз, до запуска приложения. Готовые конфигурации для баз данных и stateful-приложений, включая варианты с TrueNAS, собраны в руководстве по динамическому выделению хранилища для stateful-нагрузок.

OpenEBS, Portworx и внешние NAS/SAN: альтернативы под конкретные задачи

OpenEBS - набор движков под разные задачи, а не один продукт. LocalPV-hostpath и LocalPV-device отдают тома прямо с локальных дисков: минимум накладных расходов и максимум скорости, но данные привязаны к ноде, и при её отказе том недоступен до восстановления ноды. Jiva реплицирует тома через iSCSI поверх обычных дисков. Mayastor работает по NVMe-oF и нацелен на низкую задержку; ему нужны hugepages, модуль ядра nvme-tcp и выделенная сеть.

Portworx - коммерческая платформа: шифрование томов, снапшоты, миграция приложений между кластерами и облаками, квоты, интеграция с политиками. Лицензия считается по нодам, поэтому решение оправдано там, где нужны эти функции и поддержка вендора.

Внешние NAS и SAN подключаются двумя путями. NFS через csi-driver-nfs: драйвер создаёт каталог на существующем экспорте под каждый PV. iSCSI через CSI-драйвер: массив выдаёт LUN, а узел подключает его как блочное устройство. Плюсы внешнего варианта: железо уже куплено, бэкап централизован, RWX получается без распределённого слоя, данные живут независимо от жизненного цикла кластера. Минусы: сетевая задержка, единая точка отказа и отдельная команда, отвечающая за массив. TrueNAS с ZFS часто выступает таким бэкендом, а снапшоты и репликацию настраивают на стороне СХД.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-rwx
provisioner: nfs.csi.k8s.io
reclaimPolicy: Retain
volumeBindingMode: Immediate
mountOptions:
  - nfsvers=4.1
  - hard
parameters:
  server: 10.0.0.10
  share: /export/k8s
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-san-lun42
spec:
  capacity:
    storage: 500Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: san-iscsi
  csi:
    driver: iscsi.csi.k8s.io
    volumeHandle: 10.0.0.20:3260:iqn.2026-01.local.storage:lun42
    fsType: xfs

В примере с iSCSI подставьте адрес портала, IQN и номер LUN своего массива: volumeHandle у каждого драйвера имеет собственный формат, и копировать чужой идентификатор нельзя. Для NFS держите опцию hard в mountOptions, иначе при недоступности сервера приложение получит ошибки ввода-вывода вместо ожидания.

Сценарии эксплуатации: stateful-приложения, БД в кластере, CI/CD-кэши

Kafka, Elasticsearch и Prometheus требуют RWO с высокой пропускной способностью и предсказуемой задержкой. Для Kafka критичен fsync: сетевые бэкенды с большой задержкой увеличивают время подтверждения записи и снижают пропускную способность топика. Практичный выбор: локальные NVMe с быстрым дисковым контроллером и слоем репликации поверх (Longhorn, Mayastor), при этом число реплик и сеть подбирают так, чтобы задержка не выходила за бюджет.

Базы данных в кластере (PostgreSQL, MySQL, ClickHouse) выигрывают от RBD на NVMe или от внешнего SAN через iSCSI: важны стабильная задержка, снапшоты и восстановление на момент времени. RWX для баз данных не используйте, это прямой путь к повреждению файлов. Ниже StatefulSet с volumeClaimTemplates, который создаёт по тому на каждую реплику:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: kafka
spec:
  serviceName: kafka
  replicas: 3
  selector:
    matchLabels:
      app: kafka
  template:
    metadata:
      labels:
        app: kafka
    spec:
      containers:
        - name: kafka
          image: apache/kafka:3.7.0
          volumeMounts:
            - name: data
              mountPath: /var/lib/kafka/data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes:
          - ReadWriteOnce
        storageClassName: longhorn-ssd
        resources:
          requests:
            storage: 200Gi

Удаление такого StatefulSet не удаляет PVC: тома остаются и требуют ручной очистки. Учитывайте это в скриптах удаления окружений, иначе кластер тихо заполняется осиротевшими томами.

CI/CD-кэши (GitLab Runner, BuildKit, локальный registry) живут по другим правилам: важна ёмкость, а не задержка, поэтому подходит RWX через NFS или Longhorn, а также S3-совместимое хранилище. Канареечные выкладки добавляют к этому свой слой: в примере из документации Kubernetes stable-версия имеет 3 реплики, canary - 1, и при общем Service selector около 25% трафика уходит на canary. Оба набора подов одновременно читают одни и те же кэши и артефакты, поэтому общий том RWX удобнее, чем отдельный том каждому набору. Рекомендации по выбору хранилища под PostgreSQL, MySQL, Kafka и Elasticsearch с таблицей критериев собраны в материале про выбор хранилища для Kubernetes в 2026 году.

Типичные ошибки при настройке хранилища и как их избежать

Первое, что проверяют при проблемах, - события PVC. Команда для диагностики:

kubectl describe pvc app-data -n prod
kubectl get storageclass
kubectl get csidrivers
kubectl get pods -n kube-system | grep csi

PVC в Pending. В блоке Events смотрите причину. Нет StorageClass с указанным именем или нет драйвера с таким provisioner: проверьте kubectl get csidrivers. volumeBindingMode Immediate при топологически зависимом бэкенде: исправьте на WaitForFirstConsumer. Несовпадение accessModes: запрос RWX к блочному драйверу никогда не выполнится.

Потеря данных после удаления PVC. У многих StorageClass не указан reclaimPolicy, и по умолчанию применяется Delete. Для критичных данных ставьте Retain в самом StorageClass, а не только в манифесте PV: динамически созданные тома наследуют политику класса.

RWO на нескольких нодах. ReadWriteOnce означает одну ноду, а не один под. Два пода на разных нодах с одним RWO-томом дадут ошибку монтирования. Варианты: RWOP для строгой привязки к одному поду, RWX для общих данных или отдельные тома на реплику.

Несовпадение fsType. Том, созданный как xfs, не смонтируется как ext4, а после смены csi.storage.k8s.io/fstype в StorageClass данные на существующем томе останутся нечитаемыми. Выбирайте файловую систему до первого запуска приложения и фиксируйте выбор в документации.

Отсутствие привязки к ноде. Локальные тома и зональные диски требуют node affinity или topology-селектора. Без них под может уехать на ноду без доступа к диску и зависнуть в ContainerCreating с ошибкой FailedMount.

Заполненный том. Квоты PV не спасают от роста логов и временных файлов. Настройте алерты по использованию томов у node-exporter и kubelet, иначе приложение упадёт по ENOSPC в неудобный момент. Расширение томов работает только при allowVolumeExpansion: true, а уменьшение размера PVC не поддерживается вообще.

Обслуживание нод. Перед работами вытесняйте поды, если изменение затрагивает рабочие нагрузки, а текущее состояние события показывает Node lifecycle conditions. Для томов это критично: часть драйверов не переносит том на другую ноду автоматически, и под останется в Pending до возвращения ноды.

Снапшот вместо бэкапа. CSI-снапшот хранится в том же пуле или на том же массиве. Потеря массива уносит и данные, и снапшоты. Бэкап должен лежать на отдельном носителе, желательно в другом месте.

Миграция между бэкендами и бэкапы: как не потерять данные

Сменить StorageClass у существующего PVC нельзя: поле неизменяемо, том остаётся на прежнем драйвере. Переезд выполняется пересозданием PVC. Offline-схема: остановите приложение, скопируйте данные через rsync или restic в новый том, созданный с новым StorageClass, переключите StatefulSet или Deployment на новый claim, запустите приложение и проверьте целостность. Простой равен времени копирования, поэтому для больших томов считайте окно заранее.

Online-схема опирается на два механизма. Первый - VolumeSnapshot: если исходный и целевой драйверы умеют восстанавливать том из снапшота, копирование сокращается до выгрузки и загрузки снапшота. Второй - репликация на уровне приложения: логическая репликация PostgreSQL, зеркалирование Kafka или репликация на стороне СХД. Второй путь сложнее в настройке, но даёт минимальный простой.

Для бэкапов стандартная связка - Velero плюс серверная часть restic или kopia, которая копирует содержимое томов в S3-совместимое хранилище. Пример расписания с файловым бэкапом томов:

apiVersion: velero.io/v1
kind: Backup
metadata:
  name: daily-prod
  namespace: velero
spec:
  includedNamespaces:
    - prod
  snapshotVolumes: true
  defaultVolumesToFsBackup: true
  storageLocation: s3-prod
  ttl: 720h

Важная деталь: при defaultVolumesToFsBackup: true Velero копирует данные томов через node-agent, а не полагается на CSI-снапшот. Если драйвер не поддерживает снапшоты, без этого параметра в бэкап попадёт только описание объектов, а не данные. Обязательно проверяйте восстановление: бэкап без тестового развёртывания в отдельном namespace ничего не гарантирует.

Что выбрать в 2026 году: итоговая матрица решений

Версии компонентов сверяйте перед обновлением: в обиходе Kubernetes 1.30 и новее, Longhorn 1.7 и новее, ветки Ceph Reef и Squid, OpenEBS 4.x, спецификация CSI 1.10 и новее. Матрицы совместимости меняются от релиза к релизу, а понижение версии Ceph и Longhorn обычно не поддерживается.

Чек-лист перед запуском хранилища в работу:

1. Установите open-iscsi и iscsid на всех нодах, если используете Longhorn или iSCSI.
2. Выделите отдельную сеть под репликацию и проверьте её пропускную способность.
3. Явно задайте reclaimPolicy и volumeBindingMode в StorageClass, не полагайтесь на значения по умолчанию.
4. Проверьте, что число реплик соответствует числу нод и оставляет запас на перестройку.
5. Настройте мониторинг: состояние CSI-подов, использование томов, health Ceph или Longhorn.
6. Протестируйте восстановление из бэкапа в отдельном namespace до первого инцидента.
7. Проверьте нагрузочным тестом fio задержку и IOPS на реальном профиле нагрузки.
8. Задокументируйте StorageClass по умолчанию и запрет на RWX для баз данных.
9. Отдельно проверьте поведение при отказе ноды: переносится ли том автоматически.
10. Настройте алерты на PVC в статусе Pending и на события FailedMount.

Начните с одного сценария и одного бэкенда: разверните Longhorn на тестовом namespace, прогоните fio и восстановление из бэкапа, и только после этого переносите production-тома.