Gerade laufen viele spannende Diskussionen in der Community über Kubernetes und die dazugehörigen Tools. Aber ist Kubernetes wirklich so viel Aufmerksamkeit wert? Lohnt es sich, es im nächsten Projekt zu integrieren?
Werfen wir einen oberflächlichen Blick auf die Technologie, um diese Fragen zu beantworten. Wir beginnen mit der Definition von Kubernetes, die auf der offiziellen Website zu finden ist.
Inhaltsverzeichnis
Was tatsächlich ist Kubernetes?
Kubernetes ist ein Open-Source-System zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen.
Zunächst einmal geht es also um Container, das ist der Ausgangspunkt.
Die moderne Softwarearchitektur geht davon aus, dass eine Anwendung in miteinander verbundene logische Teile (Micro-Services) unterteilt ist, von denen jedes zur besseren Bedienbarkeit und Isolierung in einem Container gekapselt werden kann. Wenn eine Anwendung jedoch wächst, nimmt die Anzahl der Container zu, und es wird ein spezielles Tool-Set benötigt, um die Micro-Services zu orchestrieren. Sie brauchen auf jeden Fall eine Möglichkeit, alle Container in verschiedenen Umgebungen bereitzustellen, die Liveness der Container zu überwachen und eine hohe Reaktionsfähigkeit Ihrer Anwendung in der Produktion auch in Spitzenlastzeiten durch Skalierung nach oben und unten zu gewährleisten. Und das alles sollte idealerweise automatisch funktionieren, ohne ständige Aufmerksamkeit des Betriebsteams (Ops) und der Entwickler (Devs).
All das bringt Kubernetes mit sich – ein Satz verschiedener Open-Source-Komponenten (meist unter der Schirmherrschaft der Cloud Native Computing Foundation), die zusammen auf ein gemeinsames Ziel hinarbeiten: Ihre Anwendung im Cluster stabil arbeiten zu lassen.
Fehlertoleranz
Die Fehlertoleranz von Kubernetes basiert auf der Versprechens-Theorie, die dem Betreiber (der für die Bereitstellung der Anwendung verantwortlichen Person, DevOps) garantiert, dass die einmal definierte Konfiguration der Anwendung trotz des Ausfalls einiger Container oder sogar nach dem Absturz eines Teils des Clusters (virtuelle Maschinen) funktioniert.
Mit anderen Worten, das gesamte System muss fehlertolerant sein – es sollte mögliche Fehler und Ausfälle eines beliebigen Teils akzeptieren, und wenn etwas passiert, muss das System versuchen, die Anwendung gemäß der definierten Konfiguration wieder zum Laufen zu bringen. Wenn also einer der Container nicht mehr auf die Health-Checks reagiert, muss dieser Container automatisch neu gestartet werden. Wenn eine virtuelle Maschine im Cluster aus irgendeinem Grund ausfällt (z. B. Hardware- oder Netzwerkprobleme, Stromausfall oder Betriebssystemfehler), weiß Kubernetes, was zu tun ist – es verlagert die Container von der ausgefallenen Maschine auf einen anderen Knoten im Cluster und startet dann die betroffene Maschine neu, um einen “frischen” Knoten zu haben.
Es gibt nur noch einen kritischen Punkt: Wie definiert man die Konfiguration der Anwendung richtig, im richtigen Format, damit Kubernetes weiß, wie es die Infrastruktur verwalten soll? Die Konfiguration wird an die Steuerebene von Kubernetes übermittelt, und der Rest wird von dort selbst verwaltet.
Dieses Setup hat einen weiteren Vorteil: Eine so zusammengestellte Infrastruktur-/Anwendungskonfiguration kann über Git geteilt und so allen Teammitgliedern jederzeit zur Verfügung gestellt werden. So kann ein Team besser am Zustand der Infrastruktur zusammenarbeiten. Das Continuous-Delivery-System, das in jeder Umgebung installiert ist, holt sich die Konfiguration der Infrastruktur aus Git und wendet die Änderungen an, anstatt dass die Teammitglieder die Infrastruktur manuell anpassen müssen. So wird der aktuelle Zustand der Infrastruktur immer mit dem Code dokumentiert, zentral über Git verwaltet und ist für ein Team transparent. Solche nützlichen Ansätze wurden als Git Ops und Infrastructure as Code (IaC) bezeichnet.
Die neue Denkweise
In der Vergangenheit wurde jede Anwendung einzeln gehegt und gepflegt, wie eine empfindliche Pflanze im Gewächshaus. Doch mit der Einführung von Cloud-Diensten und der Containerisierung hat sich der Schwerpunkt auf die Verwaltung einer großen Gruppe ähnlicher Anwendungen verlagert, wie das Hüten von Schafen auf einem Feld. Dieser Ansatz ermöglicht einen schnellen Austausch und eine schnelle Skalierung, aber er erfordert andere Fähigkeiten und Tools, um die Herde effektiv zu verwalten.
“Schafe hüten, statt einzelne Pflanzen zu pflegen”
Die Beliebtheit von Kubernetes ist zum Teil darauf zurückzuführen, dass es neue, nützliche Tools zur Verwaltung der Herde und zur Beobachtung der Prozesse darin gibt. Sie müssen nur einmal den gewünschten Zustand von Containergruppen (Pods genannt) definieren, die Prozedur zur Überprüfung des Zustands jedes einzelnen Containers festlegen, diese Details an Kubernetes weitergeben, und das war’s eigentlich schon.
Kubernetes kümmert sich wie ein Schäferhund um die Herde: Es lädt Container-Images aus der Image-Registry herunter, stellt Container auf den Cluster-Knoten bereit, der über genügend Ressourcen verfügt, bietet Service Discovery für eine bessere Kommunikation und überwacht den Zustand der Container. Es verfolgt die Auslastung von Containern und virtuellen Maschinen im Cluster, skaliert automatisch die Anzahl der Container je nach Auslastung horizontal nach oben oder unten und kann den Cluster sogar erweitern, wenn nicht genügend Ressourcen für Ihre Container übrig sind. Ist das nicht cool?
Open Source, in der Cloud oder On-Premise
Neben Kubernetes gibt es mehrere gute Container-Orchestrierungs-Frameworks. Fast jeder große Cloud-Anbieter hat versucht, sein eigenes Container-Orchestrierungsprojekt zu entwickeln und bekannt zu machen. Der Ansatz von Google schien jedoch der theoretisch fundierteste und solideste unter den vorhandenen Tools zu sein. Nachdem Google die ersten Versionen von Kubernetes auf den Markt gebracht und intern getestet hatte, versuchte das Unternehmen, einige große Unternehmen zu gewinnen, um Kubernetes im echten Leben zu testen.
Das populäre Online-Spiel “Pokémon Go” wurde erfolgreich mit Kubernetes gehostet und verwaltet. Das Spiel hat den plötzlichen Zustrom von Spielern gemeistert. Ein unbestrittener Erfolg, sodass der nächste Schritt darin bestand, Kubernetes zur schnelleren Entwicklung und Verbreitung in die Open-Source-Community zu bringen.
Nur wenige Jahre später erlangte Kubernetes einen so guten Ruf, dass alle großen Cloud-Anbieter es nicht mehr ignorieren konnten und Kubernetes in ihr Portfolio aufnahmen. AWS, der größte Cloud-Anbieter, stellte 2017 einen Kubernetes-Managed-Service vor, weilKubernetes de facto zu einem globalen Standard geworden ist.
Kubernetes ist ein Open-Source-Projekt, das als Managed Service von jedem großen Cloud-Anbieter genutzt oder in einem On-Premise-Cluster bereitgestellt werden kann. Damit haben Sie die freie Wahl, wie und wo Sie es unter Ihren Anwendungen einsetzen wollen.
Brauchen wir Kubernetes wirklich?
Wir haben gerade die wichtigsten Funktionen von Kubernetes kennengelernt. Es sieht wirklich leistungsfähig aus und bietet viele fortschrittliche Tools. Aber natürlich ist es kein Allheilmittel für alle Ihre Anwendungsfälle. Hier sind einige Fälle, in denen Sie Kubernetes nicht für Ihre Anwendungen benötigen:
Natürlich geht es bei Kubernetes immer um Container-Orchestrierung. Wenn Ihre Anwendung nicht containerisiert ist, eignet es sich nicht für Ihre Bedürfnisse bei der Bereitstellung. Für Entwickler und DevOps kann es sehr aufwendig sein, die monolithische Anwendung auf eine Microservice-Architektur umzustellen und Microservices in Containern zu kapseln.
Kubernetes erfordert eine ausreichend hohe Einstiegshöhe, um richtig genutzt werden zu können. Neben den Kubernetes-eigenen Konzepten müssen die Entwickler die Docker-Containerisierung und die Grundprinzipien des Designs einer Cloud-freundlichen Anwendung beherrschen (hier sollte man mit zwölf Faktor-App-Konzepten beginnen). In manchen Fällen ist es sinnvoll, stattdessen eine einfachere Orchestrierung mit Docker Swarm oder Mesos zu versuchen.
Kubernetes empfiehlt, mit einem kleinen Cluster zu beginnen. Unabhängig davon, ob Sie es On-Premise installieren oder sich für die Nutzung als Managed Service entscheiden, ist es bereits ein erhebliches Budget (im Vergleich zu einem virtuellen Hosting). Daher ist bei kleineren Projekten/Anwendungen die Wahrscheinlichkeit, dass die Vorteile die Kosten überwiegen, ziemlich gering – die Einführung von Kubernetes verursacht nur mehr Aufwand, sowohl in Bezug auf Zeit als auch auf Ressourcen. Wenn Sie also keine ausreichend große Microservice-Umgebung haben, wird Kubernetes wahrscheinlich keinen großen Mehrwert bringen.
Eines der Hauptziele beim Einsatz ist die Hochverfügbarkeit. Redundanz ist Teil des Designs von Kubernetes. Selbst die empfohlene Minimalkonfiguration ist auf Hochverfügbarkeit ausgelegt. Wenn Ihre SLA also keine wirklich konstante Betriebszeit erfordert, dann ist Kubernetes vielleicht einfach zu viel des Guten.
Fazit zu Kubernetes
In Anbetracht der Argumente sollte Ihr Team zu Beginn analysieren und entscheiden, ob es machbar und kosteneffizient ist, Kubernetes im nächsten Projekt einzusetzen.
Wir bei freshcells haben schon vor Jahren mit der Einführung von Kubernetes begonnen, gleich nachdem wir unsere Produkte für die Microservice-Architektur umgestaltet hatten. Das war ein faszinierender Weg voller Herausforderungen, um das Know-how zu erlangen, das wir heute haben. Und wir müssen zugeben, dass die Umgebungen unserer Kunden, die mit Kubernetes verwaltet werden, heute viel moderner und professioneller sind als früher.
