DBAtlas · Atlas de operaciones de bases de datos

Bases de datos en Kubernetes (operator)

Síntoma

Objetivo: ejecutar la base de datos en Kubernetes con un operator; en lugar de un StatefulSet a secas, usar el failover automático, el almacenamiento persistente y las funciones de backup que ofrece el operator.

1. Por qué un operator: un StatefulSet por sí solo no basta

Un StatefulSet simple le da pods con identidades estables y PVC, pero no la lógica de failover, configuración de la replicación, backup y actualizaciones. Un operator empaqueta este conocimiento operativo específico de la base de datos como un controller + un recurso personalizado (CRD). Usted escribe un CR llamado 'Cluster' y el operator gestiona por detrás el StatefulSet, el Service, el Secret y los jobs de backup. En producción, en general se prefiere ejecutar las bases de datos con un operator.

PostgreSQL

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

2. Elija e instale el operator

Elija un operator para su motor: CloudNativePG o Zalando postgres-operator para PostgreSQL; los operators de Percona (Percona Operator for MySQL / for MongoDB) son habituales para MySQL y MongoDB. Instale el operator con Helm o con un manifiesto bundle; este paso agrega al clúster los CRD y el pod del controller.

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. Planifique el almacenamiento (StorageClass / PVC)

El estado de la base de datos reside en los PVC; especifique en el CR la StorageClass que se usará. Elija una StorageClass que ofrezca almacenamiento en bloque de baja latencia, idealmente SSD de tipo local; los sistemas de archivos de red (NFS) no se recomiendan para la mayoría de las bases de datos. Defina correctamente desde el principio el tamaño del PVC y su capacidad de expansión (allowVolumeExpansion), porque reducirlo es difícil.

PostgreSQL

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

4. Aplique el CR Cluster (réplicas y failover automático)

Especifique en el CR el número de instancias/réplicas; el operator configura la replicación síncrona/asíncrona y, si el primario falla, realiza un failover automático promoviendo una réplica. La aplicación debe conectarse al Service '-rw' (lectura-escritura) que crea el operator; este servicio siempre apunta al primario actual. Por eso el destino de conexión no cambia durante el 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. Escriba los backups en S3 mediante el CR

Los operators también gestionan los backups de forma declarativa: usted define en el CR el destino principal del backup (almacenamiento de objetos/S3) y el archivado de WAL. En CloudNativePG, los datos de S3 se indican con spec.backup.barmanObjectStore (obsoleto desde 1.26; para nuevas implementaciones use el Barman Cloud Plugin y su recurso ObjectStore); el archivado continuo de WAL + los backups base permiten la recuperación a un punto en el tiempo. Haga referencia a las credenciales desde un Secret de 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. CR de backup programado y de restauración

Cree un CR Backup para un backup puntual y un CR ScheduledBackup para los programados; realice backups base periódicos con una expresión cron. Las restauraciones también son declarativas: se inicializa un nuevo Cluster a partir de un backup existente en el almacenamiento de objetos con 'bootstrap.recovery'. Realice simulacros de restauración con regularidad; hacer backups no basta, pruebe la recuperación.

PostgreSQL

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