Veröffentlicht am

Kubernetes Industrie 4.0: Container für Smart Manufacturing

Teilen:
Authors

TL;DR

  • Kubernetes verbindet OT und IT in einer einheitlichen Plattform: Edge-Cluster an der Produktionslinie, zentrale Cluster im Rechenzentrum, synchronisiert ueber GitOps.
  • OPC-UA- und MQTT-Daten werden ueber Sidecar-Container in Kubernetes-Workloads integriert, ohne die Anwendungslogik an Industrieprotokolle zu koppeln.
  • MES-Modernisierung laeuft schrittweise: Legacy-MES-Module werden als Container verpackt und ueber APIs mit neuen Microservices verbunden.
  • Echtzeit-Dashboards mit Grafana und Prometheus zeigen Produktionskennzahlen (OEE, Taktzeit, Ausschussrate) auf Basis von Maschinendaten.
  • Predictive Maintenance mit ML-Modellen auf Kubernetes reduziert ungeplante Stillstaende um 20-40 Prozent in typischen Mittelstands-Szenarien.

Ausgangslage: Warum Industrie 4.0 auf Kubernetes setzt

Die vierte industrielle Revolution dreht sich um die Vernetzung von Maschinen, Sensoren und IT-Systemen. In der Praxis scheitern viele Industrie-4.0-Projekte nicht an fehlender Technologie, sondern an der Integrations-Komplexitaet. SPS-Steuerungen sprechen OPC-UA, das MES laeuft auf einem Windows-Server aus 2014, und die Cloud-Analyseplattform erwartet REST-APIs.

Kubernetes loest dieses Problem als einheitliche Laufzeitumgebung. Auf der gleichen Plattform laufen OPC-UA-Adapter, MQTT-Broker, Datenbanken, ML-Inference-Services und Web-Dashboards. Jede Komponente ist ein Container, jede Verbindung ist deklarativ konfiguriert, und alles laesst sich ueber GitOps reproduzierbar deployen.

Fuer den deutschen Mittelstand ist das besonders relevant: Die meisten Fertigungsunternehmen haben gewachsene IT-Landschaften mit dutzenden Inselloesungen. Kubernetes wird nicht alles auf einmal ersetzen, aber es liefert die Plattform, auf der alte und neue Systeme koexistieren koennen.

Referenzarchitektur: Edge-to-Cloud fuer die Smart Factory

Eine praxistaugliche Industrie-4.0-Architektur besteht aus drei Schichten.

Edge Layer (Hallenboden). K3s-Cluster direkt an der Produktionslinie. Hier laufen zeitkritische Workloads: Maschinenanbindung ueber OPC-UA, lokale Datenvorverarbeitung, Echtzeit-Qualitaetskontrolle. Typische Hardware: Industrierechner mit 4-8 GB RAM, optional NVIDIA Jetson fuer GPU-Inference.

Plant Layer (Werksrechenzentrum). Ein vollwertiger Kubernetes-Cluster im lokalen Rechenzentrum des Werks. Hier laufen das MES, Datenbanken (TimescaleDB, PostgreSQL), der MQTT-Broker (EMQX oder Mosquitto) und Monitoring-Stacks. Dieser Cluster hat 5-20 Nodes je nach Werksgroesse.

Cloud Layer (optional). Fuer uebergreifende Analysen, Data Lakes und Machine-Learning-Training. Kann ein Managed Kubernetes bei einem EU-Cloud-Anbieter sein oder ein zentraler On-Premise-Cluster fuer Multi-Werk-Szenarien.

Die Synchronisierung zwischen den Schichten laeuft ueber ArgoCD (GitOps fuer Deployments) und MQTT/NATS (fuer Datenstroeme). Wenn die Verbindung zwischen Edge und Plant Layer unterbrochen wird, laufen die Edge-Workloads autonom weiter. Mehr zur Edge-Architektur findet sich unter Kubernetes Edge Computing.

OPC-UA-Integration: Maschinendaten in Kubernetes

OPC-UA ist der Industriestandard fuer die Kommunikation zwischen Maschinen und uebergeordneten Systemen. Eine SPS von Siemens, Beckhoff oder B&R stellt einen OPC-UA-Server bereit, der Prozessdaten (Temperaturen, Drehzahlen, Stueckzahlen) als Nodes exponiert.

In Kubernetes laeuft die OPC-UA-Anbindung als Sidecar-Container neben der eigentlichen Anwendung. Der Sidecar liest OPC-UA-Nodes aus und publiziert die Werte als MQTT-Messages oder stellt sie ueber eine REST-API bereit.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: machine-connector
  namespace: shopfloor
  labels:
    app: machine-connector
    line: assembly-01
spec:
  replicas: 1
  selector:
    matchLabels:
      app: machine-connector
  template:
    metadata:
      labels:
        app: machine-connector
        line: assembly-01
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "9090"
    spec:
      containers:
      - name: opcua-adapter
        image: registry.internal/shopfloor/opcua-adapter:1.3.0
        ports:
        - containerPort: 9090
          name: metrics
        env:
        - name: OPCUA_ENDPOINT
          value: "opc.tcp://192.168.10.50:4840"
        - name: OPCUA_SECURITY_MODE
          value: "SignAndEncrypt"
        - name: MQTT_BROKER
          value: "tcp://emqx.messaging.svc.cluster.local:1883"
        - name: MQTT_TOPIC_PREFIX
          value: "factory/line-01/machine-03"
        - name: POLL_INTERVAL_MS
          value: "500"
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"
          limits:
            cpu: "500m"
            memory: "256Mi"
        volumeMounts:
        - name: opcua-certs
          mountPath: /certs
          readOnly: true
      - name: data-processor
        image: registry.internal/shopfloor/data-processor:2.1.0
        ports:
        - containerPort: 8080
          name: http
        env:
        - name: MQTT_BROKER
          value: "tcp://emqx.messaging.svc.cluster.local:1883"
        - name: MQTT_SUBSCRIBE_TOPIC
          value: "factory/line-01/machine-03/#"
        - name: TIMESCALEDB_URL
          value: "postgresql://tsdb.databases.svc.cluster.local:5432/shopfloor"
        resources:
          requests:
            cpu: "200m"
            memory: "256Mi"
          limits:
            cpu: "1"
            memory: "512Mi"
      volumes:
      - name: opcua-certs
        secret:
          secretName: opcua-client-certs

Wichtige Design-Entscheidungen in diesem Manifest:

Zwei Container, eine Aufgabe. Der OPC-UA-Adapter kuemmert sich ausschliesslich um das Industrieprotokoll. Der Data Processor verarbeitet die MQTT-Messages und schreibt in TimescaleDB. Das entkoppelt Protokoll-Logik von Geschaeftslogik.

MQTT als Zwischenschicht. Statt OPC-UA direkt in die Datenbank zu schreiben, geht der Weg ueber MQTT. Das entkoppelt Producer und Consumer und erlaubt es, weitere Subscriber (Dashboards, ML-Pipelines, Alarmsysteme) ohne Aenderung am Adapter hinzuzufuegen.

OPC-UA mit Verschluesselung. In der Produktion laufen OPC-UA-Verbindungen oft unverschluesselt. Fuer eine Industrie-4.0-Architektur ist SignAndEncrypt Pflicht, besonders wenn die Daten das Hallennetzwerk verlassen. Mehr zu OPC-UA-Best-Practices unter Kubernetes OPC-UA Integration.

MQTT-Broker auf Kubernetes: EMQX Deployment

MQTT ist das Rueckgrat jeder IoT-Architektur. EMQX ist ein MQTT-Broker, der Millionen gleichzeitiger Verbindungen verarbeitet und sich gut in Kubernetes integriert.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: emqx
  namespace: messaging
spec:
  serviceName: emqx-headless
  replicas: 3
  selector:
    matchLabels:
      app: emqx
  template:
    metadata:
      labels:
        app: emqx
    spec:
      containers:
      - name: emqx
        image: emqx/emqx:5.5.1
        ports:
        - containerPort: 1883
          name: mqtt
        - containerPort: 8083
          name: ws
        - containerPort: 18083
          name: dashboard
        env:
        - name: EMQX_CLUSTER__DISCOVERY_STRATEGY
          value: "dns"
        - name: EMQX_CLUSTER__DNS__RECORD_TYPE
          value: "srv"
        - name: EMQX_CLUSTER__DNS__NAME
          value: "emqx-headless.messaging.svc.cluster.local"
        resources:
          requests:
            cpu: "500m"
            memory: "1Gi"
          limits:
            cpu: "2"
            memory: "2Gi"
        volumeMounts:
        - name: emqx-data
          mountPath: /opt/emqx/data
  volumeClaimTemplates:
  - metadata:
      name: emqx-data
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: local-path
      resources:
        requests:
          storage: 10Gi

Das StatefulSet stellt sicher, dass EMQX-Nodes stabile Hostnamen haben, was fuer das Cluster-Discovery ueber DNS notwendig ist. Bei drei Replicas bleibt der Broker verfuegbar, selbst wenn ein Node ausfaellt.

MES-Modernisierung: Schritt fuer Schritt

Das Manufacturing Execution System (MES) ist das zentrale Element der Produktionssteuerung. Die meisten mittelstaendischen Fertigungsunternehmen betreiben ein MES auf einem dedizierten Server, oft monolithisch, oft schlecht dokumentiert.

Eine komplette Neuentwicklung ist unrealistisch. Der pragmatische Weg ist die schrittweise Modernisierung.

PhaseMassnahmeDauer
1. ContainerisierungBestehendes MES als Container verpacken (Lift-and-Shift)2-4 Wochen
2. API-GatewayREST-API vor das Legacy-MES stellen1-2 Wochen
3. DatenextraktionMES-Daten ueber API in TimescaleDB replizieren2-3 Wochen
4. Neue ModuleNeue Funktionen (Dashboards, Alerts) als Microserviceslaufend
5. AbloesungAlte MES-Module durch neue Services ersetzen6-12 Monate

Der Vorteil: Zu keinem Zeitpunkt steht die Produktion still. Altes und neues System laufen parallel, bis alle Funktionen migriert sind. Details zur MES-Integration beschreibt der Artikel Kubernetes MES Integration.

Echtzeit-Dashboards: OEE und Produktionskennzahlen

Overall Equipment Effectiveness (OEE) ist die Kennzahl Nummer eins in der Fertigung. Sie kombiniert Verfuegbarkeit, Leistung und Qualitaet in einem Prozentwert. Mit den Maschinendaten in TimescaleDB lassen sich OEE-Dashboards in Grafana bauen, die in Echtzeit aktualisiert werden.

# TimescaleDB als Datenquelle in Grafana hinzufuegen
# Beispiel-Query fuer OEE-Berechnung pro Schicht

# Verfuegbarkeit = Laufzeit / Geplante Produktionszeit
# Leistung = Ist-Stueckzahl / Soll-Stueckzahl
# Qualitaet = Gutteile / Gesamtteile
# OEE = Verfuegbarkeit * Leistung * Qualitaet

# Grafana Dashboard provisionieren
kubectl apply -f - <<YAMLEOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: grafana-dashboard-oee
  namespace: monitoring
  labels:
    grafana_dashboard: "true"
data:
  oee-dashboard.json: |
    {
      "title": "OEE Dashboard - Linie 01",
      "panels": [
        {
          "title": "OEE Aktuell",
          "type": "gauge",
          "datasource": "TimescaleDB"
        },
        {
          "title": "Verfuegbarkeit (24h)",
          "type": "timeseries",
          "datasource": "TimescaleDB"
        },
        {
          "title": "Ausschussrate pro Stunde",
          "type": "barchart",
          "datasource": "TimescaleDB"
        }
      ]
    }
YAMLEOF

Typische Kennzahlen, die auf dem Dashboard erscheinen:

KennzahlQuelleAktualisierung
OEE (gesamt)Berechnet aus Verfuegbarkeit, Leistung, Qualitaetalle 60 Sekunden
TaktzeitOPC-UA: Zykluszeit pro Teilalle 5 Sekunden
AusschussrateMES oder Qualitaetspruefungalle 60 Sekunden
MaschinenstatusOPC-UA: Betriebszustandalle 2 Sekunden
EnergieverbrauchModbus/OPC-UA: Leistungsmessungalle 10 Sekunden

Predictive Maintenance auf Kubernetes

Ungeplante Maschinenstillstaende kosten in der Fertigung zwischen 5.000 und 50.000 Euro pro Stunde. Predictive Maintenance analysiert Sensordaten (Vibration, Temperatur, Stromaufnahme) und erkennt Anomalien, bevor ein Ausfall eintritt.

Auf Kubernetes laeuft das als Pipeline:

  1. Datenerfassung -- OPC-UA-Adapter sammeln Sensordaten und publizieren sie ueber MQTT.
  2. Feature Engineering -- Ein Python-Service berechnet aus Rohdaten Features (FFT fuer Vibrationen, gleitende Durchschnitte, Anomalie-Scores).
  3. Inference -- Ein ML-Modell (z.B. Isolation Forest oder LSTM) bewertet die Features und gibt eine Ausfallwahrscheinlichkeit zurueck.
  4. Alerting -- Bei Ueberschreitung eines Schwellwerts wird ein Alert ueber Prometheus Alertmanager oder direkt an das MES gesendet.

Mehr zu Predictive Maintenance im Kontext von Kubernetes beschreibt der Artikel Kubernetes Predictive Maintenance.

Netzwerk-Architektur: OT und IT sicher trennen

Die Trennung von Operational Technology (OT) und Information Technology (IT) ist in der Fertigung Pflicht. Kubernetes Network Policies sind das Werkzeug, um diese Trennung auch innerhalb des Clusters durchzusetzen.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: shopfloor-isolation
  namespace: shopfloor
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          zone: ot-network
    - podSelector:
        matchLabels:
          app: mqtt-bridge
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          zone: ot-network
  - to:
    - namespaceSelector:
        matchLabels:
          name: messaging
    ports:
    - protocol: TCP
      port: 1883

Diese Policy erlaubt Pods im Namespace shopfloor nur Kommunikation innerhalb des OT-Netzwerks und zum MQTT-Broker. Kein direkter Zugriff auf das Internet oder die Buero-IT. Daten, die das OT-Netzwerk verlassen sollen, laufen ueber einen dedizierten MQTT-Bridge-Pod, der als kontrollierter Uebergangspunkt dient.

Kostenrahmen fuer ein Industrie-4.0-Pilotprojekt

PostenGeschaetzter AufwandBeschreibung
Edge-Hardware (2 Nodes)3.000-6.000 EURIndustrierechner mit optionaler GPU
Plant-Cluster (5 Nodes)15.000-25.000 EURServer im Werksrechenzentrum
K3s/Kubernetes Setup5-10 PersonentageInstallation, Konfiguration, GitOps
OPC-UA-Adapter Entwicklung10-15 PersonentageAdapter fuer vorhandene Maschinen
Dashboard-Erstellung3-5 PersonentageGrafana Dashboards fuer OEE und Alerts
Schulung Ops-Team3-5 PersonentageKubernetes-Grundlagen fuer das Betriebsteam
Gesamt (Pilotprojekt)ca. 40.000-80.000 EURFuer eine Fertigungslinie

Der ROI kommt typischerweise ueber drei Hebel: Reduktion ungeplanter Stillstaende (Predictive Maintenance), hoehere Qualitaet durch automatisierte Inspektion, und schnellere Reaktionszeiten durch Echtzeit-Dashboards.

Haeufige Fehler bei Industrie-4.0-Kubernetes-Projekten

Zu gross starten. Das erste Projekt sollte eine einzelne Fertigungslinie mit 2-3 Maschinen abdecken, nicht die gesamte Fabrik. Komplexitaet skaliert exponentiell mit der Anzahl der angebundenen Systeme.

OT-Netzwerk ohne Segmentierung. Kubernetes-Pods, die Maschinendaten verarbeiten, gehoeren in ein separates Netzwerksegment. Ein kompromittierter Container darf niemals direkten Zugriff auf SPS-Steuerungen haben.

Keine Offline-Faehigkeit. Edge-Cluster muessen autonom funktionieren, wenn die Netzwerkverbindung zum Plant-Cluster ausfaellt. Das kommt in Fabrikumgebungen regelmaessig vor (Wartungsfenster, Netzwerkstoerunen). K3s ist darauf ausgelegt, aber die Anwendungen muessen lokale Datenpufferung unterstuetzen.

MES-Anbieter nicht einbeziehen. Viele MES-Anbieter bieten inzwischen containerisierte Versionen ihrer Software an. Bevor Sie einen eigenen Adapter bauen, pruefen Sie, ob der MES-Anbieter eine Kubernetes-faehige Version oder eine dokumentierte API bereitstellt.

Fazit und naechste Schritte

Kubernetes als Plattform fuer Industrie 4.0 ist kein Zukunftsszenario mehr, sondern wird in der Fertigungsindustrie produktiv eingesetzt. Die Kombination aus Edge-Clustern fuer Echtzeit-Verarbeitung, zentralen Clustern fuer Datenanalyse und GitOps fuer reproduzierbare Deployments liefert genau die Infrastruktur, die Smart Manufacturing braucht.

Der empfohlene Einstieg: Ein Pilotprojekt an einer einzelnen Fertigungslinie. OPC-UA-Anbindung fuer 2-3 Maschinen, MQTT als Datentransport, TimescaleDB fuer Zeitreihen und ein Grafana-Dashboard fuer OEE. Wenn das stabil laeuft, kommen Predictive Maintenance, automatisierte Qualitaetskontrolle und weitere Linien dazu.

Weitere Details zur Kubernetes-Nutzung in der Fertigung finden Sie im Artikel Kubernetes in der Produktion.

Fuer eine gemeinsame Bewertung Ihres Industrie-4.0-Vorhabens oder Unterstuetzung beim Aufbau der Kubernetes-Infrastruktur erreichen Sie uns ueber die Kontaktseite.

Kubernetes-Beratung gesucht?

Wir helfen deutschen Unternehmen bei der Kubernetes-Implementierung, Migration und Optimierung. DSGVO-konform und praxiserprobt.

📖 Verwandte Artikel

Weitere interessante Beiträge zu ähnlichen Themen