¿Qué son los StatefulSets, los PersistentVolumes/Claims y cómo se ejecutan workloads stateful en Kubernetes?

Question

IT Interview Practice · Accepted Answer

Los workloads stateful (bases de datos, colas, almacenes en cluster) necesitan **identidad estable** y **almacenamiento duradero**, cosas que un Deployment no proporciona. Un **StatefulSet** da a los Pods nombres estables y un ciclo de vida ordenado; los **PersistentVolumes (PV)** y **PersistentVolumeClaims (PVC)** les dan almacenamiento que sobrevive al Pod.

## Por qué los Deployments no bastan

```text
Los Pods de un Deployment son INTERCAMBIABLES: nombres aleatorios (web-7f9-abc), cualquier orden, no
comparten nada por-Pod. Perfecto para apps stateless — pero una réplica de base de datos necesita:
  → una IDENTIDAD de red ESTABLE (para que los pares la encuentren: db-0, db-1, db-2)
  → su PROPIO disco duradero que sobreviva a reinicios/reprogramaciones
  → arranque/escalado ORDENADO y controlado (levantar db-0 antes de db-1)
El StatefulSet proporciona exactamente esto.
```

## Garantías del StatefulSet

```text
NOMBRES estables → pod-0, pod-1, pod-2 (ordinal, no aleatorio)
DNS estable      → db-0.db.default.svc... vía un Service headless
STORAGE estable  → cada Pod recibe su PROPIO PVC (db-0 conserva su disco entre reinicios)
Ops ordenadas    → crear/escalar en orden 0,1,2…; terminar en orden inverso
```

## Almacenamiento persistente: PV, PVC, StorageClass

```text
StorageClass → la plantilla de "cómo aprovisionar" (p. ej. AWS gp3, fast-ssd)
PVC          → una PETICIÓN de almacenamiento ("necesito 20Gi, ReadWriteOnce")   ← de cara a la app
PV           → el volumen realmente aprovisionado y ligado al PVC                 ← de cara al cluster
Aprovisionamiento dinámico: un PVC que referencia una StorageClass auto-crea un PV que coincide.

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

## Un StatefulSet con almacenamiento por-Pod

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db            # Service headless para DNS estable
  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 recibe su PROPIO PVC/PV de esta plantilla
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources:
          requests: { storage: 20Gi }
```

```yaml
# El Service headless que da DNS estable 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 }]
```

## Modos de acceso y advertencias

```text
ReadWriteOnce (RWO)  → montado en lectura-escritura por UN node (la mayoría del block storage: EBS/PD)
ReadOnlyMany (ROX)   → solo lectura por muchos nodes
ReadWriteMany (RWX)  → lectura-escritura por muchos nodes (necesita NFS/CephFS/EFS)
⚠ Borrar un StatefulSet NO borra sus PVCs por defecto (los datos se conservan).
⚠ La reclaim policy (Retain/Delete) decide qué pasa con el PV cuando se elimina el PVC.
⚠ Kubernetes da identidad+almacenamiento, pero el clustering/replicación a nivel de app es TU trabajo
  (a menudo vía un Operator, p. ej. para Postgres/Kafka).
```

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

## Por qué es importante

Ejecutar workloads stateful correctamente es una de las partes más difíciles de Kubernetes, así que entender los StatefulSets y el almacenamiento persistente es conocimiento de nivel senior con consecuencias reales en producción. La idea central es *por qué* los Deployments se quedan cortos: sus Pods son intercambiables (nombres aleatorios, cualquier orden, sin estado por-Pod), lo que es ideal para servicios stateless pero incorrecto para bases de datos y almacenes en cluster que necesitan **identidad estable** (para que los pares encuentren `db-0`, `db-1`, `db-2` por DNS), **su propio disco duradero** que sobreviva a reinicios y reprogramaciones, y arranque y escalado **ordenados y controlados**. Un **StatefulSet** proporciona exactamente estas garantías, y se combina con las abstracciones de almacenamiento: un **PersistentVolumeClaim** es la petición de almacenamiento de cara a la aplicación, un **PersistentVolume** es el volumen realmente aprovisionado, y una **StorageClass** habilita el aprovisionamiento dinámico, con `volumeClaimTemplates` dando a cada Pod su propio PVC/PV. Las advertencias son donde los ingenieros senior se ganan el sueldo: los **modos de acceso** (RWO vs RWX y qué backends los soportan), el hecho de que borrar un StatefulSet **conserva sus PVCs** por defecto, la **reclaim policy** que gobierna el destino del PV y —crucialmente— que Kubernetes proporciona identidad y almacenamiento pero **la replicación y el clustering a nivel de aplicación siguen siendo tu responsabilidad**, a menudo delegados en un Operator. Como la durabilidad de los datos y el comportamiento stateful correcto no perdonan (los errores significan pérdida de datos o split-brain), dominar los StatefulSets, los PVs/PVCs y sus advertencias es fundamental para ejecutar bases de datos y otros sistemas stateful de forma fiable en Kubernetes.

Por qué los Deployments no bastan

Garantías del StatefulSet

Almacenamiento persistente: PV, PVC, StorageClass

Un StatefulSet con almacenamiento por-Pod

Modos de acceso y advertencias

Por qué es importante

Preguntas relacionadas