Постоянное хранение в Kubernetes

Логотип Kubernetes на стилизованном фоне

Кратко

Kubernetes по умолчанию предоставляет эфемерные файловые системы для Pod. Для сохранения данных вне жизненного цикла контейнера используются PersistentVolume (PV) и PersistentVolumeClaim (PVC). Ниже — понятное руководство с примером, объяснением классов хранилищ, режимов доступа, рекомендациями и контрольными списками для команд.

Быстрые ссылки

Базовый пример
Классы хранилищ
Режимы доступа
Рекомендации и контрольные списки
Заключение

Почему это важно

Контейнеры по своей природе статeless — их файловая система исчезает при пересоздании. PersistentVolume и PersistentVolumeClaim позволяют хранить данные независимо от жизненного цикла Pod, что критично для баз данных, очередей и любых приложений, которым нужна долговременная запись.

Базовый пример

Ниже показан минимальный рабочий набор: PersistentVolume, PersistentVolumeClaim и Pod, который использует PVC. Пример предполагает namespace pvc-demo. Примеры используют hostPath для локального тестирования; в production используйте облачные или сетевые драйверы.

Применение манифестов:

kubectl apply -f pv.yaml -n pvc-demo
kubectl apply -f pvc.yaml -n pvc-demo
kubectl apply -f pod.yaml -n pvc-demo

Создание PersistentVolume

Файл pv.yaml:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-volume
  namespace: pvc-demo
spec:
  storageClassName: manual
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /mnt/data

Объяснение ключей:

storageClassName: имя класса хранилища; при ручном создании часто ставят “manual”.
capacity.storage: вместимость PV (здесь 2Gi).
accessModes: режимы монтирования (см. раздел ниже).
hostPath: локальный путь на узле (только для тестов).

Создание PersistentVolumeClaim

Файл pvc.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-volume-claim
  namespace: pvc-demo
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

PVC запрашивает 1Gi из PV с классом manual. Kubernetes попытается найти подходящий PV и пометит их статус как Bound, когда сопоставление выполнено.

Проверка статусов:

kubectl get pv my-volume -n pvc-demo
kubectl get pvc my-volume-claim -n pvc-demo

Добавление Pod

Файл pod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  namespace: pvc-demo
spec:
  containers:
    - name: my-container
      image: my-image:latest
      volumeMounts:
        - mountPath: /path/in/container
          name: my-pod-volume
  volumes:
    - name: my-pod-volume
      persistentVolumeClaim:
        claimName: my-volume-claim

Pod ссылается на PVC в секции volumes; в volumeMounts указываете тот же name и путь внутри контейнера. Всё, что записано в /path/in/container, будет сохраняться на PV вне жизненного цикла Pod.

Классы хранилищ

Класс хранилища (StorageClass) описывает «тип» тома и параметры динамического provisioner’а. Часто управляемые Kubernetes-сервисы (GKE, EKS, AKS, DigitalOcean) поставляют свои StorageClass:

GKE: gcePersistentDisk (или стандартные классы GCP)
DigitalOcean: do-block-storage
AWS: gp2 / gp3 (EBS)

Когда используется динамическое provisioner’ы, вам не нужно вручную создавать PV: создайте только PVC с нужным storageClassName и ресурсом requests.storage — провайдер создаст PV автоматически.

Важно

Не все StorageClass поддерживают все accessModes.
Если storageClassName у PVC пустой, будет использован дефолтный класс кластера (если он настроен).

Режимы доступа

Доступные значения поля accessModes:

ReadWriteOnce — том можно смонтировать для чтения/записи только на одном узле.
ReadOnlyMany — том можно монтировать на несколько узлов только для чтения.
ReadWriteMany — том можно монтировать на несколько узлов для чтения и записи.

Последствия

Для реплицируемых Pod, которые нуждаются в общем томе на разных узлах, нужен ReadWriteMany (или ReadOnlyMany, если только чтение).
Многие облачные блоковые диски не поддерживают ReadWriteMany; для этого часто используют сетевые файловые системы (NFS, GlusterFS, CIFS) или CSI-драйверы типа NFS/CEPH/Rook.

Провайдеры и ограничения

Проверяйте документацию драйвера: не все плагины поддерживают все режимы.
Сочетание accessModes влияет на алгоритм планировщика Kubernetes при распределении Pod по узлам.

Когда это не сработает

HostPath используется только для локальных тестов: если Pod переедет на другой узел, данные не будут доступны.
Некоторые облачные диски нельзя одновременно монтировать на два узла в режиме ReadWriteMany.
Неправильно указанный storageClassName или отсутствующий default StorageClass приведёт к ожиданию PVC в состоянии Pending.

Альтернативные подходы

Использовать объект StatefulSet для приложений, где важен постоянный идентификатор и привязка хранилища к реплике.
Применять оператор для динамических распределённых хранилищ (Rook, OpenEBS, Longhorn) для управления распределёнными томами.
Для мульти-рид/райт сценариев применять сетевые файловые системы (NFS, CIFS) или распределённые файловые системы (Ceph, GlusterFS).

Мини-методология внедрения постоянного хранилища (шаги)

Оцените требования приложения: IOPS, throughput, доступность, режим доступа.
Выберите тип хранилища и StorageClass, совместимый с accessModes.
Для локальной отладки используйте hostPath; в production — облачные/сетевые драйверы или CSI.
Настройте PVC с requests.storage и нужным storageClassName.
Примените манифесты и проверьте состояние PV/PVC.
Ручные тесты: создайте Pod, запишите и прочитайте данные при пересоздании Pod.
Документируйте политику удаления (reclaimPolicy) PV: Retain, Recycle или Delete.

Контрольные списки по ролям

DevOps / Platform Engineer

Настроить и документировать StorageClass в кластере.
Обеспечить резервное копирование PV и стратегию восстановления.
Проверить поддержку accessModes у выбранного провайдера.

Разработчик

Запросить PVC с адекватным размером и классом.
Разделить конфигурацию: secrets, configMaps и тома данных.
Тестировать восстановление при пересоздании Pod.

SRE

Следить за метриками дисковой подсистемы (IOPS, latency, available capacity).
Настроить alerting на заполнение PVC.
Прогонять сценарии failover и проверки данных.

Сравнение подходов (кратко)

hostPath: быстрый для разработки, не подходит для HA.
Cloud Block Storage (EBS/GCE PD): высокие IOPS, обычно RWO.
NFS/Share/Distributed FS: поддерживает RWX, может требовать управляющий кластер.
CSI-провайдеры: гибкость, динамический provisioning, зависят от реализации.

Диагностика типичных проблем

PVC остаётся в состоянии Pending: проверьте storageClassName и подходящие PV.
Сбои монтирования: проверьте права на директорию hostPath и логи kubelet на узле.
Неожиданное удаление данных: проверьте reclaimPolicy PV (Delete удалит ресурс вместе с PV).

Decision flowchart по выбору решения

flowchart TD
  A[Требуется постоянное хранилище?] -->|Нет| B[Используйте ephemeral тома]
  A -->|Да| C{Нужно монтирование на нескольких узлах}
  C -->|Нет| D[Используйте блоковое хранилище 'EBS/GCE PD']
  C -->|Да| E{Нужно RWX или только RO}
  E -->|RWX| F[Используйте NFS/CEPH/CSI с поддержкой RWX]
  E -->|RO| G[Можно использовать ReadOnlyMany через сетевой том]
  D --> H[Выбрать StorageClass и PVC]
  F --> H
  G --> H
  H --> I[Тестирование и мониторинг]

Критерии приёмки

PVC получает статус Bound к PV.
Данные, записанные в Pod, доступны после пересоздания Pod.
Размер PV >= заявленного в PVC.
Мониторинг оповещает при заполнении > 80%.

Краткая сводка ключевых фактов

PV независим от Pod; PVC — запрос Pod на использование PV.
StorageClass управляет динамическим созданием PV.
accessModes определяют, как и где можно монтировать том.
Для HA/мульти-нода используйте RWX-совместимые решения.

1‑строчный глоссарий

PersistentVolume (PV): абстракция физического или сетевого тома.
PersistentVolumeClaim (PVC): запрос Pod на PV.
StorageClass: шаблон и параметры для динамического provisioner’а.
accessModes: режимы монтирования тома (RWO, ROX, RWX).

Риски и рекомендации

Не используйте hostPath в production — потеря данных при переносе Pod.
Планируйте политику резервного копирования и восстановления заранее.
Проверяйте, поддерживает ли ваш провайдер нужные accessModes и постарайтесь автоматизировать создание StorageClass.

Заключение

PersistentVolume и PersistentVolumeClaim — основа постоянного хранения в Kubernetes. Понимание взаимодействия PV/PVC, выбора StorageClass и доступа критично для устойчивости приложений. Следуйте мини‑методологии, используйте role‑based контрольные списки и тестируйте сценарии восстановления, чтобы избежать потери данных.

Важно

Всегда документируйте выбранные StorageClass и стратегию удаления данных (reclaimPolicy).

Краткое резюме

Создавайте PVC для всех приложений с данными.
Подбирайте StorageClass в соответствии с требованиями (IOPS, доступность, режим доступа).
Тестируйте восстановление и мониторьте заполнение томов.