O que são StatefulSets, PersistentVolumes/Claims, e como você roda workloads stateful no Kubernetes?

Question

IT Interview Practice · Accepted Answer

Workloads stateful (bancos de dados, filas, stores em cluster) precisam de **identidade estável** e **storage durável** — coisas que um Deployment não fornece. Um **StatefulSet** dá aos Pods nomes estáveis e um ciclo de vida ordenado; **PersistentVolumes (PV)** e **PersistentVolumeClaims (PVC)** lhes dão storage que sobrevive ao Pod.

## Por que Deployments não bastam

```text
Pods de Deployment são INTERCAMBIÁVEIS: nomes aleatórios (web-7f9-abc), ordem qualquer, não
compartilham nada por Pod. Isso é perfeito para apps stateless — mas uma replica de banco precisa de:
  → uma IDENTIDADE de rede ESTÁVEL (para os peers a encontrarem: db-0, db-1, db-2)
  → seu PRÓPRIO disco durável que sobrevive a restarts/reagendamentos
  → startup/scaling ORDENADO e controlado (subir db-0 antes de db-1)
O StatefulSet fornece exatamente isso.
```

## Garantias do StatefulSet

```text
NOMES estáveis   → pod-0, pod-1, pod-2 (ordinal, não aleatório)
DNS estável      → db-0.db.default.svc... via um headless Service
STORAGE estável  → cada Pod recebe seu PRÓPRIO PVC (db-0 mantém seu disco entre restarts)
Ops ordenadas    → cria/escala para cima na ordem 0,1,2…; termina na ordem inversa
```

## Storage persistente: PV, PVC, StorageClass

```text
StorageClass → o template de "como provisionar" (ex.: AWS gp3, fast-ssd)
PVC          → uma REQUISIÇÃO de storage ("Preciso de 20Gi, ReadWriteOnce")   ← lado do app
PV           → o volume REAL provisionado, vinculado ao PVC                     ← lado do cluster
Provisionamento dinâmico: um PVC referenciando uma StorageClass cria automaticamente um PV correspondente.

App → PVC → (a StorageClass provisiona) → PV → disco real (EBS, PD, Ceph, NFS…)
```

## Um StatefulSet com storage por Pod

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db            # headless Service para DNS estável
  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:      # cada Pod recebe seu PRÓPRIO PVC/PV a partir deste template
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources:
          requests: { storage: 20Gi }
```

```yaml
# O headless Service que dá DNS estável por Pod (db-0.db, db-1.db, …)
apiVersion: v1
kind: Service
metadata: { name: db }
spec:
  clusterIP: None            # headless
  selector: { app: db }
  ports: [{ port: 5432 }]
```

## Access modes & ressalvas

```text
ReadWriteOnce (RWO)  → montado read-write por UM node (maioria dos block storage: EBS/PD)
ReadOnlyMany (ROX)   → read-only por muitos nodes
ReadWriteMany (RWX)  → read-write por muitos nodes (precisa de NFS/CephFS/EFS)
⚠ Deletar um StatefulSet NÃO deleta seus PVCs por padrão (os dados são preservados).
⚠ A reclaim policy (Retain/Delete) decide o que acontece com o PV quando o PVC é removido.
⚠ O Kubernetes dá identidade+storage, mas o clustering/replication no nível do app é TAREFA SUA
  (frequentemente via um Operator, ex.: para Postgres/Kafka).
```

```bash
kubectl get statefulset,pvc,pv
kubectl get pods -l app=db      # db-0, db-1, db-2 (estáveis, ordenados)
```

## Por que isso importa

Rodar workloads stateful corretamente é uma das partes mais difíceis do Kubernetes, então entender StatefulSets e storage persistente é conhecimento de nível sênior com consequências reais em produção. O insight central é *por que* os Deployments não são suficientes: seus Pods são intercambiáveis (nomes aleatórios, ordem qualquer, sem estado por Pod), o que é ideal para serviços stateless mas errado para bancos de dados e stores em cluster que precisam de **identidade estável** (para os peers encontrarem `db-0`, `db-1`, `db-2` por DNS), **seu próprio disco durável** que sobrevive a restarts e reagendamentos, e startup e scaling **ordenados e controlados**. Um **StatefulSet** fornece exatamente essas garantias, e ele se combina com as abstrações de storage: um **PersistentVolumeClaim** é a requisição de storage voltada à aplicação, um **PersistentVolume** é o volume realmente provisionado, e uma **StorageClass** habilita o provisionamento dinâmico — com `volumeClaimTemplates` dando a cada Pod seu próprio PVC/PV. As ressalvas são onde os engenheiros sênior provam seu valor: **access modes** (RWO vs RWX e quais backends os suportam), o fato de que deletar um StatefulSet **preserva seus PVCs** por padrão, a **reclaim policy** governando o destino do PV, e — criticamente — que o Kubernetes fornece identidade e storage mas **replication e clustering no nível da aplicação continuam sendo sua responsabilidade**, frequentemente delegados a um Operator. Como a durabilidade dos dados e o comportamento stateful correto são implacáveis (erros significam perda de dados ou split-brain), dominar StatefulSets, PVs/PVCs e suas ressalvas é fundamental para rodar bancos de dados e outros sistemas stateful de forma confiável no Kubernetes.

Por que Deployments não bastam

Garantias do StatefulSet

Storage persistente: PV, PVC, StorageClass

Um StatefulSet com storage por Pod

Access modes & ressalvas

Por que isso importa

Perguntas relacionadas