Kubernetes Robotik: Edge-Orchestrierung in der Fertigung

TL;DR

• Edge-Kubernetes (k3s oder MicroK8s) laeuft direkt in der Fertigungshalle und haelt Latenzen unter 10ms fuer Steuerungsaufgaben.
• ROS-Nodes lassen sich als einzelne Container betreiben und ueber Kubernetes-Deployments orchestrieren, inklusive Health Checks und automatischem Restart.
• GPU Device Plugins ermoeglichen Container-Zugriff auf NVIDIA-Karten fuer Echtzeit-Bildverarbeitung direkt am Edge.
• DaemonSets eignen sich fuer Hardware-Treiber und OPC-UA-Gateways, die auf jedem Worker Node laufen muessen.
• Der Einstieg funktioniert am besten mit einem nicht-kritischen Pilotprojekt, zum Beispiel einem Vision-System neben einer bestehenden SPS-Steuerung.

Warum Kubernetes in der Robotik Sinn ergibt

In den meisten Fertigungsumgebungen laufen Roboter-Steuerungen auf proprietaeren Controllern mit festem Software-Stack. Updates erfordern Stillstand, Rollbacks sind manuell, und jede Roboterzelle hat ihre eigene Konfiguration. Das fuehrt zu Inkonsistenzen und langen Wartungsfenstern.

Kubernetes loest dieses Problem durch Containerisierung und deklarative Konfiguration. Statt Software direkt auf dem Controller zu installieren, wird sie als Container-Image gebaut, versioniert und ueber Kubernetes-Manifeste ausgerollt. Ein fehlgeschlagener Container wird automatisch neu gestartet, ein schlechtes Update per Rollback in Sekunden zurueckgenommen.

Der Kernvorteil liegt in der Entkopplung: Die physische Hardware (Roboter, Sensoren, Aktoren) bleibt unveraendert. Die Software-Schicht darueber wird portabel, testbar und reproduzierbar. Das ist besonders relevant, wenn mehrere Roboterzellen identische Software in leicht unterschiedlichen Konfigurationen benoetigen.

Edge vs. Cloud: Warum der Cluster in die Halle muss

Robotersteuerungen haben harte Latenzanforderungen. Ein Cloud-Roundtrip von 50-200ms ist fuer die meisten Steuerungsaufgaben inakzeptabel. Deshalb laufen Kubernetes-Cluster fuer Robotik als Edge-Deployments direkt in der Fertigungshalle.

Fuer Edge-Szenarien eignen sich leichtgewichtige Distributionen wie k3s oder MicroK8s. Sie benoetigen weniger Ressourcen als ein vollstaendiges kubeadm-Setup und laufen problemlos auf Industrie-PCs mit 4-8 Cores und 16GB RAM. Mehr zum Thema Edge-Architektur gibt es unter Edge Computing mit Kubernetes.

Architektur: Was in welchen Container gehoert

Eine typische Robotik-Architektur auf Kubernetes teilt sich in vier Schichten:

Steuerung (Control Layer): Motion Controller, Path Planner, PLC-Logic-Wrapper. Diese Container kommunizieren direkt mit der Hardware und benoetigen niedrige Latenzen. Sie laufen als Deployments mit garantierten CPU- und Memory-Ressourcen.

Sensorik (Perception Layer): Kamera-Pipelines, LiDAR-Processing, Bildverarbeitung mit YOLO oder OpenCV. Diese Container nutzen GPU Device Plugins und sind oft die ressourcenintensivsten Workloads. Details zur GPU-Konfiguration finden sich unter GPU-Workloads auf Kubernetes.

Koordination (Middleware Layer): ROS-Master, Topic-Broker, Service-Discovery. In ROS2 entfaellt der zentrale Master, was die Container-Architektur vereinfacht. Jeder ROS-Node wird zu einem eigenstaendigen Container.

Management (Operations Layer): Monitoring (Prometheus + Grafana), Logging (Loki), CI/CD-Runner, Config-Management. Diese Services laufen auf separaten Nodes, um die Steuerungs-Workloads nicht zu beeintraechtigen.

Praxis: Deployment-Manifest fuer einen Vision-Service

Das folgende Manifest deployt einen Container fuer Echtzeit-Bildverarbeitung auf einem GPU-Node. Es nutzt CPU-Pinning ueber die guaranteed QoS-Klasse und fordert eine NVIDIA-GPU an.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vision-processing
  namespace: robotics
  labels:
    app: vision-processor
    tier: perception
spec:
  replicas: 2
  selector:
    matchLabels:
      app: vision-processor
  template:
    metadata:
      labels:
        app: vision-processor
    spec:
      nodeSelector:
        node-role: gpu-edge
      containers:
      - name: vision-app
        image: registry.internal/robotics/vision:2.4.1
        ports:
        - containerPort: 8080
          name: inference-api
        resources:
          requests:
            cpu: "2"
            memory: "4Gi"
            nvidia.com/gpu: 1
          limits:
            cpu: "2"
            memory: "4Gi"
            nvidia.com/gpu: 1
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 10
        env:
        - name: MODEL_PATH
          value: "/models/yolov8-custom.pt"
        - name: CAMERA_STREAM_URL
          valueFrom:
            configMapKeyRef:
              name: camera-config
              key: stream-url
        volumeMounts:
        - name: model-storage
          mountPath: /models
          readOnly: true
      volumes:
      - name: model-storage
        persistentVolumeClaim:
          claimName: vision-models-pvc

Wichtig: Bei der guaranteed QoS-Klasse (requests == limits) reserviert Kubernetes dedizierte CPU-Cores fuer den Container. Das reduziert Jitter und verbessert die Latenz-Konsistenz erheblich.

OPC-UA Gateway als DaemonSet

Viele Industrieroboter kommunizieren ueber OPC-UA. Ein Gateway-Container uebersetzt zwischen OPC-UA und REST/gRPC, damit andere Services im Cluster die Roboter ansprechen koennen. Als DaemonSet laeuft der Gateway auf jedem Worker Node, der physisch mit Robotern verbunden ist.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: opcua-gateway
  namespace: robotics
spec:
  selector:
    matchLabels:
      app: opcua-gateway
  template:
    metadata:
      labels:
        app: opcua-gateway
    spec:
      nodeSelector:
        has-robot-connection: "true"
      hostNetwork: true
      containers:
      - name: opcua-bridge
        image: registry.internal/robotics/opcua-gw:1.2.0
        ports:
        - containerPort: 4840
          name: opcua
        - containerPort: 9090
          name: metrics
        env:
        - name: OPCUA_SERVER_ENDPOINTS
          valueFrom:
            configMapKeyRef:
              name: robot-endpoints
              key: opcua-servers
        securityContext:
          capabilities:
            add: ["NET_RAW"]

Das hostNetwork: true ist hier notwendig, weil OPC-UA Discovery oft auf Multicast-Mechanismen basiert, die innerhalb des Container-Netzwerks nicht funktionieren. Eine saubere Alternative waere ein dediziertes Macvlan-CNI, das den Container direkt ins OT-Netzwerk haengt.

ROS2 Nodes auf Kubernetes orchestrieren

ROS2 nutzt DDS (Data Distribution Service) als Middleware, was bedeutet, dass Nodes sich per Multicast Discovery finden. In einem Kubernetes-Cluster funktioniert das nicht ohne Weiteres, weil Container-Netzwerke typischerweise kein Multicast unterstuetzen.

Zwei gaengige Loesungen:

Option A: Fast DDS Discovery Server. Ein zentraler Discovery-Server laeuft als Kubernetes-Service. Alle ROS2-Nodes werden per Umgebungsvariable darauf konfiguriert. Das ist die sauberste Loesung fuer Cluster-Deployments.

Option B: Host-Netzwerk. Alle ROS2-Pods nutzen hostNetwork: true, wodurch DDS Discovery normal funktioniert. Nachteil: Port-Konflikte muessen manuell vermieden werden.

# Fast DDS Discovery Server als Kubernetes-Service starten
kubectl create deployment fastdds-discovery \
  --image=registry.internal/ros2/discovery-server:humble \
  --port=11811 \
  -n robotics

kubectl expose deployment fastdds-discovery \
  --port=11811 \
  --type=ClusterIP \
  -n robotics

# ROS2-Nodes konfigurieren (Umgebungsvariable im Pod-Manifest)
# ROS_DISCOVERY_SERVER=fastdds-discovery.robotics.svc.cluster.local:11811

Weitere Details zu Netzwerk-Konfigurationen in Produktionsumgebungen gibt es unter Kubernetes Production Setup.

Echtzeit-Faehigkeit: Grenzen und Workarounds

Standard-Kubernetes garantiert keine harte Echtzeit. Der Linux-Kernel mit PREEMPT_RT-Patch kommt nahe an harte Echtzeit heran, aber Container-Overhead (cgroups, Netzwerk-Stack) fuegt Varianz hinzu.

Pragmatischer Ansatz fuer die meisten Robotik-Anwendungen:

Die meisten Computer-Vision-Aufgaben, Bewegungsplanungen und KI-Inferenz fallen in die Kategorie weiche Echtzeit oder Best Effort. Die harte Echtzeit-Schleife (Servoregelung, Sicherheits-SPS) bleibt auf dedizierter Hardware. Kubernetes orchestriert alles darueber.

Rollout-Strategie: Canary Deployments fuer Robotik-Software

Software-Updates an Robotern sind heikel. Ein fehlerhaftes Update kann Produktionsausfall verursachen. Canary Deployments loesen das, indem das neue Release zunaechst nur auf einer einzelnen Roboterzelle laeuft. Erst nach Validierung wird es auf alle Zellen ausgerollt.

In Kubernetes laesst sich das ueber gewichtete Traffic-Verteilung (Istio, Nginx Ingress) oder einfach ueber separate Deployments mit unterschiedlichen Labels realisieren. Mehr dazu unter Canary Deployments in Kubernetes.

Monitoring: Was Sie messen sollten

Neben den Standard-Kubernetes-Metriken (CPU, Memory, Pod-Restarts) sind in der Robotik folgende Metriken entscheidend:

• Inference-Latenz (p95, p99): Wie lange braucht der Vision-Container pro Frame? Zielwert unter 50ms fuer 20fps.
• OPC-UA Roundtrip Time: Kommunikationslatenz zwischen Kubernetes-Service und Roboter-Controller. Zielwert unter 5ms.
• GPU-Auslastung und -Temperatur: Ueberlastete GPUs drosseln und erhoehen die Latenz. Alerting ab 85 Grad Celsius.
• Container-Restart-Count: Haeufige Restarts deuten auf Memory Leaks oder Crashes hin. Alerting ab 3 Restarts in 10 Minuten.

Wie ein effizientes Monitoring-Setup mit Open-Source-Tools aufgebaut wird, beschreibt der Artikel Kubernetes Monitoring mit Open Source.

Typische Fehler bei der Einfuehrung

Alles auf einmal migrieren. Starten Sie mit einem nicht-kritischen System. Ein Vision-basiertes Qualitaetssystem neben der bestehenden SPS ist ein guter Einstieg. Die SPS bleibt als Fallback.

Container-Netzwerk unterschaetzen. OT-Netzwerke haben andere Anforderungen als IT-Netzwerke. Multicast, niedrige Latenz und deterministische Bandbreite sind Pflicht. Planen Sie das CNI-Plugin sorgfaeltig.

Kein Capacity Planning. Edge-Hardware hat begrenzte Ressourcen. Wenn drei Vision-Container gleichzeitig eine GPU anfordern, aber nur eine vorhanden ist, blockieren sich die Pods gegenseitig. Planen Sie Ressourcen vorab. Hinweise dazu unter Capacity Planning.

Fehlende OT-Expertise im Team. Kubernetes-Admins kennen selten OPC-UA, und SPS-Programmierer kennen selten Container. Investieren Sie in Cross-Training beider Teams.

Kosten und Ressourcenplanung

Fuer einen Pilotaufbau mit einer Roboterzelle reichen drei Industrie-PCs als Kubernetes-Nodes. Ein realistisches Budget:

Der ROI ergibt sich primaer durch reduzierte Stillstandszeiten (schnellere Updates und Rollbacks), hoehere Konsistenz (identische Software auf allen Zellen) und einfachere Skalierung (neue Roboterzelle = neues Deployment, nicht neues Setup).

Zusammenfassung und naechste Schritte

Kubernetes in der industriellen Robotik ist kein Ersatz fuer die SPS-Steuerung. Es ist eine Plattform fuer alles, was oberhalb der harten Echtzeit-Schleife laeuft: Vision, KI-Inferenz, Koordination, Monitoring und Deployment-Automatisierung.

Der Einstieg funktioniert am besten mit einem abgegrenzten Pilotprojekt. Waehlen Sie ein Vision-System oder einen ROS2-basierten Workflow, containerisieren Sie ihn, und betreiben Sie ihn parallel zur bestehenden Infrastruktur. Erst wenn Stabilitaet und Performance validiert sind, wird der Scope erweitert.

Wenn Sie Unterstuetzung bei der Architekturplanung oder dem initialen Setup benoetigen, melden Sie sich gerne ueber unsere Kontaktseite fuer ein technisches Erstgespraech.