Kubernetes

Kubernetes auf der lokalen Entwicklermaschine installieren

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?

Der steinige Weg vom klassischen LAMP-Stack über Docker bis hin zu Kubernetes

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

Was haben wir verloren und was haben wir gewonnen?

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.

Fazit

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.

Was wir 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.

Idee und das Ziel

Ich würde am liebsten mein Handy bzw. Google Assistant (Also auch Google Home) direkt fragen können, ob ich eigentlich gerade joggen gehen kann, oder nicht. Entscheidend dafür ist eigentlich nur ein irgendwo in der Nähe abgerufener Pegelstand des Flusses. Klar - ein kurzer Blick darauf würde reichen, aber mir geht es primär um die Tüftelei und die Frage, ob ich diese Aufgabe mit den Mitteln moderner Digitalisierung umgesetzt bekomme.

Ich möchte in diesem Artikel einen Überblick darüber geben, was mit "Enterprise"-Tools wie Rancher2, Kubernetes, Docker, DialogFlow und OCR auch im kleinen Freizeit-Rahmen schnell und einfach umgesetzt werden kann. Er ist nicht als Schritt-für-Schritt-Anleitung zu verstehen, um etwas vergleichbares nachzubauen. Das würde den Rahmen des Artikels sprengen und es gibt zu allen unten aufgeführten Themen sehr umfangreiche Dokumentation im Netz.

Recherche, Materialsammlung und Umsetzung

Nach kurzer Suche im Netz wurde ich fündig: Eine behördliche Website veröffentlicht im 15-Minuten-Takt den Pegelstand einer Messstation nur wenige Kilometer entfernt. Neben Pegelstands-Grafiken gibt es glücklicherweise auch eine reine Zahlentabelle, die allerdings nur als Bilddatei zur Verfügung steht.

Nach weiteren Recherchen zum Thema und dem Vorwissen aus der täglichen Arbeit mit Rancher, Kubernetes und Docker bin ich letztendlich auf folgende Liste benötigter Tools gekommen und habe mit der Umsetzung angefangen:

Docker Nr. 1

Ein Script, das den aktuellen Pegelstand herausfindet und anhand dessen die Entscheidung fällen kann, ob man joggen gehen kann, oder nicht:

• Eine Variable, die definiert ab welchem Wasserstand der Weg überflutet ist. Aus der Erfahrung heraus habe ich hier mal ca. 85cm angenommen.
   
• wget, um die Pegelstands-Tabellen-Grafik der Website herunter zu laden. Offenbar ändert sich der Dateiname über Zeit nicht und die Grafik wird im 15-Minuten-Takt einfach überschrieben.
   
• tesseract-ocr - Eine OpenSource OCR-Software, um aus dem Bild wieder eine reine Text-Tabelle aus Datumsfeld und Pegelstand in Zentimetern zu generieren. Die Software ist denkbar einfach zu verwenden: Bild angeben, Text herausbekommen.
  
  Es gibt einige Optionen und Parameter mit denen ich experimentiert habe, aber das beste Ergebnis ist bereits mit den default-Einstellungen erreichbar. Lediglich das Paket für die Unterstützung der deutschen Sprache sollte man noch installieren, wenn man keine reinen Wertetabellen erkennen lassen möchte.
  
  Ein interessantes Learning gab es hier allerdings: Meine Tests mit tesseract habe ich lokal unter Ubuntu 18.04 durchgeführt. Ich wollte für meinen Docker zunächst alpine Linux verwenden, um das resultierende Docker-Image so klein wie möglich zu halten. Daraufhin bekam ich keinerlei Messwerte mehr aus meinem Script zurückgemeldet. Ein Blick unter die Haube zeigte dann, dass die tesseract-Version, die in Alpine als Package integriert ist, erheblich schlechtere Erkennungsergebnisse bei gleichem Input liefert. Ob es sich einfach um eine ältere tesseract-Version handelte oder im tesseract von Alpine andere Erkennungsmodelle verwendet werden habe ich nicht weiter untersucht. Ich habe stattdessen auf Ubuntu 18.04 als Dockerbasis umgestellt.
   
• grep, awk, cut - Diverse Shell-Tools, um das OCR-Ergebnis gegen eine restriktive RegularExpression zu filtern, da nicht alle Zeilen immer zuverlässig erkannt werden. Aus dem neuesten Pegelstands-Wert und dem Datum  ir dann ein eine vom Google Assistant verarbeitbare Antwort im JSON-Format erstellt. Das JSON soll in eine Datei geschrieben werden, da der OCR-Prozess wegen des großen Bildes doch einige Sekunden benötigt und das Ergebnis jederzeit asynchron abgerufen werden können soll.
   
• Dieses Script soll als CronJob laufen, also periodisch ebenfalls alle 15 Minuten aufgerufen werden und die genannte JSON-Datei erstellen.
   
• docker - dieses Script soll in einem eigenen Docker ausgeführt werden, damit die o.g. Pakete gekapselt sind.

Das Script - die olivgrün hinterlegten Variablen übergebe ich aus der Kubernetes-Umgebung heraus.

Docker Nr. 2

Ein Go-Script meines Kollegen Matthias, das einen Webserver bereitstellt und bei einem GET-Aufruf ein vorher via Environment-Variable definiertes Shell-Kommando ausführt und das Ergebnis ausgibt. Hier also einfach ein "cat /mnt/pegelstand/pegelstand.json". So spare ich mir einen nginx oder apache. Das script steht bereits als binary in einem Docker zur Verfügung. Der soll allerdings nicht als CronJob, sondern als stetig verfügbarer Webserver-Service ausgeführt werden.

Rancher2 / Kubernetes

Ich habe bereits einige von Rancher2 verwaltete Kubernetes-Cluster zur Verfügung stehen. Es ist also naheliegend die beiden oben genannten Docker auf einem dieser Cluster zu deployen: Den Ersten als CronJob, der alle 15 Minuten ausgeführt wird und den Zweiten als normales Deployment. CronJobs und normale Services im gleichen Pod zu halten ist von Kubernetes nicht vorgesehen - ich kann daher nicht auf ein Ephemeral emptyDir als Volume zurückgreifen, sondern muss ein normales Verzeichnis vom Host als shared Volume verwenden.

Nachdem das lief, habe ich unter Rancher2 einen passenden Ingress erstellt, damit externe Zugriffe auf das JSON-File möglich werden. Dazu gehört auch die Installation des Certbot-Kubernetes-Charts, um letsencrypt-TLS-Zertifikate erhalten zu können.

Screenshot des Projekts in Rancher2, der den Kubernetes-Cluster steuert.

Google Assistant Integration mit DialogFlow

Mit diesem Teil der Lösung kannte ich mich bis dato am wenigsten bzw. gar nicht aus - höchste Zeit also, sich hier mal etwas einzuarbeiten: Bei meinen Recherchen zum Thema GoogleAssistant-Integration bin ich immer wieder über "api.io" gestolpert, was inzwischen "DialogFlow" heißt. Das Unternehmen wurde von Google aufgekauft, gehört inzwischen zum Konzern, ist sehr tief mit Googles API Console verwoben und ist eine Art Baukasten, um Dialogprozesse zwischen dem Nutzer und Google Assistant zu modellieren.

Nach dem Anmelden bei DialogFlow, was soweit ich sehen konnte auch ausschließlich über das Google-Konto erfolgt, landet man direkt in einer gut strukturierten Oberfläche in der man seinen ersten Dialog erstellen kann.

Ab diesem Zeitpunkt gibt es zahlreiche Ein- und Aussprungpunkte zwischen der DialogFlow-Oberfläche und der Google Cloud bzw. Google API Console und dem Assistant-Simulator. Ich bin noch nicht tief genug in das System eingestiegen um einschätzen zu können, ob ich die gewünschte Lösung nicht auch mit Google-Bordmitteln ohne Dialogflow hätte realisieren können, es hat den Prozess beim ersten Mal aber erheblich vereinfacht - zumindest scheint es mir aktuell so.

Das Ergebnis sieht dabei so aus, dass man den Google Assistant zunächst dazu bringen muss in den richtigen Dialog einzusteigen - so, als wenn man eine App startet. Erst danach kann man konkrete Fragen stellen, auf deren Antwort man Einfluss hat. Mir ging es nun darum meine eigene Antwort aus dem im Netz zur Verfügung gestellten JSON vorlesen zu lassen. Durch das hinzufügen eines Fulfillment-Objekts zu meinem Dialog, dem ich wiederum mein JSON-File als Webhook-URL zuweisen kann ging das ganze dann auch wie gewünscht.

So sieht das ganze auf DialogFlow aus.

Fazit

Es klappt! \o/ Ich kann meinem Google Assistant jetzt ansprechen mit "Hey Google, starte Pegelstand" (Das muss leider sein) und danach: "Kann ich heute joggen gehen?". Daraufhin erhalte ich aktuell die Antwort: "Joggen ist möglich, der Wasserstand beträgt xy Zentimeter. Gemessen am soundsovielten etc.". Das ganze war in ein paar Stunden erledigt, was für die verwendeten Tools und die Tatsache, dass ich mich mit dem Google Assistant vorher nur aus Anwendersicht auseinandergesetzt habe, eine positive Überraschung war.

Hier ein kurzes Youtube-Video, das das Ergebnis zeigt:

Nachtrag

Ich habe in der zwischenzeit noch ein paar Kleinigkeiten verbessert, die die Leistung und die Erkennungsqualität verbessert haben:

• In der ersten Version habe ich tesseract mit der Sprachbibliothek für Deutsch laufen lassen, auch wenn das für die Erkennung der reinen Zahlentabellen natürlich unnötig ist. Beim Testen habe ich dann festgestellt, dass die Erkennungsrate bei gleichem Input ohne das Deutsch-Wörterbuch erheblich besser ist. Ich kann nur spekulieren, warum das so ist, aber die Ergebnisse sind eindeutig. Deswegen läuft das System jetzt nur noch mit dem reinen tesseract Basissystem ohne Angabe der Sprache.
• Da ich nur die erste (erkannte) Zeile des relativ großen Bildes (Es ist eine sehr lange Tabelle) verwende ist es unnötig, die gesamte Tabelle per OCR zu verarbeiten. Ich habe daher noch imagemagick im Docker installiert, um das Bild zuzuschneiden. Dadurch ist der gesamte Prozess auf 2-3 Sekunden Gesamtlaufzeit optimiert worden. Damit könnte man jetzt ggf. auch eine synchrone Abfrage ermöglichen und den Cronjob dadurch einsparen.