Predictive Maintenance auf Kubernetes: Architektur, Tooling und Praxisbeispiele

TL;DR

• Eine Predictive-Maintenance-Pipeline besteht aus vier Schichten: Ingestion, Processing, Training, Serving. Kubernetes orchestriert alle vier als Microservices.
• K3s auf Edge-Gateways sammelt Sensordaten lokal vor, bevor sie per MQTT oder Kafka an den zentralen Cluster gehen.
• Kubeflow Pipelines automatisiert das Modell-Training, Seldon Core uebernimmt das Serving mit A/B-Testing und Canary Rollouts.
• Resource Requests und Limits fuer GPU-Workloads sind Pflicht, sonst kannibalisieren sich Training- und Inference-Jobs gegenseitig.
• Ein realistischer Zeitrahmen fuer einen MVP liegt bei 8-12 Wochen, wenn die Sensorik bereits installiert ist.

Das Problem mit reaktiver Wartung

Die meisten Unternehmen betreiben ihre Anlagen entweder reaktiv (reparieren nach Ausfall) oder intervallbasiert (feste Wartungszyklen unabhaengig vom Zustand). Beide Ansaetze sind teuer.

Reaktive Wartung fuehrt zu ungeplanten Stillstaenden. Bei intervallbasierter Wartung tauschst du Komponenten aus, die noch Monate haetten laufen koennen. Predictive Maintenance loest das, indem Sensordaten kontinuierlich analysiert werden und ein ML-Modell den optimalen Wartungszeitpunkt vorhersagt.

Kubernetes ist dafuer die richtige Plattform, weil die gesamte Pipeline aus heterogenen Workloads besteht: Streaming-Jobs fuer die Datenverarbeitung, Batch-Jobs fuer das Training, und Low-Latency-Services fuer die Inferenz. All das laesst sich in einem Cluster orchestrieren.

Architektur im Ueberblick

Die Pipeline hat vier Schichten, die jeweils als eigenstaendige Deployments im Cluster laufen.

Schicht 1 -- Ingestion: Sensoren liefern Daten ueber MQTT an einen Broker (z.B. EMQX oder Mosquitto als StatefulSet). Von dort gehen die Daten in Apache Kafka. Alternativ koennen Edge-Gateways mit K3s eine Vorverarbeitung durchfuehren und nur aggregierte Werte weiterleiten.

Schicht 2 -- Processing: Apache Flink oder Spark Structured Streaming liest aus Kafka-Topics, fuehrt Feature Engineering durch (Rolling Averages, FFT fuer Vibrationsdaten) und schreibt die Ergebnisse in eine Zeitreihendatenbank wie TimescaleDB.

Schicht 3 -- Training: Kubeflow Pipelines orchestriert das Modell-Training. Typische Modelle sind Isolation Forest fuer Anomalieerkennung oder LSTMs fuer Zeitreihenprognosen. Das Training laeuft als Kubernetes Job mit GPU-Requests.

Schicht 4 -- Serving: Trainierte Modelle werden ueber Seldon Core als REST/gRPC-Endpoints bereitgestellt. Neue Sensorwerte kommen rein, eine Vorhersage geht raus. Prometheus scrapt die Inference-Metriken.

Kafka und Flink als Deployment

Das folgende YAML zeigt ein minimales Kafka-Cluster mit KRaft (ohne ZooKeeper) und einen Flink JobManager. In der Praxis wuerdest du den Strimzi Operator fuer Kafka verwenden, aber fuer das Verstaendnis hilft ein direktes Deployment.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: kafka
  namespace: predictive-maintenance
spec:
  serviceName: kafka-headless
  replicas: 3
  selector:
    matchLabels:
      app: kafka
  template:
    metadata:
      labels:
        app: kafka
    spec:
      containers:
        - name: kafka
          image: bitnami/kafka:3.7
          ports:
            - containerPort: 9092
              name: plaintext
            - containerPort: 9093
              name: controller
          env:
            - name: KAFKA_CFG_PROCESS_ROLES
              value: "broker,controller"
            - name: KAFKA_CFG_LISTENERS
              value: "PLAINTEXT://:9092,CONTROLLER://:9093"
          resources:
            requests:
              cpu: "500m"
              memory: "1Gi"
            limits:
              cpu: "2"
              memory: "4Gi"
          volumeMounts:
            - name: kafka-data
              mountPath: /bitnami/kafka
  volumeClaimTemplates:
    - metadata:
        name: kafka-data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 50Gi
---
apiVersion: v1
kind: Service
metadata:
  name: kafka-headless
  namespace: predictive-maintenance
spec:
  clusterIP: None
  selector:
    app: kafka
  ports:
    - port: 9092
      name: plaintext
    - port: 9093
      name: controller

Der Strimzi Operator ist fuer Produktionsumgebungen die bessere Wahl, weil er Rolling Updates, Rack Awareness und automatische Rebalancing unterstuetzt. Mehr dazu, wie du Operatoren in Produktionsclustern einsetzt, findest du unter /blog/kubernetes-cluster-setup-production.

Modell-Serving mit Seldon Core

Nach dem Training exportierst du das Modell als ONNX- oder Pickle-Datei in einen S3-kompatiblen Object Store (MinIO laeuft prima auf Kubernetes). Seldon Core deployed das Modell als Inference-Service.

apiVersion: machinelearning.seldon.io/v1
kind: SeldonDeployment
metadata:
  name: vibration-anomaly-detector
  namespace: predictive-maintenance
spec:
  predictors:
    - name: default
      replicas: 2
      graph:
        name: classifier
        implementation: SKLEARN_SERVER
        modelUri: s3://models/vibration-anomaly/v3
        envSecretRefName: seldon-s3-secret
      componentSpecs:
        - spec:
            containers:
              - name: classifier
                resources:
                  requests:
                    cpu: "250m"
                    memory: "512Mi"
                  limits:
                    cpu: "1"
                    memory: "1Gi"
    - name: canary
      replicas: 1
      traffic: 10
      graph:
        name: classifier
        implementation: SKLEARN_SERVER
        modelUri: s3://models/vibration-anomaly/v4
        envSecretRefName: seldon-s3-secret

In diesem Setup gehen 90% des Traffics an das stabile v3-Modell und 10% an das neue v4-Modell. Du kannst die Verteilung schrittweise verschieben, waehrend du die Accuracy-Metriken in Grafana beobachtest. Falls v4 schlechtere Ergebnisse liefert, rollst du zurueck, ohne dass die Produktion betroffen ist. Fuer detailliertere Canary-Strategien siehe /blog/kubernetes-canary-deployment-deutschland.

Edge-Vorverarbeitung mit K3s

Nicht alle Sensordaten muessen in den zentralen Cluster. Vibrationssensoren erzeugen oft mehrere tausend Samples pro Sekunde. Das roh ueber das Netzwerk zu schicken, ist weder praktikabel noch noetig.

Auf dem Edge-Gateway (ein kleiner Industrierechner) laeuft K3s mit einem DaemonSet, das die Rohdaten per FFT in Frequenzspektren umwandelt und nur die relevanten Features an Kafka weitergibt. Ein Bash-Skript fuer die K3s-Installation auf einem Gateway:

#!/bin/bash
# K3s Installation auf ARM64 Edge Gateway
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--disable traefik --disable servicelb" sh -

# Warte bis der Node ready ist
until kubectl get nodes | grep -q " Ready"; do
  sleep 5
done

# Namespace fuer Edge-Workloads
kubectl create namespace edge-processing

# DaemonSet fuer Sensorvorverarbeitung deployen
kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: sensor-preprocessor
  namespace: edge-processing
spec:
  selector:
    matchLabels:
      app: sensor-preprocessor
  template:
    metadata:
      labels:
        app: sensor-preprocessor
    spec:
      containers:
        - name: preprocessor
          image: registry.internal/sensor-preprocessor:1.2.0
          env:
            - name: MQTT_BROKER
              value: "tcp://localhost:1883"
            - name: KAFKA_BROKERS
              value: "kafka.predictive-maintenance.svc:9092"
            - name: SAMPLE_RATE_HZ
              value: "5000"
            - name: FFT_WINDOW_SIZE
              value: "1024"
          resources:
            requests:
              cpu: "200m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"
EOF

echo "Edge-Preprocessing deployed."

Die Reduktion der Datenrate von mehreren Megabytes pro Sekunde auf wenige Kilobytes spart Bandbreite und macht die zentrale Pipeline deutlich schlanker. Mehr zu Edge Computing mit Kubernetes findest du unter /blog/kubernetes-edge-computing.

Tooling-Vergleich

Die Wahl der richtigen Komponenten haengt vom Anwendungsfall und der Teamgroesse ab.

Monitoring der ML-Pipeline

Ein Predictive-Maintenance-System ist nur so gut wie seine Ueberwachung. Du brauchst Metriken auf drei Ebenen:

Infrastruktur-Metriken: CPU, Memory, Disk I/O der Pods. Prometheus mit kube-state-metrics und node-exporter deckt das ab.

Pipeline-Metriken: Kafka Consumer Lag (wie weit hinkt die Verarbeitung hinterher), Flink Checkpoint Duration, Anzahl verarbeiteter Events pro Sekunde. Der Strimzi Operator exportiert Kafka-Metriken direkt nach Prometheus.

Modell-Metriken: Prediction Latency, Accuracy Drift, Feature Distribution Shift. Seldon Core liefert Prometheus-Metriken out of the box. Fuer Drift Detection eignet sich Alibi Detect, das ebenfalls als Sidecar-Container neben dem Modell laufen kann.

Wenn eine dieser Metriken aus dem Ruder laeuft, muss ein Alert ausgeloest werden. Konfiguriere Alertmanager so, dass Pipeline-Probleme das Engineering-Team erreichen und Modell-Drift-Alerts an die Data Scientists gehen. Details zum Aufbau eines Observability-Stacks findest du unter /blog/kubernetes-observability-stack-deutschland.

Haeufige Fehler und wie du sie vermeidest

GPU-Ressourcen nicht limitiert: Ohne explizite GPU-Limits kann ein Training-Job alle GPUs belegen und das Inference-Serving blockieren. Nutze nvidia.com/gpu: 1 in den Resource Limits und separate Node Pools fuer Training und Inference.

Kafka ohne Retention Policy: Sensordaten wachsen schnell. Setze retention.ms und retention.bytes auf Kafka-Topics, sonst laeuft dir der Storage voll. Bei 10 Sensoren mit 1 kHz Samplerate fallen pro Tag mehrere Gigabyte an.

Modelle nicht versioniert: Jedes Modell braucht eine klare Versionierung. Nutze MLflow oder DVC in Kombination mit dem S3-kompatiblen Storage. Seldon Core unterstuetzt die Angabe einer konkreten modelUri -- nutze das.

Kein Circuit Breaker zwischen Edge und Cloud: Wenn die Verbindung zum zentralen Cluster abbricht, muss das Edge-Gateway Daten lokal puffern. Implementiere einen Retry-Mechanismus mit Backoff und lokaler Persistenz (z.B. SQLite oder ein lokales Kafka-Topic).

Realistische Zeitplanung

Insgesamt dauert es realistisch 8-12 Wochen vom Start bis zum ersten produktiven Modell. Das setzt voraus, dass ein Kubernetes-Cluster bereits laeuft und das Team Erfahrung mit Containern hat. Falls du noch am Anfang stehst, kann der Guide unter /blog/kubernetes-in-30-tagen helfen.

Fazit

Predictive Maintenance auf Kubernetes ist kein Hexenwerk, aber es ist auch kein Wochenendprojekt. Die Architektur besteht aus vielen beweglichen Teilen, von der Sensorik ueber Streaming bis zum ML-Serving. Kubernetes gibt dir die Moeglichkeit, all diese Teile unabhaengig zu deployen, zu skalieren und zu ueberwachen.

Der wichtigste Rat: Starte mit einem einzigen Anlagentyp und einem einfachen Anomalieerkennung-Modell. Komplexitaet kommt von allein, sobald das System produktiv laeuft und weitere Anlagen angebunden werden.

Wenn du Unterstuetzung bei der Architektur oder Implementierung brauchst, melde dich unter /kontakt. Wir helfen Teams dabei, solche Pipelines von der Konzeption bis zum produktiven Betrieb aufzubauen.