K3s: Leichtgewichtiges Kubernetes für Dev und Edge

Kubernetes in unter 100 Megabyte

Kubernetes ist mächtig, aber diese Mächtigkeit hat ihren Preis: Ein vollständiges Cluster braucht etcd, kube-apiserver, kube-scheduler, kube-controller-manager und eine ganze Reihe weiterer Komponenten. Für Produktionsumgebungen in der Cloud ist das vertretbar. Für die lokale Entwicklung, CI/CD-Pipelines oder Edge-Szenarien auf ressourcenbeschränkter Hardware ist es schlicht zu viel.

Genau dieses Problem hat Rancher Labs adressiert. Vor rund sechs Wochen, im Februar 2019, wurde K3s veröffentlicht -- eine zertifizierte Kubernetes-Distribution, die als einzelne Binary unter 40 MB daherkommt und mit einem einzigen Befehl installiert werden kann. Der Name ist Programm: Wenn Kubernetes mit seinen zehn Buchstaben als K8s abgekürzt wird, dann ist die abgespeckte Variante mit fünf Buchstaben eben K3s -- halb so groß, halb so komplex.

Wir haben K3s in den letzten Wochen auf mehreren Entwicklungsrechnern und einer Handvoll virtueller Maschinen getestet. Hier ist unser erster Praxisbericht.

Was K3s anders macht

K3s ist kein Fork von Kubernetes und auch kein eigenes Orchestrierungs-Framework. Es ist Kubernetes -- zertifiziert von der CNCF und vollständig API-kompatibel. Der Unterschied liegt in dem, was Rancher Labs entfernt und ersetzt hat.

SQLite statt etcd: Die wohl auffälligste Änderung betrifft den Datastore. Statt des verteilten Key-Value-Stores etcd nutzt K3s standardmäßig SQLite als Backend. Für Single-Node-Setups und kleinere Cluster ist das völlig ausreichend und spart erheblich an Ressourcen und Komplexität. Wer etcd oder MySQL als Backend bevorzugt, kann das weiterhin konfigurieren.

Containerd statt Docker: K3s bringt containerd als Container-Runtime direkt mit. Docker wird nicht benötigt und auch nicht vorausgesetzt. Das reduziert den Overhead, bedeutet aber, dass docker ps auf dem Host keine K3s-Container anzeigt. Stattdessen arbeitet man mit crictl oder direkt mit kubectl.

Einzelne Binary: Alle Kubernetes-Komponenten -- API-Server, Scheduler, Controller-Manager und kubelet -- sind in einer einzigen Binary zusammengefasst. Kein separates Setup einzelner Dienste, keine komplexe Zertifikatsverwaltung beim Bootstrapping. Ein Binary, ein Befehl, ein laufendes Cluster.

Entfernter Ballast: Cloud-Provider-Integrationen (AWS, Azure, GCP), veraltete APIs und nicht-standardkonforme Storage-Treiber wurden entfernt. Was bleibt, ist ein schlanker Kubernetes-Kern, der das tut, was man auf lokaler Hardware oder am Edge tatsächlich braucht.

Installation: Ein einzelner Befehl

Die Installation von K3s ist fast schon irritierend einfach. Auf einem Linux-System genügt:

curl -sfL https://get.k3s.io | sh -

Das war es. Nach wenigen Sekunden läuft ein vollständiges Kubernetes-Cluster. Der K3s-Server-Prozess startet automatisch als systemd-Service, und kubectl wird direkt mitgeliefert.

Den Status des Clusters prüft man wie gewohnt:

# Cluster-Info abfragen
sudo kubectl cluster-info

# Nodes anzeigen
sudo kubectl get nodes

Die Ausgabe sieht vertraut aus -- es ist schließlich normales Kubernetes:

NAME        STATUS   ROLES    AGE   VERSION
my-host     Ready    master   30s   v1.13.5+k3s.1

Das sudo ist nötig, weil K3s die kubeconfig standardmäßig unter /etc/rancher/k3s/k3s.yaml ablegt. Alternativ kann man die Datei in das eigene ~/.kube/-Verzeichnis kopieren und die Umgebungsvariable KUBECONFIG setzen.

Erster Workload: nginx deployen

Um zu prüfen, ob das Cluster wirklich funktioniert, deployen wir einen einfachen nginx-Webserver:

# Deployment erstellen
sudo kubectl create deployment nginx --image=nginx

# Auf drei Replicas skalieren
sudo kubectl scale deployment nginx --replicas=3

# Service vom Typ NodePort erstellen
sudo kubectl expose deployment nginx --port=80 --type=NodePort

Ein Blick auf die laufenden Pods:

sudo kubectl get pods -o wide

NAME                     READY   STATUS    RESTARTS   AGE
nginx-65f88748fd-2k7jm   1/1     Running   0          15s
nginx-65f88748fd-8xb4p   1/1     Running   0          10s
nginx-65f88748fd-wqnzl   1/1     Running   0          10s

Drei Pods, alle Running, innerhalb von Sekunden. Auf einem herkömmlichen Kubernetes-Cluster hätte allein die Einrichtung des Clusters länger gedauert als dieses gesamte Deployment.

Den zugewiesenen NodePort findet man über:

sudo kubectl get services

Der Service ist dann unter http://localhost:<NodePort> erreichbar. Alles verhält sich exakt so, wie man es von Kubernetes kennt -- weil es Kubernetes ist.

Vergleich mit Minikube und Docker Desktop

Wer bisher lokal mit Kubernetes entwickelt hat, kennt vermutlich Minikube oder das in Docker Desktop integrierte Kubernetes. Wie schlägt sich K3s im Vergleich?

Minikube erstellt eine vollständige virtuelle Maschine mit einem Kubernetes-Cluster darin. Das funktioniert zuverlässig, bringt aber den Overhead einer VM mit: mehrere Gigabyte RAM-Zuweisung, längere Startzeiten und eine zusätzliche Abstraktionsschicht. K3s läuft direkt auf dem Host oder in einem minimalen Container und startet in Sekunden statt Minuten.

Docker Desktop Kubernetes ist komfortabel, aber an Docker Desktop gebunden und auf macOS und Windows beschränkt. Es nutzt ebenfalls eine VM unter der Haube und benötigt deutlich mehr Ressourcen als K3s.

K3s ist hier klar im Vorteil, wenn es um Startgeschwindigkeit und Ressourcenverbrauch geht. Allerdings läuft K3s nativ nur auf Linux. Auf macOS oder Windows braucht man eine Linux-VM -- womit der Ressourcenvorteil teilweise wieder aufgehoben wird. Für Linux-basierte Entwicklungsrechner und CI-Server ist K3s aber die schlankere Alternative.

Wo K3s wirklich glänzt

Über die lokale Entwicklung hinaus sehen wir drei Szenarien, in denen K3s sein Potenzial voll ausspielt.

CI/CD-Pipelines: Wer Kubernetes-Manifeste, Helm Charts oder Operatoren testen will, braucht ein schnell verfügbares Cluster. K3s lässt sich in wenigen Sekunden in einer CI-Pipeline hochfahren, die Tests laufen, und danach wird alles wieder abgeräumt. Kein Warten auf Cluster-Provisioning, keine Cloud-Kosten.

Edge Computing: Auf Geräten mit begrenztem Speicher und begrenzter Rechenleistung -- Industriesteuerungen, IoT-Gateways, Remote-Standorte -- ist ein vollständiges Kubernetes-Cluster unrealistisch. K3s läuft mit 512 MB RAM und einer einzelnen CPU-Core. Das eröffnet Kubernetes-basierte Deployments dort, wo sie bisher undenkbar waren.

Raspberry Pi: K3s unterstützt ARM-Architekturen. Ein Kubernetes-Cluster aus Raspberry Pis -- als Lernumgebung, Heimlabor oder für spezifische Anwendungsfälle -- ist damit ernsthaft realisierbar. Nicht nur als Spielerei, sondern mit einer zertifizierten Kubernetes-Distribution.

Einschränkungen und offene Fragen

K3s ist erst wenige Wochen alt, und das merkt man an einigen Stellen. Die Dokumentation ist noch dünn. Die Community wächst zwar schnell, aber für Randszenarios findet man wenig Erfahrungsberichte. Hochverfügbarkeits-Setups mit mehreren Server-Nodes sind derzeit nicht offiziell unterstützt -- für produktive Umgebungen mit Ausfallsicherheitsanforderungen ist das ein echtes Hindernis.

Auch die Frage nach Upgrades und Lifecycle-Management ist noch offen. Bei einer so jungen Distribution fehlt schlicht die Erfahrung, wie Updates in der Praxis ablaufen und welche Stolperfallen sich ergeben. Wer K3s heute in produktionsnahen Umgebungen einsetzt, sollte sich bewusst sein, dass er Early Adopter ist.

Fazit

K3s löst ein reales Problem: Kubernetes war bisher zu schwergewichtig für viele Einsatzszenarien abseits der Cloud. Lokale Entwicklung, CI/CD und Edge Computing brauchten eine leichtere Alternative -- und mit K3s liefert Rancher Labs genau das. Die CNCF-Zertifizierung stellt sicher, dass es sich um echtes Kubernetes handelt und nicht um eine inkompatible Eigenentwicklung.

Für unsere tägliche Arbeit sehen wir K3s vor allem als Werkzeug für Entwicklungs- und Testumgebungen. In CI-Pipelines ersetzt es schon jetzt schwerere Alternativen. Ob und wann K3s für produktive Workloads in Frage kommt, hängt davon ab, wie schnell Rancher Labs die offenen Punkte -- insbesondere Hochverfügbarkeit und stabiles Upgrade-Management -- adressiert.

Wer Kubernetes nutzt oder damit plant, sollte K3s auf dem Radar haben. Die Einstiegshürde ist denkbar niedrig: ein Linux-System, ein Befehl und dreißig Sekunden Geduld. Danach hat man ein vollständiges Cluster, das sich exakt so verhält wie jedes andere Kubernetes. Es gibt kaum einen einfacheren Weg, um mit Kubernetes zu experimentieren.