Bancos no Kubernetes (operator)

Sintoma

Objetivo: rodar o banco no Kubernetes com um operator; em vez de um StatefulSet puro, usar o failover automático, o armazenamento persistente e os recursos de backup que o operator oferece.

1. Por que um operator: só um StatefulSet não basta

Um StatefulSet simples dá pods com identidades estáveis e PVCs, mas não a lógica de failover, configuração de replicação, backup e upgrades. Um operator empacota esse conhecimento operacional específico do banco como um controller + custom resource (CRD). Você escreve um CR chamado 'Cluster', e o operator gerencia o StatefulSet, o Service, o Secret e os jobs de backup por trás dele. Em produção, rodar bancos com um operator é geralmente o preferido.

PostgreSQL

# operators for PostgreSQL:
#  - CloudNativePG (CNPG)
#  - Zalando postgres-operator
#  - Crunchy PGO

2. Escolha e instale o operator

Escolha um operator para o seu engine: CloudNativePG ou Zalando postgres-operator para PostgreSQL; os operators da Percona (Percona Operator for MySQL / for MongoDB) são comuns para MySQL e MongoDB. Instale o operator com Helm ou um manifesto bundle; esta etapa adiciona os CRDs e o pod do controller ao cluster.

PostgreSQL

# CloudNativePG installation
kubectl apply --server-side -f \
  https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/main/releases/cnpg-1.24.0.yaml

MySQL

# Percona Operator for MySQL (Helm)
helm install my-op percona/pxc-operator

MongoDB

# Percona Operator for MongoDB (Helm)
helm install psmdb-op percona/psmdb-operator

3. Planeje o armazenamento (StorageClass / PVC)

O estado do banco fica nos PVCs; especifique no CR a StorageClass a usar. Escolha uma StorageClass que ofereça block storage de baixa latência, de preferência SSD com desempenho próximo ao local; sistemas de arquivos de rede (NFS) não são recomendados para a maioria dos bancos. Defina corretamente desde o início o tamanho do PVC e a possibilidade de expansão (allowVolumeExpansion), porque reduzir é difícil.

PostgreSQL

spec:
  storage:
    storageClass: fast-ssd
    size: 50Gi

4. Aplique o CR Cluster (réplicas e failover automático)

Especifique no CR o número de instâncias/réplicas; o operator configura a replicação síncrona/assíncrona e, se o primário falhar, faz failover automático promovendo uma réplica. A aplicação deve se conectar ao Service '-rw' (read-write) criado pelo operator; esse serviço sempre aponta para o primário atual. Por isso o destino da conexão não muda durante o failover.

PostgreSQL

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: app-db
spec:
  instances: 3
  storage:
    storageClass: fast-ssd
    size: 50Gi
# the application connects to: app-db-rw

5. Grave os backups no S3 via CR

Os operators também gerenciam os backups de forma declarativa: você define no CR o destino principal do backup (object storage/S3) e o arquivamento do WAL. No CloudNativePG, os detalhes do S3 são informados com spec.backup.barmanObjectStore (obsoleto desde a 1.26; em novas implantações use o Barman Cloud Plugin e seu recurso ObjectStore); o arquivamento contínuo do WAL + base backups permitem a recuperação point-in-time. Referencie as credenciais a partir de um Secret do Kubernetes.

PostgreSQL

spec:
  backup:
    barmanObjectStore:
      destinationPath: s3://company-backup/app-db
      s3Credentials:
        accessKeyId:
          name: s3-creds
          key: ACCESS_KEY_ID
        secretAccessKey:
          name: s3-creds
          key: SECRET_ACCESS_KEY

6. CRs de backup agendado e de restore

Crie um CR Backup para um backup avulso e um CR ScheduledBackup para os agendados; faça base backups regulares com uma expressão cron. Os restores também são declarativos: você inicializa um novo Cluster a partir de um backup existente no object store com 'bootstrap.recovery'. Faça exercícios de restore regularmente; fazer backup não basta, teste a recuperação.

PostgreSQL

apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: nightly-backup
spec:
  schedule: "0 0 2 * * *"
  cluster:
    name: app-db