PostgreSQL managé (CNPG)

Kontainers intègre l’opérateur CloudNativePG (CNPG) : vous décrivez votre base PostgreSQL en YAML, l’opérateur s’occupe du reste — réplication, bascule automatique, secrets de connexion, sauvegardes. Plus fiable et plus simple qu’un conteneur postgres à gérer soi-même.

Le manifest testé sur la plateforme, prêt à copier :

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: ma-base
spec:
  instances: 2                  # 1 primaire + 1 réplica avec bascule auto
  storage:
    size: 10Gi
    storageClass: ceph-block-rwo
  resources:
    requests:
      cpu: 250m
      memory: 512Mi
    limits:
      memory: 512Mi
  bootstrap:
    initdb:
      database: app
      owner: app

kubectl apply -f ma-base.yaml -n <namespace>
kubectl get clusters.postgresql.cnpg.io -n <namespace>
# NAME      INSTANCES   READY   STATUS                     PRIMARY
# ma-base   2           2       Cluster in healthy state   ma-base-1

Le cluster est prêt en une à deux minutes.

Se connecter depuis votre application

L’opérateur génère tout ce qu’il faut :

• trois Services : ma-base-rw (écriture, pointe le primaire), ma-base-ro (lecture, les réplicas), ma-base-r (lecture, toutes instances) ;
• un Secret ma-base-app contenant identifiants et chaînes de connexion prêtes à l’emploi.

Dans votre Deployment :

env:
  - name: DATABASE_URL
    valueFrom:
      secretKeyRef:
        name: ma-base-app
        key: uri            # postgresql://app:•••@ma-base-rw:5432/app

Pour explorer la base à la main :

kubectl run psql --rm -it --restart=Never -n <namespace> \
  --image=postgres:17-alpine \
  --env="PGPASSWORD=$(kubectl get secret ma-base-app -n <namespace> -o jsonpath='{.data.password}' | base64 -d)" \
  -- psql -h ma-base-rw -U app -d app

Sauvegardes vers votre stockage S3

Votre base est déjà couverte par la sauvegarde plateforme quotidienne (volumes inclus, rétention 10 jours, restauration via ticket). Pour aller plus loin — sauvegarde continue avec restauration à un instant précis (PITR), rétention sur mesure, restauration en autonomie — CNPG sait archiver vers votre propre stockage objet S3 : un bucket OVHcloud Object Storage ou Scaleway, par exemple.

Créez le secret d’accès au bucket, puis ajoutez la section backup au Cluster :

apiVersion: v1
kind: Secret
metadata:
  name: backup-s3-credentials
stringData:
  ACCESS_KEY_ID: "votre-access-key"
  SECRET_ACCESS_KEY: "votre-secret-key"
---
# À ajouter dans le spec du Cluster :
  backup:
    barmanObjectStore:
      destinationPath: s3://mon-bucket/ma-base
      endpointURL: https://s3.gra.io.cloud.ovh.net   # OVH — ou Scaleway :
                                                     # https://s3.fr-par.scw.cloud
      s3Credentials:
        accessKeyId:
          name: backup-s3-credentials
          key: ACCESS_KEY_ID
        secretAccessKey:
          name: backup-s3-credentials
          key: SECRET_ACCESS_KEY
    retentionPolicy: "30d"

L’archivage continu des WAL démarre aussitôt. Sauvegarde à la demande :

apiVersion: postgresql.cnpg.io/v1
kind: Backup
metadata:
  name: avant-migration-v2
spec:
  cluster:
    name: ma-base

Et en planifié (ici, tous les jours à 3h00) :

apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: ma-base-quotidien
spec:
  schedule: "0 0 3 * * *"        # format cron à 6 champs (secondes en premier)
  backupOwnerReference: self
  cluster:
    name: ma-base

kubectl get backups -n <namespace>

Note

La restauration depuis le bucket se fait en créant un nouveau Cluster avec bootstrap.recovery (y compris à un instant précis, grâce aux WAL archivés) — voir la documentation CNPG et, en cas de doute, le support vous accompagne.

Ce qu’il faut savoir

• Dimensionnement : chaque instance consomme ses requests (facturées) et son volume — instances: 2 = 2 × CPU/RAM et 2 × stockage. Pour du dev, instances: 1 est très bien ;
• La bascule automatique (avec instances: 2+) remplace le primaire défaillant en quelques secondes — votre application doit juste savoir se reconnecter ;
• Extensions : ajoutez-les au bootstrap, par exemple postInitApplicationSQL: ["CREATE EXTENSION IF NOT EXISTS vector;"] pour pgvector ;
• Version PostgreSQL : celle par défaut de l’opérateur, ou fixez-la avec imageName: ghcr.io/cloudnative-pg/postgresql:<version> ;
• Mises à jour mineures : gérées par l’opérateur au fil des rolling updates ;
• Le stockage compte dans vos quotas PVC (les volumes apparaissent dans kubectl get pvc).

Superviser

kubectl get clusters.postgresql.cnpg.io -n <namespace>   # état global
kubectl describe cluster ma-base -n <namespace>           # événements, bascules
kubectl logs ma-base-1 -n <namespace>                     # logs PostgreSQL

L’opérateur expose aussi des métriques Prometheus par instance, visibles dans votre monitoring.