Cerrábamos el módulo 4 con una plataforma accesible, cifrada y segmentada, y con una deuda escrita en un comentario del manifiesto desde el módulo 2: postgres-reservas no tiene almacenamiento persistente. Este módulo la salda, y empieza por el principio, que no es el PersistentVolume sino algo más básico: entender por qué el sistema de ficheros de un contenedor desaparece y qué es exactamente un volumen en Kubernetes. Verás que el volumen es una propiedad del pod, no del contenedor, y que esa distinción resuelve el reinicio de un contenedor pero no el reemplazo del pod —justo el problema que arrastra la base de datos—. En esta lección demostrarás la pérdida de datos con tus manos, dominarás la pareja volumes/volumeMounts que rige todos los tipos de volumen del resto del módulo, y trabajarás a fondo los dos tipos que no dependen de ninguna infraestructura externa: emptyDir y hostPath.

1. Por qué el sistema de ficheros de un contenedor es efímero
2. Demostración: perder datos en postgres-reservas
3. Qué es un volumen en Kubernetes
4. La pareja volumes y volumeMounts
5. mountPath, readOnly, subPath y subPathExpr
6. emptyDir en detalle
7. Compartir un emptyDir entre contenedores del mismo pod
8. hostPath: qué es y por qué es peligroso
9. Los volúmenes de configuración: configMap, secret, downwardAPI
10. El volumen projected: todos en un directorio
11. Tabla resumen de tipos de volumen
12. Volúmenes efímeros genéricos: el puente al resto del módulo

Una imagen de contenedor está formada por capas de solo lectura apiladas. Cuando el runtime (containerd en tu minikube) arranca un contenedor a partir de postgres:16.4, no copia esas capas: las monta apiladas mediante un sistema de ficheros de unión (overlayfs) y añade encima una única capa de escritura, vacía y exclusiva de ese contenedor.

Todo lo que el proceso escribe —un fichero nuevo, la modificación de uno existente, los ficheros de datos de PostgreSQL en /var/lib/postgresql/data— va a esa capa de escritura. Y esa capa tiene una propiedad demoledora: su ciclo de vida es exactamente el del contenedor. Cuando el contenedor se destruye, la capa se borra.

Conviene distinguir con precisión dos sucesos que suenan parecidos y no lo son:

Es decir: cualquier reinicio, de la clase que sea, borra lo escrito. Y esto no es un defecto de Kubernetes; es la definición misma de contenedor y la razón de que sean ligeros y reemplazables. El precio es que el estado hay que sacarlo fuera del contenedor de forma explícita, y ese "fuera" es el volumen.

Recordarás de 03-04 que esa capa de escritura consume ephemeral-storage del nodo y que un contenedor que la llena provoca el desalojo del pod. Los volúmenes también son parte de esa contabilidad, como veremos con emptyDir.

Hazlo. Es la práctica que da sentido al módulo entero. Partimos del estado actual: postgres-reservas corriendo como Deployment en rutas-norte-dev, sin volumen alguno. Creamos una reserva real dentro de la base de datos y, además, un fichero testigo cualquiera:

Ahora provocamos lo que en producción provocaría un despliegue, un desalojo o la caída de un nodo:

Se ha perdido todo. El ReplicaSet ha hecho su trabajo a la perfección —hay un pod Running, el Service enruta, la aplicación arranca— y sin embargo el negocio ha perdido todas las reservas. Este es el punto exacto que separa una carga de trabajo sin estado de una con estado: para tienda-web recrear el pod es gratis; para postgres-reservas es una catástrofe.

Un volumen es un directorio, con contenido y respaldo variables según su tipo, que Kubernetes pone a disposición de los contenedores de un pod.

La definición formal importa menos que estas dos afirmaciones, que son las que hay que interiorizar:

1. El volumen se declara en el pod, no en el contenedor. Vive en spec.volumes del pod. Los contenedores solo lo montan en una ruta, mediante spec.containers[].volumeMounts. Por eso dos contenedores del mismo pod pueden ver el mismo volumen en rutas distintas.
2. El ciclo de vida del volumen está ligado al pod, no al contenedor. Un volumen sobrevive al reinicio de un contenedor. Lo que ocurra cuando el pod desaparece depende del tipo de volumen: unos mueren con él (emptyDir) y otros no (los respaldados por un PersistentVolumeClaim).

Esa segunda afirmación explica exactamente hasta dónde llega esta lección. Un emptyDir arregla el caso "el contenedor de PostgreSQL se cayó y el kubelet lo reinició": el nuevo contenedor vuelve a montar el mismo directorio y encuentra sus datos. No arregla el caso "el pod fue reemplazado", que es el que acabas de demostrar. Para eso hacen falta los PersistentVolumes de 05-02.

Todo volumen requiere dos declaraciones que se enlazan por el nombre. Es el patrón más repetido de Kubernetes y no cambia sea cual sea el tipo:

Los dos bloques, con precisión:

• spec.volumes (nivel de pod): una lista de volúmenes. Cada elemento tiene un name único dentro del pod y exactamente una clave de tipo (emptyDir, hostPath, configMap, secret, persistentVolumeClaim, projected, ephemeral...). Declarar un volumen que ningún contenedor monta es legal pero inútil; para algunos tipos (como configMap) implica de todos modos que el pod no arrancará si el objeto referenciado no existe.
• spec.containers[].volumeMounts (nivel de contenedor): dónde se ve ese volumen dentro de ese contenedor concreto. El name es la referencia cruzada.

Si el name no casa, el error es inmediato y explícito al crear el pod:

Los initContainers también pueden montar volúmenes, y es precisamente el mecanismo que hace útil el patrón de inicialización que se estudia en 06-04: un init container prepara ficheros en un volumen y el contenedor principal los encuentra ya listos.

Los campos de volumeMounts merecen detalle porque cada uno resuelve un problema real.

Este es el efecto que más sorprende al principio. Si montas un volumen en /etc/nginx/conf.d de la imagen de tienda-web, todo lo que la imagen traía en ese directorio deja de verse, igual que al montar un disco sobre un directorio en Linux. No se borra: queda tapado. Por eso montar sobre /etc o /usr rompe el contenedor.

Ya lo usaste en 03-01 para inyectar un único fichero de configuración sin tapar el directorio entero. La misma técnica sirve para los volúmenes de datos:

En el caso de PostgreSQL hay una razón operativa concreta para hacerlo, que se explica en detalle en 05-03: muchos volúmenes de bloque formateados traen un directorio lost+found en su raíz, y PostgreSQL se niega a inicializar un directorio de datos que no esté vacío. En Rutas Norte lo resolvimos ya en el módulo 3 por la vía equivalente de la variable PGDATA, y en 05-03 unificaremos ambos enfoques.

subPathExpr expande variables de entorno del contenedor, incluidas las de la Downward API de 03-03. El caso canónico es que cada réplica escriba en su propio subdirectorio de un volumen compartido:

Cada pod de worker-notificaciones escribe sus registros en un subdirectorio con su propio nombre, y no se pisan entre sí.

emptyDir es el tipo de volumen más simple y el más usado con diferencia.

Cuándo se crea: en el momento en que el pod se asigna a un nodo. Empieza siempre vacío, de ahí el nombre.

Cuándo se borra: cuando el pod se elimina del nodo, de forma definitiva e irrecuperable. Que quede muy claro qué lo sobrevive y qué no:

Dónde vive: por defecto, en el disco del nodo, bajo /var/lib/kubelet/pods/<uid>/volumes/kubernetes.io~empty-dir/. Puedes verlo en minikube:

Sin límite, un emptyDir puede llenar el disco del nodo y provocar DiskPressure, con el desalojo de pods ajenos que estudiaste en 03-04. Se acota con sizeLimit:

Cuando se supera el límite, el kubelet desaloja el pod (no devuelve un error de escritura al proceso). El evento lo dice sin rodeos:

Con medium: Memory, el volumen se respalda en un tmpfs: RAM, no disco. Es rapidísimo y el contenido nunca toca un disco, lo que lo hace idóneo para material sensible —es exactamente lo que Kubernetes hace por debajo con los volúmenes de secret, como viste en 03-02—. Se declara con emptyDir: { medium: Memory, sizeLimit: 64Mi }.

El aviso importante: lo que escribas ahí cuenta contra el limit de memoria del contenedor que lo usa. Si tienda-web tiene limits.memory: 256Mi y llenas 200 MiB de tmpfs, al proceso le quedan 56 MiB y acabará OOMKilled sin que ningún gráfico de "memoria del proceso" lo explique. Regla: si usas medium: Memory, súmalo al limit de memoria y pon siempre sizeLimit. Sin sizeLimit, el tmpfs puede crecer hasta la mitad de la RAM del nodo.

Este es el caso de uso que justifica por sí solo la existencia de emptyDir, y encaja con lo que aprendiste en 02-01: los contenedores de un pod comparten red y pueden compartir volúmenes, pero no su sistema de ficheros.

En Rutas Norte, tienda-web renderiza plantillas HTML de horarios y trayectos. Añadimos un contenedor secundario que las genera cada cinco minutos a partir de la API y las deja en un directorio; nginx simplemente las sirve. Ambos ven el mismo emptyDir, y nginx lo monta en solo lectura.

Los puntos de diseño que hay que saber leer en ese manifiesto:

• Un solo volumen, dos mountPath distintos. El generador escribe en /salida; nginx lee en /usr/share/nginx/html/horarios. Es el mismo directorio del nodo.
• readOnly: true en el consumidor. Si mañana una vulnerabilidad permite escribir a través de nginx, el atacante no puede alterar las plantillas que sirve. Cuesta una línea.
• medium: Memory con sizeLimit: 64Mi, y el limits.memory de nginx elevado a 192Mi para absorberlo. Sin ese ajuste, un pico de plantillas mataría el contenedor con OOMKilled.
• No es persistencia. Si el pod muere, la caché se pierde y el generador la rehace en el arranque siguiente. Ese es exactamente el criterio para elegir emptyDir: datos reconstruibles.

Verificación, incluida la prueba de que readOnly funciona:

hostPath monta un fichero o directorio del sistema de ficheros del nodo dentro del pod.

El campo type valida qué se espera encontrar en esa ruta, y es la diferencia entre un fallo claro y un comportamiento silencioso e inesperado:

Usos legítimos, todos ellos de componentes de infraestructura, no de aplicaciones:

• Un agente de recogida de logs que lee /var/log/pods de cada nodo (el patrón DaemonSet de 06-02 y de la pila EFK de 07-05).
• Un exportador de métricas del nodo que lee /proc y /sys.
• Un plugin CSI que necesita acceder al directorio de montaje del kubelet.

hostPath rompe el aislamiento entre el pod y el nodo. Las consecuencias son de gravedad máxima:

1. Escalada a root en el nodo. Un pod que monta / o /etc con escritura puede añadir una clave SSH en /root/.ssh/authorized_keys, o dejar un manifiesto en /etc/kubernetes/manifests/ que el kubelet arrancará como pod estático con todos los privilegios. Eso es control total del nodo.
2. Acceso a los secretos de los demás pods. Bajo /var/lib/kubelet/pods/ están montados los volúmenes de todos los pods de ese nodo, incluidos los Secrets con las credenciales de postgres-reservas.
3. Fuga del runtime. Montar /var/run/containerd/containerd.sock (o el socket de Docker) permite crear contenedores privilegiados sin pasar por la API de Kubernetes ni por RBAC.
4. Datos que no viajan. Aunque no hubiera riesgo de seguridad, un hostPath está atado a un nodo concreto: si el pod se reprograma en otro, encuentra un directorio distinto (o vacío) y los datos "desaparecen" sin ningún error.

Por eso hostPath no es una solución de persistencia para postgres-reservas, aunque a primera vista lo parezca. Y por eso los Pod Security Standards en su nivel baseline prohíben hostPath por completo; lo verás aplicado en 08-03, y el endurecimiento del contenedor que lo acompaña en 08-02.

Regla de Rutas Norte: ningún manifiesto de aplicación usa hostPath. Si aparece uno en una revisión de código, se rechaza sin discusión. La necesidad legítima —persistencia real— se cubre con PVC.

Ya has usado los tres en el módulo 3; los recolocamos aquí porque son volúmenes, con la misma mecánica volumes/volumeMounts, y conviene verlos en la misma familia.

Dos recordatorios que se olvidan a menudo:

• La actualización automática del contenido no reinicia el proceso. Por eso en 03-03 añadimos una anotación con el hash de la configuración al pod, para forzar un rollout cuando cambia.
• Un montaje con subPath queda congelado: recibe el contenido del momento del montaje y nunca se actualiza. Es la contrapartida de poder montar un único fichero.

projected combina varias fuentes —configMap, secret, downwardAPI y serviceAccountToken— en un único directorio. Sirve para no llenar el contenedor de puntos de montaje y, sobre todo, para pedir tokens de ServiceAccount con audiencia y caducidad controladas, como viste en 03-06.

Montado en /etc/rutasnorte, el contenedor ve un solo árbol: app/application.yaml, db/password y token.

Restricciones a recordar: dentro de un projected no caben persistentVolumeClaim ni emptyDir (solo las cuatro fuentes citadas), y no se puede repetir el mismo path en dos fuentes: el pod se rechaza por conflicto.

Los tipos que se usan hoy en un clúster 1.30+, con su ciclo de vida y su caso de uso. Los tipos "in-tree" de proveedores concretos (awsElasticBlockStore, gcePersistentDisk, azureDisk...) están eliminados o migrados a CSI; no los escribas en manifiestos nuevos.

Queda un tipo que hace de bisagra entre esta lección y las siguientes: el volumen efímero genérico. Es un volumen que se aprovisiona como un PVC —con toda la potencia del almacenamiento real: la clase que quieras, el tamaño que quieras, expansión, snapshots— pero cuyo ciclo de vida es el del pod: al borrarse el pod, el PVC creado automáticamente se borra con él.

Es lo que hay que usar cuando necesitas mucho espacio temporal —más del que cabe razonablemente en el disco del nodo— sin querer conservarlo: la generación de un informe voluminoso, un procesamiento por lotes, una descarga grande. En Rutas Norte encajará con informes-ocupacion cuando llegue en 06-03.

La comparación cierra el mapa mental de la lección:

Y con eso queda planteado lo que falta: para postgres-reservas necesitamos la tercera columna. Esa columna la construyen las cinco lecciones restantes del módulo.

Cuatro consejos que ahorran horas:

1. Antes de escribir un volumen, responde: ¿qué pasa si esto se pierde? Si la respuesta es "se regenera", emptyDir. Si es "perdemos datos del negocio", PVC. No hay término medio.
2. Inspecciona los volúmenes efectivos de un pod en marcha, que no siempre son los que creías, con kubectl exec ... -- df -h y kubectl exec ... -- mount | grep -E "tmpfs|overlay".
3. kubectl describe pod muestra la sección Volumes: y Mounts: de cada contenedor: es el sitio más rápido para verificar que el montaje es el que pretendías y si es ro o rw.
4. kubectl explain pod.spec.volumes lista todos los tipos disponibles en tu versión del clúster, que es la fuente de verdad frente a cualquier documentación desactualizada.

En rutas-norte-dev, crea un pod prueba-efimero con la imagen busybox:1.36 y dos volúmenes: uno emptyDir normal montado en /persiste-reinicio y otro emptyDir con medium: Memory y sizeLimit: 32Mi montado en /en-ram. Escribe un fichero en cada uno. Después:

1. Mata el proceso principal del contenedor para forzar un reinicio y comprueba qué sobrevive.
2. Borra el pod, recréalo y comprueba qué sobrevive.
3. Verifica con mount cuál de los dos está en tmpfs.
4. Intenta escribir 50 MiB en /en-ram y describe qué ocurre.

Escribe k8s/base/tienda-web-cache.yaml: un Deployment de tienda-web en rutas-norte-dev con dos contenedores que compartan un emptyDir llamado cache-plantillas:

• nginx (imagen nginx:1.27.1) que lo monta en /usr/share/nginx/html/horarios en solo lectura.
• generador-plantillas (usa busybox:1.36 con un bucle que escriba la hora en un fichero HTML cada 30 segundos) que lo monta en /salida en escritura.

Etiquetas y resources según las convenciones del curso. Demuestra que nginx ve lo que escribe el generador y que no puede escribir él.

Un compañero envía este manifiesto para dar persistencia a postgres-reservas en el clúster de preproducción. Encuentra cuatro problemas distintos y explica la consecuencia de cada uno.

Ejercicio 1

Ambos sobreviven: el volumen está ligado al pod, no al contenedor. Incluso el de RAM, porque el tmpfs pertenece al pod.

Los dos directorios quedan vacíos: es exactamente lo que le pasa hoy a postgres-reservas. Y con medium: Memory el sizeLimit es el tamaño real del tmpfs, así que el fallo es inmediato y dentro del contenedor. En un emptyDir de disco el comportamiento es distinto: la escritura tiene éxito y es el kubelet quien, al detectar el exceso, desaloja el pod con el evento Usage of EmptyDir volume ... exceeds the limit. Compruébalo con kubectl get events -n rutas-norte-dev --sort-by=.lastTimestamp.

Ejercicio 2

Ejercicio 3

Los cuatro problemas:

La corrección no es retocar este manifiesto sino cambiar de mecanismo: un PersistentVolumeClaim, que es lo que construyen las siguientes lecciones.

Has demostrado con tus manos el problema que da nombre al módulo: creaste una reserva en postgres-reservas, borraste el pod y la reserva desapareció. La causa no es un fallo: es la capa de escritura de overlayfs, que nace vacía con cada contenedor y muere con él. De ahí sale la regla que gobierna todo lo demás: en Kubernetes el estado hay que sacarlo del contenedor de forma explícita.

Ese "fuera" es el volumen, y ahora sabes leerlo con precisión. Se declara en el pod (spec.volumes), no en el contenedor; los contenedores solo lo montan (volumeMounts), y ambos bloques se enlazan por el name. Dominas los campos del montaje: mountPath, que oculta lo que hubiera en esa ruta; readOnly, que deberías poner por defecto en todo consumidor; subPath, para montar un único fichero al precio de congelar su contenido; y subPathExpr, para dar a cada réplica su propio subdirectorio.

Conoces a fondo los dos tipos que no dependen de infraestructura externa. emptyDir nace vacío al asignarse el pod a un nodo y muere con el pod: sobrevive al reinicio de un contenedor pero no a su reemplazo; se acota con sizeLimit para no provocar DiskPressure, y con medium: Memory vive en RAM —rápido y sin tocar disco, pero contando contra el limit de memoria del contenedor—. Lo has puesto a trabajar en el caso que le corresponde: la caché de plantillas que comparten nginx y el generador dentro del pod de tienda-web, con el consumidor en solo lectura y datos reconstruibles. Y hostPath, con sus type y con su veredicto claro: legítimo solo para infraestructura, prohibido en aplicaciones, porque rompe el aislamiento con el nodo —escalada a root, acceso a los secretos de los demás pods, fuga por el socket del runtime— y porque ata los datos a una máquina concreta. Has recolocado además los volúmenes de configuración que ya usabas —configMap, secret, downwardAPI— y el projected que los reúne en un solo directorio, y tienes la tabla de todos los tipos con su ciclo de vida.

Lo que no has resuelto es precisamente lo que abría la lección: ningún volumen de los vistos sobrevive al reemplazo del pod. La bisagra la dejamos apuntada con el volumen efímero genérico (ephemeral.volumeClaimTemplate), que ya se aprovisiona como almacenamiento de verdad aunque siga muriendo con el pod. Falta cortar el último hilo: desacoplar la vida del disco de la vida del pod. Eso exige un objeto nuevo, con existencia propia en el clúster, administrado por quien gestiona la infraestructura y consumido por quien despliega la aplicación. Es el PersistentVolume, y es la siguiente lección: Volúmenes Persistentes.