Guide: k3s-Produktionscluster mit Rancher, Longhorn und MetalLB

Guide: n8n-Workflow-Automatisierung im Produktionseinsatz

n8n im Queue-Modus mit Redis, PostgreSQL-Persistenz und sauberem Prozess-Supervising — das unspektakuläre, zuverlässige Setup, das Neustarts und Lastspitzen übersteht. Die Automatisierungsschicht hint

Guide: n8n-Workflow-Automatisierung im Produktionseinsatz

n8n im Queue-Modus mit Redis, PostgreSQL-Persistenz und sauberem Prozess-Supervising — das unspektakuläre, zuverlässige Setup, das Neustarts und Lastspitzen übersteht. Die Automatisierungsschicht hint

Ein vollständiges Muster von Lab bis Produktion: k3s in Docker mit eingebettetem etcd, Rancher für das Management, MetalLB für Layer-2-LoadBalancer-IPs, replizierter Longhorn-Speicher und Traefik-Ingress. Versionen davon betreibe ich auf eigener Hardware.

Was das ist

Ein Deployment-Guide mit lauffähigen Beispielen — kein herunterladbares Produkt. Alles unten ist die tatsächlich eingesetzte Konfiguration, gekürzt auf das, worauf es ankommt.

Deployment-Beispiel

services:
  k3s-server:
    image: rancher/k3s:${K3S_VERSION:-v1.36.4-k3s1}
    container_name: k3s-server
    restart: unless-stopped
    privileged: true
    command:
      - server
      - --disable=servicelb
      - --node-name=${K3S_NODE_NAME:-k3s-server}
    environment:
      K3S_TOKEN: ${K3S_TOKEN:?set K3S_TOKEN in .env}
      K3S_KUBECONFIG_MODE: "644"
      K3S_AGENT_TOKEN: ${K3S_AGENT_TOKEN:-}
    tmpfs:
      - /run
      - /var/run
    volumes:
      - k3s-server-data:/var/lib/rancher/k3s
      - k3s-server-etc:/etc/rancher/k3s
      - /var/lib/rancher/k3s/agent:/var/lib/rancher/k3s/agent
      - /dev/mapper:/dev/mapper
      - /etc/localtime:/etc/localtime:ro
    ports:
      - ${K3S_API_PORT:-6443}:6443
    networks:
      - k3s
    healthcheck:
      test:
        - CMD
        - k3s
        - kubectl
        - get
        - nodes
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 60s

Auszug — k3s-server aus der Compose-Datei. Die übrigen Services (k3s-agent, rancher) folgen demselben Muster und binden ihre Konfiguration aus einem config/-Verzeichnis ein.

Wesentliche Umgebungsvariablen

Kopieren Sie .env.example zu .env und setzen Sie mindestens:

K3S_VERSION=v1.36.4-k3s1
RANCHER_VERSION=v2.15.0
K3S_TOKEN=change_me_random_64_chars
K3S_AGENT_TOKEN=
K3S_API_PORT=6443
RANCHER_HTTP_PORT=8080

Produktions-Checkliste

• Starke, eindeutige Secrets in .env setzen — niemals die Beispielwerte übernehmen
• Image-Versionen pinnen und Upgrades zuerst auf einer Staging-Kopie testen
• Backups einrichten und einen Restore-Test durchführen, bevor man sich darauf verlässt
• Den Stack über TLS erreichen und Management-UIs auf VPN oder Allowlist beschränken
• Den Stack von Tag eins an in Monitoring und Alerting einbinden

Was welche Komponente besitzt

Debugging wird einfach, sobald jeder Fehler genau einer Komponente zugeordnet ist. Das eingebettete etcd besitzt den Cluster-Zustand — alles zu Objekten, Secrets oder Mitgliedschaft ist seine Domäne, und ein etcd-Snapshot ist das wahre Cluster-Backup. MetalLB besitzt Service-IPs: Ein Service, der in <pending> hängt, ist eine MetalLB-Frage, keine Kubernetes-Frage. Longhorn besitzt Volumes: Ein PVC, das nicht aus dem Pending kommt, oder ein Volume, das sich nicht attachen lässt, ist Longhorn — die UI zeigt die Replikationsgesundheit pro Volume. Traefik besitzt den Ingress: 404er und Routing-Überraschungen sind Ingress-Ressourcen samt Labels. Rancher besitzt nichts auf dem Datenpfad — es ist Management-UI und API, es darf also ausfallen, ohne dass der Cluster es bemerkt. Wer diese Grenzen kennt, verwandelt „der Cluster ist kaputt“ in eine Ein-Komponenten-Untersuchung.

Der Weg vom Labor in die Produktion

Das Wachstum folgt einer festen Sequenz. Stufe eins ist der einzelne Server — alles auf einem Knoten, für Entwicklung völlig ausreichend. Stufe zwei fügt Worker-Agents hinzu; ab hier bedeutet Longhorn-Replikation etwas. Stufe drei fügt einen zweiten und dann einen dritten Server hinzu, denn das etcd-Quorum braucht eine ungerade Anzahl, und drei ist die kleinste Zahl, die einen Ausfall überlebt. Stufe vier ist der Produktionsschritt: LoadBalancer-Services über MetalLB mit echtem Traffic — und der Schritt, den alle überspringen: ein geplanter etcd-Snapshot mit geprobtem Restore. Ein Cluster, dessen Restore nie geprobt wurde, ist ein Cluster, den Sie aus dem Gedächtnis neu bauen werden.

FAQ

Warum k3s in Docker statt klassischen VMs oder Bare Metal? Der Docker-Wrapper macht den gesamten Cluster deklarativ: Knotenzahl, Versionen und Datastore liegen in einer Compose-Datei — ein Labor baut sich in Minuten neu auf, und dieselbe Datei trägt bis zur Produktions-Topologie. Das eingebettete etcd liefert echte Hochverfügbarkeit ohne externen Zertifikats- oder Datastore-Betrieb.

Brauche ich MetalLB wirklich im kleinen Cluster? Wenn Sie etwas als LoadBalancer-Service auf eigener Hardware exponieren: ja — es gibt keinen Cloud-Controller, der IPs verteilt, und reine NodePorts werden schnell unschön. MetalLB im Layer-2-Modus annonciert Service-IPs über ARP und funktioniert auf jedem gewöhnlichen LAN ohne BGP.

Warum Longhorn statt dem lokalen Speicher des Hosts? Lokale Pfade binden Workloads an einen Knoten; Longhorn repliziert Volumes über Knoten, sodass ein Knotenausfall die Daten nicht mitnimmt — und geplante Snapshots gibt es obendrauf. Im Labor sind drei Replikate auf zwei-plus Knoten ein spürbarer Resilienz-Sprung bei vernachlässigbarem Einrichtungsaufwand.

Kann ich mit einem Knoten starten und später wachsen? Ja. Ein Server mit eingebettetem etcd trägt alles; weitere Server-Knoten sind später eine Compose-Änderung plus hinzugefügte Agents. Die Migration früh planen — etcd-Quorum braucht eine ungerade Serveranzahl, aus zwei werden also drei, bevor es fünf werden.

Ein Guide, kein Produkt. Diese Seite ist Deployment-Dokumentation mit lauffähigen Beispielen — kein Zip, kein Download, kein Supportvertrag. Sie adaptieren die Muster auf Ihre eigene Umgebung, und das Ergebnis gehört Ihnen.

Wenn Sie das produktionsreif in Ihrer Infrastruktur wollen: Ich vermittle das als zweitägigen Workshop Kubernetes im Produktionseinsatz — Details auf der Consulting-Seite.