k3s vs k0s vs MicroK8s vs RKE2: Welches Kubernetes, wenn das volle nicht nötig ist

Jeder Vergleich leichtgewichtiger Kubernetes-Distributionen beginnt mit einer Tabelle von Speicherbedarfen — und jeder verfehlt damit den Kern.

Die interessante Frage ist nicht, welche Distribution die kleinste ist. Sie lautet: Was hat jede weggelassen, und können Sie darauf verzichten? Eine Kubernetes-Control-Plane hat eine feste Menge an Aufgaben; der Unterschied zwischen diesen vier Projekten liegt darin, welche dieser Aufgaben sie Ihnen überlassen, welche sie verstecken und zu welchen sie sich bewusst nicht äußern.

Hier ist, was sie 2026 tatsächlich trennt — inklusive einer Änderung aus diesem Jahr, die die Standardwerte einer Distribution still umgeschrieben hat.

Zuerst: “Leichtgewichtig” bedeutet dreierlei

Bevor man irgendetwas vergleicht, lohnt es sich, drei Behauptungen zu trennen, die ständig vermischt werden:

1. Ein kleines Installationsartefakt. k3s wird als einzelne Binärdatei unter 100 MB ausgeliefert. k0s ist eine selbstentpackende, statisch kompilierte Binärdatei mit eingebetteten Kubernetes-Komponenten.
2. Eine niedrige Speicheruntergrenze. Wie wenig RAM die Control Plane braucht, bevor irgendein Workload darauf liegt.
3. Wenige mitgelieferte Komponenten. Wie viel Cluster Sie bekommen, bevor Sie selbst etwas installieren.

Diese Ziele ziehen in verschiedene Richtungen. Eine Distribution, die Ingress-Controller, Load Balancer und Storage-Provisioner mitbringt, liefert schneller ein funktionierendes Cluster — und verbraucht dabei mehr Speicher. Wenn ein Projekt einen kleineren Fußabdruck als ein anderes behauptet, prüfen Sie, ob dasselbe Cluster gemessen wurde.

k3s — Batteries included, für den Edge optimiert

k3s ist das, was die meisten meinen, wenn sie “leichtgewichtiges Kubernetes” sagen. Der Name ist ein Größenwitz: Kubernetes ist ein Zehn-Buchstaben-Wort, stilisiert als K8s, also ist etwas halb so Großes ein Fünf-Buchstaben-Wort, stilisiert als K3s. Es gibt keine Langform und keine offizielle Aussprache.

Bemerkenswert ist, wie viel in dieser einen Binärdatei ankommt:

• containerd als Container-Runtime
• Flannel als CNI
• CoreDNS als Cluster-DNS
• Traefik als Ingress-Controller
• ServiceLB als Load-Balancer-Controller
• Kube-router für Network Policies
• local-path-provisioner für persistente Volumes
• Spegel , ein eingebetteter verteilter Container-Image-Registry-Spiegel
• Host-Werkzeuge wie iptables und socat

Der vorletzte Punkt wiegt schwerer, als er aussieht. Spegel lässt Knoten Images voneinander ziehen, statt eine Registry zu kontaktieren — das ist der Unterschied zwischen einem funktionierenden Edge-Standort und einem hängenden Rollout, wenn die Anbindung dünn ist.

Der Datastore ist die zweite Schlagzeile. k3s nutzt standardmäßig SQLite statt etcd; etcd, MySQL und PostgreSQL stehen als Alternativen bereit. Für Hochverfügbarkeit betreiben Sie drei oder mehr Server mit eingebettetem etcd oder richten k3s auf eine externe Datenbank.

Die Mindestanforderungen liegen bei 2 Kernen und 2 GB für einen Server, 1 Kern und 512 MB für einen Agent. Der veröffentlichte Sizing-Leitfaden ist nützlicher als die Minima: Ein Server mit 2 vCPU / 4 GB trägt bis zu 350 Agents, 4 vCPU / 8 GB bis zu 900, und ein Drei-Server-HA-Setup skaliert rund 50 % weiter — drei Server mit 4 vCPU / 8 GB erreichen etwa 1.200 Agents.

Ein Hinweis aus der Dokumentation, der Homelab-Bauer erwischt: etcd ist schreibintensiv, und SD-Karten sowie eMMC halten die IO-Last nicht aus. Wer k3s mit eingebettetem etcd auf einem Raspberry Pi betreibt, sollte eine externe SSD verwenden.

k0s — Minimal aus Prinzip, und die einzige mit isolierter Control Plane

k0s bezieht die Gegenposition und sagt das offen. Der dokumentierte Anspruch lautet, so wenige Add-ons wie möglich mitzuliefern, weil Dinge wie Ingress, Service Meshes und Storage “VERY opinionated” seien und das Nachziehen vieler gebündelter Add-ons bei Upstream-Releases sehr wartungsintensiv ist.

Sie bekommen also den Kern — Konnectivity, CoreDNS, Metrics Server, containerd mit runc, Kube-router als Standard-CNI mit Calico als vorkonfigurierter Alternative — und keinen Ingress-Controller.

Die architektonische Entscheidung, die k0s wirklich abhebt, ist diese: Auf den Controllern laufen standardmäßig weder Container-Engine noch Kubelet. Die Control-Plane-Komponenten laufen als gewöhnliche Prozesse, überwacht von der k0s-Binärdatei selbst. Die praktische Folge: Ein Cluster-Nutzer kann auf Controller-Knoten keine Workloads planen — Control-Plane-Isolation ist der Standard, nicht etwas, das man mit Taints konfiguriert.

Dieselbe Control Plane, vier verschiedene Verpackungen. Unterschiedlich ist, wo die Komponenten laufen und wie viel mitkommt.

Auch die Paketierung ist stärker, als sie zunächst wirkt. Die Binärdatei ist statisch kompiliert und hat außer dem Kernel keine Abhängigkeiten auf Betriebssystemebene: keine RPMs, keine Snaps, keine distributionsspezifische Paketierung. Die in der Doku genannte Motivation ist ein reales Betriebsproblem — wenn Kubernetes auf einem Host-OS läuft, das unabhängig aktualisiert wird, gehört niemandem die Lücke dazwischen. k0s schließt sie, indem es nicht vom Host abhängt.

Die Anforderungen liegen bei 1 vCPU und 1 GB für einen Controller, 0,5 vCPU und 1 GB für einen Worker. Die gemessenen Zahlen sind ehrlicher als Minima: Ein Controller mit einem Worker und ohne Pods liegt bei etwa 510 MB, mit 20 Workern und 2.000 Pods bei rund 1 GB, mit 200 Workern und 20.000 Pods bei etwa 3,3 GB.

Die Architekturen umfassen x86-64, ARM64 und ARMv7 sowie RISC-V — mit dem in der Doku genannten Vorbehalt, dass es für RISC-V keine vorkompilierten Binärdateien und keine CI-Abdeckung gibt. Windows-Unterstützung ist experimentell.

Das gemeinsame Geheimnis: beide laufen auf kine

Ein Detail erklärt, warum sich k3s und k0s unter der Haube ähneln. Kubernetes unterstützt normalerweise nur etcd als Datastore. Beide Projekte umgehen das mit kine , einem Shim, der die etcd-API in SQL übersetzt — und k0s übernimmt kine direkt aus dem k3s-Projekt.

Deshalb können beide ein Einzelknoten-Cluster auf SQLite starten und später auf MySQL oder PostgreSQL wechseln. Es bedeutet aber auch, dass für beide derselbe Kompromiss gilt: SQLite ist eine einzelne Datei auf einem einzelnen Knoten. Hervorragend für eine Maschine — und kein hochverfügbarer Datastore.

MicroK8s — Das Workstation-Cluster, mit einer Meinung zur Paketierung

MicroK8s ist Canonicals Distribution, und ihr prägendes Merkmal ist der Auslieferungsweg: Sie installiert sich als Snap.

Terminal window

sudo snap install microk8s --classic --channel=1.35

Diese eine Zeile ist tatsächlich der schnellste Weg zu einem Cluster auf einem Ubuntu-Laptop — und zugleich der Grund, warum MicroK8s in manchen Flotten ausscheidet. Wenn Ihre Produktionshosts kein snapd betreiben — und viele gehärtete, minimale oder nicht-Ubuntu-basierte Server-Images tun das nicht — ist das ein hartes Ausschlusskriterium, keine Unbequemlichkeit.

Canonical gibt an, dass MicroK8s mit nur 540 MB Arbeitsspeicher läuft, empfiehlt aber 4 GB Speicher und 20 GB Festplatte für echte Workloads. Behandeln Sie die 540 MB als Untergrenze für ein leerlaufendes Cluster, nicht als Zusage für Ihre Anwendung.

Zwei betriebliche Eigenheiten, die man vorher kennen sollte:

kubectl ist namensraumgebunden. MicroK8s bringt ein eigenes mit, aufgerufen als microk8s kubectl, um Kollisionen mit einer bestehenden kubectl-Installation zu vermeiden. Die meisten legen sofort einen Alias an.

DNS ist standardmäßig aus. MicroK8s liefert “the minimum of components for a pure, lightweight Kubernetes”, alles Weitere kommt über Add-ons:

Terminal window

microk8s enable dns

microk8s enable hostpath-storage

Wer je zugesehen hat, wie ein frisches MicroK8s-Cluster einen Servicenamen nicht auflöst und etwas für kaputt hielt: Das ist der Grund. Es ist eine Designentscheidung, kein Fehler — aber die häufigste Überraschung in der ersten Stunde.

Besser als sein Ruf: die Hochverfügbarkeit

MicroK8s wird meist als “Laptop-Cluster” abgelegt, was seine Clustering-Fähigkeiten untertreibt. Hochverfügbarkeit schaltet sich automatisch ein, sobald ein Cluster drei oder mehr Knoten hat — es gibt keinen separaten HA-Modus zu konfigurieren.

Dahinter steht dqlite , und die Knotenrollen lohnen sich zu kennen, weil sie das Ausfallverhalten erklären:

• voters replizieren die Datenbank und nehmen an der Leader-Wahl teil
• standby -Knoten replizieren die Datenbank, stimmen aber nicht ab
• spare -Knoten tun beides nicht und existieren, um befördert zu werden

Die dokumentierten Zeiten sind erfreulich konkret: Verschwindet der Leader unsanft, dauert die Wahl eines neuen bis zu 5 Sekunden , und die Beförderung eines Nicht-Wählers zum Wähler bis zu 30 Sekunden. Jeder Knoten eines HA-MicroK8s-Clusters betreibt die Control Plane, sodass microk8s-Befehle von überall im Cluster funktionieren.

RKE2 — Die, die ein Audit bestehen soll

RKE2 ist SUSEs Distribution und der Ausreißer hier: Sie will gar nicht klein sein. Sie will vor einer Prüferin bestehen. Ihr zweiter Name sagt es deutlich — RKE Government — und ihr erklärter Fokus ist Sicherheit und Compliance im Sektor der US-Bundesbehörden.

Konkret heißt das:

• Standardwerte und Konfigurationsoptionen, mit denen Cluster den CIS Kubernetes Benchmark v1.7 oder v1.8 mit minimalem Eingriff bestehen
• Unterstützung für FIPS-140-2 -Compliance
• CVE-Scans der Komponenten mit Trivy in der Build-Pipeline

Architektonisch ist RKE2 eine bewusste Mischung. Von k3s erbt es Bedienbarkeit und Deployment-Modell. Von RKE1 erbt es die enge Ausrichtung am Upstream-Kubernetes — und Ranchers Doku ist erfreulich direkt darin, warum das zählt: k3s weicht vom Upstream ab, um für Edge-Deployments zu optimieren, während RKE1 und RKE2 eng ausgerichtet bleiben.

Auch die Control Plane läuft anders als bei allen anderen hier. RKE2 startet die Control-Plane-Komponenten als statische Pods, verwaltet vom Kubelet , mit containerd als eingebetteter Runtime. Keine Docker-Abhängigkeit, anders als bei RKE1.

Beim Netzwerk bringt RKE2 vier primäre CNI-Plugins mit — Canal ist der Standard , dazu Cilium, Calico und Flannel sowie Multus als sekundäres Plugin. Eine Warnung aus der Doku verdient Wiederholung, weil man sie sonst teuer lernt: RKE2 unterstützt es nicht, das primäre CNI, das CNI-Backend oder die Cluster- und Service-CIDRs an einem laufenden Cluster zu ändern. Ein späterer Wechsel ist ungetestet und kann verwaiste Interfaces und Routen hinterlassen; das dokumentierte Mittel ist, das Cluster neu zu bauen. Entscheiden Sie vor dem ersten Start.

Ebenfalls neu in diesem Jahr: nftables-Unterstützung , verfügbar ab den Releases vom Juli 2026 (v1.36.3+rke2r1, v1.35.7+rke2r1, v1.34.10+rke2r1) und weiterhin als experimentell markiert. Sie wird von kube-proxy und den meisten mitgelieferten CNIs unterstützt und pro Komponente aktiviert — proxy-mode=nftables für kube-proxy plus eine HelmChartConfig für das CNI.

Die Änderung von 2026: Ingress NGINX ist Geschichte

Das ist das Neueste auf dieser Seite und leicht zu übersehen. Ingress NGINX hat im März 2026 sein Lebensende erreicht. Als direkte Folge liefert RKE2 ab v1.36 Traefik als Standard-Ingress-Controller für neue Cluster aus; für bestehende Cluster gibt es einen dokumentierten Migrationspfad.

Wer sich gerade jetzt auf RKE2 festlegt, den wird dieses Detail später einholen: Cluster, die vor und nach v1.36 gebaut wurden, haben nicht denselben Ingress-Controller, und alle Helm-Werte, Annotationen oder IngressClass-Verweise, die Sie gegen nginx templatisiert haben, müssen überarbeitet werden. Annotationslastige NGINX-Konfigurationen lassen sich nicht sauber übertragen.

Die Vergleichstabelle

Auswählen: Distribution an die Randbedingung anpassen

Vergessen Sie Ranglisten. Jede dieser vier ist die richtige Antwort auf eine bestimmte Frage.

Beginnen Sie bei der Randbedingung, über die Sie nicht verhandeln können — nicht beim Speicherbedarf.

Nehmen Sie RKE2, wenn ein Mensch dieses Cluster prüfen wird. FIPS, CIS-Benchmark-Standardwerte und CVE-Scans in der Pipeline rüstet man an einer anderen Distribution nicht an einem Wochenende nach. Wenn “reguliert”, “Behörde” oder “unser Security-Team muss freigeben” in Ihren Anforderungen auftaucht, ist die Entscheidung bereits gefallen.

Nehmen Sie k3s, wenn das Cluster dort steht, wo Sie schwer hinkommen. Entfernte Standorte, Einplatinencomputer, Air-Gapped-Installationen, CI-Runner. Mitgelieferter Ingress, Load Balancer und Storage-Klasse bedeuten weniger Teile zum Bereitstellen, und der eingebettete Registry-Spiegel hält einen Standort am Leben, wenn seine Anbindung es nicht tut.

Nehmen Sie k0s, wenn Sie Ihre eigene Plattform über eine Flotte standardisieren. Keine Host-OS-Abhängigkeit, Control-Plane-Isolation gratis, k0sctl fürs Lifecycle-Management und die bewusste Weigerung, Ihren Ingress für Sie auszuwählen. Wenn Sie ohnehin wissen, welches CNI und welchen Ingress Sie wollen, bleibt k0s Ihnen aus dem Weg — und die isolierte Control Plane ist eine echte Sicherheitseigenschaft, die Sie sonst mit Taints und Hoffnung durchsetzen müssten.

Nehmen Sie MicroK8s, wenn das Cluster auf einer Ubuntu-Workstation lebt. Für lokale Entwicklung, Demos und Lehre ist ein Snap-Befehl plus Add-on-Liste schwer zu schlagen. Prüfen Sie, ob snapd auf Ihren Servern akzeptabel ist, bevor Sie es weiter befördern.

Und minikube für nichts davon. Es ist ein Entwicklungswerkzeug für ein Cluster auf der eigenen Maschine und gehört nicht in dieselbe Kategorie wie die vier oben — es ist nichts, was man an einen Standort ausrollt.

Was häufig schiefgeht

Ein paar Fehlermuster, die echte Zeit kosten:

• Einzelknoten-k3s auf SQLite als Produktion behandeln. Das ist eine Datei auf einer Maschine. Für alles mit Verfügbarkeitserwartung: drei Server mit eingebettetem etcd oder ein externer Datastore.
• Veröffentlichte Speicherminima direkt vergleichen. Sie werden unter verschiedenen Bedingungen und gegen verschiedene Komponentensätze gemessen. Ein nackter k0s-Controller und ein k3s-Server mit Traefik plus ServiceLB sind nicht dasselbe Cluster.
• Annehmen, ARM sei gleich ARM. k0s deckt ARM64 und ARMv7 ab und nennt RISC-V — ohne vorkompilierte Binärdateien und ohne CI-Abdeckung. Prüfen Sie die konkrete Architektur, nicht die Familie.
• Eingebettetes etcd auf Flash-Speicher betreiben. etcd ist schreibintensiv; SD-Karten und eMMC überleben das nicht. Nutzen Sie eine SSD.
• Heute auf RKE2 gegen nginx templatisieren. Mit dem Lebensende von Ingress NGINX und Traefik als Standard ab v1.36 hat diese Annahme ein Ablaufdatum.
• Planen, “das CNI später zu wechseln” bei RKE2. Die Doku sagt klar, dass das Ändern des primären CNI, seines Backends oder der Cluster- und Service-CIDRs an einem laufenden Cluster nicht unterstützt wird. Diese Entscheidung fällt einmal, vor dem ersten Start.

Eine kurze Checkliste

1. Schreiben Sie die Randbedingung auf, über die Sie nicht verhandeln können — Audit, Anbindung, Host-OS oder gar keine.
2. Prüfen Sie, ob snapd auf den Zielhosts erlaubt ist. Das schließt MicroK8s in einem Schritt aus oder ein.
3. Entscheiden Sie, ob Sie einen vorgegebenen Ingress wollen oder Ihren eigenen. Das trennt k3s und k0s klarer als jeder Benchmark.
4. Wenn die Control Plane keine Workloads tragen darf: Nur k0s liefert das ohne Konfiguration.
5. Für alles Hochverfügbare zuerst den Datastore planen: drei Server mit eingebettetem etcd oder eine externe Datenbank. SQLite ist eine Einzelknoten-Antwort.
6. Wenn es RKE2 wird: Version festnageln und prüfen, auf welcher Seite von v1.36 Sie stehen, bevor Sie Ingress-Manifeste schreiben.

Das ehrliche Fazit

Diese vier Distributionen konkurrieren nicht darum, die leichteste zu sein. Sie kodieren vier verschiedene Meinungen darüber, was ein Team selbst entscheiden sollte.

k3s entscheidet das meiste für Sie und optimiert für Orte, an denen selten jemand vorbeischaut. k0s entscheidet fast nichts und übergibt Ihnen eine saubere, isolierte Basis. MicroK8s entscheidet die Paketierung und überlässt den Rest den Add-ons. RKE2 entscheidet die Sicherheitshaltung, weil in seinem Zielsektor nur diese Entscheidung zählt.

Nehmen Sie die, deren Meinungen Sie ohnehin teilen. Das ist eine haltbarere Grundlage als ein Speicherbedarf, der sich mit dem nächsten Release ändert.

Weiterlesen: Für die Schicht über diesen Clustern siehe Platform Engineering auf Kubernetes und GitOps mit Argo CD. Zum Härten der gewählten Distribution siehe OPA vs Kyverno und die Secure-by-Default-GKE-Referenzarchitektur.

Quellen: Alle Zahlen und Aussagen stammen aus der jeweiligen Projektdokumentation — k3s-Doku, k3s-Anforderungen, k0s-Doku, k0s-Architektur, MicroK8s Getting Started und RKE2-Doku.

Ursprünglich veröffentlicht auf alekseialeinikov.com