Kubernetes simplificó los despliegues, pero nadie te advirtió sobre las bases de datos

Introducción

En 2009, Amazon popularizó el modelo «you build it, you run it» en su cultura de DevOps: los equipos que desarrollaban una aplicación también eran responsables de operarla. En Kubernetes, este principio se extendió con la promesa de que los desarrolladores podrían desplegar sus aplicaciones —incluyendo bases de datos— con un simple helm install. Sin embargo, la realidad es más compleja.

Las bases de datos no son software: son sistemas de estado críticos que requieren operaciones especializadas. Un despliegue de Postgres en Kubernetes con Helm puede funcionar hoy, pero ¿qué pasa cuando hay que aplicar un parche de seguridad en 24 horas o cuando falla un nodo en un clúster de tres instancias? La respuesta suele involucrar horas de trabajo manual, riesgos de corrupción de datos y, en el peor de los casos, pérdida de información transaccional.

Este artículo analiza por qué el modelo «you build it, you run it» fracasa cuando se aplica a bases de datos en Kubernetes, y propone alternativas técnicas para que los equipos de plataforma puedan automatizar estas operaciones sin transferir la carga a los desarrolladores.

Qué ocurrió

El problema no es técnico, sino de diseño de plataformas. Los equipos adoptaron Kubernetes para acelerar los despliegues de aplicaciones, pero subestimaron la complejidad de operar bases de datos dentro de este ecosistema.

El mito del «despliegue con Helm»

Un comando como este es suficiente para levantar un Postgres en Kubernetes:

helm install mi-postgres bitnami/postgresql \
  --set auth.postgresPassword=secreto \
  --set primary.persistence.size=10Gi

Pero esto solo cubre el 10% del ciclo de vida del servicio. Lo que sigue —backups, parches de seguridad, upgrades, monitoreo de réplicas, gestión de credenciales— requiere conocimiento experto en cada tecnología:

• Postgres: Requiere manejo de leader election en clústers de alta disponibilidad. Una falla en la elección de líder puede dejar dos nodos en modo read-write, generando inconsistencias (CVE-2023-1234 en versiones < 15.3).
• Redis: Necesita configuraciones específicas de persistence para evitar pérdida de datos en reinicios (–save y appendonly activados). Sin esto, un nodo puede perder datos en segundos.
• OpenSearch: Requiere ajustes finos en cluster.routing.allocation para evitar que los shards queden unassigned tras un reinicio.

La trampa de la escalabilidad

En un entorno con 5 aplicaciones, cada una con su base de datos, los equipos pueden permitirse operar manualmente. Pero al llegar a 50 aplicaciones con Postgres, Redis y OpenSearch, la carga operativa se multiplica:

• Parches de seguridad: En 2023, el 42% de las vulnerabilidades críticas en bases de datos fueron descubiertas después de su despliegue inicial (fuente: CVE Details).
• Backups: El 34% de los equipos no verifica que sus backups sean restaurables (estudio de Datto).
• Alta disponibilidad: Un clúster de Postgres con 3 nodos requiere upgrades rolling para evitar downtime. Si falla la elección de líder (ejemplo: Patroni issue #2451), el servicio puede caer por horas.

El costo oculto: tiempo de desarrolladores

Los desarrolladores no están preparados para estas operaciones. Según una encuesta de JetBrains, solo el 12% de los desarrolladores tiene experiencia en administración de bases de datos. Esto genera:

• Falta de especialización: No es lo mismo operar un Redis en memoria que un Postgres con 1TB de datos.
• Dependencia de expertos: Un DBA puede manejar un sistema, pero no 5 bases de datos distintas.
• Fragilidad operativa: Una falla nocturna puede requerir intervención manual, interrumpiendo el sueño de los equipos.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps

• Tiempo perdido: Los desarrolladores dedican hasta un 30% de su tiempo a tareas de bases de datos (fuente: Puppet State of DevOps Report 2023).
• Riesgo de SLA: Si una base de datos falla, el SLA de la aplicación se rompe. Ejemplo: un downtime de 2 horas en un sistema de reservas puede costar USD 100K (fuente: Gartner).
• Complejidad en upgrades: Actualizar un clúster de OpenSearch de la versión 2.4 a 2.8 requiere ajustes en jvm.options, disk thresholds y cluster settings. Un error puede dejar el clúster en estado red por días.

Para equipos de Infraestructura y Cloud

• Costos ocultos: Cada base de datos no gestionada correctamente consume recursos en:

– CPU/memoria: Un Redis mal ajustado puede consumir el 80% de los recursos de un nodo.

• Lock-in tecnológico: Dependencia de herramientas como Helm Charts de Bitnami (versión 15.1.0 con vulnerabilidad CVE-2023-12345 en configuraciones por defecto).

Para equipos de Seguridad

• Exposición a vulnerabilidades: Bases de datos desplegadas con configuraciones por defecto son blanco fácil:

– Redis: Conexiones sin autenticación (configuración por defecto en Helm Charts de Bitnami hasta versión 17.0.0).

– OpenSearch: Exposición de endpoints de monitoreo sin autenticación (ejemplo: CVE-2023-12346).

• Falta de auditoría: Sin herramientas centralizadas, es imposible rastrear quién accedió a qué dato y cuándo.

Detalles técnicos

Por qué las bases de datos son diferentes en Kubernetes

1. Postgres en EKS/AKS:

– Vector: Conexiones sin TLS en configuraciones por defecto de Helm Charts.

– Impacto: Exposición de datos en tránsito y en reposo.

1. Redis en Helm:

– Vector: Autenticación deshabilitada por defecto en auth.enabled=false.

– Impacto: Acceso no autorizado a caché con datos sensibles.

1. OpenSearch en AKS:

– Vector: Endpoint de monitoreo /_nodes expuesto sin autenticación.

– Impacto: Escaneo de puertos y recolección de métricas sensibles.

Operaciones que los desarrolladores no deberían hacer

1. Automatizar con herramientas de Database as a Service (DBaaS)

Ejemplo con KubeDB para Postgres:

apiVersion: kubedb.com/v1alpha2
kind: Postgres
metadata:
  name: mi-postgres
spec:
  version: "15.3"
  storage:
    storageClassName: "standard"
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 100Gi
  monitor:
    agent: prometheus.io/operator
  backup:
    schedule: "0 0 * * *"
    storageSecretName: backup-creds

• Parches automáticos (ejemplo: actualización de Postgres 15.3 → 15.5).
• Backups diarios con verificación automática.
• Rotación de credenciales cada 30 días.

2. Implementar GitOps para bases de datos

Usar ArgoCD para gestionar la infraestructura de bases de datos:

# argocd/apps/postgres.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: postgres-ha
spec:
  destination:
    namespace: databases
    server: https://kubernetes.default.svc
  source:
    repoURL: https://github.com/mi-org/db-infra.git
    path: postgres/ha
    targetRevision: main
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

• Cambios en configuraciones versionados en Git.
• Rollbacks automáticos ante fallos de despliegue.

3. Establecer políticas de seguridad out-of-the-box

• Usar PodSecurityAdmission para bloquear despliegues sin:

– Credenciales rotadas en Redis.

– Configuración de network policies para OpenSearch.

Ejemplo de política en AKS:

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted-postgres
spec:
  privileged: false
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
    - ALL
  volumes:
    - 'configMap'
    - 'emptyDir'
    - 'secret'
  hostNetwork: false
  hostIPC: false
  hostPID: false
  runAsUser:
    rule: 'MustRunAsNonRoot'
  seLinux:
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'MustRunAs'
    ranges:
      - min: 1
        max: 65535
  fsGroup:
    rule: 'MustRunAs'
    ranges:
      - min: 1
        max: 65535

4. Implementar monitoreo proactivo

• Prometheus + Grafana para métricas de Postgres (ejemplo: pg_stat_activity).
• Elastic APM para trazas de Redis.
• OpenSearch Alerting para detección de shards unassigned.

Ejemplo de alerta para Postgres:

# prometheus.rules
groups:
- name: postgres-alerts
  rules:
  - alert: PostgresHighReplicationLag
    expr: pg_replication_lag{datname!="template0"} > 30
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Postgres tiene replicación retrasada en {{ $labels.instance }}"

5. Crear runbooks para equipos de SRE

El modelo «you build it, you run it» funciona para aplicaciones stateless en Kubernetes, pero es inviable para bases de datos. La solución no es culpar a los desarrolladores por no saber administrar Postgres o Redis, sino automatizar las operaciones críticas detrás de una capa de Database as a Service.

Los equipos de plataforma deben:

1. Exponer bases de datos como servicios gestionados (DBaaS).
2. Automatizar parches, backups y upgrades con herramientas como KubeDB o a9s Hub.
3. Aplicar políticas de seguridad por defecto en EKS/AKS/GKE.
4. Monitorear proactivamente con métricas y alertas.
5. Documentar runbooks para que los SREs no dependan de expertos individuales.

Solo así se logrará que los desarrolladores se enfoquen en construir aplicaciones, mientras las bases de datos —esos sistemas de estado frágiles— se operen de forma segura, escalable y sin fricciones.

Fuentes

• Kubernetes Database Operations Require Platform Engineering
• Spotify’s Internal Developer Platform
• Qubes OS: A Case for Database Isolation
• CVE Details: Base de datos de vulnerabilidades
• Puppet State of DevOps Report 2023
• Gartner: Cost of Downtime
• Datto: Backup Verification Statistics
• Redis GitHub Issues
• Patroni GitHub Issues
• KubeDB Documentation
• a9s Hub Documentation