k3s vs. MicroK8s: Welches Lightweight Kubernetes ist das richtige?

Kubernetes ist mächtig, aber komplex. Für kleine Teams, Homelab-Setups oder Edge-Computing-Szenarien sind k3s von Rancher (SUSE) und MicroK8s von Canonical die beliebtesten Alternativen zum vollständigen Kubernetes. Beide sind CNCF-zertifizierte Kubernetes-Distributionen, vollständig kompatibel mit kubectl und Helm – aber sie unterscheiden sich in Philosophie, Ressourcenbedarf und Zielgruppe erheblich.

Was ist k3s?

k3s wurde 2019 von Rancher Labs (heute SUSE) entwickelt und ist auf minimale Ressourcen und denkbar einfache Installation ausgelegt. Die gesamte Distribution ist in einer einzigen Binärdatei unter 100 MB verpackt und lässt sich mit einem einzigen Befehl installieren:

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

k3s ersetzt mehrere Kubernetes-Standardkomponenten durch leichtere Alternativen: SQLite statt etcd für Single-Node-Setups, Flannel als Standard-CNI, Traefik als Standard-Ingress-Controller und containerd als Container-Runtime. Es ist besonders beliebt für:

  • Homelab-Cluster auf Raspberry Pi oder ressourcenarmen VPS
  • Edge-Computing und IoT-Szenarien
  • CI/CD-Pipelines mit schnellem Cluster-Bootstrap
  • Entwicklungsumgebungen auf lokalen Maschinen

Was ist MicroK8s?

MicroK8s ist Canonicals Antwort auf einfaches Kubernetes. Es wird als Snap-Paket ausgeliefert, was Installation und Updates vereinfacht. Die Konfiguration erfolgt über ein Add-on-System:

sudo snap install microk8s --classic
microk8s enable dns ingress storage

MicroK8s nutzt standardmäßig upstream Kubernetes-Komponenten direkt – kein etcd-Ersatz, sondern dqlite (distributed SQLite) von Canonical für Multi-Node-HA. Es zielt primär auf Ubuntu-Nutzer ab, läuft aber auch auf anderen Linux-Distributionen via Snap.

Technischer Vergleich auf einen Blick

Kriterium k3s MicroK8s
Hersteller SUSE/Rancher Canonical
Installation Curl-Skript, Single Binary Snap-Paket
Binärgröße ~100 MB (all-in-one) Größer (native Komponenten)
Standarddatenbank SQLite (Single) / etcd (Multi) dqlite
Standard-CNI Flannel Calico
Standard-Ingress Traefik NGINX
HA-Multi-Node ✅ (embedded etcd ab 3 Nodes) ✅ (dqlite)
Add-on-System Helm, Manifeste, Kustomize microk8s enable
ARM-Support ✅ (ARM64, ARMv7) ✅ (ARM64)
Raspberry Pi ✅ sehr beliebt ✅ möglich
RAM-Verbrauch idle ~500 MB ~700 MB
Startzeit Sehr schnell (<60s) Schnell (<90s)

Installation und Setup im Vergleich

k3s in der Praxis

Der Einstieg mit k3s ist bemerkenswert schnell. Ein vollständiger Single-Node-Cluster ist in unter zwei Minuten einsatzbereit:

# Installation (Single-Node Server)
curl -sfL https://get.k3s.io | sh -

# Kubeconfig verfügbar machen
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml

# Status prüfen
kubectl get nodes
kubectl get pods -A

Für ein Multi-Node-Cluster fügt man Worker-Nodes über den Server-Token hinzu:

# Server-Token auslesen
cat /var/lib/rancher/k3s/server/node-token

# Worker-Node hinzufügen
curl -sfL https://get.k3s.io | K3S_URL=https://SERVER_IP:6443 K3S_TOKEN=TOKEN sh -

k3s integriert standardmäßig einen Helm Controller, der HelmChart-Ressourcen direkt im Cluster verwaltet – besonders praktisch für GitOps-Workflows mit ArgoCD oder Flux.

MicroK8s in der Praxis

MicroK8s setzt auf ein modulares Add-on-Modell und ist auf Ubuntu-Systemen besonders einfach:

# Installation
sudo snap install microk8s --classic
sudo usermod -a -G microk8s $USER
newgrp microk8s

# Add-ons aktivieren
microk8s enable dns ingress hostpath-storage

# Status prüfen
microk8s status
microk8s kubectl get nodes

Das microk8s-CLI bietet direkte Befehle wie microk8s kubectl, microk8s helm3 und microk8s dashboard-proxy. Für die Integration mit externen kubectl-Installationen exportiert man die Kubeconfig:

microk8s config > ~/.kube/config

Performance und Ressourcenverbrauch

Im realen Einsatz verbraucht k3s auf einem frisch installierten System (1 vCPU, 2 GB RAM) etwa 480–550 MB RAM im Idle-Zustand. MicroK8s verbraucht aufgrund der nativen upstream Komponenten typischerweise 650–750 MB RAM.

Für Raspberry Pi 3/4 (2–4 GB RAM) ist k3s die bevorzugte Wahl, da die geringere Basislast mehr Ressourcen für eigentliche Workloads lässt. MicroK8s läuft auch auf dem Pi, aber die Snap-Infrastruktur und der höhere RAM-Verbrauch machen es dort weniger ideal.

High Availability und Multi-Node-Betrieb

Beide Distributionen unterstützen Hochverfügbarkeit (HA) mit mehreren Control-Plane-Nodes. k3s nutzt eingebettetes etcd ab 3 Nodes – unter 3 Nodes greift SQLite. MicroK8s nutzt dqlite, Canonicals eigene verteilte SQLite-Implementierung, die bereits ab 3 Nodes HA bietet.

Für Produktionsumgebungen sind beide geeignet, aber k3s hat den Vorteil einer größeren Community und tiefen Rancher-Integration. Wer den Rancher-Management-Stack nutzt, greift ohnehin zu k3s oder RKE2.

Ecosystem und Integrationen

k3s ist die Basis für viele populäre Homelab-Stacks:

  • Rancher: Vollständiges Cluster-Management über Web-UI
  • Longhorn: Persistenter Blockstorage speziell für k3s-Cluster
  • ArgoCD/Flux: GitOps-Operatoren integrieren sich nahtlos
  • Helm: Vollständige Kompatibilität mit dem Standard-Paketmanager

MicroK8s bietet ein breites Add-on-Ökosystem:

  • microk8s enable istio – Service Mesh in einer Minute
  • microk8s enable knative – Serverless-Komponenten
  • microk8s enable kubeflow – ML-Pipelines für KI-Workloads
  • Enge Integration mit Juju und dem Ubuntu-Ökosystem

Wann welche Distribution wählen?

Wähle k3s wenn:

  • Du auf ARM-Hardware, Raspberry Pi oder ressourcenarmen VPS arbeitest
  • Du maximale Einfachheit und blitzschnellen Cluster-Bootstrap brauchst
  • Du Rancher, Longhorn oder andere SUSE-Komponenten nutzt
  • Du CI/CD-Pipelines mit temporären Kubernetes-Clustern betreibst
  • Du GitOps mit ArgoCD oder Flux umsetzen möchtest

Wähle MicroK8s wenn:

  • Du primär auf Ubuntu-Systemen entwickelst und deployest
  • Du das Add-on-System für einfaches Feature-Enabling schätzt
  • Du Istio, Knative oder KubeFlow im Homelab ausprobieren möchtest
  • Du eine Snap-basierte, automatisch aktualisierbare Distribution bevorzugst

Alternativen im Überblick

Neben k3s und MicroK8s gibt es weitere Optionen für den leichtgewichtigen Kubernetes-Betrieb:

  • RKE2 (SUSE): Wie k3s, aber mit stärkerem Security-Hardening für Produktionsumgebungen
  • Kind (Kubernetes in Docker): Nur für lokale Tests und CI gedacht, kein Produktionseinsatz
  • K0s (Mirantis): Schlank wie k3s, aber mit anderem Fokus auf Zero-Friction-Deployment
  • Talos Linux: Immutable OS speziell für Kubernetes, kein Shell-Zugang

Für den alltäglichen Homelab- und Self-Hosting-Einsatz bleiben k3s und MicroK8s die pragmatischen Erstentscheidungen – k3s für minimale Ressourcen, MicroK8s für maximale Erweiterbarkeit.

Verwandte Technologien im Techradar

Weiterführende Artikel