En la lección anterior llevamos tienda-web y api-reservas a producción. Fueron trece objetos y una lista de comprobaciones larga, pero el margen de error era generoso: si un pod se pierde, nace otro idéntico y nadie se entera. Aquí desaparece esa red de seguridad. postgres-reservas contiene los datos personales de los clientes de Rutas Norte, sus reservas y sus pagos. Un pod perdido puede significar minutos de servicio caído; un volumen perdido, un problema de existencia para la empresa.

Esta lección resuelve el escenario completo de una carga con estado en producción: desde la pregunta incómoda de si esa base de datos debería estar en Kubernetes, hasta el procedimiento de restauración cronometrado, pasando por la conmutación por error, la actualización de versión mayor y el caso muy distinto de redis-cache, donde perder el dato es aceptable.

Advertencia de cumplimiento normativo. Todo lo que se describe aquí afecta a datos personales de clientes (nombre, correo, historial de viajes, datos de pago tokenizados) y a la continuidad del negocio. Las decisiones sobre ubicación de las copias de seguridad, plazos de retención, cifrado, acceso del personal a los datos y transferencias entre regiones deben ser revisadas y aprobadas por el responsable de cumplimiento normativo de la organización antes de aplicarse. Los valores de este material son ilustrativos y no sustituyen esa revisión.

1. La pregunta previa: ¿debe la base de datos vivir en Kubernetes?
2. Qué tiene de especial una carga con estado
3. postgres-reservas con CloudNativePG
4. Cómo se conecta api-reservas: el agrupador de conexiones
5. Conmutación por error: simularla y medirla
6. Copias de seguridad y recuperación a un instante concreto
7. Actualización de versión mayor de PostgreSQL
8. Réplicas de lectura para informes-ocupacion
9. redis-cache: cuando perder el dato es aceptable
10. Lista de comprobación de una carga con estado en producción

Es tentador responder "sí" por coherencia: si todo lo demás está en el clúster, la base de datos también. Es una mala razón. La pregunta correcta es qué opción minimiza el riesgo total al coste que la empresa puede asumir.

Hay tres opciones reales.

El criterio de decisión, en una frase: usa la base de datos gestionada salvo que tengas una razón concreta para no hacerlo, y no montes nunca un StatefulSet artesanal para una base de datos de producción.

Razones concretas que justifican el operador dentro del clúster:

• La factura de la gestionada es desproporcionada para el tamaño de la empresa.
• Se necesitan extensiones o parámetros que el proveedor no permite.
• Hay un requisito de portabilidad entre nubes o de despliegue en un centro de datos propio.
• El equipo ya tiene madurez operativa demostrada en Kubernetes y alguien con conocimiento real de PostgreSQL.

Razones que no justifican nada: "queda más limpio", "así todo es Kubernetes", "el YAML es bonito".

La decisión de Rutas Norte. En el módulo 6 se presentó CloudNativePG como sustituto del StatefulSet artesanal, y en el módulo 10 se eligió EKS en eu-west-1. El equipo de plataforma ha decidido mantener postgres-reservas dentro del clúster con CloudNativePG, con dos condiciones explícitas escritas en el acta: que las copias vayan siempre a un almacén de objetos fuera del clúster, y que la restauración se pruebe trimestralmente. La razón de la decisión no es técnica sino económica y de portabilidad: el volumen de datos es modesto (unos 120 GB), la instancia gestionada equivalente con alta disponibilidad multi-zona costaría aproximadamente el triple, y la dirección quiere conservar la opción de mover la plataforma a otra nube en dos años.

Es una decisión legítima con una consecuencia clara: el equipo de plataforma asume la guardia de la base de datos. Si nadie está dispuesto a firmar eso, la respuesta correcta era la gestionada.

Cuatro propiedades que rompen las suposiciones cómodas del módulo anterior.

Un pod de api-reservas es intercambiable con cualquier otro. Un pod de PostgreSQL no: uno es el primario y acepta escrituras, los demás son réplicas y solo leen. La identidad no está en la etiqueta, está en el estado de la replicación en ese instante, y puede cambiar sin que nadie despliegue nada.

Al arrancar un clúster de PostgreSQL, la primera instancia debe inicializar el directorio de datos; las demás deben clonarse de ella. Al actualizar, hay que actualizar primero las réplicas y promocionar después. RollingUpdate no entiende de eso.

El volumen no es caché: es el activo. Esto cambia tres cosas de golpe:

• La política de reclamación del PV debe ser Retain, no Delete (05-02).
• Borrar el recurso no puede borrar el dato: hace falta protección explícita.
• Las copias no son opcionales ni son un detalle de operación: son parte del diseño.

La conclusión práctica: para lo que tiene estado, no despliegas cargas, delegas en un operador que sabe de esa base de datos concreta. Eso es exactamente lo que vimos en 06-07 y lo que vamos a aplicar ahora.

CloudNativePG es un operador que implementa un clúster de PostgreSQL con replicación en flujo, elección de primario, copias continuas y actualizaciones controladas. No usa StatefulSets: gestiona los pods directamente porque necesita un control más fino del orden.

Las decisiones que conviene entender:

• instances: 3 y no 2. Con dos instancias, en cuanto una cae te quedas sin redundancia justo cuando más la necesitas, porque reconstruir una réplica de 120 GB tarda un rato. Tres es el mínimo defendible en producción.
• primaryUpdateMethod: switchover. Al aplicar una actualización menor, el operador actualiza primero las réplicas, luego promociona una réplica ya actualizada y por último actualiza el antiguo primario. El corte se mide en segundos, no en minutos.
• walStorage separado. El WAL tiene un patrón de escritura muy distinto al de los datos y, sobre todo, si se llena el volumen de datos por culpa del WAL, PostgreSQL se detiene. Separarlos convierte un incidente de severidad alta en uno leve.
• podAntiAffinityType: required. Con preferred, un clúster apretado puede colocar dos instancias en el mismo nodo y la alta disponibilidad se vuelve ficticia.
• inheritFromIAMRole: true. Ninguna clave de acceso guardada en ningún sitio: la ServiceAccount del pod tiene un rol de la nube asociado. Es la continuación directa de lo visto en 08-01 y 10-06.
• retentionPolicy: "30d". Este valor debe validarlo el responsable de cumplimiento normativo: retener demasiado poco incumple obligaciones contables y de continuidad; retener demasiado, con datos personales dentro, incumple el principio de limitación del plazo de conservación.

El backup del Cluster define dónde y cómo; hace falta además decir cuándo se toma la copia base.

Con la copia base diaria y el archivado continuo del WAL, la ventana de pérdida de datos es de segundos, no de un día: se restaura la copia base más reciente y se reproducen los WAL hasta el instante deseado. Eso es la recuperación a un instante concreto del apartado 6.

El operador mantiene un pod como primario y anota su identidad en el estado del Cluster. Cuando el primario deja de responder a las comprobaciones durante más de failoverDelay, el operador elige la réplica con el WAL más avanzado, la promociona y reconfigura las demás para que sigan a la nueva. Todo eso sin que ningún manifiesto cambie.

Los Services que crea automáticamente:

PostgreSQL crea un proceso por conexión. Con max_connections: 200 y un HPA que durante el puente de mayo lleva api-reservas a 40 réplicas con un pool de 20 conexiones cada una, la aritmética es demoledora: 800 conexiones solicitadas contra 200 disponibles. El resultado no es lentitud, es rechazo de conexiones y errores 500 en la venta de billetes.

La solución es un agrupador de conexiones (PgBouncer) delante de la base de datos, que CloudNativePG gestiona como recurso propio:

Mil conexiones de aplicación se multiplexan sobre cuarenta reales. Por eso el ConfigMap de api-reservas de la lección anterior apunta a postgres-reservas-pooler-rw y no directamente al Service -rw.

Precio a pagar: poolMode: transaction es incompatible con funcionalidades ligadas a la sesión (sentencias preparadas con nombre en algunos controladores, LISTEN/NOTIFY, tablas temporales de sesión, SET persistente). En api-reservas se comprobó que ninguna se usa. Si se usara alguna, la alternativa es session, que reduce mucho la ventaja del agrupador.

Un mecanismo de alta disponibilidad que nunca se ha probado es una hipótesis. Esta es la prueba que Rutas Norte ejecuta en rutas-norte-pre antes de cada temporada alta.

Resultados del último simulacro en rutas-norte-pre (tres repeticiones, valores medios):

Quince segundos sin poder escribir. Si api-reservas no hace nada al respecto, esos quince segundos son quince segundos de errores 500 en la compra de billetes, y en pleno puente de mayo eso son varios cientos de ventas perdidas.

Tres mecanismos, y el orden importa.

Tiempos de espera acotados. Sin tiempo de espera, una conexión a un primario muerto se queda colgada hasta el tiempo de espera del sistema operativo (minutos). Con él, falla rápido y se puede reintentar.

Reintentos con espera exponencial y aleatoriedad, solo para lo idempotente. Reintentar un SELECT es seguro. Reintentar INSERT INTO reservas sin más puede duplicar la reserva y cobrar dos veces al cliente: hace falta una clave de idempotencia.

Con cuatro intentos y base de 200 ms, la ventana cubierta ronda los 4-6 segundos. No cubre los quince del corte completo, y eso es deliberado: alargarla más haría que las peticiones se acumularan en el servidor hasta agotar la memoria.

Circuito para lo que no se puede reintentar. Cuando los fallos superan un umbral, el circuito se abre y la API deja de intentar durante unos segundos, devolviendo una respuesta degradada e inmediata en lugar de acumular peticiones colgadas.

La combinación de los tres reduce el impacto real de la conmutación a unos pocos segundos de degradación parcial, con la venta recuperándose sola. Es la diferencia entre un incidente de severidad 1 y una nota en el registro.

Con archivado continuo del WAL, el RPO real es de segundos. El RTO es el que hay que medir, y solo se mide restaurando.

CloudNativePG restaura creando un Cluster nuevo a partir del almacén de objetos. Nunca se restaura "encima" del clúster existente: se levanta uno paralelo, se verifica y luego se decide.

Verificación antes de dar por buena la restauración:

Simulacro del 12 de julio de 2026 sobre una copia de 118 GB:

Cuarenta y tres minutos, dentro del RTO de una hora, pero con poco margen. Dos acciones salieron del simulacro: subir maxParallel de 4 a 8 en la recuperación (ya aplicado arriba) y tener el manifiesto de restauración escrito y versionado en el repositorio, con el instante objetivo como único parámetro a rellenar. Los seis minutos de "redactar el manifiesto" bajo presión son el peor sitio para improvisar.

Una copia que no se ha restaurado nunca no existe. Es una afirmación literal, no una figura retórica. Los modos de fallo reales son mundanos: la credencial del almacén caducó hace cuatro meses y nadie miró la alerta; el bucket tenía una política de ciclo de vida que movía los objetos a almacenamiento en frío con horas de latencia de recuperación; la copia se hacía pero de una base de datos que ya no era la de producción. Todos se detectan restaurando, y ninguno se detecta mirando que el ScheduledBackup esté en verde.

La regla de Rutas Norte: restauración completa cronometrada cada trimestre, con acta y con el tiempo apuntado. Está en el calendario de mantenimiento de 11-06.

Las actualizaciones menores (16.4 → 16.6) las hace el operador solo: cambias imageName, actualiza réplicas, conmuta y actualiza el antiguo primario. Corte de segundos.

Las mayores (16 → 17) son otra cosa: cambia el formato del directorio de datos, la replicación en flujo no funciona entre versiones distintas y la reversión no es trivial. Hay tres caminos.

Rutas Norte eligió la replicación lógica. El procedimiento, resumido:

Secuencia del día del cambio:

1. Semanas antes: levantar el clúster 17 en rutas-norte-pre, ejecutar el conjunto completo de pruebas de api-reservas contra él y comparar planes de ejecución de las diez consultas más costosas. Un cambio de plan en el planificador es el riesgo real de una actualización mayor.
2. Días antes: levantar el 17 en pro y dejarlo sincronizando por replicación lógica hasta que el retraso sea de milisegundos.
3. Ventana de corte (unos 90 s): poner api-reservas en modo de solo lectura mediante una bandera de funcionalidad, confirmar retraso cero, detener la suscripción, apuntar el ConfigMap al pooler del clúster 17, reiniciar el despliegue y quitar el modo de solo lectura.
4. Después: vigilar durante 48 horas. El clúster 16 se conserva una semana apagado pero intacto, como plan de reversión.

Un detalle que se olvida siempre: ANALYZE completo tras la migración. Las estadísticas del planificador no se transfieren, y sin ellas las consultas van lentas durante horas y parece que la actualización ha ido mal.

informes-ocupacion es el CronJob nocturno que recorre meses de reservas para calcular ocupación por línea y por franja. Son consultas pesadas que, ejecutadas contra el primario, compiten con la venta de billetes.

La solución es directa: apuntarlo al Service -ro, que solo enruta a réplicas.

Dos advertencias sobre las réplicas de lectura:

• Coherencia eventual. Una réplica va unos milisegundos por detrás. Para informes es irrelevante; para "acabo de reservar y no veo mi reserva" es un error visible para el usuario. Regla en Rutas Norte: lo que el usuario acaba de escribir se lee del primario; todo lo demás puede ir a réplica.
• Conflictos de recuperación. Una consulta larga en la réplica puede entrar en conflicto con el WAL que llega y ser cancelada. Se ajusta con max_standby_streaming_delay, aceptando a cambio más retraso de replicación durante los informes.

Redis es también una carga con estado, pero de una categoría distinta: su dato es reconstruible. Esa diferencia lo cambia todo.

En Rutas Norte, redis-cache guarda tres cosas:

El carrito es el caso incómodo: no es crítico como una reserva confirmada, pero perderlo es visible y molesto.

Decisión de Rutas Norte: persistencia AOF activada con appendfsync everysec, un solo nodo con volumen persistente y sin réplica. El razonamiento:

• Sin persistencia, cada reinicio de pod (una actualización de nodo, un cambio de configuración) vacía todos los carritos activos. Ocurre varias veces al mes.
• Con AOF cada segundo, un reinicio ordenado pierde como mucho un segundo de escrituras y los carritos sobreviven.
• Montar Redis Sentinel o un clúster para un dato con TTL de quince minutos es complejidad sin retorno.

Y, sobre todo, la aplicación asume que Redis puede no estar: si la caché no responde, api-reservas va a PostgreSQL; si el carrito no está, se pide al usuario que repita la selección con un mensaje claro. Ninguna llamada a Redis puede tumbar una petición.

Un cuidado adicional: si Redis cae durante el puente de mayo, toda la carga de lectura pasa de golpe a PostgreSQL. Hay que dimensionar la base de datos para sobrevivir a ese escenario, o el fallo de un componente prescindible se convierte en la caída de uno que no lo es.

La fila 18 no es burocracia: en un clúster de PostgreSQL con datos personales, la retención de copias, la región del almacén de objetos, quién puede abrir una psql contra producción y qué queda registrado de ello son decisiones con consecuencias legales, no solo técnicas.

• Montar la base de datos en Kubernetes por coherencia estética. Si nadie del equipo sabe hacer una recuperación a un instante concreto ni está dispuesto a estar de guardia, la respuesta correcta es la base de datos gestionada, aunque cueste más.
• Confiar en el ScheduledBackup en verde. El indicador dice que el proceso se ejecutó, no que la copia sea restaurable. Solo la restauración cronometrada lo demuestra.
• Copias en el mismo clúster o en la misma cuenta que produce el dato. Un borrado accidental con permisos amplios, o un compromiso de credenciales, se lleva el dato y la copia a la vez. Almacén separado y, si es posible, cuenta separada con inmutabilidad.
• Conectar la aplicación al Service -rw sin agrupador. Funciona perfectamente hasta que el HPA escala, y entonces falla justo el día de más ventas.
• Reintentar escrituras no idempotentes. Duplica reservas y cobros. Cada escritura reintentable necesita una clave de idempotencia.
• Usar allkeys-lru en un Redis que guarda carritos. Al llenarse la memoria desaloja carritos activos. volatile-lru con TTL solo en lo que es caché protege el dato que sí importa.
• Consejo: escribe el manifiesto de restauración antes de necesitarlo y guárdalo en el repositorio con el instante objetivo como hueco a rellenar. Ahorra los minutos más caros del incidente.
• Consejo: haz ANALYZE tras cualquier migración o actualización mayor. Sin estadísticas, el planificador toma decisiones malas y todo parece roto.
• Consejo: dimensiona la base de datos para el escenario en que la caché no está. Si no, un fallo prescindible se convierte en uno crítico.

Rutas Norte va a lanzar un producto nuevo, rutas-carga, con su propia base de datos PostgreSQL de unos 8 GB, tres desarrolladores, sin equipo de plataforma dedicado y con lanzamiento previsto en seis semanas. Los datos incluyen información de contacto de empresas cliente. Recomienda una de las tres opciones y justifica la decisión con al menos cuatro criterios de la tabla del apartado 1. Indica también qué revisión adicional hace falta por los datos de contacto.

api-reservas tiene un HPA con maxReplicas: 40 y cada réplica abre hasta 20 conexiones. informes-ocupacion abre 5 conexiones contra las réplicas. postgres-reservas tiene max_connections: 200, de las cuales PostgreSQL reserva 3 para superusuario. Calcula las conexiones máximas solicitadas sin agrupador, explica qué ocurre en el pico del puente de mayo y comprueba si max_client_conn: 1000 y default_pool_size: 40 son valores adecuados.

Durante el simulacro trimestral, el Cluster de restauración se queda así:

Enumera tres causas posibles, di cómo distinguirlas y qué corrección aplicarías en cada caso. Indica además qué implicación tiene esto sobre el RPO real.

Solución 1. Recomendación: base de datos gestionada del proveedor. Criterios: (a) coste de personal, no hay equipo de plataforma y el operativo del operador recaería sobre tres desarrolladores que deben construir el producto; (b) tiempo hasta producción, seis semanas no dan margen para adquirir madurez operativa con CloudNativePG; (c) riesgo de fallo catastrófico, sin guardia establecida un fallo nocturno queda sin respuesta; (d) coste de infraestructura, la prima del proveedor sobre 8 GB es pequeña en términos absolutos, muy distinto del caso de postgres-reservas con 120 GB. El StatefulSet artesanal queda descartado de entrada. Revisión adicional: los datos de contacto de empresas cliente son datos personales de personas físicas de contacto, por lo que la elección de región, la retención de copias y las condiciones del encargado del tratamiento (el proveedor de la nube) deben ser revisadas por el responsable de cumplimiento normativo antes de contratar.

Solución 2. Sin agrupador: 40 × 20 = 800 conexiones de api-reservas, más 5 de informes = 805 solicitadas frente a 197 utilizables. En el pico del puente de mayo, en cuanto se superan las 197, PostgreSQL rechaza con FATAL: sorry, too many clients already; los pods afectados fallan sus sondas de preparación, salen del balanceo, el HPA ve más carga en los restantes y escala más, empeorando el problema: un ciclo de realimentación destructivo. Con el pooler: max_client_conn: 1000 cubre las 805 solicitadas con margen (adecuado); default_pool_size: 40 más reserve_pool_size: 10 abre como máximo 50 conexiones reales contra el primario, holgadamente dentro de 197, dejando sitio para informes, mantenimiento y superusuario. Ambos valores son correctos. Conviene vigilar la métrica de tiempo de espera en cola de PgBouncer: si crece durante el pico, el cuello de botella pasa a ser default_pool_size y habría que subirlo (con margen hasta unas 150 conexiones reales).

Solución 3. Causas posibles: (a) retención insuficiente, los WAL de ese periodo ya se eliminaron por la política de 30 días o por una regla de ciclo de vida del bucket; se distingue listando el prefijo wals/ en el almacén y comprobando si el segmento existe; corrección: elegir un instante objetivo dentro del rango disponible y revisar la política de retención y las reglas de ciclo de vida. (b) Fallo del archivado continuo, el primario dejó de archivar WAL en algún momento (credencial caducada, permisos, disco lleno) y hay un hueco; se distingue mirando cnpg_collector_last_failed_archive_time y los registros del primario; corrección: reparar el archivado y, muy importante, tomar inmediatamente una copia base nueva. (c) Permisos o ruta incorrectos en la restauración, el serverName o el destinationPath no coinciden con los del origen, o el rol federado no tiene lectura sobre ese prefijo; se distingue porque fallarían todos los segmentos, no uno concreto; corrección: ajustar serverName/destinationPath y los permisos del rol. Implicación sobre el RPO: si el archivado tiene huecos, el RPO declarado de 5 minutos es falso, y el real es la antigüedad de la última copia base completa, que puede ser de casi 24 horas. Es exactamente la razón por la que existe la alerta CopiaPostgresAntigua y por la que el simulacro trimestral es obligatorio.

Hemos resuelto de principio a fin el escenario de una carga con estado en producción. Empezamos por la pregunta que no conviene esquivar —si la base de datos debe estar en Kubernetes— y llegamos a una decisión razonada y con condiciones: en Rutas Norte se queda dentro del clúster con CloudNativePG, con copias fuera y restauración probada cada trimestre. Vimos qué hace especial al estado (identidad, orden, dato irreemplazable, actualizaciones que no admiten RollingUpdate), el recurso Cluster completo con sus decisiones justificadas, el agrupador de conexiones que evita que el éxito del HPA tumbe la base de datos, la conmutación por error medida en quince segundos y los tres mecanismos que permiten a api-reservas atravesarlos sin errores visibles, la recuperación a un instante concreto con su tiempo real de 43 minutos, la actualización de versión mayor por replicación lógica, las réplicas de lectura para los informes y redis-cache como el caso en que perder el dato es aceptable, siempre que la aplicación lo asuma.

La idea que resume la lección: en las cargas con estado, lo que te salva no son los manifiestos, sino los procedimientos probados. La copia que nunca se restauró, la conmutación que nunca se simuló y la actualización que nunca se ensayó en pre son deuda esperando a vencer en el peor momento.

Ya tenemos la aplicación sin estado y la base de datos en producción. Lo que no hemos contado todavía es cómo llega el código hasta ahí. En la siguiente lección, CI/CD con Kubernetes, seguimos el camino completo desde el git push de un desarrollador hasta el pod que atiende peticiones en rutas-norte-pro, pasando por la construcción de la imagen, su escaneo y firma, las pruebas contra un clúster efímero y la promoción entre entornos con Argo CD.