Neben MicroK8s eignet sich auch kubeadm für den Aufbau von Kubernetes-Clustern auf Mini-PCs oder Raspberry-Pi-Systemen. kubeadm ist das klassische Werkzeug für vollständige Kubernetes-Installationen und bietet maximale Kontrolle über Aufbau und Zusammensetzung der Control Plane. Gerade in Edge-Szenarien ist diese Transparenz von Vorteil. Als Betriebssys-tem empfiehlt sich auch hier Ubuntu 24.04 LTS. Aktivieren Sie zunächst die benötigten Kernelmodule für Overlay-Dateisysteme und Netzwerk-Bridging:

Die Funktionsfähigkeit eines Kubernetes-Clusters hängt wesentlich von korrekt konfigurierten Control Groups ab. Sie bilden die Grundlage für das Ressourcenmanagement, das Kubernetes zur Begrenzung von CPU und Arbeitsspeicher für Pods nutzt. Ohne aktive Cgroups kann das kubelet keine verlässlichen Ressourcenlimits durchsetzen. Prüfen Sie daher vor der eigentlichen Cluster-Installation mittelscat /proc/cgroups, ob die Unterstützung aktiv ist.

Die Ausgabe listet alle unterstützten Ressourcengruppen auf. Entscheidend ist die letzte Spalte, die den Aktivierungsstatus angibt. Ein gesetzter Wert bedeutet, dass der Kernel die jeweilige Control Group unterstützt. Für Kubernetes ist insbesondere die Gruppe "memory" relevant. Ist sie nicht aktiv, fehlt dem System eine zentrale Voraussetzung für stabiles Ressourcenmanagement. In diesem Fall müssen Sie die Kernel-Boot-Parameter entsprechend anpassen, bevor Sie fortfahren.

Nach der Systemvorbereitung installieren Sie containerd als Container-Runtime:

Im nächsten Schritt richten Sie die Kubernetes-Werkzeuge ein. Binden Sie dazu das offizielle Kubernetes-Repository ein und importieren Sie den zugehörigen GPG-Schlüssel:

Aktualisieren Sie anschließend die Paketinformationen übersudo apt updateund installieren Sie danach die drei zentralen Werkzeuge kubelet, kubeadm und kubectl mitsudo apt install -y kubelet kubeadm kubectl. Um Versionssprünge durch automatische Updates zu vermeiden, fixieren Sie die installierten Pakete mittelssudo apt-mark hold kubelet kubeadm kubectl. Nach Abschluss dieser Schritte ist der Knoten vollständig vorbereitet. Er verfügt über alle notwendigen Komponenten, um Teil eines kubeadm-basierten Kubernetes-Clusters zu werden oder selbst als Control-Plane-Knoten zu dienen.

HA-Control-Plane initialisieren

Ein Kubernetes-Cluster mit mehreren Control-Plane-Knoten benötigt eine fes- te Adresse, unter der der API-Server dauerhaft erreichbar ist. In klassischen Rechenzentren übernimmt diese Aufgabe ein dedizierter Loadbalancer. Auf Edge-Hardware wie Raspberry Pi oder Mini-PCs eignet sich dafür Kube-VIP. Das Werkzeug stellt eine virtuelle IP-Adresse bereit, die jeweils von einem der Control-Plane-Knoten gehalten wird. Fällt dieser Knoten aus, übernimmt ein anderer die Adresse automatisch. Der API-Server bleibt erreichbar, ohne dass Clients oder Worker-Knoten umkonfiguriert werden müssen.

Bevor Sie den Cluster initialisieren, definieren Sie daher eine freie IP-Adresse in Ihrem Netzwerk, zum Beispiel "10.0.78.50". Diese Adresse dient anschließend als zentraler Einstiegspunkt für alle kubeadm-Operationen und als feste Anlaufstelle für kubectl. Sobald die Control-Plane-Adresse feststeht, initialisieren Sie den ersten Knoten mit:

Achten Sie darauf, dass Swap vollständig deaktiviert ist, wie bereits bei MicroK8s beschrieben. Tritt während der Initialisierung ein Fehler auf, liegt die Ursache in Edge-Umgebungen häufig an nicht korrekt konfiguriertem IP-Forwarding.

Der Parameter "net.ipv4.ip_forward" bestimmt, ob der Kernel IPv4-Pakete zwischen Netzwerkschnittstellen weiterleiten darf. Kubernetes ist auf diese Funktion angewiesen, da Pods, Services und Overlay-Netzwerke intern geroutet werden. Ist IP-Forwarding deaktiviert, bricht kubeadm bereits während der Preflight-Checks ab und verweist explizit auf die Datei "/proc/sys/net/ipv4/ip_forward". Unter Ubuntu reicht es nicht aus, den Wert nur temporär per Sysctl zu setzen. Zwar aktivieren Sie die Weiterleitung kurzfristig mit:

Doch systemd-networkd setzt diesen Wert beim nächsten Neustart oder Netzwerk-Reload wieder zurück. Für einen stabilen Betrieb müssen Sie IP-Forwarding daher an zwei Stellen dauerhaft konfigurieren. Erstellen Sie zunächst eine Sysctl-Konfigurationsdatei, zum Beispiel:

Tragen Sie dort die Zeile "net.ipv4.ip_forward=1" ein und laden Sie die Systemkonfiguration neu mittelssudo sysctl --system. Damit systemd-networkd diese Einstellung nicht überschreibt, ergänzen Sie zusätzlich eine Netzwerkkonfiguration. Legen Sie unter "/etc/systemd/network/" ein Drop-in an, etwa "99-kubernetes-forwarding.conf", und setzen Sie darin:

[Network]

Starten Sie anschließend den Netzwerkdienst neu mitsudo systemctl restart systemd-networkdund prüfen Sie abschließend den Status mit cat/proc/sys/net/ ipv4/ip_forward. Der Wert muss dauerhaft "1" anzeigen. Sind beide Anpassungen korrekt gesetzt, akzeptiert kubeadm die Initialisierung der Control Plane ohne Preflight-Fehler. Dieser Schritt ist für Installationen auf Raspberry Pi und Mini-PCs besonders wichtig. Edge-Systeme basieren häufig auf minimalen Betriebssysteminstallationen, bei denen IP-Forwarding aus Sicherheitsgründen standardmäßig deaktiviert ist. Ohne diese Anpassung lässt sich ein hochverfügbarer Kubernetes-Cluster nicht zuverlässig betreiben.

Kubeadm erwartet in einer hochverfügbaren Control Plane einen festen Einstiegspunkt für den Kubernetes-API-Server. In klassischen Rechenzentren übernimmt diese Aufgabe ein Hardware- oder Software-Loadbalancer. Auf Mini-PCs oder Raspberry-Pi-Clustern kommt stattdessen häufig Kube-VIP zum Einsatz. Das Werkzeug fungiert als leichtgewichtiger Layer-2-Loadbalancer und stellt eine virtuelle IP-Adresse bereit, die von jeweils einem Control-Plane-Knoten gehalten wird.

Kube-VIP läuft als statischer Pod auf jedem Control-Plane-Knoten. Fällt der aktive Knoten aus, übernimmt ein anderer automatisch die virtuelle IP. Der API-Server bleibt damit erreichbar, ohne dass Clients oder Worker-Knoten angepasst werden müssen. Diese virtuelle IP-Adresse muss bereits verfügbar sein, bevor Sie kubeadm init ausführen. Ist das nicht der Fall, bricht die Initialisierung mit einem Timeout ab, da kubeadm den API-Server über die angegebene Adresse nicht erreichen kann. Bereiten Sie Kube-VIP daher vor der Initialisierung der Control Plane vor. Laden Sie zunächst das Container-Image mit containerd und definieren Sie ein Alias für den Aufruf:

Erzeugen Sie anschließend das Manifest für den statischen Pod und legen Sie es im Verzeichnis "/etc/kubernetes/manifests" ab:

Kubelet erkennt statische Pod-Manifeste in diesem Verzeichnis automatisch und startet den Kube-VIP-Pod ohne weitere Schritte. Die virtuelle IP ist damit verfügbar. Falls ein vorheriger Initialisierungsversuch mit kubeadm fehlgeschlagen ist, setzen Sie den Zustand zurück, bevor Sie fortfahren:

Initialisieren Sie anschließend die Control Plane mit der virtuellen IP-Adresse als festen Endpunkt:

Kubeadm erzeugt nun alle benötigten Zertifikate, startet die Control-Plane-Komponenten und legt die Konfigurationsdateien unter "/etc/kubernetes" ab. Damit Sie kubectl auf diesem Knoten verwenden können, kopieren Sie die Administrationskonfiguration in Ihr Benutzerverzeichnis:

Kubectl kann nun über die virtuelle IP-Adresse mit dem API-Server kommunizieren. Als nächsten Schritt richten Sie ein CNI-Plug-in ein, das die Pod-Kommunikation ermöglicht. In vielen Edge-Szenarien bietet sich Calico an, da es stabil arbeitet und nur geringe Systemressourcen benötigt. Das Setup entspricht weitgehend der aus klassischen Kubernetes-Installationen. Nach der erfolgreichen Initialisierung des ersten Knotens erweitern Sie die Control Plane um weitere Nodes. Kube-adm zeigt während der Initialisierung einen Join-Befehl an, den Sie unverändert auf den weiteren Geräten ausführen. Ein typisches Beispiel sieht so aus:

Der Parameter "--control-plane" weist kubeadm an, diesen Knoten als weiteren Bestandteil der hochverfügbaren API-Ebene einzubinden. Sobald mindestens drei Control-Plane-Knoten aktiv sind und alle dieselbe virtuelle IP nutzen, gilt die Control Plane als hochverfügbar. Im Anschluss binden Sie weitere Worker Nodes ein, konfigurieren Runtime, Kernelparameter und Netzwerk und testen den Cluster mit ersten Workloads. Ein so aufgebautes System verhält sich funktional wie ein Kubernetes-Cluster im Rechenzentrum, bietet jedoch die Flexibilität und Nähe zur Datenquelle, die für Edge-Szenarien entscheidend ist.

Kubernetes-Installationen auf Mini-PCs und Raspberry-Pi-Geräten unterscheiden sich grundlegend von klassischen RZ-Umgebungen. Die zugrunde liegende Hardware setzt physikalisch, thermisch und infrastrukturell deutlich engere Grenzen. Während Server im Rechenzentrum mit leistungsstarken Multi-Core-CPUs, redundanten Netzteilen, beschleunigten Netzwerkkarten und hochverfügbaren Speichersystemen arbeiten, stehen im Edge-Umfeld nur begrenzte Ressourcen zur Verfügung.

Ein Raspberry Pi 4 oder 5 bietet wenige ARM-Kerne und maximal 8 oder 16 GByte RAM. Mini-PCs wie Intel NUCs oder industrielle Box-PCs liefern zwar mehr Leistungsreserven, bleiben aber deutlich unterhalb klassischer Serverknoten. Diese Unterschiede wirken sich unmittelbar auf Architektur, Deployment und Betrieb der Kubernetes-Cluster aus.

Die Pod-Dichte pro Node fällt im Edge-Umfeld entsprechend geringer aus. Während ein Rechenzentrumsserver problemlos mehrere Dutzend oder sogar hunderte Pods tragen kann, stößt ein Raspberry-Pi-Worker deutlich früher an seine Grenzen. Das tatsächliche Limit hängt vom Workload-Profil, dem Overhead des CNI-Plug-ins und der Größe der Container ab. Sie müssen Requests und Limits daher wesentlich strenger definieren. Speicherintensive Anwendungen wie Datenbanken oder Machine-Learning-Modelle erreichen schnell die physikalischen Grenzen der Hardware. Eine konservative Kapazitätsplanung und engmaschiges Monitoring sind im Edge-Kontext unverzichtbar, um Überlastsituationen zu vermeiden.

Auch beim Storage zeigen sich deutliche Unterschiede zum Rechenzentrumsbetrieb. Produktions-Cluster setzen auf verteilte Systeme wie Ceph, dedizierte Storage-Appliances oder Fibre-Channel-SANs. Edge-Systeme arbeiten dagegen meist mit lokal angebundenen SSDs oder MicroSD-Karten. Letztere eignen sich aufgrund begrenzter Schreibzyklen nur eingeschränkt für dauerhafte Workloads. USB-SSDs oder NVMe-Module, etwa beim Raspberry Pi 5 über PCIe-Adapter, bieten deutlich bessere Haltbarkeit und Performance. Sie erreichen jedoch nicht annähernd die IOPS-Werte professioneller Speichersysteme. Für persistente Volumes empfiehlt sich daher ein zurückhaltender Ansatz, etwa über NFS-Shares oder einfache lokale Storage-Classes. Hochverfügbare, verteilte Storage-Backends lassen sich im Edge-Umfeld nur mit zusätzlicher Hardware sinnvoll umsetzen.

Das Netzwerkverhalten unterscheidet sich ebenfalls deutlich. Edge-Cluster stehen häufig hinter NAT-Routern, nutzen einfache Switches und arbeiten mit 1-GBit-Ethernet oder sogar nur 100-MBit-Anbindungen. Latenzschwankungen treten häufiger auf, Paketverluste entstehen etwa durch elektromagnetische Einflüsse oder unzureichend geschirmte Leitungen. Diese Rahmenbedingungen wirken sich direkt auf Overlay-Netzwerke, die Replikation des Cluster-Zustands und auf Service-Mesh-Komponenten aus. Netzwerk-Plug-ins wie Calico oder Flannel arbeiten zuverlässig, erreichen jedoch nicht den Durchsatz hochperformanter Rechenzentren. Sie sollten Edge-Cluster daher konsequent auf Stabilität und Fehlertoleranz optimieren, nicht auf maximale Paketverarbeitung. Das gilt auch für Loadbalancer-Komponenten wie Kube-VIP oder MetalLB.

Schließlich unterscheiden sich auch der Betrieb und die Wartung der Cluster deutlich. Große Kubernetes-Umgebungen werden kontinuierlich über CI/CD-Pipelines aktualisiert, nutzen Git-Ops-Workflows, Canary-Releases und automatisierte Sicherheitsprüfungen. Edge-Cluster in industriellen Umgebungen verfügen oft nicht über eine permanente Anbindung an zentrale Build- und Managementsysteme. Updates erfolgen zeitversetzt, manuell oder in klar definierten Wartungsfenstern. Die eingesetzte Kubernetes-Distribution muss daher besonders robust sein. MicroK8s überzeugt hier durch transaktionale Updates über Snap. K3s bietet schlanke, gut kontrollierbare Binary-Updates. Kubeadm-basierte Cluster auf Mini-PCs erfordern dagegen dieselbe Disziplin wie große Installationen, allerdings mit deutlich mehr Rücksicht auf begrenzte Hardware, fehlende Redundanzen und eingeschränkte Netzwerkbedingungen.

Ein wesentlicher Vorteil des Edge-Betriebs liegt in der hohen Flexibilität bei Platzierung und Einsatz der Hardware. Mini-PCs und Raspberry Pis lassen sich direkt in Schaltschränken, Fertigungsinseln, mobilen Fahrzeugen oder wettergeschützten Außenboxen betreiben. Faktoren wie Lärmentwicklung, Abwärme oder verfügbare Rack-Flächen verlieren damit an Bedeutung. Während klassische Server aufwendige Kühlsysteme benötigen, genügen bei Edge-Geräten oft passive Kühlkörper, kleine Lüfter oder industrietaugliche Aluminiumgehäuse mit Heatpipes.

Durch die Nähe zur Datenquelle ergeben sich zusätzliche Vorteile. Hardware lässt sich direkt an Maschinen, Robotern oder Kamerasensoren montieren. Latenzen sinken, und das Netzwerk wird entlastet, da Rohdaten nicht erst über weite Strecken durch das Unternehmensnetz übertragen werden müssen. Gerade bei zeitkritischen Anwendungen wirkt sich diese lokale Verarbeitung unmittelbar positiv auf Reaktionszeiten und Stabilität aus.

Die physische Nähe zur Anlage bringt jedoch neue Herausforderungen mit sich. Temperatur, Luftfeuchtigkeit, Vibrationen und die Qualität der Stromversorgung beeinflussen die Lebensdauer der Geräte direkt. Raspberry-Pis arbeiten zwar äußerst stromsparend, reagieren jedoch empfindlich auf Spannungsschwankungen. Industrielle Mini-PCs bieten hier Vorteile durch robuste Gehäuse, stabile Netzteile und erweiterte Temperaturtoleranzen, verursachen jedoch höhere Anschaffungskosten. Kubernetes gleicht viele dieser Risiken aus. Fällt ein Gerät durch Hitze oder Hardwaredefekte aus, übernimmt der Cluster die Work-loads automatisch, sofern mindestens zwei weitere Knoten verfügbar bleiben.

Zusätzlich profitieren Edge-Umgebungen von den schnellen Hardwarefortschritten der vergangenen Jahre. Der Raspberry Pi 5 zeigt, dass kompakte ARM-Systeme inzwischen die Rolle autonomer Mikroserver übernehmen können. Die native PCIe-Anbindung ermöglicht den Einsatz von NVMe-Modulen und beseitigt frühere I/O-Engpässe. Davon profitieren insbesondere etcd, Dqlite und lokale Volumes, die auf stabile und schnelle Schreiboperationen angewiesen sind.

Der Einsatz von NVMe-Speicher reduziert die Ausfallanfälligkeit klassischer SD-Karten deutlich. Hohe I/O-Raten sorgen für kurze Latenzen bei Workload-Wechseln, schnelle Pod-Neustarts und ein insgesamt robusteres Verhalten bei Lastspitzen oder temporären Störungen. In Kombination mit PoE-Plus-Stromversorgung lassen sich Raspberry-Pi-5-Systeme zudem zentral über Switches versorgen und sicher in geschlossenen Schaltschränken betreiben. Damit wird Edge-Kubernetes nicht nur leistungsfähiger, sondern auch betrieblich deutlich zuverlässiger.

Mini-PCs und Raspberry-Pi-Systeme bieten zwar deutlich weniger Ressourcen als klassische Server, ermöglichen dafür aber eine flexible Platzierung, geringe Leistungsaufnahme und die unmittelbare Verarbeitung von Daten nahe an der Quelle. Mit angepassten Architekturentscheidungen lassen sich auch auf dieser Hardware robuste Cluster betreiben.

MicroK8s punktet im Edge durch einfache Installation, integrierte Hochverfügbarkeit und transaktionale Updates. Kubeadm bietet maximale Kontrolle über die Cluster-Architektur, erfordert jedoch mehr manuelle Konfiguration und Disziplin im Betrieb.

(dr)