Kundenreferenz: OTA Update Plattform auf AKS seit 2023

Constantin Budin, Cloud- und Platform-Engineer bei Pexon Consulting | 8 Min. Lesezeit | 16.09.2026

Das hier ist keine Anleitung. Es ist der Bericht aus einem Mandat, in dem Pexon Consulting für die Connected-Car-Software-Einheit eines deutschen Automobilkonzerns die Azure-AKS-Infrastruktur einer OTA Update Plattform härtet und im Live-Betrieb mitträgt. Kick-off am 01.02.2023, seit Februar 2023 produktiv, das Mandat läuft. Fahrzeug-Software geht als OCI-Container über die Plattform ins Feld.

Connected-Car-Produkt intern, AKS-Naht bei uns

Ein Oberklasse-Auto fährt heute mit über 100 Millionen Zeilen Code. Damit Fahrzeuge straßentauglich die richtige Software bekommen, braucht der Hersteller eine Instanz, die Images verwaltet, Fahrzeuge authentifiziert und autorisiert und Updates gesteuert ausliefert. Genau das ist das Container-Update-Projekt der Connected-Car-Software-Einheit: eine zentrale Anlaufstelle, die Fahrzeug-Software als OCI-Container bereitstellt und aktualisiert.

Die Anwendungsentwicklung lag beim Kunden und war live, als wir dazukamen. Was wir geliefert haben und weiter liefern, ist die Fläche darunter: Cluster, State, Pipelines, Secrets, Skalierung, Observability. Pexon sitzt nicht daneben mit Folien. Wir besetzen die Cloud-Operations-Rolle im Kernteam.

So eine Teilung ist in Automotive-Mandaten oft der saubere Schnitt. Die Domain bleibt intern, Connected Car, Fahrzeugtypen, Freigaben. Die prüfbare Container-Plattform kommt von Leuten, die AKS, Terraform und Key Vault täglich bauen. Live-Betrieb und Weiterentwicklung laufen parallel, das ist der normale Maßstab einer produktiven OTA-Strecke, kein Sonderfall.

Software-Updates am Fahrzeug stehen unter UNECE R156, seit Juli 2022 Voraussetzung für die Typgenehmigung neuer Fahrzeugtypen, flankiert von ISO 24089 und UNECE R155 bzw. ISO-SAE 21434. Auf Infrastruktur-Ebene galt zusätzlich NIST SP 800. RBAC, Secret-Management, nachvollziehbare Provisionierung und Observability sind deshalb Architektur, nicht Nachtrag.

Was die OTA Update Plattform auf AKS konkret hieß

Eine OTA Update Plattform in diesem Mandat ist kein Datei-Download. Fahrzeug-Software landet als versioniertes OCI-Image in der Azure Container Registry. Das Fahrzeug authentifiziert sich gegen den Update-Server. Ein Auth- und Autorisierungs-Layer prüft Identität und Berechtigung, bevor irgendein Image rausgeht. Jedes Fahrzeug bekommt nur die für Typ und Stand freigegebenen Images, kein pauschaler Broadcast. Die Auslieferung läuft über das Azure Application Gateway. Daten liegen in CosmosDB und PostgreSQL, Compute zusätzlich über Virtual Machine Scale Sets. Netzseitig tragen VNet, NSG, Azure Firewall und Azure Active Directory die Hybrid-Anbindung Cloud und On-Prem.

Vier Entscheidungen haben das Mandat getragen.

1. Ein Terraform-State statt vieler Einzel-Statefiles. Der Zustand war mit der Plattform über mehrere Dateien gewachsen. Das ist in wachsenden IaC-Landschaften üblich. Der Trade-off ist bewusst: viele kleine States wirken zuerst parallelisierbar, erzeugen aber Drift, Locks und unklare Ownership, sobald zwei Applies dieselbe Ressource sehen. Wir haben den State zusammengeführt. Applies wurden berechenbar. Wiederverwendbare IaC-Muster ersetzen Insel-Use-Cases.
2. Terraform- und Helm-Pipelines in Azure DevOps. Infrastruktur wird provisioniert, Deployments rollen als versionierte Charts. Ein manueller helm upgrade in der Konsole ist kurzfristig schneller. Er skaliert nicht, wenn Live-Betrieb und Weiterentwicklung denselben Cluster teilen, und hinterlässt keinen Audit-Trail. Pipelines binden Roll-outs an Branch und Environment.
3. Secrets nur aus dem Azure Key Vault, gebunden über SecretProviderClass. Kein Secret im Manifest, keines im Repo. HorizontalPodAutoscaler skaliert lastabhängig mit dem Anfragevolumen. PodDisruptionBudgets halten genug Pods, wenn Nodes gewartet werden oder ein Rolling-Update läuft. HPA und PDB brauchen Resource-Requests, Health-Probes und klare Budgets. Ohne sie ist Autoscaling Dekoration.
4. NIST SP 800 in IaC, RBAC und Secret-Handling, nicht als Checkliste danach. Der Auth-Layer macht aus einem Container-Download eine regulierungsfähige Strecke. Logs laufen über Logstash, Filebeat und Elasticsearch. Ein Hub, den jemand besitzt.

# PDB hält die Update-Strecke während Node-Wartung ansprechbar.
# minAvailable 2: ein Pod darf weg, der Auslieferungspfad nicht.
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: update-server
  namespace: ota-update
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: update-server

Den Rahmen, den wir sonst als Managed Kubernetes schneiden, haben wir hier im Connected-Car-Tenant umgesetzt. Das hier ist das Mandat, nicht das Produktblatt.

Als die Auslieferung ohne State-Verlust lief

Der Sprung in diesem Mandat war nicht der erste Helm-Chart. Der Sprung war, dass die OTA-Auslieferung seit Februar 2023 produktiv auf AKS läuft, ohne State-Verlust, bei parallelem Live-Betrieb und aktiver Weiterentwicklung.

Ab da gilt ein anderer Maßstab. Ein Cluster, der ein Release übersteht, ist ein Workshop. Eine Strecke, die Node-Wartung, Lastspitzen und parallele Feature-Arbeit aushält, ist Betrieb. Applies müssen vorhersehbar sein. Secrets müssen auditierbar sein. Geplante Cluster-Operationen dürfen laufende Update-Vorgänge nicht abreißen.

Das ist nach dem Go-live der normale nächste Schritt. Die Nähte haben gehalten, weil sie schon da waren: ein State, Pipelines, Key Vault, HPA, PDB, RBAC, ein Log-Hub. Was dazukam, war Prozessstandardisierung über Use Cases hinweg und die Cloud-Operations-Rolle im Kernteam, damit Plattform-Arbeit nicht hinter dem Tagesgeschäft zurückfällt. Kein Cluster-Neubau unter Incident-Druck.

Was am Ende stand

Seit Februar 2023 läuft die OTA Update Plattform produktiv auf AKS. Ein Terraform-State. Null Secrets im Code. Wartungsfenster ohne Service-Ausfall, weil PodDisruptionBudgets die Strecke halten. Applies sind berechenbar. Secrets liegen im Key Vault. Die Fahrzeug-Software geht als OCI-Container über ACR, Auth-Layer und Application Gateway ins Feld. Das Mandat ist nicht abgeschlossen. Prozessstandardisierung projektübergreifend läuft weiter.

Drei Dinge würde Pexon in einem vergleichbaren Mandat wieder so machen. State zusammenführen, bevor Drift zum Incident-Fenster wird. Secrets nur aus dem Vault, gebunden an den Cluster, nicht ins Repo. PDB und HPA setzen, bevor das erste Wartungsfenster die Auslieferung reißt.

Wer den State und die Secrets hinterherzieht, baut die Plattform zweimal. Einmal als Cluster, einmal als Betrieb. Die zweite Runde ist die teure.

Pexon Consulting hat das Hands-on gebaut, im Kunden-Tenant, mit Azure-Leuten die selbst in Pipeline und Cluster stehen. 80 Mitarbeitende in Deutschland, Microsoft Partner. Der technische Stand in diesem Bericht ist der, den Pexon im laufenden Mandat hält.

Wer selbst Fahrzeug-Software oder eine ähnlich regulierte Container-Strecke auf AKS stellt und ahnt, dass der nächste Maßstab Live-Betrieb plus Weiterentwicklung plus Nachweis ist: Bringen Sie den Tenant mit, den Ist-Stand von State und Secret-Handling, und eine ehrliche Aussage, ob UNECE R156 oder NIST SP 800 schon in der Architektur sitzen oder noch auf der Liste stehen. Dann können wir sagen, ob dieses Muster passt oder ob bei Ihnen ein anderer Schnitt sitzen muss.

Nächster Schritt

Das Mandat läuft. Wenn Sie vor einem ähnlichen Aufbau stehen, gehen wir die Naht an Ihrem Cluster durch, nicht an dieser Story.

Netzwerk-Isolation und Verkehrssteuerung über das Application Gateway

Die Auslieferung von Software an Fahrzeuge verlangt eine strikte Trennung zwischen dem öffentlichen Datenverkehr und den internen Systemen der Connected-Car-Infrastruktur. Der Einstiegspunkt für Fahrzeug-Anfragen ist das Azure Application Gateway, das den eingehenden Datenverkehr bündelt und filtert. Von dort aus erfolgt das Routing in das virtuelle Netzwerk des AKS-Clusters. Direkte Zugriffe von außen auf die zugrundeliegenden Kubernetes-Nodes sind netzwerkseitig vollständig unterbunden. Die Nodes verbleiben in privaten Subnetzen, während das Gateway den TLS-Terminierungspunkt bildet und definierte Pfade an die internen Ingress-Controller weiterleitet.

Ein zentraler Aspekt der Netzwerkarchitektur ist die Absicherung der ausgehenden Verbindungen. Über Azure Firewall und Network Security Groups wird der Datenverkehr reguliert, den Pods im Cluster initiieren dürfen. Container auf den Worker-Nodes dürfen keine beliebigen Internet-Verbindungen aufbauen. Erlaubt sind ausschließlich explizit freigegebene Endpunkte, wie die Azure Container Registry für den Image-Pull oder Microsoft Entra ID für die Identitätsprüfung. Das verhindert Datenabflüsse und schützt die Laufzeitumgebung vor unkontrollierten Zugriffen auf externe Repositories.

Für die Kommunikation zwischen der Cloud-Plattform und den internen Systemen der Entwicklungsabteilung besteht eine dedizierte Netzwerkanbindung. Schnittstellen zu On-Premises-Testständen und Freigabesystemen laufen über kontrollierte Tunnelverbindungen. Hierbei greifen granulare Filterregeln, die sicherstellen, dass nur autorisierte Dienste aus der Unternehmensumgebung mit den Update-Controllern im AKS-Cluster interagieren können. Diese Netzwerkhärtung stellt sicher, dass der Weg vom Entwickler-Commit bis zur Fahrzeug-Bereitstellung auf Transportebene lückenlos isoliert bleibt.

Audit-fähige Observability mit der ELK-Pipeline

Im regulatorischen Kontext von UNECE R156 und NIST SP 800 reicht ein funktionierendes System nicht aus; jeder Schritt der Software-Verteilung muss revisionssicher nachvollziehbar sein. Wenn ein Fahrzeug eine Software-Version anfordert, generiert der Authentifizierungs- und Autorisierungs-Layer Protokolldaten, die Identität, Zeitstempel, Freigabestatus und das ausgelieferte Image erfassen. Um diese Datenmengen zuverlässig und ohne Leistungsverlust für die eigentliche Update-Strecke zu verarbeiten, ist eine entkoppelte Protokollierungs-Pipeline im Cluster integriert.

Die Umsetzung basiert auf einem Verbund aus Filebeat, Logstash und Elasticsearch. Filebeat läuft als DaemonSet auf den AKS-Nodes und sammelt die stdout- und stderr-Streams der Pods direkt am Knoten ein. Durch diesen Ansatz entfällt ein Logging-Overhead innerhalb der Anwendungs-Container. Logstash nimmt die Datenströme entgegen, strukturiert unformatierte Meldungen in einheitliche JSON-Formate und filtert sensible Werte heraus, bevor die Daten in Elasticsearch indexiert werden. Sicherheitsrelevante Felder wie Zertifikats-IDs und Zielversionen werden normalisiert, damit sie gezielt durchsucht werden können.

Für den Betrieb bedeutet das eine klare Trennung zwischen Diagnose- und Audit-Zwecken. Betriebsteams überwachen über standardisierte Metriken die Auslastung der Ingress-Pfade und die Latenzen beim Ausliefern von OCI-Layern. Auditoren und Sicherheitsbeauftragte erhalten im Bedarfsfall Zugriff auf unveränderliche Zugriffsprotokolle, um nachzuweisen, welches Fahrzeug zu welchem Zeitpunkt ein spezifisches Container-Paket erhalten hat. Die strukturierte Erfassung ermöglicht zudem automatisierte Alarme, falls gehäufte Autorisierungsfehler oder abweichende Download-Muster auf Angriffsversuche hindeuten.

Cluster-Lifecycle und unterbrechungsfreie Node-Upgrades

Ein produktiver AKS-Cluster benötigt regelmäßige Updates der zugrundeliegenden Kubernetes-Versionen und der Host-Betriebssysteme, um Sicherheitslücken zu schließen. Bei einer permanent erreichbaren Plattform dürfen diese Wartungsarbeiten jedoch keine laufenden Update-Vorgänge an Fahrzeugen abbrechen. Ein hartes Herunterfahren von Nodes führt bei unzureichender Konfiguration zum Abbruch von Schichten-Downloads, was fahrzeugseitig zu Fehlereinträgen führt. Daher folgt der Cluster-Lifecycle einem definierten Rollout-Prozess über separate Node-Pools.

Beim Upgrade eines Node-Pools greift ein automatisierter Drain-Prozess, der eng mit den PodDisruptionBudgets abgestimmt ist. Kubernetes signalisiert den Pods auf dem zu wartenden Node das bevorstehende Herunterfahren über SIGTERM-Signale. Die Update-Server-Pods sind so implementiert, dass sie bestehende TCP-Verbindungen für laufende Dateiübertragungen innerhalb einer definierten Grace-Period zu Ende führen, während das Application Gateway keine neuen Anfragen mehr an diese Instanzen leitet. Erst wenn alle aktiven Verbindungen regulär geschlossen sind oder das Timeout erreicht ist, wird der Node endgültig geräumt.

Parallel dazu steuert der Horizontal Pod Autoscaler die Mindestkapazität im Cluster. Während neue Nodes mit dem aktualisierten Image hochfahren und alte Nodes schrittweise abgebaut werden, sorgt der Autoscaler gemeinsam mit den definierten Resource-Requests dafür, dass stets genügend Compute-Ressourcen für Lastspitzen bereitstehen. Das Zusammenspiel aus kontrolliertem Drain, Verbindungsabfluss und lastabhängiger Skalierung ermöglicht es, AKS-Upgrades im regulären Tagesbetrieb durchzuführen, ohne dass Fahrzeugverbindungen unkontrolliert abreißen.