CloudNativePG Operator¶
PostgreSQL Operator and Barman Backup Plugin
CloudNativePG provides PostgreSQL cluster lifecycle management with automated backups, high availability, and self-healing capabilities.
Overview¶
The CNPG deployment provides:
CloudNativePG Operator (v1.27.1) - PostgreSQL cluster orchestration
Barman Cloud Plugin (v0.2.0) - S3-compatible backup and recovery
ArgoCD GitOps Management - Deployed from dp-infra/cnpg
CDK8S Infrastructure as Code - TypeScript-based manifest generation
Key Features¶
PostgreSQL Cluster Management¶
Automated cluster provisioning and lifecycle management
Self-healing and automatic failover
Connection pooling with PgBouncer
Monitoring integration (PodMonitor, Grafana dashboards)
Backup and Recovery¶
Automated backups to S3-compatible storage (Hetzner Object Storage)
Point-in-time recovery (PITR)
WAL archiving and streaming replication
Backup encryption and retention policies
High Availability¶
Multi-instance PostgreSQL clusters with automatic failover
Rolling updates with zero downtime
Pod disruption budgets and anti-affinity rules
Storage replication via Longhorn (1 replica for database workloads)
Quick Start¶
Check Operator Status¶
# Check CNPG operator pods
kubectl get pods -n cnpg-system
# Check ArgoCD sync status
kubectl get application cnpg-app-* -n argocd
List PostgreSQL Clusters¶
# List all CNPG clusters
kubectl get clusters.postgresql.cnpg.io -A
# Check specific cluster details
kubectl describe cluster <cluster-name> -n <namespace>
Create a PostgreSQL Cluster¶
See How-To: Create PostgreSQL Cluster for detailed instructions.
Architecture¶
The CNPG deployment uses CDK8S (TypeScript) to generate Kubernetes manifests deployed via ArgoCD:
dp-infra/cnpg/
├── charts/constructs/
│ ├── namespace.ts # cnpg-system namespace (sync-wave 0)
│ ├── operator.ts # CNPG operator HelmChart (sync-wave 1)
│ └── barman-plugin.ts # Barman plugin HelmChart (sync-wave 2)
├── config.yaml # Operator and plugin versions
└── manifests/
└── cnpg.k8s.yaml # Generated manifests (committed to git)
ArgoCD automatically syncs changes from the dp-infra repository to the cluster.
Storage Strategy¶
PostgreSQL databases use the longhorn-redundant-app storage class (1 replica):
Rationale: PostgreSQL clusters with N≥2 instances provide built-in replication. Adding storage-level replication would waste resources:
3 PostgreSQL instances × 1 storage replica = 3 copies of data ✅
3 PostgreSQL instances × 2 storage replicas = 6 copies of data ❌ (wasteful)
See Storage Tiers Explanation for details.
Common Use Cases¶
Application Databases - PostgreSQL clusters for web applications (e.g., GitLab BDA)
Microservices Data - Isolated databases per microservice
Development/Testing - Ephemeral clusters for development environments
Data Analytics - PostgreSQL for OLAP workloads