Datenbanken auf Kubernetes (Operator)

Symptom

Ziel: die Datenbank mit einem Operator auf Kubernetes betreiben; statt eines reinen StatefulSet die vom Operator bereitgestellten Funktionen für automatisches Failover, persistenten Storage und Backup nutzen.

1. Warum ein Operator: Ein StatefulSet allein reicht nicht

Ein einfaches StatefulSet liefert Pods mit stabilen Identitäten und PVCs, aber nicht die Logik für Failover, Replikationsaufbau, Backup und Upgrades. Ein Operator verpackt dieses datenbankspezifische Betriebswissen als Controller + Custom Resource (CRD). Du schreibst eine CR namens 'Cluster', und der Operator verwaltet das StatefulSet, den Service, das Secret und die Backup-Jobs dahinter. In Produktion wird der Betrieb von Datenbanken mit einem Operator in der Regel bevorzugt.

PostgreSQL

# operators for PostgreSQL:
#  - CloudNativePG (CNPG)
#  - Zalando postgres-operator
#  - Crunchy PGO

2. Operator wählen und installieren

Wähle einen Operator für deine Engine: CloudNativePG oder Zalando postgres-operator für PostgreSQL; für MySQL und MongoDB sind die Percona-Operatoren (Percona Operator for MySQL / for MongoDB) verbreitet. Installiere den Operator mit Helm oder einem Bundle-Manifest; dieser Schritt fügt dem Cluster die CRDs und den Controller-Pod hinzu.

PostgreSQL

# CloudNativePG installation
kubectl apply --server-side -f \
  https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/main/releases/cnpg-1.24.0.yaml

MySQL

# Percona Operator for MySQL (Helm)
helm install my-op percona/pxc-operator

MongoDB

# Percona Operator for MongoDB (Helm)
helm install psmdb-op percona/psmdb-operator

3. Storage planen (StorageClass / PVC)

Der Zustand der Datenbank liegt in PVCs; gib in der CR die zu verwendende StorageClass an. Wähle eine StorageClass mit latenzarmem Block Storage, idealerweise lokalähnlicher SSD; Netzwerkdateisysteme (NFS) werden für die meisten Datenbanken nicht empfohlen. Lege PVC-Größe und Erweiterbarkeit (allowVolumeExpansion) von Anfang an richtig fest, denn Verkleinern ist schwierig.

PostgreSQL

spec:
  storage:
    storageClass: fast-ssd
    size: 50Gi

4. Cluster-CR anwenden (Replicas und automatisches Failover)

Gib in der CR die Anzahl der Instanzen/Replicas an; der Operator richtet synchrone/asynchrone Replikation ein und führt bei Ausfall der Primary ein automatisches Failover durch, indem er eine Replica promotet. Die Anwendung sollte sich mit dem vom Operator erstellten Service '-rw' (read-write) verbinden; dieser Service zeigt immer auf die aktuelle Primary. Das Verbindungsziel ändert sich beim Failover daher nicht.

PostgreSQL

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: app-db
spec:
  instances: 3
  storage:
    storageClass: fast-ssd
    size: 50Gi
# the application connects to: app-db-rw

5. Backups über die CR nach S3 schreiben

Operatoren verwalten auch Backups deklarativ: Du definierst in der CR das primäre Backup-Ziel (Object Storage/S3) und die WAL-Archivierung. In CloudNativePG werden die S3-Angaben mit spec.backup.barmanObjectStore gemacht (seit 1.26 veraltet; für neue Deployments das Barman Cloud Plugin und seine Ressource ObjectStore verwenden); kontinuierliche WAL-Archivierung + Base Backups ermöglichen Point-in-Time-Recovery. Referenziere Zugangsdaten aus einem Kubernetes Secret.

PostgreSQL

spec:
  backup:
    barmanObjectStore:
      destinationPath: s3://company-backup/app-db
      s3Credentials:
        accessKeyId:
          name: s3-creds
          key: ACCESS_KEY_ID
        secretAccessKey:
          name: s3-creds
          key: SECRET_ACCESS_KEY

6. Geplante Backup- und Restore-CRs

Erstelle eine Backup-CR für ein einmaliges Backup und eine ScheduledBackup-CR für geplante; erstelle regelmäßige Base Backups mit einem Cron-Ausdruck. Auch Wiederherstellungen sind deklarativ: Mit 'bootstrap.recovery' bootstrappst du einen neuen Cluster aus einem vorhandenen Object-Store-Backup. Führe regelmäßig Wiederherstellungsübungen durch; Backups zu erstellen reicht nicht, teste die Wiederherstellung.

PostgreSQL

apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: nightly-backup
spec:
  schedule: "0 0 2 * * *"
  cluster:
    name: app-db