Persistent Volumes в Kubernetes: настройка хранилища для баз данных и stateful-приложений | Руководство по CSI (TrueNAS, Ceph)

Развертывание stateful-приложений, таких как базы данных PostgreSQL, кэши Redis или брокеры сообщений Kafka, в Kubernetes требует надежного и управляемого хранилища данных. В отличие от статичных серверов, контейнеры в кластере эфемерны и могут перемещаться между узлами. Это создает фундаментальное противоречие: как обеспечить постоянство данных в динамической среде.

Решение этой проблемы лежит в использовании механизмов оркестрации хранилища Kubernetes: Persistent Volumes (PV), Persistent Volume Claims (PVC), StorageClasses и CSI-драйверов. В этом руководстве вы получите пошаговые инструкции по настройке динамического выделения хранилища, выбору и развертыванию CSI-драйвера (TrueNAS или Ceph/Rook), а также готовые конфигурации для безопасного и отказоустойчивого хранения данных ваших приложений.

Почему управление хранилищем - критический вызов для современных stateful-приложений в Kubernetes

Архитектура современных приложений перешла от монолита к микросервисам и event-driven коммуникациям. Это повышает гибкость и скорость разработки, но увеличивает количество stateful-компонентов, работающих в контейнерах. Каждая база данных, кэш или очередь сообщений требует сохранения состояния между перезапусками подов.

Бизнес-требования к таким системам включают горизонтальное масштабирование под непредсказуемую нагрузку и быстрый выпуск обновлений через конвейеры CI/CD. Эфемерная природа контейнеров вступает в конфликт с необходимостью постоянного хранения данных. Классические подходы, такие как монтирование локальных дисков, не работают при миграции пода на другой узел кластера.

Для российского рынка добавляются регуляторные требования, такие как 152-ФЗ и рекомендации ФСТЭК, которые предъявляют строгие условия к безопасности и локализации данных. Эти требования накладывают дополнительные ограничения на выбор и конфигурацию систем хранения, исключая использование непроверенных или зарубежных облачных решений без должного уровня сертификации.

Ответом на эти вызовы становится оркестрация хранилища на уровне Kubernetes. Механизмы Persistent Volumes, StorageClass и CSI позволяют декларативно описывать требования к хранилищу и автоматически подключать его к подам, обеспечивая переносимость данных и интеграцию с внешними отказоустойчивыми системами хранения.

Архитектура хранения данных в Kubernetes: от PersistentVolume до CSI-драйвера

Чтобы эффективно управлять хранилищем в Kubernetes, нужно понимать роли ключевых абстракций. PersistentVolume (PV) представляет собой физический или логический ресурс хранения в кластере, например, диск NFS или блоковое устройство iSCSI. PersistentVolumeClaim (PVC) - это запрос пользователя (пода) на выделение ресурса из PV с определенными характеристиками: размером, режимом доступа (ReadWriteOnce, ReadWriteMany).

StorageClass (SC) определяет «меню» или класс хранилища с заданными параметрами производительности, отказоустойчивости и политиками. Когда Pod создает PVC, указывая нужный StorageClass, Kubernetes динамически (dynamic provisioning) создает новый PV, соответствующий этому классу. Это избавляет администратора от ручного создания томов (статический provisioning).

Стандарт Container Storage Interface (CSI) играет роль драйвера, который связывает Kubernetes с внешней системой хранения, такой как TrueNAS, Ceph, AWS EBS или Google Persistent Disk. CSI-драйвер реализует операции создания, удаления, подключения и создания снапшотов томов по запросу Kubernetes API.

Общая схема работы выглядит так:
1. Администратор развертывает CSI-драйвер для выбранной системы хранения и создает один или несколько StorageClass.
2. Разработчик в манифесте Pod или StatefulSet указывает PersistentVolumeClaim, ссылаясь на нужный StorageClass.
3. Контроллер в Kubernetes, увидев PVC, через CSI-драйвер отправляет запрос внешнему хранилищу на создание тома.
4. Созданный том привязывается к PersistentVolume, который, в свою очередь, связывается с PVC.
5. Kubelet на узле, где запланирован Pod, с помощью CSI-драйвера монтирует том в файловую систему контейнера.

StorageClass как декларация политик: производительность, отказоустойчивость и стоимость

StorageClass - это центральный объект для управления качеством хранилища. Через его параметры (parameters) решаются конкретные бизнес-задачи.

• Тип диска и производительность: Параметры вроде type: ssd или iopsLimit: 5000 позволяют выделять быстрые SSD-тома для баз данных и медленные, но емкие HDD - для архивов или логов.
• Политики репликации и отказоустойчивости: Для TrueNAS можно указать уровень RAID-Z (zfs:compression=zstd, zfs:dedup=on). Для Ceph/Rook определяется схема репликации (replicated) или кодирования стиранием (erasure coded).
• Файловая система: Параметр fsType определяет, будет ли том отформатирован в ext4, xfs или останется в родной для хранилища файловой системе (например, ZFS).
• Расширение томов: Опция allowVolumeExpansion: true позволяет в будунии увеличить размер PVC без потери данных.

Пример создания StorageClass для быстрого SSD-хранилища в TrueNAS:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: truenas-iscsi-ssd
provisioner: csi.truenas.com
parameters:
  datasetParent: "k8s-pool/volumes"
  fsType: "ext4"
  disksize: "" # Размер указывается в PVC
  apiEndpoint: "https://truenas.local"
  apiKey: ""
  disableDelete: "false"
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate

Для мониторинга производительности таких томов используются метрики IOPS (операций ввода-вывода в секунду) и latency (задержка), которые можно собирать с помощью Prometheus и визуализировать в Grafana.

Выбор и развертывание CSI-драйвера: сравнительный анализ TrueNAS и Ceph/Rook

Выбор CSI-драйвера определяет всю архитектуру хранения. Два популярных решения для on-premise сред - это TrueNAS (централизованное NAS/SAN) и Ceph/Rook (распределенное программно-определяемое хранилище).

TrueNAS (SCALE):
Идеально подходит, когда в инфраструктуре уже есть выделенный NAS-сервер или требуется глубокая интеграция с возможностями ZFS: снапшоты, клонирование, компрессия, дедупликация. Архитектура централизованная: все данные хранятся на одном или нескольких серверах TrueNAS, которые предоставляют тома по протоколам iSCSI или NFS. Настройка проще, администрирование знакомо системным администраторам. Это хороший выбор для сред, где важна предсказуемая производительность и есть бюджет на выделенное железо.

Ceph/Rook:
Это решение для полностью программно-определяемого, горизонтально масштабируемого хранилища, работающего внутри самого Kubernetes-кластера. Rook - это оператор, который управляет развертыванием и жизненным циклом кластера Ceph на дисках, подключенных к рабочим узлам Kubernetes. Ceph обеспечивает отказоустойчивость за счет репликации или кодирования стиранием данных между многими узлами. Порог входа выше, требуется больше ресурсов CPU и RAM, но система получается крайне гибкой и масштабируемой.

Таблица для выбора:

• Выбирайте TrueNAS, если: у вас есть выделенный сервер хранения, вы цените простоту администрирования и мощь ZFS, нуждаетесь в интеграции с другими системами (виртуализация через iSCSI).
• Выбирайте Ceph/Rook, если: вы строите cloud-native платформу, хотите максимальной отказоустойчивости и горизонтального масштабирования хранилища вместе с кластером K8s, готовы выделить под хранение часть ресурсов рабочих узлов.

Оба варианта позволяют обеспечить локализацию данных, что критично для соответствия требованиям 152-ФЗ.

Пошаговое развертывание CSI-драйвера для TrueNAS SCALE

1. Предварительные требования: Настроенный кластер TrueNAS SCALE с созданным ZFS pool (например, k8s-pool) и dataset внутри него (например, k8s-pool/volumes). Включенный API доступ с созданным ключом.

2. Установка драйвера: Самый простой способ - установка через Helm chart. Добавьте репозиторий и установите релиз.

helm repo add truenas https://truenas.github.io/charts
helm repo update
helm install truenas-csi truenas/truenas-csi --namespace kube-system

3. Конфигурация Secret: Создайте Secret с данными для подключения к TrueNAS API. Никогда не храните эти данные в открытом виде в манифестах.

apiVersion: v1
kind: Secret
metadata:
  name: truenas-csi-secret
  namespace: kube-system
type: Opaque
stringData:
  url: "https://truenas.local"
  apiKey: "ваш-секретный-ключ-api"

4. Проверка установки: Убедитесь, что драйвер зарегистрирован.

kubectl get csidrivers.storage.k8s.io

После этого можно создавать StorageClass, как показано в предыдущем разделе.

Пошаговое развертывание распределенного хранилища с Rook Ceph

1. Требования к узлам: На каждом узле Kubernetes, который будет использоваться для хранения, должны быть чистые диски или разделы без файловых систем. Rook займет их полностью.

2. Установка Rook Operator: Клонируйте репозиторий Rook и установите Common и Operator манифесты.

git clone --single-branch --branch v1.14.0 https://github.com/rook/rook.git
cd rook/deploy/examples
kubectl create -f crds.yaml -f common.yaml -f operator.yaml

3. Создание кластера Ceph: Отредактируйте файл cluster.yaml, указав узлы и диски, затем примените его.

kubectl create -f cluster.yaml

4. Создание StorageClass: Для блочных устройств (RBD) создайте StorageClass. Ceph также предоставляет файловое хранилище (CephFS), которое поддерживает режим доступа ReadWriteMany.

kubectl create -f csi/rbd/storageclass.yaml

5. Проверка здоровья: Снапшоты томов Встроенные снапшоты ZFS, интеграция с системой репликации TrueNAS Интеграция с Ceph Snapshots, возможность клонирования Соответствие 152-ФЗ/ФСТЭК Локализация данных на территории РФ, возможность использования сертифицированного ПО Локализация данных, развертывание на отечественном железе

Создание и использование томов: от манифеста PVC до подключения в Pod

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-data-pvc
spec:
  storageClassName: truenas-iscsi-ssd
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

apiVersion: v1
kind: Pod
metadata:
  name: postgres-pod
spec:
  containers:
  - name: postgres
    image: postgres:15
    volumeMounts:
    - mountPath: /var/lib/postgresql/data
      name: data-volume
  volumes:
  - name: data-volume
    persistentVolumeClaim:
      claimName: postgres-data-pvc

kubectl get pvc
kubectl describe pod postgres-pod # Ищем секцию Volumes
kubectl exec -it postgres-pod -- df -h /var/lib/postgresql/data

securityContext:
  runAsUser: 1000
  runAsGroup: 1000
  fsGroup: 1000