StatefulSets in Produktion — PostgreSQL und Elasticsearch auf Kubernetes

2017 haben wir mit StatefulSets in der Beta begonnen. Heute betreiben wir PostgreSQL-Cluster und Elasticsearch auf Kubernetes in der Produktion. Zwei Jahre Erfahrung in einem Artikel.

PostgreSQL auf Kubernetes¶

Wir verwenden den Patroni-Operator für PostgreSQL HA. Drei-Knoten-Cluster: Primary + 2 Replicas. Automatisches Failover, Streaming-Replikation, Point-in-Time-Recovery aus WAL-Archiven in S3.

Was funktioniert: automatisches Failover, Backup-Scheduling, Ressourcenisolation. Was herausfordernd ist: Storage-Performance-Tuning, Major-Version-Upgrades (immer noch ein manueller Prozess), Connection Pooling (PgBouncer als Sidecar).

Elasticsearch auf Kubernetes¶

Elastic Cloud on Kubernetes (ECK) Operator. 3 Master-Knoten, 3 Data-Knoten, 2 Coordinating-Knoten. Automatisches Scaling, Rolling Upgrades, Snapshot-Backups.

Der ECK-Operator ist hervorragend — Sie definieren den gewünschten Zustand, der Operator kümmert sich um den Rest. Das Upgrade von Elasticsearch von 6.x auf 7.x erfolgte per Rolling Update ohne Downtime.

Lessons Learned¶

• Storage Class ist entscheidend: SSD (gp2/gp3) für Datenbanken, immer
• Anti-Affinity: Replicas auf verschiedenen Nodes/AZs
• Resource Requests = Limits für Guaranteed QoS
• Backups regelmäßig testen — Restore-Drill jeden Monat
• Monitoring: Datenbanken brauchen spezifische Metriken (Replication Lag, Connections, Locks)

Wann NICHT auf Kubernetes¶

Extrem leistungssensible Workloads (Bare-Metal-Latenz ist immer noch niedriger). Riesige Datenbanken (TB+) mit komplexem Sharding. Legacy-Datenbanken ohne Kubernetes-Operator.

Stateful Workloads auf Kubernetes sind produktionsreif¶

Mit einem guten Operator, richtigem Storage und diszipliniertem Betrieb funktioniert es. Aber respektieren Sie die Grenzen — nicht jede Datenbank gehört auf Kubernetes.