Kubernetes in der Automobilindustrie: Edge, CI/CD und Compliance fuer Zulieferer

TL;DR

• Automotive-Zulieferer brauchen Kubernetes vor allem fuer drei Dinge: Edge Computing in der Fertigung, schnelle CI/CD Pipelines fuer Software-Releases, und nachvollziehbare Deployments fuer TISAX/ASPICE Compliance.
• K3s ist die bevorzugte Distribution fuer Edge-Nodes an der Produktionslinie, weil sie unter 512 MB RAM laeuft und ARM64 unterstuetzt.
• Eine GitOps-basierte CI/CD Pipeline mit ArgoCD liefert die lueckenlose Nachvollziehbarkeit, die ASPICE Level 3 verlangt.
• Kubernetes Network Policies und RBAC sind Grundvoraussetzung fuer TISAX-Zertifizierung in der Container-Infrastruktur.

Warum Kubernetes fuer Automobilzulieferer relevant ist

Die Automobilindustrie hat sich von einer Hardware-getriebenen zu einer Software-getriebenen Branche gewandelt. Ein modernes Fahrzeug enthaelt ueber 100 Millionen Zeilen Code. Zulieferer, die frueher Blechteile oder Kabelstraenge geliefert haben, liefern heute Software-Komponenten fuer ADAS, Infotainment oder Produktionssteuerung.

Das aendert die Anforderungen an die IT-Infrastruktur grundlegend. Monatliche Releases werden zu taeglichen Deployments. Monolithische Anwendungen werden zu Microservices. Und die Verarbeitung von Sensordaten muss direkt an der Produktionslinie stattfinden, nicht erst in einem zentralen Rechenzentrum.

Kubernetes ist die Plattform, die all das zusammenbringt. Es orchestriert Container sowohl im Rechenzentrum als auch auf Edge-Nodes, standardisiert Deployments ueber CI/CD Pipelines und bietet mit RBAC und Audit Logging die Werkzeuge fuer Compliance.

Edge Computing an der Produktionslinie

In einer modernen Fertigungslinie erzeugen Kameras, Vibrationssensoren und Laser-Scanner grosse Datenmengen. Eine optische Qualitaetskontrolle per KI-Modell muss innerhalb von Millisekunden entscheiden, ob ein Teil in Ordnung ist oder aussortiert wird. Diese Latenzanforderung laesst sich nur direkt an der Linie erfuellen.

K3s ist hierfuer die Kubernetes-Distribution der Wahl. Sie laeuft auf Industrierechnern mit begrenzten Ressourcen und ist in unter 60 Sekunden installiert. Ein typischer Edge-Node fuer die Qualitaetskontrolle sieht so aus:

Hardware: Industrierechner mit Intel N100 oder ARM64 CPU, 4-8 GB RAM, optional eine NVIDIA Jetson GPU fuer Inference.

Software: K3s mit deaktiviertem Traefik (ein zentraler Ingress ist auf einem Edge-Node nicht noetig), ein DaemonSet fuer die Datenerfassung, und ein Deployment fuer das Inference-Modell.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: quality-inspection
  namespace: edge-workloads
  labels:
    app: quality-inspection
    tisax-classification: "high"
spec:
  replicas: 1
  selector:
    matchLabels:
      app: quality-inspection
  template:
    metadata:
      labels:
        app: quality-inspection
    spec:
      containers:
        - name: inference
          image: registry.internal/quality-model:2.4.1
          ports:
            - containerPort: 8080
          env:
            - name: MODEL_PATH
              value: "/models/defect-detection-v2.onnx"
            - name: CONFIDENCE_THRESHOLD
              value: "0.92"
            - name: CAMERA_STREAM_URL
              value: "rtsp://192.168.1.50:554/stream1"
          resources:
            requests:
              cpu: "500m"
              memory: "512Mi"
              nvidia.com/gpu: "1"
            limits:
              cpu: "2"
              memory: "2Gi"
              nvidia.com/gpu: "1"
          volumeMounts:
            - name: model-storage
              mountPath: /models
              readOnly: true
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 30
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 5
      volumes:
        - name: model-storage
          persistentVolumeClaim:
            claimName: model-pvc

Wichtig: Das Image wird nicht aus einer oeffentlichen Registry gezogen, sondern aus einer internen Registry. In der Automobilindustrie sind Air-Gapped-Environments gaengig, wo Edge-Nodes keinen Internetzugang haben. Die Images werden vorab synchronisiert. Mehr zu Edge Computing mit Kubernetes findest du unter /blog/kubernetes-edge-computing.

CI/CD fuer Automotive Software

Automotive Software unterliegt strengen Anforderungen an Nachvollziehbarkeit. ASPICE (Automotive SPICE) Level 3 verlangt, dass jeder Software-Release lueckenlos dokumentiert ist: Welcher Commit hat welchen Build erzeugt, welche Tests wurden ausgefuehrt, wer hat den Release freigegeben.

Eine GitOps-basierte Pipeline mit ArgoCD erfuellt diese Anforderungen elegant. Der Workflow sieht so aus:

1. Entwickler pusht Code in das Git-Repository.
2. Die CI-Pipeline (z.B. GitLab CI) baut das Container-Image, fuehrt Unit Tests und SAST-Scans durch.
3. Bei Erfolg wird das Image in die interne Registry gepusht und der Image-Tag im GitOps-Repository aktualisiert.
4. ArgoCD erkennt die Aenderung und synchronisiert den Kubernetes-Cluster.
5. Jeder Schritt ist im Git-Log nachvollziehbar.

Ein Beispiel fuer eine GitLab CI Pipeline, die ein Image baut und das GitOps-Repo aktualisiert:

#!/bin/bash
# build-and-update.sh -- wird von GitLab CI aufgerufen

set -euo pipefail

APP_NAME="quality-inspection"
IMAGE_TAG="${CI_COMMIT_SHORT_SHA}-$(date +%Y%m%d)"
REGISTRY="registry.internal"
GITOPS_REPO="git@gitlab.internal:infra/k8s-manifests.git"

# Container Image bauen und pushen
docker build -t "${REGISTRY}/${APP_NAME}:${IMAGE_TAG}" .
docker push "${REGISTRY}/${APP_NAME}:${IMAGE_TAG}"

# Trivy Security Scan
trivy image --exit-code 1 --severity HIGH,CRITICAL \
  "${REGISTRY}/${APP_NAME}:${IMAGE_TAG}"

# GitOps Repo klonen und Image-Tag aktualisieren
git clone "${GITOPS_REPO}" /tmp/k8s-manifests
cd /tmp/k8s-manifests

# kustomize Image-Tag aktualisieren
cd "overlays/production/${APP_NAME}"
kustomize edit set image \
  "${REGISTRY}/${APP_NAME}=${REGISTRY}/${APP_NAME}:${IMAGE_TAG}"

# Commit mit Traceability-Informationen
git add .
git commit -m "release: ${APP_NAME}:${IMAGE_TAG}

CI Job: ${CI_JOB_URL}
Commit: ${CI_COMMIT_SHA}
Author: ${GITLAB_USER_LOGIN}
Tests: passed (see CI job for details)"

git push origin main
echo "GitOps update pushed. ArgoCD will sync automatically."

Der entscheidende Punkt: Jeder Commit im GitOps-Repository enthaelt einen Link zum CI-Job und zum Source-Commit. Bei einem ASPICE-Audit kann fuer jeden deployten Container lueckenlos nachvollzogen werden, welcher Code, welche Tests und welche Freigaben zugrunde liegen.

Fuer mehr Details zu GitOps-Strategien siehe /blog/gitops-evolution-deutschland.

TISAX und ASPICE Compliance

Die Automobilbranche hat eigene Compliance-Standards, die ueber generische IT-Security hinausgehen.

TISAX (Trusted Information Security Assessment Exchange): TISAX ist ein Informationssicherheits-Standard speziell fuer die Automobilbranche, basierend auf dem VDA ISA Katalog. Zulieferer muessen TISAX-zertifiziert sein, um mit OEMs zusammenarbeiten zu koennen.

ASPICE (Automotive SPICE): ASPICE definiert Reifegradmodelle fuer Software-Entwicklungsprozesse. Level 3 ist die gaengige Anforderung fuer sicherheitsrelevante Software.

Kubernetes bietet die technischen Mittel, um beide Standards zu erfuellen, aber nur wenn du sie auch konfigurierst.

RBAC richtig konfigurieren

Ein haeufiger Fehler: Teams geben allen Entwicklern cluster-admin Rechte, weil es einfacher ist. Das ist ein TISAX-Versager. Stattdessen sollte jede Rolle nur die Rechte haben, die sie tatsaechlich braucht.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer-edge
  namespace: edge-workloads
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-edge-binding
  namespace: edge-workloads
subjects:
  - kind: Group
    name: "automotive-developers"
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer-edge
  apiGroup: rbac.authorization.k8s.io

Entwickler koennen sich Deployments und Logs anschauen, aber nichts deployen oder loeschen. Deployments laufen ausschliesslich ueber ArgoCD. Diese Trennung ist genau das, was TISAX-Auditoren sehen wollen. Detailliertere RBAC-Strategien beschreiben wir in /blog/kubernetes-rbac-enterprise.

Architektur: Zentraler Cluster und Edge

Eine typische Architektur fuer einen Automobilzulieferer besteht aus zwei Schichten:

Zentraler Cluster: Laeuft im eigenen Rechenzentrum oder bei einem deutschen Cloud-Anbieter. Hier laufen Backend-Services, CI/CD Pipelines, Monitoring, das ArgoCD-Control-Plane und zentrale Datenbanken. Dieser Cluster hat 10-50 Nodes je nach Groesse des Unternehmens.

Edge-Cluster: Je einer pro Fertigungslinie oder Pruefstand. Laeuft auf K3s mit 1-3 Nodes. Fuehrt latenz-kritische Workloads wie Qualitaetskontrolle, Predictive Maintenance oder SPS-Anbindung aus. Kommuniziert ueber MQTT oder gRPC mit dem zentralen Cluster.

Die Synchronisierung zwischen zentralem Cluster und Edge-Clustern laeuft ueber ArgoCD in einer Hub-and-Spoke-Topologie. Der zentrale ArgoCD-Server verwaltet die gewuenschten Zustaende aller Edge-Cluster. Wenn ein neues Modell oder eine neue Konfiguration bereitsteht, synchronisiert ArgoCD automatisch.

Fuer den Fall, dass die Verbindung zwischen Edge und Zentrale abbricht (was in Fabrikumgebungen vorkommt), muss der Edge-Cluster autonom weiterlaufen. K3s ist darauf ausgelegt: Alle Workloads laufen weiter, nur neue Deployments sind nicht moeglich, bis die Verbindung wiederhergestellt ist.

OPC UA Integration

In der Fertigung ist OPC UA der Standard fuer die Kommunikation mit Maschinen. Kubernetes-Workloads muessen OPC UA Server ansprechen koennen, um Maschinendaten zu lesen oder Steuerungsbefehle zu senden.

Dafuer laeuft ein OPC UA Client als Sidecar-Container neben der eigentlichen Anwendung. Der Sidecar uebersetzt OPC UA in eine REST- oder gRPC-Schnittstelle, die der Haupt-Container konsumiert. Das entkoppelt die Anwendungslogik vom Industrieprotokoll.

Mehr zu OPC UA und Kubernetes findest du unter /blog/kubernetes-opc-ua-industrie40-2026.

Haeufige Fehler bei Automotive-Kubernetes-Projekten

Edge-Cluster ohne Monitoring: Nur weil ein Edge-Node in der Fabrikhalle steht, heisst das nicht, dass er kein Monitoring braucht. Installiere mindestens einen Prometheus-Agent, der Metriken an den zentralen Cluster pushed. Ohne Monitoring fliegst du blind.

Keine Netzwerktrennung zwischen IT und OT: Kubernetes-Workloads, die Maschinendaten verarbeiten, duerfen nicht im selben Netzwerksegment wie die Buero-IT laufen. Nutze Network Policies und physische Netzwerktrennung. Das ist sowohl aus Sicherheitsgruenden als auch fuer TISAX zwingend.

Image Updates ohne Rollback-Plan: Auf einem Edge-Node in der Produktion kannst du nicht mal eben ein Rollback machen, wenn das neue Image nicht funktioniert. Teste Images immer zuerst auf einem Staging-Edge-Node und nutze ArgoCD's Rollback-Feature. Mehr zu Rollback-Strategien unter /blog/kubernetes-rollback-strategien.

Kein Backup der etcd-Datenbank: K3s nutzt SQLite oder etcd. Bei einem Hardwaredefekt des Edge-Nodes verlierst du die gesamte Cluster-Konfiguration, wenn kein Backup existiert. Automatisiere etcd-Snapshots oder nutze ArgoCD als Single Source of Truth, dann reicht ein neuer K3s-Node plus Sync.

Vergleich: Managed Kubernetes vs. Self-Managed fuer Automotive

Fuer den zentralen Cluster ist Managed Kubernetes oft die pragmatische Wahl, wenn der Provider TISAX-konforme Rechenzentren in der EU hat. Fuer Edge-Nodes fuehrt kein Weg an Self-Managed K3s vorbei. Eine detaillierte Kostenanalyse findest du unter /blog/kubernetes-hosting-kosten-vergleich-2025.

Fazit

Kubernetes ist fuer Automobilzulieferer kein Nice-to-Have mehr, sondern eine Grundlage fuer schnelle Software-Releases, Edge Computing in der Fertigung und die Einhaltung branchenspezifischer Compliance-Standards.

Der wichtigste Tipp: Starte nicht mit dem groessten Problem. Nimm einen ueberschaubaren Use Case, z.B. ein Qualitaetskontroll-Modell auf einem einzelnen Edge-Node oder eine CI/CD Pipeline fuer eine nicht-sicherheitsrelevante Anwendung. Sammle Erfahrung, bau Kompetenz im Team auf, und skaliere dann.

Wenn du einen Sparringspartner fuer die Planung deiner Kubernetes-Strategie im Automotive-Umfeld suchst, melde dich unter /kontakt.