PostgreSQL en Kubernetes: buenas prácticas para despliegue, backups y actualizaciones sin sorpresas

Ejecutar PostgreSQL en Kubernetes puede ser una gran idea… o un dolor de cabeza si no se administra con disciplina. A diferencia de servicios stateless, una base de datos requiere ser riguroso en aspectos como el almacenamiento, la alta disponibilidad, los backups, la monitorización y las actualizaciones.

En esta guía se recopilan buenas prácticas orientadas a entornos empresariales para desplegar, proteger y actualizar PostgreSQL sobre Kubernetes minimizando los riesgos.

Índice

• Modelo operativo
• Despliegue: patrones que evitan problemas
• Alta disponibilidad (HA)
• Backups: restauración PITR
• Actualizaciones sin sustos
• Security
• Monitorización
• Checklist rápido
• Cómo puede ayudar Hopla
• Preguntas frecuentes (FAQ)

1) Modelo operativo

Antes de hablar de la defi nición del YAML, es esencial defi nir cómo vas a operar PostgreSQL:

• Opción A: Operador de PostgreSQL (recomendado en la mayoría de casos) Un operador automatiza tareas complejas: alta disponibilidad, failover, backups, upgrades, rotación de credenciales, etc.
• Opción B: StatefulSet “a mano”
  Puede encajar para casos simples o muy controlados, pero te obliga a implementar tú mismo HA, failover, orquestación de réplicas, backups consistentes y procedimientos de upgrade.
  Si el objetivo es evitar sorpresas, suele ganar el enfoque con operador, porque reduce trabajo manual y estandariza la operativa.

2) Despliegue: patrones que evitan problemas desde el día 1

2.1 Usa almacenamiento persistente

El rendimiento y la estabilidad de PostgreSQL dependen directamente del I/O. En Kubernetes, esto se traduce a:

• StorageClass adecuada (latencia, IOPS, throughput).
• CSI driver soportado y validado en tu plataforma.
• Volúmenes por instancia (no se deben usar volúmenes compartidos salvo casos específi cos que lo requieran).
• Política clara de retención del volumen al borrar el recurso (para evitar pérdidas accidentales).

Recomendación práctica: documentar las características del almacenamiento (SLOs, rendimiento esperado, límites) y validarlas mediante pruebas de carga realistas.

2.2 Aislamiento y planificación de pods (anti-afinidad y resiliencia)

Para reducir riesgos ante fallos de nodo/zona:

• Pod anti-affinity para separar primario y réplicas.
• Topology spread constraints si tu clúster está distribuido (zonas/CPDs).
• PodDisruptionBudget (PDB) para evitar que los mantenimientos del clúster del clúster interrumpan el servicio.
• Ajusta el priorityClass si la BBDD es crítica frente a otros workloads.

2.3 Recursos: no improvises con los recursos (CPU/RAM)

Buenas prácticas:

• Defi ne requests y limits realistas para CPU y memoria.
• Evita límites de memoria demasiado ajustados: una OOMKill en PostgreSQL compromete la estabilidad del servicio.
• Alinea confi guración de PostgreSQL con recursos (p. ej. shared_buffers, work_mem, max_connections) para mantener el uso de memoria bajo control.

2.4 Liveness/Readiness: cuidado con los reinicios innecesarios

• La Readiness probe, debe refl ejar si la instancia acepta tráfi co.
• Un Liveness probe, mal ajustado puede forzar reinicios en momentos de alta carga, justo cuando se necesite máxima estabilidad.
• Para arranques lentos (replay de WAL, recovery, etc.), valora usar startupProbe.

3) Alta disponibilidad (HA): define tu objetivo de RPO/RTO

En HA hay dos preguntas clave:

• RPO (Recovery Point Objective): cuántos datos puedes perder.
• RTO (Recovery Time Objective): cuánto tiempo puedes tardar en recuperar el entorno.
  Teniendo en cuenta estos dos conceptos de RPO y RTO, cabe diferenciar:
• Réplicas asíncronas: mejor rendimiento, posible pérdida mínima de datos en failover.
• Réplicas síncronas: menos pérdida de datos, más latencia y de bloquear las escrituras si una réplica deja de responder.
  Buenas prácticas:
• Defi ne cuántas réplicas y dónde se alojan (nodos/zonas).
• Establece reglas de failover claras (automático vs manual).
• Evita “split brain” con mecanismos de consenso/leader election (típicamente gestionado por el operador).

4) Backups: lo importante no es “hacer” backup, es “restaurar”

4.1 Backups físicos + WAL = recuperación real

Para PostgreSQL, lo habitual en entornos serios es combinar:

• Backup base (full o incremental según herramienta).
• Archivado de WAL (Write-Ahead Log) para poder hacer PITR (Point-in-Time Recovery). Sin WAL, tu capacidad de recuperación queda limitada al momento en el que se ejecutó el backup.

4.2 Reglas de oro para backups en Kubernetes

• Los backups deben guardarse fuera del clúster (almacenamiento externo u objeto tipo S3- compatible, según tu plataforma).
• Se deben cifrar los backups en reposo y en tránsito si aplica (y se deben gestionar claves con buenas prácticas).
• Defi nir la retención: diaria/semanal/mensual según el cumplimiento y el negocio.
• Automatiza y monitoriza los siguientes puntos:
  ◦ el éxito/fallo del backup
  ◦ el retraso de WAL
  ◦ el consumo de almacenamiento
  ◦ los tiempos de backup/restauración

4.3 Pruebas de restauración

En la práctica las buenas práctica que más incidentes evita son:

• Planifi car restauraciones periódicas en un entorno controlado.
• Medir el tiempo de recuperación real (RTO).
• Verifi car la integridad funcional (conexión, queries críticas, migrations, etc.).
• Documentar el procedimiento paso a paso y quién lo ejecuta.

4.4 Snapshots de volumen: son útiles, pero no suficientes

Los snapshots del Persisten Volume (PV) pueden ayudar, pero ojo:

• No siempre garantizan consistencia de base de datos si no se coordina correctamente.
• Se puede usar como complemento, no como única estrategia. Salvo que tengas un proceso robusto y verifi cado.

5) Actualizaciones sin sustos: estrategia para minor, major y Kubernetes

5.1 Distingue entre “minor” vs “major”

• Minor upgrades (parches): suelen ser más sencillos, pero no “gratis”. Valida la compatibilidad, reinicios y ventanas.
• Major upgrades (cambios de versión): requieren un plan de acción y, normalmente, procedimientos específi cos (migración/upgrade controlado).

5.2 Reglas para actualizar con confianza

• El staging debe ser lo más parecido posible a producción.
• Automatiza pruebas (smoke tests) tras el upgrade.
• Defi ne ventanas de mantenimiento, plan de rollback y responsabilidades.
• Controla cambios en:
  ◦ extensiones (p. ej. pg_stat_statements, postgis, etc.)
  ◦ parámetros de confi guración
  ◦ drivers/ORMs en aplicaciones
  ◦ herramientas de backup/replicación

5.3 Caso típico: upgrades del clúster Kubernetes

Muchas incidencias no vienen de PostgreSQL, sino de:

• cambios del CSI/StorageClass
• drenado de nodos sin respetar PDB
• cambios de red/ingress/service mesh
• políticas de seguridad (PSA/Pod Security, RBAC) que bloquean operaciones
  Por tanto, cabe recomendar algunas buenas prácticas:
• Coordina los upgrades del clúster con la capa de datos.
• Ejecuta pruebas de conmutación (failover) antes y después.
• Mantener monitorización y alertas reforzadas durante la ventana.

6) Seguridad: PostgreSQL en Kubernetes introduce capas que también deben securizarse.

Entre los puntos clave, señalamos:

• RBAC mínimo: el servicio de PostgreSQL no debería de tener permisos amplios.
• En los secretos hay que:
  ◦ evitar credenciales estáticas
  ◦ rotar contraseñas
  ◦ limitar quién puede leer los Secrets
• A nivel de Red:
  ◦ Uso de NetworkPolicies para limitar qué namespaces/pods acceden a PostgreSQL
  ◦ Cifrado de TLS en tránsito cuando aplique.
• Hardening del contenedor e imagen:
  ◦ Uso de imágenes de confi anza
  ◦ Escaneo continuo de vulnerabilidades
  ◦ Usuario no root siempre que sea posible

7) Monitorización: si no lo mides, lo sufrirás

Métricas y señales que suelen marcar la diferencia:

• latencia de queries y percentiles
• conexiones activas / saturación de max_connections
• bloqueos (locks)
• bloat (fragmentación) y autovacuum (vacuum freeze, tiempos, frecuencia)
• replicación: lag, estado de réplicas, WAL
• disco: uso, IOPS, latencia, crecimiento por día
• errores en logs y patrones anómalos
  Defi ne alertas y umbrales alineados con tus SLOs.

8) Checklist rápido previo a producción

Antes de entrar en producción:

• Revisa si la estrategia de HA está alineada a RPO/RTO.
• Haz pruebas con carga real.
• Backups con WAL + restauración probada (PITR si aplica).
• Defi ne si es necesario PodDisruptionBudget (PDB) y anti-afi nidad así como la estrategia de upgrades del clúster
• Monitorización completa (métricas, logs, alertas) y runbooks.
• Válida la seguridad: RBAC, Secrets, NetworkPolicies, cifrado donde proceda.

9) Cómo puede ayudar Hopla

Si tu objetivo es operar PostgreSQL en Kubernetes con garantías, suele ser clave estandarizar la plataforma (Kubernetes), automatizar la operación (procedimientos y tooling) y asegurar continuidad (backups, DR, monitorización y seguridad). Hopla trabaja precisamente en estas capas y pone a tu disposición servicios gestionados de Kubernetes, PostgreSQL y ciberseguridad, para ayudar a reducir riesgo operativo y acelerar la entrega sin comprometer estabilidad.
Si prefi eres montar tu propia plataforma, Hopla también ofrece servicios de consultoría para acompañarte y apoyarte en el proceso.

10) Preguntas frecuentes (FAQ)