Raspberry Pi Kubernetes Cluster

In order to gain experience with a Kubernetes cluster or to be able to experiment with it, a functioning cluster is required. Since most conceptual challenges do not require a high performance test cluster, it is also sufficient to build a smaller and therefore more cost-effective one. For this reason I decided to set up a Raspberry Pi Kubernetes Cluster for testing purposes.

Shopping List

If the Raspberry Pis are not to be connected via WLAN but cable, the corresponding network components are also required:

Set up

The website of Hypriot has a very good tutorial how to set up a Kubernetes cluster with Raspberry Pi boards: https://blog.hypriot.com/post/setup-kubernetes-raspberry-pi-cluster/. If you need some configuration examples (executable on a Raspberry Pi Kubernetes Cluster) please check out my GitHub repository with configuration examples: https://github.com/MatthiasLohr/kubernetes-rpi-examples.

And the winner is…

GitLab!

Vielen dürfte das Problem nicht mehr ganz so am Herzen bzw. eher in der Magengrube liegen wie früher: Der Betrieb, oder noch herausfordernder, die Wahl einer Projekt-Verwaltungs-Software ist inzwischen Dank GitHub und einer Vielzahl kostenloser wie frei zugänglicher Open-Source-Lösungen heutzutage kein Problem mehr. Früher (aus meiner Perspektive am Anfang meiner universitäten und beruflichen Laufbahn) war das nicht ganz so leicht.

Trac

Vielleicht erinnern sich einige noch an Trac: Ticket-System, Wiki, Verwaltung des Code-Repositories – und das alles webbasiert. Für mich als Entwickler damals beim ersten Kontakt ein Meilenstein der Software-Entwicklung, da man eine zentrale Anlaufstelle für Code, Aufgaben und weiterführenden Informationen hatte. Wenn man als Team jedoch mehrere Projekte zu stemmen hatte, kam man dabei auch schon recht schnell an die Grenzen von Trac: Pro Projekt musste eine neue Instanz eingerichtet werden, ein automatisches Setup oder gar eine komplette Verwaltung über das Webinterface war nicht ohne Weiteres möglich. Ein bis dato noch nebensächliches, kleines Manko: Trac war limitiert auf SVN, Git, damals gerade dabei bekannt zu werden, war auch nur durch mehr oder weniger stabil laufende Plugins nutzbar.

Redmine

Auf der Suche nach einer Lösung für die Multiprojektfähigkeit, ohne jedesmal einen Administrator bemühen zu müssen, landeten wir dann bei Redmine. Webbasiertes Einrichten von Projekte, nach späteren Updates sogar mit der Möglichkeit mehrere Repositories pro Projekt anzulegen – und nebenbei natürlich Unterstützung für Git – sorgten recht schnell für eine Migration aller Trac-Projekte hin zu Redmine. Kleiner Schönheitsfehler hierbei: Die Repositories mussten immernoch per Hand initialisiert werden.

GitLab

Ein Kollege unseres Teams kam dann auf die Idee, mal mit Git herumzuspielen, und – wenn man schon dabei ist – einfach mal GitLab auszuprobieren (“Ich hab’ da mal was gehört…”). Kurzum: Trotz der gerade erst erfolgten Migration auf Redmine waren gerade die kollaborativen Funktionen von GitLab in Kombination mit Git Killer-Features, welche sehr schnell gute Argumente für eine erneute Migration der Projekte auf den Tisch brachten. Recht schnell wurde die Plattform auch außerhalb des Teams und auch über die Abteilung hinweg genutzt. Entsprechend dem aktuellen Funktionsumfang von GitLab richteten wir noch Backup-Prozesse etc. ein, Änderungen am Kern der Software waren aus unserer Sicht nicht notwendig. Alles, was wir brauchten, war eben dabei. So beschränkte sich die Tätigkeit des Teams auf Benutzung (für die Entwicklungs-Projekte, die wir betreuten) sowie das Management (Server-Betrieb, Wartung, Updates, Migrationen und Schulungen) der Plattform.