© a_bachelorette/Shutterstock.com
Ergibt der Einsatz von Kubernetes wirklich immer Sinn?

Die Qual der Wahl


Kubernetes, das direkt aus dem Google-Projekt Borg heraus entstanden ist [1], 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 [2] 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 [3]. Mein Team und ich setzen bereits seit 2006 auf den Einsatz von Containern (OpenVZ [4]), 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 Befehl docker build) 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.

Kubernetes

K8s by Docker

Red Hat

AKS

EKS

GCE

On Premises

x

x

x

x*

Cloud

x

x

x

x

x

x

Hybridcloud

x

x

x

Tabelle 1: Übersicht Containerplattformen (*Kubernetes On Premises by Google (Alpha) [6])

Kubernetes? Ja, aber welches?

Um direkt zum Punkt zu kommen: Kubernetes ist ein Projekt und kein Produkt! Zugegeben, wer die GitHub-Statistiken des Kubernetes-Projekts ansieht [5], wird zustimmen, dass es sich um ein sehr großes Projekt handelt – aber nicht mehr. Kubernetes ist kein Produkt und um die Kubernetes-Plattform einsetzen zu können, existieren – abhängig von den eigenen Anforderungen und Bewertungen – unterschiedliche Möglichkeiten. Kubernetes kann von einigen IT-Unternehmen und IT-Dienstleistern eingekauft werden, zumeist als Teil eines bestehenden Produkts eines Herstellers. Einige Unternehmen, die Kubernetes anbieten, sind zum Beispiel Red Hat (OpenShift), Rancher oder Docker Enterprise. Natürlich ist es ebenfalls möglich, Kubernetes direkt selbst vom GitHub Repository des Projekts zu verwenden, in dem der Kubernetes-eigene Installer, kubeadm, verwendet wird. Für diese Variante kann anschließend jedoch nur der Communitysupport in Anspruch genommen werden. Alternativ kann Kubernetes aus der Cloud bezogen werden. Alle großen Cloudanbieter – Microsoft Azure, Amazon AWS, Google GCE, Red Hat etc. – bieten mittlerweile Kubernetes in einer PaaS-Variante an. Somit ist es ein gültiger Schluss, als Entscheidungskriterium festzulegen, ob Kubernetes on premises, in der Cloud oder sogar in einem Hybridcloudszenario eingesetzt werden soll (Tabelle 1).

Wird bereits eine Cloudumgebung als Betriebsmittel eingesetzt und wird das vom Unternehmen entwickelte Softwareprodukt Cloud-native entwickelt und betrieben, so ist die Entscheidung naheliegend, dieselbe Cloud für den Betrieb von Kubernetes zu verwenden. Ist jedoch der Einsatz von Kubernetes ebenso on premises geplant oder notwendig, wird die Entscheidung ungleich schwieriger. Dabei muss zusätzlich die Supportsituation beachtet werden. Wenn Kubernetes on premises verwendet werden soll, ist der Ausbildungsgrad der Mitarbeiter und Mitarbeiterinnen zu berücksichtigen. Entwickler sind (zumeist) keine Operatoren. Die Aufgabe von Entwicklern liegt darin, Businessapplikationen zu entwickeln, welche je nach Art des Unternehmens direkt den Gewinn erwirtschaften müssen oder die zentralen Funktionen zur Verfügung stellen, die die gewinnbringenden Prozesse innerhalb des Unternehmens unterstützen sollen. In beiden Fällen ist es die eigentliche, ursächliche Aufgabe des Entwicklers, den Code für ebendiese Anwendung(en) zu entwickeln – und nicht die Betriebsplattform zu betreiben. Bei jedem Kubernetes-Produkt, das on premises oder in der Hybridcloud zum Einsatz kommen soll, ist zumindest die fundierte Kenntnis (und Erfahrung) von Netzwerk, Storage und Virtualisierung notwendig, um Kubernetes erfolgreich einsetzen z...

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