Container es efímero. Base de datos, uploads, colas y backups no pueden serlo. Kubernetes separa quién usa el storage (pod) de quién proporciona (infraestructura) con tres objetos: PV, PVC y StorageClass.

Sello del curso: probado en Kubernetes 1.35, NFS y local-path.

El modelo

Objeto	Papel
Volume	montaje dentro del pod
PV (PersistentVolume)	recurso de storage en el cluster
PVC (PersistentVolumeClaim)	solicitud de storage por el usuario
StorageClass	“clase” que aprovisiona PVs dinámicamente
CSI	driver de storage (estándar moderno)

Flujo:

PVC (pedido) → StorageClass (provisiona) → PV (disco) → Pod (monta)

Volumen efímero vs persistente

• emptyDir: vive mientras el pod vive. Bueno para cache/tmp.
• hostPath: monta un directorio del nodo. Evítelo en producción; ata el pod al nodo.
• PVC: persiste más allá del pod.

volumes:
  - name: cache
    emptyDir: {}
  - name: data
    persistentVolumeClaim:
      claimName: app-data

PV y PVC a mano

PV:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs-5gi
spec:
  capacity:
    storage: 5Gi
  accessModes: ["ReadWriteMany"]
  persistentVolumeReclaimPolicy: Retain
  nfs:
    server: 192.168.56.50
    path: /srv/nfs/app

PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data
spec:
  accessModes: ["ReadWriteMany"]
  resources:
    requests:
      storage: 5Gi

El PVC solo se vincula si el tamaño, el modo de acceso y la clase coinciden. Si queda Pending, revise los eventos:

kubectl describe pvc app-data
kubectl get pv

StorageClass y aprovisionamiento dinámico

Con StorageClass, no crea PV manualmente:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: portal-nfs
provisioner: nfs.csi.k8s.io
parameters:
  server: 192.168.56.50
  share: /srv/nfs/portal
reclaimPolicy: Retain
volumeBindingMode: Immediate

En el PVC:

spec:
  storageClassName: portal-nfs

volumeBindingMode: WaitForFirstConsumer es útil para storage local: el PV solo se crea cuando el pod se programa, evitando que el PVC quede atado a un nodo equivocado.

Modos de acceso

Modo	Significado
RWO	ReadWriteOnce — un nodo a la vez
ROX	ReadOnlyMany — varios nodos, lectura
RWX	ReadWriteMany — varios nodos, escritura
RWOP	ReadWriteOncePod — un pod a la vez

NFS suele admitir RWX. Los discos de bloque normalmente son RWO. local-path es RWO y atado al nodo — si el pod cambia de nodo, el volumen no lo acompaña.

El caso de local-path

El local-path-provisioner crea PVs que apuntan a un directorio del nodo. Es ideal para laboratorio y para cargas que no migran (cache, monitoreo local).

Problema: el PV tiene nodeAffinity para el nodo donde fue creado. Si el pod se reprograma a otro nodo, el PVC queda Pending.

Síntoma:

pod has unbound immediate PersistentVolumeClaims

o el pod queda Pending con evento de node affinity. Solución: usar storage compartido (NFS/Ceph) o aceptar que la carga está atada al nodo.

StatefulSet y PVC

StatefulSet crea un PVC por réplica:

volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: portal-nfs
      resources:
        requests:
          storage: 5Gi

El PVC tiene el nombre <template>-<statefulset>-<ordinal>. Eliminar el StatefulSet no borra el PVC por defecto. Esto es bueno para la recuperación y malo para la limpieza; gestiónelo con intención.

Redimensionamiento y snapshots

• Redimensionar PVC depende del driver y del allowVolumeExpansion en la StorageClass.
• Los snapshots dependen de CSI (VolumeSnapshotClass).
• El backup de la aplicación no es solo volumen: la base de datos necesita un dump consistente. Velero ayuda con los PV, pero el dump lógico es insustituible.

Laboratorio

1. Cree un PVC NFS y móntelo en un pod:

kubectl apply -f pvc-nfs.yaml
kubectl run app --image=nginx:1.27 --overrides='
{"spec":{"containers":[{"name":"app","image":"nginx:1.27",
"volumeMounts":[{"name":"data","mountPath":"/data"}]}],
"volumes":[{"name":"data","persistentVolumeClaim":{"claimName":"app-data"}}]}}'
kubectl exec app -- sh -c 'echo hello > /data/teste && cat /data/teste'

2. Elimine el pod y vuelva a crearlo; el archivo debe continuar.
3. Cree un PVC con local-path y simule la reprogramación a otro nodo — vea que el PVC queda atado.
4. Inspeccione kubectl get pv,pvc y los eventos.

Errores comunes

Síntoma	Causa
PVC Pending	sin PV/StorageClass, tamaño o modo de acceso incompatible
Pod Pending con PVC	node affinity del PV local
Permission denied	UID/GID o permisos en el NFS
Datos “desaparecieron”	el pod montó emptyDir en lugar del PVC
PVC no se expande	StorageClass sin allowVolumeExpansion
RWX no funciona	el driver no admite múltiples nodos

Checklist

• [ ] Sé la diferencia entre emptyDir, hostPath y PVC.
• [ ] StorageClass predeterminada definida.
• [ ] Modo de acceso correcto para la carga.
• [ ] Sé si el storage está atado al nodo (local-path).
• [ ] StatefulSet tiene volumeClaimTemplates.
• [ ] Backup del volumen y dump lógico probados.

Glosario

• PV: recurso de storage.
• PVC: solicitud de storage.
• StorageClass: aprovisionador dinámico.
• CSI: Container Storage Interface.
• RWX/RWO: modos de acceso.
• Reclaim policy: qué sucede con el PV al eliminar el PVC.

Siguiente

Ahora que los datos persisten, vamos a configurar la aplicación sin reconstruir la imagen: ConfigMap, Secret y el guard que ya derribó un deploy nuestro.

Siguiente: Curso Kubernetes 12 — ConfigMap, Secret y el guard de credenciales