Von LAMP zu K8S - Kubernetes als lokale Entwicklungsumgebung

Wer containerd, Docker bzw. Containerisierung im Allgemeinen verwendet wird schnell feststellen, dass diese Technologie in Konsequenz auch eine Art von Orchestrierung erfordert, um flächendeckend sinnvoll eingesetzt werden zu können.

Was mit vergleichsweise einfachen Lösungen wie docker-compose, swarm und Co. angefangen hat, endet inzwischen immer öfter bei Kubernetes als Platzhirsch in Sachen Containersteuerung, ursprünglich aus dem Hause Google und nun ein Projekt der CNCF (Cloud Native Computing Foundation): Extrem mächtig, extrem gut, aber eben auch extrem komplex.

Da drängt sich die Frage auf: Will man sich Kubernetes als Basis für eine lokale Entwicklungsumgebung ans Bein binden oder nicht? Um die Antwort vorweg zu nehmen: Wir denken ja! Warum erkläre ich hier im Einzelnen:

Es gibt inzwischen einige handliche und ordentlich vorkonfigurierte Kubernetes-Setups, z.B. K3S, Microk8s und Minikube, die verschiedene Vor- und Nachteile mit sich bringen, aber vor allem eines gemein haben: Sie sind schnell und einfach installiert und auf “normaler” Entwickler-Hardware performant lauffähig.

Die Installation eines solchen vorgefertigten Kubernetes-Clusters dürfte also keinen Entwickler mehr vor eine echte Herausforderung stellen, aber wie sieht es mit der Lernkurve aus?

Was früher bei kleinen Projekten mit einem einfachen LAMP-Stack umsetzbar war - also Linux, Apache, MySQL und PHP - ist heute oft sehr viel kleinteiliger, mächtiger und komplexer. Daraus ergibt sich analog die Anforderung nach definierten, replizierbaren Komponenten und Prozessen:

• Eine Containerisierungs-Lösung wie Docker setzt diese Anforderung im Bereich der Softwarepakete nun um: Durch das Verpacken einer Applikation in ein Container-Image ist über ihre Quelldateien fest definiert, wie diese Applikation aufgebaut ist, welche Komponenten in welcher Version vorliegen und ihr Verhalten ist so deterministisch wie eben möglich. Lediglich der Kernel wird von außerhalb des Containers verwendet. Alles andere wird beim Start des Containers übergeben, in Form von hineingereichten Verzeichnissen oder Umgebungsvariablen. Und genau hier zeigt sich, dass eine Containerisierung ohne Orchestrierung nur eine Teillösung sein kann: Jetzt, da ich die Softwarekomponenten automatisiert definieren und steuern kann, möchte ich das auch mit dem Rest der Infrastruktur tun können, die ich benötige, um eine Applikation zu betreiben - und genau das ist der Job von Kubernetes:
• Man könnte sagen Kubernetes besetzt die riesige Lücke zwischen Host-Betriebssystem und Containern: Eigentlich ist es ein Service, der “nur” folgendes macht: Man gibt ihm Definitionen in Form von YAML-Dateien, wann welche Container zu laufen haben, wie sie sich verhalten sollen und welche Daten ihnen zur Verfügung gestellt werden. Klingt einfach - ist es aber ganz und gar nicht.

Die Lernkurve bei der Verwendung einer Containerisierung ist je nach Anwendungsfall und Komplexität flach bis steil: Hier geht es vor allem darum die Implikationen auf z.B. die eigene Software zu verstehen, wenn man diese in einen Docker oder mehrere getrennte Microservices aufteilen möchte und darum, unter Umständen sehr viele Komponenten aus der “alten Welt” in die Welt der Container zu migrieren.

Kubernetes legt in puncto Lernkurve dann nochmal eine Schippe obendrauf: Hier hat man es mit einem System zu tun, das aus vielen kleinen und großen Zahnrädern besteht - die muss man kennen und auch ihre Steuerung über YAML-Files bedarf einiger Übung.

Letztendlich ist aber die Frage: Wer muss was in welcher Tiefe verstehen, um damit produktiv arbeiten zu können?

“Ein Betriebssystem benutzt jeder - und kaum einer versteht es bis ins letzte Detail. Das muss so sein, denn es ist die Voraussetzung dafür, dass komplexe Systeme überhaupt entstehen und verwendet werden können.”

Man ist vielleicht geneigt zu denken, dass man die Möglichkeit verloren hat ungeplant und schnell etwas ausprobieren zu können - aber ich denke das stimmt nicht: Man muss sicherlich anfangs neu überlegen, wie man auch in Zukunft ungeplant und schnell etwas ausprobieren zu können, denn auch diese Möglichkeit ist Gold wert und darf bei einem komplexen Setup nicht auf der Strecke bleiben. Wenn das geschafft ist, freundet man sich aber sehr schnell mit Kubernetes an und lernt seine Vorteile von Tag zu Tag mehr schätzen.

In jedem Fall verloren hat man aber gebrochene Programmbibliotheksabhängigkeiten, zueinander inkompatible Pakete, sich gegenseitig beeinflussende Systemeinstellungen und vor allem aber das klassische “Bei mir läuft es aber” - Problem.

Was hat man gewonnen? Den unschätzbaren Vorteil beliebig viele Systeme und Projekte beliebiger Komplexität bis ins letzte Detail programmatisch definieren zu können, um sie so mit minimalem Zeitaufwand auch in anderen Umgebungen wieder zum Laufen bringen zu können. Also im Endeffekt genau das, was jeder Entwickler jeden Tag macht: Lokal entwickeln, auf einer Testumgebung prüfen und in eine Produktivumgebung überführen.

Hier muss man unterscheiden: Handelt es sich um den Umstieg auf Kubernetes, oder wird dafür neu entwickelt?

Der Umstieg auf eine Kubernetes-Infrastruktur mit containerisierten Workloads kann je nach Projektumfang komplex und zeitaufwändig werden. Das liegt in der Natur der Sache und darf bei der Projektierung nicht unterschätzt werden. Im Endeffekt ist die Frage: Ist es für ein Unternehmen wirtschaftlich sinnvoll in diesem Bereich zu investieren und hier rückt klar die Total Cost of Ownership in den Fokus: Ein System, das einen mittleren bis langen Lebenszyklus vor sich hat und trotzdem flexibel bleiben soll, was seine einzelnen Bausteine und auch seine Betriebsumgebung angeht, wird von Kubernetes auf jeden Fall extrem profitieren.

Wird ein Projekt neu entwickelt, ist die Entscheidung eigentlich klar: Praktisch jedes Softwareprodukt oder Modul gibt es inzwischen in Container-Form und Kubernetes bietet exakt die Plattform, die man benötigt, diese Komponenten zu schlagkräftigen Komplettsystemen zu verbinden.

Deswegen ist es auch kein Zufall, dass die größten Cloud-Anbieter, respektive Amazon Web Services, Microsoft Azure oder die Google Compute Cloud, trotz ihrer Wettbewerbssituation und unterschiedlichsten Strategien allesamt eine verwaltete Kubernetes-Lösung anbieten.

Wir bieten das an, was sich für ein normales Unternehmen nicht lohnt selbst aufzubauen, nämlich umfassendes Know-how bei Planung, Aufbau und Betrieb von containerisierten Anwendungen und Kubernetes-Clustern.

Unsere Engagements erstrecken sich dabei angefangen von reinem Consulting bis hin zur Hands-on-Umsetzung mit Ihrem Team vor Ort.