Kubernetes fuer Drohnen-Logistik: Edge-Architektur, Fleet Management und Echtzeit-Telemetrie

TL;DR

• Drohnenflotten brauchen eine Zwei-Ebenen-Architektur: leichtgewichtige Edge-Cluster (k3s) auf den Gateways und ein zentrales Kubernetes-Cluster fuer Fleet Management
• Telemetrie-Daten (GPS, Batterie, Sensoren) laufen ueber Kafka ins zentrale Cluster -- bei Verbindungsabbruch puffert das Edge-Gateway lokal
• Routenplanung und Anomalie-Erkennung laufen als Microservices im zentralen Cluster, skaliert ueber HPA
• EASA-Regularien und DSGVO erfordern auditierbare Flugdaten-Speicherung und verschluesselte Kommunikation
• Fangt mit einem PoC auf dem Werksgelaende an, nicht im oeffentlichen Luftraum -- die Genehmigungen dauern Monate

Das Architektur-Problem

Eine einzelne Lieferdrohne zu steuern ist vergleichsweise trivial. Eine Flotte von 50 oder 500 Drohnen in Echtzeit zu koordinieren -- mit Routenplanung, Telemetrie, Anomalie-Erkennung und regulatorischer Compliance -- ist ein verteiltes System-Problem.

Die Herausforderungen:

• Latenz: Flugentscheidungen (Ausweichmanoever, Notlandung) muessen in Millisekunden fallen. Das geht nicht ueber eine Cloud-Verbindung.
• Konnektivitaet: Drohnen fliegen durch Gebiete mit schlechter Netzabdeckung. Die Architektur muss mit intermittierenden Verbindungen umgehen.
• Skalierung: Bei Lastspitzen (z.B. Lieferpeaks am Freitagnachmittag) muessen die Backend-Services mitskalieren.
• Auditierbarkeit: Jeder Flugbefehl, jede Routenaenderung und jeder Sensorwert muss nachvollziehbar gespeichert werden.

Kubernetes loest die letzten drei Punkte. Fuer die Latenz-Anforderungen braucht ihr Edge Computing.

Zwei-Ebenen-Architektur

Die Architektur teilt sich in zwei Ebenen:

Edge-Ebene (Basisstationen / Gateways): Jede Basisstation betreibt einen k3s-Cluster. Hier laufen die zeitkritischen Services: Kollisionsvermeidung, lokale Routenanpassung, Telemetrie-Pufferung. k3s ist ideal, weil es auf einem Raspberry Pi oder einem kleinen x86-Board laeuft und trotzdem volle Kubernetes-API-Kompatibilitaet bietet.

Zentrales Cluster (Rechenzentrum): Hier laufen Fleet Management, globale Routenoptimierung, Analytics, Monitoring und die API fuer externe Systeme (ERP, Kundenportal). Das ist ein regulaerer Kubernetes-Cluster mit ausreichend Ressourcen.

Die Kommunikation zwischen den Ebenen laeuft ueber MQTT oder gRPC mit TLS. Bei Verbindungsabbruch arbeitet das Edge-Gateway autonom weiter und synchronisiert spaeter.

Wer sich generell fuer Edge-Architekturen mit Kubernetes interessiert, findet im Artikel zu Kubernetes Edge Computing eine breitere Einfuehrung.

Edge-Gateway: k3s-Setup

Das Edge-Gateway ist der Knotenpunkt zwischen Drohne und zentralem Cluster. Hier ein minimales k3s-Setup fuer eine Basisstation:

# k3s auf dem Gateway installieren (ARM64 oder x86)
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server \
  --disable traefik \
  --disable servicelb \
  --write-kubeconfig-mode 644 \
  --node-label role=edge-gateway \
  --node-label location=hub-frankfurt-01" sh -

# Kubeconfig exportieren
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml

# Telemetrie-Puffer deployen (faengt Daten bei Verbindungsabbruch auf)
kubectl apply -f - <<'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
  name: telemetry-buffer
  namespace: drone-edge
spec:
  replicas: 1
  selector:
    matchLabels:
      app: telemetry-buffer
  template:
    metadata:
      labels:
        app: telemetry-buffer
    spec:
      containers:
        - name: buffer
          image: registry.internal/telemetry-buffer:1.2.0
          env:
            - name: MQTT_BROKER
              value: "mqtt://localhost:1883"
            - name: KAFKA_BROKER
              value: "kafka-central.internal:9092"
            - name: BUFFER_MAX_MB
              value: "512"
            - name: RETRY_INTERVAL_SEC
              value: "5"
          resources:
            requests:
              memory: "64Mi"
              cpu: "50m"
            limits:
              memory: "256Mi"
              cpu: "200m"
          volumeMounts:
            - name: buffer-storage
              mountPath: /data/buffer
      volumes:
        - name: buffer-storage
          hostPath:
            path: /var/lib/telemetry-buffer
EOF

Der Telemetry-Buffer ist das wichtigste Edge-Service. Er empfaengt Daten per MQTT von den Drohnen, speichert sie lokal auf Disk falls die Kafka-Verbindung zum zentralen Cluster unterbrochen ist, und forwarded sie sobald die Verbindung wieder steht. Das ist das Store-and-Forward-Pattern.

Traefik und ServiceLB sind auf dem Edge-Gateway deaktiviert (--disable), weil sie hier nicht gebraucht werden und Ressourcen sparen.

Zentrales Fleet Management

Im zentralen Cluster laufen die Services, die die gesamte Flotte koordinieren. Das Fleet Management ist der Kern:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: fleet-manager
  namespace: drone-platform
spec:
  replicas: 3
  selector:
    matchLabels:
      app: fleet-manager
  template:
    metadata:
      labels:
        app: fleet-manager
    spec:
      containers:
        - name: fleet-manager
          image: registry.internal/fleet-manager:2.4.1
          ports:
            - containerPort: 8080
              name: api
            - containerPort: 9090
              name: metrics
          env:
            - name: KAFKA_BOOTSTRAP
              value: "kafka.drone-platform.svc:9092"
            - name: DB_HOST
              value: "postgres.drone-platform.svc"
            - name: DB_NAME
              value: "fleet_db"
            - name: REDIS_HOST
              value: "redis.drone-platform.svc:6379"
          resources:
            requests:
              memory: "512Mi"
              cpu: "500m"
            limits:
              memory: "1Gi"
              cpu: "1"
          livenessProbe:
            httpGet:
              path: /healthz
              port: api
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /ready
              port: api
            periodSeconds: 5
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: fleet-manager-hpa
  namespace: drone-platform
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: fleet-manager
  minReplicas: 3
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
        - type: Pods
          value: 2
          periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300

Drei Replicas als Minimum, weil Fleet Management hochverfuegbar sein muss. Wenn der Service ausfaellt, koennen keine neuen Auftraege zugewiesen werden. Die Scale-Down-Stabilisierung von 300s verhindert Flapping bei kurzfristigen Lastspitzen.

Redis dient als Cache fuer den aktuellen Drohnenstatus (Position, Batterie, aktueller Auftrag). PostgreSQL speichert die persistenten Daten (Auftragshistorie, Flottenkonfiguration, Wartungsplaene).

Telemetrie-Pipeline

Jede Drohne sendet ca. 10 Datenpunkte pro Sekunde: GPS-Position, Hoehe, Geschwindigkeit, Batteriestand, Motortemperaturen, Windgeschwindigkeit. Bei 100 Drohnen sind das 1.000 Datenpunkte pro Sekunde -- kein Problem fuer Kafka, aber die Downstream-Consumer muessen mitskalieren.

Die Pipeline:

Kafka ist hier die richtige Wahl, weil es sowohl Pufferung bei Lastspitzen als auch Replay-Faehigkeit bietet. Wenn ein Consumer ausfaellt, kann er nach dem Restart die verpassten Nachrichten nachholen.

TimescaleDB (PostgreSQL-Extension fuer Zeitreihendaten) als Hot Storage ist ein pragmatischer Kompromiss: Ihr bekommt die Vertrautheit von SQL mit der Performance einer Zeitreihen-DB. Fuer Langzeitarchivierung wandern die Daten nach 30 Tagen als Parquet-Files in S3.

Details zur Storage-Architektur auf Kubernetes findet ihr unter Kubernetes Storage.

Vergleich: Edge-Cluster-Optionen

Nicht jede Basisstation braucht einen vollwertigen k3s-Cluster. Hier ein Vergleich der Optionen:

Fuer die meisten Drohnen-Szenarien ist k3s die beste Balance aus Kubernetes-Kompatibilitaet und Ressourceneffizienz. KubeEdge ist interessant, wenn ihr eine direkte Cloud-zu-Edge-Verwaltung ueber ein einzelnes Control Plane wollt, aber die Lernkurve ist steiler.

Sicherheit und Regulatorik

Drohnen-Logistik unterliegt strengen Regularien. Die wichtigsten aus technischer Sicht:

EASA-Kategorien:

Die EU-Drohnenverordnung teilt Fluege in drei Kategorien ein: Open, Specific und Certified. Lieferdrohnen fallen fast immer in Specific oder Certified, was bedeutet: Risikobeurteilung, Betriebsgenehmigung und in vielen Faellen ein Fernidentifikationssystem.

DSGVO-relevante Aspekte:

• Telemetrie-Daten koennen personenbezogen sein, wenn sie Rueckschluesse auf Personen zulassen (Lieferadresse, Kameradaten).
• Daten muessen verschluesselt uebertragen und gespeichert werden.
• Loeschkonzepte muessen implementiert sein -- Telemetrie-Daten braucht ihr fuer Compliance-Nachweise, aber nicht ewig.
• Eine Datenschutz-Folgenabschaetzung (DSFA) nach Art. 35 DSGVO ist wahrscheinlich erforderlich.

Technische Umsetzung:

Kubernetes bietet die Werkzeuge, um diese Anforderungen zu implementieren:

• NetworkPolicies isolieren die Drone-Platform-Namespace von anderen Workloads.
• Cert-Manager automatisiert TLS-Zertifikate fuer die Kommunikation zwischen Edge und Central.
• RBAC stellt sicher, dass nur autorisierte Services auf Flugdaten zugreifen.
• Audit Logging protokolliert jeden API-Zugriff revisionssicher.

Fuer eine tiefere Einfuehrung in Kubernetes-Sicherheit empfehle ich den Artikel zu Kubernetes Network Security und Supply Chain Security.

Routenplanung als Microservice

Die Routenplanung ist rechentechnisch der anspruchsvollste Teil. Sie muss in Echtzeit Routen berechnen, die Folgendes beruecksichtigen:

• No-Fly-Zones (Flughaefen, Militaergebiete, temporaere Sperrzonen)
• Wetterdaten (Wind, Regen, Sicht)
• Batterie-Reichweite
• Lieferprioritaeten
• Andere Drohnen im Luftraum (Deconfliction)

Dieser Service profitiert stark von horizontaler Skalierung. Bei Lastspitzen (z.B. 200 gleichzeitige Lieferauftraege) kann er auf mehrere Pods skaliert werden. Fuer komplexere Optimierungen (z.B. Vehicle Routing Problem mit Zeitfenstern) lohnt sich auch der Einsatz von GPUs.

Wer ML-basierte Routenoptimierung evaluiert, findet im Artikel zu Kubernetes AI und Machine Learning Hintergrund zur GPU-Anbindung.

Monitoring der Drohnenflotte

Das Monitoring hat zwei Dimensionen: Infrastructure Monitoring (Kubernetes-Cluster, Services) und Fleet Monitoring (Drohnenstatus, Flugdaten).

Fuer das Infrastructure Monitoring reicht der klassische Stack: Prometheus, Grafana, Alertmanager. Fuer das Fleet Monitoring braucht ihr zusaetzliche Dashboards:

• Flottenueberblick: Karte mit aktuellen Drohnenpositionen, Status (fliegend, ladend, wartend, Wartung)
• Einzel-Drohnen-View: Batterieverlauf, Motortemperaturen, Flughistorie
• Auftrags-Tracking: Zustellstatus, Durchlaufzeiten, Fehlerquoten
• Anomalie-Alerts: Ungewoehnlicher Batterieverbrauch, Abweichung von geplanter Route, Kommunikationsausfall

Die Anomalie-Erkennung laesst sich als eigener Microservice implementieren, der auf dem Kafka-Telemetrie-Stream operiert. Einfache Regeln (Batterie faellt schneller als erwartet) funktionieren mit Threshold-Based Alerting. Fuer komplexere Pattern (Motorvibration deutet auf Verschleiss hin) braucht ihr ML-basierte Erkennung.

Eine ausfuehrliche Anleitung zum Monitoring-Setup gibt es unter Kubernetes Observability Stack.

Lessons Learned

Einige Erfahrungswerte aus Edge-Kubernetes-Projekten:

Die Netzwerkverbindung ist nie so stabil wie ihr denkt. Plant Store-and-Forward auf jeder Ebene ein. Edge-Gateways muessen mindestens 24 Stunden autonom arbeiten koennen.

k3s-Upgrades auf Edge-Nodes sind heikel. Anders als im Rechenzentrum koennt ihr nicht einfach SSHen und neustarten. Baut einen automatisierten Upgrade-Prozess mit Rollback-Faehigkeit. System Upgrade Controller von Rancher hilft hier.

GPS-Daten sind verrauscht. Rohe GPS-Positionen springen um mehrere Meter. Filtert auf dem Edge-Gateway (Kalman-Filter) bevor ihr die Daten zentral speichert, sonst ertrinkt eure TimescaleDB in Rauschen.

Regulatorik dauert laenger als Technik. Eine EASA Specific-Category-Genehmigung kann 6-12 Monate dauern. Startet den regulatorischen Track parallel zum technischen. Die Technik ist einfacher als die Buerokratie.

Battery Management unterschaetzen die meisten. Die Batterie bestimmt die maximale Flugdauer und damit den Lieferradius. Integriert Batterie-Degradationsmodelle in die Routenplanung, nicht nur den aktuellen Ladestand.

Fazit

Kubernetes-basierte Drohnen-Logistik ist kein Science-Fiction-Projekt mehr, aber auch kein Plug-and-Play. Die technische Architektur mit k3s am Edge und einem zentralen Kubernetes-Cluster fuer Fleet Management ist bewaehrt und skalierbar. Die groessten Herausforderungen liegen nicht in der Software, sondern in der Regulatorik und der zuverlaessigen Netzwerkkonnektivitaet.

Der pragmatische Einstieg: Ein PoC auf dem eigenen Gelaende, mit einer Drohne, einem Edge-Gateway und dem zentralen Cluster. Damit validiert ihr die Architektur, sammelt Erfahrung mit der Telemetrie-Pipeline und koennt parallel den regulatorischen Prozess starten.

Wenn ihr ein konkretes Drohnen-Logistik-Projekt plant oder Unterstuetzung bei der Kubernetes-Architektur braucht, sprecht uns gerne an unter /kontakt.