MES auf Kubernetes: Fertigungs-Microservices mit OPC UA und Kafka betreiben

TL;DR

• Monolithische MES-Systeme lassen sich schrittweise in Microservices zerlegen und auf Kubernetes betreiben, ohne den laufenden Betrieb zu unterbrechen.
• OPC UA dient als Standardprotokoll fuer die Maschinenanbindung; Kafka uebernimmt das Event-Streaming zwischen den Services.
• TimescaleDB (PostgreSQL-Extension) eignet sich als Zeitreihendatenbank fuer Maschinendaten deutlich besser als klassische relationale Datenbanken.
• Kubernetes liefert Self-Healing, Horizontal Pod Autoscaling und Rolling Updates -- Eigenschaften, die fuer Fertigungsumgebungen mit 24/7-Betrieb entscheidend sind.
• Starten Sie mit einem einzelnen Modul (z.B. Maschinendatenerfassung), nicht mit dem gesamten MES.

Warum MES-Systeme modernisiert werden muessen

Klassische MES-Systeme sind haeufig monolithische Anwendungen, die auf einzelnen Windows-Servern laufen. Updates erfordern Wartungsfenster, Skalierung bedeutet groessere Hardware, und die Integration neuer Datenquellen ist aufwaendig.

Das Problem wird greifbar, wenn ein neuer Maschinentyp angebunden werden soll oder ein KI-Modul fuer Predictive Maintenance integriert wird. Beim Monolithen betrifft jede Aenderung das gesamte System. Bei Microservices auf Kubernetes laesst sich ein einzelner Service unabhaengig entwickeln, testen und deployen.

Kubernetes bringt ausserdem Self-Healing mit: Faellt ein Container aus, wird er automatisch neu gestartet. Das ist fuer den 24/7-Betrieb in der Fertigung kein Nice-to-have, sondern eine Grundvoraussetzung.

Architektur: Vom Shop Floor bis zum ERP

Eine praxistaugliche Architektur fuer ein MES auf Kubernetes hat vier Schichten:

Der Datenfluss: Maschinen liefern Daten ueber OPC UA an Edge Gateways. Diese schreiben Events in Kafka-Topics. Die MES-Microservices konsumieren diese Events, verarbeiten sie und persistieren Ergebnisse in TimescaleDB oder PostgreSQL.

OPC UA auf Kubernetes: Maschinendaten einsammeln

OPC UA ist der De-facto-Standard fuer die Kommunikation zwischen Maschinen und IT-Systemen in der Fertigung. Ein OPC UA Client laeuft als Deployment im Cluster und verbindet sich mit den OPC UA Servern auf den Maschinen.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: opcua-collector
  namespace: mes
spec:
  replicas: 2
  selector:
    matchLabels:
      app: opcua-collector
  template:
    metadata:
      labels:
        app: opcua-collector
    spec:
      containers:
        - name: collector
          image: registry.example.com/mes/opcua-collector:1.4.0
          env:
            - name: OPCUA_ENDPOINTS
              valueFrom:
                configMapKeyRef:
                  name: opcua-config
                  key: endpoints
            - name: KAFKA_BROKERS
              value: "kafka-0.kafka.mes.svc:9092,kafka-1.kafka.mes.svc:9092"
            - name: KAFKA_TOPIC
              value: "machine-events"
          resources:
            requests:
              cpu: 100m
              memory: 256Mi
            limits:
              cpu: 500m
              memory: 512Mi
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 15

Der Collector liest Maschinendaten ueber OPC UA Subscriptions und schreibt sie als Events in ein Kafka-Topic. Durch zwei Replicas ist der Collector ausfallsicher -- faellt eine Instanz aus, uebernimmt die andere.

Kafka als Event-Backbone

Kafka entkoppelt die Datenerfassung von der Verarbeitung. Wenn ein MES-Service kurzzeitig nicht verfuegbar ist, gehen keine Daten verloren -- sie werden im Kafka-Topic gepuffert.

Fuer den Betrieb von Kafka auf Kubernetes hat sich der Strimzi Operator bewaehrt. Er verwaltet Kafka-Cluster als Custom Resources:

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: mes-kafka
  namespace: mes
spec:
  kafka:
    version: 3.7.0
    replicas: 3
    listeners:
      - name: internal
        port: 9092
        type: internal
        tls: false
      - name: tls
        port: 9093
        type: internal
        tls: true
    storage:
      type: persistent-claim
      size: 100Gi
      class: fast-ssd
    config:
      offsets.topic.replication.factor: 3
      transaction.state.log.replication.factor: 3
      default.replication.factor: 3
      min.insync.replicas: 2
      log.retention.hours: 168
  zookeeper:
    replicas: 3
    storage:
      type: persistent-claim
      size: 20Gi
      class: fast-ssd

Drei Broker mit Replication Factor 3 und min.insync.replicas: 2 stellen sicher, dass Daten auch bei Ausfall eines Brokers konsistent bleiben. Die Retention von 168 Stunden (7 Tage) gibt genuegend Puffer fuer Wartungsarbeiten.

Fuer die Wahl der richtigen Storage-Klasse lohnt ein Blick auf /blog/kubernetes-storage-deutschland.

MES-Microservices strukturieren

Nicht jedes MES-Modul muss sofort als eigener Microservice laufen. Eine sinnvolle Aufteilung orientiert sich an Bounded Contexts:

Maschinendatenerfassung (MDE): Konsumiert Events aus Kafka, normalisiert Rohdaten, berechnet OEE-Kennzahlen. Schreibt Zeitreihen in TimescaleDB.

Betriebsdatenerfassung (BDE): Erfasst Auftraege, Rueckmeldeungen und Stillstandsgruende. Kommuniziert per REST-API mit dem ERP-System.

Qualitaetsmanagement (QM): Prueft Messwerte gegen Toleranzen, loest Alerts aus, dokumentiert Pruefprotokolle.

Feinplanung: Ordnet Auftraege Maschinen zu, beruecksichtigt Ruestzeiten und Prioritaeten.

Jeder Service hat seine eigene Datenbank (Database per Service Pattern), eigenes Deployment und eigenes Helm-Chart. Die Kommunikation zwischen Services laeuft ueber Kafka-Events (asynchron) oder gRPC-Calls (synchron, wenn noetig).

TimescaleDB fuer Fertigungsdaten

Maschinendaten sind Zeitreihen: Temperaturen, Druecke, Drehzahlen, Stueckzahlen -- alle mit Zeitstempel. TimescaleDB ist eine PostgreSQL-Extension, die genau dafuer optimiert ist. Sie bietet automatische Partitionierung (Hypertables), effiziente Aggregationen und Continuous Aggregates.

Der Vorteil gegenueber reinem PostgreSQL: Queries wie "Durchschnittliche Temperatur pro Maschine pro Stunde der letzten 30 Tage" laufen um Groessenordnungen schneller, weil die Daten nach Zeit partitioniert sind.

TimescaleDB laeuft auf Kubernetes als StatefulSet mit Persistent Volumes. Fuer Produktion sollte ein Operator wie der CloudNativePG Operator eingesetzt werden, der Backups, Failover und Connection Pooling automatisiert.

Netzwerk und Sicherheit: IT/OT-Trennung

Die Integration von IT und OT erfordert strikte Netzwerksegmentierung. Maschinen im OT-Netz sollten niemals direkt mit dem Kubernetes-Cluster kommunizieren. Stattdessen:

1. Edge Gateways stehen in einer DMZ zwischen OT- und IT-Netz.
2. Die Gateways kommunizieren nur ueber definierte Ports mit dem Kafka-Cluster im Kubernetes-Netz.
3. Kubernetes Network Policies beschraenken den Traffic innerhalb des Clusters auf das Noetigste.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-kafka-ingestion-only
  namespace: mes
spec:
  podSelector:
    matchLabels:
      app: mes-kafka
  policyTypes:
    - Ingress
  ingress:
    - from:
        - ipBlock:
            cidr: 10.100.0.0/24  # DMZ-Subnetz der Edge Gateways
      ports:
        - protocol: TCP
          port: 9093  # nur TLS-Listener

Diese NetworkPolicy erlaubt Ingress-Traffic zum Kafka-Cluster ausschliesslich aus dem DMZ-Subnetz und nur auf dem TLS-Port. Weitere Details zur Netzwerksicherheit unter /blog/kubernetes-security-hardening-checkliste.

Monitoring fuer Fertigungsumgebungen

In der Fertigung ist ein Monitoring-Ausfall nicht nur ein IT-Problem -- er kann Produktionsausfaelle verursachen. Das Monitoring-Setup braucht daher eigene Redundanz.

Die wichtigsten Metriken fuer ein MES auf Kubernetes:

• Kafka Consumer Lag: Wie viele Events hat ein Service noch nicht verarbeitet? Steigt der Lag, laeuft etwas schief.
• OPC UA Connection Status: Ist die Verbindung zu jeder Maschine aktiv?
• OEE pro Maschine: Die zentrale Produktionskennzahl.
• Pod Restart Count: Haeufige Restarts deuten auf Speicherlecks oder Konfigurationsfehler hin.
• Latenz der Event-Verarbeitung: Wie lange dauert es von der Maschinenerfassung bis zur Anzeige im Dashboard?

Prometheus mit dem Strimzi-Exporter fuer Kafka-Metriken und Grafana fuer Dashboards ist die Standard-Kombination. Mehr zum Thema unter /blog/opentelemetry-kubernetes-deutschland.

Schrittweise Migration: Wie anfangen?

Der groesste Fehler ist, das gesamte MES auf einmal migrieren zu wollen. Stattdessen:

Phase 1 (Monat 1-2): Maschinendatenerfassung als ersten Microservice aufsetzen. OPC UA Collector und Kafka deployen. Daten in TimescaleDB schreiben. Erstes Grafana-Dashboard fuer OEE bauen.

Phase 2 (Monat 3-4): BDE-Modul als zweiten Service aufbauen. REST-Schnittstelle zum bestehenden ERP anbinden. Das monolithische MES laeuft parallel weiter.

Phase 3 (Monat 5-6): QM-Modul migrieren. Erste KI-Integration (z.B. Anomalie-Erkennung auf Maschinendaten) als separaten Service deployen.

Phase 4 (ab Monat 7): Feinplanung migrieren. Altes MES schrittweise abschalten.

In jeder Phase laeuft das alte System parallel. Erst wenn der neue Service nachweislich stabil ist, wird das entsprechende Modul im alten MES deaktiviert. Einen allgemeinen Migrationsleitfaden finden Sie unter /blog/monolith-microservices-migration-2025.

Horizontal Pod Autoscaling fuer Fertigungs-Workloads

In der Fertigung schwankt die Last stark: Waehrend der Fruehschicht laufen alle Maschinen, nachts nur wenige. Der Horizontal Pod Autoscaler (HPA) skaliert die MES-Services automatisch.

Ein Beispiel fuer den MDE-Service:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: mde-service-hpa
  namespace: mes
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: mde-service
  minReplicas: 2
  maxReplicas: 8
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Pods
      pods:
        metric:
          name: kafka_consumer_lag
        target:
          type: AverageValue
          averageValue: "1000"

Dieser HPA skaliert auf Basis von zwei Metriken: CPU-Auslastung und Kafka Consumer Lag. Wenn der Lag ueber 1000 Events steigt, werden zusaetzliche Pods gestartet, um die Verarbeitung zu beschleunigen. Nachts, wenn weniger Events eintreffen, skaliert der HPA wieder herunter auf die minimalen 2 Replicas.

Die Custom Metric kafka_consumer_lag muss ueber den Prometheus Adapter bereitgestellt werden. Das ist etwas Konfigurationsaufwand, aber der Effekt ist enorm: Die MES-Services passen sich automatisch an das Produktionsvolumen an.

Typische Stolperfallen

Zu fruehe Microservice-Zerlegung: Nicht jedes MES-Modul braucht einen eigenen Service. Wenn zwei Module staendig synchron kommunizieren, gehoeren sie vermutlich zusammen.

OPC UA Timeout-Handling: Maschinen sind keine Cloud-APIs. Verbindungen brechen ab, Timeouts sind laenger, Datenqualitaet schwankt. Bauen Sie robustes Retry- und Circuit-Breaker-Handling ein.

Kafka-Partitionierung falsch gewaehlt: Wenn alle Events einer Maschine in dieselbe Partition gehen, kann ein einzelner Consumer zum Bottleneck werden. Partitionieren Sie nach Maschinen-Gruppe, nicht nach einzelner Maschine.

Kein Backup fuer TimescaleDB: Zeitreihendaten sind schwer rekonstruierbar. Automatisierte Backups mit pgBackRest und regelmessige Restore-Tests sind Pflicht.

Fazit

Ein MES auf Kubernetes zu betreiben ist kein Selbstzweck. Der Mehrwert liegt in der Faehigkeit, einzelne Module unabhaengig zu skalieren, zu aktualisieren und zu erweitern. Kafka als Event-Backbone entkoppelt die Komponenten und macht das System resilient gegen Teilausfaelle.

Der pragmatischste Einstieg: Einen OPC UA Collector mit Kafka und einem einfachen Dashboard aufsetzen. Damit haben Sie in wenigen Wochen den ersten Microservice in Produktion und koennen datenbasiert entscheiden, ob und wie Sie weitere Module migrieren.

Wenn Sie Unterstuetzung bei der Architektur oder Umsetzung brauchen, sprechen Sie uns an unter /kontakt.