Dejamos el PersistentVolume pv-postgres-reservas-10gi en fase Available, con la columna CLAIM vacía y 10 GiB esperando a alguien. Un PV no se monta solo: hace falta que la aplicación lo reclame, y esa reclamación es un objeto con namespace llamado PersistentVolumeClaim (PVC). Esta es la lección en la que la deuda del módulo se salda de verdad: escribirás el PVC, entenderás con precisión el algoritmo por el que el controlador empareja demanda y oferta, montarás el volumen en el pod de postgres-reservas y harás la prueba que llevamos prometiendo desde el módulo 2 —crear una reserva, borrar el pod y encontrarla intacta—. Verás además qué ocurre al borrar un PVC, por qué a veces se queda en Terminating, y por qué un Deployment con un PVC ReadWriteOnce no puede escalar.

1. Qué es exactamente un PersistentVolumeClaim
2. Anatomía del objeto campo a campo
3. El algoritmo de emparejamiento
4. Por qué puedes recibir más espacio del que pediste
5. El estado Pending y su diagnóstico
6. Consumir el PVC desde el pod
7. El manifiesto definitivo de postgres-reservas
8. La demostración: los datos sobreviven al pod
9. La relación 1:1 y el peligro de dos pods sobre un RWO
10. Borrar un PVC: finalizadores y Terminating
11. Por qué un Deployment con PVC no escala

Un PersistentVolumeClaim es la petición de almacenamiento que hace una aplicación. La analogía que mejor funciona es la de los recursos de cómputo que ya conoces de 03-04:

Sus dos propiedades definitorias:

1. Tiene namespace. Vive junto a la aplicación que lo usa, se ve afectado por las ResourceQuota del namespace (03-04) y desaparece si se borra el namespace. Un pod solo puede montar PVCs de su propio namespace: no existe forma de referenciar un PVC de otro.
2. Es la única pieza de almacenamiento que escribe el equipo de aplicación. En un clúster con aprovisionamiento dinámico bien configurado, un desarrollador nunca escribe un PersistentVolume; escribe PVCs.

Los campos, con su significado exacto:

Dos campos merecen un comentario aparte.

Funciona igual que los selectores de 02-07, con matchLabels y matchExpressions, y se aplica sobre las etiquetas del PV. Sirve para expresar requisitos que la capacidad no captura: matchExpressions: [{ key: tipo-disco, operator: In, values: ["ssd", "nvme"] }] significa "quiero un disco rápido, me da igual cuál".

Cuidado: si el PVC lleva selector, el aprovisionamiento dinámico no puede satisfacerlo (un volumen recién creado no tendrá esas etiquetas), así que el PVC quedará Pending para siempre en un clúster que solo use StorageClasses. Es un campo del mundo estático.

Ata el PVC a un PV concreto por su nombre, saltándose la búsqueda. Es útil en una recuperación —"quiero exactamente ese volumen, el que tiene los datos"— y es el complemento del claimRef que viste en 05-02: si ambos objetos se nombran mutuamente, la vinculación es determinista y nadie más puede colarse.

Cuando creas un PVC sin volumeName, el controlador de PersistentVolume (parte de kube-controller-manager) busca un PV candidato. El proceso, en orden:

Los cinco criterios, sin excepciones:

1. La misma storageClassName, comparada como cadena exacta. "" y ausente no son lo mismo.
2. capacity.storage del PV ≥ requests.storage del PVC. Mayor o igual, nunca menor.
3. Los accessModes del PVC deben estar contenidos en los del PV. Si el PVC pide ["ReadWriteMany"] y el PV ofrece ["ReadWriteOnce"], no hay trato.
4. volumeMode idéntico.
5. El selector del PVC, si existe, debe casar con las etiquetas del PV.

Entre todos los candidatos, el controlador elige el de menor capacidad, para desperdiciar lo menos posible. Y una vez decidido, la vinculación es bidireccional y exclusiva: se escribe spec.claimRef en el PV y spec.volumeName en el PVC. A partir de ahí ambos objetos están casados y ningún otro PVC puede usar ese PV, aunque sobre espacio.

De la regla 2 se deriva un comportamiento que sorprende: requests.storage es un mínimo, no una talla exacta. Si pides 8 GiB y el único PV disponible tiene 10 GiB, te vinculas a él y kubectl get pvc informa de CAPACITY: 10Gi. Consecuencias prácticas:

• No hay devolución. Los 2 GiB de diferencia se pierden para el resto del clúster: nadie más puede usar ese PV.
• La ResourceQuota cuenta lo pedido, no lo obtenido. Si el namespace tiene requests.storage: 20Gi de cuota (03-04), tu PVC de 8 GiB consume 8 GiB de cuota aunque disfrutes de 10.
• En aprovisionamiento dinámico esto no ocurre: el volumen se crea exactamente del tamaño pedido (redondeado al mínimo del proveedor). Es una razón más para preferirlo.

Lo que nunca pasa es lo contrario: un PVC jamás se vincula a un PV más pequeño del que pidió.

Pending es el estado que más vas a ver y a diagnosticar. Significa una sola cosa: el PVC no ha encontrado volumen. Las causas son pocas y el método para distinguirlas es siempre el mismo.

Los eventos del final son la clave:

Y el procedimiento de diagnóstico, en orden, cuando el evento no basta:

Un Pending en el PVC arrastra al pod: se queda en Pending también, con el evento del planificador pod has unbound immediate PersistentVolumeClaims. Diagnostica siempre el PVC primero; el pod es solo el síntoma.

En el pod, el PVC se usa a través de un volumen del tipo persistentVolumeClaim. La mecánica volumes/volumeMounts de 05-01 no cambia en absoluto:

Eso es todo. El pod no menciona el PersistentVolume por ninguna parte, ni el proveedor, ni el disco: solo el nombre del PVC. Esa indirección es la que hace que el mismo manifiesto funcione en minikube y en producción.

Ha llegado el momento de borrar el comentario "PROVISIONAL" que arrastramos desde 02-05. Primero el PVC:

Bound por ambos lados. La columna CLAIM del PV, que en la lección anterior estaba vacía, ahora nombra al PVC con su namespace. Y el Deployment completo:

Cuando un volumen de bloques se formatea con ext4, su raíz contiene un directorio lost+found. Y el initdb de PostgreSQL se niega a inicializar un directorio de datos que no esté vacío:

Hay dos formas de resolverlo, y en el manifiesto están las dos, lo que no es redundancia sino cinturón y tirantes:

En Rutas Norte adoptamos PGDATA como mecanismo principal (ya venía del módulo 3) porque el subPath tiene una desventaja seria: un volumen montado con subPath no se redimensiona automáticamente en algunos controladores, lo que complica la expansión de 05-05. Si eliges solo uno, elige PGDATA para PostgreSQL y reserva subPath para el caso general de otras aplicaciones.

El proceso de PostgreSQL no corre como root, sino como el usuario postgres (UID 999 en la imagen oficial). Un volumen recién creado suele pertenecer a root:root, así que el proceso no puede escribir:

securityContext.fsGroup: 999 hace que el kubelet cambie el grupo propietario del volumen a 999 y le añada permiso de escritura al montarlo. Es la solución estándar y se trata en profundidad en 08-02.

Este es el momento del módulo. Aplicamos y repetimos exactamente el experimento de 05-01, que entonces perdió todos los datos.

Creamos una reserva ficticia:

Y ahora la prueba. Borramos el pod, igual que haría un rollout, un desalojo o la caída del nodo:

Las reservas siguen ahí, en un pod distinto, con otro nombre y otra IP. La deuda del módulo 2 está saldada. Y puedes verificar dónde viven realmente los bytes con minikube ssh -p rutas-norte -- "sudo ls -l /data/postgres-reservas/pgdata": los ficheros son del UID 999 gracias a fsGroup, y están en el directorio del nodo, fuera del contenedor.

Sube la apuesta si quieres: borra el Deployment entero y vuelve a aplicarlo. Los datos siguen, porque el PVC y el PV no dependen del Deployment.

La relación entre PVC y PV es estrictamente 1:1. Un PV vinculado no admite un segundo PVC ni aunque le sobren 9 GiB de 10. Compruébalo:

Pending: el único PV de esa clase está Bound. Bórralo y sigamos.

Ahora la parte peligrosa. Varios pods sí pueden montar el mismo PVC, y ahí es donde reaparece la trampa de 05-02:

El error del segundo caso, que verás en cuanto trabajes con un clúster de varios nodos:

Ese mensaje es una protección, no una avería: el controlador de conexión impide que un disco de bloques se conecte a dos máquinas. Lo grave es el primer caso, donde nadie te protege. Por eso, para cualquier carga con estado sobre ReadWriteOnce, la combinación obligatoria en Rutas Norte es:

• replicas: 1
• strategy: Recreate (termina el pod viejo antes de crear el nuevo)
• y, si el driver lo soporta, ReadWriteOncePod en PV y PVC.

Borrar un PVC en uso es una operación que casi nunca sale como el principiante espera, y por buenas razones.

El comando se queda colgado. Y en otra terminal, la explicación:

kubernetes.io/pvc-protection es la protección de objeto de almacenamiento en uso. Mientras un pod activo esté usando el PVC, el finalizador no se retira y el objeto no se borra. Es el mecanismo de finalizadores de 01-06 aplicado a evitar que alguien vuele el almacenamiento de una aplicación en marcha.

La solución es eliminar primero al consumidor, nunca forzar el finalizador:

Nunca hagas kubectl patch pvc ... -p '{"metadata":{"finalizers":null}}'. Es la receta que circula por internet para "desatascar" un PVC y lo que consigue es dejar el volumen real conectado a un nodo sin ningún objeto que lo represente: un huérfano invisible que hay que limpiar a mano en el proveedor.

Cuando el PVC desaparece, el destino del PV lo decide su política de reclamación (05-02):

En nuestro caso el PV queda Released, con la columna CLAIM mostrando todavía rutas-norte-dev/postgres-reservas-datos, y las reservas dentro. Para volver a la situación operativa, aplicas el rescate que ya conoces y vuelves a crear el PVC y el Deployment:

Esa es la razón de ser de Retain en una base de datos con datos personales. Con Delete, este ejercicio habría terminado con la pérdida de todas las reservas de Rutas Norte.

Última pieza, y es una limitación de fondo, no un detalle. Prueba a escalar:

En un clúster de varios nodos verías dos pods atascados con Multi-Attach error. En minikube, que tiene un solo nodo, verías algo peor: los tres pods arrancan, montan el mismo directorio de datos y PostgreSQL empieza a quejarse de que ya hay una instancia usando ese directorio (o, con otro motor menos protegido, corrompe los ficheros en silencio).

La razón es estructural: todos los pods de un Deployment comparten exactamente la misma plantilla, incluida la lista de volumes. Si la plantilla dice claimName: postgres-reservas-datos, las tres réplicas piden ese mismo PVC. Un Deployment no sabe dar a cada réplica su propio volumen.

La solución correcta es el StatefulSet, que incorpora un volumeClaimTemplate: crea un PVC por réplica, con nombre estable y ligado a la identidad del pod, de modo que postgres-reservas-0 siempre reencuentra su volumen. Es el objeto que abre el módulo 6 en 06-01, y ahora sabes exactamente qué problema viene a resolver.

Mientras tanto, la regla operativa para Rutas Norte es clara y suficiente: postgres-reservas es un Deployment de una sola réplica con strategy: Recreate y un PVC ReadWriteOnce. Devuélvelo a su sitio:

Consejos:

1. Comando de cabecera para ver oferta y demanda a la vez:

   kubectl get pvc -A -o custom-columns=\
   NS:.metadata.namespace,PVC:.metadata.name,ESTADO:.status.phase,\
   PV:.spec.volumeName,PEDIDO:.spec.resources.requests.storage,CLASE:.spec.storageClassName
   

2. Averigua quién usa un PVC antes de borrarlo, filtrando kubectl get pods -o json con jq por .spec.volumes[]?.persistentVolumeClaim.claimName.
3. Nombra los PVC por su función, no por su tamaño: postgres-reservas-datos, no pvc-10gi. El tamaño cambia con la expansión (05-05); la función no.
4. Pide con holgura pero sin exagerar. En estático te vinculas al menor PV que te sirva; en dinámico creas exactamente lo pedido y podrás expandirlo después, pero nunca reducirlo.

Aplica el PVC y el Deployment definitivo de postgres-reservas del apartado 7 en rutas-norte-dev y demuestra la persistencia en tres niveles crecientes:

1. Inserta tres reservas ficticias y bórralas del pod con kubectl delete pod.
2. Borra el Deployment entero y vuelve a aplicarlo.
3. Borra el PVC (habiendo borrado antes el Deployment) y recupera los datos rescatando el PV.

Documenta en cada paso el estado del PVC y del PV.

Crea estos cuatro PVC en rutas-norte-dev sabiendo que el único PV disponible es pv-postgres-reservas-10gi (10Gi, RWO, clase rutasnorte-rapida, etiqueta tipo-disco: ssd) y que ya está Bound. Para cada uno, predice si quedará Bound o Pending y por qué; después compruébalo.

El equipo quiere que redis-cache conserve su volcado RDB entre reinicios para no perder la caché de disponibilidad de plazas en cada despliegue. Escribe el PVC (redis-cache-datos, 2 GiB) y el fragmento del Deployment que lo monta en /data, con las etiquetas de Rutas Norte.

Después responde, razonando: ¿es una buena decisión? Ten en cuenta lo que se decidió en 03-05 sobre la naturaleza de redis-cache.

Ejercicio 1

Resumen de estados:

Si la política hubiera sido Delete, el cuarto paso habría destruido los datos definitivamente.

Ejercicio 2

Los cuatro quedan Pending, cada uno por una razón distinta, y for x in a b c d; do kubectl describe pvc prueba-$x -n rutas-norte-dev | tail -3; done lo confirma con el mismo evento genérico FailedBinding: no persistent volumes available for this claim and no storage class is set — un recordatorio de que el evento dice que no hay candidato, pero no por qué: eso lo tienes que razonar tú con los cinco criterios.

Para que A se vinculara habría que liberar antes el PV (borrar el PVC de postgres-reservas y limpiar el claimRef), lo que ilustra la limitación central del aprovisionamiento estático que resuelve 05-04.

Ejercicio 3

¿Es una buena decisión? Es aceptable, pero no es prioritaria y tiene contrapartidas. En 03-05 clasificamos redis-cache como Burstable precisamente porque es prescindible: lo que guarda —la disponibilidad de plazas cacheada— se recalcula consultando postgres-reservas. Lo que se pierde al reiniciar no es información, es un rato de latencia mayor.

A favor: tras un despliegue, la caché arranca templada y postgres-reservas no recibe una avalancha de consultas; en un puente, ese pico de recálculo puede ser notable.

En contra, tres cosas: el PVC lo convierte en una carga con estado, con replicas: 1 y Recreate obligatorios; una caché persistida puede servir datos caducos si el RDB es de hace horas y la disponibilidad de plazas ha cambiado, lo que es peor que no tener caché; y si Redis guarda cualquier dato personal de clientes, ese volumen entra en el ámbito de protección de datos y de las copias de seguridad de 05-06.

Decisión de Rutas Norte: no persistir redis-cache. Si el problema real es el pico de consultas tras un despliegue, la solución correcta es un precalentamiento controlado de la caché al arrancar, no conservar datos de disponibilidad potencialmente obsoletos.

La deuda que arrastraba Rutas Norte desde el módulo 2 está saldada. Has escrito el PersistentVolumeClaim —el objeto con namespace que expresa la demanda de la aplicación y la única pieza de almacenamiento que escribe un equipo de aplicación—, lo has vinculado al PV de la lección anterior y has visto la columna CLAIM llenarse por ambos lados con Bound. Y sobre todo has hecho la prueba: tres reservas insertadas, el pod borrado, el Deployment borrado, y las reservas intactas en un pod nuevo con otro nombre y otra IP. Los bytes, verificables en el nodo, viven fuera del contenedor.

Sabes cómo se produce esa vinculación. El algoritmo de emparejamiento exige cinco condiciones —misma clase exacta, capacidad suficiente, modos de acceso del PVC contenidos en los del PV, volumeMode idéntico y selector que case— y, entre los candidatos, elige el menor, de donde sale el comportamiento que sorprende: requests.storage es un mínimo y puedes recibir más espacio del que pediste, sin devolución posible y sin que la cuota lo refleje. Cuando no hay candidato, el PVC queda Pending, y ya no lo diagnosticas a ciegas: kubectl describe pvc y sus eventos distinguen en segundos entre "no hay PV compatible", "la clase no existe", "esperando al primer consumidor" —que no es un error— y "cuota excedida".

Dominas el manifiesto definitivo de la base de datos y las tres trampas que lo rodean: el mountPath correcto (/var/lib/postgresql/data, no un nivel más arriba), el subdirectorio vía PGDATA o subPath que evita el fallo de lost+found, y el fsGroup sin el cual el proceso no root no puede escribir en su propio volumen. Conoces la relación 1:1 entre PVC y PV —un PV vinculado no admite un segundo reclamante aunque le sobre espacio— y la diferencia entre las dos formas de romperse con ReadWriteOnce: en nodos distintos el Multi-Attach error te protege; en el mismo nodo nadie te protege, y por eso replicas: 1 con strategy: Recreate no es una preferencia sino un requisito. Y sabes borrar sin destruir: el finalizador kubernetes.io/pvc-protection deja el PVC en Terminating mientras un pod lo use, se resuelve eliminando al consumidor y jamás forzando el finalizador; y lo que le ocurre después al PV lo decide su política de reclamación, donde Retain te ha permitido recuperar las reservas de un borrado que con Delete habría sido definitivo.

Queda apuntado el techo de esta arquitectura: un Deployment tiene una sola plantilla, así que todas sus réplicas piden el mismo PVC y por tanto no escala; la respuesta es el volumeClaimTemplate de los StatefulSets (06-01). Y queda el otro techo, el que abría esta lección: seguimos creando los PersistentVolumes a mano, uno por uno, con el desperdicio, el trabajo manual y los huérfanos que eso implica. La solución es que el clúster cree el volumen exacto en el momento en que alguien lo pide, y el objeto que lo hace posible es el que llevamos tres lecciones nombrando en storageClassName sin explicar: Clases de Almacenamiento.