A perfect match

Kubernetes und NoSQL-Datenbanken gehören zusammen

Steffen Schneider

© Shutterstock / Funtap

Entwicklung und Betrieb von Kubernetes-Clustern stellen ganz eigene, komplexe Anforderungen an die benötigten Datenbank-Services. Für deren automatisierte Bereitstellung und Verwaltung sind NoSQL-Datenbanken erste Wahl. Warum sie besser geeignet sind als SQL-Lösungen, erklärt Steffen Schneider, Head of Solutions Engineering Central Europe bei Couchbase, in diesem Artikel.

Eine dynamische Microservices-Architektur wie Kubernetes ist auf einen hohen Automatisierungsgrad ausgelegt. Das gilt notwendigerweise auch für die dafür erforderlichen Datenbank-Services. Transaktionsorientierte relationale SQL-Datenbanken mit ihren starren Tabellen-Schemata sind damit jedoch überfordert. Im Gegensatz zu NoSQL-Datenbanken verfügen sie weder über die Voraussetzungen noch die Ausbaufähigkeit für automatische Skalierungs-, Provisionierungs-, Failover- oder Replikationsfunktionen.

Die Microservices in Kubernetes benötigen aufgrund des temporären und volatilen Charakters der Arbeitsprozesse flüchtige (stateless) Datenbank-Services. Die Pods in einem Microservices-Cluster sind temporär angelegt, also nur für eine bestimmte Zeit aktiv und werden danach geplant – und manchmal auch ungeplant – beendet. Die für Datenbanken benötigten permanenten Volumes um Daten stateful vorzuhalten, können bei relationen Datenbanken nicht oder nur schwer getrennt werden. Dies versursacht bei relationalen Datenbanken, aufgrund daraus resultierender ständiger Überwachung und händischer Aktivierung oder Deaktivierung hohen Operations-Aufwand. Letzterer ist enorm komplex, zeitaufwändig und fehleranfällig und daher in der Praxis oftmals nicht zu leisten.

Servicelieferanten für die Pods

NoSQL-Datenbanken sind in der Kubernetes-Entwicklung daher gesetzt. Sie sind besser geeignet, die Pods in einem Kubernetes-Cluster mit den gerade benötigten Datenbank-Ressourcen zu versorgen. Jedem Pod wird dabei aus dem bereitstehenden Persistent-Volume eine Stateful-Komponente zur Verfügung gestellt. Dessen Zuordnung, Inhalt, Verhalten und Laufzeit wird dabei ebenso verwaltet, wie das Zusammenspiel mit den anderen Pods innerhalb eines Kubernetes-Clusters.

Ein ganz wesentliches Element und wichtiges Qualitätskriterium für eine NoSQL-Datenbank ist das automatisierte intelligente Echtzeit-Management der Logik in den Pods. Die dafür 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. Die NoSQL-Datenbank verwaltet die Laufzeit, reagiert auf Abbrüche und steuert Restarts. Neben der Automatisierung einzelner Pods übernimmt die Managementschicht der NoSQL-Datenbank idealerweise auch die Steuerung und Kontrolle der vorhandenen und benötigten Datenbank-Persistent Volumes sowie ihrer Services. Entwickler und Administratoren müssen sich dank der Automatisierung um diese Datenbank-Operationen nicht mehr selbst kümmern und können sich verstärkt kreativen Aufgaben widmen.

Fünf Stufen zur Perfektion

Die Funktionstiefe und -breite von NoSQL-Datenbanken ist sehr unterschiedlich ausgeprägt. Sie differieren stark hinsichtlich der jeweiligen Reifegrade. Die sogenannten Maturity-Level werden von der Cloud Native Computing Foundation (CNCF) definiert und umfassen insgesamt fünf Stufen. Level 1 bietet ausschließlich Basisfunktionen wie das automatisierte App-Provisioning und das Konfigurationsmanagement. Eine Reihe von NoSQL-Datenbanken beherrscht mittlerweile Level 3 oder gar 4, ein einziger Anbieter hat bereits Level 5 (Full Automation) vollumfänglich umgesetzt. Auf dieser finalen Stufe 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 Auto Scheduling und Auto-Scaling (vertikal- und horizontal).

Aufgrund des stabilen Trends zu hybriden Umgebungen und Multi-Cloud-Szenarien müssen Microservices unabhängig von der jeweils genutzten Cloud-Plattform (wie etwa AWS EKS, Azure AKS, Google GKE oder Red Hat OpenShift) funktionsfähig sein. Das betrifft dann logischerweise auch die automatisierten, von der NoSQL-Datenbank bereitgestellten, Services. Neben der Unterstützung der diversen Cloud-Plattformen durch die NoSQL-Datenbank kann die Kompatibilität auch durch die Nutzung von Open Source Kubernetes sichergestellt werden.

Geschrieben von
Steffen Schneider

Steffen Schneider ist Head of Solutions Engineering Central Europe bei Couchbase.

Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: