k3s: Leichtgewichtiges Kubernetes für lokale Hardware, Proxmox und den Mittelstand

Kubernetes ist der Standard für Container-Orchestrierung — aber Standard-Kubernetes ist für viele Anwendungsfälle zu schwer, zu komplex und zu sehr auf Cloud-Infrastruktur ausgerichtet. Ein Cluster mit drei Control-Plane-Nodes, externem etcd-Cluster und Cloud-Load-Balancer ist für einen Raspberry-Pi-Cluster im Homelab genauso fehl am Platz wie für ein mittelständisches Unternehmen ohne dediziertes Kubernetes-Team.

k3s ist die Antwort auf dieses Problem. Entwickelt von Rancher (heute SUSE), seit 2020 ein CNCF-Projekt und vollständig Kubernetes-konform — aber in einem einzigen Binary unter 100 MB, mit halb so viel RAM-Verbrauch wie upstream Kubernetes, ohne externe Abhängigkeiten. Ein curl | sh und ein Cluster läuft.

GitHub: k3s-io/k3s — ~33k ⭐, 2.6k Forks

Was k3s weglässt — und warum das gut ist

k3s ist kein Fork von Kubernetes, sondern eine Distribution. Der Unterschied: k3s divergiert nicht vom Upstream, sondern paketiert es anders. Was weggelassen wurde, sind genau zwei Dinge:

In-Tree-Storage-Driver — Treiber für AWS EBS, GCE Persistent Disk, Azure Disk und andere Cloud-Speicher sind nicht enthalten. Sie werden durch das CSI-Interface (Container Storage Interface) ersetzt, das dieselbe Funktionalität als externe Komponente liefert. In k3s-Umgebungen läuft stattdessen der local-path-provisioner für einfache lokale Volumes, oder Longhorn für verteilten Speicher.

In-Tree-Cloud-Provider — Keine direkte Integration mit AWS, GCP, Azure im Kern. Auch das über das CCM-Interface (Cloud Controller Manager) nachrüstbar.

Was daraus folgt: Das Binary ist kleiner, der Speicherverbrauch geringer, die Startzeit kürzer. Und es gibt keine Cloud-Abhängigkeiten im Kern — k3s läuft auf jedem Linux-System, das einen vernünftigen Kernel und cgroup-Mounts hat.

Was k3s stattdessen mitbringt: containerd, runc, Flannel als CNI, CoreDNS, Traefik als Ingress-Controller, einen eingebauten Service-Load-Balancer (Klipper-lb), einen Helm-Controller, SQLite als Standard-Datenbank und den local-path-provisioner. Alles in einem Binary, alles sofort einsatzbereit.

Installation: ein Befehl

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

# Worker-Node hinzufügen (NODE_TOKEN aus /var/lib/rancher/k3s/server/node-token)
curl -sfL https://get.k3s.io | K3S_URL=https://myserver:6443 K3S_TOKEN=XXX sh -

# Cluster-Status prüfen
sudo kubectl get nodes

k3s registriert sich automatisch als systemd-Service. Die kubeconfig landet unter /etc/rancher/k3s/k3s.yaml. Keine separaten etcd-, kube-apiserver- oder controller-manager-Prozesse — alles läuft in einem einzigen Prozess, was den Memory-Overhead erheblich reduziert.

Einsatzzweck: Homelab und lokale Entwicklung

Das häufigste Einstiegsszenario für k3s ist das Homelab: ein oder mehrere alte Rechner, Mini-PCs oder Raspberry Pis, auf denen ein vollwertiger Kubernetes-Cluster laufen soll — ohne Cloud-Kosten, mit vollem Zugriff auf alle Kubernetes-Konzepte.

k3s eignet sich dafür besser als Minikube oder Kind (die nur für lokale Entwicklung gedacht sind), weil es ein echter Cluster ist: mehrere Nodes, echte Netzwerkpolicies, echtes Ingress, persistente Volumes. Workloads, die auf k3s laufen, laufen mit minimalen Anpassungen auch auf EKS oder GKE.

Für Entwickler, die Kubernetes lernen wollen, ist k3s der beste Einstieg: Die Konzepte sind identisch mit upstream Kubernetes, aber der Betrieb ist deutlich einfacher.

Einsatzzweck: ARM und Raspberry Pi

k3s unterstützt ARM64 und ARMv7 nativ — das Binary für den Raspberry Pi ist genauso stabil wie die x86_64-Version. Ein Cluster aus drei Raspberry Pi 4 oder Pi 5 ist ein voll funktionsfähiger k3s-Cluster.

Minimale Hardware für einen Raspberry Pi 4 Cluster:

Rolle	RAM	CPU	Speicher
Server (Control Plane)	1 GB (2 GB empfohlen)	2 Cores	16 GB SD/SSD
Agent (Worker)	512 MB	1 Core	8 GB SD/SSD

Wichtig: SD-Karten sind für etcd-Schreiblast ungünstig. USB-SSDs oder NVMe über USB 3.0 verlängern die Lebensdauer erheblich und verbessern die Performance.

Für Pi-Cluster empfiehlt sich, SQLite als Datenbank zu behalten (Standard, kein separater Prozess) und Longhorn für persistente Volumes zu installieren — Longhorn nutzt den lokalen Speicher aller Nodes und repliziert ihn über den Cluster.

Einsatzzweck: Edge und IoT

k3s ist das Kubernetes für Situationen, in denen kein Team verfügbar ist, das den Cluster verwaltet — Industrieanlagen, Filialserver, Remote-Standorte, eingebettete Systeme.

Die Eigenschaften machen k3s dafür geeignet:

• Ein-Binary-Deployment: Kein Paket-Manager, keine Abhängigkeiten, kein externes etcd. Eine Datei, ein Service.
• Automatische Updates: k3s kann sich selbst über einen Helm-Chart-Controller aktualisieren.
• Geringe Ressourcen: Läuft auf Hardware mit 512 MB RAM und 1 CPU-Core.
• Airgap-fähig: k3s unterstützt Offline-Installationen — Image-Archive und Binaries können vorab gepackt und ohne Internetzugang installiert werden.

In IoT-Szenarien läuft k3s oft als Single-Node-Cluster: Eine Maschine, ein Control-Plane-Prozess, ein Worker. Das ergibt kein HA-Setup, aber es ergibt volle Kubernetes-API-Kompatibilität mit minimalem Ressourcenverbrauch.

Einsatzzweck: Mittelständische Unternehmen

Für Unternehmen mit 50 bis 500 Mitarbeitern, eigenem Rechenzentrum oder Colocation, aber ohne dediziertes Kubernetes-Infrastruktur-Team, ist k3s der pragmatische Mittelweg.

Was k3s in diesem Kontext bringt:

Kubernetes-API-Kompatibilität bedeutet: Standard-Helm-Charts, ArgoCD, Flux, Cert-Manager, External-DNS — das gesamte CNCF-Ökosystem funktioniert. Ein Entwickler, der AWS EKS kennt, findet sich auf k3s in Minuten zurecht.

Was k3s vereinfacht:

Kein etcd-Cluster-Management. SQLite als Default reicht für kleine bis mittlere Cluster (unter 50 Nodes). Für größere Setups oder HA-Anforderungen: eingebettetes etcd mit --cluster-init, oder externe PostgreSQL-Datenbank über Kine.

# HA-Setup mit eingebettetem etcd (3 Server-Nodes)
# Erster Node:
curl -sfL https://get.k3s.io | K3S_TOKEN=SECRET sh -s - server \
  --cluster-init

# Weitere Server-Nodes:
curl -sfL https://get.k3s.io | K3S_TOKEN=SECRET sh -s - server \
  --server https://first-server:6443

Typisches Setup für ein mittelständisches Unternehmen:

• 3 Server-Nodes (Control Plane + etcd), je 4 vCPU / 8 GB RAM
• 3–10 Agent-Nodes je nach Workload
• Longhorn oder NFS-CSI für persistente Volumes
• MetalLB oder kube-vip als Load-Balancer (ersetzt Klipper-lb für Produktionsumgebungen)
• Traefik (mitgeliefert) oder nginx-ingress
• ArgoCD oder Flux für GitOps-Deployments
• Cert-Manager für TLS-Zertifikate (Let’s Encrypt oder internes CA)

k3s und Proxmox

Proxmox VE ist der am weitesten verbreitete Open-Source-Hypervisor für On-Premise-Setups — Homelab, Mittelstand und kleinere Rechenzentren. k3s und Proxmox passen gut zusammen, aber die Wahl des Virtualisierungsansatzes bestimmt die Erfahrung.

VMs vs. LXC-Container

VMs (empfohlen für Produktion): QEMU-VMs unter Proxmox sind die sauberste Variante. Jeder k3s-Node läuft in einer vollständigen virtuellen Maschine mit eigenem Kernel. Alle k3s-Features funktionieren ohne Konfigurationstricks. VirtIO-Treiber sorgen für gute Netzwerk- und Disk-Performance.

Empfohlenes Basis-Image: Ubuntu 22.04 LTS oder Debian 12 als Cloud-Init-Template. Ein einmal eingerichtetes Template lässt sich in Sekunden klonen.

# Cloud-Init-Template erstellen (einmalig auf Proxmox-Host)
qm create 9000 --name ubuntu-2204-template --memory 2048 --cores 2 \
  --net0 virtio,bridge=vmbr0
qm importdisk 9000 ubuntu-22.04-server-cloudimg-amd64.img local-lvm
qm set 9000 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-9000-disk-0
qm set 9000 --ide2 local-lvm:cloudinit --boot c --bootdisk scsi0
qm set 9000 --serial0 socket --vga serial0
qm set 9000 --agent enabled=1
qm template 9000

# VM aus Template klonen
qm clone 9000 101 --name k3s-server-1 --full
qm set 101 --ipconfig0 ip=192.168.1.101/24,gw=192.168.1.1
qm set 101 --sshkeys ~/.ssh/authorized_keys
qm resize 101 scsi0 +20G
qm start 101

LXC-Container (für Homelab, nicht Produktion): Technisch möglich, aber mit Aufwand verbunden. Containerd in k3s braucht privilegierten Modus oder spezifische AppArmor- und cgroup-Konfiguration. Folgende LXC-Optionen müssen in der Proxmox-Konfiguration gesetzt sein:

features: keyctl=1,nesting=1
lxc.apparmor.profile: unconfined
lxc.cgroup.devices.allow: a
lxc.cap.drop:

Für Produktionsumgebungen ist der LXC-Weg nicht empfohlen — zu viele Ausnahmen vom Standard-Sicherheitsmodell. Für Homelab-Experimente funktioniert er, wenn man weiß, was man tut.

Netzwerk in Proxmox

k3s nutzt Flannel als Standard-CNI mit VXLAN-Encapsulation. Das funktioniert in Proxmox-VMs ohne Anpassungen. Für Setups mit mehreren Proxmox-Hosts empfiehlt sich SDN (Software Defined Networking) in Proxmox, um ein konsistentes Layer-2-Netzwerk über Hosts hinweg zu schaffen.

Für Load-Balancing ohne Cloud-Provider gibt es zwei bewährte Optionen:

MetalLB: Weist Services vom Typ LoadBalancer echte IPs aus einem konfigurierten Pool zu. Einfach einzurichten, weit verbreitet.

kube-vip: Läuft als DaemonSet, bietet sowohl HA für den Control-Plane (virtuelle IP für den API-Server) als auch Load-Balancing für Services. Besonders sinnvoll, wenn k3s-HA gewünscht ist und Proxmox-VMs auf mehreren physischen Hosts verteilt laufen.

# kube-vip als HA-Control-Plane-VIP
# VIP: 192.168.1.100 – diese IP antwortet auf kubectl-Anfragen
# unabhängig davon, welcher Server-Node gerade der Leader ist

Storage in Proxmox

Für persistente Volumes gibt es in Proxmox-Umgebungen mehrere Optionen:

Longhorn: Läuft vollständig im Cluster, repliziert Volumes über Nodes, hat eine eigene UI. Guter Einstieg für Homelab und kleine Produktionsumgebungen. Braucht SSDs für akzeptable Performance — keine SD-Karten.

NFS-CSI: Proxmox kann NFS-Shares bereitstellen (oder ein dedizierter NAS), der k3s-NFS-CSI-Treiber macht daraus dynamisch provisionierbare PersistentVolumes. Einfachste Option wenn bereits ein NAS vorhanden ist.

Proxmox CSI Plugin: Es gibt einen Kubernetes-CSI-Treiber, der direkt Proxmox-Volumes (LVM, ZFS, Ceph) als PersistentVolumes bereitstellt. Für Setups mit Proxmox-Ceph-Backend ist das die performanteste Option.

Typisches Proxmox + k3s HA-Setup

Proxmox-Cluster (3 physische Hosts)
├── Host 1: k3s-server-1 (4 vCPU, 8 GB RAM) + kube-vip VIP: 192.168.1.100
├── Host 2: k3s-server-2 (4 vCPU, 8 GB RAM)
├── Host 3: k3s-server-3 (4 vCPU, 8 GB RAM)
├── Host 1+2+3: k3s-agent-1/2/3 (8 vCPU, 16 GB RAM je)
└── NAS (NFS) oder Longhorn für Persistent Volumes

Wenn ein Proxmox-Host ausfällt, übernehmen die verbleibenden etcd-Nodes die Kontrolle, kube-vip verlagert die VIP automatisch, laufende Pods auf dem ausgefallenen Host werden nach kurzer Zeit auf anderen Nodes neu gestartet.

Wann k3s nicht die richtige Wahl ist

k3s ist kein Ersatz für upstream Kubernetes in allen Szenarien:

Sehr große Cluster. SQLite skaliert nicht über einige Dutzend Nodes. Eingebettetes etcd ist stabil, aber für Cluster mit hunderten Nodes und hohem API-Server-Traffic ist ein dediziertes etcd-Cluster und upstream Kubernetes die bessere Wahl.

Strikte Cloud-Native-Compliance. Einige Enterprise-Kubernetes-Distributionen (OpenShift, Tanzu) bieten Zertifizierungen und Support-Verträge, die k3s nicht hat. Für Unternehmen mit strengen Compliance-Anforderungen kann das relevant sein.

Komplexe Netzwerk-Anforderungen. Wenn Cilium, Calico mit BGP oder andere fortgeschrittene CNIs benötigt werden, lässt sich Flannel deaktivieren und ersetzen — aber das erhöht die Komplexität. In diesem Fall ist der Unterschied zu upstream Kubernetes kleiner.

Einordnung

k3s ist seit 2018 in Entwicklung, CNCF-konform und in mehr Produktionsumgebungen im Einsatz als viele neuere Kubernetes-Distributionen. 33k GitHub-Stars für ein Infrastruktur-Tool sind ein deutliches Signal: Das Tool löst ein echtes Problem.

Der entscheidende Vorteil ist nicht die kleinere Binärgröße — es ist die Reduzierung der operativen Komplexität. Ein einzelner curl | sh-Befehl pro Node, kein externes etcd, kein Paket-Manager, kein Expertenwissen in Kubernetes-Administration erforderlich. Auf Proxmox, auf dem Raspberry Pi, auf dem alten Server im Keller: k3s läuft, wo Kubernetes sonst zu aufwändig wäre.

Für Unternehmen ohne dediziertes Kubernetes-Team, für Entwickler die Kubernetes produktiv einsetzen wollen ohne Cloud-Kosten, und für Edge-Deployments ohne zuverlässige Internetverbindung ist k3s die direkteste Antwort auf die Frage: Wie komme ich schnell zu einem echten, konformen Kubernetes-Cluster? Wer den Cluster dann in Produktion betreibt, braucht früher oder später auch ein Monitoring-Setup mit Prometheus und Grafana.