k3s statt Kubernetes: Warum der leichtgewichtige Champion die Realität ändert
Du hast es versucht. Die kubeadmin init-Magie auf drei teuren AWS EC2-Instanzen, gefolgt von dem Moment, in dem das Monitoring zeigt, dass das leere Cluster bereits 4 GB RAM frisst. Wir haben alle diesen Schmerz empfunden. Der Weg zum „Cloud-native“ Operating System wird schnell zur Resourcenfalle, wenn du einfach nur ein paar Stateless-APIs und ein Nginx-Proxy hosten willst. Hier kommt k3s ins Spiel. Entwickelt von Rancher, nimmt k3s den kompletten Kubernetes-Standardspezifikationen-Kram, wirft aber alles raus, was für kleine bis mittlere Umgebungen nicht zwingend nötig ist – ohne dabei inkompatibel zu werden. Es ist kein abgespecktes Spielzeug, sondern eine vollständig zertifizierte Distribution.
Unter der Haube: Was macht k3s wirklich so klein?
Ein normales Kubernetes-Setup benötigt etliche externe Abhängigkeiten. Etcd als Schlüssel-Wert-Speicher, ein vollwertiger Container-Runtime wie Containerd oder CRI-O, sowie diverse Kernel-Module. Wenn du dir das mal auf einem Raspberry Pi oder einem kleinen VPS mit 2 GB RAM anlegen willst, läuft dir schnell die Luft aus. k3s packt die Kernkomponenten zusammen: Ein einzelnes Binary (oft unter 100 MB), ein eingebettetes SQLite-Datenbankbackend anstatt von etcd (im Single-Node-Modus) und eine stark optimierte Version von Containerd.
Wenn du die Standardinstallation startest, geschieht die Magie fast stumm. Du hast keine komplexen YAML-Manifeste mehr, um nur die API-Umgebung einzurichten. Der interne Netzwerk-Plugin (flannel) ist standardmäßig aktiviert, aber durch andere wie Calico austauschbar.
# Die berühmte One-Liner-Installation auf Debian/Ubuntu
curl -sfL https://get.k3s.io | sh -
Nach wenigen Sekunden läuft dein Control Plane inkl. Worker Node auf derselben Maschine. Das kubectl-Binary wird automatisch verlinkt, und über /etc/rancher/k3s/k3s.yaml greifst du nahtlos auf die Kubernetes-API zu. Du kannst sofort Helm-Charts puschen, genau wie im Enterprise-Cluster.
Meine persönliche Einschätzung: Diese Reduktion auf das Wesentliche ist genial. Ich sehe immer noch Admins, die Stunden damit verbringen, ein manuell zusammengenähtes K8s-Cluster zum Laufen zu bringen, während k3s diese Hürde komplett ausradieren würde. Es macht Kubernetes plötzlich wieder für den menschlichen Verstand begreifbar.
High Availability ohne Schmerzen
Der häufigste Einwand gegen k3s war früher: „Es ist nur für Development gedacht.“ Das stimmt heute nicht mehr. Wenn du ein Ausfallschutz-System brauchst, musst du in einer Produktionsumgebung mehrere Server einsetzen. Früher war es kompliziert, etcd hochverfügbar zu machen. Mit k3s funktioniert das über eine externe Datenbank (wie PostgreSQL oder MySQL) oder – was in der Praxis am verbreitetsten ist – über einen eingebetteten etcd-Modus, der über eine Ungeraden-Zahl von Servern repliziert wird.
Stell dir drei Nodes vor. Du installierst den ersten als Server und gibst ihm ein Token:
# Auf dem ersten Master:
export K3S_TOKEN='meinGeheimesToken'
curl -sfL https://get.k3s.io | sh -
# Auf den anderen beiden Masters exakt das Gleiche,
# plus die Adresse des ersten Masters als Argument:
curl -sfL https://get.k3s.io | sh -s - --server https://master1-ip:6443
Innerhalb von Minuten synchronisieren sich die Datenbanken. Falls ein Master ausfällt, übernimmt nahtlos ein anderer den Traffic über deinen Load-Balancer. Du kannst Workers danach ganz normal hinzufügen, indem du denselben Token nutzt.
Was viele unterschätzen: Der integrierte Load Balancer (servicelb). In echten Clustern brauchst du oft einen externen L7/L4 Balancer (z.B. MetalLB oder einen Hardware-F5). k3s bringt einen rudimentären, aber funktionierenden Balancer mit, der perfekt für HA-Setups geeignet ist, wenn du deine Services vom Internet aus erreichbar machen willst.
Meine persönliche Einschätzung: Die Tatsache, dass High Availability hier fast schon beiläufig mitsamt dem Network-Plugin geliefert wird, ist unschlagbar. Ich habe kürzlich eine komplette Microservices-Architektur eines mittelständischen Kunden auf genau diesem Setup migriert. Die Downtime bei Updates lag bei null Sekunden.
Sicherheitsaspekte und RBAC aus der Konsole
Sicherheitsbedenken sind bei jedem Cluster berechtigt. Da k3s auf echtem Kubernetes basiert, erbt es auch das komplexe Rollen-basierte Access-Control (RBAC). Standardmäßig laufen die Komponenten mit Root-Rechten, da sie tief ins Dateisystem eingreifen müssen. Doch die API selbst bleibt streng getrennt.
Um dich sicher anzumelden, wirst du nie mit root arbeiten. Stattdessen erstellst du Nutzerkonten, die über ServiceAccounts oder externe Authentifizierung angebunden werden. Ein einfaches Beispiel: Du möchtest einem Entwickler nur Lesezugriff auf sein eigenes Namespace gewähren.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: namespace: development name: pod-reader
rules:
- apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata: name: read-pods namespace: development
subjects:
- kind: User name: developer1 apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io
Mit kubectl apply -f rolebinding.yaml ist die Regel sofort aktiv. Versucht der Benutzer, etwas zu löschen, erhält er eine saubere Forbidden-Meldung. Ein weiteres wichtiges Feature ist die integrierte Secrets-Verschlüsselung. Während Secrets standardmäßig nur Base64-kodiert im Speicher liegen, kannst du k3s anweisen, sie direkt in der Embedded-Datenbank zu verschlüsseln, bevor sie physisch geschrieben werden. Das erfordert ein kleines Config-Snippet in /etc/rancher/k3s/config.yaml, bevor du den Dienst startest.
Meine persönliche Einschätzung: Viele vergessen, dass ein kleiner Cluster oft genauso exponiert ist wie ein großer. Die nativen K8s-Security-Features dürfen niemals ignoriert werden. Aber k3s erleichtert hier massiv das Testing von Policies, bevor man sie in riesigen Clustern implementiert, wo ein Fehler katastrophale Auswirkungen hätte.
Storage und Persistent Volumes im Kleinen
Eine der schwierigsten Fragen beim Self-Hosting lautet: Wo speichere ich persistente Daten? Im großen Rechenzentrum greift man zu Storage Area Networks (SAN) oder Cloud-Providern. Im Homelab oder kleinen Hosting-Setup muss der Knoten selbst oft den Speicher bereitstellen. k3s löst dieses Problem elegant durch die Unterstützung dynamischer Provisionierung mittels Local Path Provisioner.
Standardmäßig installiert k3s einen einfachen Provisioner, der Verzeichnisse direkt auf der Festplatte des Servers anlegt und als Volume bereitstellt. Erstellst du ein PersistentVolumeClaim (PVC), sucht Kubernetes nach einem passenden StorageClass-Eintrag und legt lokal einen Ordner an – meistens unter /var/lib/rancher/k3s/storage.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-storage
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
storageClassName: local-path
Nutzt du dies in einer Datenbank wie MariaDB, bleiben deine Daten auch nach einem Neustart des Pods erhalten. Für echte HA-Anforderungen mit mehreren Writers gleichzeitig reicht das lokale Filesystem natürlich nicht; dann muss man Systeme wie Longhorn (ebenfalls von Rancher) integrieren, was hervorragend mit k3s harmoniert.
Meine persönliche Einschätzung: Der Local Path Provisioner ist der stille Held. Er eliminiert den stressigen Schritt, NFS-Server manuell zu konfigurieren, nur um einen einfachen WordPress-Blog oder ein GitLab-Instance hochzufahren. Erst wenn du skalierst, stolperst du über seine Grenzen, aber für den Anfang ist er perfekt.
Häufige Fehler bei der k3s-Integration
Auch wenn k3s extrem benutzerfreundlich ist, gibt es Fallstricke, in die fast jeder Admin einmal hineintappt.
Erstens: Firewall-Konflikte. k3s öffnet standardmäßig Port 6443 (HTTPS API) und im HA-Modus noch weitere Ports für die Kommunikation zwischen den Servern (etcd Replication). Vergiss nicht, deine ufw oder firewalld Regeln anzupassen, sonst schlägt das Joining weiterer Nodes fehl, ohne dass dir die Logs sofort verraten, warum.
Zweitens: Ressourcen-Limits ignorieren. Weil das Setup so leicht ist, denken viele, sie könnten unbeschränkt Pods starten. Starte jeden Container mit sinnvollen requests und limits für CPU und Memory. Sonst kann ein schlecht konfigurierter Java-Pod deinen gesamten Node zum Absturz bringen, weil der Linux OOM-Killer zuschlägt, bevor Kubernetes reagiert.
Drittens: Backup-Vergessen. Nur weil deine Daten „in Kubernetes“ sind, heißt das nicht, sie sind gesichert. Im Single-Node-Modus liegt alles in einer einzigen SQLite-Datei (/var/lib/rancher/k3s/server/db/sqlite3/k3s.db). Ein tägliches cp dieser Datei in einen gesicherten Ordner reicht für viele Szenarien völlig aus, wird jedoch oft übersehen. Für HA-Setups solltest du ein Tool wie k3s-quick-start Skripte oder besser noch Velero nutzen.
Fazit: Dein nächster Schritt in die moderne Infrastruktur
k3s ist keine Nische mehr. Es hat sich als vollwertige Alternative für Edge Computing, CI/CD-Runner und kleine bis mittlere Produktivlandschaften etabliert. Die Lernkurve ist flach, die Dokumentation umfassend, und weil es 100% kompatibel mit der Kubernetes-API ist, verlierst du keine Zeit mit proprietären Workarounds.
Wenn du heute noch auf schweren Bare-Metal-VMs herkömmliches Docker oder statisches Hosting betreibst, ist jetzt der perfekte Zeitpunkt zum Wechsel. Nimm dir einen Abend, provisioniere zwei alte Laptops oder billige VPS-Instanzen, führe den obigen One-Liner aus und deploye deine erste Anwendung. Du wirst staunen, wie schnell sich die Architektur deiner Dienste modernisiert, wenn dasDeployment selbst keine operative Last mehr darstellt. Probier es aus – deine zukünftigen Backups und deine Schlafqualität werden es dir danken.
Top comments (0)