Bisher gibt es die offizielle Docker Registry lediglich als x86 Docker Image. Damit ist ein Betrieb unter ARM oder ARM 64 aktuell nicht möglich. Obwohl Docker Multi-Arch-Support eingeführt hat, also die Möglichkeit unter dem selben Image-Namen verschiedene Architekturen zu bedienen, ist das bei dem hauseigenen Image leider noch nicht umgesetzt worden. In diesem Beitrag geht es nun darum, ein passendes Image durch Cross-Compilation zu erstellen und damit eine Registry bereit zu stellen.

Der Betrieb des mit Docker erstellen Image wird unter CRI-O erfolgen, womit die Interoperabilität, dank der Standardisierung von OCI, unter Beweis gestellt wird.

Um auf Kubernetes-Dienste zuzugreifen gibt es mehrere Möglichkeiten, eine davon ist der Ingress. Ingress eignet sich für HTTP basierte Dienste und kann Funktionalitäten wie TLS-Terminierung und Load-Balancing übernehmen. Im Prinzip handelt es sich bei Ingress also um so etwas wie einen Reverse-Proxy.

Kubernetes bringt dabei keine Ingress-Implementierung mit, sondern es gibt diverse Optionen von nginx über HA-Proxy und Apache Trafficserver bis zu traefik. Wie traefik als Kubernetes-Ingress-Implementierung eingesetzt werden kann, wird in diesem Beitrag vorgestellt.

In einer Public-Cloud-Umgebung wird dauerhafter Speicher für Kubernetes in der Regel durch den jeweiligen Cloud-Provider bereitgestellt. Bedarf an dauerhaften Speicher gibt es dabei regelmäßig, wenn Daten nicht in den jeweiligen Datenbanken oder Messaging-Systemen der Umgebung gehalten wird, sondern lokale.

Wird der Kubernetes Cluster sogar lokal betrieben, gibt es entsprechnd keinen Cloud-Provider, der Storage in Form von Object-Store oder Block-Storage zur Verfügung stellen könnte. Neben NFS und iSCSI, mit denen klassische SAN-Systeme angebunden werden können, wächst auch das Angebot an Cloud-Native-Storage. Dabei handelt es sich um Softwarelösungen, die flexibel und dynamisch Speicher im gesamten Kubernetes Cluster zur Verfügung stellen können.

In diesem Beitrag wird der Einsatz von Rook (https://www.rook.io) auf einem ARM 64 Cluster mit ODROID C2 Knoten demonstriert.

Um Anwendungen erfolgreich bauen zu können, ist - je nach Anwendung - ein hoher Aufwand in die Einrichtung der Umgebung zu investieren. Beispielsweise für ein Android-Projekt muss Java installiert sein, es werden die Android-Tools mit dem Android-SDK benötigt und der Build muss passend konfiguriert werden. Dieses Setup wird aber nicht nur auf den Entwickler-Rechnern benötigt, auch die Countinuous-Integration-Umgebung des Buildservers muss entsprechende Werkzeuge bereitstellen. Um Reproduzierbarkeit zu gewährleisten, sollte sichergestellt sein, dass in allen diesen Umgebungen die gleichen Versionen der Tools genutzt werden.

In diesem Artikel werden wir uns damit beschäftigen, wie auf einfachem Wege eine zur Entwicklung von Android-Projekten geeignete Umgebung mit Hilfe von Docker erstellt werden kann. Am Beispiel von Gitlab-CI wird der Einsatz des entsprechenden Docker-Containers in einer CI-Umgebung gezeigt.

Kubernetes bietet eine Weboberfläche zur Clusterverwaltung bzw. Administration: Das sogenannte Kubernetes Dashboard. Das Dashboard gibt es als vorbereitetes Deployment für die Architekturen AMD/Intel 64 und ARM. Leider gibt es derzeit kein fertiges ARM 64 Deployment. Wer das reguläre ARM Deployment ausprobiert, wird zwar die zugehörigen Resourcen erfolgreich erzeugen, jedoch wird der Container nicht erfolgreich starten und in der Folge wird der Pod-Status mit einem der Fehler Error oder CrashLoopBackOff ausgegeben.

Das Setup von Kubernetes mit Arch Linux ARM 64bit auf einem ODROID C2 wurde im vorherigen Beitrag zu Kubernetes gezeigt. Als Overlay-Network wurde Weave verwendet, was leider im Zusammenspiel mit dem ODROID C2 Linux Kernel zu Abstürzen durch eine Kernel Panic führen kann. Die zugehörige Issue findet sich hier: https://github.com/weaveworks/weave/issues/3314

Eine Lösung ist, auf den "Fast Data Path" zu verzichten, was zur Folge hat, dass die Performance sich verringert und die CPU Belastung steigt. Alternativ kann der ODROID C2 mit einem aktuellen Linux Kernel, dem Mainline (oder Upstream) Linux Kernel verwendet werden.

Nachdem im vorherigen Beitrag zu Kubernetes gezeigt wurde, wie mittels CRI-O ein Kubernetes Master Node eingerichtet wird, folgt nun eine Worker Node. Das besondere auch hier: Es wird Arch Linux auf ARM 64bit Architektur verwendet.

Für das Setup wird kubeadm verwendet, daher wird auch die Ausgabe von einem Kubernetes-Master Setup benötigt, da dort das erforderliche Token ausgeben wird.

Auch wenn Docker stand heute die vermutlich am weitesten verbreitete Container-Lösung darstellt, gibt es doch einen regen Wettbewerb. Besonders seit Kubernetes in Version 1.5 das Container-Runtime-Interface (CRI) eingeführt hat, mit dem sich die tatsächliche Container-Implementierung austauschen lässt. Das CRI-O Projekt stellt einen Adapter zwischen der durch die OCI (Open Container Initiative) spezifizierten Schnittstellen für Container-Runtimes und dem durch Kubernetes mit CRI definierten Integrationspunkten dar. Standardmäßig verwendet CRI-O die OCI konforme Containerimplementierung runc.

Andere OCI kompatible Laufzeitumgebungen wie rkt oder Intel Clear Container lassen sich damit ebenfalls einsetzen. In einem typischen Docker basierten Setup sähe die Interaktion so aus:

Mit CRI-O sieht die Interaktion so aus:

Der Stack bei CRI-O ist also deutlich geringer, ist jedoch als auf Kubernetes fokussierter Stack auch kein vollständiger Ersatz für die vielen verschiedenen Anwendungsfälle von Docker.

Im folgenden geht es um das konkrete Setup von CRI-O mit Kubernetes unter Arch Linux ARM.

Auch wenn Arch Linux meist topaktuelle Pakete hat, so ist dies bei Projekten wie Kubernetes auf der ARM Architektur nicht der Fall. Auch im AUR, also dem von der Community gepflegten Bereich, finden sich für ARM 64 bit keine Kubernetes Pakete. Es ist jedoch relativ einfach, sich auf Basis des Quellcodes von Kubernetes einen eigenen Build zu erzeugen. Damit sind sowohl für ARM 32bit als auch ARM 64bit eigene Arch Linux Kubernetes Pakete in überschaubarer Zeit und mit nur wenigen Handgriffen gebaut.

Wie das geht, wird im folgenden Beitrag erklärt.

Im Artikel Kubernetes Cluster mit Raspberry Pi wurde ein Cluster-Setup mit Raspberry Pi Computern gezeigt. Als Alternative dazu bieten ODROID-C2 Maschinen doppelt so viel RAM und auch etwas mehr CPU Leistung. Viel wichtiger ist dabei jedoch die deutlich bessere Netzwerkanbindung mit 1Gbit, die auch tatsächlich erreicht werden. Der ODROID unterstützt schnellen eMMC Speicher und UHS-1 SDR50 MicroSD, der preislich deutlich günstiger als die eMMC Module sind. Der ODROID besitzt als Hauptspeicher DDR3 SDRAM Module, die rund doppelt so hoch getaktet sind, wie die LPDDR2 des Raspberry Pi 3. Preislich liegt ein Raspberry Pi 3 bei ca. 36 Euro und ein ODROID C2 bei 58 Euro - je nach Einsatzzweck ist das Preis-Leistungsverhältnis bei dem ODROID deutlich besser. Die ARMv8 Architektur des ODROID C2 wird von Arch Linux und Ubuntu Cloud als 32 und 64 bit Variante unterstützt, Raspian gibt es bisher lediglich als 32 bit Variante.

Ein Nachteil beim 64bit Betrieb ist der etwas höhere Speicherbedarf. Zwar hat der ODROID mit 2GB RAM doppelt so viel Speicher wie der Raspberry Pi, doch für den Betrieb vieler Container kann man nie genug Speicher haben. Hier kann man nun von einem Trick profitieren, der in ähnlicher Form bereits auch von Apple standardmässig eingesetzt wird, um Nutzern auch mit relativ wenig Speicher ein gutes Gesamterlebnis zu bieten.

Ein Mini-Cluster für Kubernetes eignet sich hervorragend für Experimente und zum Training. Wie beispielsweise in Kubernetes Cluster mit Raspberry Pi erklärt, eignen sich für einen kostengünstigen Start Raspberry Pi Minicomputer ausgezeichnet. Leider ist ARM aktuell nicht im Fokus der diversen Cloud-Native Storage Lösungen, so dass sich als Alternative ein externes Volume anbietet. Das häufig anzutreffende Synology NAS bietet NFS Support. Wie sich dies mit Kubernetes einsetzen lässt, wird im folgenden illustriert.

Sowohl für Trainings als auch eigene Experimente ist ein physischer Cluster oft anschaulicher, als virtuelle Maschinen. Als preiswerter Einstieg bieten sich bereits seit geraumer Zeit die Raspberry Pi Minicomputer an. Für rund 40 Euro pro Gerät erhält man einen Rechner mit 1 Gb RAM und vier ARM Kernen. Dazu wird noch eine USB Stromversorgung und MicroSD Speicherkarten benötigt, und schon kann es los gehen.