Что такое StatefulSet, PersistentVolume/Claim, и как запускать stateful-нагрузки на Kubernetes?

Question

IT Interview Practice · Accepted Answer

Stateful-нагрузки (базы данных, очереди, кластеризованные хранилища) нуждаются в **стабильной идентичности** и **надёжном хранилище** — вещах, которые Deployment не предоставляет. **StatefulSet** даёт Pod стабильные имена и упорядоченный жизненный цикл; **PersistentVolume (PV)** и **PersistentVolumeClaim (PVC)** дают им хранилище, которое переживает Pod.

## Почему Deployment недостаточно

```text
Pod из Deployment ВЗАИМОЗАМЕНЯЕМЫ: случайные имена (web-7f9-abc), любой порядок, ничего
не разделяют на уровне Pod. Это идеально для stateless-приложений — но реплике БД нужна:
  → СТАБИЛЬНАЯ сетевая идентичность (чтобы пиры находили её: db-0, db-1, db-2)
  → СОБСТВЕННЫЙ надёжный диск, переживающий перезапуски/перепланирование
  → УПОРЯДОЧЕННЫЙ, контролируемый запуск/масштабирование (поднять db-0 до db-1)
StatefulSet предоставляет именно это.
```

## Гарантии StatefulSet

```text
Стабильные ИМЕНА    → pod-0, pod-1, pod-2 (порядковые, не случайные)
Стабильный DNS       → db-0.db.default.svc... через headless Service
Стабильное ХРАНИЛИЩЕ → каждый Pod получает СВОЙ PVC (db-0 сохраняет диск при перезапуске)
Упорядоченные операции → создание/увеличение по порядку 0,1,2…; завершение в обратном порядке
```

## Постоянное хранилище: PV, PVC, StorageClass

```text
StorageClass → шаблон "как выделять" (например, AWS gp3, fast-ssd)
PVC          → ЗАПРОС на хранилище ("Нужно 20Gi, ReadWriteOnce")   ← со стороны приложения
PV           → РЕАЛЬНЫЙ выделенный том, привязанный к PVC           ← со стороны кластера
Динамический провижининг: PVC, ссылающийся на StorageClass, авто-создаёт подходящий PV.

App → PVC → (StorageClass выделяет) → PV → реальный диск (EBS, PD, Ceph, NFS…)
```

## StatefulSet с хранилищем на каждый Pod

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db            # headless Service для стабильного DNS
  replicas: 3
  selector:
    matchLabels: { app: db }
  template:
    metadata:
      labels: { app: db }
    spec:
      containers:
        - name: db
          image: postgres:16
          ports: [{ containerPort: 5432 }]
          volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:      # каждый Pod получает СВОЙ PVC/PV из этого шаблона
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources:
          requests: { storage: 20Gi }
```

```yaml
# Headless Service, дающий стабильный DNS на каждый Pod (db-0.db, db-1.db, …)
apiVersion: v1
kind: Service
metadata: { name: db }
spec:
  clusterIP: None            # headless
  selector: { app: db }
  ports: [{ port: 5432 }]
```

## Режимы доступа и оговорки

```text
ReadWriteOnce (RWO)  → монтируется на чтение-запись ОДНИМ node (большинство блочных хранилищ: EBS/PD)
ReadOnlyMany (ROX)   → только на чтение многими node
ReadWriteMany (RWX)  → на чтение-запись многими node (нужен NFS/CephFS/EFS)
⚠ Удаление StatefulSet по умолчанию НЕ удаляет его PVC (данные сохраняются).
⚠ Reclaim policy (Retain/Delete) решает, что происходит с PV при удалении PVC.
⚠ Kubernetes даёт идентичность+хранилище, но кластеризация/репликация на уровне приложения — ВАША задача
  (часто через Operator, например для Postgres/Kafka).
```

```bash
kubectl get statefulset,pvc,pv
kubectl get pods -l app=db      # db-0, db-1, db-2 (стабильные, упорядоченные)
```

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

Корректный запуск stateful-нагрузок — одна из более сложных частей Kubernetes, поэтому понимание StatefulSet и постоянного хранилища — знание уровня senior с реальными production-последствиями. Ключевая мысль — *почему* Deployment недостаточно: его Pod взаимозаменяемы (случайные имена, любой порядок, нет состояния на уровне Pod), что идеально для stateless-сервисов, но неверно для баз данных и кластеризованных хранилищ, которым нужна **стабильная идентичность** (чтобы пиры находили `db-0`, `db-1`, `db-2` по DNS), **собственный надёжный диск**, переживающий перезапуски и перепланирование, и **упорядоченные, контролируемые** запуск и масштабирование. **StatefulSet** предоставляет именно эти гарантии и работает в паре с абстракциями хранилища: **PersistentVolumeClaim** — это запрос на хранилище со стороны приложения, **PersistentVolume** — реальный выделенный том, а **StorageClass** обеспечивает динамический провижининг — при этом `volumeClaimTemplates` даёт каждому Pod свой PVC/PV. Оговорки — там, где senior-инженеры отрабатывают свой хлеб: **режимы доступа** (RWO против RWX и какие бэкенды их поддерживают), тот факт, что удаление StatefulSet **сохраняет его PVC** по умолчанию, **reclaim policy**, управляющая судьбой PV, и — критически — то, что Kubernetes предоставляет идентичность и хранилище, но **репликация и кластеризация на уровне приложения остаются вашей ответственностью**, часто делегируемой Operator. Поскольку сохранность данных и корректное stateful-поведение неумолимы (ошибки означают потерю данных или split-brain), овладение StatefulSet, PV/PVC и их оговорками фундаментально для надёжного запуска баз данных и других stateful-систем на Kubernetes.

Почему Deployment недостаточно

Гарантии StatefulSet

Постоянное хранилище: PV, PVC, StorageClass

StatefulSet с хранилищем на каждый Pod

Режимы доступа и оговорки

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

Похожие вопросы