Anzeige

Kubernetes

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.

Steffen Schneider, Senior Solutions Engineer Central Europe
Steffen Schneider
Senior Solutions Engineer Central Europe, Couchbase

Newsletter Anmeldung

Smarte News aus der IT-Welt

Sie möchten wöchentlich über die aktuellen Fachartikel auf it-daily.net informiert werden? Dann abonnieren Sie jetzt den Newsletter!

Newsletter eBook

Exklusiv für Sie

Als Newsletter-Abonnent erhalten Sie das Booklet „Social Engineering: High Noon“ mit zahlreichen Illustrationen exklusiv und kostenlos als PDF!

 

Artikel zu diesem Thema

Cloud digital
Jun 26, 2020

Fünf Tipps für eine reibungslose Datenbank-Migration

Die Verfügbarkeit und Verarbeitung von Daten ist für digitalisierte Unternehmen ein…
Container
Jun 05, 2020

Welche Container-Plattform ist die richtige?

Der Erfolg von Unternehmen hängt zunehmend davon ab, wie sie Applikationen konzipieren,…
Kubernetes
Mai 19, 2020

Maschinenidentitäten in Kubernetes richtig schützen

Kubernetes ist zunehmend in aller Munde, wenn es um das Management von Multi-Cloud…

Weitere Artikel

5G

COVID-19 wird zur 5G-Bremse

Bislang verzeichneten europäische Telekommunikationsunternehmen kaum negative ökonomische Auswirkungen der globalen COVID-19-Krise. Im Gegenteil: Im Zuge vermehrter Arbeit im Homeoffice und temporärer Social-Distancing-Maßnahmen stieg die Netzauslastung in…
Digitale Kugel

IT-Infrastruktur krisensicher machen

Krisen bedeuten immer Veränderungen – das gilt auch für den IT-Betrieb eines Unternehmens. Viel zu oft verlieren Verantwortliche bei steigender Belastung und veränderten Anforderungen den Überblick über erfolgskritische IT-Prozesse.
Notfall

Notfall managen: Mit ITSCM für den schlimmsten Fall gewappnet

Auf den kritischen IT-Vorfall vorbereiten: Verpflichtend ist IT Service Continuity Management (ITSCM) lediglich für Banken, Versicherungen und Betreiber kritischer Infrastrukturen.

Anzeige

Newsletter Anmeldung

Smarte News aus der IT-Welt

Sie möchten wöchentlich über die aktuellen Fachartikel auf it-daily.net informiert werden? Dann abonnieren Sie jetzt den Newsletter!

Newsletter eBook

Exklusiv für Sie

Als Newsletter-Abonnent erhalten Sie das Booklet „Social Engineering: High Noon“ mit zahlreichen Illustrationen exklusiv und kostenlos als PDF!