---
title: "PostgreSQL managé (CNPG)"
description: "Créer un cluster PostgreSQL haute disponibilité sur Kontainers avec l'opérateur CloudNativePG : connexion, réplicas, sauvegardes vers votre stockage S3."
source_url:
  html: https://docs.blackswift.cloud/deployer/postgresql-manage/
  md: https://docs.blackswift.cloud/deployer/postgresql-manage.md
---

# PostgreSQL managé (CNPG)

> Créer un cluster PostgreSQL haute disponibilité sur Kontainers avec l'opérateur CloudNativePG : connexion, réplicas, sauvegardes vers votre stockage S3.

Kontainers intègre l'opérateur [CloudNativePG](https://cloudnative-pg.io) (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 :

```yaml
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
```

```bash
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 :

```yaml
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 :

```bash
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](https://docs.blackswift.cloud/operer/sauvegardes-et-restauration.md)
(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 :

```yaml
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 :

```yaml
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) :

```yaml
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
```

```bash
kubectl get backups -n <namespace>
```

<Aside type="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](https://cloudnative-pg.io/documentation/current/backup/)
et, en cas de doute, [le support vous accompagne](https://docs.blackswift.cloud/depanner/contacter-le-support.md).
</Aside>

## Ce qu'il faut savoir

- **Dimensionnement** : chaque instance consomme ses requests
  ([facturées](https://docs.blackswift.cloud/reference/facturation.md)) 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](https://docs.blackswift.cloud/reference/quotas-et-limites.md)
  (les volumes apparaissent dans `kubectl get pvc`).

## Superviser

```bash
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](https://docs.blackswift.cloud/operer/acceder-au-monitoring.md).