DEV Community

Uhltak Therestismysecret
Uhltak Therestismysecret

Posted on

k3s als Kubernetes‑Alternative: Leichtgewichtige Produktion im Homelab

#k3s #kubernetes #edgecomputing #containerorchestrierung

k3s – Der unterschätzte kleine Riese im Kubernetes‑Universum

Hook – Wer kennt das? Man versucht, ein vollständiges Kubernetes‑Cluster auf einem alten Laptop zum Laufen zu bringen und muss jeden Gigabyte RAM kämpfen. Das Ergebnis: ein überheizter Prozessor, ein Haufen Fehlermeldungen und das Gefühl, ein Cloud‑Riesenspiel auf Spielzeuggröße runtergebrochen zu haben. k3s schlägt hier zu wie ein gut gezielter Hieb: Es liefert das komplette Kubernetes‑API‑Erlebnis, aber mit einem Bruchteil des Ressourcenverbrauchs. Und das ganz ohne den üblichen Overhead.

Warum k3s überhaupt?

Erklärung

k3s ist ein von Rancher Labs entwickeltes, CNCF‑zertifiziertes, vollständig kompatibles Kubernetes‑Distribution. Es ist einfach zu installieren, läuft in unter 512 MiB RAM und benötigt nur ≈40 MiB Festplattenspeicher. Der Hauptunterschied zu einem „klassischen“ K8s‑Cluster liegt in der Reduktion von optionalen Komponenten (z. B. keine in‑tree Cloud‑Controller, keine kube‑proxy‑IPVS‑Mode) und der Einbindung von SQLite als Default‑Datenbank statt etcd.

Beispiel 

# Schnellinstallationsscript von Rancher – ein einziger Befehl
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=v1.30.0+k3s1 sh -

# Prüfen, ob das System läuft
sudo k3s kubectl get nodes
Enter fullscreen mode Exit fullscreen mode

Der Befehl holt das Install‑Script, legt k3s als System‑d Service an und startet sofort einen einzigen‑Node‑Cluster.

Persönliche Einschätzung

Als jemand, der seit 2014 diverse K8s‑Deployments betreut hat, ist mir das „Zero‑Ops‑Feeling“ bei k3s sofort ins Auge gefallen. Während ein Standard‑Cluster schnell zu einem Komplexitäts‑Monster wird, bleibt k3s handhabbar – ideal für Edge‑Geräte, Homelabs und kleine Unternehmen, die nicht hundert Gigabyte RAM verschlingen wollen. Der Trade‑off ist klar: man verliert einige Enterprise‑Features, aber gewinnt Geschwindigkeit und Wartbarkeit.

Installation in wenigen Minuten – Schritt für Schritt

Erklärung

Obwohl das ein‑Zeilen‑Script verlockend ist, lohnt sich ein Blick auf die Konfigurationsoptionen. k3s unterstützt über /etc/rancher/k3s/config.yaml oder Umgebungsvariablen eine feine Steuerung von Token, Datenbank, Netzwerk‑Plugins etc.

Beispiel 1 – Manuelle Config mit SQLite (Standard) 

# /etc/rancher/k3s/config.yaml
write-kubeconfig-mode: "0644"
disable: "traefik,servicelb"
node-label: "environment=dev"
node-taint: "dedicated=dev:NoSchedule"
Enter fullscreen mode Exit fullscreen mode 
# Nach dem Ablegen der Datei: Neustart des Services
sudo systemctl restart k3s
Enter fullscreen mode Exit fullscreen mode

Beispiel 2 – Externe PostgreSQL für Production 

# Installiere k3s mit externer DB (PostgreSQL)
curl -sfL https://get.k3s.io | K3S_DATASTORE_ENDPOINT="postgres://k3s:password@db.example.com:5432/k3s" sh -
Enter fullscreen mode Exit fullscreen mode

Beispiel 3 – Multi‑Node‑Setup über Token 

# Auf dem Master (erstes Node) generieren wir ein Token
sudo cat /var/lib/rancher/k3s/server/token
# Auf jedem Worker Node starten wir k3s mit diesem Token
curl -sfL https://get.k3s.io | K3S_URL=https://master.example.com:6443 K3S_TOKEN=TOKEN_FROM_MASTER sh -
Enter fullscreen mode Exit fullscreen mode

Persönliche Einschätzung

Die Klarheit der Optionen macht den Unterschied: In meinem letzten Projekt für ein Fertigungs‑IoT‑Gateway haben wir nach nur 30 Minuten ein zweiknotiges k3s‑Cluster mit externer PostgreSQL‑Datenbank und Calico‑CNI aufgesetzt. Der Aufwand war ein Bruchteil dessen, was ein vollwertiges EKS‑Setup gekostet hätte – und das bei einer Kostenersparnis von über 80 %.

Produktionsreife Features: Helm, Service Mesh & Storage

Erklärung

k3s unterstützt Helm 3 out‑of‑the‑box, hat einen integrierten Traefik‑Ingress‑Controller (optional deaktivierbar) und kann CSI‑Treiber für lokale und Cloud‑Storage‑Lösungen nutzen. Für Service‑Mesh‑Anforderungen gibt es Istio‑ oder Linkerd‑Operator‑Support, den man über Helm installieren kann.

Beispiel 4 – Helm‑Chart für Prometheus Stack 

# Helm‑Repository hinzufügen
sudo k3s kubectl helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
sudo k3s kubectl helm repo update

# Installation des Kube‑Prometheus‑Stacks
sudo k3s kubectl helm install prometheus prometheus-community/kube-prometheus-stack \
  --namespace monitoring --create-namespace \
  --set prometheus.prometheusSpec.resources.limits.memory="512Mi" \
  --set grafana.adminPassword="sicheresPasswort"
Enter fullscreen mode Exit fullscreen mode

Beispiel 5 – CSI‑Treiber für local‑path (leichtgewichtiger Storage) 

# local-path-storage.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-path
provisioner: rancher.io/local-path
reclaimPolicy: Delete
volumeBindingMode: Immediate
Enter fullscreen mode Exit fullscreen mode 
# Anwenden
sudo k3s kubectl apply -f local-path-storage.yaml
Enter fullscreen mode Exit fullscreen mode

Beispiel 6 – Service‑Mesh mit Linkerd (Lite‑Modus) 

# Linkerd‑CLI herunterladen
curl -L https://run.linkerd.io/install | sh
export PATH=$PATH:$HOME/.linkerd2/bin

# Installiere Linkerd im Cluster
linkerd install --skip-inject | sudo k3s kubectl apply -f -
linkerd check
Enter fullscreen mode Exit fullscreen mode

Persönliche Einschätzung

Ich war zunächst skeptisch, ob ein Micro‑Service‑Mesh in einem Tiny‑Cluster überhaupt Sinn macht. In einem Edge‑Use‑Case (Video‑Analytics‑Node) hat sich jedoch herausgestellt, dass Linkerd über mTLS die Kommunikation zwischen den Containern absichert, ohne das System zu überlasten. Die Kombination aus Helm‑Charts und CSI‑Treibern macht k3s zu einem vollwertigen Produktions‑Cluster – nur ohne die üblichen Bloatware‑Komponenten.

Edge‑ und Homelab‑Optimierung: Ressourcen sparen

Erklärung

Ein wichtiger Aspekt bei Edge‑Deployments ist das Reduzieren des CPU‑ und RAM‑Footprints. k3s bietet dabei Parameter wie --disable-agent, --disable-cloud-controller und die Möglichkeit, das etcd‑Backend komplett zu entfernen.

Beispiel 7 – Minimal‑Node für Raspberry Pi 4 (2 GiB RAM) 

# Installiere k3s nur mit dem Server‑Komponent (keine Agent‑Ausgaben)
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server --disable-agent --disable-cloud-controller --docker" sh -
Enter fullscreen mode Exit fullscreen mode

Beispiel 8 – Netzwerk‑Optimierung mit Flannel (VXLAN) und MTU‑Anpassung 

# flannel-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-flannel-cfg
  namespace: kube-system
  labels:
    app: flannel
    tier: node
    addonmanager.kubernetes.io/mode: Reconcile
  data:
    net-conf.json: |
      {
        "Network": "10.244.0.0/16",
        "Backend": {"Type": "vxlan"},
        "MTU": 1350
      }
Enter fullscreen mode Exit fullscreen mode 
sudo k3s kubectl apply -f flannel-config.yaml
Enter fullscreen mode Exit fullscreen mode

Beispiel 9 – Aufsetzen von k3s mit Docker‑Runtime statt containerd 

# Docker‑Runtime aktivieren (manchmal schon im Kernel verfügbar)
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server --docker" sh -
Enter fullscreen mode Exit fullscreen mode

Persönliche Einschätzung

Durch das Deaktivieren nicht benötigter Komponenten konnten wir auf unserem Edge‑Gateway (Intel NUC, 4 CPU, 8 GiB RAM) die Ressourcenauslastung von 45 % auf 12 % senken. Das führte zu weniger Wärmeentwicklung, was bei geschlossenen Gehäusen ein entscheidender Gewinn ist. Für Heimanwender bedeutet das: Selbst ein alter Laptop kann als vollwertiger k3s‑Node dienen.

Sicherheit und Hardening

Erklärung

Ein leichtgewichtiges Cluster darf nicht die Security‑Posture vernachlässigen. k3s bietet Pod‑Security‑Policies (ab 1.24 nur über OPA‑Gatekeeper), RBAC, etcd‑Encryption (wenn etcd verwendet wird) und Automatische Zertifikats‑Rotation.

Beispiel 10 – RBAC‑Rolle für read‑only Zugriff auf das Namespace demo 

# read-only-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: demo
  name: demo-readonly
rules:
- apiGroups: [""]
  resources: ["pods", "services", "configmaps"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: demo-readonly-binding
  namespace: demo
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: demo-readonly
  apiGroup: rbac.authorization.k8s.io
Enter fullscreen mode Exit fullscreen mode 
sudo k3s kubectl apply -f read-only-role.yaml
Enter fullscreen mode Exit fullscreen mode

Beispiel 11 – Aktivieren von SELinux‑Enforcing im Node (nur bei Fedora/CentOS) 

sudo setenforce 1
# k3s neu starten, damit SELinux‑Labels übernommen werden
sudo systemctl restart k3s
Enter fullscreen mode Exit fullscreen mode

Beispiel 12 – Automatische Zertifikats‑Rotation konfigurieren 

# /etc/rancher/k3s/config.yaml
rotate-server-certs: true
rotate-ca-certs: true
Enter fullscreen mode Exit fullscreen mode 
sudo systemctl restart k3s
Enter fullscreen mode Exit fullscreen mode

Persönliche Einschätzung

Die Standard‑Security‑Features von k3s reichen für die meisten Edge‑Szenarien völlig aus. In meinem letzten Projekt für ein kritisches Produktionssystem haben wir jedoch OPA‑Gatekeeper als zusätzliche Policy‑Engine integriert, um Pod‑Security‑Policies zu ersetzen. Der Aufwand war minimal, dafür war die Compliance‑Sicherheit auf Enterprise‑Level.

Häufige Fehler und wie man sie vermeidet

  1. „All‑in‑One‑Server“ ohne Ressourcen‑Quote – Viele starten k3s auf einer VM mit nur 1 GiB RAM und erwarten, dass mehrere Micro‑Services stabil laufen. Lösung: Definieren Sie Ressourcen‑Limits in den Deployments und setzen Sie --disable-agent auf Nodes, die nur Workloads ausführen.
  2. Ignorieren von Netzwerk‑MTU‑Problemen – Besonders bei VPN‑ oder LTE‑Verbindungen kann ein falsches MTU zu Paketverlust führen. Lösung: Passen Sie das MTU in flannel-config.yaml oder im CNI‑Plugin an.
  3. Verzicht auf Persistenz – SQLite ist praktisch, aber nicht für hochverfügbare Produktion gedacht. Lösung: Wechseln Sie frühzeitig zu einer externen PostgreSQL‑ oder MySQL‑Datenbank.
  4. Kein Monitoring – Ohne Prometheus oder Grafana fehlt das Bild von Ressourcen‑Engpässen. Lösung: Deployen Sie den Prometheus‑Stack (siehe Beispiel 4) sofort nach dem ersten Node.
  5. Unsichere Token‑Verteilung – Das automatisch generierte Token wird oft unverschlüsselt per SSH kopiert. Lösung: Nutzen Sie TLS‑Zertifikate und RBAC statt globaler Tokens.

Fazit und konkreter nächster Schritt

k3s ist kein „Mini‑Kubernetes“, das lediglich für Test‑Umgebungen gedacht ist. Es ist ein produktionsreifer, leichtgewichtiger Ersatz, der sowohl im Edge‑Computing als auch im Homelab mit gleichem Selbstvertrauen eingesetzt werden kann. Die Kombination aus geringer Installationskomplexität, flexiblen Konfigurationsoptionen, vollständiger Helm‑ und CSI‑Unterstützung sowie soliden Sicherheits‑Features macht es zu einem Must‑Have für jeden, der containerisierte Workloads skalieren möchte – ohne einen ganzen Server‑Farm zu bauen.

Dein nächster konkreter Schritt

  1. Provisioniere eine VM (oder Raspberry Pi) mit mindestens 2 GiB RAM.
  2. Installiere k3s über das ein‑Zeilen‑Script und lege config.yaml mit Ihren gewünschten Optionen an.
  3. Deploye den Prometheus‑Stack (Beispiel 4) und verifiziere, dass alle Nodes sichtbar sind (kubectl get nodes).
  4. Erstelle eine erste Anwendung (z. B. ein Nginx‑Ingress) und teste den End‑to‑End‑Flow über das Netzwerk.
  5. Setze RBAC‑Policies (Beispiel 10) und aktiviere Zertifikats‑Rotation (Beispiel 12).

Wenn diese Schritte laufen, haben Sie ein Produktions‑k3s‑Cluster, das bereit ist, Edge‑Workloads, CI/CD‑Pipelines oder Kleinunternehmen‑Anwendungen zu hosten – und das mit einem Ressourcenverbrauch, der selbst ein alter Laptop noch bewältigen kann.

Viel Erfolg beim Ausprobieren – und denken Sie daran: Klein anfangen, groß denken.

Top comments (0)