Ejecutar bases de datos en Kubernetes es polémico. La respuesta honesta: depende. Con un operador maduro, ganas automatización de failover, backup y upgrade que difícilmente tendrías con scripts propios.

CloudNativePG (CNPG) es uno de los operadores más completos para PostgreSQL.

Sello del curso: probado en Kubernetes 1.35 con CloudNativePG 1.24/1.25 y PostgreSQL 16.

Qué ofrece el operador

• Cluster con primario + réplicas.
• Servicios -rw, -ro y -r.
• Streaming replication gestionada.
• Failover y switchover.
• Backup continuo (WAL) a S3/MinIO.
• Restore y point-in-time recovery.
• Métricas Prometheus.

El Cluster

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: portal-postgres
  namespace: portal
spec:
  instances: 2
  imageName: ghcr.io/cloudnative-pg/postgresql:16.4
  storage:
    size: 10Gi
    storageClass: portal-nfs
  resources:
    requests:
      cpu: 250m
      memory: 512Mi
    limits:
      cpu: "2"
      memory: 2Gi
  monitoring:
    enablePodMonitor: true
  backup:
    barmanObjectStore:
      destinationPath: s3://portal-k8s-backup/
      endpointURL: http://minio-s3:9000
      s3Credentials:
        accessKeyId:
          name: portal-secrets
          key: APP_STORAGE_S3_ACCESSKEY
        secretAccessKey:
          name: portal-secrets
          key: APP_STORAGE_S3_SECRETKEY
      wal:
        compression: gzip
    retentionPolicy: "14d"

Servicios creados:

Servicio	Uso
portal-postgres-rw	escritura (primario)
portal-postgres-ro	lectura (réplicas)
portal-postgres-r	cualquier instancia

La aplicación debe escribir en -rw y leer en -ro (si tolera lag).

Failover y switchover

• Switchover: planificado, sin pérdida.
• Failover: el primario murió; el operador promueve la réplica más avanzada.

CNPG usa replicación y un instance manager. Si el primario pierde el liveness, el operador inicia el failover. El primario antiguo necesita ser fenced (dejar de escribir). Si no muere, el cluster puede quedarse en Failing over.

Caso real: en una prueba de carga, el primario perdió los probes por contención de memoria/CPU. El failover inició, pero el pod antiguo quedó atascado en shutdown. La eliminación manual del pod permitió la promoción de la réplica. El runbook está en el capítulo del postmortem.

Backup

El backup de CNPG tiene dos partes:

1. WAL archiving continuo (RPO bajo).
2. Base backup programado.

apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: portal-postgres-daily
spec:
  schedule: "0 2 * * *"
  immediate: true
  backupOwnerReference: self
  cluster:
    name: portal-postgres

Verifica:

kubectl -n portal get backups.postgresql.cnpg.io
kubectl -n portal get scheduledbackup

Un backup que nunca fue restaurado no es backup. Haz drill.

Restore

Restore a un cluster nuevo (no sobrescribas el actual):

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: portal-postgres-restore
spec:
  instances: 1
  storage:
    size: 10Gi
  bootstrap:
    recovery:
      source: portal-postgres
  externalClusters:
    - name: portal-postgres
      barmanObjectStore:
        destinationPath: s3://portal-k8s-backup/
        endpointURL: http://minio-s3:9000
        s3Credentials:
          accessKeyId:
            name: portal-secrets
            key: APP_STORAGE_S3_ACCESSKEY
          secretAccessKey:
            name: portal-secrets
            key: APP_STORAGE_S3_SECRETKEY

Para PITR, añade recoveryTarget con fecha/hora. Valida los datos antes de apuntar la aplicación.

Laboratorio

1. Inspecciona el cluster:

kubectl -n portal get cluster.postgresql.cnpg.io portal-postgres
kubectl -n portal get pods -l cnpg.io/cluster=portal-postgres -o wide
kubectl -n portal get svc | grep postgres

2. Ve el primario y las réplicas:

kubectl -n portal get cluster.postgresql.cnpg.io portal-postgres \
  -o jsonpath='{.status.currentPrimary}{"\n"}'

3. Prueba failover en laboratorio:

kubectl -n portal delete pod <primario>
kubectl -n portal get pods -w

4. Haz un backup manual y sigue el progreso:

kubectl -n portal create -f backup.yaml
kubectl -n portal get backups.postgresql.cnpg.io -w

5. Restaura en un cluster nuevo y valida con psql.

Errores comunes

Síntoma	Causa
El cluster no queda Ready	PVC, storageClass o secrets
Backup falla	credenciales S3, endpoint o bucket
Failing over atascado	el primario antiguo no terminó el shutdown
Réplica con lag	IO/red o recursos insuficientes
La aplicación escribe en -ro	configuración errónea del servicio
Restore no arranca	backup/WAL incompleto o credencial

Checklist

• [ ] Cluster con al menos 2 instancias.
• [ ] Anti-affinity entre primario y réplica.
• [ ] PDB y recursos definidos.
• [ ] Backup programado + WAL archiving.
• [ ] Restore probado en cluster nuevo.
• [ ] Monitoreo y alertas de lag/failover.
• [ ] Runbook de failover y fencing.

Glosario

• primario: instancia de escritura.
• réplica: instancia de lectura/replicación.
• failover: promoción automática.
• switchover: cambio planificado.
• WAL: write-ahead log.
• PITR: point-in-time recovery.
• fencing: impedir que el antiguo primario escriba.

Siguiente

Ahora que la base de datos está cubierta, vamos al object storage: MinIO, erasure coding, buckets y credenciales.

Siguiente: Curso Kubernetes 16 — MinIO: erasure coding, buckets y credenciales