Rodar banco de dados no Kubernetes é polêmico. A resposta honesta: depende. Com um operador maduro, você ganha automação de failover, backup e upgrade que dificilmente teria com scripts próprios.

O CloudNativePG (CNPG) é um dos operadores mais completos para PostgreSQL.

Selo do curso: testado em Kubernetes 1.35 com CloudNativePG 1.24/1.25 e PostgreSQL 16.

O que o operador entrega

• Cluster com primário + réplicas.
• Serviços -rw, -ro e -r.
• Streaming replication gerenciada.
• Failover e switchover.
• Backup contínuo (WAL) para S3/MinIO.
• Restore e point-in-time recovery.
• Métricas Prometheus.

O 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"

Serviços criados:

Serviço	Uso
portal-postgres-rw	escrita (primário)
portal-postgres-ro	leitura (réplicas)
portal-postgres-r	qualquer instância

A aplicação deve escrever no -rw e ler no -ro (se tolerar lag).

Failover e switchover

• Switchover: planejado, sem perda.
• Failover: primário morreu; o operador promove a réplica mais avançada.

O CNPG usa replicação e um instance manager. Se o primário perde o liveness, o operador inicia o failover. O primário antigo precisa ser fenced (parar de escrever). Se ele não morre, o cluster pode ficar em Failing over.

Caso real: em um teste de carga, o primário perdeu os probes por contenção de memória/CPU. O failover iniciou, mas o pod antigo ficou preso em shutdown. A remoção manual do pod permitiu a promoção da réplica. O runbook está no capítulo do postmortem.

Backup

Backup do CNPG tem duas partes:

1. WAL archiving contínuo (RPO baixo).
2. Base backup agendado.

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

Verifique:

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

Backup que nunca foi restaurado não é backup. Faça drill.

Restore

Restore para um cluster novo (não sobrescreva o atual):

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, adicione recoveryTarget com data/hora. Valide os dados antes de apontar a aplicação.

Laboratório

1. Inspecione o 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. Veja o primário e as réplicas:

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

3. Teste failover em laboratório:

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

4. Faça um backup manual e acompanhe:

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

5. Restore em um cluster novo e valide com psql.

Erros comuns

Sintoma	Causa
Cluster não fica Ready	PVC, storageClass ou secrets
Backup falha	credenciais S3, endpoint ou bucket
Failing over preso	primário antigo não terminou shutdown
Réplica com lag	IO/rede ou recurso insuficiente
Aplicação escreve no -ro	configuração errada de serviço
Restore não sobe	backup/WAL incompleto ou credencial

Checklist

• [ ] Cluster com pelo menos 2 instâncias.
• [ ] Anti-affinity entre primário e réplica.
• [ ] PDB e recursos definidos.
• [ ] Backup agendado + WAL archiving.
• [ ] Restore testado em cluster novo.
• [ ] Monitoramento e alertas de lag/failover.
• [ ] Runbook de failover e fencing.

Glossário

• primário: instância de escrita.
• réplica: instância de leitura/replicação.
• failover: promoção automática.
• switchover: troca planejada.
• WAL: write-ahead log.
• PITR: point-in-time recovery.
• fencing: impedir que o antigo primário escreva.

Próximo

Agora que o banco está coberto, vamos ao object storage: MinIO, erasure coding, buckets e credenciais.

Próximo: Curso Kubernetes 16 — MinIO: erasure coding, buckets e credenciais