© WarmWorld/Shutterstock.com
Kubernetes Operator im Fokus

Die drei Fragezeichen: Was? Wann? Wie?


Dieser Artikel beschäftigt sich mit drei zentralen Fragen: Was ist ein Kubernetes Operator, wann lohnt es sich, einen zu schreiben, und zu guter Letzt: Wie geht das eigentlich?

In den vergangenen Jahren haben wir unsere Anwendungen zunehmend in Container verpackt, um sie zu isolieren und einfach auslieferbar zu machen. Häufig haben wir sie später mit Hilfe eines Containerorchestrierungs-Frameworks, wie zum Beispiel Kubernetes, in Produktion bewegt. In den gängigen Containerorchestrierungs-Frameworks sind mittlerweile alle üblichen Prozesse implementiert und Probleme gelöst, um zustandslose Anwendungen zu betreiben und sie auch aus einem Fehlerzustand wieder herauszuführen. Fairerweise muss man allerdings sagen, dass die Behebung eines Fehlerzustands einer zustandslosen Anwendung eher einfach ist. Der einfachste Weg, ein Problem zu beheben, ist, dass man den fehlerhaften Container einfach durch einen neuen ersetzt. Man verwirft also den Zustand des problematischen Containers und ersetzt ihn durch einen neuen. Das ist bei zustandslosen Anwendungen auch ohne Weiteres möglich. Allerdings sind manche Teile unserer Anwendung auch zustandsbehaftet, zum Beispiel Datenbanken. Ich denke, dass keiner gerne seine Stammdatenverwaltung verwerfen möchte, falls der Datenbankcontainer ein Problem hat. Daher werden zustandsbehaftete Anwendungen meist speziell behandelt, und es wird häufig keine automatische Fehlerbehandlung durch das Container-Orchestrierungs-Framework konfiguriert. Manche Datenbanken benötigen zum Beispiel auch spezielle Behandlung für Updates oder haben eine ganz spezielle Reihenfolge, in der die Container eines Datenbankclusters gestartet werden müssen.

Aber warum macht das nicht Kubernetes?

Das Problem ist an dieser Stelle nicht, diese spezielle Logik für das Starten oder das Update zu implementieren. Das Problem ist, dass jede Datenbank unterschiedlich ist und unterschiedliche Behandlung benötigt. Zunächst können wir Datenbanken unterscheiden, die für verteilte Systeme entworfen wurden und daher ein sehr gutes Konzept für Clustering haben. Elasticsearch, Neo4j oder MongoDB würde ich als Vertreter dieser Kategorie nennen. Im Gegensatz dazu stehen Datenbanken, die eher für vertikale Skalierung (à la „viel CPU und viel RAM hilft viel“) entworfen wurden und daher erst nachträglich ein Konzept für Clustering erhalten haben. Typische Vertreter dieser Kategorie sind die meisten relationalen Datenbanken. Keiner dieser Ansätze ist schlechter oder besser als der andere. Es hängt immer vom Einsatzzweck ab. Eine nicht geclusterte Installation einer Datenbank neigt dazu, eine bessere Performanz zu haben als ein Betrieb im Cluster der gleichen Datenbank, da es keine teure Netzwerkkommunikation gibt. Allerdings sind geclusterte Datenbanken fehlertoleranter und haben eine höhere Verfügbarkeit. Wenn man die Möglichkeit hat, seine Datenbank auf leistungsstarker und ultrahochverfügbarer Hardware zu betreiben, ist eine nicht geclusterte Datenbank wahrscheinlich genau die Weise, wie man seine Datenbank betreiben möchte, um die beste Performanz zu erhalten. Allerdings ist diese Art der Hardware nur selten in typischen Kubernetes-Installationen zu finden. Daher sind Cluster wesentlich häufiger zu finden, und damit gehen auch die unterschiedlichen Sonderbehandlungen einher.

Der menschliche Operator

Das hat aber nun zur Folge, dass mein Datenbankcluster in eine Situation geraten kann, in der Kubernetes ihn nicht mehr von einem problematischen Zustand in einen gesunden Zustand überführen kann. Oder es kann die Situation entstehen, dass ein Update durchgeführt werden soll, das einem speziellen Prozess folgen muss, aber Kubernetes nicht unterstützt. In diesem Fall ist manuelles Eingreifen eines menschlichen Operators notwendig. Typischerweise würde das so aussehen, dass ein Mensch jeden einzelnen Schritt des Updateprozesses mit einem Befehl manuell durchführt. Im Prinzip ist es der gleiche manuelle Aufwand, der bei einem klassischen Betrieb ohne Container auch entstehen würde, nur dass die Datenbank nun in einem Container verpackt ist.

Der Kubernetes Operator

Und genau dieses manuelle Eingreifen versucht man nun durch ein Programm zu ersetzen. Die Strategie ist aber nicht, dass man dieses Problem generisch für alle Datenbanken/Anwendungen dieser Welt löst. Die Strategie lautet, dass ein sehr spezielles Programm nur für genau eine Datenbanktechnologie implementiert wird und genau mit allen Eigenheiten dieser Datenbank umgehen kann. Dieser programmatische Operator spricht dann direkt mit dem Containerorchestrierungs-Framework, in unserem Fall Kubernetes, und trifft Entscheidungen, wie in gegebenen Situationen sinnvoll mit der Datenbank umgegangen werden soll.

Ist ein Kubernetes Operator nur fü...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang