PostgreSQL Helm Chart: So deployst du Postgres auf Kubernetes

PostgreSQL auf Kubernetes zu betreiben ist heute für viele Teams Alltag. Helm hat sich als Standard-Werkzeug durchgesetzt, um diese Deployments reproduzierbar zu machen. Was dabei oft unterschätzt wird: Stateful Workloads wie Datenbanken verzeihen Konfigurationsfehler weniger als zustandslose Services – und wer bisher blind auf Bitnami-Charts gesetzt hat, steht seit 2025 vor einer unerwarteten Entscheidung.

Was Helm hier eigentlich macht

Helm ist ein Package Manager für Kubernetes. Ein Helm Chart bündelt alle Kubernetes-Manifeste, die du für ein Deployment brauchst. Dazu gehören Deployments, Services, ConfigMaps, Secrets und PersistentVolumeClaims, zusammengefasst in einem versionierten, konfigurierbaren Paket. Statt dutzende YAML-Dateien manuell zu pflegen, definierst du deine Abweichungen vom Standard in einer values.yaml und übergibst den Rest dem Chart.

Für PostgreSQL bedeutet das: Das Chart kümmert sich um StatefulSets, Headless Services für die Peer-Kommunikation, die Einbindung von Persistent Volumes und optionale Replikationskonfigurationen. Du musst das Rad nicht neu erfinden, solltest aber verstehen, was unter der Haube passiert.

PostgreSQL Helm Chart Deployment – der direkte Weg

Voraussetzungen

Bevor du deployst, solltest du folgendes sicherstellen:

• Helm 3.x ist installiert
• Du hast kubectl-Zugriff auf deinen Cluster
• Ein StorageClass ist konfiguriert, der dynamisch Persistent Volumes bereitstellen kann
• Deine Kubernetes-Version ist kompatibel mit dem gewählten Chart

Das Chart installieren

Mit einem Community-kompatiblen Chart (Details zur Wahl im nächsten Abschnitt) sieht der Basis-Befehl so aus:

helm repo add <repo-name> <repo-url>
helm repo update

helm install my-postgres <repo-name>/postgresql \
  --namespace databases \
  --create-namespace \
  -f values.yaml

Statt alle Parameter als --set-Flags zu übergeben, empfiehlt sich eine saubere values.yaml. Das macht das Deployment nachvollziehbar, versionierbar und reproduzierbar.

Wichtige Konfigurationsparameter

Drei Bereiche sind in der Praxis am kritischsten:

Passwörter gehören nicht direkt in die values.yaml. Lege stattdessen Kubernetes Secrets vorher an und referenziere sie im Chart:

auth:
  existingSecret: 'my-postgres-secret'
  secretKeys:
    adminPasswordKey: 'postgres-password'
    userPasswordKey: 'user-password'

Die Standard-Persistenzkonfiguration reicht für Tests, genügt aber nicht für den Produktionsbetrieb. Definiere Größe und StorageClass explizit:

primary:
  persistence:
    enabled: true
    size: 50Gi
    storageClass: 'fast-ssd'

Wenn du Hochverfügbarkeit brauchst, lohnt sich ein Read-Replica-Setup:

architecture: replication
readReplicas:
  replicaCount: 2

Ohne explizite Replikationskonfiguration deployst du eine Einzelinstanz. Das funktioniert, ist aber kein produktionstaugliches Setup.

Das Bitnami-Problem und was es für dein Setup bedeutet

Bitnami hat jahrelang den De-facto-Standard für Helm Charts geliefert. Die Charts waren einfach zu nutzen, gut dokumentiert und hatten eine breite Community. Das hat sich geändert.

Seit VMware Bitnami übernommen hat, wurde das Repository-Modell schrittweise umgebaut – ein klassisches Beispiel für Vendor Lock-in. Ab August 2025 ist der direkte Zugriff auf das öffentliche Bitnami-Repository für kommerzielle Nutzer eingeschränkt. Wer helm repo update in seiner CI/CD-Pipeline ohne Anpassung laufen lässt, riskiert, dass Deployments fehlschlagen – nicht weil der Cluster ein Problem hat, sondern weil das Chart-Repository nicht mehr wie erwartet erreichbar ist.

Für bestehende Setups heißt das: Überprüfe, welche deiner Helm Charts von Bitnami stammen. Schau dir an, ob du betroffen bist – und wenn ja, wann dein aktuell gecachtes Chart das letzte Mal erfolgreich geladen wurde.

Das ist kein Grund zur Panik, erfordert aber konkretes Handeln.

Alternativen zum Bitnami PostgreSQL Helm Chart

Open-Source-Alternativen im Überblick

Es gibt funktionstüchtige Alternativen, die aktiv gepflegt werden:

Wie du PostgreSQL mit dem Cloudpirates Helm Chart auf lowcloud deployst, zeigt unser Schritt-für-Schritt-Guide.

• Cloudpirates Open Source Helm Charts: lowcloud stellt eigene, quelloffene Charts bereit – als direkte Antwort auf die Bitnami-Problematik. Die Charts sind auf praxistaugliche Defaults ausgelegt und werden aktiv gewartet.
• Zalando Postgres Operator: Ein Operator-Ansatz, der über CRDs gesteuert wird. Mächtiger als ein simples Chart, aber auch komplexer in der Einrichtung.
• CloudNativePG Operator: Der CNCF-gepflegte Postgres-Operator mit starkem Fokus auf Kubernetes-Native-Features wie Streaming-Replikation, Point-in-Time-Recovery und automatische Failover-Szenarien.

Kriterien für die Wahl des richtigen Charts

Die Wahl hängt von deinen Anforderungen ab:

Für Teams, die PostgreSQL produktiv und mit Hochverfügbarkeitsanforderungen betreiben wollen, ist ein Operator mittelfristig die solidere Wahl. Für kleinere Services oder Entwicklungsumgebungen reicht ein gut konfiguriertes Chart.

Persistenz, Backups und Monitoring nicht vergessen

Wenn das Deployment läuft, fangen die eigentlichen Operationsaufgaben an.

Stelle sicher, dass dein PersistentVolumeClaim an eine StorageClass gebunden ist, die tatsächlich schnelle I/O liefert. Langsame Festplatten sind bei PostgreSQL ein häufiger Performance-Killer, der sich erst unter Last zeigt.

Für Backups bleibt pg_dump eine valide Lösung bei kleineren Datenbanken. In Kubernetes-nativen Setups lohnt sich ein Blick auf Velero für Snapshot-basierte Backups des Persistent Volumes auf S3-kompatiblem Objektspeicher oder Barman für WAL-Archivierung und Point-in-Time-Recovery.

# Einfacher pg_dump aus einem laufenden Pod
kubectl exec -it my-postgres-0 -n databases -- \
  pg_dump -U postgres mydb > backup.sql

Beim Monitoring ist der postgres_exporter der Standardweg, um PostgreSQL-Metriken in Prometheus zu exportieren. Folgende Metriken solltest du im Blick haben:

• pg_stat_activity – aktive Verbindungen und laufende Queries
• pg_replication_lag – Replikationsverzögerung bei Read Replicas
• pg_database_size_bytes – Datenbankwachstum über Zeit

Ein Grafana-Dashboard gibt es fertig zum Import – such nach Dashboard-ID 9628 im Grafana-Repository.

Wann ein Managed-Ansatz die bessere Wahl ist

Der Betrieb von PostgreSQL auf Kubernetes ist lösbar, aber er bindet Zeit. Jemand muss die Charts aktualisieren, Backups überwachen, Failover-Szenarien testen und sicherstellen, dass Storage-Klassen nach Cluster-Upgrades noch korrekt funktionieren.

Für Teams, die sich auf ihre Anwendung konzentrieren wollen statt auf Datenbankinfrastruktur, ist eine DevOps-as-a-Service-Plattform wie lowcloud eine pragmatische Alternative. PostgreSQL wird dort als verwalteter Service bereitgestellt – auf Basis derselben souveränen Kubernetes-Infrastruktur, aber ohne den operativen Overhead. Du brauchst keine eigenen Helm Charts zu pflegen, keine manuelle Backup-Konfiguration einzurichten und kein Monitoring-Setup von Grund auf aufzubauen.

Das ist kein Ersatz für jeden Use Case. Wer spezifische PostgreSQL-Konfigurationen, eigene Extensions oder volle Kontrolle über jeden Parameter braucht, ist mit dem Eigenbetrieb besser bedient. Für alles andere lohnt sich die Frage: Ist das wirklich ein differenzierender Vorteil für dein Team, oder doch nur notwendiger Overhead?

Fazit

PostgreSQL mit Helm auf Kubernetes zu deployen funktioniert. Die Schritte sind überschaubar, die Konfigurationsoptionen gut dokumentiert. Was sich geändert hat: Die Wahl des richtigen Charts ist keine Selbstverständlichkeit mehr. Wer bisher auf Bitnami gesetzt hat, sollte die eigene CI/CD-Pipeline überprüfen und eine Alternative evaluieren – ob das ein Community-Chart, ein Operator oder ein Managed-Service ist, hängt von den eigenen Anforderungen ab.

Die Infrastruktur-Entscheidungen von heute wirken sich direkt auf die Wartbarkeit in zwölf Monaten aus.

Wie du PostgreSQL in wenigen Minuten auf lowcloud deployst, zeigt unser PostgreSQL-Guide in der Dokumentation.