TL;DR

• Kubernetes in der Fertigung verbindet IT und OT (Operational Technology) auf einer einheitlichen Container-Plattform -- von der Fabrikhalle bis zum Rechenzentrum
• OPC-UA Integration ueber Sidecar-Container entkoppelt Anwendungslogik vom Industrieprotokoll und ermoeglicht standardisierten Maschinenzugriff
• Edge Computing mit K3s bringt Datenverarbeitung direkt an die Produktionslinie -- fuer Latenzanforderungen unter 10ms bei Qualitaetskontrolle und SPS-Anbindung
• Predictive Maintenance auf Kubernetes skaliert ML-Modelle fuer vorausschauende Wartung ueber hunderte Maschinen und reduziert ungeplante Stillstands-Zeiten um 30-50%
• MES-Integration ueber Kubernetes-native APIs modernisiert monolithische Manufacturing Execution Systems schrittweise ohne Produktionsunterbrechung

Kubernetes in der Fertigung: Container-Plattform fuer die moderne Produktion

Fertigungsunternehmen stehen vor einer doppelten Herausforderung: Einerseits muessen bestehende Produktionssysteme zuverlaessig weiterlaufen, andererseits verlangen neue Anforderungen wie Predictive Maintenance, digitale Zwillinge und KI-gestuetzte Qualitaetskontrolle eine moderne IT-Plattform. Kubernetes schliesst diese Luecke.

Dieser Guide richtet sich an IT-Leiter und DevOps-Teams in produzierenden Unternehmen, die Kubernetes als Plattform fuer Industrie-4.0-Anwendungen evaluieren oder einsetzen wollen. Er zeigt konkrete Architektur-Patterns, Konfigurationen und Integrationsstrategien fuer den Einsatz in der Fertigung.

Warum Kubernetes in der Fertigung?

Das IT/OT-Konvergenz-Problem

Traditionell sind IT (Information Technology) und OT (Operational Technology) in Fertigungsunternehmen strikt getrennt. IT verwaltet ERP, E-Mail und Business-Anwendungen. OT betreibt SPS-Steuerungen, SCADA-Systeme und MES. Diese Trennung war jahrzehntelang sinnvoll, wird aber zunehmend zum Hindernis:

• Sensordaten aus der Produktion muessen in Echtzeit mit Planungsdaten aus dem ERP verknuepft werden
• ML-Modelle fuer Predictive Maintenance brauchen sowohl historische Produktionsdaten als auch Echtzeit-Sensorwerte
• Qualitaetsdaten muessen automatisch in das QM-System einfliessen
• Digitale Zwillinge benoetigen eine Echtzeit-Verbindung zu physischen Maschinen

Kubernetes bietet eine einheitliche Plattform, auf der IT- und OT-Workloads nebeneinander laufen koennen -- mit strikter Netzwerktrennung, aber auf gemeinsamer Infrastruktur.

Vorteile gegenueber klassischer Industrie-IT

Edge Computing in der Fabrikhalle

Architektur: Hub-and-Spoke mit K3s

Eine typische Fertigungsumgebung besteht aus einem zentralen Kubernetes-Cluster im Rechenzentrum und mehreren Edge-Clustern in der Fabrikhalle:

Fertigungs-Kubernetes-Architektur
├── Zentraler Cluster (Rechenzentrum)
│   ├── ArgoCD (GitOps Control Plane)
│   ├── Prometheus/Grafana (zentrales Monitoring)
│   ├── ML Training Pipelines
│   ├── MES Backend Services
│   └── Data Lake / TimeSeries DB
├── Edge Cluster: Fertigungslinie 1
│   ├── K3s (1-3 Nodes)
│   ├── OPC-UA Connector
│   ├── Qualitaetskontrolle (Inference)
│   └── Lokaler Prometheus Agent
├── Edge Cluster: Fertigungslinie 2
│   ├── K3s (1-3 Nodes)
│   ├── OPC-UA Connector
│   ├── Predictive Maintenance Agent
│   └── Lokaler Prometheus Agent
└── Edge Cluster: Montage
    ├── K3s (1 Node)
    ├── Pick-by-Light Service
    └── Werker-Informationssystem

K3s ist die bevorzugte Distribution fuer Edge-Nodes, weil sie unter 512 MB RAM laeuft und in Sekunden installiert ist. Detaillierte Informationen zu Edge-Computing-Distributionen finden Sie unter Kubernetes Edge Computing.

Edge-Node Hardware fuer die Fabrik

Edge-Nodes in der Fabrikhalle muessen industrietauglich sein:

• Temperaturbereich: 0 bis 50 Grad Celsius (kein Serverraum-Klima)
• Vibrationsfestigkeit: Montage direkt an der Maschine moeglich
• Schutzklasse: Mindestens IP54 gegen Staub und Spritzwasser
• Stromversorgung: 24V DC aus dem Maschinennetzwerk
• Formfaktor: DIN-Hutschiene fuer Schaltschrankeinbau

Gaengige Hardware: Siemens IPC, Beckhoff C6030, NVIDIA Jetson (fuer GPU-Inference), oder Advantech UNO-Serie. K3s laeuft auf all diesen Plattformen, solange ein Linux-Kernel ab Version 5.x verfuegbar ist.

OPC-UA Integration

Sidecar-Pattern fuer Maschinenzugriff

OPC UA (Open Platform Communications Unified Architecture) ist der Standard fuer Maschine-zu-Maschine-Kommunikation in der Industrie. Kubernetes-Workloads greifen ueber ein Sidecar-Pattern auf OPC-UA-Server zu:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: machine-data-collector
  namespace: edge-workloads
  labels:
    app: machine-data-collector
    production-line: "line-1"
spec:
  replicas: 1
  selector:
    matchLabels:
      app: machine-data-collector
  template:
    metadata:
      labels:
        app: machine-data-collector
    spec:
      containers:
        - name: data-processor
          image: registry.internal/data-processor:1.8.0
          ports:
            - containerPort: 8080
          env:
            - name: OPCUA_PROXY_URL
              value: "http://localhost:4840"
            - name: INFLUXDB_URL
              value: "http://influxdb.monitoring:8086"
            - name: SAMPLING_INTERVAL_MS
              value: "100"
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "1"
              memory: "512Mi"
        - name: opcua-sidecar
          image: registry.internal/opcua-connector:2.1.0
          ports:
            - containerPort: 4840
          env:
            - name: OPCUA_SERVER_URL
              value: "opc.tcp://192.168.10.100:4840"
            - name: OPCUA_SECURITY_POLICY
              value: "Basic256Sha256"
            - name: OPCUA_SECURITY_MODE
              value: "SignAndEncrypt"
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"
          volumeMounts:
            - name: opcua-certs
              mountPath: /certs
              readOnly: true
      volumes:
        - name: opcua-certs
          secret:
            secretName: opcua-certificates

Der Sidecar-Container uebersetzt zwischen OPC UA und einer lokalen REST-API. Der Haupt-Container (data-processor) kennt kein OPC UA und spricht nur HTTP. Das entkoppelt die Anwendungslogik vom Industrieprotokoll und macht den data-processor wiederverwendbar fuer verschiedene Maschinen.

Wichtig: OPC-UA-Verbindungen nutzen SignAndEncrypt fuer Authentifizierung und Verschluesselung. Die Zertifikate liegen als Kubernetes Secret vor.

Maschinendaten in die TimeSeries-Datenbank

Gesammelte Maschinendaten (Temperatur, Drehzahl, Vibration, Stromverbrauch) werden in eine TimeSeries-Datenbank geschrieben. InfluxDB oder TimescaleDB auf Kubernetes sind gaengige Loesungen. Von dort speist Grafana die Dashboards fuer die Produktionsleitung.

Predictive Maintenance auf Kubernetes

Architektur: Training und Inference

Predictive Maintenance besteht aus zwei Phasen, die unterschiedliche Kubernetes-Workload-Profile haben:

Training (zentraler Cluster): ML-Modelle werden auf historischen Maschinendaten trainiert. Das ist ein Batch-Workload mit hohem Ressourcenbedarf (GPU, viel RAM). Kubernetes Jobs oder Argo Workflows orchestrieren das Training.

Inference (Edge-Cluster): Das trainierte Modell laeuft auf dem Edge-Node an der Maschine. Es empfaengt Echtzeit-Sensordaten und gibt Vorhersagen aus (z.B. "Lager-Verschleiss in 72 Stunden erwartet"). Das ist ein langlebiger, latenz-sensitiver Workload.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: predictive-maintenance
  namespace: edge-workloads
  labels:
    app: predictive-maintenance
    machine-type: "cnc-mill"
spec:
  replicas: 1
  selector:
    matchLabels:
      app: predictive-maintenance
  template:
    metadata:
      labels:
        app: predictive-maintenance
    spec:
      containers:
        - name: inference-engine
          image: registry.internal/pred-maintenance:3.0.2
          ports:
            - containerPort: 8501
          env:
            - name: MODEL_PATH
              value: "/models/bearing-failure-v3.onnx"
            - name: ALERT_THRESHOLD_HOURS
              value: "96"
            - name: DATA_SOURCE
              value: "http://localhost:4840/api/v1/sensors"
          resources:
            requests:
              cpu: "500m"
              memory: "512Mi"
            limits:
              cpu: "2"
              memory: "1Gi"
          volumeMounts:
            - name: model-storage
              mountPath: /models
              readOnly: true
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8501
            initialDelaySeconds: 20
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /ready
              port: 8501
            initialDelaySeconds: 10
            periodSeconds: 5
      volumes:
        - name: model-storage
          persistentVolumeClaim:
            claimName: ml-models-pvc

Das Modell wird als ONNX-Datei auf einem Persistent Volume bereitgestellt. Wenn ein neues Modell trainiert wurde, aktualisiert ArgoCD das Deployment auf allen relevanten Edge-Nodes gleichzeitig.

Modell-Updates ueber GitOps

Der Modell-Update-Workflow:

1. Data Scientists trainieren ein neues Modell im zentralen Cluster
2. Das Modell wird validiert (Accuracy, Precision, Recall)
3. Bei Freigabe wird das Modell in die interne Registry gepusht
4. Der Image-Tag im GitOps-Repository wird aktualisiert
5. ArgoCD synchronisiert alle Edge-Cluster

Dieser Workflow stellt sicher, dass Modell-Updates nachvollziehbar, reproduzierbar und rueckrollbar sind. Mehr zu GitOps-Strategien erfahren Sie unter Kubernetes Security Hardening im Abschnitt zu Change Management.

MES-Integration

Manufacturing Execution System modernisieren

Das MES (Manufacturing Execution System) ist das Rueckgrat der Produktionssteuerung. Es plant Auftraege, verfolgt den Produktionsfortschritt und dokumentiert Qualitaetsdaten. Viele MES-Systeme sind monolithisch und laufen auf dedizierten Servern.

Eine schrittweise Modernisierung mit Kubernetes sieht so aus:

Phase 1: API Gateway vor dem Legacy-MES. Ein Kubernetes-basierter API Gateway stellt eine moderne REST-API bereit, die intern auf das Legacy-MES weiterleitet. Neue Anwendungen (Dashboards, Mobile Apps) nutzen nur noch die neue API.

Phase 2: Einzelne MES-Funktionen als Microservices extrahieren. Starten Sie mit Funktionen, die am haeufigsten geaendert werden (z.B. Qualitaets-Reporting oder Auftragsverfolgung). Diese werden als eigenstaendige Kubernetes-Deployments betrieben und ueber die API integriert.

Phase 3: Neue Funktionen nur noch auf Kubernetes. Predictive Maintenance, KI-Qualitaetskontrolle, Echtzeit-Dashboards -- alles, was neu gebaut wird, laeuft auf Kubernetes. Das Legacy-MES schrumpft ueber die Zeit.

Echtzeit-Monitoring der Produktion

Ein Echtzeit-Dashboard fuer die Produktionsleitung kombiniert Daten aus verschiedenen Quellen:

Datenquellen fuer Produktions-Monitoring
├── OPC-UA (Maschinendaten: Drehzahl, Temperatur, Zykluszeit)
├── MES (Auftragsdaten: Soll/Ist, Rueckstau, Qualitaetsrate)
├── ERP (Materialdaten: Bestand, Nachbestellungen)
├── Kubernetes Metriken (Infrastruktur: CPU, Memory, Pod Status)
└── ML-Modelle (Vorhersagen: Wartungsbedarf, Qualitaetstrend)

Prometheus sammelt all diese Metriken. Custom Exporters fuer OPC UA und MES uebersetzen Industrie-Daten in das Prometheus-Format. Grafana stellt sie in Echtzeit dar -- auf grossen Bildschirmen in der Fabrikhalle oder auf Tablets der Schichtleiter. Umfassende Monitoring-Strategien beschreibt unser Guide zu Kubernetes Monitoring und Observability.

Netzwerk-Architektur: IT/OT-Segmentierung

Warum Segmentierung kritisch ist

Die Verbindung von IT und OT bringt Sicherheitsrisiken. Ein kompromittierter Office-PC darf nicht auf SPS-Steuerungen zugreifen koennen. Kubernetes Network Policies allein reichen hier nicht aus -- die Segmentierung muss auf Netzwerkebene beginnen.

Netzwerk-Zonen in der Fertigung
├── Zone 1: Enterprise IT (10.0.0.0/16)
│   ├── ERP, E-Mail, Office
│   └── K8s: Business Applications
├── Zone 2: DMZ (10.1.0.0/16)
│   ├── API Gateways
│   └── K8s: Integration Services
├── Zone 3: Production IT (10.2.0.0/16)
│   ├── MES, SCADA HMI
│   └── K8s: Production Applications
├── Zone 4: Production OT (10.3.0.0/16)
│   ├── SPS, Sensoren, Aktoren
│   └── K3s Edge Nodes
└── Firewall Rules:
    Zone 1 -- Zone 3: nur ueber Zone 2 (DMZ)
    Zone 3 -- Zone 4: definierte Ports (OPC-UA 4840)
    Zone 1 -- Zone 4: KEIN direkter Zugriff

Kubernetes-Cluster in Zone 3 koennen ueber OPC UA auf Maschinen in Zone 4 zugreifen, aber nur ueber definierte Ports. Enterprise-IT in Zone 1 hat keinen direkten Zugriff auf OT-Systeme.

Ausfallsicherheit in der Produktion

Was passiert, wenn der Edge-Node ausfaellt?

Ein Edge-Node in der Fabrik kann durch Hardwaredefekt, Stromausfall oder Netzwerkprobleme ausfallen. Die Produktionslinie muss trotzdem weiterlaufen.

Strategie 1: Redundante Edge-Nodes. Zwei K3s-Nodes pro Fertigungslinie. Kubernetes verteilt die Pods automatisch auf beide Nodes. Faellt einer aus, uebernimmt der andere.

Strategie 2: Graceful Degradation. Wenn der Edge-Node fuer Predictive Maintenance ausfaellt, laeuft die Produktion trotzdem weiter -- nur ohne Vorhersagen. Die Maschinen-Steuerung (SPS) ist unabhaengig vom Edge-Node.

Strategie 3: Offline-Faehigkeit. K3s laeuft autonom weiter, auch wenn die Verbindung zum zentralen Cluster abbricht. Maschinendaten werden lokal gepuffert und synchronisiert, sobald die Verbindung wieder steht.

Detaillierte Backup- und Recovery-Strategien finden Sie unter Kubernetes Backup und Disaster Recovery.

Haeufige Fehler bei Kubernetes in der Fertigung

Kubernetes fuer SPS-Steuerung einsetzen: Kubernetes ist nicht fuer harte Echtzeit-Anforderungen geeignet. SPS-Steuerungen muessen weiterhin auf dedizierter Hardware mit deterministischem Zeitverhalten laufen. Kubernetes uebernimmt die Datenverarbeitung und Analytik -- nicht die Maschinensteuerung.

Edge-Nodes ohne Monitoring: Ein Edge-Node in der Fabrikhalle ist kein Fire-and-Forget-System. Installieren Sie mindestens einen Prometheus-Agent, der Metriken an den zentralen Cluster pushed. Ohne Monitoring bemerken Sie Probleme erst, wenn die Produktion steht.

Flat Network zwischen IT und OT: Ohne Netzwerksegmentierung kann ein Ransomware-Angriff auf die Office-IT die gesamte Produktion lahmlegen. Das ist kein theoretisches Szenario -- es passiert regelmaessig.

Kein Change Management fuer Edge-Updates: Ein fehlerhaftes Update auf einem Edge-Node kann eine Fertigungslinie stoppen. Nutzen Sie Canary Deployments: Erst eine Linie aktualisieren, validieren, dann die naechste.

Ueberdimensionierte Edge-Cluster: Nicht jeder Use Case braucht einen 3-Node-Cluster. Ein einzelner K3s-Node reicht oft fuer eine Fertigungslinie. Starten Sie klein und skalieren Sie bei Bedarf.

Checkliste: Kubernetes in der Fertigung

Fazit

Kubernetes bringt Cloud-Native-Konzepte in die Fabrikhalle. Die Kombination aus zentralem Cluster im Rechenzentrum und K3s-Edge-Nodes an der Produktionslinie ermoeglicht Use Cases wie Predictive Maintenance, KI-Qualitaetskontrolle und Echtzeit-Monitoring, die mit klassischer Industrie-IT schwer umsetzbar waeren.

Der wichtigste Grundsatz: Kubernetes ersetzt keine SPS-Steuerung und kein bewaehertes SCADA-System. Es ergaenzt die bestehende OT-Infrastruktur um eine Plattform fuer Datenverarbeitung, Analytik und moderne Anwendungen. Starten Sie mit einem ueberschaubaren Pilotprojekt -- etwa Maschinendaten-Erfassung und Visualisierung fuer eine einzelne Fertigungslinie -- und erweitern Sie von dort.

Wenn Sie Unterstuetzung bei der Planung Ihrer Kubernetes-Strategie fuer die Fertigung suchen, kontaktieren Sie uns unter /kontakt.