Организация работы с Persistent Volume в Kubernetes‑кластере

Почему необходимы постоянные тома

В современных облачных и on‑premise‑средах Kubernetes изначально ориентировался на stateless‑приложения, где каждый pod мог быть уничтожен без потери данных. При росте количества сервисов, требующих сохранения состояния (базы данных, кеши, системы очередей), появляется необходимость обеспечить стабильный доступ к локальному хранинию, которое живёт дольше, чем отдельный pod. Persistent Volume (PV) и Persistent Volume Claim (PVC) решают эту задачу, отделяя управление хранилищем от жизненного цикла контейнеров и позволяя использовать как локальные, так и сетевые диски, облачные блобы и специализированные решения (Ceph, Portworx, OpenEBS).

Стратегия развертывания PV в кластере

Для упрощения администрирования и обеспечения масштабируемости рекомендуется придерживаться следующего плана:

1. Определить типы данных и их требования – уровень IOPS, размер, задержки, необходимость шифрования и репликации.
2. Выбрать подходящий провайдер хранилища – облачные диски (AWS EBS, GCP PD, Azure Disk), сетевые файловые системы (NFS, GlusterFS) или распределённые решения (Ceph RBD, Longhorn).
3. Создать StorageClass с параметрами, соответствующими выбранному провайдеру, и задать политику reclaimPolicy (Retain, Delete, Recycle) в зависимости от того, нужно ли сохранять данные после удаления PV.
4. Настроить динамическое выделение – так k8s будет автоматически создавать PV под каждый PVC, избавляя от ручного управления.
5. Внедрить обязательные политики доступа – accessModes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany) и ограничения на тип тома через volumeBindingMode.

Создание StorageClass и динамическое выделение

Пример StorageClass для локального SSD в on‑premise‑среде:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-ssd
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete
allowedTopologies:
  - matchLabelExpressions:
      - key: topology.kubernetes.io/zone
        values: ["zone-a"]

Для облачных дисков (AWS EBS) типичный шаблон выглядит так:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-gp2
provisioner: ebs.csi.aws.com
parameters:
  type: gp2
  encrypted: "true"
reclaimPolicy: Retain
volumeBindingMode: Immediate

После создания StorageClass пользователи могут запросить том через PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: db-data
spec:
  storageClassName: ebs-gp2
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi

Kubernetes автоматически связывает PVC с новым PV, созданным по правилам StorageClass.

Работа с StatefulSet и PVC

Для приложений, требующих уникального постоянного хранилища на каждый pod (например, PostgreSQL, Redis), рекомендуется использовать StatefulSet. Основные преимущества:

• Stable network identity – каждый pod получает предсказуемый DNS‑имя (my-db-0, my-db-1).
• Персистентные тома – volumeClaimTemplates позволяют генерировать отдельный PVC для каждого реплики.

Пример StatefulSet с автоматическим созданием PVC:

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

Каждая реплика получит собственный PVC pgdata-<statefulset>-<ordinal>, что гарантирует изоляцию данных и упрощает масштабирование.

Обеспечение отказоустойчивости и резервного копирования

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

1. Репликация на уровне хранилища – многие провайдеры (Ceph, Portworx) позволяют задать количество реплик при создании PV.
2. Snapshot‑ы – CSI‑драйверы поддерживают создание мгновенных снимков томов. Их можно интегрировать в CI/CD‑pipeline или использовать в качестве точки восстановления.
3. Бэкапы на внешние хранилища – инструменты Velero, Stash или кастомные скрипты позволяют экспортировать данные в облако (S3, GCS) и восстанавливать их в новых кластерах.
4. Политика reclaimPolicy: Retain сохраняет том после удаления PVC, что удобно при миграции или ручном восстановлении.

Пример создания snapshot через CSI:

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: pgdata-snap-2024-02-25
spec:
  volumeSnapshotClassName: ebs-snapshot
  source:
    persistentVolumeClaimName: pgdata-0

Мониторинг и управление томами

Эффективный контроль над PV требует интеграции с системами наблюдения:

• Prometheus exporter (kube‑state‑metrics, csi‑driver‑metrics) собирает метрики о состоянии PVC, доступных ресурсах и ошибках.
• Grafana‑дашборды визуализируют заполненность томов, количество доступных PV по StorageClass и время создания/удаления.
• Alertmanager генерирует оповещения при превышении порогов (например, заполнение более 80 %).
• kubectl и k9s позволяют быстро проверять привязку PVC к PV, статус Bound/Pending и параметры accessModes.

Регулярный аудит прав доступа (RBAC) к объектам PersistentVolume, PersistentVolumeClaim и StorageClass предотвращает несанкционированное создание или удаление томов, что особенно важно в мульти‑тенантных кластерах.