K3s vs MicroK8s vs Kind: Welches Mini-Kubernetes wofuer

TL;DR

K3s fuer Edge und kleine Produktions-Cluster, MicroK8s fuer lokale Entwicklung mit Add-on-System, Kind fuer CI-Pipelines und schnelle Wegwerf-Cluster. Alle drei sind zertifiziert konform. Die Wahl haengt vom Use Case ab, nicht von der Feature-Liste.

Drei Tools, ein Ziel: Kubernetes ohne den Overhead eines vollstaendigen Clusters. Aber jedes loest ein anderes Problem. Ich hab alle drei in Produktion, Entwicklung und CI eingesetzt. Hier ist, was tatsaechlich zaehlt.

Ueberblick: Was ist was

K3s (Rancher/SUSE): Ein einzelnes Binary unter 70 MB. Ersetzt etcd durch SQLite (oder embedded etcd fuer HA), buendelt containerd, Flannel und CoreDNS. Urspruenglich fuer Edge und IoT gebaut, laeuft aber problemlos als Produktions-Cluster.

MicroK8s (Canonical): Snap-Paket mit Add-on-System. Installiert ein vollstaendiges Kubernetes mit optionalen Komponenten (Istio, Knative, GPU-Support). Canonical pflegt es aktiv, eng an Ubuntu gebunden.

Kind (Kubernetes SIG): "Kubernetes in Docker". Startet Cluster-Nodes als Docker-Container. Gedacht fuer Kubernetes-Entwicklung selbst und CI-Tests. Kein Anspruch auf Produktionstauglichkeit.

Ressourcenverbrauch im Vergleich

Getestet auf Ubuntu 24.04, frische Installation, ein Node, kein Workload:

K3s ist der sparsamste. Auf einem Raspberry Pi 4 mit 2 GB RAM laeuft K3s mit einem kleinen Workload. MicroK8s braucht dort schon Tuning.

Installation

K3s

# Ein Befehl, fertig
curl -sfL https://get.k3s.io | sh -

# Kubeconfig direkt verfuegbar
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
kubectl get nodes

# Worker hinzufuegen (auf anderem Rechner)
curl -sfL https://get.k3s.io | K3S_URL="https://MASTER:6443" \
  K3S_TOKEN="$(cat /var/lib/rancher/k3s/server/node-token)" sh -

# Deinstallation
/usr/local/bin/k3s-uninstall.sh

MicroK8s

# Via Snap (Ubuntu, oder jede Distro mit snapd)
sudo snap install microk8s --classic --channel=1.31/stable

# Nutzer zur Gruppe hinzufuegen
sudo usermod -aG microk8s $USER
newgrp microk8s

# Status pruefen
microk8s status --wait-ready

# Add-ons aktivieren
microk8s enable dns storage ingress

# kubectl-Alias
alias kubectl='microk8s kubectl'

# Deinstallation
sudo snap remove microk8s

Kind

# Kind CLI installieren
go install sigs.k8s.io/kind@latest
# oder: brew install kind

# Cluster erstellen
kind create cluster --name dev

# Multi-Node-Cluster
cat <<EOF | kind create cluster --config=-
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker
EOF

# Kubeconfig wird automatisch gesetzt
kubectl get nodes

# Cluster loeschen
kind delete cluster --name dev

Kind braucht Docker oder Podman. Das ist gleichzeitig Staerke (keine Root-Rechte noetig auf vielen Systemen) und Einschraenkung (Docker-Overhead, kein echtes Networking).

Feature-Vergleich

Wann welches Tool

K3s: Edge, IoT, kleine Produktion

K3s glaenzt dort, wo Ressourcen knapp sind. Raspberry Pi Cluster, Edge-Standorte in Fabriken, kleine Produktionsumgebungen ohne Managed-Kubernetes-Budget.

Typischer K3s-Einsatz:

• Kubernetes auf ARM-Hardware (Raspberry Pi, Jetson Nano)
• Edge-Cluster in Filialen oder Fertigungshallen
• Hetzner/Netcup-Server als guenstige Produktions-Cluster
• Homelab und Lernumgebungen

K3s taugt nicht fuer: Wenn ihr ein vollstaendiges Ecosystem mit einem Klick braucht. Jede Erweiterung installiert ihr per Helm oder Manifest selbst.

MicroK8s: Lokale Entwicklung, All-in-One

MicroK8s ist das "Batteries-included"-Paket. GPU-Workloads testen? microk8s enable gpu. Service Mesh ausprobieren? microk8s enable istio. Das Add-on-System spart Zeit, wenn ihr verschiedene Features evaluieren wollt.

Typischer MicroK8s-Einsatz:

• Entwickler-Workstations (besonders Ubuntu)
• ML/AI-Prototyping mit GPU-Passthrough
• Feature-Evaluierung (Istio, Knative, Kubeflow)
• Teams, die keine Helm-Charts schreiben wollen

MicroK8s taugt nicht fuer: Extrem ressourcenlimitierte Umgebungen. Der Snap-Daemon und die Add-ons fressen mehr RAM als K3s.

Kind: CI/CD, Tests, kurzlebige Cluster

Kind erstellt Cluster in Sekunden und zerstoert sie genauso schnell. Perfekt fuer automatisierte Tests.

# Typischer CI-Einsatz (GitHub Actions)
- name: Create Cluster
  run: kind create cluster --wait 60s

- name: Run Tests
  run: |
    kubectl apply -f manifests/
    kubectl wait --for=condition=available deployment/app --timeout=120s
    ./run-integration-tests.sh

- name: Cleanup
  run: kind delete cluster

Typischer Kind-Einsatz:

• CI/CD-Pipelines (GitHub Actions, GitLab CI)
• Helm-Chart-Tests mit ct (chart-testing)
• Kubernetes-Controller-Entwicklung
• Schnelle Wegwerf-Cluster fuer Demos

Kind taugt nicht fuer: Alles was laenger als ein paar Stunden laufen soll. Kein HA, kein echtes Networking, kein Persistent Storage out of the box.

Performance-Vergleich: Pod-Startup

Gemessen: Zeit von kubectl apply bis Pod im Status Running, nginx:1.27-alpine Image (schon gepullt):

K3s ist durchgehend schneller, weil weniger Abstraktionsschichten. Kind hat den Docker-Overhead.

Migration zwischen den Tools

Ein haeufiges Muster: Entwicklung auf Kind, Staging auf MicroK8s, Produktion auf K3s. Die Manifeste sind identisch -- alle drei sind CNCF-konform. Probleme entstehen bei:

• Storage Classes: Jedes Tool bringt eine andere Default-StorageClass mit. Nutzt explizite storageClassName in PVCs.
• Ingress: K3s hat Traefik, MicroK8s hat nginx, Kind hat nichts. Standardisiert auf einen Controller.
• CNI-spezifische Features: Calico NetworkPolicies auf MicroK8s vs. Flannel auf K3s -- testet NetworkPolicies in der gleichen Umgebung wie Produktion.

# StorageClass-Unterschiede pruefen
kubectl get storageclass

# K3s:      local-path (default)
# MicroK8s: microk8s-hostpath (nach enable storage)
# Kind:     standard (hostpath)

Entscheidungsmatrix

Beantwortet diese drei Fragen:

1. Laeuft der Cluster laenger als einen Tag? Nein -> Kind. Ja -> weiter.
2. Ist RAM unter 1 GB verfuegbar? Ja -> K3s. Nein -> weiter.
3. Braucht ihr ein Add-on-Ecosystem? Ja -> MicroK8s. Nein -> K3s.

Im Zweifel: K3s. Es deckt die meisten Use Cases ab, braucht am wenigsten Ressourcen und skaliert von einem Raspberry Pi bis zu einem 50-Node-Cluster.

FAQ

Kann ich K3s in Produktion einsetzen?

Ja. K3s ist CNCF-zertifiziert und laeuft bei SUSE-Kunden in Produktion. Mit embedded etcd und drei Control-Plane-Nodes bekommt ihr HA. Das ist kein Spielzeug.

Ist MicroK8s wirklich an Ubuntu gebunden?

Nein, aber es braucht snapd. Auf Fedora, Arch oder Debian funktioniert es, ist aber weniger getestet. Auf Ubuntu laeuft es am stabilsten.

Wie unterscheidet sich Kind von Minikube?

Kind nutzt Docker-Container als Nodes, Minikube startet VMs (oder Docker). Kind ist schneller, leichter und besser fuer CI. Minikube hat mehr Features fuer lokale Entwicklung (Dashboard, Tunnel, Add-ons).

Kann ich zwischen K3s und MicroK8s wechseln?

Eure Workloads (Deployments, Services, ConfigMaps) sind portabel. Cluster-spezifische Konfiguration (StorageClasses, CNI-Policies, Ingress-Controller) muesst ihr anpassen. Plant dafuer 2-4 Stunden ein.

Unsicher, welches Mini-Kubernetes fuer euer Szenario passt? Ich berate Teams bei der Auswahl und dem initialen Setup -- pragmatisch und ohne Vendor-Lock-in.

Weiterführende Artikel:

• K3s vs MicroK8s: Edge-Kubernetes für IoT und Fertigung
• Kubernetes Tutorial: Erster Pod, Deployment und Service