Персистентные данные в кластерах: сравнение Docker Swarm и Kubernetes с примерами конфигураций (2026)

Управление постоянными данными в кластерах контейнеров — критическая задача для production-сред. В отличие от одиночных серверов, где достаточно смонтировать локальный том, в распределенной среде данные должны оставаться доступными независимо от того, на каком узле запущен контейнер. В этой статье мы сравниваем два основных подхода: встроенный механизм томов Docker Swarm и комплексную систему Kubernetes на основе PersistentVolume, PersistentVolumeClaim и StorageClass. Вы получите готовые к применению конфигурации для обоих оркестраторов, научитесь выбирать режимы доступа (ReadWriteMany, ReadWriteOnce) для разных сценариев и гарантировать сохранность данных при миграции контейнеров между узлами.

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

При переходе от одиночного Docker-хоста к кластеру оркестраторов фундаментально меняется подход к управлению данными. Локальный том, привязанный к конкретному серверу, становится бесполезен, когда контейнер перезапускается на другом узле — данные остаются на исходной машине и становятся недоступными. Это требует специальных механизмов, обеспечивающих персистентность данных в распределенной среде.

Stateful vs Stateless: в чем ключевое отличие для оркестратора

Первое, что необходимо определить — тип вашего приложения:

Stateful-приложения хранят состояние между сессиями: базы данных (PostgreSQL, MySQL, MongoDB), системы очередей сообщений (RabbitMQ, Kafka), файловые хранилища (Nextcloud, MinIO). Для них потеря данных при перемещении контейнера недопустима.
Stateless-приложения не хранят локальное состояние: веб-серверы (Nginx, Apache), микросервисы без сессий, API-шлюзы. Их можно свободно перемещать между узлами без риска потери данных.

Для оркестратора ключевой вопрос: как управлять жизненным циклом контейнера stateful-приложения, обеспечивая доступ к его данным независимо от физического расположения? Ответом становятся распределенные системы хранения, интегрированные с оркестратором.

Экономический контекст: эффективность использования ресурсов хранения

Правильная организация кластерного хранилища — не только техническая необходимость, но и способ повысить экономическую эффективность инфраструктуры. Согласно исследованиям, потребность в увеличении емкости корпоративных систем хранения растет более чем на 43% ежегодно, при этом средняя заполненность СХД составляет лишь около 25%. Коэффициент использования серверов также остается низким — 20% и менее.

Кластерные системы хранения решают эту проблему через:

Пулы ресурсов — объединение дискового пространства всех узлов в единый логический объем
Виртуальное выделение (Thin Provisioning) — выделение места по мере фактической необходимости
Дедупликацию данных — устранение дублирования одинаковых блоков
Моментальные снимки (snapshots) — создание точек восстановления без копирования всех данных

Эти технологии, интегрированные в оркестраторы, позволяют значительно повысить коэффициент использования ресурсов хранения.

Механизм Docker Swarm Volumes: встроенное решение для персистентности

Docker Swarm предлагает относительно простой, но эффективный механизм работы с персистентными данными через абстракцию томов, управляемую оркестратором. В отличие от локальных томов Docker, тома Swarm могут использовать распределенные драйверы хранения, обеспечивая доступность данных на разных узлах.

Создание и использование тома: готовый пример конфигурации

Рассмотрим пример развертывания PostgreSQL в Swarm с использованием персистентного тома:

version: '3.8'

services:
  postgres:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - postgres_data:/var/lib/postgresql/data
    deploy:
      placement:
        constraints:
          - node.role == manager

volumes:
  postgres_data:
    driver: local
    driver_opts:
      type: nfs
      o: addr=192.168.1.100,nfsvers=4.1
      device: ":/mnt/nfs_share/postgres_data"

Ключевые параметры:

driver: local — базовый драйвер с поддержкой распределенного хранения через опции
driver_opts — настройки для подключения к NFS-серверу
type: nfs — использование сетевой файловой системы
addr — IP-адрес NFS-сервера

Для развертывания выполните:

docker stack deploy -c docker-compose.yml postgres-stack

Данные будут сохраняться на NFS-сервере и оставаться доступными при перезапуске сервиса на любом узле кластера.

Ограничения и режимы доступа в Swarm

Docker Swarm имеет несколько важных ограничений по сравнению с Kubernetes:

Аналог ReadWriteOnce — том обычно доступен только одному контейнеру на одном узле одновременно. Это подходит для большинства баз данных.
Проблема с ReadWriteMany — одновременная запись с нескольких узлов требует использования распределенных файловых систем (NFS, Ceph, GlusterFS) через драйверы томов.
Управление на больших кластерах — Swarm не имеет встроенной системы управления жизненным циклом хранилища, что усложняет администрирование при масштабировании.

Для небольших кластеров и простых сценариев Swarm предлагает достаточную функциональность с минимальной сложностью настройки. Однако для сложных production-сред с требованием высокой доступности и автоматизации лучше рассмотреть Kubernetes.

Система Kubernetes: PV, PVC и StorageClass — полный контроль

Kubernetes предлагает трехступенчатую модель управления персистентными данными, обеспечивающую максимальную гибкость и контроль. Эта модель состоит из PersistentVolume (PV), PersistentVolumeClaim (PVC) и StorageClass (SC), работающих по принципу «ресурс — заявка — правила создания».

Static Provisioning: создание PV и PVC вручную (манифесты)

Начнем с базового подхода — ручного создания ресурсов. Пример манифеста PersistentVolume для NFS-хранилища:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: postgres-pv
spec:
  capacity:
    storage: 100Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs-storage
  nfs:
    path: /mnt/nfs_share/postgres
    server: 192.168.1.100

PersistentVolumeClaim, запрашивающий этот том:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-pvc
spec:
  storageClassName: nfs-storage
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi

И подключение PVC к Pod:

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

Этот подход понятен, но требует ручного управления каждым томом, что не масштабируется в больших кластерах.

Dynamic Provisioning: автоматизация через StorageClass

Для production-сред Kubernetes предлагает динамическое выделение томов через StorageClass. Пример StorageClass для AWS EBS:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: aws-gp3
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  encrypted: "true"
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete
allowVolumeExpansion: true

Теперь при создании PVC, ссылающегося на этот StorageClass, Kubernetes автоматически создаст соответствующий PV:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: dynamic-pvc
spec:
  storageClassName: aws-gp3
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi

Преимущества динамического выделения:

Автоматизация — том создается автоматически при запросе
Интеграция с облачными провайдерами — поддержка AWS EBS, GCE Persistent Disk, Azure Disk
Соответствие политикам — централизованное управление параметрами хранилища

Этот подход напрямую связан с тенденцией автоматизации управления ресурсами, упомянутой в контексте из интернета.

Режимы доступа (Access Modes): выбор для вашего сценария

Kubernetes определяет три основных режима доступа к томам:

Режим	Описание	Типичное использование
`ReadWriteOnce (RWO)`	Том может быть смонтирован для чтения и записи одним узлом	Базы данных (PostgreSQL, MySQL), системы с эксклюзивным доступом
`ReadWriteMany (RWX)`	Том может быть смонтирован для чтения и записи многими узлами	Распределенные файловые системы (NFS, Ceph), системы общего доступа
`ReadOnlyMany (ROX)`	Том может быть смонтирован для чтения многими узлами	Статические файлы, конфигурации, библиотеки

Выбор правильного режима критически важен для корректной работы приложения. Например, для StatefulSet с репликами базы данных потребуется RWO, а для распределенного веб-приложения с общими файлами — RWX.

Сравнение подходов: Swarm vs Kubernetes в 2026 году

Выбор между Docker Swarm и Kubernetes для управления персистентными данными зависит от масштаба проекта, требований к гибкости и доступных ресурсов на администрирование.

Сложность администрирования и гибкость

Docker Swarm предлагает простоту:

Минимальная кривая обучения для администраторов Docker
Меньше компонентов для управления
Быстрое развертывание простых конфигураций

Kubernetes обеспечивает гибкость:

Трехступенчатая модель (PV/PVC/SC) дает полный контроль над жизненным циклом хранилища
Поддержка сложных сценариев (StatefulSet, динамическое выделение, расширение томов)
Интеграция с широким спектром систем хранения через CSI (Container Storage Interface)

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

Интеграция с внешними системами хранения и облаком

Оба оркестратора поддерживают интеграцию с внешними СХД, но с разной степенью зрелости:

Docker Swarm использует драйверы томов для подключения к NFS, Ceph, облачным дискам. Настройка часто требует дополнительных шагов и менее стандартизирована.
Kubernetes через CSI имеет богатую экосистему драйверов для практически любой системы хранения: от локальных решений (Rook/Ceph, Longhorn) до облачных сервисов (AWS EBS, Google Persistent Disk, Azure Disk).

В 2026 году Kubernetes остается лидером в интеграции с облачными платформами, что делает его предпочтительным выбором для гибридных и мультиоблачных сред.

Production-рекомендации: обеспечение надежности и избегание ошибок

Внедрение персистентного хранилища в production требует соблюдения определенных практик для гарантии надежности и доступности данных.

Настройка для высокой доступности (High Availability)

Для Kubernetes используйте StatefulSet вместе с распределенным хранилищем:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres-ha
spec:
  serviceName: postgres
  replicas: 3
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:15
        volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: "ceph-rbd"
      resources:
        requests:
          storage: 100Gi

Для Docker Swarm размещайте сервисы с томами на нескольких узлах, используя распределенный драйвер (NFS, Ceph). Убедитесь, что при остановке узла данные остаются доступными на новом узле.

Мониторинг и управление жизненным циклом хранилища

Регулярный мониторинг использования томов критически важен для предотвращения сбоев:

Используйте Prometheus с экспортерами для отслеживания использования PV/PVC
Настройте алерты при достижении 80% емкости тома
Используйте политику возврата (Reclaim Policy) в StorageClass: Retain для сохранения данных после удаления PVC, Delete для автоматической очистки

Процесс удаления должен следовать порядку: Pod → PVC → PV (для статических томов). Для динамических томов с политикой Delete удаление PVC автоматически освобождает ресурсы.

Типичные ошибки и их предотвращение:

Неправильный accessMode для StatefulSet — используйте ReadWriteOnce для реплицированных баз данных
Отсутствие правильных драйверов для распределенного хранения в Swarm — заранее протестируйте интеграцию с выбранной СХД
Недостаточный мониторинг использования — настройте алерты для предотвращения исчерпания места

Для резервного копирования данных кластерных томов используйте моментальные снимки через системы хранения (Ceph, ZFS) или специализированные инструменты оркестратора (Velero для Kubernetes).

Выводы и выбор стратегии для вашего проекта

Управление персистентными данными в кластерах требует осознанного выбора подхода, соответствующего масштабу и требованиям вашего проекта. Docker Swarm предлагает простоту и быстрое внедрение для небольших кластеров, в то время как Kubernetes обеспечивает полный контроль и масштабируемость для сложных production-сред.

Алгоритм выбора стратегии:

Определите тип приложения — stateful (базы данных, файловые хранилища) или stateless (веб-серверы, API)
Определите требуемый режим доступа — ReadWriteOnce для эксклюзивного доступа, ReadWriteMany для распределенных систем
Оцените сложность инфраструктуры — небольшой кластер или enterprise-среда с множеством узлов
Выберите оркестратор и схему хранения:
- Для простых сценариев и небольших команд: Docker Swarm с NFS или распределенными драйверами
- Для сложных production-сред, облачных развертываний и требований к автоматизации: Kubernetes с PersistentVolume, PersistentVolumeClaim и StorageClass

Оба подхода, представленные в статье, проверены на практике и готовы к применению в production-средах. Выберите решение, соответствующее вашим текущим потребностям, но предусмотрите возможность масштабирования в будущем.

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