Kubernetes auf Proxmox betreiben lassen: Talos, k3s und RKE2 werden passend zum Betriebsmodell ausgewählt.
Kubernetes produktiv betreiben lassen? WZ-IT plant, baut und betreibt Kubernetes-Cluster auf Proxmox, Bare Metal und europäischer Infrastruktur - unabhängig von der Distribution, mit klarem Betriebs-Scope. Managed Kubernetes ansehen
Wer Kubernetes selbst betreiben will, installiert nicht „Kubernetes", sondern eine Distribution. Drei Optionen dominieren die Diskussion um souveräne, self-hosted Cluster: k3s, RKE2 und Talos Linux. Sie lösen dasselbe Ziel auf grundverschiedene Weise - von „leichtgewichtig und vertraut" bis „unveränderliches Betriebssystem ohne SSH". Dieser Vergleich ordnet die drei ein und beantwortet die eigentliche Frage: welche zu welchem Fall passt. Stand Oktober 2026.
Inhaltsverzeichnis
- Drei Wege zu Kubernetes
- k3s: der leichtgewichtige Einstieg
- RKE2: gehärtet für regulierte Umgebungen
- Talos Linux: das Kubernetes-Betriebssystem
- Die drei im Vergleich
- Welche Distribution für welchen Fall
Drei Wege zu Kubernetes
Der entscheidende Unterschied liegt nicht in Feature-Listen, sondern im Betriebsmodell. k3s und RKE2 sind Distributionen, die auf einem herkömmlichen Linux (Ubuntu, Debian, RHEL, SLES) laufen - Sie behalten Ihr gewohntes Betriebssystem, den SSH-Zugang und den Paketmanager. Talos Linux geht den anderen Weg: Es ersetzt das Betriebssystem durch eine minimale, unveränderliche Appliance, die ausschließlich über eine API verwaltet wird.
Gemeinsam ist allen dreien, dass sie upstream-Kubernetes ausliefern und CNCF-konform sind. Ihre Manifeste und Helm-Charts laufen also überall gleich - der Unterschied liegt darin, wie der Cluster darunter gebaut, gehärtet und betrieben wird. Genau das bestimmt Aufwand, Angriffsfläche und Compliance-Fähigkeit.
k3s: der leichtgewichtige Einstieg
k3s ist die schlanke Distribution von SUSE/Rancher: ein einziges Binary, geringer Ressourcenbedarf, in Minuten installiert. Das macht es zur beliebten Wahl für Edge-Standorte, IoT-Gateways, ARM-Hardware und kleine Cluster.
Der wichtigste Punkt für den produktiven Einsatz steckt im Datastore. Der Standard von k3s ist SQLite - und das funktioniert laut k3s-Dokumentation ausschließlich auf einem einzelnen Server: „SQLite cannot be used on clusters with multiple servers." Für einen hochverfügbaren Cluster muss man auf embedded etcd umstellen (automatisch aktiv, sobald k3s als etcd-Cluster initialisiert wird) oder eine externe Datenbank wie PostgreSQL, MySQL oder MariaDB anbinden.
Das ist die häufigste k3s-Falle: Ein mit Default-Einstellungen aufgesetzter „Produktions"-Cluster hat mit SQLite einen Single Point of Failure. Wer das von Anfang an berücksichtigt, bekommt mit k3s eine ausgezeichnete, sparsame Distribution - besonders dort, wo Ressourcen knapp sind.
RKE2: gehärtet für regulierte Umgebungen
RKE2 ist SUSE/Ranchers „enterprise-ready" Distribution mit Fokus auf Sicherheit und Compliance. Sie läuft ebenfalls auf einem herkömmlichen Linux, bringt aber ab Werk mit, was regulierte Umgebungen fordern (RKE2-Dokumentation):
- CIS Kubernetes Benchmark - Defaults und Optionen, mit denen ein Cluster den CIS Benchmark v1.12 oder v1.11 „with minimal operator intervention" besteht.
- FIPS 140-2 - validierte Kryptografie, in vielen Behörden- und Finanz-Kontexten Pflicht.
- CVE-Scanning - die Komponenten werden im Build mit trivy auf Schwachstellen geprüft.
- containerd als Laufzeit, Control-Plane-Komponenten als statische Pods, etcd als Datastore.
RKE2 verbindet damit die Bedienbarkeit von k3s mit der Upstream-Nähe und Härtung, die Rechenzentren und regulierte Sektoren (öffentliche Hand, Finanz, Gesundheit) brauchen. Für den compliance-bewussten Mittelstand - ISO 27001, BSI-Vorgaben - ist RKE2 oft die pragmatischste Wahl, weil die Härtung nicht nachgerüstet, sondern voreingestellt ist. Der Hardening Guide dokumentiert die verbleibenden Schritte.
Talos Linux: das Kubernetes-Betriebssystem
Talos Linux von Sidero Labs ist kein Add-on auf Linux, sondern ein eigenes, für Kubernetes gebautes Betriebssystem. Es ist unveränderlich, minimal und API-verwaltet - und definiert sich vor allem über das, was es weglässt: keinen SSH-Daemon, keine Shell, kein Konsolen-Login, keinen Paketmanager. Der einzige Zugang läuft über apid als gegenseitig authentifizierte gRPC-API. Das Root-Dateisystem ist ein schreibgeschütztes SquashFS-Image; Upgrades schreiben ein neues Image auf die inaktive Partition und booten dorthin.
Der Effekt ist eine radikal reduzierte Angriffsfläche und ein durchgängig deklaratives Betriebsmodell: Ein Cluster wird über eine Konfigurationsdatei beschrieben, nicht über manuelle Eingriffe. Das passt hervorragend zu GitOps und zu Flotten aus vielen identischen Knoten, und Talos läuft sauber auf Proxmox und Bare Metal. Talos ist Kubernetes-zertifiziert und seit Jahren produktiv im Einsatz (Projekt auf GitHub).
Der Preis: Man muss das gewohnte SSH-Vorgehen aufgeben. Wer bei einer Störung reflexhaft auf den Host springt, findet dort keine Shell. Für Teams, die Automatisierung und minimale Angriffsfläche über Vertrautheit stellen, ist genau das der Vorteil.
Die Talos-Installation auf Proxmox führt von der Image Factory bis zum Cluster-Bootstrap.
Die drei im Vergleich
| Dimension | k3s | RKE2 | Talos Linux |
|---|---|---|---|
| Modell | Distribution auf Linux | Distribution auf Linux | Eigenes, immutables OS |
| Host-Zugang | SSH, Paketmanager | SSH, Paketmanager | Nur gRPC-API, kein SSH |
| Datastore | SQLite (Default), etcd/externe DB für HA | etcd | etcd |
| Härtung ab Werk | Schlank, manuell härten | CIS Benchmark, FIPS 140-2 | Minimale Angriffsfläche, immutable |
| Ressourcenbedarf | Sehr gering | Moderat | Gering |
| Sweet Spot | Edge, IoT, kleine Cluster | Regulierte, Compliance-lastige Umgebungen | Flotten, GitOps, Security-Maximum |
| Hersteller | SUSE/Rancher | SUSE/Rancher | Sidero Labs |
Welche Distribution für welchen Fall
Die ehrliche Kurzfassung: Für einen souveränen Produktions-Cluster läuft die Wahl meist auf RKE2 oder Talos hinaus - k3s ist der verlockende, aber oft falsche Default, wenn Härtung und Hochverfügbarkeit zählen.
- k3s, wenn Ressourcen knapp sind: Edge-Standorte, IoT-Gateways, ARM, Entwicklungs- und kleine Single-Purpose-Cluster. Wichtig: Für HA früh von SQLite auf etcd umstellen.
- RKE2, wenn Compliance zählt: regulierte Sektoren, ISO 27001, BSI-Vorgaben, und Teams, die ein herkömmliches, per SSH administrierbares Linux behalten und die CIS-/FIPS-Härtung ab Werk wollen.
- Talos, wenn Skalierung und Sicherheit führen: viele gleichartige Knoten, konsequentes GitOps, maximale Reduktion der Angriffsfläche - und die Bereitschaft, das SSH-Vorgehen gegen API-Betrieb zu tauschen.
Die Distribution ist eine frühe, prägende Entscheidung, weil sie Betriebsmodell und Härtung festlegt. Ob Kubernetes überhaupt der richtige Weg ist, klärt vorab Brauchen wir Kubernetes?; wie diese Distributionen auf souveräner Infrastruktur landen, zeigt Kubernetes auf Proxmox. Und wer einen bestehenden, fremden Cluster übernimmt, findet im Übernahme-Audit die Checkliste dafür.
