Produktiv arbeitende Kubernetes-Cluster erstrecken sich über mehrere physische Server. Dabei spielt es keine Rolle, ob die Kubernetes-Nodes direkt auf der Hardware laufen oder einen – heute eigentlich überflüssigen – Virtualisierungslayer dazwischen verwenden. Viele der hier bereits erschienenen Artikel zu Kubernetes setzen für praktische Beispiele aber auf Single-Node-Setups, wie sie in erster Linie von Anwendungsentwicklern benutzt werden. Es gibt jedoch eine zunehmende Reihe von Szenarien, in denen Single-Node-Setups auch im praktischen Einsatz durchaus Sinn machen. Im Artikel "Weit draußen" in Ausgabe 4/23 [1] haben wir bereits über das Basis-OS-Setup für Edge-Devices berichtet. Immer mehr Anwender statten diese Edge-Devices mit einer simplen Kubernetes-Umgebung aus.

Zum einen können Sie diese über ein zentrales Cluster-Management wie etwa Open Cluster Manager (Artikel "Alle mit einem", Ausgabe 4/23) [2] verwalten. Zum anderen müssen Sie dann Ihre Anwendungen nur noch für eine Zielplattform, nämlich Kubernetes, entwickeln und testen. Praktische Beispiele hierfür sind unter anderem Warenwirtschaftssysteme. Auf den zentralen Kubernetes-Clustern im Datacenter laufen dabei die Komponenten für Lagerhaltung, Rechnungs- und Bestellwesen. Für die Kassensysteme der Filialen genügen kleine Edge-Server mit der Kassenapplikation in einem Kubernetes-Container.

Allerdings lassen sich leistungsfähige Kuberntes-Plattformen, wie Rancher (Suse) oder OpenShift (Red Hat), nicht so einfach auf einem einzelnen Node aufsetzen. Das wäre technisch zwar machbar, ergibt jedoch wenig Sinn, da die vollausgestatteten Plattformen selbst mehrere dutzend Container betreiben. Für den Edge-Betrieb offerieren daher verschiedene Hersteller abgespeckte Kubernetes-Distributionen, die selbst nur wenige Container beanspruchen. Von diesen Distributionen betrachten wir drei in diesem Artikel:

1. K3s (Suse)

2. Microshift (Red Hat)

3. MicroK8s (Canonical)

Es gibt natürlich auch andere "Kleindistributionen" wie etwa Kind, MiniKube oder K3D. Die lassen wir an dieser Stelle einmal außen vor, da sie sich in erster Linie für den Betrieb auf Entwickler-Desktops eignen.

K3s ist der kleine Bruder von Ranchers Kubernetes Engine (RKE), die seit Dezember 2020 zur Suse GmbH gehört. Die Distribution existiert seit 2019 und lässt sich mit minimalen Ressourcen betreiben. Laut Hersteller läuft K3s sogar auf Maschinen mit lediglich einem CPU-Kern und 512 MByte RAM, da das minimale K3s-Setup selbst nur 250 MByte verbraucht. Zu den radikalen Sparmaßnahmen gehört, dass K3s in der Grundkonfiguration auf die I/O-intensive etcd-Datenbank als Konfigurationsspeicher verzichtet und stattdessen Sqlite nutzt. Das reicht für den Single-Node-Betrieb auf einem Edge-Device.

Darüber hinaus erlaubt K3s aber auch einen Multi-Node-Betrieb. Die Distribution unterscheidet dabei zwischen einem K3s-Server, der die Kuberentes-Management-Pods betreibt, und einem K3s-Agenten, der lediglich Applikations-Pods ausführt. Diese Funktion erweist sich auch im Edge-Einsatz als durchaus praktisch. Schafft ein einzelnes Edge-Device die Workloads alleine nicht mehr, fügt der Administrator einfach einen zweiten Agent-Node hinzu. K3s erlaubt es aber auch, mehrere K3s-Server für die Redundanz der Control-Plane zu betreiben, dann natürlich auch mit etcd.

Das verleiht K3s eine Flexibilität, die anderen kleinen Kubernetes Distributionen fehlt: Der Anwender kann mit einem einzelnen Node anfangen und diese Kubernetes-Umgebung bei Bedarf im laufenden Betrieb erweitern. K3s kann dabei ein bestehendes Single-Node-Setup mit Sqlite zu etcd konvertieren und die Control-Plane auf das übliche Drei-Knoten-Setup erweitern.

Weitere Sparmaßnahmen finden sich beim Storage, Netzwerk und beim Proxy. K3s setzt auf den Reverse-Proxy Traefik für die IP-Routen, anstelle des sonst üblichen, aber ressourceintensiveren Nginx. Das bedeutet jedoch, dass Anwender gegebenenfalls bestehende Deployment- und/oder Stateful-Sets-Konfigurationen ihrer Applikationen ändern müssen. Hier werden gerne Ingress-Routen via Nginx definiert und nicht mit Traefik. Für die virtuellen Pod-Netzwerke kommt das simple Overlay-Netzwerk Flannel mit vxlan zum Einsatz. Andere CNI-Treiber sind optional möglich.

Als Storage-Provider nutzt K3s per Vorgabe den simple Hostpath-Treiber. Der unterstützt zwar nur Filesystemspeicher und das auch nur ohne Redundanz, aber für den Edge-Betrieb reicht das völlig aus. Zudem stellt Hostpath keine besonderen Anforderungen an die Platte des Knotens oder deren LVM-Setup und kommt darüber hinaus mit minimalen Ressourcen aus. Wie auch beim Netzwerk ist K3s in Sachen Storage flexibel. Falls hostpath nicht genügt, lässt sich natürlich jeder beliebige andere Storage-Provider (longorn, rook) nachrüsten.

Die Installation von K3s könnte kaum simpler sein. Als OS werden nahezu alle gängigen Linux-Distributionen unterstützt, wie SLES, OpenSuse, RHEL, Fedora, Centos-Streams, EL-Klone (diese selbstverständlich mit aktivem SELinux) sowie Ubuntu, Debian und Raspberry Pi OS. Bei den CPUs beherrscht das kleine Kubernetes die üblich verdächtigen 64-Bit-ARM und x86_64-Prozessoren und selbst auf s390x soll die Distribution laufen. Als Container-Engine setzt K3s wie die meisten Kubernetes-Distributionen auf das bevorzugte cri-o. Dank 64-Bit-Arm-Support läuft K3s auch auf Nvidia Developer Boards (wie Jetson, AGX, Xavier oder Orin) mit Unterstützung der dort verbauten GPU.

Das Installations-Skript lässt sich direkt über das Internet herunterladen und ausführen. Es richtet die nötigen Pakete und Repositories für das Setup ein, startet die lokalen Dienste und Pods. Bei einem Single-Node-Setup ohne besondere Konfigurationsänderungen läuft Kubernetes auf dem Rechner innerhalb von wenigen Minuten. Die Verwaltung des Setups erledigt der Administrator über die Kommandozeile oder Client-Admin-Tools wie K9s oder OpenLens.

K3s präsentiert sich alles in allem als leicht zu installierende, ressourcensparende und extrem flexible Distribution. Gut gefällt die Option, ein Single-Node-Setup um einfache Agenten zu erweitern oder das Setup nachträglich auf einen Cluster hochzurüsten.

Die abgespeckte Edge-Variante von Red Hats OpenShift trägt nur inoffiziell den Namen "Microshift", denn die Trademark dieses Begriffs liegt bei einer Firma, die Gangschaltungen für Fahrräder herstellt. Das Projekt "RHDE" (Red Hat Device Edge) existiert seit 2022 und befindet sich noch in der Entwicklungsphase. Die Installation erfordert aktuell einen Red-Hat-Account. Microshift lädt Container-Images von der geschlossenen Red Hat Container Registry und benötigt dafür ein sogenanntes Pull-Secret. Ein freier Developer-Account genügt hierfür.

Microshift packt die essenziellen Kubernetes-Dienste in einen einzigen Systemd-Service auf dem Edge-Host. Dieses Paket enthält auch etcd als Konfigurationsspeicher. Somit sollen laut Hersteller 1 GByte RAM und ein CPU-Kern (ARM64 oder x86_64) genügen. Microshift verlangt selbst 500 MByte RAM – das ist mehr als bei K3s, da hier Module wie Nginx als Reverse-Proxy, etcd, OVN (Networking via OpenVswitch statt Flannel) und TopoLVM zum Einsatz kommen.

Die Installation auf RHEL 9 erfolgt zum einen über ein RPM-Paket und den DNF-Packet Manager. Dazu muss der Administrator zuerst zwei Repositories hinzufügen. Alternativ lässt sich Microshift mithilfe des Image-Builders (siehe [1]) in ein OSTree-Abbild packen. Das soll auch das präferierte Rollout für die Edge-Kubernetes-Distribution werden. Das Setup erfordert zudem ein spezielles Layout der angebundenen Disk. Da Microshift auf TopoLVM als Speichertreiber setzt, muss es auf dem System eine Volume-Group namens "RHEL" mit freiem Platz für logische Volumes geben. Beim initialen Set-up des RHEL-Systems müssen Sie darauf achten, dass das "Root"-LV genügend freien Platz lässt.

Auch bei Microshift kommt die cri-o-Container-Runtime zum Einsatz, die das Setup automatisch mitinstalliert. Nach dem initialen Start benötigt Microshift ein paar Minuten, um die zugehörigen Pods und Dienste zu starten. Vor allem TopoLVM als Storage-Treiber lässt sich hier gerne etwas mehr Zeit.

Neben den regulären Kubernetes-APIs liefert Microshift auch ein paar Open­Shift-Extensions für Security und Route mit. Besonders die OpenShift-Route als Alternative zur Ingress-Route ist für Anwender interessant, die auf anderen Clustern OpenShift einsetzen. Damit müssen sie bestehende Deployments und StatefulSets zumindest in Sachen Routen nicht anpassen. Ein Multi-Node-Betrieb ist für kommende Versionen angedacht, aber aktuell noch nicht implementiert.

Die abgespeckte Edge-Version von Open-Shift bietet bereits solide Funktionen, kann aber noch nicht mit der Flexibilität von K3s mithalten. Das gilt besonders für den optionalen Multi-Node-Betrieb. Gut gefallen bei Microshift hat uns die Integration in den Image-Builder für OSTree-Edge-Builds und die enthaltenen Open-Shift-Routen. Als Open-Source-Projekt hängt Microshift aktuell aber noch zu stark an kommerziellen Produkten wie RHEL und der geschlossenen Red Hat Registry. Hier wird es künftig hoffentlich ein komplett quelloffenes Projekt geben, das dann auch ohne Quay-Account auf freien Systemen wie Fedora läuft. Auch lässt die aktuelle Upstream-Dokumentation sehr zu wünschen übrig, beschreibt sie doch das Setup der Version 4.8 vom April 2022 und nicht die aktuelle Version 4.14.

Ob der Umstieg des Microshift-Projekts vom Speichertreiber hostpath auf TopoLVM eine gute Idee war, muss die Praxis zeigen. Zwar erlaubt TopoLVM Funktionen wie PV-Snapshots, braucht dafür aber mehr Ressourcen (ganze acht Container), mehr Zeit für das PV-Provisioning und eine aufwändigere Plattenkonfiguration.

Die abgespeckte Variante von Canonicals Kubernetes hört auf den Namen MicroK8s. Auch hier gibt der Hersteller den minimalen RAM-Bedarf der Distribution mit rund 500 MByte an. Die Grundinstallation bringt weder einen Ingress-Router wie Trafik oder Nginx mit und installiert auch keinen Default-Storage-Treiber. Canonical gruppiert diese Funktionen in Add-ons, die sich über das microk8s-Kommando zusätzlich installieren lassen. So kann sich der Anwender aussuchen, was er für sein Setup braucht. Auch MicroK8s verzichtet in der Basisvariante auf etcd als Konfigurationsspeicher. Hier kommt eine Eigenentwicklung namens "Dqlite" zum Einsatz, eine verteilte In-Memory-Variante von Sqlite. Anders als bei den meisten anderen Kubernetes-Distributionen nutzt MicroK8s auch nicht die übliche – vom Kubernetes-Projekt präferierte – cri-o-Container Engine.

Hier bettet Canonical direkt containerd ein, wie sie auch Docker einsetzt. Erschwerend kommt hinzu, dass das MicroK8s-Setup nicht über den regulären Paket-Manager apt (Ubunut/Debian), sondern Canonicals "snap" läuft. Damit landen die benötigten Binaries und Konfigurationsdateien nicht in den genormten Linux-Verzeichnissen wie "/etc/" oder "/var", sondern irgendwo unterhalb von "/snap/microk8s/xxxx/" und "/snap/bin/". Das erschwert das Debugging und die Fehlersuche. Installationen mit cri-o liefern beispielsweise das Tool "crictl" mit, um Informationen zu laufenden Containern und Images abzurufen. Eine ähnliche Funktion soll "ctx" für containerd liefern, was mit Canonicals schrägem Snap-Setup aber nicht ohne weiteres funktioniert. Somit arbeitet MicroK8s auch nicht auf Systemen mit SELinux, sondern nur mit Canonicals AppArmor.

Als Netzwerktreiber kommt Calico anstelle von Flannel zum Einsatz. Über die Add-ons kann MicroK8s aber auch mit anderen CNIs arbeiten, wie beispielsweise Kube-OVN (OpenVswitch).

Das Aufspielen auf einem Ubuntu 22.04 LTS-Server fällt sehr simpel aus. Bereits während der OS-Installation selbst kann der Administrator den MicroK8s-Snap hinzufügen. Das "microk8s"-CLI-Tool gibt Auskunft über das laufende Setup und verwaltet zudem die gewünschten Add-ons. Ebenfalls via microk8s-cli kann der Anwender weitere Knoten hinzufügen. Das Tool generiert für jeden neuen Knoten ein individuelles Token, über das ein neu aufgesetzter Host später dem Cluster beitreten kann.

Das laufende System verwaltet der Administrator lokal via "microk8s kubectl" oder über das kubectl-Tool auf seiner Arbeitsstation. MicroK8s liefert das Kubernetes-Dashboard als Add-on mit. So lässt sich mit einem einzigen Kommando dem Kuberentes-Setup eine Web-UI hinzufügen.

Auch Canonicals Mini-Kuberntes-Setup gibt dem Anwender viele Freiheiten beim Setup. Die Distribution läuft sowohl auf einem einzelnen Knoten ohne Network-Ingress als auch in einem Cluster-Verbund mit etcd und OVN. Gut gefällt bei der Distribution das Add-on-Konzept, was besonders Kubernetes-insteigern entgegenkommt. Tools, die der Administrator sonst über yaml-Dateien mit Deployments und RBAC-Konfigurationen manuell einrichten müsste, setzt microk8s mit einem einzigen "enable"-Kommando auf.

Negativ fallen jedoch Canonicals selbstgestrickte Komponenten und Konstruktionen wie dlite, K8s auf containerd und das verwirrende snap-Setup ins Gewicht. Wo sich andere Hersteller an die etablierten Standards und Tools mit einer jeweils großen Community halten – Projekte wie cri-o, etcd, sqlite haben mindestens das Zehnfache an Developern und Commits gegenüber den Canonical-Tools – braut Canonical eigene Süppchen.

Immer wieder hatte der Hersteller über die Jahre versucht, den Anwendern alternative Lösungen zu den gängigen Standards unterzujubeln, meist mit geringem Erfolg. Als OpenStack sich als Scale-Out-VM-Architektur etablierte, setzte Canonical auf das weitgehend unbekannte Eucalyptus. Dem populären Docker setzte Ubuntu LXC/LXD entgegen und der Unity-Desktop statt Gnome fand auch nicht unbedingt viele Freunde. Der Anwender sollte sich also genau überlegen, ob er Ressourcen und Lernaufwand in Tools und Architekturen investiert, die längerfristig vielleicht nicht bestehen.

Alle drei betrachteten Kleindistributionen bieten eine relativ einfache und kompakte Kubernetes-Distribution für den Betrieb auf einem Edge-Device oder einer kleinen Branch-Office-Umgebung. Microshift liefert eine sehr gute Edge-Integration über den OSTree-Image-Builder, läuft aktuell jedoch nur und ausschließlich als Single-Node-Setup. Im derzeitigen Enticklungsstatus ist die Distribution zu eng an kommerzielle Red Hat Produkte und Dienste gebunden. Als Open-Source-Projekt sollte das Tool frei von geschlossenen Registries funktionieren.

MicroK8s von Canonical macht den Anwendern den Einstieg in Kubernetes sehr leicht und skaliert bei Bedarf von einem simplen, funktionsreduzierten Single-Node zum Cluster. Gut gefällt das Bundeling verschiedener Dienste als "Add-ons", die sich mit einem einzigen Kommando einrichten lassen. Negativ fällt hier jedoch das Fehlen von SELinux ins Gewicht. Canonicals selbstgestrickte Tools wie dqlite und das verwirrende snap-Setup können auch nicht jeden Anwender überzeugen.

K3s stellt sich als flexible Distribution dar, die ebenfalls vom simplen Edge-Setup bishin zu einem kleinern Cluster skalliert. Die Umgebung ist sehr einfach aufgesetzt, läuft auf verschiedenen Distributionen und unterstützt SELinux. Zudem setzt K3s durch die Bank auf gut gepflegte Standardprojekte wie cri-o und sqlite. Gut gefällt auch die Migrationsoption, die den Umstieg von sqlite auf etcd im laufenden Betrieb erlaubt, wenn ein Anwender sein Single-Node-Setup auf einen Cluster hochrüsten möchte.