9 Als DevOps-Engineer bei Scality habe ich mit Kubernetes-Clustern und CI/CD-Pipelines in allen großen Clouds zu tun. Zu meinen täglichen Aufgaben gehört die Pflege von Zenko (auf Englisch), daher stehen mir in der Regel große Mengen an Rechen- und Speicherressourcen zur Verfügung, um neue Infrastruktur zu testen und bereitzustellen. Ich liebe Kubernetes und würde versuchen, einen Cluster auf allem bereitzustellen – von ein paar Toastern bis zu AWS. Und dann hörte ich eines Tages die Ankündigung von Rancher (auf Englisch) zu ihrer Micro-Kubernetes-Distribution namens K3s (auf Englisch) (fünf weniger als K8s) Sofort packte mich der unwiderstehliche Wunsch, einen kleinen, tragbaren Cluster aufzubauen und K3s auf Herz und Nieren zu testen. Als langjähriger Raspberry-Pi-Fan sah ich darin natürlich die Gelegenheit für ein Herzensprojekt. Die Idee ist einfach, aber reizvoll: Man nehme ein paar Raspberry Pis und verbinde sie zu einem Kubernetes-Cluster. Neu ist die Idee keineswegs, das wurde schon gemacht; in Kombination mit diesem schlanken Kubernetes bliebe jedoch genug Platz für einige Workloads. Ich begann davon zu träumen, Zenko auf einem entfernten Edge-Gerät zu betreiben, auf dem die asynchrone Replikation in die Cloud bestens funktionieren würde. Ich dachte: „Packen wir’s an!“ DIE EINKAUFSLISTE FÜR EINEN WINZIGEN KUBERNETES-CLUSTER Zuerst die Einkaufsliste: Fünf Raspberry Pi 3B+ (plus Speicherkarten) C4 Labs „Cloudlet“-Gehäuse mit 8 Einschüben tragbarer TP-Link-Router Anker-USB-Ladegerät mit 6 Ports und 60 Watt Switch mit 8 Ports BETRIEBSSYSTEM-GERANGEL Es gibt unzählige gute Anleitungen, wie man einen Raspberry Pi mit den verschiedenen verfügbaren Betriebssystemen einrichtet. Für die Ersteinrichtung begann ich mit einem einfachen Raspbian (auf Englisch), um zu testen, ob ich ARM-Images für alle Zenko-Dienste finden oder erstellen konnte. Die Images der Schlüsselkomponenten – CloudServer (auf Englisch) und Backbeat (auf Englisch) – ließen sich mit dem Docker-Image ‚arm32v6/node‘ als Basis problemlos erstellen. Nachdem das geklappt hatte, wollte ich MongoDB testen, die zentrale Datenbank unserer Metadaten-Engine. Hier stieß ich auf mein erstes Problem: MongoDB 3.x unterstützt nur 64-Bit-Betriebssysteme. Das setze ich schon so lange als selbstverständlich voraus, dass ich vergessen hatte, dass es ein Thema ist. Zum Glück verwenden Raspberry Pis ab Version 2 64-Bit-ARM-Chips, ich musste aber dennoch ein neues Betriebssystem finden, da Raspbian nur in einer 32-Bit-Variante erhältlich ist. Eine endgültige Liste gibt es zwar nicht, doch die meisten Distributionen haben eine ‚aarch64‘-Version, die in der Regel mit den neueren Raspberry Pis funktioniert. Ich entschied mich für Fedora 29, vor allem weil es ein CLI-Tool gibt, das das Image auf die SD-Karte lädt, einen öffentlichen SSH-Schlüssel hinzufügt und das Root-Dateisystem so vergrößert, dass es die SD-Karte ausfüllt. All das sind manuelle Konfigurationen, die normalerweise nach dem ersten Start des Pi erledigt werden müssen. So konnte ich alle fünf Pis einrichten, ohne Tastatur und Monitor anzuschließen, und hatte sofort laufende Headless-Server. Hinweis: Den Download von Fedora finden Sie hier (auf Englisch). Nachdem alle Pis eingerichtet waren, blieb im Grunde nur noch die Einrichtung des Kubernetes-Clusters. Ich habe schon unzählige Cluster auf virtuellen Maschinen und Bare-Metal-Servern bereitgestellt – so oft, dass ich es wohl im Schlaf könnte –, doch diesmal war es völlig anders als alles, was ich bisher gemacht hatte. Dank des K3s-Installers hatte ich in unter fünf Minuten einen Cluster mit vier dedizierten Nodes und einem Master/Node (ohne die Zeit für die Einrichtung der Pis). Mit dem Bootstrap-Skript geht das ganz einfach. So einfach: # On the control server node curl -sfL https://get.k3s.io | sh - # Kubeconfig is written to /etc/rancher/k3s/k3s.yaml k3s kubectl get node # To setup an agent node run the below. NODE_TOKEN comes from /var/lib/rancher/k3s/server/node-token on the your server curl -sfL https://get.k3s.io | K3S_URL=https://master-node-hostname:6443 K3S_TOKEN=XXX sh - KUBERNETES IM MINI-RACK Als der Pi-Cluster mit fünf Nodes lief, war es an der Zeit, alles in ein tragbares Format zu bringen. Ziel war es, nur ein einziges Stromkabel für alles zu haben und sich überall einfach mit dem WLAN zu verbinden. Das bedeutete aber auch, dass wir uns nicht die Mühe machen wollten, jeden Raspberry Pi an jedem neuen Ort manuell einzurichten und mit dem WLAN zu verbinden. Die Lösung war einfach: Das Netzwerk selbst wird mit einem kleinen Switch und einem tragbaren Router ebenso mobil. Das Cloudlet-Gehäuse von C4Labs ist mit Blick auf das Kabelmanagement sehr durchdacht, gut verarbeitet und hat eine verständliche Anleitung für den Einbau aller Raspberry Pis. In unserem Fall wollte ich auch Platz für den tragbaren Router, den Switch und das Netzteil lassen. Glücklicherweise und rein zufällig entsprach die Länge des bestellten Switches genau der Innenhöhe des Gehäuses, sodass wir ihn senkrecht montieren konnten. So blieb unter den Pis Platz für das Netzteil, und wir konnten den tragbaren TP-Link-Router in einem der freien Einschübe montieren. Mit montierten Lüftern, angeschlossenen Pis und sauber verlegten Kabeln blieb noch ein offensichtliches Problem: Sowohl der 8-Port-Switch als auch das USB-Netzteil brauchten jeweils eine eigene Steckdose. Beim Blick auf den Switch fiel mir schnell auf, dass er mit 5 V läuft, also problemlos über USB betrieben werden könnte. Allerdings hatte ich alle sechs Ports des Netzteils bereits für die fünf Pis und den tragbaren Router belegt. WIE GEHT ES WEITER? Das war es für heute. Als Nächstes soll dieser Mini-Cluster einige Workloads durchlaufen, um die Leistung einzuschätzen, und der Einrichtungsprozess soll in einfache Ansible-Playbooks überführt werden, um das Bootstrapping mehrerer Nodes zu vereinfachen. Sagen Sie mir Ihre Meinung oder stellen Sie mir Ihre Fragen im Forum (auf Englisch).
