DEV Community

Uhltak Therestismysecret
Uhltak Therestismysecret

Posted on

k3s statt Kubernetes: Warum die Rancher-Distribution unschlagbar ist

#linux #devops #kubernetes #k3s

k3s statt Kubernetes: Warum die Rancher-Distribution unschlagbar ist

Honesty time: Wer heute noch ein vollwertiges, upstream Kubernetes per kubeadm in einer Entwicklungsumgebung oder einem kleinen Homelab aufsetzt, baut sich einen Tempel, in dem niemand betet. Die Menge an beweglichen Teilen – etcd, kube-apiserver, scheduler, controller-manager, CNI, Ingress Controller – erzeugt so viel Ballast, dass man oft mehr Zeit mit dem Debugging des Clusters verbringt als mit der eigentlichen Anwendungsentwicklung.

Hier kommt k3s ins Spiel. Entwickelt von SUSE (bzw. Rancher), ist k3s keine abgespeckte Spielzeugversion, sondern eine hochkompakte, aber voll CVE-konforme Kubernetes-Distribution. Sie wurde speziell für IoT, Edge Computing und CI/CD-Pipelines konzipiert, hat sich aber längst auch als extrem robustes Fundament für Produktivsysteme kleiner bis mittlerer Auslegung bewährt.

In diesem Artikel zeige ich euch, warum k3s die vernünftige Wahl für den meisten Use Cases ist, wie ihr es in unter drei Minuten installiert und welche Fallstricke es bei der Netzwerkkonfiguration gibt. Wir verlassen hier das theoretische Gedöns und schauen direkt in die Praxis.

Was macht k3s eigentlich anders? (Und warum das wichtig ist)

Klassisches Kubernetes besteht aus mehreren Dutzend Binaries und erfordert meist mindestens drei Server-Knoten, nur um das interne Schlüsselverwaltungssystem etcd redundant zu betreiben. Das ist für die Produktion großartiger Banken-Infrastruktur gut, für ein Startup oder ein modernes DevOps-Team jedoch absolut überdimensioniert.

k3s packt alles, was man braucht, in eine einzelne Binary von knapp 100 MB Größe.

Die Magie dahinter sind einige gezielte Kürzungen:

  1. Embedded Database: Standardmäßig nutzt k3s SQLite statt etcd. Ja, SQLLite! Das klingt nach einem Rückschritt, ist aber für Cluster mit bis zu 50 Knoten und 5.000 Pods mehr als performant und eliminiert den operativen Aufwand eines separaten Datenbanksclusters komplett.
  2. Entfernte Add-Ons: Alte Storage-Plugins (wie GCE oder AWS EBS nativ) und Ingress-Controller (wie nginx oder traefik im alten Stil), die sowieso kaum noch genutzt werden, wurden rausgeworfen. Stattdessen wird standardmäßig Flannel als CNI (Container Network Interface) und Local-path-provisioner für persistenten Speicher mitgeliefert.
  3. Bundle-Ansatz: Alle Komponenten laufen als systemd-Services unter einer einzigen Haupteinheit.

Persönliche Einschätzung

Ich habe in den letzten Jahren dutzende Kubernetes-Cluster administraturiert. k3s hat meine mentale Last halbiert. Man vermisst manchmal die tiefgreifende Kontrolle von Vanilla-K8s, aber wenn man ehrlich ist: Wie oft aktualisiert man wirklich die Version von kube-proxy manuell? k3s automatisiert diesen Overhead hervorragend.

Beispiel 1: Die Installation in 60 Sekunden

Kein kubeadm init, kein Download von fünf verschiedenen tar-Dateien, kein Konfigurieren von cgroups. k3s setzt sich so einfach auf, wie ein normales Linux-Paket.

Öffnet euer Terminal auf eurem Ubuntu-, Debian- oder RHEL-basierten Server und führt folgendes aus:

curl -sfL https://get.k3s.io | sh -
Enter fullscreen mode Exit fullscreen mode

Das ist nicht nur Ein-Zeiler-Marketing. Der Installer lädt die kompilierte Binary herunter, richtet die notwendigen systemd-Services ein und startet den Cluster sofort.

Wenn der Befehl durchgelaufen ist, liegt euer kubeconfig automatisch unter /etc/rancher/k3s/k3s.yaml. Um als normaler User darauf zugreifen zu können, kopiert ihr es typischerweise:

sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
sudo chown $USER:$USER ~/.kube/config
Enter fullscreen mode Exit fullscreen mode

Testet die Verbindung mit:

kubectl get nodes
Enter fullscreen mode Exit fullscreen mode

Ihr solltet sofort euren Node mit dem Status Ready sehen. Fertig. Ihr habt jetzt einen lauffähigen Kubernetes-Cluster.

Persönliche Einschätzung

Es fühlt sich fast illegal an, wie schnell das geht. Früher brauchte ich für ein funktionierendes Lab-Setup mindestens eine Stunde. Mit k3s bin ich in der Zeit schon dabei, Helm-Charts zu deployen. Diese Schnelligkeit befähigt Teams enorm, denn sie senkt die Einstiegshürde für neue Entwickler drastisch.

Beispiel 2: Multi-Node Cluster ohne externen etcd

Ein Single-Node-Cluster ist nett zum Testen, aber was ist, wenn wir Hochverfügbarkeit wollen? Bei Vanilla K8s müsstet ihr entweder einen eigenen, externalisierten etcd-Cluster pflegen oder komplexe Join-Prozeduren für mehrere Control-Plane-Nodes (--control-plane) durchführen.

k3s löst das elegant über sein eingebautes Storage-Backend (SQLite) in Kombination mit einem sogenannten Server-Token. Dabei übernimmt der erste Node die Rolle des Hauptcontrollers, und weitere Nodes hängen sich einfach daran.

Schritt 1: Auf eurem Master-Node sucht ihr den Token heraus:

sudo cat /var/lib/rancher/k3s/server/node-token
Enter fullscreen mode Exit fullscreen mode

Kopiert diesen langen String.

Schritt 2: Auf euren Worker-Nodes (oder weiteren Server-Nodes für HA) führt ihr folgenden Befehl aus:

curl -sfL https://get.k3s.io | sh -s - --server https://<MASTER_IP>:6443 --token <EUCHER_TOKEN>
Enter fullscreen mode Exit fullscreen mode

Das war's. k3s synchronisiert die Daten intern über SQLite-Replikation (in der Enterprise-Variante bzw. neueren Versionen auch über embedded etcd, falls man den Flag -d/--datastore-endpoint auf etcd umstellt, aber Standard-SQLite reicht für kleine HA-Setups oft aus).

Überprüft erneut vom Master aus:

kubectl get nodes
# Ausgabe sollte nun alle Nodes mit 'Ready' auflisten
Enter fullscreen mode Exit fullscreen mode

Persönliche Einschätzung

Die Tatsache, dass man keinen separaten etcd-Cluster pflegen muss, ist der größte运维 (Operational)-Gewinn. Ich habe schon unzählige Nächte damit verbracht, korrupte etcd-Snapshots wiederherzustellen. Das passiert bei k3s mit SQLite so gut wie nie. Es ist pragmatisch und trifft genau den Sweet Spot für 90% aller Self-Hosted- und On-Premise-Szenarien.

Beispiel 3: Networking und Ingress (Traefik & MetalLB)

Standardmäßig bringt k3s Flannel mit. Flannel ist simpel, funktioniert über VXLAN und reicht für die meisten internen Kommunikationsszenarien völlig aus. Doch irgendwann wollt ihr eure Apps von außen erreichen.

Dafür nutzen wir zwei gängige Open-Source-Tools, die perfekt mit k3s harmonieren: Traefik als Ingress Controller und MetalLB als Load-Balancer für bare-metal Umgebungen (da wir keinen Cloud-Provider wie AWS haben, der uns automatisch externe IPs zuweist).

Zuerst installieren wir MetalLB via Helm, damit LoadBalancer-Services echte IPs aus unserem lokalen Netzwerk bekommen:

helm repo add metallb https://metallb.github.io/metallb
helm install metallb metallb/metallb -n metallb --create-namespace

# Konfigurationsdatei für Metallb (config.yaml)
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 192.168.1.240-192.168.1.250 # Passt dies an euer LAN an!
Enter fullscreen mode Exit fullscreen mode

Anschließend deployen wir Traefik:

helm repo add traefik https://helm.traefik.io/traefik
helm install traefik traefik/traefik -n traefik --create-namespace --set service.type=LoadBalancer
Enter fullscreen mode Exit fullscreen mode

Da MetalLB jetzt läuft, bekommt der Traefik-Service automatisch eine IP aus dem definierten Pool zugewiesen. Fragt ab mit:

kubectl get svc -n traefik
# Sucht nach der EXTERNAL-IP unter traefik
Enter fullscreen mode Exit fullscreen mode

Persönliche Einschätzung

Kubernetes-Netzwerke waren historisch gesehen eine absolute Katastrophe zu verstehen (CNI, CILI, Services, Ingress, NetworkPolicies). k3s ändert daran nichts Grundlegendes, da es spezzifikationstreu bleibt. Aber durch die klaren Defaults (Flannel!) und die leichte Integration von Tools wie MetalLB spart man sich das mühsame Basteln an VPC-CNDIs, wie man sie von AWS oder Azure kennt. Im lokalen Rechenzentrum ist MetalLB + k3s die ungeschlagene Kombination.

Häufige Fehler und Fallen

Auch wenn k3s einfach ist, gibt es Dinge, die euch in die Quere kommen können. Hier sind die häufigsten Probleme, mit denen ich Support leisten musste:

1. Der "SELinux from Hell" Modus

k3s läuft am besten, wenn SELinux im permissive Modus ist oder komplett deaktiviert wurde. Wenn ihr strict enforcing benutzt, werdet ihr Fehlermeldungen bekommen, weil Container nicht starten können oder Netzwerkregeln blockiert werden.
Abhilfe: Führt setenforce 0 aus oder passt eure SELinux-Policies präzise an, was jedoch sehr aufwendig ist und oft gegen die Philosophie von k3s als „schnelles Setup“ verstößt.

2. Nur eine WAN-IP, aber mehrere Nodes?

Viele Homelabber oder kleine Provider haben nur eine öffentliche IPv4-Adresse. Wie bringt man einen Multi-Node k3s Cluster hinter eine einzige IP?
Abhilfe: Nutzt einen Reverse Proxy (wie HAProxy oder Nginx) vor dem k3s Master, der den Traffic auf Port 6443 (API) und 10250 (kubelet) weiterleitet, oder schaltet im Router ein NAT/DNAT ein. Noch besser: Setzt von Anfang auf IPv6 lokal und nutze Cloudflare Tunnels (cloudflared) für den sicheren External Access, ohne Ports öffnen zu müssen.

3. Resource Limits vergessen

Weil k3s so leicht ist, denken viele, sie könnten alles darauf stapeln. Vergesst niemals LimitRange und ResourceQuota in eurem Namespace einzurichten. Ein vergessener CronJob, der in eine Endlosschleife gerät, kann euren ganzen Host aushungern, wenn keine Limits gesetzt sind.

Fazit und dein nächster Schritt

k3s ist keine temporäre Modeerscheinung. Es hat sich als de-facto Standard für Edge-Kubernetes etabliert und bietet selbst für mittelgroße Production-Workloads (bis ca. 50 Nodes) eine fantastische Stabilität. Der Verzicht auf etcd zugunsten von SQLite ist der Schlüssel, der den operativen Albdruck massiv verringert.

Wenn ihr bisher von Kubernetes abgeschreckt wart, weil es zu komplex wirkte, oder wenn ihr euer altes, schweres Setup entschlacken möchtet: Gebt k3s eine Chance.

Dein konkreter nächster Schritt:
Wählt euch einen leeren VM oder einen Raspberry Pi 4 aus. Loggt euch ein, führt curl -sfL https://get.k3s.io | sh - aus und deploys eine einfache Webanwendung (z.B. nginx). Spielt herum, brecht es kaputt, startet neu. Ihr werdet überrascht sein, wie wenig kaputtgehen kann und wie schnell ihr wieder funktionsfähig seid.

Top comments (0)