Si gestionas aplicaciones en Kubernetes y no configuras almacenamiento persistente, corres el riesgo de perder toda tu información cuando un pod se reinicie. Aquí entran los persistent volume (PV) y persistent volume claim (PVC), dos objetos clave para guardar datos dentro del clúster sin depender siempre de servicios externos costosos.

Esta guía es útil para quienes trabajan con bases de datos, colas como RabbitMQ o cualquier servicio stateful en entornos de desarrollo, donde ahorrar en infraestructura sí marca diferencia.

Qué diferencia hay entre stateless y stateful en Kubernetes

Antes de tocar PV y PVC, conviene aclarar cómo se comportan tus aplicaciones frente a los datos.

Una aplicación stateless resuelve cada petición de forma independiente. Piensa en un REST API que recibe en el body todo lo necesario: el backend procesa, responde y olvida. No necesita memoria entre peticiones.

En cambio, una aplicación stateful recibe información limitada y necesita ir a una base de datos para completar la respuesta. Aquí la persistencia importa, porque sin ese almacén la lógica se rompe.

¿Cuándo necesito almacenamiento persistente en Kubernetes? Cuando tu aplicación es stateful, es decir, depende de datos guardados entre peticiones, como bases de datos, colas o sistemas de archivos compartidos.

Cómo funcionan los persistent volume y persistent volume claim

La forma más clara de entenderlo es con una analogía: el PV es el almacén de datos y el PVC es la llave que te permite entrar a ese almacén [02:30].

Un pod nunca accede directamente al volumen. En su lugar, hace referencia a un PVC, y ese PVC se enlaza con un PV mediante labels coincidentes. Esa relación uno a uno es la que Kubernetes usa para garantizar que solo las aplicaciones autorizadas toquen los datos.

En los archivos YAML verás esta cadena:

• El pod referencia un PVC en su sección de volumes.
• El PVC declara capacidad, modos de acceso y storageClassName.
• El PV expone la capacidad real y la ruta donde viven los datos.

Qué tipos de almacenamiento puedes usar con storage classes

Kubernetes maneja distintos tipos de almacenamiento mediante las storage classes. En entornos locales con Minikube se usa la clase manual, que apunta a un directorio dentro del nodo, como /mnt/data.

En producción puedes apoyarte en proveedores externos. Con AWS, por ejemplo, tienes dos opciones potentes:

• EFS (Elastic File System) para sistemas de archivos compartidos.
• EBS (Elastic Block Storage) para volúmenes de bloque asociados a instancias.

Usar estos servicios externos te da alta disponibilidad, backup automático y facilidad para migrar datos entre clústeres.

Cómo crear un PV y un PVC paso a paso en Minikube

El ejemplo práctico monta un archivo index.html dentro del nodo de Minikube y lo expone a través de un pod con nginx. La idea es comprobar que el contenido persiste fuera del pod.

Primero entras al nodo con minikube ssh [06:50]. Como Minikube es restrictivo con permisos, ejecuta sudo su para escribir en /mnt/data/index.html con un contenido sencillo: <h1>Hello from volume</h1>.

Después vuelves a tu terminal y aplicas los manifiestos:

1. kubectl apply -f sobre el archivo del PV y PVC.
2. kubectl apply -f sobre el archivo del pod que consume ese PVC.
3. kubectl get pv y kubectl get pvc para confirmar la creación.

Qué define el YAML del persistent volume

El manifiesto del PV especifica varios campos críticos [08:40]:

• capacity: 1Gi en este caso.
• accessModes: por ejemplo ReadWriteOnce, que permite montar el volumen en un solo pod a la vez.
• storageClassName: manual para entornos locales.
• hostPath: la ruta /mnt/data dentro del nodo.

El PVC, por su parte, reclama una porción de ese volumen. El enlace entre PV y PVC ocurre cuando los labels y el storageClassName coinciden. Así Kubernetes sabe qué llave abre qué almacén.

Cómo conecta el pod con el PVC

Dentro del YAML del pod no se referencia el PV directamente. Se referencia el PVC en la sección volumes, con el nombre mypvc. Luego, en volumeMounts, montas ese volumen en /usr/share/nginx/html, que es la ruta donde nginx sirve los archivos por defecto.

¿Por qué un pod no accede directo al PV? Porque el PVC actúa como capa de control: garantiza que solo las aplicaciones con la reclamación correcta puedan leer o escribir en el volumen.

Cómo validar que el volumen funciona correctamente

Una vez creados los recursos, ejecuta kubectl describe pod mypod para ver la sección de volumes enlazada al PVC mypvc en modo readOnly: false.

Luego comprueba que el archivo viajó desde el host hasta el contenedor:

bash kubectl exec mypod -- ls -la /usr/share/nginx/html

Deberías ver index.html listado. Para cerrar la prueba, expón el servicio con un port forward:

bash kubectl port-forward pod/mypod 8080:80

Abre localhost:8080 en tu navegador y verás el mensaje Hello from volume servido por nginx desde el archivo que creaste en Minikube.

Con esta configuración garantizas que tus datos sobrevivan al ciclo de vida del pod. En tiempos donde la información de tus clientes vale oro, dejar de usar PV y PVC no es una opción. ¿Qué modos de acceso te imaginas útiles para tus aplicaciones? Cuéntalo en los comentarios.