Kubernetes am Edge: K3s und MicroK8s in der Fertigung einsetzen

TL;DR

• K3s ist die bevorzugte Distribution fuer Edge-Knoten in der Fertigung -- laeuft auf ARM und x86, braucht 512 MB RAM
• Fleet Management ueber Rancher/Fleet oder Argo CD ist ab 5+ Standorten unverzichtbar
• OT-Netze (Profinet, OPC UA) und IT-Netze muessen strikt getrennt bleiben, auch am Edge
• Datenvorverarbeitung am Edge reduziert Cloud-Traffic um 60-80% -- nur aggregierte Ergebnisse gehen nach oben
• GitOps ist der einzig skalierbare Weg, um Dutzende Edge-Cluster konsistent zu halten

Warum Kubernetes am Produktionsstandort?

In der klassischen Architektur schicken Sensoren und SPSen ihre Daten an einen zentralen Server -- entweder On-Premise im Rechenzentrum oder in der Cloud. Das funktioniert, solange die Netzwerkverbindung stabil ist und die Latenz keine Rolle spielt.

In der Praxis sieht es anders aus. Eine Qualitaetskontrolle per Computer Vision braucht Inferenz-Ergebnisse in unter 50 ms. Ein Predictive-Maintenance-Modell, das einen Lagerschaden erkennt, muss die Maschine sofort stoppen koennen -- nicht nach einem Cloud-Roundtrip von 200 ms. Und wenn die WAN-Verbindung zum Rechenzentrum ausfaellt, darf die Produktion nicht stillstehen.

Kubernetes am Edge loest diese Probleme, indem Compute direkt an den Ort der Wertschoepfung gebracht wird. Nicht als Ersatz fuer die zentrale Infrastruktur, sondern als Erweiterung.

K3s vs. MicroK8s vs. Vanilla Kubernetes

Nicht jede Kubernetes-Distribution ist fuer die Fertigungshalle geeignet. Vanilla Kubernetes (kubeadm) braucht mindestens 2 GB RAM pro Node und setzt einen funktionierenden etcd-Cluster voraus. Am Edge ist das oft zu viel.

K3s hat sich als De-facto-Standard fuer Edge-Deployments etabliert. Der Grund: Ein einzelnes Binary, kein externer etcd noetig, und das System laeuft stabil auf Hardware wie dem Siemens IPC227E oder vergleichbaren Industrie-PCs.

K3s auf einem Edge-Node installieren

Die Installation ist bewusst einfach gehalten. Ein curl-Befehl genuegt:

# K3s als Server (Control Plane + Worker) installieren
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server" sh -s - \
  --write-kubeconfig-mode 644 \
  --disable traefik \
  --disable servicelb \
  --node-label edge-location=werk-sued \
  --node-label machine-type=cnc-bereich

# Kubeconfig pruefen
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
kubectl get nodes

# Weitere Worker-Nodes hinzufuegen (Token vom Server holen)
K3S_TOKEN=$(cat /var/lib/rancher/k3s/server/node-token)
curl -sfL https://get.k3s.io | K3S_URL=https://10.0.50.10:6443 \
  K3S_TOKEN=$K3S_TOKEN sh -

Traefik und ServiceLB werden hier deaktiviert, weil am Edge in der Regel kein Ingress-Controller benoetigt wird. Die Sensordaten kommen ueber OPC UA oder MQTT rein, nicht ueber HTTP.

Deployment: Sensordaten-Collector

Ein typischer Edge-Workload sammelt Daten von OPC-UA-Endpunkten, fuehrt eine Vorverarbeitung durch und schickt nur die Ergebnisse an die zentrale Instanz.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sensor-collector
  namespace: edge-workloads
  labels:
    app: sensor-collector
    zone: ot-bridge
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sensor-collector
  template:
    metadata:
      labels:
        app: sensor-collector
        zone: ot-bridge
    spec:
      containers:
        - name: collector
          image: registry.internal/sensor-collector:2.4.1
          ports:
            - containerPort: 8080
              name: metrics
          env:
            - name: OPCUA_ENDPOINT
              value: "opc.tcp://10.0.100.20:4840"
            - name: SAMPLE_INTERVAL_MS
              value: "500"
            - name: UPSTREAM_URL
              valueFrom:
                configMapKeyRef:
                  name: edge-config
                  key: central-ingest-url
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              cpu: 500m
              memory: 512Mi
          volumeMounts:
            - name: data-buffer
              mountPath: /var/data/buffer
      volumes:
        - name: data-buffer
          hostPath:
            path: /mnt/edge-storage/buffer
            type: DirectoryOrCreate
      nodeSelector:
        edge-location: werk-sued
      tolerations:
        - key: "edge"
          operator: "Exists"
          effect: "NoSchedule"
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: edge-config
  namespace: edge-workloads
data:
  central-ingest-url: "https://ingest.zentral.internal:8443/api/v1/metrics"

Wichtig ist der hostPath-Volume-Mount fuer den Datenpuffer. Wenn die Verbindung zum zentralen Cluster abbricht, werden Daten lokal zwischengespeichert. Sobald die Verbindung wieder steht, werden sie nachgesendet. Das ist kein Kubernetes-Feature, sondern muss in der Collector-Applikation implementiert sein.

Netzwerk: OT und IT trennen

Die vielleicht wichtigste Regel am Edge: Das OT-Netz (Operational Technology), in dem Maschinen, SPSen und Sensoren haengen, darf nicht direkt mit dem IT-Netz verbunden sein. Kubernetes-Pods, die OPC-UA-Endpunkte abfragen, brauchen ein dediziertes Interface ins OT-Netz und ein separates Interface fuer die Upstream-Kommunikation.

In der Praxis wird das ueber Multus (ein CNI-Plugin fuer mehrere Netzwerk-Interfaces pro Pod) oder ueber dedizierte Gateway-Nodes geloest, die physisch in beiden Netzen haengen.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: ot-bridge-policy
  namespace: edge-workloads
spec:
  podSelector:
    matchLabels:
      zone: ot-bridge
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - ipBlock:
            cidr: 10.0.100.0/24  # OT-Netz
      ports:
        - protocol: TCP
          port: 4840  # OPC UA
  egress:
    - to:
        - ipBlock:
            cidr: 10.0.100.0/24  # OPC UA Server
      ports:
        - protocol: TCP
          port: 4840
    - to:
        - ipBlock:
            cidr: 10.0.50.0/24  # IT-Netz, Upstream
      ports:
        - protocol: TCP
          port: 8443  # Zentrale Ingest-API
    - to:
        - namespaceSelector:
            matchLabels:
              name: kube-system
      ports:
        - protocol: UDP
          port: 53

Diese Policy erlaubt dem Collector genau drei Dinge: OPC-UA-Daten lesen, Ergebnisse an die zentrale API schicken, DNS-Anfragen stellen. Alles andere wird geblockt.

Fleet Management: Viele Cluster zentral steuern

Ab dem zweiten Standort stellt sich die Frage: Wie rolle ich Updates ueber alle Edge-Cluster aus? Manuelles kubectl pro Cluster skaliert nicht.

Rancher Fleet ist hier der naheliegendste Ansatz. Fleet ist in Rancher integriert und kann Hunderte von K3s-Clustern ueber GitOps-Bundles verwalten. Alternativ funktioniert Argo CD mit dem ApplicationSet-Controller, der pro Cluster eine Application generiert.

Der entscheidende Punkt: Die Edge-Cluster initiieren die Verbindung zum Management-Cluster, nicht umgekehrt. Das ist wichtig, weil Edge-Cluster hinter NAT oder Firewalls stehen koennen. In Rancher registriert sich der Edge-Agent beim zentralen Server und haelt eine Websocket-Verbindung offen. Konfigurationsaenderungen werden darüber gepusht.

Offline-Faehigkeit und Store-and-Forward

Edge-Cluster muessen ohne permanente WAN-Verbindung funktionieren. Das betrifft nicht nur die Workloads, sondern auch Kubernetes selbst. K3s ist hier robust: Der Control Plane laeuft weiter, bestehende Pods laufen weiter, nur neue Deployments koennen nicht verteilt werden.

Fuer die Applikationsebene bedeutet das: Jeder Edge-Workload braucht eine lokale Puffer-Strategie. Entweder eine lokale Datenbank (SQLite, embedded PostgreSQL), eine Message Queue (Mosquitto fuer MQTT) oder einfach ein Dateisystem-Buffer.

Wenn die WAN-Verbindung wiederhergestellt ist, muessen die gepufferten Daten in der richtigen Reihenfolge nachgesendet werden. Idempotente APIs auf der Empfaengerseite sind Pflicht, weil Duplikate bei Reconnects unvermeidlich sind.

Monitoring am Edge

Prometheus laeuft auch auf Edge-Knoten, allerdings mit reduzierter Retention. 24 Stunden lokale Speicherung reichen in der Regel aus. Langfristige Metriken werden ueber Remote Write an eine zentrale Prometheus/Thanos/Mimir-Instanz geschickt.

Ein haefiger Fehler: Prometheus auf einem Edge-Node mit 2 GB RAM betreiben und 30 Tage Retention konfigurieren. Das fuehrt zu OOM-Kills. Besser: kurze lokale Retention, Remote Write fuer alles, was laenger als einen Tag aufbewahrt werden soll. Mehr zum Thema Monitoring finden Sie unter Kubernetes Observability Stack.

Sicherheit am Edge

Edge-Nodes stehen physisch in der Fertigungshalle, nicht im abgeschlossenen Rechenzentrum. Das erweitert das Bedrohungsmodell um physischen Zugang. Festplattenverschluesselung (LUKS) ist Pflicht. Secure Boot verhindert, dass manipulierte Firmware geladen wird. TPM-Module koennen fuer die Attestation genutzt werden.

Auf Kubernetes-Ebene gelten die ueblichen Regeln: Pod Security Standards auf "restricted" setzen, keine privilegierten Container, Image-Signierung mit Cosign oder Notation. Ausfuehrlicher behandelt in Kubernetes Runtime Security.

Hardware-Auswahl fuer Edge-Nodes

Die Hardware muss den Umgebungsbedingungen in der Fertigung standhalten: Staub, Vibrationen, Temperaturschwankungen von 0 bis 50 Grad. Consumer-Hardware faellt hier schnell aus.

Fuer die meisten Anwendungsfaelle reicht ein luefterloses Industrie-PC. GPU-basierte Edge-Server sind nur noetig, wenn Computer-Vision-Modelle lokal laufen sollen. Fuer einfache Schwellwert-basierte Anomalieerkennung genuegt CPU-Inferenz.

Ein oft uebersehener Punkt: Die Speichermedien. SSDs in industriellen Umgebungen sollten Industrial-Grade sein (SLC oder pSLC NAND), weil sie deutlich mehr Schreibzyklen verkraften als Consumer-SSDs. Bei einem Sensor-Collector, der alle 500 ms Daten schreibt, ist die SSD nach ein bis zwei Jahren am Ende, wenn billige TLC-Medien verwendet werden.

Wann lohnt sich Kubernetes am Edge?

Kubernetes am Edge ist kein Selbstzweck. Der Overhead gegenueber einem einfachen Docker-Compose-Setup oder einem nackten Applikations-Binary ist real. K3s macht es leichter, aber nicht kostenlos.

Der Break-even liegt typischerweise bei 3+ Workloads pro Standort oder 3+ Standorten. Wenn Sie an einem einzigen Standort einen einzigen Container betreiben, ist Docker Compose die einfachere Wahl. Sobald Sie mehrere Services orchestrieren, Rolling Updates brauchen, oder Dutzende Standorte konsistent halten muessen, zahlt sich Kubernetes aus.

Weitere Informationen zur Entscheidungsfindung zwischen verschiedenen Container-Plattformen finden Sie unter Container ohne Cloud. Fuer die Integration in bestehende Industrie-4.0-Umgebungen ist auch der Artikel zu OPC UA und Kubernetes relevant.

Fazit

Kubernetes am Edge in der Fertigung ist kein Hype-Thema mehr, sondern etablierte Praxis. K3s macht den Einstieg niedrigschwellig, GitOps-basiertes Fleet Management haelt die Komplexitaet bei vielen Standorten beherrschbar, und die strikte OT/IT-Trennung sorgt dafuer, dass Produktionsnetzwerke sicher bleiben.

Der wichtigste Rat: Fangen Sie klein an. Ein Standort, ein Use Case, ein K3s-Cluster. Wenn das stabil laeuft, skalieren Sie. Nicht umgekehrt.

Wenn Sie vor der Entscheidung stehen, ob und wie Kubernetes in Ihre Fertigungsumgebung passt, stehen wir fuer eine technische Bewertung zur Verfuegung. Melden Sie sich unter /kontakt.