In klassischen IT-Umgebungen sind Dienste fest an Server, IP-Adressen und Routen gebunden. Fällt ein System aus, muss der Administrator eingreifen, Maschinen neu starten, Backups aktivieren und Clients umkonfigurieren. Solche Szenarien gehören seit Jahrzehnten zum Alltag im Rechenzentrum. Kubernetes löst diese enge Kopplung auf und trennt Applikationen konsequent von der darunterliegenden Infrastruktur. Ressourcen und Dienste erhalten in Kubernetes eindeutige Namen und bleiben unabhängig von physischen Hosts oder IP-Adressen erreichbar. Anwender greifen etwa über einen festen DNS-Namen wie "five.apps.firmenname-intern.ip" auf eine Applikation zu – auf welchem Knoten oder sogar in welchem Rechenzentrum sie gerade läuft, spielt keine Rolle. Selbst der Ausfall mehrerer Cluster-Knoten bleibt transparent, solange Kubernetes die Applikation neu starten kann.

Damit diese Dynamik zuverlässig funktioniert, muss jedoch die Cluster-Architektur stimmen. Genau hier greifen viele Administratoren noch zu statischen Konzepten wie festen Ressourcenzuweisungen oder Aktiv/Standby-Konstrukten, die der Arbeitsweise von Kubernetes entgegenstehen. In diesem Artikel schauen wir uns die Grundlagen einer sauberen Cluster-Architektur für Kubernetes an und zeigen praxisnahe Setups für unterschiedliche Einsatzszenarien.

Controller und Worker verstehen

Während Administratoren früher externe Werkzeuge wie Pacemaker für Failover-Szenarien einsetzen mussten, bringt Kubernetes Hochverfügbarkeit bereits im Management-Framework mit. Grundsätzlich unterscheidet Kubernetes zwei Knotentypen: Controller, die die Verwaltungsdienste und die Konfigurationsdatenbank betreiben, sowie Worker, auf denen die eigentlichen Applikationen laufen. In größeren Umgebungen halten Administratoren User-Workloads in der Regel von den Controllern fern, da ein falsch konfigurierter Pod mit hohem Ressourcenverbrauch die Performance der Control Plane beeinträchtigen kann. In kleineren Edge-Setups oder Außenstellen ist es hingegen durchaus üblich, Applikationen auch auf Controller-Knoten zu betreiben.

Ein Kubernetes-Controller führt die zentralen Kernkomponenten des Clusters aus. Der API-Server nimmt alle Anfragen entgegen, verwaltet diese und leitet sie an die registrierten API-Endpunkte weiter. Kubernetes selbst stellt dabei lediglich das Management-Framework bereit, die eigentliche Arbeit übernehmen die jeweiligen Endpunkte. Der API-Server läuft parallel auf allen Controller-Knoten im Active/Active-Modus und wird über einen vorgeschalteten Loadbalancer angesprochen. Die Verteilung der Arbeitsanweisungen übernimmt der Scheduler. Aktiv ist dabei immer nur der Scheduler eines Controller-Knotens, während die übrigen passiv bleiben. Der Dienst "kubelet", der auf allen Worker- und Controller-Knoten läuft, empfängt die Anweisungen des Schedulers und setzt sie lokal um.

Ausfallsicherheit im Cluster einrichten

Konfiguration und Status des Clusters speichert Kubernetes in der Key/Value-Datenbank "etcd". Sie ist das zentrale Kernstück jedes Kubernetes-Clusters, und Probleme damit wirken sich unmittelbar auf den gesamten Betrieb aus. etcd läuft auf allen Controller-Knoten und repliziert die In-Memory-Datenbank untereinander. Zusätzlich sichern die Controller die Daten regelmäßig auf lokale Datenträger. etcd arbeitet nach dem Leader/Follower-Prinzip: Nur ein Knoten nimmt Schreibzugriffe entgegen, die übrigen replizieren die Änderungen. Fällt der Leader aus, übernimmt automatisch einer der verbleibenden Knoten dessen Rolle.

Für einen stabilen Betrieb ist eine ungerade Anzahl von Controller-Knoten erforderlich, um Split-Brain-Szenarien zu vermeiden. In der Praxis setzen die meisten Anwender auf drei Controller. Nur in sehr großen Clustern kommen fünf Controller zum Einsatz. Mehr Knoten erhöhen die Ausfallsicherheit nicht weiter, sondern wirken sich im Gegenteil negativ auf die Performance aus. Mit steigender Anzahl replizierender Knoten verlangsamt sich etcd. Für den produktiven Cluster-Betrieb planen Sie daher – unabhängig von der verwendeten Kubernetes-Distribution – drei Server mit schnellen NVMe-Datenträgern, leistungsfähigem Netzwerk und ausreichend performanten ECC-RAM.

Kleine und Single-Node-IoT-Installationen können optional auf etcd verzichten. In diesen Szenarien kommen einfache Backends wie SQLite über den etcd-Kompatibilitäts-Layer kine zum Einsatz, was allerdings ausschließlich für Single-Controller-Setups geeignet ist.

CNI-Netzwerke: Calico, Flannel & OVN nutzen

Damit die Container überhaupt miteinander kommunizieren können, braucht ein Kubernetes-Cluster ein "Container Network Interface", kurz CNI. Darüber erhält jeder Container die Netzwerkanbindung und seine IP-Adresse. Viele einfache Distributionen (zum Beispiel K0s, K3s) setzen auf Flannel. Das arbeitet als einfaches Overlay-Network mit VxLAN-Tunneln. Flannel ist zwar simpel, birgt aber eine Reihe von Risiken: VxLAN-Tunnel beherrschen beispielsweise keine TLS-Verschlüsselung. Zudem bringt Flannel keine Policy Engine mit. Jeder Container kann jeden anderen Container per IP ansprechen – selbst wenn dieser in einem anderen Namespace arbeitet und einem anderen Nutzer gehört. Schleust ein Nutzer einen "bösen" Container in den Cluster ein, kann dieser mit Tools wie Nmap die Ports anderer Container scannen und diese attackieren.

Abhilfe schafft ein CNI wie Calico, das mit Policys das IP-Routing begrenzen und Container in ihren eigenen Namespace einsperren kann. Distributionen wie Canonical Kubernetes nutzen Calico, während RKE2 (Rancher) mit Canal eine Kombination aus Flannel und Calico verwendet. OpenShift nutzt ein virtuelles Netzwerk mit Open-vSwitch OVN. Das verwendet das modernere Geneve-Tunneling-Protokoll, das anders als VxLAN TLS-Verschlüsselung unterstützt. Der OVN-CNI kann zur Verschlüsselung auch Netzwerk-Policys verwenden, um die Netzwerkkommunikation verschiedener Namespaces voneinander zu isolieren.

CNIs lassen sich modular laden und verwenden. K8s-Distributionen sind nicht zwingend an den Default-CNI gebunden, mit dem sie geliefert werden. Sie könnten – mit etwas Mehraufwand – beispielsweise OVN auf K0s installieren und betreiben.

Mit Ingress und Traefik externes Routing steuern

CNIs regeln den Netzwerkverkehr innerhalb des Clusters. Um mit der Außenwelt kommunizieren zu können, braucht es zusätzlich den passenden Router und Loadbalancer, der Anfragen von außen per CNI an die Applikations-Pods verteilt. Dieser Router fungiert als Reverse-Proxy mit name-based Routing. Bis vor Kurzem setzten die K8s-Distributionen hierbei überwiegend auf Nginx.

Allerdings wird dieses Tool zunehmend von Traefik verdrängt. Dieser kompakte und schnelle Loadbalancer mit Reverse-Proxy wurde speziell für Container-Umgebungen entwickelt. Zu seinen großen Stärken zählt, dass sich Traefik sehr schnell dynamisch umkonfigurieren lässt – worauf es im Kubernetes-Umfeld ankommt. Daher nutzen Distributionen wie K0s, K3s und RKE2 als Standard Traefik. OpenShift geht einen Eigenweg mit dem OpenShift-Router auf Basis des etablierten HA-Proxy-Loadbalancers, und bei Canonical kommt Nginx zum Einsatz. Neben den modularen Netzwerktreibern gibt es eine Reihe von Storage-Treibern für Persistent Volumes. 

Kubernetes am Edge einsetzen

Kubernetes-Setups müssen nicht aus dutzenden Knoten mit TBytes an Arbeitsspeicher bestehen. Die Technik skaliert nach unten bis hin zu IoT-Edge-Devices mit nur einer CPU und 1 GByte RAM. Das ist keine Spielerei, sondern ein valides Einsatzszenario. Anwender entwickeln und testen ihre Kernapplikationen auf größeren Kubernetes-Clustern und rollen anschließend ausgewählte Edge-Applikationen gezielt auf kleine Geräte aus. Umgekehrt eignen sich diese kompakten Distributionen jedoch nicht für klassische Enterprise-Umgebungen.

Der kleinste Ableger von Red Hat OpenShift trägt den Namen Microshift-IO und richtet sich an Single-Node-IoT-Setups. Die Distribution unterstützt weder zusätzliche Control-Nodes noch Worker-Knoten. Microshift-IO kommt mit zwei CPU-Kernen und 2 GByte Arbeitsspeicher aus und setzt als Container-Runtime "cri-o" ein. Das ist mehr, als andere Mini-Kubernetes-Distributionen verlangen, dafür bringt Microshift bereits den OVN-Netzwerkstack samt Router, den Cert-Manager sowie TopoLVM für persistente Volumes mit. Ziel ist eine möglichst hohe Kompatibilität zum großen Bruder OpenShift.

Neben der x86_64-Architektur unterstützt Microshift-IO auch 64-Bit-ARM-Systeme. Kubernetes auf einem Raspberry Pi 4 zu betreiben, ist damit problemlos möglich. Die Software lässt sich zwar als RPM- Paket installieren, das ist jedoch nicht die eigentliche Zielplattform. Über den Image Builder können Sie fertige Betriebssystem-Images mit einem "immutable" OS erzeugen und auf Edge-Geräte verteilen. Microshift ist dafür ausgelegt, direkt in solche Images integriert zu werden. Zusätzlich lässt sich die Distribution in sogenannte Bootc-Container einbetten. Dabei handelt es sich um startfähige Container, die sich mit Podman-Tools über ein Container-File bauen lassen und anschließend als bootfähige Binärimages vorliegen. Diese können auf SD-Karten für Edge-Devices kopiert oder in einer Cloud gestartet werden.

Kritikpunkt an Microshift war in der Vergangenheit oft, dass die Distribution stark an Red Hat und RHEL gebunden war und einen Red-Hat-Account erforderte. Inzwischen hat Red Hat das Upstream-Repository aktualisiert. Nutzer können Microshift-IO nun auch ohne Account auf freien Plattformen wie Fedora einsetzen.

K3s-Cluster: Lightweight-K8s für Edge & KMU

Ähnlich wie Red Hat bietet auch SUSE zwei Kubernetes-Distributionen an. RKE2 richtet sich an Enterprise-Umgebungen, während sich K3s für Edge-Geräte und kleinere Cluster eignet. Wie Microshift bündelt K3s die grundlegenden Kubernetes-Funktionen in einem einzigen kompakten Binary und kommt dadurch mit sehr wenig Ressourcen aus. Bereits ein CPU-Core und 1 GByte RAM reichen für kleine Edge-Setups aus.

In einem Single-Node-Setup kann K3s auf ein klassisches etcd verzichten und speichert Konfigurations- und Laufzeitdaten stattdessen über kine in einer SQLite-Datenbank. kine stellt dabei einen Abstraktionslayer bereit, der die etcd-Dienste emuliert und alternative Back-ends für die Persistenz erlaubt. Als Storage-Treiber nutzt K3s HostPath, als Netzwerk Flannel, was weitere Ressourcen spart. Für das externe Routing setzt K3s auf Traefik, als Container-Runtime kommt containerd zum Einsatz.

Im Gegensatz zu Microshift unterstützt K3s auch den Multi-Node-Betrieb. Einer bestehenden Single-Node-K3s-Installation lassen sich zusätzliche Worker-Knoten hinzufügen, um mehr Last am Edge zu betreiben. Die Control Plane bleibt dabei jedoch auf einen einzelnen Controller beschränkt. Zudem funktioniert HostPath-Storage dann nicht mehr, sodass Anwender auf ein Storage-Angebot wie Longhorn wechseln müssen. Optional kann K3s mehrere Controller-Knoten betreiben, wobei der integrierte etcd anstelle des SQLite-Setups zum Einsatz kommt. K3s unterstützt dabei auch die Migration von einem Single-Node-Controller mit SQLite zu einem Drei-Knoten-Controller mit etcd-Cluster.

Damit eignet sich K3s sowohl für Single-Node-Edge-Setups als auch für kleinere Cluster mit drei Management-Nodes und mehreren Workern oder für konvergente Drei-Knoten-Cluster mit Controllern, Workern und Storage. Vorteilhaft ist zudem, dass das Managementtool "Rancher" aus dem Hause SUSE sowohl mit RKE2- als auch mit K3s-Clustern arbeitet.

Über K0s und GitOps Multi-Cluster zentral steuern

Von Mirantis stammt die Distribution K0s . Anders als Single-Binary-Distributionen wie Microshift liefert K0s einzelne ausführbare Komponenten für kubelet und weitere Core-Dienste getrennt aus. Dazu gehören ein vollwertiges etcd sowie containerd als Container-Runtime. K0s lässt sich sowohl als Single-Node- Setup als auch im Multi-Node-Cluster betreiben. Die Hardwareanforderungen liegen bei mindestens 2 GByte RAM und zwei CPUs und damit auf einem ähnlichen Niveau wie bei Microshift.

Eine reine K0s-Installation bringt weder Router noch Overlay-Netzwerk oder Default-Storage-Treiber mit. Stattdessen ist die Distribution konsequent auf ein "as-Code"-Deployment ausgelegt. Dem Installationsskript kann der Administrator eine Konfigurationsdatei mitgeben, die die gewünschten Komponenten beschreibt und dabei auch auf Helm-Repositorys verweist. K0s installiert damit automatisch Erweiterungen, die nicht Teil des Lieferumfangs sind.

Dieses Konzept ergänzt sich mit dem Mirantis-Werkzeug k0rdent, das sich an GitOps-Prinzipien orientiert. Administratoren definieren damit Kubernetes-Cluster deklarativ und rollen sie automatisiert über einen Verwaltungs-Cluster aus. Das ist grundsätzlich auch mit anderen Distributionen möglich, für K0s jedoch optimiert.

Ebenfalls von Mirantis stammt k0smotron. Hier betreiben Sie die Control Planes mehrerer Kubernetes-Cluster als Pods auf einem zentralen Management-Cluster, den Mirantis als Mutterschiff bezeichnet. Dieses Modell eignet sich für Umgebungen mit vielen voneinander getrennten Clustern, etwa im Managed-Services-Umfeld. Voraussetzung ist jedoch eine stabile und latenzarme Netzwerkverbindung. Fällt diese aus, können die Worker ihre Aufgaben nicht mehr vollständig ausführen.

MicroK8s als Canonical- Variante für Einsteiger

Canonicals MicroK8s ist bei Ubuntu enthalten und wird über den Paketmanager Snap installiert. Eine Besonderheit ist der integrierte Add-on-Manager, mit dem sich zusätzliche Komponenten sehr einfach aktivieren lassen. Ein Web-UI-Dashboard richten Sie beispielsweise mit dem Befehl microk8s enable dashboard ein. Während K0s Erweiterungen deklarativ integriert, setzt Canonical bewusst auf interaktive Einzeiler.

 

 

Bei den Core-Komponenten geht Canonical eigene Wege. Statt eines klassischen etcd nutzt MicroK8s kine und im Hintergrund die Datenbank dqlite, eine Canonical-eigene Implementierung für verteiltes SQLite. Diese findet außerhalb des Canonical-Ökosystems kaum Verbreitung. MicroK8s hält sich aber leider nicht konsequent an etablierte Kubernetes-Standards. Das zeigt sich auch an der Snap-basierten Installation mit einer eigenen Verzeichnisstruktur unter "/snap/ microk8s".

In unserem Testsetup startete MicroK8s in Version 1.34 zunächst nicht korrekt. Kubernetes lief hier als "Snap-classic"-Paket, das mit Canonical-spezifischen Änderungen an sudo kollidierte. Erst nach dem Austausch des angepassten Sudo-Tools ließ sich der Cluster starten. Anschließend traten weitere Probleme auf: Der CNI-Treiber Calico legte die Umgebung unter "/var/lib/calico" an, suchte die Daten später jedoch unter "/var/snap/microk8s/current/var/lib/calico". Nach einem weiteren Reset und dem Wechsel auf Version 1.32 lief das Szenario dann stabil.

Ist MicroK8s dann erst einmal in Betrieb, kommt es Kubernetes-Einsteigern entgegen. Der Add-on-Manager und die Community-Repositorys erleichtern es sehr, grundlegende Komponenten wie Ingress, Registry, Dashboard sowie HostPath- oder NFS-Storage per einfachem Einzeiler nachzurüsten.

Die SUSE-Kubernetes-Engine einrichten

Im SUSE-Portfolio sorgt die Namensgebung rund um Rancher häufig für Verwirrung. Rancher bezeichnet in erster Linie die Managementplattform für Kubernetes-Cluster mit Web-UI, Helm-Integration und Multi-Cluster-Verwaltung und ist nicht an eine einzelne Distribution gebunden. Unter Rancher lassen sich unterschiedliche Kubernetes-Distributionen betreiben, darunter K3s und die Rancher Kubernetes Engine 2, kurz RKE2.

 

 

RKE2 richtet sich an produktive Umgebungen und integriert im Vergleich zu K3s eine Reihe zusätzlicher Sicherheitsfunktionen, etwa Network Policys mit Calico anstelle von Flannel. Zudem betreibt RKE2 – wie vom Kubernetes-Upstream vorgesehen – die Core-Dienste in eigenen Containern, während K3s diese direkt in sein Binary integriert. Dadurch benötigt RKE2 etwas mehr Ressourcen, hält sich jedoch enger an die Referenzarchitektur von Kubernetes und bleibt langfristig flexibler.

Das Setup ist ähnlich einfach wie bei K3s, und im praktischen Cluster-Betrieb auf x86_64-Systemen zeigen sich keine gravierenden Unterschiede beim Ressourcenbedarf. RKE2 bildet unter anderem die Kubernetes-Basis für SUSEs KubeVirt-Ansatz Harvester.

Unter dem Strich ist RKE2 die robustere Distribution für klassische Server- und Cluster-Umgebungen. Wer keine Single-Node-Edge-Szenarien betreibt, sondern auf regulärer Hardware arbeitet, sollte RKE2 K3s vorziehen. Im Basissetup bleibt RKE2 vergleichsweise ressourcenschonend und eignet sich auch für kleinere Cluster.

Da SUSE mit Longhorn einen einfach zu betreibenden hyperkonvergenten Storage für kleine und mittelgroße Umgebungen anbietet, läuft RKE2 zuverlässig auf konvergenten Drei-Knoten-Clustern. In größeren Installationen mit vielen Dutzend Knoten skaliert RKE2 ebenfalls, sollte dort jedoch mit einem leistungsfähigeren Storage-Backend als Longhorn kombiniert werden.

OKD und OpenShift für Enterprise-Cluster

Am oberen Ende der Kubernetes-Distributionen stehen OpenShift und dessen Upstream-Version OKD. Diese Distributionen zielen von Beginn an auf Enterprise-Setups mit größeren Clustern und erhöhten Sicherheitsanforderungen. Bereits das Basissetup umfasst mehr als 100 Container für interne Dienste wie Netzwerk, Router, Policys, Cert-Manager, Operator-Management, Metriken und weitere Systemkomponenten.

 

 

Die interne Kommunikation der Cluster-Knoten ist durchgängig per TLS verschlüsselt, sämtliche Endpunkte arbeiten mit gültigen Zertifikaten. Optional lässt sich auch die Data Plane verschlüsseln, also die Kommunikation der Applikationen untereinander. Diese Funktion kommt vor allem in Multi-Tenant-Umgebungen zum Einsatz. Ein simples, konvergentes Drei-Knoten-Setup ist theoretisch möglich, in der Praxis finden sich jedoch überwiegend Cluster mit dutzenden Worker-Nodes.

Als hyperkonvergenten Storage setzen OKD und OpenShift auf Rook/Ceph, bei OpenShift in Form der OpenShift Data Foundation. Dabei handelt es sich um einen hoch skalierenden, jedoch recht komplexen Software-defined Storage. Hinzu kommt, dass OpenShift häufig mit optionalen Komponenten wie "KubeVirt" (OpenShift Virtualization) betrieben wird. Anders als bei Rancher gehört ein Multi-Cluster-Manager nicht zum Basissetup, sondern wird mit dem Advanced Cluster Manager als separates Add-on angeboten. Verglichen mit anderen Distributionen ist OpenShift weniger flexibel und stärker an die eigenen Komponenten gebunden. Technologien wie das OVN-Netzwerk und der OpenShift-eigene HAProxy-basierte Ingress-Router sind faktisch gesetzt. Ein minimalistisches Setup mit Traefik und Flannel ist weder bei OpenShift noch bei OKD vorgesehen.

Netzwerkarchitektur optimal auslegen

Unabhängig davon, welche der vorgestellten Kubernetes-Distributionen Sie testen oder produktiv einsetzen: Performance und Zuverlässigkeit eines Clusters stehen und fallen mit dem zugrunde liegenden Netzwerkdesign.

Die wichtigste Regel betrifft den etcd-Cluster. Die drei etcd-Knoten müssen über ein sehr schnelles Netzwerk mit möglichst niedriger Latenz kommunizieren. Der Gedanke, Controller-Komponenten räumlich zu trennen und etwa in verschiedenen Brandabschnitten oder Rechenzentren zu betreiben, liegt nahe, ist bei Kubernetes jedoch problematisch. Ein sogenannter "stretched cluster" funktioniert nur dann, wenn alle Controller im selben Layer-2-Netz hängen, idealerweise sogar am selben Switch. Sobald ein Router zwischen den Standorten liegt und die Latenz dauerhaft über etwa 5 ms steigt, leidet die Performance des gesamten Clusters erheblich. In solchen Szenarien ist es sinnvoller, getrennte Cluster zu betreiben und auf Replikations- oder Fail-over-Software wie Kasten K10 oder einen Multi-Cluster-Manager zu setzen.

Eine zweite zentrale Regel gilt nicht nur für Kubernetes, sondern für alle hyperkonvergenten Architekturen. Applikationen und Storage lassen sich zwar gemeinsam auf demselben Cluster-Knoten betreiben, das Storage-Netzwerk sollte jedoch physisch getrennt sein. Idealerweise laufen Storage-Traffic und Replikation über eigene Netzwerkkarten und Switches mit der größtmöglichen MTU, die Hardware und Infrastruktur unterstützen, typischerweise 9000 Byte. Das gilt für Software-defined-Storage-Ansätze wie Longhorn ebenso wie für Rook/Ceph. Größere MTU-Werte können sich auch im Applikationsnetz positiv auswirken, da Overlay-Netzwerke die effektiv nutzbare Payload-Größe häufig von 1500 auf etwa 1350 Byte reduzieren. Größere Frames helfen, Fragmentierung zu vermeiden und die Performance zu stabilisieren.

Gelegentlich wird empfohlen, die Kommunikation der Control Plane physisch vom Applikationsverkehr zu trennen. Das bringt in erster Linie Sicherheitsvorteile, insbesondere in Umgebungen ohne durchgängige TLS-Verschlüsselung. Ein spürbarer Performancegewinn zeigt sich jedoch meist erst bei sehr hoher Netzwerklast. In vielen Fällen reichen auch gezielte Policys aus, um den Traffic der Control Plane gegenüber Anwendungsdaten zu priorisieren.

Fazit

Für Administratoren, die aus einer klassischen IT-Welt mit virtuellen Maschinen und statischen Diensten kommen, bedeutet Kubernetes zunächst eine spürbare Umstellung. Die Dynamik von Containern, Services und Ressourcen erfordert ein Umdenken – insbesondere bei Architektur, Netzwerk und Betrieb. Anfangs wirkt ein Kubernetes-Cluster daher komplex und ungewohnt.

Mit zunehmender Praxis zeigt sich jedoch, dass viele Aufgaben einfacher und robuster lösbar sind als in statischen Umgebungen. Wer die grundlegenden Architekturprinzipien versteht und eine zur eigenen Umgebung passende Distribution wählt, kann stabile und sichere Kubernetes-Cluster aufbauen – idealerweise im eigenen Rechenzentrum. Auf dieser Basis lassen sich bestehende Applikationen schrittweise auf eine moderne, dynamische Plattform migrieren. (ln)