PV, PVC и StorageClass: как хранить stateful workload

⚙️ Теория

🧱 Базовые сущности хранения

PV (PersistentVolume): ресурс хранения в кластере.
PVC (PersistentVolumeClaim): запрос на хранение от workload.
StorageClass: правила динамического provisioning.

Обычно приложение работает через PVC, а детали хранилища скрыты за StorageClass.

🔄 Жизненный цикл PVC/PV

Создается PVC.
Если есть подходящий PV — bind к нему.
Если PV нет — провиженер создает PV динамически (по StorageClass).
При удалении PVC поведение зависит от reclaim policy PV:
- Delete
- Retain

📌 Access modes и volumeMode

Часто используемые режимы:

ReadWriteOnce (RWO)
ReadOnlyMany (ROX)
ReadWriteMany (RWX)

И отдельный выбор volumeMode:

Filesystem
Block

Важно проверять поддержку конкретным storage backend.

⚠️ Где главные риски

ожидание RWX там, где backend поддерживает только RWO;
некорректная reclaim policy (Delete вместо Retain для критичных данных);
отсутствие backup/restore тестов.

❓ Что нужно уметь объяснить

Почему PVC не "создает диск" сам по себе?

PVC это декларация потребности. Реальное выделение делает провиженер через StorageClass/CSI.

Почему reclaim policy это критичный параметр?

Она определяет судьбу данных после удаления claim. Неправильный выбор может привести к безвозвратной потере данных.

Почему StatefulSet важен вместе с PVC?

StatefulSet обеспечивает стабильную identity и предсказуемое привязывание томов для stateful workload.

🧪 Практика

1. Пример StorageClass + PVC

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
# Замените на provisioner вашего кластера (например ebs.csi.aws.com, pd.csi.storage.gke.io и т.д.)
provisioner: ebs.csi.aws.com
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data
spec:
  accessModes: ["ReadWriteOnce"]
  resources:
    requests:
      storage: 20Gi
  storageClassName: fast-ssd

2. Проверка binding и событий

kubectl get pvc,pv
kubectl describe pvc app-data
kubectl get events --sort-by=.lastTimestamp

3. Guardrails

для критичных данных использовать Retain + backup policy;
регулярно тестировать restore, а не только backup;
фиксировать StorageClass как часть архитектурного контракта приложения.

🧾 Вывод

Kubernetes storage надежен при ясной модели: корректный StorageClass, реалистичные access modes и проверенный backup/restore процесс. Основные инциденты происходят из неверных ожиданий к backend и reclaim policy.

📚 Ссылки

✅ Проверка источников

Kubernetes Storage Docs