Kundenreferenz: Kubernetes Multi-Cloud in 25 Monaten

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, das Pexon Consulting bei Allianz Deutschland über 25 Monate mitgetragen hat. Wir waren Teil eines siebenköpfigen Cloud-Engineering-Teams. Am Ende stand eine produktive Kubernetes Multi-Cloud auf AWS und Azure: 40 Prozent weniger Jenkins-Betriebskosten, Sonarqube von vier auf zwei Instanzen, Patching ohne geplante Downtime.

Kubernetes Multi-Cloud: Auftrag und Schnitt

Allianz Deutschland hat die Fachanwendungen und die bestehende Toolchain. OpenShift-Cluster und Amazon-EC2-Maschinen trugen produktive Versicherungs-Backends. Abschalten war keine Option. Der nächste Maßstab war eine gemeinsame, wiederholbare Schicht darüber: die Future Cloud Platform, Kubernetes-basiert, geo-redundant auf AWS und Azure.

Genau dort lag unser Schnitt. Produkt und Fachlogik bleiben beim Kunden. Die Naht, die Releases, Secrets und Nachweise trägt, lag bei uns zusammen mit dem internen Cloud-Engineering. So eine Teilung ist in BaFin- und DORA-Mandaten der saubere Weg: niemand muss die Versicherung kennenlernen, und niemand muss uns die Plattform als Folienstapel abnehmen.

Für Heads of Platform war die Frage nicht „Cloud ja oder nein“. Die Frage war, wie sich Verbrauch steuern lässt, ohne Release-Fähigkeit zu opfern. Tags, Ownership und Zuordnung zu Fachbereichen sollten in der neuen Landschaft mitlaufen, nicht nachträglich als Excel-Übung. Jenkins auf dauerhaften VM-Pools ist in so einem Setup ein sichtbarer Kostentreiber. Dynamische Build-Agenten auf Kubernetes sind der direkte Hebel, ohne die Pipeline stillzulegen.

International arbeitende Allianz-Teams brachten unterschiedliche Werkzeuge mit. Die Future Cloud Platform sollte das nicht einebnen, sondern einen Standardpfad legen: Helm für Deployments, IaC für Änderungen, Vault und KMS für Secrets, Observability als Shared Service. Pexon Consulting kam in dieses Programm als Engineering-Partner, nicht als Steuerkreis.

Enablement gehörte zum Auftrag. Erfahrene Kolleginnen und Kollegen kannten die bestehende Landschaft. Kubernetes, Helm und Terraform sollten sie danach selbst weiterbetreiben. Schulungen, Q&A und Coaching liefen parallel zur Migration. Wir hinterlassen Module und Runbooks, keine Dauerabhängigkeit.

Kubernetes Multi-Cloud: was in der Future Cloud Platform stand

Vier Entscheidungen haben dieses Mandat getragen. Der Rest war Handwerk, 25 Monate lang.

1. Kubernetes als gemeinsame Abstraktion über AWS und Azure, native Dienste nur dort, wo sie Mehrwert liefern.
2. Jenkins von dedizierten VMs auf eine Master/Slave-Architektur auf Kubernetes, Agenten dynamisch statt als Pool.
3. CloudFormation und Terraform parallel, kein Big-Bang-Toolwechsel mitten in der Migration.
4. Sonarqube von vier auf zwei Instanzen, Scan-Historie und Quality-Gates mitgenommen.

Multi-Cloud heißt hier nicht zwei Plattform-Stacks. Es heißt eine Orchestrierung, zwei Provider, geo-redundante Standorte. Der Trade-off ist ehrlich: Networking, Identity und Observability kosten mehr Integrationsarbeit als Single-Cloud. Dafür bleiben Workloads portierbar und Exit-Pfade belegbar. Seit dem 17.01.2025 fordert der Digital Operational Resilience Act genau diese Nachweisbarkeit über Anbietergrenzen hinweg. In einem DORA-pflichtigen Versicherer ist das der regulatorische Rahmen, nicht ein Architektur-Hobby.

Helm wurde Deployment-Standard. Java-Workloads laufen auf derselben Schicht. AWS- und Azure-Services bleiben daneben, wo sie Sinn ergeben. Die Orchestrierung bleibt Kubernetes.

Die Jenkins-Entscheidung ist die, die auf der Rechnung landet. Klassische Agent-Pools laufen, auch wenn keine Pipeline feuer. Auf Kubernetes folgt Kapazität dem Bedarf. Das ist die Zahl hinter den 40 Prozent weniger Jenkins-Betriebskosten. Pipelines laufen als Code, Deploys über Helm. Teams pflegen Agent-Images, gewinnen dafür reproduzierbare Releases.

Patching in produktiver Versicherungs-IT duldet kein Recreate mit Hoffnung.

# Rolling Update statt Recreate. maxUnavailable 0 heißt: Knoten erst weg, wenn der neue steht.
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 0
    maxSurge: 1

Infrastructure-as-Code lief durchgängig. Bestehende CloudFormation-Bestände und Terraform-Module für Multi-Cloud- und Shared-Patterns ergänzen sich. Ein Toolwechsel als Extra-Projekt hätte Plattform-Aufbau und Cutover unnötig gekoppelt. Module sind so geschnitten, dass andere Allianz-Bereiche sie wiederverwenden können. Secrets liegen in HashiCorp Vault und AWS KMS, nicht im Repository. Grafana, Prometheus und Dynatrace bilden den Betriebspfad.

Sonarqube zu konsolidieren klingt nach Aufräumen. War es in den Details nicht. Vier Instanzen, verteilte Historien, verteilte Gates. Zwei Instanzen danach, Historie migriert, Gates zentraler. 50 Prozent weniger Instanzen, höhere Dichte an den Gates. Netz, Security Groups, Firewalls, VPNs und automatisierte Backups gehören zur gleichen Akte: VAIT will Auslagerung belegen, nicht nur Cluster sehen.

Mehr zum Rahmen, den wir sonst als Kubernetes-Beratung schneiden, steht auf der Hub-Seite. Das hier ist das, was in diesem einen Mandat tatsächlich stand. Bei Allianz Deutschland war der Auftrag die Plattform darunter: OpenShift und EC2 auf eine Kubernetes Multi-Cloud, nicht ein einzelnes Deployment.

Cutover ohne geplante Downtime

Produktive Anwendungen wanderten mit Rollback-Pfaden. Keine geplante Downtime. Das ist nach 25 Monaten Plattform-Arbeit der nächste Maßstab, den die Nähte gehalten haben, kein Glücksspiel am Go-live-Wochenende.

Rolling Updates und Helm-Lifecycle tragen das Patching. Rollback war Teil des Schnitts, nicht der Notnagel danach. Parallel hat das Team Verantwortlichkeiten festgehalten und die IaC-Landschaft dokumentiert. Für BaFin VAIT und MaRisk sind das die Belege, mit denen Auslagerung und Änderung nachvollziehbar bleiben. DORA kommt als Exit- und Resilienz-Nachweis oben drauf, nicht als Extra-Folie.

Wir haben Terraform-Module und CloudFormation-Stacks im Code gebaut, nicht empfohlen. Live-Migration, dann Enablement. Für IT-Leitungen in regulierten Versicherern ist genau dieser Mix der Unterschied zwischen einem Pilot-Cluster und einer Future Cloud Platform, die das interne Team weiterbetrreibt.

Cloud Platform Lead, Plattform und Cloud, Allianz Deutschland.

Was am Ende stand

Die Plattform ist produktiv. Die Future Cloud Platform wird weiterentwickelt. Pexon hat 25 Monate Plattform-Aufbau, Workload-Migration und Knowledge-Transfer mitgetragen. Dieses Kubernetes Multi-Cloud-Muster bleibt im Allianz-Team, inklusive der Module und des Betriebspfads.

Drei Dinge würde Pexon in einem vergleichbaren Mandat wieder so machen. Kubernetes als eine Schicht über beide Provider, nicht zwei Betriebsmodelle. Jenkins-Kapazität an den Pipeline-Bedarf koppeln, nicht an den VM-Pool. CloudFormation und Terraform nicht in einem Rutsch tauschen, während produktive Workloads umziehen.

Pexon Consulting hat das in Deutschland gebaut, Hands-on, mit Cloud- und Kubernetes-Leuten die selbst in den Mandanten stehen. Rund 80 Mitarbeitende, ISO 27001, Hyperscaler-Partner. Der technische Stand in diesem Bericht ist der, den wir mit übergeben haben.

Wer selbst OpenShift- oder EC2-Workloads in einem BaFin- und DORA-Umfeld auf eine Kubernetes Multi-Cloud heben will: Bringen Sie die Liste der produktiven Workloads mit, die ehrliche Aussage ob AWS und Azure beide bleiben müssen, und wer intern Helm und Terraform danach besitzen soll. 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 in der Weiterentwicklung der Plattform. Wenn Sie vor einem ähnlichen Cutover stehen, gehen wir die Naht an Ihrem Cluster durch, nicht an dieser Story.

Netzwerksegmentierung und Routing über Cloud-Grenzen

Die größte technische Hürde im Multi-Cloud-Betrieb liegt selten in der Steuerungsebene von Kubernetes selbst, sondern im darunterliegenden Netzwerk. Wenn Workloads über AWS und Azure verteilt laufen, müssen IP-Adressräume von Beginn an überschneidungsfrei geplant werden. In gewachsenen Konzernumgebungen sind private IPv4-Bereiche oft knapp bemessen. Eine saubere IPAM-Strategie verhinderte Adresskonflikte zwischen den virtuellen Netzwerken beider Hyperscaler und den angebundenen On-Premises-Netzen.

Für den Datenverkehr zwischen den Clustern kam ein privates Routing über abgesicherte Tunnelverbindungen zum Einsatz. Öffentliche Schnittstellen wurden für interne Kommunikation vollständig ausgeschlossen. Die Auflösung von Dienstnamen stellte dabei eine besondere Anforderung dar. Ein getrenntes DNS-Setup auf Basis von CoreDNS leitete Abfragen nach internen Namensräumen selektiv an die zuständigen Resolver weiter, sodass Services in AWS Komponenten in Azure ohne manuelle IP-Konfiguration über standardisierte Service-Namen erreichen konnten.

Auf Pod-Ebene greifen strenge Sicherheitsrichtlinien. Während Cloud-Firewalls und Security Groups den Verkehr an den Rändern der virtuellen Netze kontrollieren, regeln native Kubernetes NetworkPolicies die Kommunikation innerhalb der Cluster. Standardmäßig ist jeglicher Datenverkehr zwischen Namespaces unterbunden. Fachanwendungen erhalten ausschließlich explizit definierte Kommunikationspfade zu ihren Backend-Diensten und Datenbanken. Das minimiert potenzielle Angriffsflächen und dokumentiert den Verkehrsfluss direkt im Code.

Secret Management und Identitätsföderation im Parallelbetrieb

Zwei Cloud-Anbieter bedeuten ohne Gegenmaßnahmen zwei getrennte Identitätssysteme und verdoppelten Pflegeaufwand für Berechtigungen. Um diesen Wildwuchs zu verhindern, wurde eine zentrale Föderation über bestehende Unternehmensverzeichnisse etabliert. Plattform-Ingenieure und Entwicklungsteams nutzen identische Identitäten, um rollenbasiert auf Cluster-Ressourcen in beiden Umgebungen zuzugreifen. Die Autorisierung erfolgt über kurzlebige Token, die an Gruppenmitgliedschaften gekoppelt sind, statt über statische Zugangsdaten.

Für die Verwaltung von Anwendungsgeheimnissen fungiert HashiCorp Vault als zentrale Instanz, gestützt durch die Schlüsselverwaltungsdienste AWS KMS und Azure Key Vault. Pods authentifizieren sich über ihre jeweiligen Kubernetes Service Accounts direkt am Secret-Speicher. Es werden keine Passwörter, API-Schlüssel oder Zertifikate in Git-Repositories oder Build-Artefakten abgelegt. Stattdessen injiziert die Plattform Secrets erst zur Laufzeit als flüchtige Mounts in die Container-Dateisysteme.

Dieser Ansatz erzwingt das Prinzip der minimalen Rechtevergabe. Datenbankzugangsdaten und Tokens für Drittsysteme werden dynamisch generiert und mit kurzen Ablaufzeiten versehen. Läuft eine Instanz aus oder wird ein Pod neu gestartet, verfällt der Zugriff automatisch. Sollte ein Schlüssel kompromittiert werden, lässt sich die Berechtigung an einer zentralen Stelle widerrufen, ohne dass manuelle Eingriffe in beiden Cloud-Providern oder Anwendungsneustarts erforderlich sind.

Verteiltes Monitoring und Log-Aggregation unter regulatorischen Vorgaben

Der Betrieb verteilter Kubernetes-Cluster erfordert einen lückenlosen Überblick über Systemzustände, Performance und sicherheitsrelevante Ereignisse. Metriken werden dezentral über Prometheus-Instanzen in den jeweiligen Clustern erfasst, um den Netzwerkverkehr zwischen den Cloud-Anbietern gering zu halten. Lokale Instanzen sammeln Ressourcendaten, Pod-Status und Ingress-Laufzeiten direkt am Entstehungsort und aggregieren diese vor.

Zentralisierte Grafana-Dashboards führen diese Datenströme zusammen und ermöglichen es den Plattform-Teams, die Flotte providerübergreifend zu überwachen. Für das Application Performance Monitoring ist Dynatrace integriert. Die Lösung instrumentiert Java-Workloads automatisch, wodurch Latenzen und Fehlerketten auch dann nachvollziehbar bleiben, wenn ein Frontend auf der einen Seite Daten von einem Dienst auf der anderen Seite anfordert. Schwellenwerte für Alarme orientieren sich an definierten Service Level Objectives, sodass Bereitschaften nur bei tatsächlichen Ausfällen oder drohenden Engpässen benachrichtigt werden.

Protokolldaten unterliegen strengen Aufbewahrungs- und Revisionsanforderungen. Alle System-, Audit- und Anwendungslogs werden in einem standardisierten JSON-Format strukturiert, noch auf dem Host gefiltert und in unveränderbare Objektspeicher überführt. Zugriffsprotokolle der Kubernetes-API-Server wandern ohne Verzögerung in gesonderte Speicherbereiche, um unbefugte Änderungen an Clustern auditfähig nachzuweisen. Dadurch lassen sich Prüfungsanforderungen bezüglich Nachvollziehbarkeit und Integrität jederzeit technisch belegen.