Was ist K3s?
K3s ist eine Kubernetes-Distribution, verpackt als eine Binärdatei unter 100 MB. Sie bleibt konform mit dem Upstream-Kubernetes und bündelt containerd, Flannel-Netzwerk, CoreDNS, Traefik als Ingress, einen Service-Load-Balancer, Local-Path-Speicher und einen Helm-Controller, die sich jeweils abschalten oder ersetzen lassen. Ein einzelner Server speichert den Clusterzustand standardmäßig in SQLite; drei oder mehr Server bilden einen hochverfügbaren Cluster auf eingebettetem etcd, und externes MySQL, MariaDB oder Postgres funktionieren ebenfalls.
K3s entstand bei Rancher Labs, wurde im Juni 2020 an die CNCF übergeben und wird von SUSE als CNCF-Sandbox-Projekt beschrieben, mit SUSE als wichtigem Mitwirkenden. Die Software steht unter Apache 2.0 und hat keine Bezahlversion; SUSE verkauft Support über sein Rancher-Prime-Abonnement, mit bis zu fünf Jahren Support pro Release.
Für GPU-Arbeit erkennt K3s beim Start die NVIDIA Container Runtime, trägt sie in seine containerd-Konfiguration ein und liefert eine passende RuntimeClass namens nvidia mit. Die Versionsnummern folgen dem Upstream-Kubernetes: v1.37.2+k3s1 und v1.36.6+k3s1 erschienen beide am 3. November 2026.
Lohnt sich K3s?
K3s ist der vernünftige Weg, Inferenz- und Agenten-Dienste unter Kubernetes zu stellen, wenn man ein paar Maschinen hat und kein Plattformteam. Weil es konformes Kubernetes ist, lassen sich Helm-Charts für Modellserver, das NVIDIA Device Plugin und die meisten Operatoren unverändert installieren, und die Doku verlangt für einen Server-Knoten nur 2 Kerne und 2 GB RAM, für einen Agenten 512 MB, jeweils ohne Workloads. Das Repo hat rund 34.400 GitHub-Sterne, und das Projekt will Patch-Releases innerhalb einer Woche nach Upstream liefern und neue Minor-Versionen innerhalb von 30 Tagen.
Die GPU-Unterstützung läuft größtenteils automatisch, mit einer bekannten Falle. Installiert man NVIDIAs Container-Runtime-Pakete auf dem Host und startet K3s neu, schreibt es die Runtime in containerd; Pods fordern dann nvidia.com/gpu an und setzen runtimeClassName: nvidia. Das NVIDIA Device Plugin erwartet jedoch nvidia als Standard-Runtime, und Nutzer berichten in einer langen GitHub-Diskussion zu K3s, dass das Plugin in einer Absturzschleife hängt, bis sie --default-runtime nvidia setzen oder K3s' Vorlage config.toml.tmpl anpassen. NVIDIAs GPU Operator funktioniert ebenfalls, aber sein Toolkit muss auf K3s' eigenen containerd-Socket und dessen Konfigurationspfade zeigen; die K3s-Doku behandelt das nicht, und NVIDIAs aktuelle Installationsanleitung führt K3s nicht auf.
Der Einzelknoten-Standard ist ein echter Kompromiss. SQLite auf einem Server hat kein Failover. Hochverfügbarkeit braucht drei oder mehr Server auf eingebettetem etcd, eine ungerade Zahl für das Quorum, und die Doku warnt, dass etcd für SD-Karten oder eMMC zu schreibintensiv ist, Edge-Geräte also eine SSD brauchen. Ein einzelner Server lässt sich später durch einen Neustart mit --cluster-init auf etcd umstellen. Der Flannel-VXLAN-Port 8472 gehört hinter eine Firewall, denn laut Doku öffnet er sonst das Clusternetz für jeden. GitHub führt drei Sicherheits-Advisories für das Projekt, zuletzt einen mittelschweren Path-Traversal-Fehler bei der Wiederherstellung von etcd-Snapshots, veröffentlicht im Juni 2026.
Auf einem GPU-Host mit Modellserver, Vektordatenbank und Agenten-API reicht meist Docker Compose: Es reserviert GPUs pro Dienst mit einem devices-Block und hinterlässt keine Control Plane, die gepatcht werden muss. K3s lohnt sich, sobald ein zweiter GPU-Host zum Verteilen dazukommt, Rolling Updates gefordert sind oder Dutzende Edge-Standorte aus Git verwaltet werden sollen, genau der Fall, für den SUSE Rancher Prime verkauft. Einen Preis für diesen Support nennt SUSE auf seiner K3s-Seite nicht.
Wo es sich lohnt
Ein zweiköpfiges ML-Team mit drei GPU-Servern
Modellserver und eine Agenten-API auf alle drei Maschinen verteilen, ohne Container von Hand zu platzieren
K3s mit dem curl-Skript auf jedem Host installieren, NVIDIAs Runtime-Pakete hinzufügen, die Server mit --default-runtime nvidia starten und Device Plugin sowie Modellserver über Helm deployen. Der Scheduler setzt Pods dorthin, wo GPUs frei sind; die Software kostet nichts, der eigentliche Aufwand ist, kubectl zu lernen und drei Knoten bei jedem Release zu patchen.
Ein IT-Leiter einer Einzelhandelskette mit 40 Filialen, die kleine Vision-Modelle auf Mini-PCs im Laden betreibt
Denselben Inferenz-Container in jeder Filiale betreiben und alle zentral aktualisieren
Jede Filiale betreibt K3s mit einem Knoten auf SQLite, was für K3s selbst 2 Kerne und 2 GB braucht. Rancher Prime ergänzt GitOps-Flottenverwaltung über Cluster hinweg und Herstellersupport, Preis auf Anfrage; ohne es trägt das Team Upgrades und Monitoring an jedem Standort selbst.
Ein Solo-Entwickler, der einen Agenten-Stack auf einer Workstation mit einer GPU selbst hostet
Entscheiden, ob Ollama, Qdrant und eine Agenten-API unter Kubernetes gehören
Docker Compose reserviert die GPU pro Dienst mit einem devices-Block und hat keine Control Plane. K3s bringt Neustarts nach Health Checks und Rolling Updates, kostet dafür aber eigenen Ressourcenbedarf und eine neue Werkzeugkette; auf einer Maschine reicht Compose meist, und K3s wird sinnvoll, wenn ein zweiter GPU-Host dazukommt.
Bevor du dich festlegst
- Einrichtung
- curl -sfL https://get.k3s.io | sh - installiert einen systemd- oder openrc-Dienst und schreibt eine kubeconfig nach /etc/rancher/k3s/k3s.yaml; Worker treten mit K3S_URL und dem Token aus /var/lib/rancher/k3s/server/node-token bei. Binärdateien für x86_64, armhf, arm64 und s390x.
- Integrationen
- Standard-Kubernetes-Werkzeuge (kubectl, Helm, CSI-Treiber, Cloud Controller Manager; die In-Tree-Speichertreiber und Cloud-Provider sind entfernt). NVIDIA, crun und mehrere WebAssembly-Runtimes werden automatisch erkannt; der GPU Operator braucht CONTAINERD_CONFIG und CONTAINERD_SOCKET auf K3s' Pfade gesetzt.
- Daten und Datenschutz
- Apache 2.0 ohne Bezahlversion. Der Clusterzustand liegt in SQLite, eingebettetem etcd oder einer externen Datenbank, die du selbst betreibst. Port 8472 (Flannel VXLAN) gehört nicht ins Internet. Drei Sicherheits-Advisories auf GitHub, das jüngste mittelschwer (Juni 2026).
- Kosten im großen Maßstab
- Die Software ist kostenlos. Die Doku dimensioniert einen Server mit 2 vCPU und 4 GB für bis zu 350 Agenten und mit 4 vCPU und 8 GB für bis zu 900; drei Server mit 4 vCPU und 8 GB schaffen etwa 1.200 Agenten. Die GPUs dominieren die Rechnung, und Support über Rancher Prime gibt es zum Preis auf Anfrage.
- Grenzen
- 78 offene Issues und Pull Requests. Der Rootless-Modus ist experimentell und nur für einen Knoten; Hochverfügbarkeit braucht eine ungerade Zahl von Servern; Installationen mit dem GPU Operator sind ein von der Community dokumentierter Weg, kein offizieller.
Was gut ist
- Konformes Kubernetes in einer Binärdatei unter 100 MB
- Erkennt die NVIDIA Container Runtime und liefert eine nvidia-RuntimeClass mit
- Server-Knoten braucht nur 2 Kerne und 2 GB RAM
- Bis zu fünf Jahre bezahlter Support über SUSE Rancher Prime
Was nicht
- NVIDIA Device Plugin braucht nvidia als Standard-Runtime
- GPU Operator braucht K3s-spezifische containerd-Pfade und ist hier nicht dokumentiert
- Standard mit einem Server auf SQLite hat kein Failover
- Mehr zu lernen und zu patchen als Docker Compose auf einem Host
Am besten für
Kleine Teams, die Inferenz- oder Agenten-Dienste auf einigen GPU-Maschinen oder vielen Edge-Standorten betreiben und Kubernetes ohne Plattformteam wollen.
Alternativen zu K3s
K3s: häufige Fragen
- Lohnt sich K3s?
- Kubernetes in der passenden Größe für eine Handvoll GPU-Rechner oder eine Flotte von Edge-Standorten, auch wenn Docker Compose auf einer einzelnen Maschine mit weniger Wartung auskommt. Wir bewerten es mit 4.4 von 5.
- Was kostet K3s?
- Kostenlos und Open Source unter Apache 2.0, ohne Bezahlversion. Kommerzieller Support kommt über SUSE Rancher Prime (bis zu fünf Jahre pro Release); Preise gibt es auf Anfrage.
- Welche Nachteile hat K3s?
- NVIDIA Device Plugin braucht nvidia als Standard-Runtime; GPU Operator braucht K3s-spezifische containerd-Pfade und ist hier nicht dokumentiert; Standard mit einem Server auf SQLite hat kein Failover; Mehr zu lernen und zu patchen als Docker Compose auf einem Host.
- Für wen eignet sich K3s?
- Kleine Teams, die Inferenz- oder Agenten-Dienste auf einigen GPU-Maschinen oder vielen Edge-Standorten betreiben und Kubernetes ohne Plattformteam wollen.
- Was kostet K3s für ein Team oder im Produktivbetrieb?
- Die Software ist kostenlos. Die Doku dimensioniert einen Server mit 2 vCPU und 4 GB für bis zu 350 Agenten und mit 4 vCPU und 8 GB für bis zu 900; drei Server mit 4 vCPU und 8 GB schaffen etwa 1.200 Agenten. Die GPUs dominieren die Rechnung, und Support über Rancher Prime gibt es zum Preis auf Anfrage.
- Ist K3s sicher für Firmendaten?
- Apache 2.0 ohne Bezahlversion. Der Clusterzustand liegt in SQLite, eingebettetem etcd oder einer externen Datenbank, die du selbst betreibst. Port 8472 (Flannel VXLAN) gehört nicht ins Internet. Drei Sicherheits-Advisories auf GitHub, das jüngste mittelschwer (Juni 2026).
- Was sind die besten Alternativen zu K3s?
- Die nächsten Alternativen, die wir getestet haben, sind Ollama, Mesh LLM und vLLM.
Antworten geprüft am 9. Nov. 2026.
Du entwickelst K3s? Zeig diese Bewertung auf deiner Website
