k3s auf einem VPS: Wann lohnt sich ein einzelner Node?

Was k3s ist und was Ihnen ein einzelner Node davon bietet

k3s ist eine vollständige Kubernetes-Distribution, die als einzelne Binärdatei paketiert ist. Wenn Sie sie auf einem einzelnen VPS ausführen, erhalten Sie die echte Kubernetes-API, ohne eine aus drei Maschinen bestehende Control Plane zu benötigen. Es handelt sich um eine zertifizierte Kubernetes-Distribution. Daher kann ein Manifest, das hier angewendet wird, später auch auf einem verwalteten Cluster angewendet werden. Die Installation besteht aus einem einzigen Befehl und dauert etwa eine Minute. Dafür steht weniger Arbeitsspeicher für Ihre Anwendungen zur Verfügung. Außerdem gibt es Fehlerfälle, die bei Docker Compose nicht auftreten.

SUSE entwickelt k3s für Edge-Standorte und kleine Installationen. Jede Abweichung vom Upstream-Kubernetes dient dazu, die Distribution kleiner zu machen. Der standardmäßige Datenspeicher ist SQLite hinter einem Shim namens kine und nicht etcd. Daher müssen Sie kein etcd-Quorum verwalten. containerd ist in die Binärdatei eingebettet und wird nicht separat installiert. Dieselbe Binärdatei bringt außerdem CoreDNS für die Cluster-DNS-Auflösung, Traefik als Ingress-Controller, ServiceLB (auch klipper-lb genannt) für LoadBalancer-Services ohne dahinterliegenden Cloud-Provider, den local-path-Provisioner für persistente Volumes, metrics-server und flannel für das Pod-Netzwerk mit. Alle diese Komponenten werden standardmäßig gestartet. Deshalb ist die weiter unten beschriebene Portkollision das häufigste erste Problem auf einem VPS, der bereits andere Aufgaben ausgeführt hat.

Wann sich ein einzelner k3s-Knoten lohnt

Verwenden Sie k3s, wenn Sie die Kubernetes-API benötigen: Sie lernen Kubernetes auf einer von Ihnen verwalteten Maschine, oder die gewünschte Software stellt ausschließlich ein Helm-Chart bereit. Auch die Portierbarkeit von Manifests ist relevant, weil sich ein Deployment, das Sie hier erstellen, unverändert in einen verwalteten Cluster übertragen lässt. Verwenden Sie Docker Compose, wenn Sie die Anwendungen selbst benötigen. Compose startet dieselben Container mit deutlich weniger Komponenten, und eine Compose-Datei auf einem VPS ist auch ein Jahr später leichter zu lesen als ein Verzeichnis voller Manifests.

Beachten Sie, was ein einzelner Knoten nicht bietet.

• Keine Hochverfügbarkeit. Beim Neustart des VPS werden alle Workloads angehalten. Kubernetes plant einen Pod auf einem anderen Knoten ein, aber es gibt keinen anderen Knoten.
• Kein Rolling Update, bei dem ein Dienst weiterläuft, es sei denn, die Anwendung unterstützt zwei Replikas auf derselben Maschine, die sich ein Volume teilen.
• Speicher, der an diese Maschine gebunden ist, aus dem im folgenden Abschnitt zu local-path beschriebenen Grund.
• Eine Control Plane, die unabhängig davon, ob Sie etwas deployen, etwa ein Gigabyte RAM benötigt.

Das macht k3s nicht zu einer schlechten Wahl. Es macht k3s jedoch zu einer schlechten Wahl aus dem Grund, den viele normalerweise nennen: Zuverlässigkeit. Wenn Sie tatsächlich mehrere Maschinen benötigen, um einen echten Cluster mit mehreren Knoten aufzubauen, steht diese Entscheidung an erster Stelle: Proxmox auf eigener Hardware im Vergleich zu einem gemieteten VPS legt fest, woher die Knoten kommen, bevor k3s festlegt, was darauf ausgeführt wird.

Was k3s an RAM und CPU benötigt, bevor Sie etwas bereitstellen

Das k3s-Projekt veröffentlicht gemessene Werte statt Schätzungen. Lesen Sie diese sorgfältig, denn der häufig zitierte Wert beschreibt nicht den Leerlaufverbrauch von k3s.

[
  {
    "label": "Server, sqlite datastore",
    "ram_mb": "1,596",
    "cpu_percent_of_one_core": 6
  },
  {
    "label": "Server, embedded etcd",
    "ram_mb": "1,606",
    "cpu_percent_of_one_core": 6
  },
  {
    "label": "Agent node only",
    "ram_mb": "275",
    "cpu_percent_of_one_core": 3
  }
]

Ein Serverknoten in diesem Test verwendete beim 95. Perzentil 1,596 MB RAM und etwa 6 Prozent eines CPU-Kerns. Das sind veröffentlichte Werte und keine Messungen aus dieser Anleitung. Der Test lief mit k3s v1.26.5, wobei alle mitgelieferten Komponenten sowie ein Monitoring-Stack aus Prometheus und Grafana aktiviert waren. Der Wert umfasst daher eine reale Arbeitslast und keinen leeren Cluster. Der Wechsel von sqlite zu eingebettetem etcd erhöhte den Wert auf 1,606 MB. Ein Agent-Knoten, auf dem kubelet und containerd ohne Control Plane laufen, verwendete 275 MB. Als dokumentiertes Minimum für einen Server gelten 2 Kerne und 2 GB RAM. Dieses Minimum deckt k3s und seine mitgelieferten Komponenten ab, bevor Sie Ihre Workloads bereitstellen.

Die praktische Schlussfolgerung: Auf einem VPS mit 2 GB lässt die Control Plane zusammen mit den gebündelten Add-ons nur sehr wenig Arbeitsspeicher übrig. Bei Speicherdruck beginnt kubelet zuerst damit, Pods zu evakuieren. 4 GB sind eine komfortable Untergrenze für einen Knoten mit einigen kleinen Diensten. Messen Sie Ihr eigenes System, statt sich auf veröffentlichte Werte zu verlassen, auch auf diesen.

free -h
sudo k3s kubectl top node
sudo k3s kubectl get pods -A

Führen Sie free -h vor der Installation aus und erneut, sobald jeder Pod in kube-system den Status Running hat. Die Differenz zeigt, wie viel die Control Plane auf Ihrer Hardware benötigt. k3s kubectl top node liefert in den ersten ein bis zwei Minuten nach der Installation error: Metrics API not available, weil metrics-server noch keine Daten erfasst hat. Das ist kein Fehler. Wenn Sie einen Rechner gleichzeitig für diesen Zweck und für andere Aufgaben dimensionieren, gilt die Berechnung aus RAM und CPU für einen VPS dimensionieren hier unverändert.

k3s auf einen Release-Stand festlegen, nicht auf latest

Die Quickstart-Zeile, die jeder kopiert, verwendet den Stand, auf den der Stable-Kanal an dem Tag zeigt, an dem Sie sie ausführen. Auf einem Rechner, den Sie dauerhaft betreiben möchten, sollten Sie die Version festlegen. k3s veröffentlicht für jede Kubernetes-Minor-Version einen eigenen Kanal. Daher folgt INSTALL_K3S_CHANNEL=v1.36 den Patch-Releases innerhalb von v1.36 und wechselt nicht ohne Ihr Zutun zu einer anderen Minor-Version. Im August 2026 zeigt der Stable-Kanal auf v1.36.3+k3s1.

Schreiben Sie zuerst die Konfigurationsdatei und führen Sie anschließend die Installation aus. k3s liest /etc/rancher/k3s/config.yaml beim Start ein. Daher gelten die darin enthaltenen Einstellungen sowohl für den ersten Start als auch für alle späteren Starts.

sudo mkdir -p /etc/rancher/k3s
sudo tee /etc/rancher/k3s/config.yaml >/dev/null <<'EOF'
tls-san:
  - k3s.example.com
EOF
curl -sfL https://get.k3s.io | INSTALL_K3S_CHANNEL=v1.36 sh -

Um statt eines Kanals einen exakt festgelegten Release zu verwenden, nutzen Sie INSTALL_K3S_VERSION=v1.36.3+k3s1. Das Pluszeichen ist Bestandteil des Tags. Prüfen Sie anschließend, ob der Dienst gestartet wurde.

k3s --version
sudo systemctl status k3s
sudo k3s kubectl get node
sudo k3s kubectl get pods -A

kubectl get node sollte innerhalb von etwa dreißig Sekunden einen Knoten mit dem STATUS Ready auflisten. Jeder Pod in kube-system sollte den Status Running oder Completed erreichen. Ein Knoten, der bei NotReady hängen bleibt, bedeutet in der Regel, dass die Container-Runtime nicht gestartet wurde. Lesen Sie daher sudo journalctl -u k3s -n 100 --no-pager. Bei einem ungewöhnlichen VPS-Image führen Sie sudo k3s check-config aus, bevor Sie etwas anderes untersuchen. Der Befehl meldet fehlende Kernel-Funktionen. Das liefert deutlich schneller eine Antwort, als Logs zu lesen.

Warum Port 80 bereits verwendet wird und worauf Sie zur Behebung verzichten müssen

Dieser Fehler tritt häufig auf einem VPS auf, auf dem bereits ein Dienst ausgeführt wurde. Die Installation ist erfolgreich. Traefik erhält jedoch nie eine Adresse, während die bereits laufende Website weiterhin funktioniert. Daher sieht zunächst nichts fehlerhaft aus, bis Sie versuchen, einen Ingress zu erreichen.

Der Mechanismus: Das mitgelieferte Traefik-Chart erstellt einen Service vom Typ LoadBalancer für die Ports 80 und 443. ServiceLB erfüllt diese Anforderung, indem es einen DaemonSet mit kleinen Pods erstellt. Deren Namen beginnen mit dem Präfix svclb-. Diese Pods reservieren die Portnummern auf jedem Node als hostPort. hostPort veröffentlicht den Container-Port direkt im Netzwerk-Namespace des Nodes, genau wie docker run -p 80:80. Wenn nginx, Caddy, Apache oder ein anderer Container Port 80 bereits verwendet, gibt der Kernel ihn nicht zweimal frei. Der Scheduler kann den Pod daher auf keinem Node platzieren.

sudo k3s kubectl -n kube-system get pods
sudo k3s kubectl -n kube-system get svc traefik
sudo ss -lntp '( sport = :80 or sport = :443 )'

Der svclb-Pod steht auf Pending, und der Service hat keine externe Adresse:

svclb-traefik-8f2c1a-r6k9x   0/2   Pending   0   3m
traefik   LoadBalancer   10.43.62.11   <pending>   80:31480/TCP,443:30219/TCP

Mit kubectl -n kube-system describe pod svclb-traefik-... wird die Ursache direkt angezeigt:

0/1 nodes are available: 1 node(s) didn't have free ports for the requested pod ports.

ss -lntp zeigt, welcher Prozess den Port verwendet. Es gibt mehrere Lösungen. Jede davon hat Nachteile.

Überlassen Sie die Ports k3s. Stoppen und deaktivieren Sie den vorhandenen Webserver. Überlassen Sie anschließend Traefik die Ports 80 und 443. Das ist die richtige Lösung, wenn der VPS ausschließlich als k3s-Server dienen soll und alle bisher bereitgestellten Dienste hinter einen Ingress verschoben werden.

Deaktivieren Sie ServiceLB und behalten Sie Ihren vorhandenen Proxy. Installieren Sie mit --disable=servicelb. Ein Service vom Typ LoadBalancer reserviert weiterhin einen NodePort. Traefik bleibt daher über einen hohen Port wie 31480 erreichbar, und nginx oder Caddy leitet Anfragen an 127.0.0.1:31480 weiter. Sie verzichten dabei auf die externe Adresse: Der Service meldet dauerhaft <pending>. Das sieht wie ein Fehler aus, ist hier aber eine bewusste Entscheidung.

Deaktivieren Sie Traefik und verwenden Sie Ihren eigenen Proxy. Installieren Sie mit --disable=traefik. Danach gibt es keinen Ingress-Controller. Ingress-Objekte haben daher keinerlei Wirkung: Sie bleiben in der API, ohne dass ein Controller sie überwacht. Das ist in Ordnung, wenn Sie den Datenverkehr von einem Host-Proxy an NodePorts weiterleiten. Es ist außerdem die ehrliche Entscheidung, wenn Sie bereits wissen, wie HTTP verarbeitet werden soll. Wenn Sie noch nicht entschieden haben, welcher Proxy vorgeschaltet werden soll, klären Sie die Auswahl zwischen nginx, Caddy und Traefik als Reverse Proxy, bevor Sie etwas deaktivieren.

Beide Flags gehören zum Installer oder in die Konfigurationsdatei:

tls-san:
  - k3s.example.com
disable:
  - traefik
  - servicelb

Sie können die Datei auch nach der Installation bearbeiten und anschließend sudo systemctl restart k3s ausführen. Das funktioniert, weil --disable mehr bewirkt, als eine Komponente nur während der Installation zu überspringen. Der Befehl löscht auch eine bereits bereitgestellte Komponente. Die Änderung wird daher in einem laufenden Cluster wirksam.

Wenn Sie Traefik behalten, aber die Konfiguration des Charts ändern möchten, bearbeiten Sie /var/lib/rancher/k3s/server/manifests/traefik.yaml nicht. k3s schreibt diese Datei bei jedem Start mit den Standardwerten neu. Legen Sie stattdessen eine separate Datei im selben Verzeichnis an. Alles in /var/lib/rancher/k3s/server/manifests wird beim Start und bei jeder Änderung an der Datei automatisch angewendet.

apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: traefik
  namespace: kube-system
spec:
  valuesContent: |-
    ports:
      web:
        forwardedHeaders:
          trustedIPs:
            - 10.0.0.0/8

Dieses Beispiel setzt einen Wert des Traefik-Charts: die Adressen vertrauenswürdiger Proxys. Mit demselben Verfahren können Sie jeden anderen vom Chart bereitgestellten Wert setzen, einschließlich der Ports.

Persistenter Speicher auf einem Knoten

k3s liefert standardmäßig eine StorageClass namens local-path, die auf Rancher's local-path provisioner basiert. Ein PersistentVolumeClaim ohne storageClassName verwendet diese StorageClass. Die Volumes liegen unter /var/lib/rancher/k3s/storage, jeweils in einem eigenen Unterverzeichnis auf der lokalen Festplatte des Knotens.

sudo k3s kubectl get storageclass
sudo k3s kubectl get pvc -A
sudo ls -l /var/lib/rancher/k3s/storage

Aus der Formulierung „auf der lokalen Festplatte des Knotens“ ergeben sich zwei Folgen. Beide werden erst später relevant.

Die StorageClass verwendet volumeBindingMode: WaitForFirstConsumer. Daher bleibt ein neuer PVC im Status Pending, bis ein Pod ihn tatsächlich einbindet. kubectl describe pvc gibt Folgendes aus:

waiting for first consumer to be created before binding

Das ist normal. Wenn Sie nur einen PVC erstellen und warten, ändert sich sein Status daher nicht.

Nach der Bindung erhält das Volume eine Node-Affinität für den Knoten, auf dem es erstellt wurde. Dadurch wird jeder Pod, der diesen Claim verwendet, für die gesamte Lebensdauer des Volumes an diesen Knoten gebunden. Auf einem einzelnen Knoten fällt das nicht auf. Wenn Sie später einen zweiten Knoten hinzufügen, wirkt ein Pod, der nicht auf einen anderen Knoten verschoben werden kann, wie ein Scheduler-Fehler. Führen Sie dann kubectl get pv -o yaml aus. Dort finden Sie den Hostnamen in nodeAffinity.

Für die Backups sind Sie selbst verantwortlich. Beim erneuten Erstellen des VPS wird dieses Verzeichnis gelöscht. Das gilt auch für das folgende Deinstallationsskript. Sichern Sie /var/lib/rancher/k3s/storage sowie den SQLite-Datenspeicher unter /var/lib/rancher/k3s/server/db/state.db. Kopieren Sie ihn nur bei gestopptem Dienst, da es sich um eine aktive Datenbank handelt. Alternativ können Sie den Cluster als jederzeit neu erstellbar behandeln und alle Manifeste in git verwalten.

Ingress und TLS

Wenn Traefik weiterhin aktiviert ist, benötigen Sie nur ein standardmäßiges Ingress-Objekt.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt
spec:
  ingressClassName: traefik
  tls:
    - hosts:
        - hello.example.com
      secretName: hello-tls
  rules:
    - host: hello.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: hello
                port:
                  number: 80

Zertifikate werden nicht automatisch erstellt. Die übliche Lösung ist cert-manager, installiert aus seinem veröffentlichten Manifest, zusammen mit einem ClusterIssuer. Version v1.21.1 ist im August 2026 aktuell.

sudo k3s kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.21.1/cert-manager.yaml

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt
spec:
  acme:
    email: you@example.com
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-account-key
    solvers:
      - http01:
          ingress:
            ingressClassName: traefik

Bei der HTTP-01-Challenge verbindet sich der ACME-Server (automatic certificate management environment) aus dem öffentlichen Internet mit http://hello.example.com/.well-known/acme-challenge/.... Der DNS-A-Eintrag muss daher bereits auf den VPS zeigen, und Port 80 muss Traefik erreichen. Wenn Sie ServiceLB deaktiviert und einen eigenen Proxy vorgeschaltet haben, muss dieser Proxy den Challenge-Pfad ebenfalls weiterleiten. Andernfalls bleibt cert-manager hängen und zeigt im Challenge-Objekt folgende Meldung:

Waiting for HTTP-01 challenge propagation: wrong status code '404', expected '200'

Überwachen Sie die Ausstellung mit sudo k3s kubectl describe certificate hello-tls und sudo k3s kubectl get order,challenge -A.

Die kubeconfig und warum der API-Server privat bleibt

k3s schreibt die Administratoranmeldedaten nach /etc/rancher/k3s/k3s.yaml. Die Datei gehört standardmäßig root und wird mit dem Modus 600 erstellt. Sie enthält ein Clientzertifikat mit cluster-admin-Berechtigungen. Jeder, der die Datei lesen kann, besitzt damit den Cluster.

sudo k3s kubectl get node
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
kubectl get node

Ein separat installiertes kubectl ohne gesetztes KUBECONFIG schlägt mit The connection to the server localhost:8080 was refused - did you specify the right host or port? fehl, weil es auf einen Standardwert zurückfällt, der nichts mit k3s zu tun hat. Setzen Sie KUBECONFIG oder verwenden Sie sudo k3s kubectl. Dieser Befehl liest automatisch die richtige Datei.

Häufig wird --write-kubeconfig-mode 644 empfohlen, damit ein normaler Benutzer kubectl ausführen kann. Beachten Sie die Auswirkungen: Dadurch wird ein cluster-admin-Anmeldedatensatz für jedes lokale Konto auf dem Rechner lesbar. Auf einem Rechner mit nur einem Administrator kann dieser Kompromiss vertretbar sein. Auf einem gemeinsam genutzten Rechner ist er das nicht. Wenn Sie die Datei kopieren, erhält nur ein Benutzer Zugriff, ohne dass die Datei allgemein lesbar wird:

mkdir -p ~/.kube
sudo install -o $USER -g $USER -m 600 /etc/rancher/k3s/k3s.yaml ~/.kube/config

Die Zeile server: in dieser Datei liest https://127.0.0.1:6443. Um kubectl von Ihrem Laptop aus zu verwenden, öffnen Sie Port 6443 nicht für das Internet. Eine öffentlich erreichbare Kubernetes-API ist ein dauerhaftes Ziel. Eine ungeschützte API führt dazu, dass kleine Cluster für das Mining von Kryptowährungen durch Dritte missbraucht werden. Tunneln Sie den Zugriff über SSH und lassen Sie die Adresse in der Datei unverändert:

ssh -N -L 6443:127.0.0.1:6443 user@your-vps
KUBECONFIG=./k3s.yaml kubectl get node

Wenn Sie die API über eine private Netzwerkadresse erreichen müssen, installieren Sie mit tls-san und geben Sie diesen Namen oder diese Adresse an. Bearbeiten Sie anschließend in der kopierten Datei die Zeile server: entsprechend. Ohne den SAN-Eintrag (Subject Alternative Name) verweigert kubectl die Verbindung:

x509: certificate is valid for 127.0.0.1, 10.43.0.1, not 203.0.113.10

Die dokumentierten eingehenden Ports für einen Cluster sind TCP 6443 für die API, UDP 8472 für flannel-VXLAN zwischen den Nodes und TCP 10250 für kubelet-Metriken. Bei einem einzelnen Node muss keiner dieser Ports zum Internet geöffnet sein.

containerd ist nicht Docker

k3s verwendet ein eigenes eingebettetes containerd und teilt keinen Image-Speicher mit Docker. Ein Image, das Sie gerade mit docker build erstellt haben, ist für k3s nicht sichtbar. Deshalb schlägt der Pod mit ErrImagePull fehl, obwohl docker images das Image auflistet. Importieren Sie es ausdrücklich:

docker save myapp:0.1 | sudo k3s ctr images import -
sudo k3s crictl images

Verwenden Sie anschließend für diesen Container nicht den Tag :latest. :latest verwendet standardmäßig ein imagePullPolicy von Always, und der kubelet greift deshalb trotzdem auf eine Registry zu. Jeder andere Tag verwendet standardmäßig IfNotPresent und nutzt damit das importierte Image. Beide Systeme können auf einem VPS betrieben werden. Dabei ist wichtig zu wissen, dass eine normale Docker-Installation auf einem VPS und k3s auf demselben Rechner jeweils einen eigenen Image-Speicher und eigene iptables-Regeln verwenden.

So entfernen Sie k3s

Das Installationsprogramm legt ein Deinstallationsskript an. Eine teilweise Entfernung und eine Rückgängig-Funktion gibt es nicht.

sudo /usr/local/bin/k3s-uninstall.sh

Das Skript beendet und entfernt den Dienst, löscht den Datenspeicher und die Daten persistenter Volumes, entfernt die Knotenkonfiguration und löscht die vom Installationsprogramm hinzugefügten Werkzeuge. Auf einem Agent-Knoten heißt das Skript stattdessen k3s-agent-uninstall.sh. Kopieren Sie zunächst alle Daten unter /var/lib/rancher/k3s/storage vom System, weil dieses Verzeichnis zusammen mit k3s entfernt wird. Prüfen Sie anschließend mit ip link show und sudo ss -lntp, dass keine Prozesse mehr Ports oder Netzwerkschnittstellen belegen. Eine verbliebene cni0- oder flannel.1-Schnittstelle wird beim nächsten Reboot entfernt.

Zu entscheiden, dass ein Kubernetes-Knoten für die Aufgabe mehr Aufwand als Nutzen bedeutet, ist ein normales Ergebnis und kein Fehlschlag. Die Workloads zurück zu Compose zu verschieben, dauert normalerweise einen Nachmittag.

Fehlerbilder und die angezeigten Meldungen

Node NotReady oder k3s wird in einer Endlosschleife neu gestartet. Lesen Sie zuerst sudo journalctl -u k3s -n 200 --no-pager. Auf einem kleinen VPS ist häufig der Out-of-Memory-Killer des Kernels die Ursache. Er beendet den Prozess. In dmesg erscheint dann eine Zeile, die k3s-server nennt. Das dokumentierte Minimum von 2 GB ist eine reale Untergrenze.

Ein Pod bleibt im Status Pending. kubectl describe pod nennt die Ursache in jedem Fall. Insufficient memory oder Insufficient cpu bedeutet, dass auf dem Node kein Speicherplatz oder keine Kapazität mehr verfügbar ist. didn't have free ports weist auf die oben beschriebene hostPort-Kollision hin. waiting for first consumer bei einer PVC bedeutet, dass WaitForFirstConsumer korrekt arbeitet.

ImagePullBackOff. Entweder existiert der Tag in keiner Registry, die der Node erreichen kann, oder Sie haben das Image mit Docker erstellt und nie in containerd importiert.

Traefik antwortet, die Anwendung jedoch nicht. Ein Antworttext mit 404 page not found stammt direkt von Traefik. Das bedeutet, dass die Anfrage eingegangen ist, aber kein Router dafür gefunden wurde. Prüfen Sie, ob host des Ingress dem eingegebenen Namen entspricht und ob ingressClassName gleich traefik ist.

Die Cluster-DNS-Auflösung schlägt fehl, während der Host Namen korrekt auflöst. Prüfen Sie CoreDNS mit sudo k3s kubectl -n kube-system logs -l k8s-app=kube-dns. Eine Meldung wie plugin/loop: Loop ... detected for zone "." verhindert den Start von CoreDNS. Die Ursache ist, dass CoreDNS Anfragen an einen Resolver weiterleitet, der sie an CoreDNS zurückleitet. Genau das bewirkt eine Loopback-Adresse in /etc/resolv.conf. Verweisen Sie k3s mit --resolv-conf /run/systemd/resolve/resolv.conf auf die tatsächliche Upstream-Datei.

FAQ

Lohnt sich k3s auf einem einzelnen VPS?

Ja, wenn Sie die Kubernetes-API benötigen: um sie auf einer von Ihnen verwalteten Maschine zu erlernen, Deployments als portable Manifeste zu verwalten, Software zu betreiben, die nur ein Helm-Chart veröffentlicht, oder etwas aufzubauen, das Sie später in einen Managed Cluster verschieben. Wenn Sie lediglich Container ausführen möchten, lohnt es sich nicht, weil Docker Compose dies mit deutlich weniger Verwaltungsaufwand und ungefähr einem Gigabyte mehr freiem RAM erledigt. Ein einzelner Node bietet keine Hochverfügbarkeit. Zuverlässigkeit ist daher kein Grund, sich dafür zu entscheiden.

Warum bleibt mein k3s-LoadBalancer-Service im Status Pending?

ServiceLB erstellt svclb- Pods. Diese belegen die Ports des Service auf dem Node als hostPort. Daher werden sie nur auf Nodes eingeplant, auf denen diese Ports frei sind. Wenn nginx oder ein anderer Proxy bereits Port 80 verwendet, bleibt der Pod im Status Pending, und der Service erhält nie eine externe Adresse. kubectl -n kube-system describe pod svclb-... meldet 0/1 nodes are available: 1 node(s) didn't have free ports for the requested pod ports. Geben Sie den Port frei, oder installieren Sie mit --disable=servicelb neu und leiten Sie den Datenverkehr an den NodePort weiter, den der Service weiterhin zuweist.

Wie viel RAM benötigt k3s auf einem VPS?

Das dokumentierte Minimum für einen Server-Node beträgt 2 Cores und 2 GB. Damit sind k3s und die mitgelieferten Komponenten abgedeckt, bevor Sie Ihre Workloads starten. Das eigene Profiling des Projekts hat für einen Server-Node mit darauf ausgeführtem Monitoring-Stack 1,596 MB gemessen. Betrachten Sie 2 GB daher als Untergrenze und 4 GB als erste Größe, bei der ein einzelner Node ausreichend Reserven hat. Messen Sie Ihr System mit free -h vor der Installation und erneut, nachdem jeder Pod in kube-system den Status Running erreicht hat.

Kann ich Docker und k3s auf demselben VPS ausführen?

Ja. Beide bleiben voneinander getrennt. k3s verwendet sein eigenes eingebettetes containerd. Ein mit docker build erstelltes Image ist daher erst sichtbar, nachdem Sie docker save myapp:0.1 | sudo k3s ctr images import - ausgeführt haben. Beide schreiben eigene iptables-Regeln und verwenden eigene Bridge-Netzwerke. Überwachen Sie den gesamten Speicherbedarf, weil Docker, k3s und Ihre Container auf einem System mit 2 GB nicht ausreichend Platz haben.

Wie entferne ich k3s vollständig?

Führen Sie sudo /usr/local/bin/k3s-uninstall.sh auf einem Server-Node oder sudo /usr/local/bin/k3s-agent-uninstall.sh auf einem Agent aus. Der Befehl stoppt den Dienst, löscht den Datenspeicher, löscht persistente Volume-Daten unter /var/lib/rancher/k3s/storage und entfernt die mitgelieferten Tools. Sichern Sie alle Daten, die Sie behalten möchten, vorher auf einem anderen System, weil der Vorgang nicht rückgängig gemacht werden kann. Eine verbleibende cni0- oder flannel.1-Netzwerkschnittstelle verschwindet beim nächsten Reboot.