OPC UA auf Kubernetes: Maschinenanbindung am Edge fuer Industrie 4.0

TL;DR

• OPC UA ist der Standard fuer maschinenuebergreifende Kommunikation in der Fertigung und loest proprietaere Protokolle (Modbus, S7, Profinet) durch ein einheitliches Datenmodell ab.
• Ein OPC UA Gateway laeuft als Container auf einem Edge-Kubernetes-Cluster (z.B. K3s auf einem Industrie-PC) und uebersetzt Maschinenprotokolle in standardisierte OPC UA Nodes.
• Die Daten fliessen ueber MQTT oder Kafka an eine zentrale Zeitreihendatenbank (InfluxDB, TimescaleDB) und von dort in Dashboards oder ML-Pipelines.
• K3s braucht minimal 512 MB RAM und 1 CPU Core -- das laeuft auf Hardware fuer unter 500 EUR.
• Store-and-Forward am Edge sichert Daten bei Netzwerkausfall. Nichts geht verloren.

Das Grundproblem: Heterogene Maschinenparks

Eine typische Fertigungshalle hat Maschinen aus drei Jahrzehnten. Die CNC-Fraese von 2005 spricht Modbus TCP. Die Spritzgussmaschine von 2015 hat eine Siemens S7-1500 mit Profinet. Die neue Laseranlage von 2024 bringt einen nativen OPC UA Server mit.

All diese Daten manuell abzugreifen -- per USB-Stick, Excel-Sheet oder Ablesen am HMI -- ist langsam, fehleranfaellig und nicht skalierbar. Was fehlt, ist eine einheitliche Schicht, die alle Maschinen auf ein gemeinsames Datenmodell bringt.

Genau das ist der Job von OPC UA: ein offener Standard (IEC 62541), der nicht nur Daten transportiert, sondern auch semantisch beschreibt. Ein Temperaturwert ist nicht nur eine Zahl, sondern traegt Einheit, Zeitstempel, Qualitaetsflag und eine Position im Informationsmodell. Wer tiefer in Edge-Szenarien einsteigen will, findet Grundlagen unter Kubernetes Edge Computing.

Warum Kubernetes am Edge?

Man koennte das OPC UA Gateway auch direkt auf dem Industrie-PC als systemd-Service laufen lassen. Funktioniert, hat aber Nachteile:

• Updates: Ohne Container muss man Pakete manuell aktualisieren, Abhaengigkeiten aufloesen und hoffen, dass nichts bricht.
• Rollbacks: Wenn ein Update fehlschlaegt, gibt es kein sauberes Zurueck.
• Monitoring: Jeder Industrie-PC hat eine eigene Monitoring-Loesung, keine einheitliche Sicht.
• Skalierung: Zehn Maschinen, zehn manuell konfigurierte Server.

Kubernetes (speziell K3s fuer Edge) loest diese Probleme. Deployments sind deklarativ, Rollbacks automatisch, Monitoring per Prometheus einheitlich, und neue Gateways werden per kubectl apply ausgerollt -- nicht per SSH und Bash-Skript.

K3s vs. MicroK8s vs. Vanilla K8s am Edge

Fuer den Edge-Einsatz in der Fertigung ist K3s die klare Empfehlung. Einziges Binary, minimaler Footprint, laeuft stabil auf ARM und x86.

Referenzarchitektur

Die Architektur hat drei Ebenen:

1. Edge Layer (Produktionshalle)

• Industrie-PC mit K3s (z.B. Siemens IPC227E, OnLogic Helix, oder ein einfacher Intel NUC)
• OPC UA Gateway Container: Verbindet sich mit SPSen ueber deren native Protokolle
• MQTT Broker (Mosquitto) fuer lokales Publish/Subscribe
• Lokale Zeitreihen-DB (InfluxDB) als Store-and-Forward-Puffer

2. Transport Layer

• MQTT-Bridge oder Kafka Connect zwischen Edge und Rechenzentrum
• TLS-verschluesselt, optional ueber VPN oder WireGuard
• Bei Netzwerkausfall: Edge speichert lokal, synchronisiert bei Reconnect

3. Central Layer (Rechenzentrum oder Cloud)

• Zentraler Kubernetes-Cluster fuer Datenverarbeitung
• TimescaleDB oder InfluxDB fuer langfristige Speicherung
• Grafana fuer Dashboards und Alerting
• Optional: ML-Pipeline fuer Predictive Maintenance

Deployment: OPC UA Gateway auf K3s

K3s installieren

# K3s auf dem Edge-Node installieren (einziger Befehl)
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--disable traefik --disable servicelb" sh -

# Kubeconfig kopieren fuer kubectl-Zugriff
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml

# Cluster pruefen
kubectl get nodes
# NAME          STATUS   ROLES                  AGE   VERSION
# edge-node-1   Ready    control-plane,master   30s   v1.29.2+k3s1

Traefik und der ServiceLB werden deaktiviert, weil sie am Edge selten gebraucht werden. Das spart Ressourcen.

OPC UA Gateway Deployment

# opcua-gateway.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: shopfloor

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: opcua-gateway-config
  namespace: shopfloor
data:
  gateway.yaml: |
    servers:
      - name: fraese-cnc-01
        protocol: modbus-tcp
        host: 192.168.10.20
        port: 502
        poll_interval_ms: 1000
        registers:
          - address: 40001
            name: spindle_speed
            type: float32
            unit: rpm
          - address: 40003
            name: spindle_temp
            type: float32
            unit: celsius
          - address: 40005
            name: feed_rate
            type: float32
            unit: mm_per_min
      - name: spritzguss-02
        protocol: s7
        host: 192.168.10.30
        rack: 0
        slot: 1
        poll_interval_ms: 500
        variables:
          - address: DB100.DBD0
            name: injection_pressure
            type: real
            unit: bar
          - address: DB100.DBD4
            name: mold_temp
            type: real
            unit: celsius
    opcua_server:
      port: 4840
      security_mode: SignAndEncrypt
      certificate_path: /certs/server.pem
      private_key_path: /certs/server.key
    mqtt:
      broker: mosquitto.shopfloor.svc.cluster.local
      port: 1883
      topic_prefix: factory/machines
      qos: 1

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: opcua-gateway
  namespace: shopfloor
  labels:
    app: opcua-gateway
    component: edge-connector
spec:
  replicas: 1
  selector:
    matchLabels:
      app: opcua-gateway
  template:
    metadata:
      labels:
        app: opcua-gateway
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "9090"
    spec:
      containers:
        - name: gateway
          image: registry.example.com/opcua-gateway:1.4.0
          ports:
            - containerPort: 4840
              name: opcua
            - containerPort: 9090
              name: metrics
          volumeMounts:
            - name: config
              mountPath: /etc/gateway
              readOnly: true
            - name: certs
              mountPath: /certs
              readOnly: true
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 256Mi
          livenessProbe:
            httpGet:
              path: /healthz
              port: 9090
            initialDelaySeconds: 10
            periodSeconds: 30
          readinessProbe:
            httpGet:
              path: /readyz
              port: 9090
            initialDelaySeconds: 5
            periodSeconds: 10
      volumes:
        - name: config
          configMap:
            name: opcua-gateway-config
        - name: certs
          secret:
            secretName: opcua-tls-certs

---
apiVersion: v1
kind: Service
metadata:
  name: opcua-gateway
  namespace: shopfloor
spec:
  selector:
    app: opcua-gateway
  ports:
    - port: 4840
      targetPort: opcua
      name: opcua
    - port: 9090
      targetPort: metrics
      name: metrics
  type: ClusterIP

Ein paar wichtige Entscheidungen in diesem YAML:

• ConfigMap statt Hardcoding: Die Gateway-Konfiguration (welche Maschinen, welche Register) liegt in einer ConfigMap. Aenderungen erfordern nur ein ConfigMap-Update und Pod-Restart, kein neues Image.
• TLS-Zertifikate als Secret: OPC UA unterstuetzt SignAndEncrypt. Die Zertifikate liegen in einem Kubernetes Secret, nicht im Image.
• Liveness und Readiness Probes: Kubernetes erkennt automatisch, wenn das Gateway haengt, und startet es neu.
• Resource Limits: Am Edge ist RAM begrenzt. 256 MB reichen fuer ein Gateway mit 10-20 Maschinen.

Mosquitto MQTT Broker am Edge

# mosquitto.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mosquitto
  namespace: shopfloor
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mosquitto
  template:
    metadata:
      labels:
        app: mosquitto
    spec:
      containers:
        - name: mosquitto
          image: eclipse-mosquitto:2.0
          ports:
            - containerPort: 1883
          volumeMounts:
            - name: data
              mountPath: /mosquitto/data
            - name: config
              mountPath: /mosquitto/config
          resources:
            requests:
              cpu: 50m
              memory: 64Mi
            limits:
              cpu: 200m
              memory: 128Mi
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: mosquitto-data
        - name: config
          configMap:
            name: mosquitto-config

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mosquitto-data
  namespace: shopfloor
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: local-path

---
apiVersion: v1
kind: Service
metadata:
  name: mosquitto
  namespace: shopfloor
spec:
  selector:
    app: mosquitto
  ports:
    - port: 1883
      targetPort: 1883
  type: ClusterIP

Der persistente Storage ist entscheidend fuer Store-and-Forward. Wenn die Verbindung zum zentralen Rechenzentrum ausfaellt, puffert Mosquitto die Messages auf Disk. Bei Reconnect werden sie nachgeliefert. Fuer Storage-Optionen auf Kubernetes siehe Kubernetes Storage fuer Produktionsumgebungen.

Daten-Pipeline: Vom Sensor bis zum Dashboard

Der Datenfluss sieht so aus:

1. SPS/Maschine sendet Daten ueber Modbus/S7/Profinet an das Gateway
2. OPC UA Gateway normalisiert die Daten und published sie als MQTT Messages
3. Mosquitto (Edge) verteilt die Messages lokal und leitet sie an den zentralen Broker weiter
4. Telegraf oder ein MQTT-Consumer schreibt die Daten in InfluxDB oder TimescaleDB
5. Grafana visualisiert Metriken, Trends und Anomalien

Ein typischer MQTT-Topic-Baum:

factory/machines/fraese-cnc-01/spindle_speed    -> 12450.5
factory/machines/fraese-cnc-01/spindle_temp     -> 42.3
factory/machines/fraese-cnc-01/feed_rate        -> 800.0
factory/machines/spritzguss-02/injection_pressure -> 1245.8
factory/machines/spritzguss-02/mold_temp        -> 185.2

Jede Message enthaelt einen JSON-Payload mit Timestamp, Wert, Einheit und Qualitaetsflag. Das ermoeglicht spaeter saubere Aggregation und Anomalie-Erkennung.

Predictive Maintenance: Der eigentliche Mehrwert

Maschinendaten sammeln ist der erste Schritt. Der eigentliche Wert entsteht, wenn man aus den Daten Muster ableitet und drohende Ausfaelle erkennt, bevor sie passieren.

Ein einfaches Beispiel: Die Spindeltemperatur einer CNC-Fraese steigt normalerweise waehrend eines Bearbeitungszyklus um 5-8 Grad und faellt danach zurueck. Wenn die Temperatur ueber mehrere Zyklen kontinuierlich steigt, ohne zurueckzufallen, deutet das auf ein Lagerproblem hin.

Mit den OPC UA Daten in einer Zeitreihendatenbank laesst sich das per Grafana-Alert oder per ML-Modell erkennen. Fuer komplexere Predictive-Maintenance-Szenarien gibt es einen separaten Artikel: Predictive Maintenance mit Kubernetes.

Netzwerk und Sicherheit

Die Trennung von IT und OT (Operational Technology) ist nicht verhandelbar. Das OPC UA Gateway sitzt an der Schnittstelle und muss korrekt abgesichert sein.

Wichtige Massnahmen:

• Netzwerksegmentierung: Der Edge-Cluster steht im OT-Netz. Nur der MQTT-Bridge-Port (z.B. 8883 mit TLS) ist in Richtung IT-Netz geoeffnet. Kein direkter Zugriff von aussen auf die SPSen.
• OPC UA Security: Mindestens SignAndEncrypt (Security Mode 3) verwenden. Zertifikate pro Gateway, nicht ein gemeinsames.
• Kubernetes NetworkPolicies: Im Edge-Cluster nur erlaubte Kommunikationspfade oeffnen (Gateway zu Mosquitto, Mosquitto nach aussen, Prometheus zu allen).
• RBAC: Nur der Operator hat kubectl-Zugriff auf den Edge-Cluster. Maschinenbediener interagieren ueber Grafana-Dashboards, nicht ueber die Kubernetes-API.

Fuer eine weitergehende Absicherung von Kubernetes-Clustern, auch in regulierten Umgebungen, ist Kubernetes Network Security relevant.

Hardware-Empfehlungen fuer den Edge

Gesamtkosten pro Edge-Standort: 400-800 EUR Hardware plus einmalige Einrichtung. Das ist ein Bruchteil der Kosten eines kommerziellen MES-Gateways. Fuer eine haertere Cluster-Konfiguration mit Talos Linux gibt es Details unter Kubernetes mit Talos Linux.

Typische Stolpersteine

Firewalls im OT-Netz: In vielen Betrieben ist das OT-Netz strikt segmentiert. Die Freigabe von Ports (Modbus 502, S7 102, OPC UA 4840) erfordert Abstimmung mit der OT-Abteilung und oft einen Change-Request-Prozess. Planen Sie dafuer mindestens 2-3 Wochen ein.

SPS-Zugriff parallel zum SCADA: Manche SPSen erlauben nur eine begrenzte Anzahl gleichzeitiger Verbindungen. Wenn das SCADA-System bereits verbunden ist, kann eine weitere Verbindung vom OPC UA Gateway die Verbindung destabilisieren. Pruefen Sie vorab die Verbindungslimits.

Zeitstempel-Synchronisation: Maschinendaten sind nur nützlich, wenn die Zeitstempel stimmen. Am Edge laeuft NTP oft nicht sauber. Stellen Sie sicher, dass der Industrie-PC per NTP oder PTP synchronisiert ist, bevor Sie Daten korrelieren.

DNS am Edge: K3s bringt CoreDNS mit, aber wenn der Edge-Cluster keinen Upstream-DNS-Server erreicht, funktionieren externe Auflösungen nicht. Konfigurieren Sie CoreDNS mit einem statischen Upstream oder nutzen Sie IP-Adressen statt Hostnamen fuer externe Ziele.

Fazit

Die Kombination aus OPC UA und Kubernetes am Edge ist technisch ausgereift und wirtschaftlich attraktiv. K3s laeuft stabil auf minimaler Hardware, OPC UA Gateway Container lassen sich deklarativ deployen und aktualisieren, und die Daten-Pipeline ueber MQTT in eine Zeitreihendatenbank ist ein bewaehrtes Pattern.

Der Einstieg ist ein Pilotprojekt mit einer einzelnen Maschine. Zwei bis drei Tage fuer Setup und Konfiguration, dann hat man einen funktionierenden Datenfluss von der SPS bis zum Grafana-Dashboard. Danach ist die Skalierung auf weitere Maschinen inkrementell und vorhersagbar.

Wenn Sie Unterstuetzung bei der Architektur oder Umsetzung eines Edge-Kubernetes-Projekts benoetigen, sprechen Sie uns an unter /kontakt.