Guide DBA - Interactions Kubernetes et PostgreSQL

Interactions Kubernetes et PostgreSQL — Guide DBA / SRE

Objectif du guide

Comprendre précisément comment Kubernetes et PostgreSQL interagissent : pod, PVC, service, DNS, opérateur, réplication, failover, sauvegarde, restauration, sécurité, observabilité et procédures d’exploitation. Ce guide est orienté entretien DBA, exploitation réelle et architecture de plateforme.

PostgreSQL

Moteur transactionnel, WAL, réplication, slots, rôles, backup physique et logique.

Kubernetes

Orchestration, pods, services, StatefulSet, PVC, scheduling, RBAC, secrets.

Opérateur

Automatisation du cycle de vie : création, failover, backup, restore, upgrade.

GitOps

Déclaration de l’état cible dans Git, réconciliation via ArgoCD ou Flux.

Le point clé

Kubernetes ne transforme pas PostgreSQL en base stateless. PostgreSQL reste un moteur stateful avec des fichiers de données, des journaux WAL, des contraintes d’intégrité, des transactions et une logique de réplication propre. Kubernetes apporte l’orchestration, le placement, le redémarrage, l’abstraction réseau, le stockage persistant et les primitives de sécurité. L’opérateur PostgreSQL fait le pont entre les deux mondes.

Erreur classique : croire qu’un simple Deployment PostgreSQL + un PVC suffit pour faire de la haute disponibilité. En production, il faut gérer le rôle primary/standby, la réplication, les WAL, le failover, les services applicatifs, les backups et les tests de restauration.

Carte mentale des interactions

Couche	Kubernetes apporte	PostgreSQL exige	Risque si mal compris
Exécution	Pod, container, probes, restart policy, scheduling.	Démarrage contrôlé, arrêt propre, cohérence fichiers.	Crash loop, recovery permanent, corruption logique ou indisponibilité.
Identité	StatefulSet, ordinal, DNS stable.	Instance primary ou standby identifiable.	Replica qui redémarre avec un mauvais rôle ou service mal routé.
Stockage	PV, PVC, StorageClass, CSI, snapshots.	Latence faible, fsync fiable, volume persistant, IOPS prévisibles.	Perte de données, lenteur massive, PVC bloqué, snapshot incohérent.
Réseau	Service, DNS, NetworkPolicy, endpoints.	Port 5432, réplication, client routing, split lecture/écriture.	Applications qui écrivent sur un standby, failover non transparent.
Cycle de vie	Rolling update, reconciliation, CRD, operator.	Upgrade maîtrisé, sauvegarde avant changement, compatibilité extension.	Upgrade moteur raté, downtime, incompatibilité de données.

Vue simple : du manifest à la base disponible

GitManifest Cluster PostgreSQL

→

GitOpsArgoCD / Flux applique l’état cible

→

OperatorCrée pods, PVC, services, secrets

→

PostgreSQLPrimary, standbys, WAL, replication

→

ApplicationsConnexion via services rw / ro

Résultat attendu pour un DBA

Savoir expliquer pourquoi PostgreSQL doit être traité comme un workload stateful.
Savoir choisir entre PostgreSQL hors Kubernetes, PostgreSQL dans Kubernetes via StatefulSet manuel, et PostgreSQL via opérateur.
Savoir lire les objets Kubernetes liés à PostgreSQL : pods, PVC, services, secrets, events, logs.
Savoir diagnostiquer les problèmes de failover, réplication, storage, DNS, permissions et backups.
Savoir défendre une architecture de production : backup testé, restore testé, services séparés, storage chiffré, sécurité réseau, observabilité.

Architecture d’ensemble : Kubernetes autour de PostgreSQL

Une architecture PostgreSQL Kubernetes sérieuse est composée de plusieurs couches. Le DBA doit savoir où commence Kubernetes, où commence PostgreSQL, et où l’opérateur intervient.

Diagramme en couches

ApplicationsServices métiers, API, batchs, workers, outils BI connectés aux services PostgreSQL.

Services KubernetesEntrées réseau stables : service read/write vers primary, service read-only vers replicas.

Pods PostgreSQLUn pod par instance PostgreSQL, avec rôle primary ou standby et volume dédié.

OperatorRéconciliation, bootstrap, failover, réplication, backup, restore, maintenance.

Storage KubernetesPV/PVC, StorageClass, CSI driver, snapshots, expansion, chiffrement.

InfrastructureNodes, zones, réseau, disques cloud/on-prem, IAM, sécurité, object storage.

Trois modèles de déploiement

Modèle	Description	Avantages	Limites
External DB	PostgreSQL est hors Kubernetes : VM, bare metal, RDS, Cloud SQL, Azure Database.	Simplicité pour les applications Kubernetes, maturité DBA classique.	Moins cloud-native, deux mondes d’exploitation séparés.
StatefulSet manuel	PostgreSQL est déployé avec StatefulSet, PVC, scripts et configuration maison.	Contrôle total, bon pour apprendre.	Failover, backup, upgrade et promotion à gérer soi-même.
Operator	PostgreSQL est décrit par une CRD ; l’opérateur orchestre le cycle de vie.	Production-friendly, automatisation, services, backup, failover.	Dépendance à l’opérateur, nécessité de comprendre la CRD et ses limites.

Exemple de choix d’architecture

Contexte	Choix recommandé	Justification
Application critique, équipe DBA classique forte, cloud managé disponible.	PostgreSQL managé hors cluster.	Réduction du risque opérationnel Kubernetes/stateful.
Plateforme interne, besoin GitOps, multi-environnements, maîtrise Kubernetes.	CloudNativePG ou opérateur équivalent.	Cycle de vie déclaratif, intégration Kubernetes, automatisation.
Formation, POC, expérimentation technique.	StatefulSet manuel ou CNPG minimal.	Permet de comprendre les objets Kubernetes et le comportement PostgreSQL.
Très forte volumétrie, latence extrême, contraintes disques spécifiques.	À arbitrer : bare metal, cloud DB ou operator avec storage haut de gamme.	Le stockage est souvent le facteur limitant.

Pattern de production : pour une base critique dans Kubernetes, privilégier une architecture opérateur, trois instances, anti-affinity, storage dédié, services read/write et read-only, backup continu WAL vers object storage, tests de restauration et supervision complète.

Cycle de vie : ce que Kubernetes peut faire, ce que PostgreSQL doit faire

Kubernetes sait créer, déplacer, redémarrer et exposer des pods. PostgreSQL sait maintenir la cohérence transactionnelle, écrire ses WAL, faire du crash recovery, streamer vers des replicas, archiver ses journaux et restaurer un état cohérent. L’opérateur coordonne ces deux logiques.

Cycle de vie d’un cluster PostgreSQL managé par opérateur

1. Déclaration Un manifest décrit le cluster : nombre d’instances, version PostgreSQL, stockage, ressources, sauvegarde et paramètres.

2. Bootstrap L’opérateur initialise le primary avec initdb, un backup existant ou une récupération PITR.

3. Création des replicas Les standbys sont provisionnés, connectés au primary, et commencent à recevoir les WAL.

4. Exposition réseau Des services Kubernetes exposent le rôle read/write et le rôle read-only aux applications.

5. Exploitation Backups, métriques, logs, probes, secrets, certificats et quotas sont suivis dans Kubernetes.

6. Incident Si le primary tombe, l’opérateur détecte l’état, promeut un standby et ajuste les services.

7. Maintenance Upgrade mineur, changement de paramètres, extension de PVC ou rotation de secrets sont opérés progressivement.

8. Restore Un nouveau cluster peut être reconstruit depuis un backup physique et des WAL archivés.

Responsabilités comparées

Action	Kubernetes	PostgreSQL	Operator
Redémarrer un pod	Oui	Crash recovery au redémarrage	Surveille et ordonne si nécessaire
Savoir qui est primary	Non nativement	Oui via rôle interne	Maintient les labels/services cohérents
Faire un failover PostgreSQL	Non seul	Promotion possible	Automatise la promotion et le routage
Créer un PVC	Oui	Consomme le filesystem	Déclare les volumes nécessaires
Archiver les WAL	Non	Produit les WAL	Configure le mécanisme de backup/archive
Restaurer à un instant précis	Non	Recovery via backup + WAL	Orchestre bootstrap recovery

Point d’entretien : Kubernetes ne comprend pas les transactions PostgreSQL. Il sait voir un pod vivant ou mort. Le rôle primary/standby, la réplication, les WAL et le point de recovery appartiennent au monde PostgreSQL.

StatefulSet, pods et identité PostgreSQL

PostgreSQL a besoin d’une identité stable et d’un stockage stable. C’est pour cette raison que les bases dans Kubernetes s’appuient sur des StatefulSets ou sur des objets créés par un opérateur qui produisent un comportement équivalent.

Pourquoi pas un Deployment simple ?

Besoin PostgreSQL	Deployment	StatefulSet / Operator
Nom stable par instance	Non garanti	Oui, ordinal stable ou identité opérateur
Volume stable par instance	Possible mais moins naturel	Oui, PVC attaché à l’instance
Ordre de création et suppression	Non orienté stateful	Oui
Réplication primary/standby	À coder soi-même	Orchestration plus adaptée
Failover DB	Non	Oui avec opérateur

Exemple pédagogique de StatefulSet PostgreSQL minimal

apiVersion: apps/v1
                kind: StatefulSet
                metadata:
                name: postgres-lab
                namespace: db-lab
                spec:
                serviceName: postgres-lab-headless
                replicas: 1
                selector:
                matchLabels:
                app: postgres-lab
                template:
                metadata:
                labels:
                app: postgres-lab
                spec:
                containers:
                - name: postgres
                image: postgres:16
                ports:
                - containerPort: 5432
                name: postgres
                env:
                - name: POSTGRES_DB
                value: appdb
                - name: POSTGRES_USER
                valueFrom:
                secretKeyRef:
                name: postgres-lab-secret
                key: username
                - name: POSTGRES_PASSWORD
                valueFrom:
                secretKeyRef:
                name: postgres-lab-secret
                key: password
                volumeMounts:
                - name: pgdata
                mountPath: /var/lib/postgresql/data
                volumeClaimTemplates:
                - metadata:
                name: pgdata
                spec:
                accessModes: ["ReadWriteOnce"]
                storageClassName: db-fast-ssd
                resources:
                requests:
                storage: 20Gi

Attention : cet exemple est volontairement pédagogique. Il ne fournit pas de HA PostgreSQL, pas de réplication, pas de backup, pas de failover et pas de gestion de version. Pour la production, utiliser un opérateur comme CloudNativePG ou une architecture contrôlée équivalente.

Commandes de diagnostic utiles

kubectl -n db-lab get statefulset
                kubectl -n db-lab get pods -o wide
                kubectl -n db-lab get pvc
                kubectl -n db-lab describe pod postgres-lab-0
                kubectl -n db-lab logs postgres-lab-0
                kubectl -n db-lab exec -it postgres-lab-0 -- psql -U appuser -d appdb

Ce qu’un DBA doit regarder dans un pod PostgreSQL

Le pod est-il en Running, Pending, CrashLoopBackOff ou Terminating ?
Le PVC est-il bien attaché au pod attendu ?
Le pod a-t-il changé de node récemment ?
Le conteneur PostgreSQL a-t-il redémarré ? Combien de fois ?
Les logs montrent-ils un crash recovery, une promotion, un refus de réplication ou une erreur disque ?

Stockage Kubernetes et exigences PostgreSQL

Le stockage est le sujet le plus critique. Kubernetes peut provisionner un volume, mais il ne garantit pas automatiquement que ce volume est adapté à PostgreSQL. Il faut comprendre les IOPS, la latence, le fsync, la politique de conservation, l’expansion, les snapshots et les zones.

Objets de stockage

Objet	Rôle	Impact PostgreSQL
`StorageClass`	Décrit le type de volume provisionné par le CSI.	Détermine performance, chiffrement, expansion, zone, politique de suppression.
`PersistentVolumeClaim`	Demande de stockage consommée par un pod.	Chaque instance PostgreSQL doit avoir son volume stable.
`PersistentVolume`	Volume réel fourni par l’infrastructure.	Contient `PGDATA`, donc les données critiques.
`VolumeSnapshot`	Copie ponctuelle d’un volume via CSI.	Utile mais doit être coordonné avec PostgreSQL pour cohérence applicative.
`reclaimPolicy`	Comportement après suppression du PVC/PV.	`Retain` est souvent préférable pour éviter perte accidentelle.

StorageClass recommandée pour PostgreSQL

apiVersion: storage.k8s.io/v1
                kind: StorageClass
                metadata:
                name: db-fast-ssd
                provisioner: ebs.csi.aws.com
                parameters:
                type: gp3
                encrypted: "true"
                reclaimPolicy: Retain
                allowVolumeExpansion: true
                volumeBindingMode: WaitForFirstConsumer

Pourquoi `WaitForFirstConsumer` ?

Cette option évite de créer un volume dans une mauvaise zone avant que le pod soit planifié. Pour PostgreSQL multi-zone, cela aide à aligner volume, pod et node. Sans cela, on peut avoir un PVC créé dans une zone où le pod ne peut pas tourner.

Check-list stockage PostgreSQL

Contrôle	Commande	Lecture
PVC liés	`kubectl -n db get pvc`	Tous les PVC doivent être `Bound`.
PV conservés	`kubectl get pv`	Vérifier `Retain` pour bases critiques.
Events storage	`kubectl -n db describe pvc <name>`	Repérer erreurs CSI, quota ou zone.
Espace disque PostgreSQL	`df -h` dans le pod	Ne jamais attendre 100% avant action.
WAL volumétrie	`SELECT * FROM pg_replication_slots;`	Un slot bloqué peut retenir trop de WAL.

Piège : un snapshot de volume n’est pas automatiquement équivalent à un backup PostgreSQL restaurable. Pour du PRA sérieux, il faut privilégier backup physique PostgreSQL + archivage WAL + test de restauration.

Réseau : services, DNS, routage primary/replica

Le réseau Kubernetes fournit des noms stables. Mais pour PostgreSQL, le routage doit respecter les rôles : les écritures doivent aller vers le primary, les lectures optionnelles peuvent aller vers les replicas. C’est l’une des interactions les plus importantes entre Kubernetes et PostgreSQL.

Services typiques

Service	Cible	Usage applicatif	Risque
`cluster-rw`	Primary uniquement	Connexions read/write, migrations, transactions.	Critique : doit suivre le primary après failover.
`cluster-ro`	Replicas disponibles	Lectures, reporting léger, requêtes analytiques contrôlées.	Replica lag, lectures obsolètes.
`cluster-r`	N’importe quelle instance	Lecture distribuée selon opérateur.	Peut toucher le primary si mal utilisé.
Headless service	Pods individuels	Découverte stable des instances.	À réserver aux besoins internes ou avancés.

Service ClusterIP minimal

apiVersion: v1
                kind: Service
                metadata:
                name: postgres-app-rw
                namespace: db-lab
                spec:
                type: ClusterIP
                selector:
                app: postgres-lab
                role: primary
                ports:
                - name: postgres
                port: 5432
                targetPort: 5432

NetworkPolicy : n’autoriser que l’application

apiVersion: networking.k8s.io/v1
                kind: NetworkPolicy
                metadata:
                name: allow-app-to-postgres
                namespace: db-prod
                spec:
                podSelector:
                matchLabels:
                cnpg.io/cluster: pg-prod
                policyTypes:
                - Ingress
                ingress:
                - from:
                - namespaceSelector:
                matchLabels:
                name: app-prod
                podSelector:
                matchLabels:
                app: backend-api
                ports:
                - protocol: TCP
                port: 5432

DNS à connaître

pg-prod-rw.db-prod.svc.cluster.local
                pg-prod-ro.db-prod.svc.cluster.local
                pg-prod-r.db-prod.svc.cluster.local
                postgres-lab-0.postgres-lab-headless.db-lab.svc.cluster.local

Bonne pratique : les applications ne doivent pas pointer directement vers les noms de pods PostgreSQL. Elles doivent utiliser les services stables prévus pour leur usage : read/write ou read-only.

CloudNativePG : opérateur PostgreSQL Kubernetes

CloudNativePG est un opérateur PostgreSQL très adapté à ce sujet, car il expose clairement les interactions entre Kubernetes et PostgreSQL : CRD Cluster, services, secrets, PVC, backup, failover et restauration.

Objets CNPG importants

Objet	Rôle	Ce que le DBA doit savoir
`Cluster`	Décrit un cluster PostgreSQL complet.	Nombre d’instances, version image, stockage, bootstrap, paramètres.
`Backup`	Déclenche ou représente un backup.	Vérifier statut, date, durée, destination.
`ScheduledBackup`	Planifie des backups récurrents.	S’assurer que la fréquence respecte le RPO.
`Pooler`	Gère un pool pgBouncer intégré selon configuration.	Utile pour réduire les connexions directes à PostgreSQL.
Services générés	`-rw`, `-ro`, `-r`.	Routage applicatif selon rôle PostgreSQL.

Manifest CNPG minimal mais sérieux

apiVersion: postgresql.cnpg.io/v1
                kind: Cluster
                metadata:
                name: pg-prod
                namespace: db-prod
                spec:
                instances: 3
                imageName: ghcr.io/cloudnative-pg/postgresql:16

                bootstrap:
                initdb:
                database: appdb
                owner: appuser
                secret:
                name: appuser-secret

                storage:
                size: 100Gi
                storageClass: db-fast-ssd

                resources:
                requests:
                cpu: "1"
                memory: 4Gi
                limits:
                cpu: "4"
                memory: 8Gi

                postgresql:
                parameters:
                max_connections: "300"
                shared_buffers: 2GB
                effective_cache_size: 6GB
                wal_level: replica
                hot_standby: "on"

                monitoring:
                enablePodMonitor: true

Commandes CNPG d’exploitation

kubectl -n db-prod get cluster
                kubectl -n db-prod describe cluster pg-prod
                kubectl -n db-prod get pods -l cnpg.io/cluster=pg-prod -o wide
                kubectl -n db-prod get svc | grep pg-prod
                kubectl -n db-prod get pvc | grep pg-prod
                kubectl -n db-prod get backup
                kubectl -n db-prod logs deployment/cnpg-controller-manager -c manager

Ce que CNPG automatise

Bootstrap

Initialisation depuis zéro, backup ou recovery.

Réplication

Primary/standby, services cohérents, suivi des rôles.

Failover

Promotion contrôlée d’un standby en cas de perte du primary.

Backup

Intégration backup physique et archivage WAL vers object storage.

Restore

Création d’un nouveau cluster depuis sauvegarde et WAL.

Monitoring

Exposition de métriques et intégration Prometheus.

À retenir : CNPG ne remplace pas PostgreSQL. Il automatise ce qu’un DBA ferait manuellement : initialiser, configurer, superviser, sauvegarder, promouvoir, restaurer et exposer correctement le cluster.

Manifests : construire un environnement PostgreSQL Kubernetes

Cette section donne une base de manifests que tu peux adapter dans un dépôt GitOps. L’idée est d’avoir une organisation claire : namespace, quotas, secrets, storage, cluster PostgreSQL, pooler et politiques réseau.

Arborescence Git recommandée

postgres-k8s-platform/
                clusters/
                dev/
                kustomization.yaml
                namespace.yaml
                quotas.yaml
                secrets.yaml
                cluster.yaml
                pooler.yaml
                networkpolicy.yaml
                prod/
                kustomization.yaml
                namespace.yaml
                quotas.yaml
                secrets-external.yaml
                cluster.yaml
                backup.yaml
                pooler.yaml
                networkpolicy.yaml
                base/
                cnpg-operator/
                storage/
                observability/
                runbooks/
                failover.md
                restore.md
                pvc-full.md
                upgrade.md

Namespace et quota

apiVersion: v1
                kind: Namespace
                metadata:
                name: db-prod
                labels:
                name: db-prod
                workload-type: database
                ---
                apiVersion: v1
                kind: ResourceQuota
                metadata:
                name: db-prod-quota
                namespace: db-prod
                spec:
                hard:
                requests.cpu: "12"
                requests.memory: 48Gi
                limits.cpu: "24"
                limits.memory: 96Gi
                requests.storage: 2Ti
                persistentvolumeclaims: "20"

Secret applicatif

apiVersion: v1
                kind: Secret
                metadata:
                name: appuser-secret
                namespace: db-prod
                type: kubernetes.io/basic-auth
                stringData:
                username: appuser
                password: change-me-in-vault

Pooler pgBouncer via CNPG

apiVersion: postgresql.cnpg.io/v1
                kind: Pooler
                metadata:
                name: pg-prod-pooler-rw
                namespace: db-prod
                spec:
                cluster:
                name: pg-prod
                instances: 2
                type: rw
                pgbouncer:
                poolMode: transaction
                parameters:
                max_client_conn: "1000"
                default_pool_size: "50"

Kustomization simple

apiVersion: kustomize.config.k8s.io/v1beta1
                kind: Kustomization
                resources:
                - namespace-and-quota.yaml
                - appuser-secret.yaml
                - cnpg-cluster-basic.yaml
                - cnpg-pooler.yaml
                - postgres-networkpolicy.yaml

Production : ne stocker aucun mot de passe réel en clair dans Git. Utiliser Vault, External Secrets, Sealed Secrets ou un mécanisme équivalent validé par l’équipe sécurité.

Réplication PostgreSQL dans Kubernetes

La réplication PostgreSQL repose sur les WAL. Le primary envoie les changements aux standbys via streaming replication. Kubernetes ne fait pas cette réplication ; il fournit le réseau, les pods et les services. L’opérateur configure et surveille.

Concepts PostgreSQL essentiels

Concept	Définition	Impact Kubernetes
WAL	Write-Ahead Log, journal transactionnel nécessaire à la réplication et au recovery.	Peut saturer le disque si archive ou replica bloqué.
Primary	Instance acceptant les écritures.	Le service `-rw` doit pointer dessus.
Standby	Replica recevant et rejouant les WAL.	Le service `-ro` peut pointer dessus.
Replication slot	Mécanisme retenant les WAL nécessaires à un consommateur.	Un slot inactif peut remplir le PVC du primary.
Replication lag	Retard entre primary et standby.	Les lectures `-ro` peuvent être obsolètes.

Requêtes SQL de diagnostic réplication

SELECT application_name,
                client_addr,
                state,
                sync_state,
                sent_lsn,
                write_lsn,
                flush_lsn,
                replay_lsn
                FROM pg_stat_replication;

                SELECT slot_name,
                slot_type,
                active,
                restart_lsn,
                wal_status
                FROM pg_replication_slots;

                SELECT now() - pg_last_xact_replay_timestamp() AS replica_lag;

Commandes Kubernetes corrélées

kubectl -n db-prod get pods -l cnpg.io/cluster=pg-prod -o wide
                kubectl -n db-prod get svc pg-prod-rw pg-prod-ro pg-prod-r
                kubectl -n db-prod describe cluster pg-prod
                kubectl -n db-prod logs pg-prod-1 | grep -i replication
                kubectl -n db-prod logs pg-prod-2 | grep -i wal

Replication lag : causes typiques

Cause	Symptôme	Action
Replica sous-dimensionné	CPU ou I/O saturés sur standby.	Augmenter ressources, vérifier requêtes longues.
Réseau instable	Déconnexions fréquentes, streaming interrompu.	Vérifier CNI, NetworkPolicy, DNS, node.
WAL généré trop vite	Retard croissant pendant batch massif.	Analyser batch, IOPS, checkpoint, archiving.
Slot inactif	Accumulation WAL sur primary.	Identifier slot, redémarrer consommateur ou supprimer si validé.
Replica bloqué en recovery	Logs recovery répétés.	Comparer timeline, WAL disponibles, restaurer replica si nécessaire.

Phrase d’entretien : “Kubernetes expose et déplace les instances, mais c’est PostgreSQL qui garantit la réplication via WAL. Je surveille donc à la fois les objets Kubernetes et les vues PostgreSQL comme pg_stat_replication.”

Backup : interaction entre WAL, object storage et Kubernetes

En environnement Kubernetes, le backup PostgreSQL sérieux ne doit pas dépendre seulement de la survie des PVC. Il faut externaliser les sauvegardes vers un object storage et archiver les WAL pour restaurer à un point précis.

Trois types de sauvegarde

Type	Exemple	Usage	Limite
Backup logique	`pg_dump`, `pg_dumpall`	Migration, extraction, petite base, objet spécifique.	Lent pour grosses bases, PITR non couvert seul.
Backup physique	Barman, pgBackRest, base backup.	Production, restauration complète, gros volumes.	Nécessite gestion WAL et compatibilité version.
Snapshot volume	CSI VolumeSnapshot	Complément infrastructure, rollback rapide selon contexte.	Pas suffisant seul sans cohérence PostgreSQL.

Architecture backup recommandée

Flux backup PostgreSQL Kubernetes

PrimaryGénère données et WAL

→

Backup sidecar / toolBase backup + WAL archive

→

Object storageS3 / MinIO / Azure Blob / GCS

→

Restore clusterBootstrap recovery + PITR

Backup CNPG avec plugin Barman Cloud — structure conceptuelle

apiVersion: postgresql.cnpg.io/v1
                kind: ScheduledBackup
                metadata:
                name: pg-prod-daily-backup
                namespace: db-prod
                spec:
                schedule: "0 0 2 * * *"
                backupOwnerReference: self
                cluster:
                name: pg-prod

Backup logique ponctuel via Kubernetes Job

apiVersion: batch/v1
                kind: Job
                metadata:
                name: pgdump-appdb
                namespace: db-prod
                spec:
                template:
                spec:
                restartPolicy: Never
                containers:
                - name: pgdump
                image: postgres:16
                env:
                - name: PGPASSWORD
                valueFrom:
                secretKeyRef:
                name: appuser-secret
                key: password
                command:
                - /bin/sh
                - -c
                - |
                pg_dump -h pg-prod-rw -U appuser -d appdb -Fc -f /backup/appdb.dump
                volumeMounts:
                - name: backup-volume
                mountPath: /backup
                volumes:
                - name: backup-volume
                persistentVolumeClaim:
                claimName: pgdump-backup-pvc

Contrôles minimum après backup

Le backup est-il terminé avec succès ?
Les WAL sont-ils archivés en continu ?
Le stockage objet est-il accessible depuis le cluster ?
Le backup est-il chiffré côté stockage ou applicatif ?
La rétention respecte-t-elle les contraintes métiers et réglementaires ?
Un restore réel a-t-il été testé récemment ?

Règle absolue : un backup non restauré au moins une fois est une hypothèse, pas une garantie.

Restore, PITR et reconstruction de cluster

La restauration est le vrai test de l’architecture. Dans Kubernetes, on restaure souvent dans un nouveau cluster PostgreSQL, avec de nouveaux pods et PVC, à partir d’un backup externe et des WAL archivés.

Types de restauration

Type	Objectif	Exemple
Restore complet	Reconstruire la base au dernier état sauvegardé.	Perte du cluster, corruption volume, migration environnement.
PITR	Restaurer juste avant une erreur humaine ou applicative.	Suppression accidentelle d’une table à 14:37.
Restore partiel logique	Restaurer une base, un schéma ou des objets depuis dump.	Récupération d’un environnement de test.
Clone	Créer un environnement depuis un backup de production.	Staging, analyse incident, recette migration.

Workflow PITR

1. Identifier l’incidentHeure précise, base concernée, action fautive, impact métier.

2. Choisir le point cibleDéfinir l’horodatage de récupération juste avant l’erreur.

3. Créer un cluster de restaurationNe pas écraser immédiatement la production si ce n’est pas validé.

4. Rejouer backup + WALLe moteur restaure le backup physique puis applique les WAL jusqu’au point cible.

5. Valider les donnéesContrôler tables, séquences, transactions, intégrité applicative.

6. Basculer ou extraireDécider entre remplacement complet, export partiel ou correction applicative.

Exemple conceptuel de bootstrap recovery CNPG

apiVersion: postgresql.cnpg.io/v1
                kind: Cluster
                metadata:
                name: pg-restore
                namespace: db-restore
                spec:
                instances: 3
                imageName: ghcr.io/cloudnative-pg/postgresql:16

                bootstrap:
                recovery:
                source: pg-prod-backup
                recoveryTarget:
                targetTime: "2026-06-01 14:35:00+00"

                externalClusters:
                - name: pg-prod-backup
                barmanObjectStore:
                destinationPath: s3://postgres-backups/pg-prod
                s3Credentials:
                accessKeyId:
                name: backup-s3-secret
                key: ACCESS_KEY_ID
                secretAccessKey:
                name: backup-s3-secret
                key: SECRET_ACCESS_KEY

                storage:
                size: 100Gi
                storageClass: db-fast-ssd

Validation post-restore

SELECT current_database();
                SELECT pg_is_in_recovery();
                SELECT now();
                SELECT count(*) FROM information_schema.tables WHERE table_schema = 'public';
                SELECT datname, numbackends FROM pg_stat_database ORDER BY datname;
                SELECT schemaname, relname, n_live_tup FROM pg_stat_user_tables ORDER BY n_live_tup DESC LIMIT 20;

Bonne pratique : toujours restaurer dans un namespace isolé comme db-restore ou db-drill, puis valider avant toute bascule applicative.

Sécurité : secrets, RBAC, TLS, chiffrement et accès

La sécurité PostgreSQL dans Kubernetes combine plusieurs niveaux : sécurité Kubernetes, sécurité réseau, sécurité PostgreSQL, secrets, certificats, chiffrement des volumes et contrôle des accès humains.

Niveaux de sécurité

Niveau	Contrôle	Exemple
Kubernetes API	RBAC, namespace isolation, audit logs.	Limiter qui peut lire les Secrets et exécuter dans les pods.
Secrets	Encryption at rest, Vault, External Secrets.	Ne pas stocker les mots de passe réels en clair dans Git.
Réseau	NetworkPolicy, TLS, services internes.	Autoriser uniquement les pods applicatifs nécessaires.
PostgreSQL	Rôles, privilèges, `pg_hba.conf`, audit.	Séparer owner, app user, migration user, read-only user.
Storage	Volumes chiffrés, snapshots protégés, rétention.	Chiffrer les volumes et l’object storage de backup.

RBAC minimal pour lecture DBA

apiVersion: rbac.authorization.k8s.io/v1
                kind: Role
                metadata:
                name: dba-readonly
                namespace: db-prod
                rules:
                - apiGroups: [""]
                resources: ["pods", "services", "endpoints", "persistentvolumeclaims", "events"]
                verbs: ["get", "list", "watch"]
                - apiGroups: ["postgresql.cnpg.io"]
                resources: ["clusters", "backups", "scheduledbackups", "poolers"]
                verbs: ["get", "list", "watch"]
                ---
                apiVersion: rbac.authorization.k8s.io/v1
                kind: RoleBinding
                metadata:
                name: dba-readonly-binding
                namespace: db-prod
                subjects:
                - kind: Group
                name: dba-team
                apiGroup: rbac.authorization.k8s.io
                roleRef:
                kind: Role
                name: dba-readonly
                apiGroup: rbac.authorization.k8s.io

Rôles PostgreSQL recommandés

CREATE ROLE app_owner NOLOGIN;
                CREATE ROLE app_rw LOGIN PASSWORD 'replace-with-secret';
                CREATE ROLE app_ro LOGIN PASSWORD 'replace-with-secret';
                CREATE ROLE app_migration LOGIN PASSWORD 'replace-with-secret';

                GRANT CONNECT ON DATABASE appdb TO app_rw, app_ro, app_migration;
                GRANT USAGE ON SCHEMA public TO app_rw, app_ro, app_migration;
                GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_rw;
                GRANT SELECT ON ALL TABLES IN SCHEMA public TO app_ro;
                GRANT CREATE, USAGE ON SCHEMA public TO app_migration;

Secrets : règles pratiques

Activer le chiffrement des Secrets Kubernetes dans etcd.
Limiter l’accès aux Secrets avec RBAC strict.
Préférer Vault ou External Secrets pour la production.
Ne jamais exposer le superuser PostgreSQL à l’application.
Prévoir une procédure de rotation des mots de passe.
Activer TLS client/serveur si le contexte l’exige.

Erreur dangereuse : donner aux développeurs le droit exec dans les pods PostgreSQL de production peut contourner plusieurs contrôles. Il faut distinguer observabilité, debug applicatif et accès DBA privilégié.

Observabilité : Kubernetes + PostgreSQL

Pour superviser PostgreSQL dans Kubernetes, il faut corréler deux familles de signaux : les signaux Kubernetes et les signaux PostgreSQL. Une alerte pod en erreur n’explique pas forcément la cause database, et une alerte réplication peut venir du réseau, du disque ou du moteur.

Métriques à surveiller

Domaine	Métriques	Alerte typique
Kubernetes pod	Restart count, readiness, CPU, mémoire, OOMKilled.	Pod PostgreSQL instable ou non prêt.
Storage	Utilisation disque, latence, IOPS, PVC pending.	Volume plein, latence élevée, CSI incident.
PostgreSQL connexions	`numbackends`, max_connections, pool usage.	Connexions saturées, besoin pgBouncer.
Réplication	Lag, streaming state, slots, WAL retained.	Replica en retard ou slot bloquant.
Transactions	Deadlocks, locks, long transactions, xact age.	Blocage applicatif, autovacuum empêché.
Backup	Dernier succès, durée, WAL archive errors.	RPO non tenu.

Requêtes SQL utiles

SELECT datname, numbackends, xact_commit, xact_rollback, deadlocks
                FROM pg_stat_database
                ORDER BY numbackends DESC;

                SELECT pid, usename, state, wait_event_type, wait_event, query_start, query
                FROM pg_stat_activity
                WHERE state <> 'idle'
                ORDER BY query_start;

                SELECT blocked_locks.pid AS blocked_pid,
                blocking_locks.pid AS blocking_pid,
                blocked_activity.query AS blocked_query,
                blocking_activity.query AS blocking_query
                FROM pg_catalog.pg_locks blocked_locks
                JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
                JOIN pg_catalog.pg_locks blocking_locks
                ON blocking_locks.locktype = blocked_locks.locktype
                AND blocking_locks.database IS NOT DISTINCT FROM blocked_locks.database
                AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
                AND blocking_locks.pid != blocked_locks.pid
                JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
                WHERE NOT blocked_locks.granted;

Commandes Kubernetes observabilité

kubectl -n db-prod get pods -o wide
                kubectl -n db-prod top pods
                kubectl -n db-prod describe cluster pg-prod
                kubectl -n db-prod describe pod pg-prod-1
                kubectl -n db-prod logs pg-prod-1 --previous
                kubectl -n db-prod get events --sort-by=.lastTimestamp

Alertes prioritaires

Primary down

Indisponibilité écriture ou failover en cours.

Replica lag

Lectures obsolètes et risque RPO.

WAL archive failed

PITR compromis si non corrigé.

PVC usage high

Risque arrêt brutal si volume plein.

Backup failed

RPO non respecté.

Too many connections

Application ou pooling mal dimensionné.

Incidents typiques et diagnostic croisé

Les incidents PostgreSQL dans Kubernetes sont souvent hybrides : un symptôme PostgreSQL peut avoir une cause Kubernetes, et un symptôme Kubernetes peut révéler une contrainte PostgreSQL. Le DBA doit savoir croiser les deux mondes.

Table de diagnostic rapide

Symptôme	Causes possibles	Contrôles	Action
Pod `Pending`	PVC non provisionné, quota, zone, node resources.	`describe pod`, `describe pvc`, events.	Corriger storage class, quota ou scheduling.
Pod `CrashLoopBackOff`	PGDATA incohérent, secret invalide, config cassée, disque plein.	Logs previous, events, volume usage.	Identifier cause avant suppression du volume.
Applications ne se connectent plus	Service mal routé, DNS, NetworkPolicy, failover en cours, max_connections.	Endpoints, service, logs app, pg_stat_activity.	Valider service rw, pooling, firewall réseau.
Replica lag massif	I/O saturé, batch massif, réseau, standby bloqué.	pg_stat_replication, pod metrics, logs standby.	Réduire charge, augmenter ressources, reconstruire replica si besoin.
Volume presque plein	WAL retenus, logs, table bloat, backup archive bloquée.	df, pg_replication_slots, pg_database_size.	Expansion PVC, corriger slots, vacuum, purge maîtrisée.
Backup échoue	Secret S3 invalide, réseau, bucket, permission, sidecar erreur.	Backup CR status, logs operator, object storage.	Corriger credentials et relancer backup test.

Runbook : volume plein

kubectl -n db-prod get pvc
                kubectl -n db-prod describe pvc pg-prod-1
                kubectl -n db-prod exec -it pg-prod-1 -- df -h
                kubectl -n db-prod exec -it pg-prod-1 -- du -h /var/lib/postgresql/data/pgdata/pg_wal | tail
                kubectl -n db-prod exec -it pg-prod-1 -- psql -U postgres -c "SELECT * FROM pg_replication_slots;"
                kubectl -n db-prod exec -it pg-prod-1 -- psql -U postgres -c "SELECT pg_size_pretty(pg_database_size(datname)), datname FROM pg_database ORDER BY pg_database_size(datname) DESC;"

Runbook : failover suspect

kubectl -n db-prod describe cluster pg-prod
                kubectl -n db-prod get pods -l cnpg.io/cluster=pg-prod -o wide
                kubectl -n db-prod get endpoints pg-prod-rw pg-prod-ro
                kubectl -n db-prod logs deployment/cnpg-controller-manager -c manager | tail -n 200
                kubectl -n db-prod exec -it pg-prod-1 -- psql -U postgres -c "SELECT pg_is_in_recovery();"

Règle d’incident : ne jamais supprimer un PVC PostgreSQL dans la panique. Avant toute action destructive, identifier le rôle de l’instance, l’état du backup, l’état des WAL et la stratégie de récupération.

GitOps : PostgreSQL déclaratif et garde-fous

En GitOps, l’état attendu du cluster PostgreSQL est stocké dans Git. ArgoCD ou Flux applique cet état au cluster. C’est très puissant, mais dangereux si les manifests de base de données ne sont pas protégés par une vraie revue.

Ce qui doit être dans Git

Élément	Dans Git ?	Remarque
Manifest Cluster CNPG	Oui	Version, instances, stockage, ressources, paramètres.
Namespace / quota / RBAC	Oui	Permet reproductibilité et revue sécurité.
NetworkPolicy	Oui	Contrôle des flux applicatifs.
Secrets réels	Non en clair	Utiliser Vault, External Secrets ou Sealed Secrets.
Backup policy	Oui	La fréquence et la rétention doivent être revues.
Actions d’incident	Pas toujours	Le break-glass peut être hors Git mais doit être tracé.

Application ArgoCD conceptuelle

apiVersion: argoproj.io/v1alpha1
                kind: Application
                metadata:
                name: postgres-prod
                namespace: argocd
                spec:
                project: databases
                source:
                repoURL: https://git.example.com/platform/postgres-k8s-platform.git
                targetRevision: main
                path: clusters/prod
                destination:
                server: https://kubernetes.default.svc
                namespace: db-prod
                syncPolicy:
                automated:
                prune: false
                selfHeal: true
                syncOptions:
                - CreateNamespace=true

Garde-fous indispensables

Pas de prune automatique agressif sur des ressources stateful sans validation.
Pas de modification de taille PVC, version majeure ou paramètres critiques sans procédure.
Validation obligatoire des PR touchant PostgreSQL production.
Diff lisible avant synchronisation ArgoCD/Flux.
Runbook rollback écrit avant upgrade.
Environnement staging iso-prod pour répéter les changements.

Point subtil : GitOps peut corriger un drift, mais il peut aussi réappliquer une mauvaise configuration. Pour les bases, la revue humaine reste indispensable sur les changements destructifs ou stateful.

Préparation entretien : questions, réponses et checklist

Cette section synthétise ce qu’il faut savoir dire en entretien pour montrer que tu maîtrises les interactions Kubernetes/PostgreSQL au niveau exploitation DBA/SRE.

Questions probables

Question	Réponse attendue
Pourquoi PostgreSQL dans Kubernetes est difficile ?	Parce que PostgreSQL est stateful : stockage persistant, WAL, réplication, rôle primary/standby, backup et recovery doivent être coordonnés avec l’orchestration Kubernetes.
Pourquoi utiliser un opérateur ?	Pour automatiser le cycle de vie PostgreSQL : bootstrap, replicas, failover, services, backups, restore, upgrades et monitoring.
Différence entre service `rw` et `ro` ?	`rw` pointe vers le primary pour les écritures ; `ro` pointe vers les replicas pour les lectures, avec attention au replica lag.
Un snapshot PVC suffit-il comme backup ?	Non. Il peut aider, mais le backup PostgreSQL sérieux repose sur backup physique cohérent, archivage WAL et test de restauration.
Que regarder si le pod PostgreSQL redémarre ?	Events Kubernetes, logs previous, PVC, OOMKilled, disque plein, configuration, état PostgreSQL et rôle de l’instance.
Comment réduire les connexions ?	Utiliser pgBouncer/pooler, dimensionner `max_connections`, limiter les connexions applicatives, surveiller pool usage.

Phrase de synthèse à utiliser

“Je vois PostgreSQL dans Kubernetes comme une interaction entre deux systèmes : Kubernetes orchestre les ressources, mais PostgreSQL reste responsable de la cohérence transactionnelle, des WAL, de la réplication et du recovery. Mon rôle DBA est de m’assurer que les services, PVC, secrets, backups, restores, failovers et métriques sont cohérents avec les contraintes réelles du moteur PostgreSQL.”

Checklist lab à préparer

Lab Kubernetes

k3d/kind ou cluster 3 nodes, StorageClass, metrics server, Prometheus stack.

CNPG

Cluster 3 instances, services rw/ro, monitoring activé.

Backup

MinIO/S3, scheduled backup, WAL archive, test restore.

Failover

Suppression du primary, observation promotion, validation service rw.

Sécurité

RBAC read-only, NetworkPolicy, secrets externes ou simulés.

Runbooks

Volume plein, replica lag, backup failed, restore PITR, upgrade mineur.

Mini-séquence de démonstration

kubectl -n db-prod get cluster pg-prod
                kubectl -n db-prod get pods -l cnpg.io/cluster=pg-prod -o wide
                kubectl -n db-prod get svc pg-prod-rw pg-prod-ro
                kubectl -n db-prod exec -it pg-prod-1 -- psql -U postgres -c "SELECT pg_is_in_recovery();"
                kubectl -n db-prod delete pod pg-prod-1
                kubectl -n db-prod get pods -w
                kubectl -n db-prod get endpoints pg-prod-rw
                kubectl -n db-prod get backup

Objectif entretien : ne pas seulement réciter Kubernetes ou PostgreSQL séparément. Il faut montrer que tu comprends les zones de friction : storage, failover, services, secrets, WAL, backups, restauration et observabilité.

Interactions Kubernetes et PostgreSQL — Guide DBA / SRE

Le point clé

Carte mentale des interactions

Résultat attendu pour un DBA

Architecture d’ensemble : Kubernetes autour de PostgreSQL

Trois modèles de déploiement

Exemple de choix d’architecture

Cycle de vie : ce que Kubernetes peut faire, ce que PostgreSQL doit faire

Cycle de vie d’un cluster PostgreSQL managé par opérateur

Responsabilités comparées

StatefulSet, pods et identité PostgreSQL

Pourquoi pas un Deployment simple ?

Exemple pédagogique de StatefulSet PostgreSQL minimal

Commandes de diagnostic utiles

Ce qu’un DBA doit regarder dans un pod PostgreSQL

Stockage Kubernetes et exigences PostgreSQL

Objets de stockage

StorageClass recommandée pour PostgreSQL

Pourquoi WaitForFirstConsumer ?

Check-list stockage PostgreSQL

Réseau : services, DNS, routage primary/replica

Services typiques

Service ClusterIP minimal

NetworkPolicy : n’autoriser que l’application

DNS à connaître

CloudNativePG : opérateur PostgreSQL Kubernetes

Objets CNPG importants

Manifest CNPG minimal mais sérieux

Commandes CNPG d’exploitation

Ce que CNPG automatise

Manifests : construire un environnement PostgreSQL Kubernetes

Arborescence Git recommandée

Namespace et quota

Secret applicatif

Pooler pgBouncer via CNPG

Kustomization simple

Réplication PostgreSQL dans Kubernetes

Concepts PostgreSQL essentiels

Requêtes SQL de diagnostic réplication

Commandes Kubernetes corrélées

Replication lag : causes typiques

Backup : interaction entre WAL, object storage et Kubernetes

Trois types de sauvegarde

Architecture backup recommandée

Backup CNPG avec plugin Barman Cloud — structure conceptuelle

Backup logique ponctuel via Kubernetes Job

Contrôles minimum après backup

Restore, PITR et reconstruction de cluster

Types de restauration

Workflow PITR

Exemple conceptuel de bootstrap recovery CNPG

Validation post-restore

Sécurité : secrets, RBAC, TLS, chiffrement et accès

Niveaux de sécurité

RBAC minimal pour lecture DBA

Rôles PostgreSQL recommandés

Secrets : règles pratiques

Observabilité : Kubernetes + PostgreSQL

Métriques à surveiller

Requêtes SQL utiles

Commandes Kubernetes observabilité

Alertes prioritaires

Incidents typiques et diagnostic croisé

Table de diagnostic rapide

Runbook : volume plein

Runbook : failover suspect

GitOps : PostgreSQL déclaratif et garde-fous

Ce qui doit être dans Git

Application ArgoCD conceptuelle

Garde-fous indispensables

Préparation entretien : questions, réponses et checklist

Questions probables

Phrase de synthèse à utiliser

Checklist lab à préparer

Mini-séquence de démonstration

Pourquoi `WaitForFirstConsumer` ?