Kubernetes auf einem VPS mit k3s: wann es sich lohnt und wie es läuft

Kubernetes hat den Ruf, nur für große Umgebungen gemacht zu sein. k3s ist eine vollwertige, zertifizierte Kubernetes-Distribution, die als einzelne Datei kommt und auf einem VPS läuft. Die Frage ist nicht, ob es geht, sondern ob es dir etwas bringt, was Docker Compose nicht auch bringt.

Wann k3s sich lohnt und wann nicht#

Situation	Besser
Eine Anwendung mit Datenbank auf einem Server	Compose
Zehn Dienste, die einzeln aktualisiert werden, deklarativ im Git	k3s
Mehrere Server, Dienste sollen bei Ausfall umziehen	k3s
Du willst Kubernetes lernen oder dein Arbeitgeber nutzt es	k3s
Du willst möglichst wenig bewegliche Teile	Compose

Kubernetes bringt eigene Konzepte mit: Pods, Deployments, Services, Ingress, Volumes über StorageClasses. Wer sie nicht braucht, trägt die Komplexität ohne Gegenwert. Wer sie nutzt, bekommt einiges geschenkt: Rolling Updates, Neustart ungesunder Container (was Compose nicht kann), einheitliche Konfiguration über alle Dienste.

Was k3s anders macht#

Eine Datei statt vieler Komponenten; Server und Agent in einem Programm.
SQLite statt etcd für einen einzelnen Server. Für mehrere Server kann k3s ein eingebettetes etcd nutzen.
Mitgeliefert: Traefik als Ingress-Controller, ein Speicher-Provisioner für lokale Volumes (local-path), ein einfacher Load-Balancer für LoadBalancer-Dienste.

Das macht den Einstieg kurz. Was mitgeliefert wird, lässt sich bei der Installation abschalten, wenn du etwas anderes nutzen willst.

Die Installation#

Das offizielle Installationsskript lädt k3s herunter und richtet es als systemd-Dienst ein. Lies es vorher, wie jedes Skript, das du mit root-Rechten ausführst:

curl -sfL https://get.k3s.io -o k3s-install.sh
less k3s-install.sh
sh k3s-install.sh

Mit Optionen, hier ohne Traefik (weil du etwa einen eigenen Reverse-Proxy nutzt) und mit lesbarer Konfigurationsdatei für deinen Benutzer:

INSTALL_K3S_EXEC="--disable traefik --write-kubeconfig-mode 0640" sh k3s-install.sh

Prüfen:

systemctl status k3s
k3s kubectl get nodes
k3s kubectl get pods -A

Die Zugangsdatei für kubectl liegt unter /etc/rancher/k3s/k3s.yaml. Sie enthält Administrator-Zugangsdaten für den ganzen Cluster und gehört behandelt wie ein root-Passwort.

Ressourcen: was bleibt übrig#

k3s selbst braucht Arbeitsspeicher und etwas Rechenzeit, auch wenn noch keine Anwendung läuft. Wie viel, misst du am besten auf deinem Server:

free -m                                  # vor der Installation notieren
# … installieren …
free -m
k3s kubectl top node                     # funktioniert mit dem mitgelieferten metrics-server

Grenzen für jeden Container gehören in die Deployments (resources.requests und resources.limits), sonst kann ein einzelner Pod den Knoten in den Speichermangel treiben. Auf einem kleinen VPS ist das die häufigste Ursache für einen hängenden Cluster.

Die Firewall: was nicht offen sein darf#

Port 6443 gehört nicht ins Internet

Über 6443 spricht kubectl mit dem Cluster. Er ist zwar mit Zertifikaten geschützt, aber eine Verwaltungsschnittstelle, die offen im Internet steht, ist ein Angriffsziel, sobald eine Lücke bekannt wird. Zugriff über WireGuard oder einen SSH-Tunnel. Dasselbe gilt für 10250 (kubelet).

Von außen erreichbar sein müssen nur die Ports, über die deine Dienste ausgeliefert werden, meist 80 und 443 über den Ingress. Und: Wie Docker trägt auch k3s eigene Regeln in die Paketfilter des Kernels ein. Wer eigene Firewall-Regeln pflegt, prüft nach der Installation, ob sie noch greifen, siehe Firewall auf dem VPS.

Ein erster Dienst#

# whoami.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: whoami
spec:
  replicas: 1
  selector:
    matchLabels: { app: whoami }
  template:
    metadata:
      labels: { app: whoami }
    spec:
      containers:
        - name: whoami
          image: traefik/whoami
          ports: [{ containerPort: 80 }]
          resources:
            requests: { memory: "16Mi", cpu: "10m" }
            limits:   { memory: "64Mi" }
---
apiVersion: v1
kind: Service
metadata:
  name: whoami
spec:
  selector: { app: whoami }
  ports: [{ port: 80 }]

k3s kubectl apply -f whoami.yaml
k3s kubectl get pods,svc

Nach außen bringt ihn dann eine Ingress-Regel, mit dem mitgelieferten Traefik oder einem anderen Ingress-Controller.

Sichern#

Zwei Dinge gehören gesichert, und sie liegen an verschiedenen Orten:

Der Zustand des Clusters: bei einem einzelnen Server in /var/lib/rancher/k3s/server/. Besser noch: alle Manifeste liegen ohnehin in einem Git-Repository, dann ist der Cluster jederzeit neu aufbaubar.
Die Daten in den Volumes: beim local-path-Provisioner unter /var/lib/rancher/k3s/storage/. Sie gehören in die normale Sicherung, etwa mit Restic, am besten mit angehaltenen Datenbanken oder über Datenbank-Dumps.

Häufige Fragen#

Wie werde ich k3s wieder los?#

Das Installationsskript legt /usr/local/bin/k3s-uninstall.sh an. Es entfernt k3s mit allen Containern und Daten, also vorher sichern, was bleiben soll.

Wie aktualisiere ich k3s?#

Das Installationsskript erneut mit derselben Konfiguration ausführen, es installiert die aktuelle Version. Für mehrere Knoten gibt es einen Upgrade-Controller. Vor dem Sprung auf eine neue Kubernetes-Minor-Version die Release Notes lesen, weil Kubernetes veraltete Schnittstellen entfernt.

Kann ich Docker daneben weiterlaufen lassen?#

Technisch ja, k3s bringt seine eigene Container-Laufzeit (containerd) mit. Beide tragen aber Regeln in die Paketfilter ein, und die Fehlersuche wird mit zwei Systemen nicht einfacher.

Reicht ein kleiner VPS?#

Für Lernzwecke und eine Handvoll kleiner Dienste ja. Miss nach der Installation, wie viel Speicher übrig bleibt, und plane danach.

Kurz gesagt#

k3s ist echtes Kubernetes in einer Datei. Für einen einfachen Dienst ist Compose trotzdem besser.
Installationsskript vorher lesen; Traefik und anderes lässt sich abschalten.
resources.limits in jedem Deployment, sonst kippt der Knoten bei Speichermangel.
6443 und 10250 nie offen ins Internet.
Manifeste ins Git, Volume-Daten in die normale Sicherung.