- Authors

- Name
- Phillip Pham
- @ddppham
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.
| Phase | Massnahme | Dauer |
|---|---|---|
| 1. Containerisierung | Bestehendes MES als Container verpacken (Lift-and-Shift) | 2-4 Wochen |
| 2. API-Gateway | REST-API vor das Legacy-MES stellen | 1-2 Wochen |
| 3. Datenextraktion | MES-Daten ueber API in TimescaleDB replizieren | 2-3 Wochen |
| 4. Neue Module | Neue Funktionen (Dashboards, Alerts) als Microservices | laufend |
| 5. Abloesung | Alte MES-Module durch neue Services ersetzen | 6-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:
| Kennzahl | Quelle | Aktualisierung |
|---|---|---|
| OEE (gesamt) | Berechnet aus Verfuegbarkeit, Leistung, Qualitaet | alle 60 Sekunden |
| Taktzeit | OPC-UA: Zykluszeit pro Teil | alle 5 Sekunden |
| Ausschussrate | MES oder Qualitaetspruefung | alle 60 Sekunden |
| Maschinenstatus | OPC-UA: Betriebszustand | alle 2 Sekunden |
| Energieverbrauch | Modbus/OPC-UA: Leistungsmessung | alle 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:
- Datenerfassung -- OPC-UA-Adapter sammeln Sensordaten und publizieren sie ueber MQTT.
- Feature Engineering -- Ein Python-Service berechnet aus Rohdaten Features (FFT fuer Vibrationen, gleitende Durchschnitte, Anomalie-Scores).
- Inference -- Ein ML-Modell (z.B. Isolation Forest oder LSTM) bewertet die Features und gibt eine Ausfallwahrscheinlichkeit zurueck.
- 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
| Posten | Geschaetzter Aufwand | Beschreibung |
|---|---|---|
| Edge-Hardware (2 Nodes) | 3.000-6.000 EUR | Industrierechner mit optionaler GPU |
| Plant-Cluster (5 Nodes) | 15.000-25.000 EUR | Server im Werksrechenzentrum |
| K3s/Kubernetes Setup | 5-10 Personentage | Installation, Konfiguration, GitOps |
| OPC-UA-Adapter Entwicklung | 10-15 Personentage | Adapter fuer vorhandene Maschinen |
| Dashboard-Erstellung | 3-5 Personentage | Grafana Dashboards fuer OEE und Alerts |
| Schulung Ops-Team | 3-5 Personentage | Kubernetes-Grundlagen fuer das Betriebsteam |
| Gesamt (Pilotprojekt) | ca. 40.000-80.000 EUR | Fuer 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
Kubernetes Industrie 4.0 im deutschen Mittelstand
Kubernetes treibt Industrie 4.0 im deutschen Mittelstand voran: Produktionsautomatisierung, Digital Factory und Smart Manufacturing mit Container-Orchestrierung.
OPC UA auf Kubernetes: Maschinenanbindung am Edge
OPC UA Gateways als Container auf Edge-Kubernetes betreiben: Architektur, Deployment-YAMLs und Daten-Pipeline von der SPS bis zur Zeitreihendatenbank.
Digitaler Zwilling auf Kubernetes: Simulation und Wartung
Digitale Zwillinge auf Kubernetes betreiben: Echtzeit-Synchronisation mit MQTT, GPU-Simulations-Container und Predictive Maintenance in der Fertigung.
Kubernetes Edge Computing: K3s, KubeEdge und Akri
Edge Computing mit Kubernetes umsetzen: K3s, KubeEdge und Akri für IoT-Orchestrierung mit Offline-Fähigkeit und Hub-Spoke-Architektur.
Kubernetes Fernwartung und IoT im Maschinenbau
Fernwartung und IoT für Maschinenbauer mit Kubernetes am Edge: OPC-UA-Integration, Predictive Maintenance und Field Service ohne eigene DevOps-Abteilung.