Datenbanken in Kubernetes – Alternativen zur Cloud-Hosted DB

Der Betrieb von Datenbanken in Kubernetes galt lange Zeit als riskant: Stateful Workloads, persistente Daten und Container-Orchestrierung schienen nicht zusammenzupassen. Heute ist die Lage eine andere. Durch spezialisierte Operatoren, optimierte Storage-Lösungen und bewährte Praktiken sind relationale und dokumentenbasierte Datenbanken inzwischen stabile Bausteine für Cloud-native Architekturen.

Während Hyperscaler wie AWS, Google oder Azure mit Cloud-hosted DBaaS-Angeboten (z. B. RDS, CloudSQL, CosmosDB) den Betrieb stark vereinfachen, bleiben Fragen offen: Vendor Lock-in, Souveränität, Compliance. Unternehmen, die volle Kontrolle und Flexibilität wünschen, setzen daher auf Self-Hosted Datenbanken in Kubernetes.

In diesem Artikel vergleichen wir drei populäre Datenbanken und deren Operatoren für Kubernetes:

• PostgreSQL mit CloudNativePG
• MariaDB mit MariaDB Operator
• MongoDB mit MongoDB Kubernetes Operator

Wir analysieren deren Features im Hinblick auf Skalierung, Cluster-Bildung, Backups, Monitoring und Day-2-Operations. Außerdem geben wir einen Einblick, wie wir bei ayedo seit vielen Jahren erfolgreich Stateful Database Workloads in Kubernetes betreiben – insbesondere im Zusammenspiel mit Longhorn, einer leistungsfähigen Storage-Lösung mit data locality und eingebauter Replikation.

Warum Datenbanken in Kubernetes?

Die Vorteile liegen auf der Hand:

• Automatisierung: Operatoren übernehmen Routineaufgaben (Provisionierung, Updates, Failover).
• Flexibilität: Einsetzbar on-premises oder in Multi-Cloud-Umgebungen.
• Kosteneffizienz: Keine Abhängigkeit von Cloud-Provider-Pricing.
• Souveränität: Volle Kontrolle über Daten, Speicher und Security.

Gleichzeitig gilt: Datenbanken in Kubernetes erfordern ein tieferes Verständnis von Storage, Netzwerk und Day-2-Betrieb. Hier trennen sich gute von schwachen Implementierungen.

PostgreSQL mit CloudNativePG

CloudNativePG ist ein CNCF-Projekt, das sich vollständig auf PostgreSQL in Kubernetes spezialisiert hat.

Features

• Cluster-Bildung: Automatische Replikation und Failover mit Patroni-ähnlichem Ansatz.
• Skalierung: Unterstützung von Read Replicas für horizontale Skalierung.
• Backups: Integriert mit pgBackRest.
• Monitoring: Exporter für Prometheus, Dashboards in Grafana.
• Day-2-Operations: Rolling Updates, automatische Failover, Point-in-Time Recovery.

Vorteile

• CNCF-Community-getrieben, offen entwickelt.
• Sehr nahe an PostgreSQL-Standards.
• Breite Integration mit Cloud-Storage und On-Prem Storage.

Nachteile

• Fokus nur auf PostgreSQL, keine Multi-DB-Funktionalität.
• Komplexität bei sehr großen Clustern (>100 Nodes).

MariaDB mit MariaDB Operator

Der MariaDB Operator bringt die beliebte MySQL-Fork-DB in Kubernetes.

Features

• Cluster-Bildung: Automatisierte Galera-Cluster-Integration.
• Skalierung: Horizontal skalierbar über Read Replicas.
• Backups: Unterstützt mysqldump, Percona XtraBackup.
• Monitoring: Integration mit Percona Monitoring and Management, Prometheus Exporter.
• Day-2-Operations: Automatisierte Upgrades, Scale-Out, Failover.

Vorteile

• Reife Technologie mit langjähriger Community.
• Starke MySQL-Kompatibilität.
• Galera bietet Multi-Master-Szenarien.

Nachteile

• Galera-Cluster können bei Netzwerk-Latenzen komplex werden.
• Backup/Restore weniger integriert als bei CloudNativePG.

MongoDB mit MongoDB Kubernetes Operator

Der MongoDB Operator ist die offizielle Lösung für dokumentenbasierte Datenbank-Workloads.

Features

• Cluster-Bildung: Sharding und Replica Sets werden automatisiert.
• Skalierung: Automatische Replikation, horizontale Skalierung durch Shards.
• Backups: Integration mit Ops Manager.
• Monitoring: Exporter für Prometheus, Dashboards in Grafana.
• Day-2-Operations: Automatisierte Upgrades, Schema-Migrationen.

Vorteile

• Nahtlose MongoDB-Integration, direkt vom Vendor.
• Sharding out-of-the-box.
• Geeignet für große, dynamische Datenmengen.

Nachteile

• Abhängigkeit von MongoDB Inc., einige Features nur kommerziell.
• Höhere Ressourcenanforderungen im Vergleich zu relationalen DBs.

Vergleich der Operatoren

Metrics, Logs und Alerts

Alle drei Operatoren bieten native Integration mit Prometheus und Grafana. Unterschiede liegen in der Tiefe der Dashboards und Exporter.

• PostgreSQL: Reife Exporter (postgres_exporter), detaillierte Dashboards.
• MariaDB: MySQL-kompatible Exporter, Integration mit PMM.
• MongoDB: Exporter aus dem MongoDB Monitoring-Projekt.

Für Logs empfiehlt sich eine zentrale Lösung wie Grafana Loki oder Elasticsearch. Operatoren liefern meist Standard-Log-Integration, die durch Agents wie Promtail oder Vector gesammelt werden kann.

Day-2-Operations

„Day-2" bezeichnet alle Operationen nach der Erstbereitstellung. Dazu zählen:

• Backups & Restores: Einbindung in zentrale Backup-Strategien.
• Upgrades: Rolling Updates, automatische Versionierung.
• Failover: Self-Healing und Rescheduling.
• Observability: Dashboards, Alerts, Logs.
• Security: TLS, Secrets-Management, Benutzerverwaltung.

Hier sind die Unterschiede spürbar:

• CloudNativePG punktet durch nahtloses PITR und robuste Upgrade-Mechanismen.
• MariaDB Operator überzeugt bei Multi-Master-Setups, erfordert aber Netzwerkdisziplin.
• MongoDB Operator ist sehr mächtig, jedoch mit stärkerer Vendor-Bindung verbunden.

ayedo Praxis: Datenbanken + Longhorn

Wir bei ayedo betreiben seit vielen Jahren erfolgreich Stateful Database Workloads in Kubernetes. Besonders bewährt hat sich dabei das Zusammenspiel mit Longhorn:

• Data Locality: Daten bleiben nah an den NVMe-Disks der Nodes.
• Replikation: Eingebaute Replikation schützt vor Node-Ausfällen.
• Performance: Optimiert für Hochgeschwindigkeits-Storage.

Dieses Setup erlaubt es uns, relationale und dokumentenbasierte Datenbanken stabil, performant und hochverfügbar in Kubernetes zu betreiben – ohne auf Cloud-DB-Services angewiesen zu sein.

Fazit

Self-Hosted Datenbanken in Kubernetes sind keine Experimente mehr, sondern praxiserprobte Realität. Die Wahl des passenden Operators hängt stark von den Workloads und organisatorischen Anforderungen ab:

• PostgreSQL (CloudNativePG) für relationale Standards, hohe Zuverlässigkeit und Community-Support.
• MariaDB Operator für MySQL-Kompatibilität und Multi-Master-Szenarien.
• MongoDB Operator für hochskalierbare, dokumentenbasierte Workloads.

Mit Storage-Lösungen wie Longhorn lassen sich diese Datenbanken performant und resilient betreiben – und bieten damit eine echte Alternative zu Cloud-hosted DBs, ohne Souveränität und Flexibilität aufzugeben.