Zalando-Postgres-Operator: adoptieren und die PVC-Falle

Eine Datenbank auf Kubernetes betreibt man am besten über einen Operator, der die Instanz aus einer Beschreibung erzeugt und ihren Lebenszyklus führt. Der Zalando-Postgres-Operator macht das gut. Beim Aufräumen und beim Übergang in GitOps gibt es aber eine Falle, die im schlimmsten Fall die Daten kostet.

Eine Datenbank als Ressource

Statt StatefulSet, Service und Volumes einzeln zu bauen, beschreibt man die Datenbank als postgresql-Ressource. Der Operator erzeugt daraus das StatefulSet und die passenden Volumes. Welche Felder es im Manifest gibt, steht in der Cluster-Manifest-Referenz des Operators:

apiVersion: acid.zalan.do/v1
kind: postgresql
spec:
  numberOfInstances: 1
  volume:
    size: 2Gi
    storageClass: standard
  postgresql:
    version: "16"

Die PVC-Falle

Die eigentlichen Daten liegen nicht im Pod, sondern in einem PersistentVolumeClaim, den der Operator anlegt (pgdata-<name>-0). Genau hier ist die Gefahr:

Löscht man die postgresql-Ressource, oder pruned ArgoCD sie, weil sie aus Git verschwunden ist, dann räumt der Operator konsequent auf: das StatefulSet, der Service, und eben auch die PVC. Ein helm uninstall oder ein unbedachtes prune: true wird so aus einer Konfigurationsänderung ein Datenverlust.

Darum gehen Datenbanken unter ArgoCD nur mit Vorsicht: das Pruning für die DB-Ressourcen bewusst aus oder eng gescopt, die CRDs nicht helm-managed (der Operator registriert postgresqls selbst), und der Eigentumsübergang erst, nachdem geprüft ist, dass ein Backup steht. Konkret schützt in ArgoCD die Sync-Option Prune=false eine Ressource vor dem Löschen, entweder als Annotation an der Ressource oder in der syncPolicy der Application. Die verfügbaren Optionen stehen in den ArgoCD Sync-Options. Das grundsätzliche Adoptieren bestehender Workloads habe ich im Beitrag Ein gewachsenes Cluster nach ArgoCD holen beschrieben, für Datenbanken gilt es doppelt.

Ehrlich: DB auf Kubernetes ist kein Nebenbei

Ein Datenbank-Operator nimmt viel Handarbeit ab, aber er ersetzt kein Backup-Konzept. Bevor man sich auf ihn verlässt, muss die Sicherung stehen, idealerweise ein kontinuierliches Verfahren mit Point-in-Time-Recovery, das die Sicherung außerhalb des Clusters ablegt. Der Operator sorgt für Betrieb, nicht für Wiederherstellbarkeit. Das bleibt Ihre Entscheidung und Ihre Verantwortung.

Sie betreiben Datenbanken und wollen sicher sein, dass die Daten einen Fehlgriff überleben? Ich baue Datenhaltung mit getestetem Backup und klarer Wiederherstellung, auf Kubernetes wie klassisch. Mehr unter Infrastruktur & Cloud, das Erstgespräch ist unverbindlich.