Présentation¶

CloudNativePG est un opérateur open-source qui permet de gérer des instances PostgreSQL dans Kubernetes.

Cet opérateur définit une nouvelle ressource dans Kubernetes appelée Cluster.

C’est en quelque sorte une extension de Kubernetes.

Cette ressource représente en fait un cluster PostgreSQL avec au minimum un primaire et autant de secondaires que ce qui est configuré.

Sauvegardes¶

CloudNativePG intègre une fonctionnalité de sauvegarde avancée permettant la restauration à un point dans le temps (PITR). Cette solution s’appuie sur l’outil Barman Cloud pour la gestion des sauvegardes. Le système utilise le package barman-cli-cloud, qui est embarqué dans l’image ghcr.io/cloudnative-pg/postgresql:X.X fournie par CloudNativePG. Cette image sert de base pour la création des instances PostgreSQL gérées par l’opérateur.

Warning

À partir de la version 1.26 de CloudNativePG, la prise en charge native de Barman Cloud sera dépréciée. Pour les versions suivantes, il sera utilisable en tant que plugin via le système d’interface CNPG.”

Monitoring¶

CloudNativePG fournit un ensemble de métriques prédéfinies pour le monitoring de PostgreSQL, accessibles via un exporter Prometheus sur le port 9187. Les métriques liées à PostgreSQL fournissent entre autres les informations suivantes :

Informations sur les fichiers WAL
Statut des réplicas synchrones
Informations sur les sauvegardes
État du cluster (mode réplica, fencing, etc.)

Les métriques sont collectées de manière atomique (une transaction par requête), avec le rôle pg_monitor, et exécutées en tant qu’utilisateur postgres.

Replication¶

CloudNativePG utilise la réplication physique native de PostgreSQL pour la haute disponibilité. Celle-ci est gérée de manière déclarative dans Kubernetes, basée sur le nombre d’instances spécifié dans la ressource Cluster.

Bascule automatique¶

Le processus de bascule automatique est déclenché en cas d’erreurs inattendues sur le primaire pendant une durée de dépassant celle défini par le paramètre .spec.failoverDelay (par défaut 0 secondes). Le processus de failover se déroule en deux grandes étapes :

Le contrôleur marque le TargetPrimary comme “pending”. Ce changement d’état force l’arrêt du Pod primaire, et s’assure que les walreceiver sur les réplicas cessent leur activité. Le cluster sera alors signalé comme étant en phase de failover (“Failing over”).

Une fois tous les walreceiver arrêtés, une élection de leader aura lieu et un nouveau primaire sera désigné parmi les instances disponibles. L’instance choisie entamera sa promotion au statut de primaire et le cluster reprendra son fonctionnement normal. Pendant ce temps, l’ancien Pod primaire redémarrera, détectera qu’il n’est plus le primaire, et se raccrochera au cluster en tant que nœud réplica.

Logs¶

Toutes les ressources créées et contrôlées par CloudNativePG enregistrent leurs logs en sortie standard au format JSON. Pour récupérer les logs, il faut utiliser la commande kubectl logs. Pour améliorer la lisibilité des logs JSON, il est conseillé d’utiliser d’ajouter | jq -C à la commande kubectl logs.