DBAtlas · Atlas d'exploitation des bases de données

Bases de données sur Kubernetes (operator)

Symptôme

Objectif : exécuter la base sur Kubernetes avec un operator ; au lieu d'un simple StatefulSet, utiliser les fonctionnalités de failover automatique, de stockage persistant et de sauvegarde fournies par l'operator.

1. Pourquoi un operator : un StatefulSet seul ne suffit pas

Un simple StatefulSet fournit des pods à identité stable et des PVC, mais pas la logique de failover, de mise en place de la réplication, de sauvegarde et de montée de version. Un operator empaquette ce savoir opérationnel propre à la base sous forme de contrôleur + ressource personnalisée (CRD). Vous écrivez une CR appelée 'Cluster', et l'operator gère en coulisses le StatefulSet, le Service, le Secret et les jobs de sauvegarde. En production, l'exécution des bases avec un operator est généralement privilégiée.

PostgreSQL

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

2. Choisissez et installez l'operator

Choisissez un operator pour votre moteur : CloudNativePG ou Zalando postgres-operator pour PostgreSQL ; les operators Percona (Percona Operator for MySQL / for MongoDB) sont courants pour MySQL et MongoDB. Installez l'operator avec Helm ou un manifeste bundle ; cette étape ajoute les CRD et le pod contrôleur au 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. Planifiez le stockage (StorageClass / PVC)

L'état de la base réside dans les PVC ; indiquez dans la CR la StorageClass à utiliser. Choisissez une StorageClass offrant un stockage bloc à faible latence, idéalement de type SSD local ; les systèmes de fichiers réseau (NFS) sont déconseillés pour la plupart des bases. Définissez correctement dès le départ la taille des PVC et leur extensibilité (allowVolumeExpansion), car la réduction est difficile.

PostgreSQL

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

4. Appliquez la CR Cluster (réplicas et failover automatique)

Indiquez dans la CR le nombre d'instances/réplicas ; l'operator met en place la réplication synchrone/asynchrone et, en cas de défaillance du primaire, effectue un failover automatique en promouvant un réplica. L'application doit se connecter au Service '-rw' (lecture-écriture) créé par l'operator ; ce service pointe toujours vers le primaire courant. La cible de connexion ne change donc pas lors d'un 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. Écrivez les sauvegardes vers S3 via la CR

Les operators gèrent aussi les sauvegardes de manière déclarative : vous définissez dans la CR la destination principale des sauvegardes (stockage objet/S3) et l'archivage du WAL. Dans CloudNativePG, les informations S3 sont fournies avec spec.backup.barmanObjectStore (obsolète depuis 1.26 ; pour les nouveaux déploiements, utilisez le Barman Cloud Plugin et sa ressource ObjectStore) ; l'archivage continu du WAL + les sauvegardes de base permettent la restauration à un instant donné. Référencez les identifiants depuis un Secret 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 sauvegarde planifiée et de restauration

Créez une CR Backup pour une sauvegarde ponctuelle et une CR ScheduledBackup pour les sauvegardes planifiées ; prenez des sauvegardes de base régulières avec une expression cron. Les restaurations sont aussi déclaratives : vous initialisez un nouveau Cluster à partir d'une sauvegarde existante du stockage objet avec 'bootstrap.recovery'. Faites régulièrement des exercices de restauration ; prendre des sauvegardes ne suffit pas, testez la récupération.

PostgreSQL

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