Kubernetes hat sich als Orchestrierungsschicht der Wahl für die Arbeit mit Containern bewährt. Das dürfte der wichtigste Grund sein, warum es sich in den Fortune-500-Unternehmen so großer Beliebtheit erfreut. Parallel zur steigenden Verbreitung von Microservices und Cloud Computing für den groß angelegten E-Commerce und die digitale Transformation nutzen große Einzelhandelsunternehmen seit 2018 Kubernetes (K8s), um massive Workload-Peaks wie beispielsweise den Black Friday zu bewältigen.
Triebfeder für die Entwicklung von Kubernetes war das Bestreben, die IT-Infrastruktur zu optimieren. Die IT befand sich damals in der Überhangsphase 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. Über die kommerzielle Software ‘Docker‘ führte diese Entwicklung zu den Containern. Man kann sie sich als Speicher vorstellen, die ein Bündel von Programmen enthalten und nützliche Dinge erledigen.
Schließlich kam das quelloffene Kubernetes auf den Markt. Es ermöglichte es Entwicklern, viele Container zu koordinieren. So können sie sämtliche benötigten Container ausführen und verwalten („orchestrieren“). Als nützlichstes Feature erweist sich, dass K8s 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, und das Ganze zusammen mit einer Spezifikation, 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. Das ist eine gute Sache; es gibt viele Möglichkeiten, wie man das tun 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 großartigen Möglichkeiten erhalten, welche 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. Genau 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.
Es wäre sicher 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, aber 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, sind aber nicht in der Lage, die Transaktionsfähigkeiten relationaler Datenbanken zu replizieren.
Dazu kommt noch ein weiterer Gedanke: Wer Microservices nutzt, möchte auch in der Lage sein, für verschiedene Zwecke viele verschiedene Datenbankformate einzusetzen, idealerweise sowohl relationale als auch NoSQL-Datenbanken. Für eine moderne Anwendung mag ein Anwender vielleicht eine Transaktionsdatenbank benötigen; er hat möglicherweise einen analytischen Speicher zur Verfügung – so etwas wie Snowflake; seine Anwendung enthält zudem vielleicht einige Events oder Messaging.
Hier könnte man sich so etwas wie den Message Broker Kafka vorstellen. 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, hat man es mit einem sehr aufwändigen Programmier- und Software-lastigen Ablauf zu tun – oder gar mit einem gänzlich unmöglichen zu lösenden Problem. Die gute Nachricht ist, dass es eine Antwort auf dieses Dilemma gibt. Denkt man den Gedanken konsequent weiter, der von „Bare Metal“-Servern zu Containern geführt hat, so führt das zur Idee einer Datenschicht. Wenn es bei Containern um horizontale Skalierung und Elastizität für Anwendungen geht, warum kann man das nicht auch für Daten so umsetzen? Die Datenschicht löst das Problem, indem sie auf intelligente Weise mit Daten arbeitet, eine Etage unterhalb der Anwendung.
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 naheliegendes Beispiel ist Kafka. Die Herausforderung, vor der die meisten Unternehmen stehen, besteht jedoch darin, die Grenzen ihrer monolithischen (relationalen) 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, eine vollständig verteilte Datenbank – wie zum Beispiel YugabyteDB – auf der gleichen Plattform wie die Anwendung zu haben, so dass den Anwendern eine einzige Methode zur Verwaltung aller Daten zur Verfügung steht. Dadurch können sie Ihre Betriebskosten weiter senken und den Prozess einfacher verwalten.
Dieses Projekt befindet sich noch im Anfangsstadium, aber mehrere unserer 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. Vielleicht sollten Sie das auch tun.
Zustandslos oder zustandsorientiert?
Bei der Arbeit mit Containern ergeben sich einige Komplikationen, die aus dem Unterschied zwischen zustandslosen und zustandsfähigen Anwendungen resultieren. Vereinfacht gesagt, hat eine zustandslose Anwendung nur eine Funktion oder einen Dienst, z. B. ein IoT-Gerät. Sie ist also im Wesentlichen eine containerisierte Microservices-Anwendung. Da der Prozess einer solchen Anwendung nur mit denjenigen Daten arbeitet, die ihm jedes Mal neu bereitgestellt werden, muss er nicht auf frühere Daten zurückgreifen.
Zustandslose Anwendungen „speichern“ also keine Daten, im Gegensatz zu zustandsbehafteten Anwendungen, die genau das tun müssen. Typischerweise enthalten zustandsbehaftete Anwendungen einen Datenspeicher, oder sie bestehen eben aus der Datenbank, auf die andere Anwendungen zugreifen, um einen zeitlichen Kontext zu ermöglichen. Ein Beispiel für einen solche notwendigen Kontext im Rahmen einer zustandsbehafteten Anwendung sind Transaktionen in einer Finanzdienstleistungsanwendung.
David Walker ist Field CTO im Bereich EMEA bei Yugabyte.
