Kubernetes am Edge: K3s, Fleet und die Kunst, einen Cluster zu betreiben, wo das Netzwerk lügt

Continuum findet, validiert und behebt Code-Schwachstellen: Es beweist, welche Befunde in Ihrer Umgebung tatsächlich ausnutzbar sind, priorisiert sie nach geschäftlicher Auswirkung und schlägt Korrekturen vor – mit menschlicher Freigabe, bevor etwas ausgeliefert wird.

Kubernetes ist eine Control Plane, die davon ausgeht, dass ihre Nodes erreichbar sind, ihr etcd dauerhaft ist und ihr Betreiber eine Person mit Laptop und VPN ist. Verlegen Sie es in eine Fabrikhalle, auf einen Mobilfunkmast, in einen Einzelhandelslagerraum oder auf ein Schiff, und jede dieser Annahmen bricht. Das Netzwerk lügt. Der Strom flackert. Die Hardware ist klein. Und die Person, die es bereitgestellt hat, ist dreihundert Kilometer entfernt, wahrscheinlich schlafend.

Dieser Artikel ist ein Feldführer für den Betrieb von Kubernetes am Edge mit den Werkzeugen, die dort tatsächlich funktionieren: K3s als Laufzeit, Fleet als Flottenmanager, GitOps als Auslieferungsmechanismus und eine Reihe von Praktiken, um die Bedingungen zu überstehen, über die die Cloud nie nachdenken muss. Er ist aus der Perspektive des Betreibers geschrieben – was Sie bereitstellen, was kaputtgeht und worauf Sie achten müssen.

Was „Edge“ tatsächlich bedeutet

Das Wort Edge wird für drei verschiedene Dinge verwendet, und sie zu vermischen ist der erste Fehler.

• Das Far Edge: Hunderte oder Tausende von Standorten mit jeweils einer Handvoll Geräten – Einzelhandelsgeschäfte, Mobilfunkmasten, Geldautomaten, Verkaufsautomaten. Sehr begrenzte Rechenleistung, intermittierende Konnektivität, kein Personal vor Ort.
• Das Near Edge: Regionale Präsenzpunkte mit bescheidenen Racks – regionale Rechenzentren, Telekom-Zentralen, Fabrikkontrollräume. Echte Server, aber begrenzte Stromversorgung, Kühlung und Bandbreite.
• Das Device Edge: Das Gerät selbst – eine Kamera, ein Roboter, ein Sensor – das einen einzelnen Container oder einen winzigen K3s-Node ausführt.

Die Architektur ändert sich mit der Stufe. Ein Far-Edge-Standort betreibt einen einzelnen K3s-Node mit einer Handvoll Pods und einem lokalen Store-and-Forward-Puffer. Ein Near-Edge-Standort betreibt einen kleinen HA-Cluster. Eine Device-Edge-Bereitstellung ist oft gar kein Kubernetes – es ist ein Container auf einem Gerät, der von derselben Control Plane verwaltet wird, die auch die Cluster verwaltet.

Dieser Artikel konzentriert sich auf das Far und Near Edge, wo Kubernetes seinen Wert verdient: viele Standorte, eine Control Plane, deklarative Konfiguration und die Fähigkeit, eine Änderung an tausend Standorten ohne Flugticket auszurollen.

Warum K3s

K3s ist für die meisten Edge-Fälle die richtige Antwort, und die Gründe sind nicht die üblicherweise genannten.

Es ist nicht „Kubernetes Lite“ im Sinne eines Spielzeugs. Es ist eine zertifizierte Kubernetes-Distribution mit API-Server, Scheduler, Controller-Manager und Kubelet in einer einzigen Binärdatei, mit SQLite als Standard-Datenspeicher und einem eingebetteten containerd. Der Footprint ist klein – etwa 50 MB Binärdatei, ~250 MB RAM im Leerlauf – und es läuft auf einem Raspberry Pi, einem Industrie-PC oder einer VM mit zwei Kernen.

Die Gründe, die am Edge zählen:

1. Eine einzige Binärdatei, ein einziger Prozess. Eine systemd-Unit. Eine Sache, die neu gestartet werden muss. Eine Sache, die aktualisiert werden muss. Bei tausend Standorten ist „wie viele bewegliche Teile“ die einzige Metrik, die skaliert.
2. SQLite-Datenspeicher standardmäßig. Kein externes etcd, das betrieben, gesichert oder verloren werden kann. Für Einzelknoten-Edge-Cluster ist das der richtige Kompromiss: Dauerhaftigkeit kommt von GitOps und von der Tatsache, dass der Cluster in Minuten aus der Spezifikation neu aufgebaut werden kann.
3. Eingebettetes containerd. Kein Docker-Daemon zu verwalten, kein Socket zu sichern. K3s bringt sein eigenes mit.
4. Air-Gap-freundlich. Ein einziges Tarball enthält alles. Sie können einen Node ohne Internetzugang installieren.
5. HA, wenn Sie es brauchen. Drei K3s-Nodes mit einem externen Datenspeicher (etcd oder Postgres) ergeben eine echte HA-Control-Plane. Verwenden Sie es für Near-Edge-Standorte mit echten Servern.

Die Kompromisse: K3s wird standardmäßig mit Traefik, CoreDNS und einem Local-Path-Provisioner ausgeliefert. Für Edge sollten Sie Traefik normalerweise deaktivieren und Ihr eigenes Ingress mitbringen, und Sie sollten mit dem Local-Path-Provisioner vorsichtig sein, da lokaler Speicher auf Edge-Hardware unzuverlässig ist.

# Minimale Edge-Installation: kein Traefik, kein gebündelter Metrics-Server, Air-Gap-freundlich
curl -sfL https://get.k3s.io | sh -s - \
  --disable traefik \
  --disable metrics-server \
  --write-kubeconfig-mode 644

# Überprüfen
k3s kubectl get nodes -o wide
systemctl status k3s --no-pager

Die Control Plane: Ein Cluster, der alle beherrscht

Das Edge-Muster, das funktioniert, ist eine Hub-and-Spoke-Topologie. Ein einzelner Verwaltungscluster – der in Ihrer Cloud oder Ihrem On-Prem-Rechenzentrum läuft – hält den gewünschten Zustand für jeden Edge-Standort. Jeder Edge-Standort betreibt seinen eigenen K3s-Cluster. Der Verwaltungscluster führt nicht die Edge-Workloads aus; er führt die Controller aus, die die Konfiguration an sie pushen.

Das Werkzeug dafür ist Fleet, Ranchers GitOps-Engine, obwohl Argo CD und Flux auch funktionieren. Fleet ist speziell für das Problem „viele Cluster, eine Quelle der Wahrheit“ gebaut: Es beobachtet ein Git-Repository, bündelt die Manifests und rollt sie auf eine Reihe von Zielclustern aus, die durch Labels ausgewählt werden.

Der Grund, warum Fleet besser zum Edge passt als die Alternativen:

• Es ist für Tausende von Clustern ausgelegt, nicht für Dutzende.
• Es behandelt Teil-Rollouts und cluster-spezifische Überschreibungen nativ.
• Es funktioniert offline: Ein Edge-Cluster kann sein Bundle ziehen, wenn die Konnektivität zurückkehrt, und der gewünschte Zustand wird lokal zwischengespeichert.
• Es hat ein einfaches mentales Modell: Git → Bundle → Cluster-Selektor → Anwenden.

# fleet.yaml im Stammverzeichnis Ihres GitOps-Repos
defaultNamespace: edge-apps
helm:
  repo: https://charts.example.com
  chart: edge-agent
  version: "1.4.2"
  values:
    telemetryEndpoint: https://telemetry.example.com
targetCustomizations:
  - name: retail
    clusterSelector:
      matchLabels:
        site-type: retail
    helm:
      values:
        storeId: "{{ .ClusterLabels.storeId }}"
  - name: factory
    clusterSelector:
      matchLabels:
        site-type: factory
    helm:
      values:
        modbusEnabled: true

Der Cluster-Selektor ist der Schlüssel. Sie labeln jeden Edge-Cluster, wenn er sich registriert – site-type, region, hardware-generation, customer – und Fleet leitet die richtige Konfiguration an die richtigen Standorte. Ein neuer Standort, der sich mit den richtigen Labels registriert, erhält automatisch die richtige Konfiguration. Kein Ticket, kein manueller Schritt.

GitOps als einziger Auslieferungsmechanismus

Am Edge ist GitOps keine Präferenz. Es ist der einzige Auslieferungsmechanismus, der die Bedingungen übersteht.

Der Grund ist einfach: Der Edge-Cluster kann nicht erreicht werden. SSH ist blockiert, das VPN ist down, und die Person mit den Schlüsseln ist in einem Flugzeug. Der einzige Kanal, der zuverlässig funktioniert, ist ausgehendes HTTPS vom Edge zur Verwaltungsebene (oder zu einem Git-Host). GitOps verwandelt diesen Kanal in den gesamten Auslieferungspfad: Der Edge-Cluster zieht seinen gewünschten Zustand, wendet ihn an und meldet den Status zurück. Kein eingehender Zugriff erforderlich.

Die Regeln, die das zum Funktionieren bringen:

1. Alles ist in Git. Manifests, Helm-Charts, Kustomize-Overlays, Fleet-Bundles, sogar das K3s-Installationsskript. Wenn es nicht in Git ist, existiert es am Edge nicht.
2. Der Edge-Cluster ist wegwerfbar. Ein Standort sollte aus seiner Git-Spezifikation plus einer K3s-Installation wiederherstellbar sein. Wenn Sie einen Standort nicht in 30 Minuten von einem USB-Stick und einer Git-URL neu aufbauen können, ist Ihre Architektur falsch.
3. Versionen pinnen. Stellen Sie niemals latest am Edge bereit. Pinnen Sie Chart-Versionen, Image-Digests und Fleet-Bundle-Versionen. Ein unkontrolliertes Update, das einen Standort beschädigt, beschädigt tausend.
4. In Wellen ausrollen. Verwenden Sie die Rollout-Strategie von Fleet, um zuerst in einer Canary-Gruppe bereitzustellen – 1 %, dann 10 %, dann 100 %. Der Edge ist der Ort, an dem eine schlechte Version zu einem physischen Problem wird.
5. Einen lokalen Cache behalten. Der Edge-Cluster sollte sein letztes bekanntes gutes Bundle zwischenspeichern. Wenn Git nicht erreichbar ist, läuft er mit der letzten guten Konfiguration weiter, anstatt abzustürzen.

# Fleet-Rollout mit Canary
rolloutStrategy:
  maxUnavailable: 5%
  maxUnavailablePartitions: 1
  autoPartitionSize: 10%
  partitions:
    - name: canary
      maxUnavailable: 1
      clusterSelector:
        matchLabels:
          canary: "true"
    - name: production
      maxUnavailable: 5%

Das Netzwerk überleben

Das Netzwerk am Edge ist nicht langsam. Es ist intermittierend, asymmetrisch und feindselig. Zellulare Backhaul-Verbindungen verlieren Pakete. Satellitenverbindungen haben 600 ms Latenz. Fabriknetzwerke sind aus politischen Gründen per Air-Gap getrennt. Das Design muss davon ausgehen, dass die Verbindung die meiste Zeit down ist, und Konnektivität als Bonus behandeln.

Praktiken, die zählen:

• Store-and-Forward für Telemetrie. Puffern Sie Metriken und Logs lokal (Prometheus-Remote-Write-Warteschlange, Vector oder ein einfacher SQLite-Puffer) und leeren Sie sie, wenn die Verbindung zurückkehrt. Verwerfen Sie niemals Daten stillschweigend; blockieren Sie niemals die Anwendung, die auf einen entfernten Endpunkt wartet.
• Lokales DNS und Service Discovery. CoreDNS auf dem Edge-Cluster löst lokale Dienste auf. Verlassen Sie sich für nichts, was die Anwendung zum Starten benötigt, auf einen entfernten DNS-Resolver.
• Offline-fähige Images. Ziehen Sie alle Images vorab auf den Node. K3s kann mit einem Image-Registry-Mirror oder einem Air-Gap-Image-Tarball konfiguriert werden. Ein Pod, der sein Image nicht ziehen kann, ist ein Pod, der nicht startet.
• Idempotente Rekonziliation. Der GitOps-Controller muss tolerieren, dass er Git stunden- oder tagelang nicht erreichen kann, ohne zu degradieren. Fleet und Flux handhaben das; stellen Sie sicher, dass Ihre eigenen Controller das auch tun.
• Graceful Degradation. Die Anwendung sollte ihre Kernfunktion weiterhin erfüllen, wenn Upstream down ist. Ein Point-of-Sale-Terminal, das nicht mehr funktioniert, weil die Cloud-Inventar-API nicht erreichbar ist, ist ein Designfehler.

# K3s Air-Gap: Private Registry-Mirror-Konfiguration
# /etc/rancher/k3s/registries.yaml
mirrors:
  docker.io:
    endpoint:
      - "https://registry.edge.local:5000"
  "registry.edge.local:5000":
    endpoint:
      - "https://registry.edge.local:5000"
configs:
  "registry.edge.local:5000":
    tls:
      insecure_skip_verify: false
    auth:
      username: edge
      password: "${REGISTRY_PASSWORD}"

Observability auf beschränkter Hardware

Sie können keinen vollständigen Prometheus + Grafana + Loki + Tempo-Stack auf einem 2-Kern-, 4-GB-Edge-Node betreiben. Der Observability-Footprint muss proportional zur Hardware sein.

Das Muster, das funktioniert:

1. Leichter Agent auf dem Edge. VictoriaMetrics-Agent oder Prometheus mit einem kleinen Scrape-Intervall und kurzer Aufbewahrungsdauer (1–2 Stunden). Scrapen Sie nur die Metriken, die zählen: Node-Gesundheit, Pod-Neustarts, Festplattennutzung, Netzwerk up/down.
2. Puffern und weiterleiten. Remote-Write an eine zentrale VictoriaMetrics- oder Thanos-Instanz. Lokal für 24–48 Stunden getrennten Betrieb puffern.
3. Zentrale Dashboards. Grafana lebt im Verwaltungscluster, nicht am Edge. Der Edge-Node braucht keine Benutzeroberfläche.
4. Logs: Stichproben und versenden. Versenden Sie Logs auf Fehlerebene und eine Stichprobe von Logs auf Info-Ebene. Vollständige Protokollierung auf einem beschränkten Node ist eine Verschwendung von Festplatte und Bandbreite.
5. Synthetische Sonden. Ein kleiner Cronjob auf dem Edge-Node, der einen Health-Endpunkt anruft und up/down meldet. Das ist das nützlichste einzelne Signal: Ist der Standort am Leben?

# VictoriaMetrics-Agent auf dem Edge
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: vmagent
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: vmagent
  template:
    metadata:
      labels:
        app: vmagent
    spec:
      containers:
        - name: vmagent
          image: victoriametrics/vmagent:v1.102.0
          args:
            - "-promscrape.config=/config/scrape.yml"
            - "-remoteWrite.url=https://metrics.example.com/api/v1/write"
            - "-remoteWrite.tmpDataPath=/data/buffer"
            - "-remoteWrite.maxDiskUsagePerURL=1GB"
          volumeMounts:
            - name: config
              mountPath: /config
            - name: buffer
              mountPath: /data
      volumes:
        - name: config
          configMap:
            name: vmagent-config
        - name: buffer
          hostPath:
            path: /var/lib/vmagent
            type: DirectoryOrCreate

Die Einstellung maxDiskUsagePerURL ist das Sicherheitsnetz: Wenn der Puffer voll ist, verwirft vmagent die ältesten Daten, anstatt abzustürzen oder die Festplatte zu füllen. Auf Edge-Hardware ist eine volle Festplatte ein Standortausfall.

Upgrades: Der Teil, der tatsächlich wehtut

Die Aktualisierung von tausend Edge-Clustern ist der schwierigste Teil der Arbeit, und hier scheitern die meisten Edge-Bereitstellungen.

• K3s-Upgrades sind einfach, aber riskant. Ein einziger Binärdatei-Tausch, aber wenn es kaputtgeht, ist der Standort down und niemand ist da, um es zu reparieren. Testen Sie jedes Upgrade in einem Labor, das die Edge-Hardware nachbildet. Rollen Sie in Wellen aus. Behalten Sie die vorherige Binärdatei auf der Festplatte für den Rollback.
• Fleet-Bundle-Upgrades sind der normale Weg. Anwendungsupdates laufen über GitOps. K3s-Upgrades erfordern einen separaten Mechanismus – Ranchers System-Upgrade-Controller oder ein von Fleet verwaltetes DaemonSet, das das Installationsskript ausführt.
• Hardware-Upgrades sind physisch. Planen Sie für 3–5-jährige Hardware-Lebenszyklen. Entwerfen Sie die Software so, dass sie auf der ältesten Hardware in der Flotte läuft, nicht auf der neuesten.
• OS-Upgrades sind die versteckten Kosten. Das Betriebssystem unter K3s muss gepatcht werden. Verwenden Sie ein unveränderliches OS (Flatcar, Talos oder ein schreibgeschütztes Root mit A/B-Updates), damit das OS ein versioniertes Artefakt ist, kein Unikat.

# System-Upgrade-Controller-Plan für K3s
apiVersion: upgrade.cattle.io/v1
kind: Plan
metadata:
  name: k3s-upgrade
  namespace: system-upgrade
spec:
  concurrency: 10
  cordon: true
  nodeSelector:
    matchExpressions:
      - key: node-role.kubernetes.io/control-plane
        operator: In
        values: ["true"]
  serviceAccountName: system-upgrade
  upgrade:
    image: rancher/k3s-upgrade
    version: v1.30.4-k3s1

Das concurrency: 10 ist das Sicherheitsventil. Aktualisieren Sie niemals die gesamte Flotte auf einmal.

Sicherheit am Edge

Edge-Standorte sind physisch zugänglich. Ein Gerät in einem Einzelhandelslagerraum kann abgesteckt, geöffnet oder gestohlen werden. Das Sicherheitsmodell muss davon ausgehen, dass die Hardware kompromittiert ist.

• Verschlüsselung im Ruhezustand. K3s unterstützt verschlüsselte Secrets und etcd- (oder SQLite-)Verschlüsselung. Verwenden Sie es.
• mTLS überall. Fleet kommuniziert über mTLS. Die Kubeconfig des Edge-Clusters sollte auf ein Servicekonto mit minimalen Berechtigungen beschränkt sein, nicht auf Cluster-Admin.
• Schreibgeschütztes Root-Dateisystem. Wo das OS es unterstützt, mounten Sie das Root-Dateisystem schreibgeschützt und verwenden Sie ein beschreibbares Overlay für Laufzeitdaten.
• Remote-Attestierung. Verwenden Sie für Standorte mit hohen Sicherheitsanforderungen TPM-basierte Attestierung, um die Identität des Nodes zu überprüfen, bevor er der Verwaltungsebene beitritt.
• Keine Secrets in Git. Verwenden Sie SOPS, Sealed Secrets oder einen externen Secrets-Operator, der zur Laufzeit aus einem Vault abruft. Der Edge-Cluster zieht Secrets über mTLS aus dem Vault, niemals aus dem Git-Repo.

Was Sie stattdessen tun sollten (die Kurzversion)

1. Verwenden Sie K3s. Einzelne Binärdatei, SQLite-Datenspeicher, Air-Gap-freundlich. Deaktivieren Sie Traefik und bringen Sie Ihr eigenes Ingress mit.
2. Verwenden Sie Fleet (oder Flux/Argo) für GitOps. Labeln Sie Cluster nach Standorttyp, Region und Hardware. Lassen Sie den Selektor die Konfiguration automatisch weiterleiten.
3. Pinnen Sie alles. Versionen, Image-Digests, Bundle-Versionen. Kein latest am Edge.
4. Rollen Sie in Wellen aus. Zuerst Canary, dann Produktion. Niemals die gesamte Flotte auf einmal.
5. Gehen Sie davon aus, dass das Netzwerk down ist. Store-and-Forward, lokales DNS, vorab gezogene Images, Graceful Degradation.
6. Halten Sie Observability klein. Ein leichter Agent, ein zentrales Dashboard, eine synthetische Sonde. Führen Sie niemals einen vollständigen Stack auf einem beschränkten Node aus.
7. Machen Sie Standorte wegwerfbar. In 30 Minuten aus Git + einem USB-Stick wiederherstellbar.
8. Verwenden Sie ein unveränderliches OS. Flatcar, Talos oder A/B-Updates. Keine Unikate.
9. Verschlüsseln und attestieren. Die Hardware ist physisch zugänglich. Planen Sie dafür.

Coda: Der Cluster ist ein Werkzeug

Kubernetes am Edge ist keine kleinere Version von Kubernetes in der Cloud. Es ist eine andere Sache: ein Werkzeug, das Bedingungen überstehen muss, denen die Cloud nie ausgesetzt ist, verwaltet von Menschen, die nie vor Ort sind, läuft auf Hardware, die alt und klein ist. Die Werkzeuge, die funktionieren – K3s, Fleet, GitOps, unveränderliches OS, leichte Observability – sind diejenigen, die diese Bedingungen akzeptieren, anstatt gegen sie anzukämpfen.

Der Cluster ist ein Werkzeug. Wie alle Werkzeuge sollte er in der Arbeit zurücktreten. Am Edge besteht die Arbeit darin, tausend Standorte am Laufen zu halten, während niemand zusieht. Die Kunst besteht darin, etwas zu bauen, das das kann, und ihm dann aus dem Weg zu gehen.

Quellen und weiterführende Literatur

• K3s-Dokumentation: https://docs.k3s.io
• Fleet-Dokumentation: https://fleet.rancher.io
• Rancher System-Upgrade-Controller: https://github.com/rancher/system-upgrade-controller
• CNCF-Edge-Computing-Whitepaper: https://www.cncf.io/reports/
• Flatcar Container Linux: https://www.flatcar.org
• Talos Linux: https://www.talos.dev
• VictoriaMetrics: https://docs.victoriametrics.com
• SOPS: https://github.com/getsops/sops
• Sealed Secrets: https://sealed-secrets.netlify.app
• KubeCon + CloudNativeCon Kubernetes on Edge Day: https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/