© WarmWorld/Shutterstock.com
Java Magazin
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?

Johannes Unterstein


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 gle...

Java Magazin
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?

Johannes Unterstein


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 gle...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang