Faire tourner une base PostgreSQL dans Kubernetes a longtemps été le contre-exemple cité par tout le monde : un état persistant, une réplication à orchestrer, un failover à ne pas rater, le tout dans un environnement conçu pour des workloads sans état. Le réflexe historique, c'était le Helm chart à base de StatefulSet plus un sidecar Patroni qui cause à un etcd planqué quelque part. Ça marche, mais ça empile deux couches de consensus distribué qui ne se connaissent pas, et le jour de l'incident on débugue Patroni, etcd et Kubernetes en même temps.
CloudNativePG prend le problème par l'autre bout. C'est un operator développé par EDB, donné à la CNCF en 2025 où il est passé projet Sandbox, et sa thèse tient en une phrase : si vous avez déjà un cluster Kubernetes qui marche, vous avez déjà votre couche de consensus, inutile d'en ajouter une seconde. Pas de StatefulSet, pas de Patroni, pas d'etcd dédié à la base. L'operator gère lui-même les pods, les volumes, la réplication et la bascule, et il stocke l'état du cluster Postgres là où Kubernetes stocke tout le reste : dans l'API server.
Un CRD Cluster, pas un StatefulSet
On déclare une base avec une ressource personnalisée Cluster, et c'est tout. Pas de StatefulSet généré derrière : l'operator gère directement les pods et leurs PersistentVolumeClaim, parce que la sémantique d'un StatefulSet (ordre de démarrage figé, scaling séquentiel) colle mal à un cluster de base de données où le primary peut changer à tout instant.
En pratique, un manifeste minimal donne ça :
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
name: pg-prod
spec:
instances: 3
storage:
size: 100Gi
storageClass: longhorn
Trois instances : un primary et deux replicas en réplication physique streaming, montés et raccordés automatiquement. L'operator crée des Services distincts pour séparer les accès, un endpoint qui pointe toujours le primary en écriture, un autre qui route vers les replicas en lecture seule. L'application ne se soucie pas de savoir quel pod est primary à un instant donné, elle parle au bon Service.
Le reste se gère de la même façon, en déclaratif. Utilisateur applicatif, base applicative, identifiants superuser, paramètres postgresql.conf, tout vit dans le spec du Cluster et l'operator réconcilie. C'est la logique GitOps appliquée à une base : l'état désiré dans Git, l'operator qui converge vers cet état.
Le failover passe par l'API server, pas par etcd
C'est le point qui change tout par rapport à Patroni. Dans une stack PostgreSQL haute disponibilité avec Patroni, etcd et HAProxy, le DCS (Distributed Configuration Store) est un etcd externe que vous installez, dimensionnez et supervisez vous-même. C'est lui qui détient la vérité sur qui est leader, et Patroni s'appuie dessus pour décider d'une bascule. Vous opérez donc deux clusters à quorum distincts : etcd et, si vous êtes sur Kubernetes, celui du control plane.
CloudNativePG supprime cette couche. L'instance manager, le processus que l'operator injecte dans chaque pod Postgres comme PID 1, surveille la santé locale et remonte l'état via l'API Kubernetes. Quand le primary tombe, l'operator détecte la perte, choisit le replica le plus à jour et le promeut, puis raccroche les autres replicas sur le nouveau primary. Le rôle de DCS est tenu par l'API server et son etcd, celui qui fait déjà tourner tout le cluster. Vous avez un seul système de consensus à opérer, pas deux.
Pour les exigences de durabilité forte, l'operator gère la réplication synchrone et un failover à quorum, qui refuse de promouvoir un replica n'ayant pas confirmé les dernières transactions. Le réglage est le même arbitrage que partout en HA Postgres : la réplication synchrone protège contre la perte de transactions au prix d'une latence d'écriture, l'asynchrone fait l'inverse. CloudNativePG ne tranche pas à votre place, il rend les deux modes déclaratifs.
Backups Barman Cloud, archivage WAL et PITR
Une base sans sauvegarde restaurable n'est pas en production, c'est une démo. CloudNativePG s'appuie sur Barman Cloud pour pousser les backups de base et archiver les WAL en continu vers un object store : Amazon S3, tout service compatible S3, Azure Blob, Google Cloud Storage. La combinaison backup de base plus archivage WAL continu, c'est ce qui ouvre le PITR (Point-In-Time Recovery) : restaurer la base à un instant précis, juste avant un DROP TABLE malheureux ou une migration ratée.
Côté déclaratif, on définit un object store et une ScheduledBackup, et l'operator gère l'archivage des WAL via barman-cloud-wal-archive, les backups planifiés et la rétention sur une fenêtre de récupération configurable. La restauration se fait en créant un nouveau Cluster qui se reconstruit (bootstrap) depuis l'object store, à la dernière transaction ou à un point dans le temps.
Un piège de version à connaître, parce qu'il vous tombera dessus si vous l'ignorez : le support Barman Cloud intégré (in-tree) est retiré dans CloudNativePG 1.30. La voie à venir, c'est le plugin Barman Cloud via l'interface CNPG-I. Si vous démarrez aujourd'hui, partez directement sur le plugin, ne câblez pas votre dispositif de sauvegarde sur un mécanisme en fin de vie. Pour la philosophie générale, restauration testée et RPO mesuré plutôt que déclaré : un failover ou un PITR jamais déclenché pour de vrai ne prouve rien, tant qu'on ne l'a pas joué en condition réelle on ignore s'il tient.
Rolling updates et montées de version
L'operator gère les mises à jour sans coupure franche. Pour une montée de version mineure de Postgres ou une nouvelle image, il procède par rolling update en commençant par les replicas : il détruit un pod replica, le recrée sur la nouvelle image en réutilisant le volume sous-jacent, vérifie, passe au suivant, puis bascule le primary en dernier via un switchover contrôlé. La fenêtre d'indisponibilité en écriture se réduit au temps d'une promotion.
Le major upgrade, longtemps le point noir, est désormais déclaratif depuis la version 1.26. L'operator fait un major upgrade in-place hors ligne via pg_upgrade --link : on change le tag de version majeure dans imageName (de 16 à 17 par exemple), l'operator arrête les pods, lance un job pg_upgrade sur le volume du primary, redémarre, puis re-clone les replicas depuis le primary mis à jour. Deux contraintes fermes : c'est une opération hors ligne (la base est indisponible le temps du pg_upgrade), et les images de départ et d'arrivée doivent reposer sur la même distribution de base. On ne saute pas de bullseye à bookworm dans un major upgrade.
Pooling, métriques et stockage : les détails qui font la prod
Le pooling de connexions se déclare avec une ressource Pooler, qui déploie des pods PgBouncer distincts devant le Service de la base. Le cycle de vie du Pooler est indépendant de celui du Cluster : supprimer la base ne supprime pas ses poolers. PgBouncer reste PgBouncer, avec ses modes session, transaction et statement, et les arbitrages habituels que détaille un guide dédié au pooling de connexions PostgreSQL avec PgBouncer. Le mode transaction casse les fonctionnalités liées à la session (prepared statements côté serveur, advisory locks), à choisir en connaissance de cause.
Côté observabilité, l'instance manager expose un endpoint Prometheus sur le port 9187, compatible avec la syntaxe de postgres_exporter, et accepte des requêtes de métriques personnalisées définies en SQL via ConfigMap ou Secret. Vous branchez ça sur votre stack existante et vous surveillez réplication, lag, état du backup et santé des pods comme le reste.
Reste le sujet qui décide de tout : le stockage. CloudNativePG s'appuie sur des PVC, donc sur votre CSI. Et Postgres, comme etcd, paie cash la latence disque, parce que chaque commit attend un fsync durable. Le datastore d'une base de prod exige un backend rapide et à faible latence : du stockage distribué Longhorn pour Kubernetes correctement dimensionné, ou du local NVMe avec une stratégie de réplication assumée au niveau Postgres. Coller une base sur un NFS lent ou un stockage réseau à latence imprévisible, c'est se garantir des incidents qui ressemblent à un problème de base alors que c'est le disque. Le stockage réglé, le reste du tuning passe par le spec du Cluster, mais les principes d'optimisation avancée de PostgreSQL restent identiques : ce n'est pas parce que la base tourne dans Kubernetes que les fondamentaux changent. La gestion des secrets (identifiants, certificats) se branche proprement sur un dispositif type External Secrets Operator pour Kubernetes, plutôt que des Secrets en clair dans Git.
Verdict ops
Le choix n'a rien d'idéologique, il dépend de l'endroit où vit votre infra. Si votre plateforme est déjà Kubernetes, que vos équipes pensent en CRD et en GitOps, CloudNativePG est le bon outil : une seule couche de consensus, une seule API, un cycle de vie cohérent avec le reste du cluster, et un operator qui gère le sale boulot (failover, backup, upgrade) en déclaratif. Empiler Patroni et un etcd dédié dans ce contexte, c'est ajouter de la complexité que l'API server rend inutile.
Si vous tournez sur des VM ou du bare metal, sans Kubernetes ou avec un Kubernetes que vous ne voulez pas mettre dans le chemin critique de votre base, Patroni reste la référence. Il ne traîne pas la dépendance à tout un control plane et il fait exactement une chose, l'orchestration HA de Postgres, depuis longtemps et bien. Monter Kubernetes uniquement pour y poser une base via CloudNativePG serait une inversion des priorités.
La vraie erreur n'est ni l'un ni l'autre outil : c'est de faire tourner une base de prod dans Kubernetes sans backend de stockage adapté, sans restauration testée, et sans supervision de la réplication. CloudNativePG vous donne les bons primitifs ; il ne vous dispense pas de les opérer correctement.
Quand un cluster Kubernetes héberge des bases critiques sans dispositif de sauvegarde restaurable ni stockage dimensionné pour la latence, on reprend la stack data à la base : choix de l'operator, classe de stockage, archivage WAL, PITR éprouvé, alerting sur le lag de réplication. C'est ce qu'on fait au quotidien sur les infrastructures qu'on opère. Si votre Postgres tourne dans Kubernetes sans que personne n'ait jamais éprouvé son failover ni sa restauration, on peut auditer votre stack et la mettre au niveau.
Sources
- CloudNativePG, documentation officielle : référence de l'operator, dépendance à l'API server Kubernetes comme couche de consensus, absence de Patroni et d'etcd externe.
- CloudNativePG, Operator Capability Levels : CRD Cluster, Pooler, Backup, ScheduledBackup, gestion directe des pods et PVC, rolling updates et failover à quorum.
- CloudNativePG, PostgreSQL upgrades : major upgrade in-place déclaratif via pg_upgrade depuis la 1.26, contraintes hors ligne et même distribution de base.
- CloudNativePG, Connection Pooling : ressource Pooler, pods PgBouncer distincts, modes de pooling et cycle de vie indépendant du Cluster.
- CloudNativePG, Backup and Recovery : archivage WAL continu et backups de base Barman Cloud vers S3, Azure et GCS, fenêtre de rétention.
- plugin-barman-cloud, dépôt GitHub : plugin Barman Cloud via CNPG-I, retrait du support in-tree en 1.30.
