Thought Leadership
Für Kubernetes-Entwickler steht gleich zu Beginn eines Projekts eine folgenschwere Entscheidung an: Welche Datenbank setze ich dafür ein? Die Antwort auf diese Frage kann im weiteren Verlauf entweder für viel Verdruss oder für hilfreiche Entlastung sorgen.
Denn Datenbanken haben sich in der Kubernetes-Entwicklung zu einem der größten Schmerzpunkte entwickelt.
Fest oder flüchtig?
Grund dafür ist die notwendige „Flüchtigkeit“ von Datenbank-Services für Microservices in Kubernetes. Dieser flüchtige Status wird von Entwicklern „stateless“ genannt und steht im Gegensatz zu den bekannten permanenten Volumes zentralisierter Datenbanken (persistent oder stateful). Eine zentralisierte relationale Datenbank aber ist für die Versorgung einer dynamischen Microservices-Architektur mit Datenbank-Services überfordert, denn diese Services werden aufgrund des temporären und volatilen Charakters der Arbeitsprozesse (Pods) in einem Microservices-Cluster nur für eine bestimmte Zeit benötigt, egal ob der Pod geplant oder ungeplant beendet wird.
Um die mit Kubernetes – oder anderen Orchestrierungsplattformen wie OpenShift – eingesetzten Pods in einem Cluster mit den Datenbank-Ressourcen zu versorgen, sind NoSQL-Datenbank besser geeignet. Jedem Pod wird dabei aus dem bereitstehenden Persistent-Volume ein Stateless-Service zur Verfügung gestellt. Dessen Zuordnung, Inhalt, Verhalten und Laufzeit muss dabei ebenso verwaltet werden, wie das Zusammenspiel mit den anderen Pods innerhalb eines Kubernetes-Clusters. Bei händischer Programmierung und Steuerung ist das enorm komplex, zeitaufwändig und fehleranfällig. Zudem lässt sich die innere Datenbank-Service-Logik in den Pods nicht mit Kubernetes-Onboard-Mitteln der StatefulSets adressieren – es bedarf intelligenterer und umfassenderer automatisierter Logik, die ein Hersteller mitbringen darf.
NoSQL and more
Deshalb empfiehlt sich die Nutzung von NoSQL-Datenbanken, die diese Prozesse weitgehend und besser vollständig automatisiert in Echtzeit abarbeiten. Die jeweils benötigten Datenbank-Ressourcen werden zur Laufzeit zur Verfügung gestellt, egal ob es um Pods für Key Value, Indizierung, Queries, Analytics, Eventing oder Full-Text-Search geht. Und auch für deren Beendigung ist kein händisches Eingreifen mehr nötig. Neben der Automatisierung einzelner Pods übernimmt die Managementschicht der NoSQL-Datenbank idealerweise auch die Steuerung und Kontrolle der vorhandenen und benötigten Datenbank-Volumes sowie der Services. Für Entwickler und Administratoren bedeutet diese Automatisierung eine enorme Entlastung. Beide müssen sich um die Datenbank-Operationen nicht mehr kümmern.
Die verschiedenen NoSQL-Datenbanken unterscheiden sich hinsichtlich der Reifegrade, der sogenannten Maturity-Level. Sie sind also ein wichtiges Auswahlkriterium bei der Wahl der richtigen NoSQL-Datenbank für Kubernetes-Cluster. Definiert werden sie von der Cloud Native Computing Foundation (CNCF), die für Kubernetes eine ähnliche Autoritätsinstitution ist wie die FIFA für den Fußball. Level 1 umfasst Basisfunktionen wie das automatisierte App-Provisioning und Konfigurationsmanagement und reicht in der praktischen Umsetzung bis zu Level 5 (Full Automation), das aktuell im NoSQL-Umfeld vollumfänglich mit allen Datenbank-Komponenten seit Juni 2020 von einem einzigen Anbieter umgesetzt ist. Zu den automatisierten Funktionen in Level 5 gehören unter anderem Auto Failover, Automated Availability, Automated Provisioning, Automated Update, Centralized Management, On-demand Dynamic Scaling, Failure Recovery und Cross Datacenter Replication (XDCR) bis hin zu vollständigem Vertikal- und Horizontal-Auto-Scaling sowie Auto Scheduling.
Cloud-agnostisch
Zwingend nötig für eine containerisierte NoSQL-Datenbank ist, dass sie automatisch auch die Service-Logik innerhalb eines Pods erkennt – und so beispielsweise rechtzeitig selbständig auf dessen Ausfall reagieren kann: etwa indem der Pod neu gestartet oder, falls er nicht mehr gebraucht wird, die zugeordneten Datenbank-Services zurückgefahren werden. Mit dieser Funktionalität wird die NoSQL-Datenbank quasi zu einer eigenen Applikation für das Management des gesamten Kubernetes-Datenbank-Clusters.
Ihr volles Potenzial entfaltet eine NoSQL-Datenbank im Kubernetes-Umfeld dann, wenn die Automatisierungsfunktionalitäten unabhängig von der Cloud-Plattform bereitgestellt werden. Neben Red Hat OpenShift, Google GKE, Azure AKS und AWS EKS als herstellereignen Kubernetes-Servicelösungen kann durch die Kompatibilität mit Open Source Kubernetes potenziell jede Cloud-Plattform genutzt werden.
