📝 aWall goes Kubernetes [Bachelor-Thesis] (de)

aTouch GmbH Container auf ihrem Weg nach Kubernetes

tldr:

Als Projekt für meine Bachelor-Thesis wurde zusammen mit einem Projektpartner eine Deployment-Strategie und ein Monitoring-System für das Forschungsprojekt aWall des IMVS der FHNW entwickelt, um aWall auf einer Kubernetes-Plattform betreiben zu können. Dafür wurden moderne GitOps Methoden und Tools verwendet.

Vorstellung

In diesem Blog-Post möchte ich meine Bachelorarbeit vorstellen und einen kurzen Abriss über die bearbeiteten Kernthemen geben.

aWall

aWall ist ein Forschungsprojekt des Instituts für Mobile und Verteilte Applikation der Fachhochschule Nordwestschweiz zusammen mit der Firma aTouch GmbH. Das Projekt dient der Erforschung agiler Zusammenarbeit mittels extra-grosser Touchscreens. Projektdaten aus Jira werden dabei auf einem grossen Kanban-Board angezeigt, welches über Touch-Gesten gesteuert werden kann. Der grosse Screen und die intuitive Bedienung soll agile Teams zur konstruktiveren Zusammenarbeit anregen.

Das aWall System besteht dabei aus den folgenden Komponenten.

Web Client (Angular)
Mobile App (Angular & Ionic)
pySyncServer (Flask)
pyWall (Flask)
Database (PostgreSQL)

Das aWall Container Diagram zeigt wie die einzelnen Komponenten Zusammenspielen und was ihre Aufgabe ist:

aWall ist aufgrund seiner Service-Architektur für ein Deployment auf einem Kubernetes Cluster gut geeignet. Weil die aWall Software Architektur für jeden Kunden ein Set dieser 4 Hautkomponenten vorsieht (Mobile App ausgenommen), können dank des Kubernetes Cluster mehrere Kundeninstanzen auf geteilten Resourcen parallel laufen. Jede pyWall Instanz wird für jeden Kunden individuell über eine Config-Map konfiguriert.

💡

Kubernetes ist ein Container Orchestrierungs-Tool, welches in der Sprache Go und ursprünglich von Google entwickelt wurde. Die Stärke von Kubernetes liegt in ihrer API, die es Entwickler:Innen erlaub, einfache bis hoch komplexe verteilte Applikationen von manuell bis komplett automatisiert zu deployen.

Erarbeitete Lösung

Damit aWall weg von dedizierten virtuellen Machinen und Docker-Compose hin zu einem voll automatisierten Kubernetes Deployment mit Observability kommt, braucht es weitere Subsysteme, welche dies ermöglichen. Das System Context Diagram bildet die Lösung in ihren einzelnen Sub-Systemen ab.

Grob lassen sich die 4 einzelnen Teilsysteme wie folgt zusammenfassen:

Infrastructure as Code System zur provisionierung des Clusters
Als Source of Truth sind die einzelnen GitLab Repositories zusammengefasst welche vom Gesammtsystem benötigt werden
Deployment System welches vollautomatisch das Cluster Bootstrapped gemäss den in der Single Source of Truth beschriebenen Manifesten
Monitoring oder Observability-System welches Einblick in das System mittels Metriken und Traces gewährt

IaC System

Das Cluster wird bei Azure Kubernetes Service (AKS) gehostet. Um dieses wiederum zu provisionieren, wird Terraform verwendet. Das HCL Skript ist in einem GitLab Repository abgelegt, welches ebenfalls den Terraform State verwaltet. So können verschiedene Entwickler:Innen Änderungen am Cluster vornehmen, ohne dass es zu Konflikten kommen sollte.

Dank des deklarativen Infrastructure-as-Code Ansatzes kann das Cluster nach belieben auf-/abgebaut, repariert oder dupliziert werden.

Deployment System

Ist das Cluster aufgebaut, wird Argo CD über über den von den Entwickler:Innen zur verfügung gestellten Helm Chart auf dem Cluster in einem eigenen Namespace installiert. Die Schritt für Schritt Anleitung dafür befindet sich in GitLab.

💡

Helm bezeichnet sich selbst als Package-Manager für Kubernetes und ist ein weit verbreitetes Tool um Applikationen auf Kubernetes zu deployen. Die für eine Applikation benötigten Kubernetes-Ressourcen (z.B. Container, Services oder Persistant Volumes) können als sogenannten Helm-Chart zusammengefasst und mit anderen Entwickler:Innen geteilt werden. Über ein YAML file können Values (Variablen) im original Manifest überschrieben werden, um Anpassungen oder Konfigurationen vorzunehmen.

Argo CD ist ein Deployment Tool für Kubernetes, welches einen GitOps Ansatz verfolgt. Das heisst kurz gesagt, dass alle im Cluster deployten Ressourcen als YAML Manifeste in einem Git-Repository versioniert und abgelegt sind, damit Argo CD sie gemäss deren Konfiguration automatisch und kontinuierlich im Cluster deployen kann. Das angesprochene Git-Respository nennt man Single-Source-of-Truth, weil es nur eine zentrale Stelle gibt, in welcher der zu erreichene Zustand einer App beschrieben wird. Falls eine Deployte App von der in Git Beschriebenen Deklaration abweicht, spricht man von Drift. Diesen Drift erkennt Argo CD und kann darauf reagieren, sprich korrigieren, warnen, etc. Dank des sogenannten Apps-of-Apps Pattern, kontrolliert Argo CD fortlaufend, ob es Veränderungen in der Single-Source-of-Truth gegeben hat und wird zum Beispiel ein neues Manifest für eine aWall Umgebung hinzugefügt, so erstellt Argo CD diese automatisch. Das gesammte Cluster-Bootstrapping, also alle weiteren im Cluster laufenden Applikationen für das Monitoring, Tracing oder der Ingress Controller, werden ebenfalls über Argo CD erstellt und verwaltet. Damit ist das Cluster-Setup relativ einfach und das benötigte Kubernetes-Know-How relativ klein.

Observability

Um aWall überwachen und passende SLO's definieren zu können, werden die einzelnen Systemkomponenten über Prometheus überwacht. Prometheus ruft in regelmässigen Abständen den /metrics Pfad der einzelnen Komponenten auf, um die aktuellsten Metrikdaten in der Time-Series Database abzuspeichern.

Screenshot des Metrics Endpunkt von pyWall

Eine Metrik ist im wesentlichen ein Label und ein Zahlenwert. Dieser kann zum Beispiel als Counter über eine Anzahl Aufrufe oder als Gauge über eine aktuelle Auslastung auskunft geben. Mit Grafana können die gesammelten Werte grafisch dargestellt werden. Das hier gezeigte Dashboard zeigt wie das aussehen kann.

Des weiteren verfügt aWall über ein Tracing System. Jede Systemkomponente sendet sobald ein Request eintrifft einen Span an den Trace Collector. Diese Spans lassen sich über Headerinformationen zu Traces aggregieren, welche schön aufzeigen, wie sich ein Request durch das System bewegt. Das kann in Zukunft helfen Fehler schneller finden zu können. Für aWall wurde Jaeger verwendet, da es den OpenTelemetry Standard nativ unterstützt und open-source ist.

😅

Zur Observability gehört eigentlich auch das geordnete sammeln von Logs. Wir haben ursprünglich versucht die zwei Python Applikationen mittels Open-Telemetry zu überwachen. OTel verspricht einen einheitlichen Standard für die sogenannten "Three Pillars of Observability" - Metrics, Logs & Traces - zu bieten. Dieser Hersteller agnostische Standard ist noch ziemlich neu. Deshalb fehlt es noch hier und da an Dokumentation und Anleitungen. Gewisse Features (zum Beispiel das sammeln von Logs mit OTel und Flask) waren während des Projekts noch als experimentell gekennzeichnet. Leider haben wir es nicht geschafft, die Komponenten mit Auto-Instrumentation und Side-Cars zu überwachen, weshalb wir auf einen konventionelleren Ansatz umgestiegen sind.

Zur Visualisierung der Bachelorarbeit wurden C4-Modell Grafiken verwendet. Mehr informationen dazu findet sich unter c4model.com.