Warum PostgreSQL auf Kubernetes?

Datenbanken auf Kubernetes zu betreiben gilt lange als Anti-Pattern – heute ist es dank Kubernetes Operators produktionsreif. Ein Operator kapselt das Wissen eines Datenbankadministrators als Code: Er übernimmt Backup, Failover, Monitoring, Upgrades und Skalierung automatisch.

Für PostgreSQL haben sich zwei Operators als de-facto Standard etabliert: CloudNativePG (von EDB, dem größten PostgreSQL-Contributor) und der Zalando PostgreSQL Operator (von Zalando entwickelt, Open Source). Beide sind produktionsreif, werden aktiv entwickelt und unterscheiden sich in Architektur, Features und Betriebsphilosophie.

CloudNativePG: Der CNCF-Sandbox-Operator

CloudNativePG wurde 2022 von EDB unter Apache 2.0 lizenziert und 2023 in die CNCF Sandbox aufgenommen. Es ist der aktuell am schnellsten wachsende PostgreSQL-Operator – und setzt auf einen direkten Streaming-Replication-Ansatz ohne externe Dependency auf Patroni.

Installation

# CloudNativePG via kubectl
kubectl apply -f \
  https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/main/releases/cnpg-latest.yaml

# Oder via Helm
helm repo add cnpg https://cloudnative-pg.github.io/charts
helm install cnpg cnpg/cloudnative-pg -n cnpg-system --create-namespace

Cluster-Konfiguration

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: postgres-cluster
  namespace: database
spec:
  instances: 3  # 1 Primary + 2 Standby

  postgresql:
    parameters:
      max_connections: "200"
      shared_buffers: "256MB"

  storage:
    size: 20Gi
    storageClass: longhorn

  backup:
    retentionPolicy: "30d"
    barmanObjectStore:
      destinationPath: "s3://backups.example.com/postgres"
      serverName: postgres-cluster
      s3Credentials:
        accessKeyId:
          name: backup-creds
          key: ACCESS_KEY_ID
        secretAccessKey:
          name: backup-creds
          key: SECRET_ACCESS_KEY

Key Features von CloudNativePG

  • Direkte Streaming Replication ohne externe Tools wie Patroni oder etcd
  • Integriertes Backup via Barman (unterstützt S3, Azure Blob, GCS)
  • In-Place Major Upgrades (experimentell ab v1.22)
  • Declarative Connection Pooling via PgBouncer als Sidecar
  • PITR (Point-in-Time Recovery) mit WAL-Archivierung
  • Prometheus Metrics out-of-the-box

Zalando PostgreSQL Operator: Bewährt in Production

Der Zalando PostgreSQL Operator läuft seit 2016 in Produktion bei Zalando – auf über 300 Datenbankcluster. Er basiert auf Patroni für High Availability und Spilo als PostgreSQL-Image. Dies bringt Battle-Tested-Reife, aber auch eine höhere Komplexität mit sich.

Installation

# Via Helm
helm repo add postgres-operator-charts \
  https://opensource.zalando.com/postgres-operator/charts/postgres-operator
helm install postgres-operator postgres-operator-charts/postgres-operator \
  -n postgres-operator --create-namespace

Cluster-Konfiguration

apiVersion: "acid.zalan.do/v1"
kind: postgresql
metadata:
  name: app-postgres
  namespace: database
spec:
  teamId: "myteam"
  volume:
    size: 20Gi
    storageClass: longhorn
  numberOfInstances: 3
  users:
    appuser: []
  databases:
    appdb: appuser
  postgresql:
    version: "16"
  resources:
    requests:
      cpu: 100m
      memory: 250Mi
    limits:
      cpu: 500m
      memory: 500Mi

Key Features von Zalando PostgreSQL Operator

  • Patroni-basiertes HA: Battle-tested Failover in <30 Sekunden
  • Automatisches User/DB-Management: Deklarative Datenbanknutzer
  • Spilo-Images: Enthält PostgreSQL + Patroni + WAL-E/WAL-G
  • Pod Anti-Affinity: Automatische Verteilung auf Nodes
  • Clone via S3: Schnelles Erstellen von Staging-Clustern aus Backups
  • Logical Backups via pg_dump (täglich)

Direktvergleich: CloudNativePG vs Zalando Operator

Kriterium CloudNativePG Zalando Operator
HA-Mechanismus Native Streaming Replication Patroni + etcd/DCS
Komplexität Geringer Höher
Backup-Integration Barman (S3/Azure/GCS) WAL-G + Logical
PITR ✅ Vollständig ✅ Via WAL-G
Major Upgrades ⚠️ Experimentell ✅ Via pg_upgrade
Connection Pooling ✅ PgBouncer Sidecar ❌ Extern
Metrics ✅ Prometheus built-in ✅ Via Sidecar
CNCF Mitglied ✅ Sandbox ❌
Lizenz Apache 2.0 MIT
Primäre Sprache Go Python/Go
Externe Dependencies Minimal Patroni, etcd
Enterprise Support EDB (kostenpflichtig) Community only

PITR: Point-in-Time Recovery

Für Produktionsdatenbanken ist PITR essentiell. CloudNativePG hat hier die elegantere Implementierung:

# CloudNativePG: Recovery auf bestimmten Zeitpunkt
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: postgres-recovery
spec:
  instances: 1
  bootstrap:
    recovery:
      backup:
        name: postgres-cluster-backup
      recoveryTarget:
        targetTime: "2026-09-09 02:00:00"
  storage:
    size: 20Gi

Monitoring und Alerting

Beide Operators bieten Prometheus-Metriken. CloudNativePG liefert sie direkt im Primary-Container:

# ServiceMonitor für CloudNativePG
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: cnpg-metrics
spec:
  selector:
    matchLabels:
      cnpg.io/cluster: postgres-cluster
  endpoints:
    - port: metrics
      interval: 30s

Wichtige Metriken:

  • cnpg_pg_replication_lag – Replikationsverzögerung der Standbys
  • cnpg_backends_waiting_total – Wartende Datenbankverbindungen
  • cnpg_pg_database_size_bytes – Datenbankgröße

Wann CloudNativePG, wann Zalando Operator?

CloudNativePG ist die bessere Wahl wenn:

  • Ein moderner, wartungsarmer Betrieb gewünscht wird
  • CNCF-Alignment und Long-Term-Support wichtig sind
  • Connection Pooling über den Operator verwaltet werden soll
  • Einfache, deklarative Cluster-Konfiguration bevorzugt wird
  • Das Team noch keine Patroni-Erfahrung hat

Zalando Operator ist besser wenn:

  • Sehr große Cluster (100+ Datenbanken) verwaltet werden
  • Automatisches User- und Datenbankmanagement benötigt wird
  • Bestehendes Spilo-Know-how vorhanden ist
  • Zalando-spezifische Features wie Team-Integration genutzt werden

Fazit: CloudNativePG für Neuprojekte

Für neue Kubernetes-Projekte ist CloudNativePG klar empfehlenswert: geringere Komplexität, CNCF-Backing, aktive Weiterentwicklung und ein sauberes API-Design. Der Operator hat den Zalando-Operator in GitHub-Stars bereits überholt und ist auf dem Weg zum CNCF-Standard für PostgreSQL auf Kubernetes.

Zalando PostgreSQL Operator bleibt eine exzellente Wahl für Teams mit bestehender Patroni-Expertise oder komplexen User-Management-Anforderungen.

Für beide gilt: Teste PITR regelmäßig – ein Backup das nie geprüft wurde, ist kein Backup.

Weiterführende Artikel

Verwandte Technologien im Techradar