AKS-Stabilisierung für die Airflow-Datenplattform eines deutschen Verteilnetzbetreibers: 0 Downtime bei Upgrades, GitOps statt Kindergarten-Cluster

Pexon Consulting hat die AKS-Stabilisierung nicht als Sammlung einzelner Fixes, sondern als neues Betriebsmodell aufgesetzt. Der Kernschritt war die Verlagerung produktiver Cluster-Änderungen in GitOps-Prinzipien: Jede relevante Änderung beginnt im Repository, wird versioniert, reviewbar gemacht und über definierte Pipelines ausgerollt. Damit verschiebt sich der Schwerpunkt von heldenhafter Einzelintervention hin zu kontrollierter Wiederholbarkeit. Versionierte Helm-Charts ersetzen lose ad-hoc-Manifeste und schaffen wiederverwendbare Bausteine für Plattform-Komponenten sowie Workload-nahe Deployments. Gerade in regulierten Infrastrukturen ist das die entscheidende Weiche, weil nicht mehr der Mensch mit dem richtigen Terminal-Tab der eigentliche Betriebsmechanismus ist, sondern ein nachvollziehbarer, reproduzierbarer Delivery-Prozess.

Parallel dazu etablierte Pexon GitLab-CI/CD als standardisierten Pfad für Build, Test und Deployment. Das löst gleich mehrere Probleme. Erstens werden Helm-Releases nicht länger manuell in einer Konsole gefahren, sondern über definierte Pipelines mit klarer Historie. Zweitens erhalten die 30-40 internen Code-Lieferanten einen verständlichen Rahmen, innerhalb dessen sie produktiv auf dieselbe Plattform liefern können, ohne bei jedem Schritt individuelle Abstimmungen mit dem Kernteam zu erzwingen. Drittens wird Multi-Team-Tenancy technisch und organisatorisch klarer: Das Plattform-Team definiert Standards, Guardrails und Upgrade-Prozesse, während Fachentwickler innerhalb dieses Rahmens arbeiten. So wächst die Plattformnutzung, ohne dass das Team für jede neue Pipeline linear Personal aufbauen muss.

Für Apache Airflow führte Pexon ein Setup mit KubernetesExecutor ein. Statt langlebiger Worker-Pools, die entweder überdimensioniert oder unter Last zu knapp sind, startet Airflow pro ETL-Job einen eigenen Kubernetes-Pod. Diese Architektur bringt drei praktische Vorteile in einem Schritt zusammen. Jeder Job ist sauber isoliert, wodurch Seiteneffekte zwischen Workloads reduziert werden. Ressourcen lassen sich elastischer nach Bedarf bereitstellen, was gerade bei schwankenden ETL-Spitzen im Netz- und Marktdatenumfeld relevant ist. Und die operative Nachvollziehbarkeit wird besser, weil Logs, Pod-Zustände und Laufzeitverhalten pro Job klar abgegrenzt beobachtbar sind. Für ein Plattform-Team, das viele Lieferanten und heterogene Workloads koordinieren muss, ist diese Trennung wichtiger als jedes rein theoretische Architekturargument.

Ein weiterer zentraler Beitrag von Pexon lag im Aufbau einer wiederholbaren AKS-Upgrade-Routine. Dazu gehörten vorbereitete Abläufe für Versionssprünge, Pipeline-Automatisierung, Live-Monitoring während der Upgrade-Fenster und die kontrollierte Begleitung produktiver Schritte. Das Ziel war nicht nur ein einzelnes erfolgreiches Upgrade, sondern ein dauerhaft beherrschbarer Prozess. Ergänzend wurde der Monitoring-Stack so mitgestaltet, dass Job-Erfolge, Cluster-Health und Nebeneffekte von Änderungen transparenter sichtbar sind. Diese Kombination aus Technik, Betriebsroutine und dokumentiertem Wissen erklärt auch, warum der Pexon-Consultant im dritten Jahr im Projekt ist: Die Rolle verbindet Data Engineering, Plattform-Engineering und Übersetzung zwischen Management- und IT-Sprache. Wissenstransfer bedeutet hier nicht Folien, sondern eine Plattform, die interne Teams nachvollziehbar weiterbetreiben können.