La lección anterior terminó con un PersistentVolume que apareció solo, y con una caja negra sin abrir: dijimos "el aprovisionador crea el volumen" sin explicar quién es ese aprovisionador, cómo se entera de que hay un PVC pendiente, cómo conecta el disco a un nodo y cómo acaba montado en el contenedor. Esa maquinaria se llama CSI, la Container Storage Interface, y entenderla es lo que separa a quien aplica manifiestos de quien puede diagnosticar por qué un pod lleva veinte minutos en ContainerCreating. Además, la StorageClass anunciaba dos capacidades que aún no hemos usado: la expansión de un volumen en marcha y los snapshots, imprescindibles antes de tocar el esquema de una base de datos en producción. En esta lección las pondrás a trabajar sobre postgres-reservas, y cerrarás con la advertencia que más incidentes evita: un snapshot no es una copia de seguridad.

1. Qué problema resolvió CSI
2. La arquitectura: plugin de controlador y plugin de nodo
3. Los sidecars y los objetos CSIDriver y CSINode
4. El flujo completo de un volumen, de extremo a extremo
5. Preparar el clúster de prácticas
6. Expansión de volúmenes: requisitos y mecánica
7. Expansión en línea frente a expansión con reinicio
8. Snapshots: los tres objetos
9. Crear un snapshot de postgres-reservas
10. Restaurar desde un snapshot con dataSource
11. Clonar un PVC
12. La advertencia: consistencia y qué NO es un snapshot

Antes de 2018, el código que hablaba con AWS EBS, con Google Persistent Disk, con Ceph o con NetApp vivía dentro del repositorio de Kubernetes. Se les llamaba controladores in-tree, y el modelo tenía tres problemas graves:

CSI (Container Storage Interface) es una especificación estándar —no exclusiva de Kubernetes: la usan también Mesos y Nomad— que define un contrato gRPC entre el orquestador y el sistema de almacenamiento. El proveedor implementa ese contrato en un componente propio, lo empaqueta como contenedor y lo despliega en el clúster, como cualquier otra carga de trabajo. El resultado: los controladores in-tree quedaron obsoletos y fueron eliminados (kubernetes.io/aws-ebs, kubernetes.io/gce-pd, kubernetes.io/azure-disk ya no existen en 1.30+). Hoy todo el almacenamiento de red pasa por CSI, y hay más de un centenar de drivers disponibles.

Un driver CSI se despliega siempre en dos mitades, porque las operaciones de almacenamiento son de dos naturalezas distintas:

La separación no es caprichosa: crear un disco es una llamada a una API remota que solo debe hacerse una vez desde un sitio; montarlo es una operación local que solo puede hacer la máquina donde está el pod.

Aquí está la parte elegante del diseño. El driver del proveedor no habla con la API de Kubernetes: solo implementa el contrato gRPC de CSI. Quien observa la API y traduce son unos contenedores auxiliares mantenidos por el proyecto Kubernetes, los sidecars, que se despliegan junto al driver en el mismo pod (el patrón multi-contenedor de 06-04).

Hay además un livenessprobe que sondea la salud del driver. Gracias a este diseño, un fabricante solo escribe la lógica de su almacenamiento; toda la integración con Kubernetes ya está hecha y probada. Y hay dos objetos de la API que describen el estado de esta infraestructura:

Declara las capacidades de un driver instalado. El clúster lo consulta para saber qué puede pedirle.

Se crea automáticamente por cada nodo y registra qué drivers hay disponibles allí y con qué identificador conoce el proveedor a esa máquina.

Ese Count es una limitación muy real en producción: AWS, por ejemplo, restringe el número de volúmenes EBS conectables a una instancia. Cuando se agota, los pods se quedan Pending con node(s) exceed max volume count, un mensaje que ahora sabes de dónde sale.

Este es el diagrama que hay que retener: qué ocurre exactamente desde que aplicas un PVC hasta que el proceso escribe su primer byte.

Las cinco fases, con su nombre técnico y el síntoma de cuando fallan:

Dos detalles que valen oro en un diagnóstico. NodeStageVolume ocurre una vez por nodo; NodePublishVolume, una vez por pod, y por eso un volumen puede estar "montado" y aun así el pod no verlo: son dos montajes distintos. Y puedes seguir la fase de conexión en la API con kubectl get volumeattachments, algo que rara vez se sabe: muestra una fila por volumen conectado, con el driver, el PV, el nodo y una columna ATTACHED; si esa columna es false durante minutos, el problema está en el plugin de controlador, no en el nodo.

El provisioner de minikube (k8s.io/minikube-hostpath) no admite expansión ni snapshots, así que para esta lección instalaremos el driver CSI de hostpath, que sí las implementa. Es un driver de referencia para pruebas —no lo uses en producción— pero reproduce fielmente el comportamiento de un CSI real.

Punto importante: los CRDs de snapshot y el snapshot-controller no forman parte de Kubernetes. En un clúster gestionado suelen venir instalados, pero en uno propio hay que ponerlos. Si intentas crear un VolumeSnapshot sin ellos, el error es no matches for kind "VolumeSnapshot" in version "snapshot.storage.k8s.io/v1".

Ahora reescribimos rutasnorte-rapida sobre este driver —hay que borrarla y recrearla, porque las StorageClass no se editan—, manteniendo el contrato (nombre y Retain) y ganando las dos capacidades:

Llega el día en que 10 GiB se quedan cortos: la tabla de reservas ocupa 8,4 GiB y el disco va camino de llenarse en dos semanas. La expansión permite agrandar el volumen sin migrar los datos.

Los requisitos, los tres a la vez: la StorageClass debe tener allowVolumeExpansion: true, el driver CSI debe implementar la capacidad (ControllerExpandVolume) y el PVC debe estar Bound.

Y la restricción absoluta: un volumen no se puede reducir. Ni con un PVC nuevo, ni con kubectl edit, ni de ninguna manera; Kubernetes rechaza la petición con spec.resources.requests.storage: Forbidden: field can not be less than previous value.

La razón es de seguridad de datos: reducir un sistema de ficheros exige moverlo y compactarlo, y ningún proveedor garantiza hacerlo sin riesgo. Consecuencia práctica: pide con cabeza, porque solo puedes subir. Reducir significa crear un PVC menor y copiar, con parada, como en 05-04.

Se edita spec.resources.requests.storage del PVC —nunca del PV—. La vía rápida es un patch; la buena, editar el manifiesto en Git y aplicarlo, como manda el modelo declarativo de 01-06:

Y la comprobación que de verdad importa, dentro del contenedor:

20 GiB, con los 8,4 GiB de datos intactos y sin haber parado la base de datos.

La expansión ocurre en dos etapas, y de ahí las dos condiciones que verás en el PVC:

Si el PVC se queda con la condición FileSystemResizePending, el disco ya es mayor pero el sistema de ficheros no lo sabe: df -h dentro del contenedor sigue mostrando el tamaño antiguo. La solución es recrear el pod, y el kubelet ejecuta NodeExpandVolume durante el montaje:

Dos avisos operativos. Primero, subPath puede impedir la expansión automática del sistema de ficheros en algunos drivers: es la razón, anunciada en 05-03, por la que en postgres-reservas preferimos la variable PGDATA al subPath. Y segundo, vigila el llenado antes de que sea urgente: Kubernetes expone kubelet_volume_stats_available_bytes y kubelet_volume_stats_capacity_bytes, y una alerta al 75 % da margen de sobra (07-03 y 07-04).

Un snapshot es una copia puntual del contenido de un volumen, hecha por el sistema de almacenamiento. Su gran virtud es que es casi instantánea —los sistemas modernos usan copia sobre escritura, así que no duplican los datos al crearla— y que permite crear volúmenes nuevos a partir de ella. El modelo de objetos es un calco exacto del de los volúmenes, lo que hace que ya te lo sepas:

Y la VolumeSnapshotClass, análoga a la StorageClass:

deletionPolicy decide qué ocurre con el snapshot real al borrar el objeto VolumeSnapshot: Delete lo destruye; Retain lo conserva, y es la elección coherente con rutasnorte-rapida para los snapshots de la base de datos.

Requisitos previos, que ya cubriste en el apartado 5: los tres CRDs, el snapshot-controller y el sidecar external-snapshotter junto al driver.

El escenario real: mañana se despliega la versión 3.0 de api-reservas, que incluye una migración de esquema —añade columnas a reservas y reescribe la tabla de clientes—. Si la migración sale mal, hay que volver atrás en minutos, y un rollout undo del Deployment (02-04) no deshace los cambios en la base de datos. Un snapshot previo sí.

Estado de partida: tres reservas en la tabla, según kubectl exec ... psql -c "SELECT count(*) FROM reservas;". El manifiesto del snapshot:

READYTOUSE: true es la columna que hay que mirar: hasta que no lo sea, el snapshot no sirve para restaurar. El describe amplía con el Bound Volume Snapshot Content Name, la Creation Time, el Restore Size y los eventos CreatingSnapshot y SnapshotCreated del snapshot-controller.

Las anotaciones con el motivo, el responsable y el ticket no son adorno: un clúster acumula snapshots, cada uno cuesta dinero, y sin esa información nadie se atreve a borrar ninguno. Es la aplicación directa de lo aprendido en 02-07.

Ahora simulamos el desastre. La migración se ejecuta y va mal: borra reservas.

La restauración no sobrescribe el volumen original: crea un PVC nuevo cuyo dataSource apunta al snapshot. Es una diferencia crucial, porque conserva la evidencia del estado dañado para poder analizarlo después.

Al aplicarlo aparece un segundo PVC Bound junto al original, con su propio PV. Y apuntamos el Deployment al volumen restaurado:

Las tres reservas están de vuelta. Cuatro condiciones para que una restauración funcione:

1. El PVC nuevo debe pedir al menos el restoreSize del snapshot. Menos, y falla.
2. Debe usar la misma StorageClass (o al menos el mismo driver): un snapshot no cruza sistemas de almacenamiento.
3. El snapshot debe estar READYTOUSE: true.
4. El snapshot debe existir en el mismo namespace que el PVC nuevo. Para cruzar namespaces hay que importar el VolumeSnapshotContent a mano.

Un caso hermano y muy útil: crear una copia de un volumen directamente desde otro PVC, sin pasar por un snapshot. Cambia solo el kind del dataSource:

El clonado es la forma limpia de dar al equipo de desarrollo una copia de los datos de preproducción para ensayar una migración. Y ojo con la letra pequeña: ese clon contiene datos personales reales de clientes —nombre, DNI, teléfono, correo—. Un clon para pruebas es un tratamiento de datos igual que el original y exige las mismas protecciones, o mejor, una anonimización previa. Se retoma en 05-06.

Una limitación técnica que conviene saber: clonar un PVC mientras la base de datos está escribiendo produce una copia equivalente a la de un corte de luz, con los mismos problemas de consistencia del apartado siguiente.

Esta es la advertencia central de la lección. Un snapshot fotografía los bloques del disco, no el estado lógico de la aplicación. Y una base de datos en marcha tiene, en cualquier instante, páginas modificadas en memoria que aún no se han escrito al disco, transacciones a medio confirmar, y escrituras en el WAL que el sistema operativo tiene en su caché y no ha volcado.

El snapshot resultante equivale a el estado del disco tras un corte de corriente. La buena noticia es que PostgreSQL está preparado para eso: al arrancar sobre ese volumen ejecuta una recuperación por WAL y llega a un estado coherente. La mala es doble: esa recuperación puede tardar minutos en una base grande, y perderás las transacciones que no llegaron al disco. Y con motores menos robustos, o con datos repartidos entre varios volúmenes que se fotografían por separado, el resultado puede ser directamente inservible. La solución profesional es coordinar el snapshot con la aplicación: dejarla en un estado consistente justo antes, y liberarla justo después.

Kubernetes ofrece el mecanismo para lo tercero: los hooks de pre y post que ejecutan un comando dentro del contenedor antes y después del snapshot. No es una capacidad nativa del VolumeSnapshot, sino de las herramientas de copia de seguridad, y por eso se estudia en la lección siguiente, 05-06, con Velero.

Es la afirmación más importante del módulo y el error conceptual que más datos ha destruido:

Si se borra la cuenta de la nube, si la zona se pierde, si alguien con credenciales de administrador destruye el proyecto, los snapshots se van con todo lo demás. Son una herramienta magnífica para lo que son —deshacer un cambio local, rápido, en minutos—, pero no son una estrategia de recuperación ante desastres. Regla de Rutas Norte: los snapshots son la red de seguridad de corto plazo —antes de una migración, de un despliegue arriesgado, de tocar producción—, con retención de días; la copia de seguridad de verdad va a un almacén de objetos externo y es lo que se construye en la lección siguiente.

Consejos:

1. Antes de cualquier cambio irreversible —migración de esquema, actualización mayor del motor, script de limpieza— haz un snapshot y anótalo con el ticket. Cuesta segundos y ha salvado carreras.
2. Verifica que un snapshot sirve, no que existe. Un snapshot no probado no es nada. Restaura periódicamente en un PVC de prueba y comprueba las filas.
3. Vigila el llenado con antelación con un df -h sobre el punto de montaje, y automatízalo con alertas al 75 % en 07-04.
4. Diagnostica el almacenamiento por fases. Si un pod no arranca por el volumen, mira en este orden: kubectl describe pvc (provisión), kubectl get volumeattachments (conexión), kubectl describe pod (montaje) y los registros del pod del driver CSI en kube-system.

Con el driver CSI de hostpath instalado y rutasnorte-rapida recreada con allowVolumeExpansion: true:

1. Comprueba el tamaño actual del volumen de postgres-reservas desde dentro del contenedor.
2. Amplíalo de 10 GiB a 20 GiB editando el PVC.
3. Sigue las condiciones del PVC hasta que termine y verifica el tamaño con df -h.
4. Intenta reducirlo a 5 GiB y transcribe el error.
5. Comprueba que las reservas siguen ahí.

Ensaya el procedimiento completo que usarás en producción:

1. Inserta cinco reservas ficticias en postgres-reservas.
2. Crea un VolumeSnapshot llamado snap-practica con las anotaciones de motivo, responsable y ticket. Espera a READYTOUSE: true.
3. Provoca el desastre: DROP TABLE reservas.
4. Crea un PVC restaurado con dataSource y apunta el Deployment a él.
5. Verifica que las cinco reservas han vuelto.
6. Mide el tiempo total desde el paso 3 hasta el 5 y anótalo: es tu RTO real para este tipo de incidente.

Responde de forma razonada, en forma de tabla de decisión que puedas presentar al equipo:

• A. ¿Qué volúmenes de Rutas Norte merecen snapshots automáticos y cuáles no? Justifica cada componente.
• B. ¿Con qué frecuencia y con qué retención? Ten en cuenta que en un puente se venden unas 400 reservas por hora y que un snapshot de 20 GiB cuesta dinero cada mes.
• C. ¿Por qué los snapshots no bastan como estrategia de protección de datos de Rutas Norte? Enumera tres escenarios concretos en los que no salvarían la situación.

Ejercicio 1

El df -h final debe decir 20G con solo un 1 % usado. Si status.conditions muestra FileSystemResizePending=True, falta la segunda etapa: un kubectl rollout restart deploy/postgres-reservas y ya lo dirá.

La expansión no toca los datos: solo agranda el dispositivo y extiende el sistema de ficheros sobre el espacio nuevo.

Ejercicio 2

Ese número —del orden de uno a tres minutos en un clúster local, y de cinco a quince en producción con volúmenes grandes— es tu RTO para este tipo de incidente. Anótalo: es el dato que hay que llevar a la conversación sobre objetivos de recuperación de 05-06. Y fíjate en que el volumen original sigue ahí, con la tabla borrada, disponible para investigar qué pasó.

Ejercicio 3

A. Qué merece snapshots:

B. Frecuencia y retención:

La aritmética que justifica el punto tres: con snapshot diario, el RPO es de 24 h y en un puente eso son unas 9.600 reservas perdidas. Con snapshot cada 4 h, el RPO baja a 4 h, es decir, unas 1.600. Y con el WAL archivado de forma continua bajaría a minutos, que es la solución de verdad y se comenta en 05-06. El RPO es una decisión de negocio, no técnica: alguien tiene que decidir cuántas reservas es aceptable perder.

C. Tres escenarios en los que los snapshots no salvan la situación:

1. Pérdida del sistema de almacenamiento o de la zona. Los snapshots viven en la misma cabina o región que los volúmenes originales. Si desaparece, desaparecen con ella. Una copia de seguridad en un almacén de objetos de otra región sí sobrevive.
2. Borrado de la cuenta o el proyecto de la nube, accidental o malicioso. Un administrador comprometido, o un error de facturación que suspende la cuenta, se lleva volúmenes y snapshots por igual. La protección es una copia en otra cuenta, con credenciales distintas e inmutabilidad activada.
3. Corrupción lógica no detectada a tiempo. Un error de la aplicación que corrompe registros poco a poco durante tres semanas hace inútiles los snapshots de 7 días: todos contienen ya la corrupción. Hacen falta copias con retención larga —mensuales, anuales— y, sobre todo, volcados lógicos verificables: un pg_dump que se restaura correctamente demuestra que los datos son coherentes, cosa que un snapshot de bloques no demuestra. Un cuarto escenario que conviene mencionar: migrar a otro proveedor o restaurar en otro clúster; un snapshot de EBS no se restaura en GKE, un volcado lógico sí.

Has abierto la caja negra. Sabes que CSI existe porque tener el código de cada fabricante dentro de Kubernetes era insostenible, y que su arquitectura son dos mitades: un plugin de controlador, desplegado como Deployment, que habla con la API del proveedor y crea, conecta y fotografía volúmenes; y un plugin de nodo, desplegado como DaemonSet, que formatea y monta en cada máquina. Entre el driver y la API de Kubernetes se interponen los sidecars —external-provisioner, external-attacher, external-resizer, external-snapshotter, node-driver-registrar—, que traducen objetos de la API en llamadas gRPC y permiten que un fabricante solo escriba la lógica de su almacenamiento. Y conoces los objetos que describen esa infraestructura: CSIDriver, con las capacidades declaradas, y CSINode, con los drivers de cada nodo y ese Count que explica el exceed max volume count. Sobre todo, tienes el flujo completo en la cabeza —Provision, Attach, NodeStage, NodePublish— y sabes qué síntoma produce cada fase al fallar, incluido el kubectl get volumeattachments que casi nadie usa y que distingue en un segundo un problema de controlador de uno de nodo.

Has expandido en caliente el volumen de postgres-reservas de 10 a 20 GiB, con la base de datos en marcha y sin tocar un solo dato. Conoces los tres requisitos —allowVolumeExpansion, soporte del driver y PVC Bound—, que la petición se hace siempre en el PVC y nunca en el PV, y las dos etapas del proceso: la del disco real y la del sistema de ficheros, con la condición FileSystemResizePending que delata cuándo hace falta recrear el pod para que df -h diga la verdad. Y tienes grabada la restricción: no se puede reducir, así que la talla se piensa antes.

Y dominas los snapshots, con su modelo de objetos calcado del de los volúmenes —VolumeSnapshotClass, VolumeSnapshot, VolumeSnapshotContent, exactamente el papel de StorageClass, PVC y PV—, sus requisitos previos que no vienen con Kubernetes (los CRDs y el snapshot-controller), y el flujo de trabajo real: snapshot anotado con motivo, responsable y ticket antes de una migración de esquema; desastre; y restauración creando un PVC nuevo con dataSource, que no sobrescribe el original y conserva la evidencia. Sabes clonar un PVC en caliente cambiando el kind del dataSource, y que ese clon de producción lleva datos personales reales y merece el mismo cuidado que el original.

Y te llevas las dos advertencias que dan sentido a la lección siguiente. La primera: un snapshot de un disco con una base de datos en marcha es crash-consistent, equivalente al estado tras un corte de luz; PostgreSQL se recupera por WAL, pero tarda y puede perder lo no volcado, y el remedio es coordinar la aplicación con hooks antes y después. La segunda, la más importante del módulo: un snapshot no es una copia de seguridad. Vive en el mismo sistema de almacenamiento que el original, así que no sobrevive a la pérdida de la zona, ni al borrado de la cuenta, ni a una corrupción lógica descubierta tres semanas tarde, ni sirve para restaurar en otro clúster. Es una red de seguridad de corto plazo, excelente para lo que es.

Falta, por tanto, lo que de verdad protege a Rutas Norte: sacar los datos del clúster, ponerlos en un almacén independiente, incluir también los objetos de la API, coordinar la base de datos para que la copia sea consistente, definir retención y —esto es innegociable— probar la restauración. Eso es Copias de Seguridad y Restauración de Datos, la lección que cierra el módulo.