Mario Kleinsasser STRABAG BRVZ GmbH

„Kubernetes nur wegen Kubernetes einzusetzen oder weil der Einsatz ohne Grund als notwendig erachtet wird (Hype), stellt den falschen Ansatz dar und kann zu einem sehr großen Anstieg der Komplexität führen, weilcher am Ende sowohl Entwickler als auch Operatoren überfordert und schlussendlich frustriert.“

Kubernetes, das direkt aus dem Google-Projekt „Borg“ heraus entstanden ist, hat sich seit seinem Start als Orchestrator für Containertechnologien vor rund vier Jahren zu einem Ökosystem mit unzähligen Tools und Projekten entwickelt. Aber ist es in jeder Situation sinnvoll, eine Plattform einzusetzen, die immer ein bisschen mehr kann, oder ist es vielleicht doch zielführender, das KISS-Prinzip zu verfolgen?

Containertechnologien zur leichtgewichtigen Kapselung von einem oder mehreren Prozessen innerhalb eines Betriebssystems existieren schon seit dem Ende der 1970er-Jahre hauptsächlich innerhalb der Unix-Betriebssystemfamilie in unterschiedlichen Formen. Mein Team und ich setzen bereits seit 2006 auf den Einsatz von Containern (OpenVZ), da sich die Verwendung von Containertechnologien bereits damals als eine sehr effiziente Vorgehensweise zur Separation unterschiedlicher Anwendungen, hauptsächlich Apache Tomcat, bewährt hat.

Natürlich ist die damals eingesetzte Containertechnologie, bis auf die grundlegende Idee der Prozessisolation, nicht mit den heutigen Möglichkeiten von Kubernetes, Docker, OpenShift und anderen Technologien vergleichbar. Der Grund hierfür ist rasch erklärt: Bis zur Veröffentlichung von Docker im Jahr 2013 existierte kein Toolset, das den Einsatz von Containern erleichtert hätte. Viele Komponenten, beispielsweise die Bereitstellung dessen, was heute unter einem Container-Image verstanden wird, war damals ein Tarball und dessen Erstellung (heute zum Beispiel mit dem docker build-Befehl) musste selbst entwickelt werden. Ebenso existierten keine Container-Registries, weshalb die Verteilung der Images selbst organisiert und implementiert werden musste. Für diese Aufgabe kamen Configuration-Management-Werkzeuge (bspw. Puppet) zum Einsatz.

Dies alles waren Gründe, warum die Migration der bestehenden Containerplattform von OpenVZ zu Docker im Frühjahr 2016 in Angriff genommen wurde. Bis zu diesem Zeitpunkt war die Verwendung von Docker aufgrund gravierender Einschränkungen, zum Beispiel dem Fehlen eines integrierten Overlay-Netzwerks, in einem größeren Umfeld wie dem unseren nicht möglich. Eine weitere Migration oder die parallele Verwendung von Kubernetes steht derzeit noch im Raum und wird laufend evaluiert, da bei allen Containerplattformen (Tabelle 1) Vorteile ebenso wie Nachteile existieren. Aufgrund der hohen Know-how-Anforderungen an die Entwickler und Entwicklerinnen sowie an die Operatoren und Operatorinnen kann eine Migration aller im Betrieb befindlicher Services durchaus viele Monate oder Jahre in Anspruch nehmen. Die OpenVZ-Plattform wird daher immer noch verwendet. Aber bleiben wir bei Kubernetes und der Frage, welches Kubernetes es denn sein darf.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Entwickler Magazin Spezial Vol. 20: Kubernetes - "Kubernetes"

Alle Infos zum Heft
579891257Macht der Einsatz von Kubernetes wirklich immer Sinn?
X
- Gib Deinen Standort ein -
- or -