Kubernetes in der Logistik: Lieferkettengesetz, Supply Chain Visibility und ESG-Reporting

TL;DR

• Das LkSG verlangt ein dokumentiertes Risikomanagement ueber die gesamte Lieferkette. Eine Kubernetes-basierte Plattform kann Risikoanalyse, Monitoring und Reporting automatisieren.
• Supply Chain Visibility braucht Event-Streaming (Kafka), IoT-Integration und skalierbare APIs. Kubernetes liefert die Laufzeitumgebung dafuer.
• ESG-Reporting und CO2-Bilanzierung lassen sich als CronJobs automatisieren und in bestehende Plattformen integrieren.
• Namespace-Isolation und Audit-Logging decken die Dokumentationspflichten nach Paragraph 10 LkSG ab.
• HorizontalPodAutoscaler gleichen saisonale Lastspitzen (Black Friday, Weihnachten) automatisch aus.

Was das Lieferkettengesetz fuer die IT bedeutet

Seit 2024 gilt das LkSG fuer Unternehmen ab 1.000 Mitarbeitern. Ab 2026 kommt die EU CSDDD mit erweitertem Scope hinzu. Die Kernpflichten sind: Risikoanalyse der Lieferkette, praeventive und abstellende Massnahmen, ein Beschwerdeverfahren und eine jaehrliche Berichterstattung ans BAFA.

Fuer die IT-Abteilung heisst das konkret: Man braucht ein System, das Lieferantendaten zentral verwaltet, Risikoscores berechnet, Aenderungen protokolliert und am Ende einen BAFA-konformen Report generiert. Excel-Tabellen skalieren dafuer nicht. Eine Microservice-Architektur auf Kubernetes schon.

LkSG-Pflichten und ihre technischen Anforderungen

Architektur: Supply Chain Plattform auf Kubernetes

Eine typische LkSG-Plattform besteht aus mehreren Microservices: Supplier-Datenbank, Risk-Scoring-Engine, Event-Processor fuer Echtzeit-Monitoring, Whistleblower-Portal und Reporting-Service. Jeder Service laeuft in einem eigenen Deployment und kann unabhaengig skaliert werden.

Die Namespace-Struktur bildet die fachlichen Domaenen ab:

apiVersion: v1
kind: Namespace
metadata:
  name: supplier-management
  labels:
    compliance: lksg
    function: risk-management
---
apiVersion: v1
kind: Namespace
metadata:
  name: whistleblower
  labels:
    compliance: lksg
    function: complaint-procedure
    confidentiality: high
---
apiVersion: v1
kind: Namespace
metadata:
  name: supply-chain-visibility
  labels:
    function: tracking

Warum drei Namespaces statt einem? Das Whistleblower-Portal hat besondere Vertraulichkeitsanforderungen (Paragraph 8 LkSG). Es darf keine Verbindung zu internen Systemen haben, ueber die man Hinweisgeber identifizieren koennte. Network Policies setzen das auf Netzwerkebene durch:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: whistleblower-isolation
  namespace: whistleblower
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: ingress-controller
      ports:
        - protocol: TCP
          port: 8443
  egress:
    - to:
        - podSelector: {}

Damit kann das Whistleblower-Portal nur Traffic vom Ingress Controller empfangen und nur innerhalb seines eigenen Namespaces kommunizieren. Kein Zugriff auf die Supplier-Datenbank, kein Zugriff auf interne User-Directories.

Supplier Risk Scoring mit CronJobs

Die Risikoanalyse nach Paragraph 5 LkSG muss mindestens jaehrlich durchgefuehrt werden, bei konkreten Anlaessen (z.B. Medienberichte ueber einen Lieferanten) auch ad-hoc. Beides laesst sich in Kubernetes abbilden:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: annual-risk-analysis
  namespace: supplier-management
spec:
  schedule: "0 3 15 1 *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: risk-analyzer
              image: registry.internal/risk-analyzer:v2.4
              env:
                - name: ANALYSIS_SCOPE
                  value: all-direct-suppliers
                - name: DATA_SOURCES
                  value: ecovadis,cdp,internal-audits,news-api
                - name: OUTPUT_FORMAT
                  value: bafa-report
              resources:
                requests:
                  cpu: "2"
                  memory: "4Gi"
                limits:
                  cpu: "4"
                  memory: "8Gi"
          restartPolicy: OnFailure

Fuer die ereignisgesteuerte Analyse laeuft ein separater Event-Processor, der auf Nachrichten aus einer Kafka-Queue reagiert:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: risk-event-processor
  namespace: supplier-management
spec:
  replicas: 2
  selector:
    matchLabels:
      app: risk-event-processor
  template:
    metadata:
      labels:
        app: risk-event-processor
    spec:
      containers:
        - name: event-processor
          image: registry.internal/risk-events:v1.8
          env:
            - name: KAFKA_BROKERS
              value: kafka.supply-chain-visibility:9092
            - name: KAFKA_TOPIC
              value: supplier-risk-events
            - name: ALERT_THRESHOLD
              value: high
            - name: NOTIFICATION_CHANNELS
              value: email,slack
          resources:
            requests:
              cpu: "500m"
              memory: "1Gi"
            limits:
              cpu: "1"
              memory: "2Gi"

Wenn der Event-Processor einen kritischen Risiko-Score erkennt, schickt er eine Benachrichtigung ans Compliance-Team. Die ganze Kette -- von der Datenquelle ueber die Bewertung bis zur Benachrichtigung -- ist nachvollziehbar und automatisiert.

Supply Chain Visibility: Echtzeit-Tracking

Neben dem LkSG-Compliance-Thema ist Supply Chain Visibility ein eigenstaendiger Business Case. Echtzeit-Sendungsverfolgung, ETA-Prediction und Geofencing brauchen eine Plattform, die hohe Event-Raten verarbeiten kann.

Der typische Stack: Ein Kafka-Cluster fuer Event-Streaming, eine Tracking-API fuer GPS- und Telematik-Daten, und ein HorizontalPodAutoscaler, der bei Lastspitzen automatisch skaliert.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tracking-api
  namespace: supply-chain-visibility
spec:
  replicas: 3
  selector:
    matchLabels:
      app: tracking-api
  template:
    metadata:
      labels:
        app: tracking-api
    spec:
      containers:
        - name: tracking
          image: registry.internal/tracking-api:v3.1
          ports:
            - containerPort: 8443
          resources:
            requests:
              cpu: "1"
              memory: "2Gi"
            limits:
              cpu: "2"
              memory: "4Gi"
          livenessProbe:
            httpGet:
              path: /health/live
              port: 8443
              scheme: HTTPS
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /health/ready
              port: 8443
              scheme: HTTPS
            periodSeconds: 5
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: tracking-api-hpa
  namespace: supply-chain-visibility
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: tracking-api
  minReplicas: 3
  maxReplicas: 30
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 65

In der Vorweihnachtszeit kann das Tracking-Volumen um das Zehnfache steigen. Der HPA skaliert die Pods automatisch hoch und nach der Spitze wieder runter. Ohne Kubernetes muesste man die Infrastruktur statisch fuer den Peak dimensionieren und wuerde den Rest des Jahres Geld verbrennen. Mehr zum Thema Autoscaling unter Kubernetes HPA.

ESG-Reporting und CO2-Bilanzierung

Das LkSG ist nur ein Teil der ESG-Anforderungen. Die EU CSRD (Corporate Sustainability Reporting Directive) verlangt ab 2026 zusaetzlich eine detaillierte CO2-Bilanzierung ueber alle Scopes. Fuer Logistik-Unternehmen sind Scope-3-Emissionen (Transport, Lieferanten) der groesste Posten.

Ein CronJob, der naechtlich die Transportdaten aggregiert und nach dem GLEC Framework berechnet, ist ein pragmatischer Startpunkt:

# Terraform-Auszug fuer den Kubernetes-Namespace
# und die PersistentVolumeClaim fuer Report-Daten

resource "kubernetes_namespace" "sustainability" {
  metadata {
    name = "sustainability"
    labels = {
      function = "esg-reporting"
    }
  }
}

resource "kubernetes_persistent_volume_claim" "esg_reports" {
  metadata {
    name      = "esg-report-storage"
    namespace = kubernetes_namespace.sustainability.metadata[0].name
  }
  spec {
    access_modes = ["ReadWriteOnce"]
    resources {
      requests = {
        storage = "50Gi"
      }
    }
    storage_class_name = "standard-encrypted"
  }
}

Die Reports landen auf einem verschluesselten PersistentVolume und werden von dort an das BAFA-Portal oder das interne ESG-Dashboard weitergeleitet. Das ist kein Raketenwissenschaft, aber es muss zuverlaessig laufen, und genau dafuer ist ein CronJob auf Kubernetes besser geeignet als ein Cron-Eintrag auf irgendeiner VM.

Vergleich: Monolith vs. Microservices auf Kubernetes

Fuer kleinere Unternehmen (unter 50 Lieferanten) kann eine monolithische Loesung ausreichen. Sobald man aber hunderte oder tausende Lieferanten verwaltet, Events in Echtzeit verarbeitet und verschiedene Reporting-Anforderungen (LkSG, CSRD, CDP) bedienen muss, fuehrt an einer Microservice-Architektur kaum ein Weg vorbei.

Dokumentationspflichten technisch umsetzen

Paragraph 10 LkSG verlangt eine sieben Jahre aufzubewahrende Dokumentation. Auf Kubernetes-Ebene heisst das: API-Server Audit Logs, Anwendungs-Logs und Aenderungshistorie in Git muessen langfristig archiviert werden.

Ein pragmatischer Ansatz: Audit-Logs ueber Vector oder Fluentd an einen S3-kompatiblen Object Store mit Object Lock senden. Git-Repositories mit allen Manifest-Aenderungen in ein Archiv sichern. Anwendungs-Logs mindestens 90 Tage in einem Log-Backend (Loki, Elasticsearch) vorhalten, danach auf Cold Storage verschieben.

Mehr zum Thema Observability und Log-Management unter Kubernetes Observability Stack.

IoT-Integration fuer Lager und Transport

Logistik-Unternehmen haben oft eine IoT-Komponente: Temperatursensoren in Kuehlketten, GPS-Tracker an Containern, Barcode-Scanner im Lager. Diese Geraete senden Daten per MQTT oder HTTP an die Kubernetes-Plattform.

Fuer die MQTT-Integration eignet sich ein DaemonSet, das auf jedem Edge-nahen Node einen Broker bereitstellt. Die eigentliche Verarbeitung laeuft dann in einem Deployment mit Autoscaling. Fuer groessere Setups lohnt sich ein Blick auf Kubernetes Edge Computing.

Managed Kubernetes fuer Logistik-Unternehmen

Die wenigsten Logistik-Unternehmen haben ein Platform-Team, das Kubernetes selbst betreiben kann. Ein Managed-Kubernetes-Provider ist fuer die meisten der realistischere Weg. Worauf man achten sollte:

Einen umfassenden Vergleich gibt es unter Managed Service vs. Inhouse. Fuer die Kostenplanung hilft Kubernetes Kosten-Optimierung.

Fazit

Das Lieferkettengesetz ist ein regulatorischer Treiber fuer die IT-Modernisierung in der Logistik. Wer ohnehin eine Supply-Chain-Plattform aufbaut, kann die LkSG-Anforderungen als festen Bestandteil der Architektur mitdenken: Namespace-Isolation fuer Vertraulichkeit, Audit-Logging fuer Dokumentationspflichten, CronJobs fuer automatisierte Reports und Autoscaling fuer saisonale Lasten.

Der Aufwand fuer die Plattform ist nicht trivial. Aber die Alternative -- manuelle Prozesse, Excel-Listen und fehlende Transparenz -- fuehrt nicht nur zu BAFA-Bussgeldern (bis zu 2% des Jahresumsatzes), sondern auch zu operativen Risiken in der Lieferkette.

Wenn Sie eine LkSG-konforme Supply-Chain-Plattform auf Kubernetes planen, sprechen Sie uns an unter /kontakt.