Constantin, Kubernetes & Platform Engineering bei Pexon Consulting | 12 Min. Lesezeit | 29.08.2026
TL;DR
k3s vs k8s vs Rancher: k3s ist die Lightweight-Distribution für Edge und kleine Cluster, vanilla bzw. managed k8s der Production-Standard, Rancher die Multi-Cluster-Schicht darüber. Pexon Consulting (80 MA, Azure/AWS/GCP) empfiehlt managed k8s für die meisten Mittelstands-Setups, k3s an der Werks-Edge, Rancher erst ab mehreren Clustern. Architektur-Sprint 18-32k EUR.
Warum die Distributionsfrage 2026 wieder hochkommt
Die Frage klingt technisch, entscheidet aber über Betriebsmodell und Budget. In Fertigung und IIoT taucht sie fast immer auf, sobald jemand ein Edge-Image mit k3s sieht und fragt: „Ist das echtes Kubernetes oder ein Spielzeug?“
Die ehrliche Antwort: k3s ist eine vollwertige, CNCF-zertifizierte Distribution. Vanilla k8s (bzw. managed AKS/EKS/GKE) bleibt die Referenz für Production. Für den bestehenden AKS-Cluster ist der AKS Cluster-Check der nächste Schritt, kein Umzug ins fremde RZ. Rancher ist keine Distribution, sondern die Schicht, mit der Sie mehrere Cluster zentral steuern. Wer das vermischt, baut entweder Over-Engineering (Rancher für einen Cluster) oder Edge-Risiken (vanilla Control Plane auf schwacher Hardware).
Stand August 2026 liefert k3s mit v1.36.4+k3s1 (Release 27.08.2026) Upstream-Kubernetes v1.36.4. Das Repo liegt bei rund 33.8k GitHub-Stars (Abruf 29.08.2026). Genau diese Frische brauchen Sie in der Evaluation: nicht „k3s irgendwie“, sondern konkrete Version, Breaking Changes und Passung zum Betriebsmodell.
Gleichzeitig steigt der Druck aus der Fläche. Mehr Werke wollen lokale Verarbeitung (Latenz, Bandbreite, Datenresidenz), während die IT zentral steuern will. Genau dazwischen sitzt die k3s-vs-k8s-Entscheidung. Rancher kommt erst dazu, wenn die Flotte größer wird als das, was ein Team noch in Provider-Consoles im Kopf behält.
Mehr zur Einordnung der Plattform-Entscheidung im Kubernetes-Beratung-Überblick.
Was k3s, k8s und Rancher wirklich sind
Drei Begriffe, drei Rollen. Ohne diese Trennung landet jede Vergleichstabelle im Nebel.
k3s packt eine konforme Kubernetes-Distribution in eine Binary unter 100 MB (je nach Build/Asset). Single-Server mit SQLite, HA mit etcd oder externem Datastore, Traefik und Local Path Provisioner out of the box. Manifeste, die auf AKS laufen, laufen in der Regel auch auf k3s. Das ist kein Fork mit eigener API-Welt.
Vanilla k8s ist die Upstream-Referenz. In der Praxis meinen die meisten Mittelständler damit aber managed Kubernetes (AKS, EKS, GKE) oder eine gehärtete Self-Hosted-Variante. Der Resource- und Ops-Overhead ist höher, dafür HA, Add-on-Ökosystem und Hyperscaler-Integrationen Standard.
Rancher (SUSE) importiert und provisioniert Cluster: k3s, RKE2, AKS, EKS, GKE. UI, RBAC, Fleet-GitOps, Monitoring über die Flotte. Ohne Rancher haben Sie drei Cluster und drei Betriebswelten. Mit Rancher eine Management-Plane, die selbst betrieben und gepatcht werden muss.
Unsere klare Position: Wer „Rancher statt Kubernetes“ sagt, hat die Architektur falsch verstanden. Rancher sitzt darüber. Wer „k3s statt Kubernetes“ sagt, liegt ebenfalls falsch: k3s ist Kubernetes, nur anders verpackt.
RKE2 gehört in denselben SUSE/Rancher-Kosmos, ist aber die gehärtete Variante (CIS, oft FIPS-nah) für Datacenter und regulierte On-Prem-Workloads. Kurz: k3s für Edge und leichte Knoten, RKE2 wenn Self-Hosted härter und security-first sein soll, managed k8s wenn Sie Control Plane und Upgrade-Pfad abgeben wollen.
Ein häufiger Einstieg ist k3s auf günstiger Infrastruktur, etwa auf Hetzner Cloud, wo es kein eigenes Managed Kubernetes gibt. Wie sich dieser selbst betriebene Weg gegen einen gemanagten Cluster rechnet, zeigt der Vergleich Hetzner vs STACKIT Kubernetes auf unserem Vergleichsportal kubernetes-anbieter.de, inklusive Betriebsaufwand und BSI C5.
k3s im Detail: Edge ohne Spielzeug-Image
k3s ist die richtige Antwort, wenn RAM, Bandbreite und Ops-Zeit knapp sind. Wir sehen das in Werken: OEE-Pipelines, OPC-UA-Aggregation, lokale Inferenz-Pods. Dort ist ein AKS-ähnlicher Control-Plane-Footprint oft Geldverschwendung.
Stärken, die in der Praxis zählen. Single-Binary-Install in Minuten. Embedded SQLite für Single-Server. ARM64/ARMv7. Laut Doku-Richtwerten halten HA-Setups mit drei Servern (je 4 vCPU / 8 GB) grob um die 1.200 Agents. Traefik und containerd sind eingebettet. Production-Track-Record seit Jahren, nicht erst seit dem Marketing-Slide 2024.
Schwächen, die Teams unterschätzen. HA ist nicht „Checkbox an“. Multi-Server braucht etcd oder externen Datastore und Disziplin bei Upgrades. Das Add-on-Ökosystem ist kleiner als bei managed k8s. Und der Traefik-Chart-Bump auf v40.x in v1.36.4+k3s1 ändert den Provider-Namen von kubernetesIngressNginx zu kubernetesIngressNGINX. Wer ingress-nginx-Migrationen im Helm-Chart hat, muss das vor dem Cluster-Upgrade prüfen. Genau solche Details trennen einen stabilen Edge-Rollout von einem Wochenend-Ausfall.
Quick-Start (Single-Server, nur Lab oder isolierte Edge-Box):
# k3s Server installieren (Stand: v1.36.4+k3s1, Aug 2026)
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION="v1.36.4+k3s1" sh -
# Node und API prüfen
sudo k3s kubectl get nodes
sudo k3s kubectl get pods -AAir-gap und OT-Netze ändern das Bild. Dann brauchen Sie vorab Image-Tarballs, eine Update-Strategie ohne offenen GitHub-Pull und klare Regeln, wer die Binary auf den Shopfloor bringt. k3s kann das. Es verlangt aber Prozess, nicht nur ein Install-Skript.
Sweet-Spot. Edge-Cluster in Werken, Dev/CI-Cluster, kleine Production mit wenigen Nodes und einem klaren Use-Case. Wir raten davon ab, k3s als „billiges AKS“ für 40 Microservices im HQ zu verkaufen. Das funktioniert technisch eine Weile und wird dann teuer im Betrieb: Backup der SQLite/etcd-Lage, Certificate-Rotation, Observability und Incident-Response ohne Hyperscaler-Knopf.
Zur Architektur mit Edge und Cloud-Datenplattform passt oft dasselbe Muster: lokale Aggregation am Standort, zentrale Auswertung in der Datenplattform.
Vanilla und managed k8s: wo 75 Prozent unserer Setups landen
Managed Kubernetes bleibt für die meisten Mittelstands-Production-Workloads unsere Empfehlung. Nicht weil k3s schlecht wäre, sondern weil SLA, Node-Pools, Identity-Anbindung und Upgrade-Pfade bei AKS/EKS/GKE den Ops-Aufwand senken.
Stärken. Größte Community und Add-on-Landschaft. HA und Control-Plane-Patching beim Provider. Lange Track-Records in regulierten Branchen. Klare Trennung von Plattform und Workload, wenn das Team Platform Engineering ernst nimmt.
Schwächen. Höherer Footprint und Kosten als k3s an der Edge. Self-Hosting von vanilla k8s ohne Managed-Service ist im Mittelstand selten wirtschaftlich: etcd, Certificate-Rotation, Upgrade-Fenster, Network-Policy, Ingress, Storage. Das ist kein Wochenendprojekt und auch kein „wir stellen zwei Juniors drauf“.
Hyperscaler-Wahl ist eine eigene Entscheidung. Kurz: In Microsoft-lastigen Landschaften (Entra ID, Azure Landing Zone, Arc) landen wir meist bei AKS. Multi-Cloud oder AWS-First ändern die Matrix. Den detaillierten Hyperscaler-Vergleich finden Sie unter den verwandten Themen.
Sweet-Spot. Production ab drei Nodes, mehrere Use-Cases auf einem Cluster, Teams die GitOps und Policy brauchen. Rund 75 Prozent der Pexon-Kubernetes-Setups landen hier. k3s bleibt daneben als Spoke an Standorten, nicht als Ersatz für den zentralen Production-Cluster.
Was Teams oft unterschätzen: Upgrade-Disziplin. Managed nimmt Ihnen die Control Plane ab, nicht die Workload-Kompatibilität. Deprecated APIs, PodSecurity, Ingress-Controller-Versionen und Storage-Classes bleiben Ihre Hausaufgabe. Wer das ignoriert, zahlt später in Notfall-Wochenenden.
Rancher: sinnvoll ab Flotte, Overkill für einen Cluster
Rancher lohnt sich, wenn die Flotte größer wird als das, was ein Team noch in drei Provider-Consoles im Kopf behält. Typisch: HQ auf AKS, drei Werke auf k3s, ein Legacy-RKE2, einheitliches RBAC und Audit.
Stärken. Distribution-agnostisches Multi-Cluster-Management. Fleet für GitOps über die Flotte. Marketplace und Monitoring-Stack. Ein Login, eine Policy-Sicht, weniger „wer hat in welchem Cluster die RoleBinding gesetzt?“.
Schwächen. Rancher selbst ist eine Plattform mit Upgrade-, Backup- und HA-Bedarf. Resource-Overhead für die Management-Komponenten liegt oft bei 1-2 GB zusätzlich. Und die kommerzielle Seite hat sich 2025/2026 verschärft: SUSE Rancher Prime ist von einfachen Per-Node-Modellen in Richtung CPU/vCPU-Lizenzierung gewandert. Community-Berichte sprechen von spürbaren Kostensteigerungen; Listenpreise sind quote-basiert. Open-Source-Rancher bleibt kostenlos, bindet aber Engineering-Kapazität.
Unsere Empfehlung: Rancher erst ab etwa acht Clustern oder wenn Multi-Distribution und konsolidierter Audit-Trail Pflicht sind. Bei einem oder zwei Clustern ist Rancher Over-Engineering. Dann reichen Provider-Console plus GitOps (z. B. Argo CD) und ein sauberes Identity-Setup.
Wenn Sie Rancher evaluieren, rechnen Sie die Plane mit: Hochverfügbarkeit der Management-Cluster, Backup der Rancher-DB, Upgrade-Fenster und wer 24/7 reagiert, wenn die UI weg ist und die Spokes weiterlaufen. Viele Projekte unterschätzen genau diese zweite Plattform.
Entscheidungs-Matrix und grobe Kostenlage
k3s wählen, wenn Edge/IIoT, niedriger Footprint Pflicht und der Cluster einen engen Use-Case hat.
Managed k8s wählen, wenn Production mit mehreren Workloads, Standard-Enterprise-Anforderungen und Sie Ops-Last abgeben wollen. Das ist unser Default.
Rancher wählen, wenn viele Cluster, gemischte Distributionen und zentrale Governance Pflicht sind.
TCO hängt stärker an Menschen und Incidents als an der Binary. Ein „kostenloses“ Self-Hosted-Setup mit zwei FTE Patch-Nachtarbeit ist teurer als AKS plus ein kleines Platform-Team. Zahlen zu Node- und Cluster-Kosten finden Sie in der Kubernetes-Cluster-Kostenrechnung 2026.
Für Platform-Engineering und Golden Paths verweisen wir auf die Platform-Engineering-Beratung.
Typisches Hybrid-Muster aus Industrie-Projekten
Was wir bei multiplen Werken oft bauen: schlanke GitOps- oder Rancher-Management-Plane auf AKS im HQ. Spoke-Cluster mit k3s an den Standorten (OEE, Vision, lokale Buffer). Workloads per GitOps, Secrets und Identity zentral, Datenaggregation Richtung Lakehouse oder Fabric.
Das Muster skaliert, ohne jedes Werk zu einem Mini-Hyperscaler zu machen. Es verlangt aber Netzwerk-Design, Offline-Toleranz und klare Besitzgrenzen zwischen OT und IT. Genau dort scheitern „nur mal k3s flashen“-Piloten. Ohne Update-Kanal, ohne Observability und ohne klare Ownership wird aus dem Edge-Cluster in sechs Monaten ein Schatten-IT-Problem.
OpenShift ist übrigens eine eigene Distribution mit Red-Hat-Ökosystem, kein Drop-in für Rancher. OpenShift ersetzt eher die Distro-Entscheidung, Rancher die Flotten-Entscheidung.
Worauf Sie vor der Entscheidung achten sollten
- Workload und Standort zuerst. Edge mit 2 GB RAM ist kein AKS-Thema. HQ mit 40 Services und Compliance-Audit ist kein Single-Node-k3s-Thema.
- Betriebsmodell vor Binary. Wer patched Control Plane und Nodes? In welchem Fenster? Wer ist on-call?
- Flottengröße ehrlich zählen. Drei Cluster in einer Cloud brauchen oft kein Rancher. Zwölf Standorte mit gemischter Distro schon eher.
- Upgrade-Pfad testen. Gerade k3s-Releases bringen eingebettete Chart-Änderungen mit. Staging-Cluster Pflicht.
- Kosten über 36 Monate. Lizenz, Cloud, FTE und Incident-Kosten addieren, nicht nur die Install-Demo.
Wenn Sie diese fünf Punkte schriftlich beantworten können, ist die Distributionswahl meist in einer Stunde entschieden. Wenn nicht, fehlt Architektur, nicht ein weiteres Feature-Vergleichs-PDF.
Häufig gestellte Fragen
Ist k3s wirklich produktionsreif?
Ja. Wir betreiben k3s bei Industrie-Kunden an 12+ Werks-Standorten produktiv. Für Edge-Workloads klar im Vorteil. Für große Multi-Tenant-HQ-Cluster bleibt managed k8s die bessere Default-Wahl.
Was bei sehr großen k3s-Clustern (über 100 Nodes)?
Technisch möglich, aber nicht der Sweet-Spot. Ab dieser Größe und bei gemischten Workloads wechseln wir auf managed oder gehärtetes vanilla/RKE2. Details stehen im Betriebsmodell-Vergleich Managed vs Self-Hosted.
Können wir Rancher auf AKS aufsetzen?
Ja, gängiges Pattern: Management-Plane auf AKS, Spoke-k3s in den Werken. Pragmatisch, wenn viele Standorte und ein gemeinsames RBAC-Modell nötig sind.
Was kostet Rancher Prime 2026?
Open-Source-Rancher: 0 EUR Lizenz, dafür Engineering. Rancher Prime ist quote-basiert; nach dem Wechsel zu CPU/vCPU-Modellen 2025 berichten Kunden teils deutliche Kostensteigerungen gegenüber alten Per-Node-Verträgen. Vor Kauf immer Angebot einholen, nicht mit 2023er Preisen planen.
Wie verhält sich k3s vs k8s gegenüber OpenShift?
OpenShift ist eine opinionated Distribution mit Support und eigenem Stack. k3s bleibt upstream-nah und leicht. Rancher managed verschiedene Distros inklusive k3s. OpenShift ersetzt eher die Distro-Entscheidung, Rancher die Flotten-Entscheidung.
Nächster Schritt
Wenn Sie zwischen k3s, managed k8s und Rancher entscheiden: 30-Minuten-Call. Wir skizzieren Topologie, Footprint und Sprint-Scope.
Verwandte Themen
→Managed Kubernetes vs Self-Hosted: Betriebsmodell-Entscheidung
→AKS vs EKS vs GKE im Hyperscaler-Vergleich
→Kubernetes vs OpenShift: Lohnt sich Red Hat?
