Infrastrukturprojekt 2022 Wie sich Kubernetes mit der neuen Datenschicht verknüpfen lässt

Anbieter zum Thema

Paessler AG

NetModule AG

Confluent Germany GmbH

Große Einzelhandelsunternehmen nutzen seit 2018 Kubernetes, um überall auf der Welt massive Workload-Peaks zu bewältigen. Denn durch Kubernetes lassen sich operative Verwaltungsarbeit drastisch reduzieren und die Produktivität der Ressourcen steigern.

Kubernetes hat sich als Orchestrierungsschicht der Wahl für die Arbeit mit Containern bewährt. Man kann sich Container als Speicher vorstellen, die ein Bündel von Programmen enthalten und nützliche Dinge erledigen. Das dürfte der wichtigste Grund dafür sein, dass es sich in den Fortune-500-Unternehmen so großer Beliebtheit erfreut.

Triebfeder für die Entwicklung von Kubernetes war das Bestreben, die IT-Infrastruktur zu optimieren. Die IT befand sich damals in der Übergangsphase von lokalen Servern als Standard-Bare-Metal-Maschinen hin zu virtuellen Maschinen. Von dort ging die Entwicklung weiter zu Containern, die noch weniger Ressourcen verbrauchten und effizienter waren als der Betrieb virtueller Maschinen. Dieser Weg führte über die kommerzielle Software Docker.

Dann kam das quelloffene Kubernetes auf den Markt. Damit konnten Entwickler viele Container koordinieren. So können sie sämtliche benötigten Container ausführen und verwalten. Als nützlichstes Feature erweist sich, dass Kubernetes, von Entwicklern auch K8s genannt, Container zwecks leichterer Handhabung in Pods bündelt. Ein Pod ist die kleinste einsatzfähige Recheneinheit, die man innerhalb des Systems erstellen und verwalten kann. Es besteht aus einer Gruppe von einem oder mehreren Containern mit gemeinsam genutzten Speicher- und Netzwerkressourcen sowie einer Spezifikation, die klarstellt, wie sie ausgeführt werden sollen. Um eine Vorstellung von der möglichen Größenordnung zu geben: Manche Unternehmen betreiben gleichzeitig Tausende von Pods im produktiven Einsatz.

Gegenwärtig kann die meist verbreitete Art, mit K8s zu arbeiten, mit zustandslosen Workloads verglichen werden (siehe Kasten). Es gibt viele Möglichkeiten, wie man dabei vorgehen kann. Da die Cloud jedoch immer häufiger für Business-Zwecke genutzt werden soll, sind transaktionsbasierte Prozesse erforderlich.

Entwickler und Anwender möchten sich die Möglichkeiten erhalten, die Cloud und Container für solche Anwendungsfälle bieten. Früher hatten es User mit einer Anwendung zu tun, die auf ihren Servern oder Clustern lief. Heutzutage dirigieren sie zahlreiche Microservice-Anwendungen mit Hunderten von Kopien dieser Anwendung. Anstatt fünf Anwendungsserver für eine bestimmte vorgegebene Workload zu betreiben, können User von Containern bei plötzlichen Nachfragespitzen elastisch skalieren und im Handumdrehen 15 Server aktivieren. Das bedeutet horizontale Skalierbarkeit: die Fähigkeit, auf Knopfdruck zusätzliche Container zu erstellen und damit weitere Kopien der Anwendung zu erhalten. User erhalten so kostengünstig und automatisch einen sofortigen Ressourcenschub.

Open-Source-Software

In drei Schritten die Migration zu Open Source bewältigen

Es wäre praktisch, wenn Kubernetes auch bei großen zustandsbehafteten Anwendungen unterstützen könnte. Dazu ist es notwendig, von zustandslosen Anwendungen dazu überzugehen, die von zustandsbehafteten Diensten benötigten Daten zu speichern.

Bislang hat Kubernetes in seinem kurzen Dasein als IT-Tool für Unternehmen das Datenproblem umgangen, indem es entweder RDBMS/relationale Datenbanken im alten Stil verwendet oder stattdessen auf NoSQL-Datenbanken zurückgegriffen hat. Das war bis jetzt in Ordnung. Doch dieser Weg hat in eine Sackgasse geführt. Relationale Datenbanken, oft als monolithische Datenbanken bezeichnet, eignen sich fantastisch für jede Topologie - außer der Cloud. No-SQL-Datenbanken wie Cassandra und MongoDB dagegen schlagen sich in Cloud-Umgebungen hervorragend – mit Kubernetes für einige Anwendungsfälle. Sie sind jedoch nicht in der Lage, die Transaktionsfähigkeiten relationaler Datenbanken zu replizieren.

Dazu kommt noch ein weiterer Gedanke: Wer Microservices nutzt, möchte in der Lage sein, für unterschiedliche Zwecke viele verschiedene Datenbankformate einzusetzen – im Idealfall sowohl relationale als auch NoSQL-Datenbanken. Für eine moderne Anwendung mag ein Anwender eine Transaktionsdatenbank benötigen. Er hat möglicherweise einen analytischen Speicher wie Snowflake zur Verfügung. Die Anwendung enthält zudem eventuell einige Events oder Messaging. Hier wäre beispielsweise der Message-Broker Kafka eine Option. In einer Online-Shopping-Anwendung könnte das „Nächste beste Angebot“ von einem analytischen Datenspeicher ausgeführt werden, der Delivery-Prozess vom Messaging-Speicher, der Warenkorb von einer NoSQL-Datenbank, und die Abwicklung der Bezahlung würde über eine relationale Datenbank laufen.

Falls Kubernetes diese Aufgabe nicht stemmen kann, ist ein sehr aufwendigen Programmier- und softwarelastiger Ablauf die Folge. Im schlimmsten Fall ist das Problem nicht lösbar.

Die gute Nachricht ist, dass es eine Antwort auf dieses Dilemma gibt. Denkt man den Weg konsequent weiter, der von Bare-Metal-Servern zu Containern geführt hat, so gelangt man zur Idee einer Datenschicht. Wenn es bei Containern um horizontale Skalierung und Elastizität für Anwendungen geht, warum soll sich das nicht auch bei Daten umsetzen lassen? Die Datenschicht löst das Problem, indem sie eine Etage unterhalb der Anwendung auf intelligente Weise mit Daten arbeitet.

Umzug in die Cloud

Nach der Pandemie ist vor der Datenbank-Systemumstellung

Die Verbindung von K8s und verteilten Datenbanken als Teil einer Datenschicht

Die Datenschicht ist der Ort, an dem all die verschiedenen benötigten Speicherkomponenten untergebracht werden. Je mehr Arbeit auf Kubernetes verlagert werden kann, desto weniger operative Verwaltungsarbeit muss geleistet werden. Je mehr Anwendungslogik sich durch einen Datenschicht-Ansatz automatisieren lässt, desto einfacher ist die Skalierung. Nur so können Anwender die Kosten senken und die Produktivität ihrer Ressourcen steigern, ohne das Budget zu sprengen.

Teile des Daten-Layers können bereits in einer in K8s gehosteten Datenschicht betrieben werden. Ein nahe liegendes Beispiel ist Kafka. Die Herausforderung, vor der die meisten Unternehmen stehen, besteht jedoch darin, die Grenzen ihrer monolithischen Datenbank zu überwinden.

Wenn Anwender von einer monolithischen Datenbank außerhalb von Kubernetes zu einer elastischen, zustandslosen Datenbank innerhalb von Kubernetes wechseln können, so ist das ein gewisser Fortschritt. Noch besser wäre es, über eine vollständig verteilte Datenbank – wie YugabyteDB – auf der gleichen Plattform wie der Anwendung zu verfügen. Damit stünde den Anwendern eine einzige Methode zur Verwaltung aller Daten zur Verfügung. Als Resultat können Unternehmen ihre Betriebskosten weiter senken und den Prozess einfacher verwalten.

Dieses Projekt befindet sich noch im Anfangsstadium, aber mehrere Kunden haben bereits von bedeutenden Erfolgen bei der Verknüpfung der Leistungsfähigkeit von K8s und verteilten Datenbanken als Teil einer Datenschicht berichtet. Das lässt vermuten, dass viele CIOs dieses Projekt als eines ihrer Top-Projekte für 2022 eingestuft haben.

Empfehlung der Redaktion

Newsletter Industry of Things weekly

Zwei Mal wöchentlich ausgewählte Beiträge rund um den Themenkomplex Industrie 4.0. Hier erhalten Sie Ihr persönliches Update zu IoT, Data Analytics, KI, VR/AR, Edge und Cloud Computing und vielem mehr. Abonnieren Sie jetzt unseren Newsletter!

Jetzt anmelden

* David Walker ist Field CTO, EMEA, bei Yugabyte.

(ID:48193265)