Kubernetes im Maschinenbau: Fernwartung und IoT ohne eigene DevOps-Abteilung

TL;DR

• Maschinenbauer brauchen kein DevOps-Team um Fernwartung und IoT umzusetzen -- ein Managed Kubernetes Partner uebernimmt Betrieb, Updates und Security
• K3s am Edge laeuft auf industrietauglicher Hardware mit 512 MB RAM und verbindet Maschinen per OPC-UA mit der Cloud
• Predictive Maintenance reduziert ungeplante Stillstaende um 30-50% durch Echtzeit-Analyse von Vibrations-, Temperatur- und Druckdaten direkt an der Maschine
• Field Service wird planbar: Techniker wissen vor dem Einsatz, welches Ersatzteil benoetigt wird -- Erstloesungsrate steigt auf ueber 85%
• DSGVO-konform: Sensordaten werden lokal am Edge vorverarbeitet, nur aggregierte Ergebnisse gehen in die Cloud

Warum Maschinenbauer jetzt auf Kubernetes setzen sollten

Der deutsche Maschinenbau steht vor einem Umbruch. Kunden erwarten heute nicht nur eine zuverlaessige Maschine, sondern eine digitale Serviceplattform: Fernwartung, vorausschauende Wartung, automatische Ersatzteilbestellung. Wer das nicht liefert, verliert Auftraege an Wettbewerber, die es tun.

Das Problem: Die meisten Maschinenbauer haben 200 bis 800 Mitarbeiter, eine IT-Abteilung mit 3 bis 8 Personen und keinerlei Erfahrung mit Cloud-Infrastruktur. Kubernetes klingt nach Ueberforderung.

Die Loesung ist einfacher als gedacht: Edge-Kubernetes auf dem Hallenboden kombiniert mit einer Managed Platform in der Cloud. Sie kuemmern sich um Ihre Maschinendaten und Ihre Applikationslogik. Den Rest uebernimmt ein Partner.

Die Architektur: Vom Sensor bis zum Dashboard

Edge-to-Cloud mit K3s und Managed Kubernetes

Produktionshalle (Kunde)          Cloud (Managed Kubernetes)
┌──────────────────────────┐     ┌─────────────────────────────┐
│  Maschine / SPS          │     │  Managed Kubernetes Cluster  │
│  ├── OPC-UA Server       │     │  ├── Fernwartungs-Portal     │
│  ├── Vibrationssensor    │     │  ├── Predictive-Maintenance  │
│  └── Temperatursensor    │     │  ├── Ersatzteil-Service      │
│          │                │     │  ├── Monitoring Dashboard    │
│          ▼                │     │  └── Kundenverwaltung        │
│  ┌────────────────────┐  │     └─────────────┬───────────────┘
│  │  Edge-Gateway       │  │                   │
│  │  (K3s, 2 GB RAM)   │──┼───── VPN/MQTT ────┘
│  │  ├── OPC-UA Client  │  │
│  │  ├── Datenfilterung │  │
│  │  └── Lokale Analyse │  │
│  └────────────────────┘  │
└──────────────────────────┘

Die Trennung ist entscheidend: Am Edge laeuft nur das Noetigste. Alles, was Rechenleistung und Wartung braucht, laeuft in der Managed Cloud.

OPC-UA-Daten in Kubernetes einlesen

OPC-UA ist der Standard fuer Maschinenkommunikation. Die Herausforderung: OPC-UA-Daten muessen zuverlaessig in Ihre Cloud-Plattform gelangen. Hier ein Beispiel, wie ein OPC-UA-Collector als Kubernetes-Deployment auf dem Edge-Gateway laeuft.

Edge-Deployment: OPC-UA Collector

# opcua-collector-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: opcua-collector
  namespace: edge-gateway
spec:
  replicas: 1
  selector:
    matchLabels:
      app: opcua-collector
  template:
    metadata:
      labels:
        app: opcua-collector
    spec:
      containers:
      - name: collector
        image: registry.internal/opcua-collector:2.4.1
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "250m"
        env:
        - name: OPCUA_ENDPOINT
          value: "opc.tcp://192.168.1.10:4840"
        - name: MQTT_BROKER
          value: "mqtt://mqtt-broker.edge-gateway.svc:1883"
        - name: POLL_INTERVAL_MS
          value: "1000"
        - name: SECURITY_MODE
          value: "SignAndEncrypt"
        volumeMounts:
        - name: opcua-certs
          mountPath: /etc/opcua/certs
          readOnly: true
      volumes:
      - name: opcua-certs
        secret:
          secretName: opcua-client-certs

Dieses Deployment pollt einmal pro Sekunde die relevanten OPC-UA-Nodes, transformiert die Daten und sendet sie per MQTT an den Cloud-Cluster. Die Zertifikate fuer die verschluesselte OPC-UA-Verbindung liegen als Kubernetes Secret vor.

Predictive Maintenance: Ungeplante Stillstaende vermeiden

Wie es funktioniert

Die Edge-Komponente sammelt Rohdaten (Vibration, Temperatur, Druck, Stromaufnahme) und fuehrt eine lokale Vorverarbeitung durch: Mittelwerte, Standardabweichungen, FFT-Spektren. Nur die aufbereiteten Features gehen an die Cloud, wo ein Machine-Learning-Modell den Zustand bewertet.

Cloud-Deployment: Predictive Maintenance Service

# predictive-maintenance-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: predictive-maintenance
  namespace: maschinenbau-platform
spec:
  replicas: 2
  selector:
    matchLabels:
      app: predictive-maintenance
  template:
    metadata:
      labels:
        app: predictive-maintenance
    spec:
      containers:
      - name: ml-inference
        image: registry.internal/pred-maintenance:1.8.0
        resources:
          requests:
            memory: "512Mi"
            cpu: "500m"
          limits:
            memory: "1Gi"
            cpu: "1000m"
        env:
        - name: MODEL_PATH
          value: "/models/vibration-anomaly-v3"
        - name: ALERT_THRESHOLD
          value: "0.85"
        - name: DB_CONNECTION
          valueFrom:
            secretKeyRef:
              name: timescaledb-credentials
              key: connection-string
        volumeMounts:
        - name: ml-models
          mountPath: /models
          readOnly: true
      volumes:
      - name: ml-models
        persistentVolumeClaim:
          claimName: ml-models-pvc
---
apiVersion: v1
kind: Service
metadata:
  name: predictive-maintenance
  namespace: maschinenbau-platform
spec:
  selector:
    app: predictive-maintenance
  ports:
  - port: 8080
    targetPort: 8080

Wenn der Anomalie-Score ueber 0.85 steigt, wird automatisch ein Wartungsticket erstellt und der zustaendige Techniker informiert. Der Techniker sieht im Dashboard: Welche Maschine, welche Komponente, welches Ersatzteil.

Vergleich: Eigenentwicklung vs. Managed Platform

Die Rechnung ist eindeutig: Maschinenbauer sind Maschinenbauer, keine IT-Dienstleister. Ihre Entwickler sollen bessere Algorithmen fuer die Vibrations-Analyse schreiben, nicht Kubernetes-Cluster patchen.

Typisches Vorgehen: Vom Konzept zur Fernwartungsplattform

Phase 1: Proof of Concept (4 Wochen)

Woche 1-2: Infrastruktur-Setup
├── Managed Kubernetes Cluster aufsetzen (DE-Rechenzentrum)
├── K3s Edge-Gateway auf Testmaschine installieren
├── VPN-Tunnel zwischen Edge und Cloud etablieren
└── MQTT-Broker deployen

Woche 3-4: Erste Daten-Pipeline
├── OPC-UA Collector konfigurieren (Ihre Maschinentypen)
├── Daten in TimescaleDB speichern
├── Erstes Grafana-Dashboard aufbauen
└── Demo mit echten Maschinendaten

Phase 2: Ausbau (6-8 Wochen)

Fernwartungs-Portal:
├── Web-Frontend fuer Ihre Kunden
├── Echtzeit-Maschinenansicht
├── Remote-Diagnose und Parameteraenderung
└── Rollenkonzept (Bediener, Wartung, Admin)

Predictive Maintenance:
├── ML-Modell trainieren (historische Daten)
├── Anomalie-Erkennung aktivieren
├── Alerting-Regeln definieren
└── Field-Service-Integration

Phase 3: Rollout (fortlaufend)

Jede weitere Maschine bekommt ein Edge-Gateway mit vorkonfiguriertem K3s-Image. Einschalten, Netzwerk verbinden, fertig. Die Registrierung am Cloud-Cluster erfolgt automatisch.

Kosten: Was eine Fernwartungsplattform wirklich kostet

Managed Platform fuer einen Maschinenbauer mit 200 Maschinen im Feld

Monatliche Kosten:
├── Managed Kubernetes Cluster (Cloud):     2.500 EUR/Monat
├── 200 Edge-Gateways (K3s Management):       800 EUR/Monat
├── TimescaleDB (Managed):                    400 EUR/Monat
├── Monitoring, Logging, Alerting:            300 EUR/Monat
├── Backup und Disaster Recovery:             200 EUR/Monat
└── 24/7 Support:                             800 EUR/Monat
─────────────────────────────────────────────────────────────
GESAMT:                                     5.000 EUR/Monat

Pro Maschine:                                  25 EUR/Monat

25 EUR pro Maschine pro Monat. Das koennen Sie Ihren Kunden als Wartungsvertrag weiterberechnen -- die meisten zahlen gerne 50 bis 100 EUR pro Monat fuer vorausschauende Wartung und schnelleren Service. Ihre Fernwartungsplattform wird zum Profitcenter.

Sicherheit: Maschinen im Feld absichern

Maschinen im Feld stehen in fremden Netzwerken. Sicherheit ist keine Option, sondern Pflicht.

Besonders wichtig: Die Edge-Gateways duerfen niemals direkt aus dem Internet erreichbar sein. Der VPN-Tunnel wird immer vom Gateway nach aussen aufgebaut, nie umgekehrt.

Haeufige Fragen von Maschinenbauern

Brauchen wir wirklich Kubernetes? Reicht nicht ein einfacher MQTT-Broker?

Fuer 5 Maschinen reicht ein MQTT-Broker auf einem Raspberry Pi. Aber ab 50 Maschinen brauchen Sie: automatische Updates, Monitoring, Alerting, Zugriffssteuerung, Skalierung, Backup. Das einzeln zusammenzubauen kostet mehr als eine Managed Kubernetes Platform.

Was passiert, wenn das Internet am Maschinenstandort ausfaellt?

Die Edge-Komponente arbeitet autonom weiter. Sensordaten werden lokal gepuffert (bis zu 72 Stunden je nach Konfiguration). Sobald die Verbindung steht, werden die Daten nachsynchronisiert. Die Maschine laeuft normal weiter.

Koennen unsere Kunden die Daten selbst einsehen?

Ja. Das Fernwartungs-Portal hat ein Rollenkonzept. Ihre Kunden sehen ihre eigenen Maschinen, Zustandsdaten und Wartungshistorie. Sie als Hersteller sehen alle Maschinen und koennen per Fernzugriff diagnostizieren.

Weiterführende Artikel

• K3s vs MicroK8s: Edge-Kubernetes fuer IoT und Industrie 4.0
• Kubernetes Vendor Lock-in vermeiden: Cloud-Exit-Strategie
• Kubernetes Managed Service vs. Inhouse: Der ehrliche Vergleich
• Kubernetes-Betrieb auslagern: Die komplette Checkliste
• Kubernetes Partner in Deutschland: Auswahl-Guide