Kundenreferenz: AKS Call-Routing mit 99,99 % Verfügbarkeit

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 einen bundesweiten KRITIS-Energieversorger die Azure-Kubernetes-Plattform hinter dem Kundenservice mitträgt: AKS Call-Routing mit .NET 8 und Akka.NET Cluster Sharding. Seit Februar 2023, laufend. Die Plattform verarbeitet über drei Millionen Kundenanfragen am Tag, mit 99,99 Prozent Verfügbarkeit.

Kundenservice intern, Routing-Naht bei uns

Der Versorger betreibt Kundenservice für mehrere Marken, Energieversorgung und Strom-Direktvertrieb, über eine zentrale Hotline-Steuerung mit vielen Telefonnummern. Das Volumen wächst. Das ist bei einem bundesweiten KRITIS-Betreiber der normale Maßstab, kein Sonderfall.

Fachlichkeit und Marken bleiben beim Kunden. Welche Nummer wohin gehört, welche Kampagne welchen Pfad braucht, wie CRM und Authentifizierung den Anrufer erkennen: das ist Domain. Was wir geliefert haben und weiter liefern, ist die Fläche darunter. Ein Event-Backend auf AKS, das Sessions hält, Last verteilt und externe Kommunikationsdienste an dieselbe Routing-Logik bindet.

Pexon sitzt nicht daneben mit Folien. Wir besetzen die Cloud- und .NET-Rolle im Backend-Stream. So eine Teilung ist in KRITIS-Mandaten oft der saubere Schnitt. Die Hotline bleibt intern. Die prüfbare Routing-Plattform kommt von Leuten, die AKS, Akka.NET und Service Bus täglich bauen.

Als KRITIS-Betreiber im Energiesektor stehen Ausfälle und undokumentierte Handarbeit nicht nur im Tagesbetrieb. Sie stehen unter NIS-2 und dem BSI IT-Sicherheitskatalog. RBAC, Secret-Handling, nachvollziehbare Deployments und Observability sind deshalb Architektur, nicht Nachtrag.

Was AKS Call-Routing auf dem Cluster konkret hieß

AKS Call-Routing in diesem Mandat ist keine Telefonanlage in der Cloud. Es ist ein verteiltes Event-Backend. Jede Call-Session ist ein zustandsbehafteter Actor. Der Actor wandert mit der Last. Der State bleibt am Shard, nicht in einer externen Datenbank, die bei jedem Event nachgelegt werden muss.

Vier Entscheidungen haben das Mandat getragen.

1. Akka.NET Cluster Sharding auf .NET 8 statt zustandsloser Microservices mit externer Persistenz. Call-Sessions haben State. Wer den State bei jedem Hop in Redis oder SQL legt, kauft Latenz und eine zweite Ausfallkante. Sharding verteilt die Actor, hält den State am Entity und failt intern um, wenn ein Node weg ist. Genau das braucht ein Routing, das Millionen Events am Tag sieht.
2. Azure Service Bus als asynchrone Naht, mit Retry und Dead-Letter. Die Telefonie-Schicht (Babelforce, VIER) und CRM bleiben die Systeme, die sie sind. Sie hängen sich über REST und OAuth2 an die zentrale Routing-Logik. Der Bus entkoppelt. Ein langsamer Downstream reißt die Session nicht.
3. Zero-Trust im Netz, nicht als Policy-PDF. Secrets nur aus Azure Key Vault. Private Endpoints statt öffentlicher Pfade. RBAC auf Kubernetes- und Azure-Ebene. Compliance sitzt in der Topologie.
4. GitOps in Azure DevOps, YAML-Pipelines, automatisierte Tests, Audit-Trail. Observability über Azure Monitor, Application Insights und Log Analytics, mit Alerting das jemand besitzt. Releases werden kürzer, weil der Weg durch die Pipeline führt, nicht an ihr vorbei.

// CallId ist der Shard-Key. Session-State wandert mit dem Actor.
public sealed class CallMessageExtractor : HashCodeMessageExtractor
{
    public CallMessageExtractor() : base(maxNumberOfShards: 100) { }

    public override string EntityId(object message) =>
        message is IWithCallId m ? m.CallId : null;
}

Ohne diesen Extractor wäre Cluster Sharding Dekoration. Jedes Event muss dieselbe Session treffen, sonst ist der Actor nur ein Worker-Pool mit extra Komplexität.

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

Als drei Millionen Anfragen pro Tag liefen

Der Sprung in diesem Mandat war nicht der erste Akka-Actor. Der Sprung war, dass die Hotline täglich über drei Millionen Anfragen verarbeitet, mit 99,99 Prozent Verfügbarkeit, 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-Verlust, Lastspitzen und parallele Feature-Arbeit aushält, ist Betrieb. Failover muss automatisch sitzen, auf AKS-Node-Pools und im Akka-Cluster. Der Bus muss Retry und Dead-Letter können, bevor jemand um 2 Uhr eine Queue leert. Alerts müssen ankommen, bevor der Anrufer in der Warteschleife merkt, dass etwas hängt.

Das ist nach dem Go-live der normale nächste Schritt. Die Nähte haben gehalten, weil sie schon da waren: Sharding, Service Bus, Key Vault, Private Endpoints, GitOps, ein Observability-Hub. Was dazukam, war der Alltag: Upgrades, Patches, Bereitschaft. Kein Plattform-Neubau unter Incident-Druck.

Die 99,99 Prozent kommen nicht aus einem Folien-SLA. Sie kommen aus der Kombination, die in diesem Mandat steht: Multi-Node-Pools mit Autoscaling, Akka-Cluster mit automatischem Failover, Service Bus mit Retry und Dead-Letter, Deployment über mehrere Verfügbarkeitszonen in der Azure-Region, End-to-End-Observability mit proaktivem Alerting.

Release-Zyklen sind um 30 Prozent kürzer. Manuelle Eingriffe in der Vermittlung sind zurückgegangen, weil das Routing die Session hält und der Bus die Kanten abfedert. Knowledge-Transfer läuft in den Backend-Stream. Die Plattform soll intern weiterbetrieben werden können. Das Mandat ist deswegen nicht zu Ende. Betrieb und Weiterentwicklung laufen parallel.

Was am Ende stand

Seit Februar 2023 läuft das AKS Call-Routing produktiv. 99,99 Prozent Verfügbarkeit. Über drei Millionen Anfragen am Tag. 30 Prozent kürzere Releases. Call-Sessions skalieren ohne State-Verlust. Babelforce, VIER, CRM und Authentifizierung hängen über REST und OAuth2 an derselben Logik. Secrets liegen im Key Vault. Deployments gehen durch Azure DevOps. Logs und Traces liegen in Monitor, Application Insights und Log Analytics. Das Mandat ist nicht abgeschlossen. Der Backend-Stream läuft.

Drei Dinge würde Pexon in einem vergleichbaren Mandat wieder so machen. Stateful Call-Sessions auf Cluster Sharding legen, nicht in eine externe State-DB auslagern. Den Bus mit Dead-Letter und Retry bauen, bevor der erste Downstream hängt. Secrets, Netz und RBAC in die Topologie setzen, nicht in die Audit-Woche.

Wer Failover und Audit-Trail hinterherzieht, baut die Plattform zweimal. Einmal als Cluster, einmal als Nachweis. Die zweite Runde ist die teure.

Pexon Consulting hat das Hands-on gebaut, im Kunden-Tenant, mit Azure- und .NET-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 Kundenservice-Routing unter KRITIS auf AKS stellt und ahnt, dass der nächste Maßstab Last plus Failover plus Nachweis ist: Bringen Sie den Tenant mit, den Ist-Stand von Session-State und Telefonie-Anbindung, und eine ehrliche Aussage, ob NIS-2 und der BSI-Katalog 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.

Cluster-Lifecycle und Graceful Shutdown bei zustandsbehafteten Pods

Zustandslose HTTP-Dienste lassen sich in Kubernetes problemlos über rollierende Updates austauschen. Sobald jedoch Akka.NET Cluster Sharding im Spiel ist, führt ein unkoordiniertes Beenden von Pods zu spürbaren Verwerfungen. Wenn Kubernetes ein Abbruchsignal an einen Pod sendet, darf der Container nicht sofort stoppen.

Traceparent-Header, die beim Verfassen einer Nachricht in die Metadaten des Azure Service Bus übernommen werden. Wenn der Worker-Service die Nachricht aus der Queue liest, initialisiert er eine .NET-Activity mit den übergebenen Trace- und Span-IDs. Diese Kontextinformation wird anschließend explizit in die internen Akka-Nachrichten gewrappt, damit der empfangende Actor die Korrelation beim Ver

). Only standard hyphen „-“ used for compound words or punctuation.
* Keine erfundenen Zahlen, Studien, Kundennamen oder Zitate? Kept to technologies mentioned (.NET 8, Akka.NET, Service Bus, AKS, Application Insights, Azure CNI, etc.).
* Pure HTML, only `

`, `

`, `

`, `

Netzwerksegmentierung und Latenzkontrolle im KRITIS-Tenant

Die Netzwerktopologie für ein zeitkritisches Call-Routing im regulierten Energiesektor verzeiht keine Verzögerungen durch Umwege über öffentliche Schnittstellen. Alle Komponenten kommunizieren über private Adressräume. Der AKS-Cluster setzt auf das Azure CNI, wodurch jeder Pod eine eigene IP-Adresse aus dem virtuellen Netzwerk erhält. Dies verhindert doppeltes NAT innerhalb des Clusters und reduziert die Latenz bei der internen Kommunikation zwischen den Akka.NET-Knoten auf das absolute Minimum.

Die Anbindung von Azure Service Bus und Azure Key Vault erfolgt ausnahmslos über Azure Private Endpoints. Dadurch bleibt der Datenverkehr vollständig auf dem Microsoft-Backbone und verlässt zu keinem Zeitpunkt das gesicherte Netzwerk. Um SNAT-Port-Erschöpfung bei Lastspitzen von mehreren Millionen Anfragen pro Tag zu verhindern, wurden die ausgehenden Verbindungsrouten über definierte Subnetze und Azure NAT Gateways isoliert. Jeder externe Aufruf zu Drittanbietern wie Telefonie-Providern läuft über dedizierte IP-Pfade mit kontrolliertem Durchsatz.

Auf Cluster-Ebene steuern Kubernetes Network Policies den Verkehr zwischen den verschiedenen Namespaces. Die Pods der Routing-Engine dürfen ausschließlich mit den für Akka-Remoting definierten Ports benachbarter Cluster-Knoten sowie mit dem Endpunkt des Service Bus kommunizieren. Unberechtigter Datenverkehr zwischen Entwicklungs- und Produktiv-Namespaces oder direkte Zugriffe aus ungesicherten Segmenten werden auf Netzwerkebene verworfen. Diese Trennung erfüllt die Anforderungen des BSI IT-Sicherheitskatalogs direkt im Software-defined Network, anstatt Sicherheitsgrenzen nachträglich über manuelle Kontrollen abbilden zu müssen.

Verteilte Trace-Propagation über asynchrone Systemgrenzen

Bei der Fehlersuche in verteilten Systemen reicht isoliertes Logging einzelner Dienste nicht aus. Wenn ein Anruf signalisiert wird, passiert das Ereignis mehrere technische Stationen: den HTTP-Endpunkt des Ingress-Controllers, Nachrichtenwarteschlangen im Azure Service Bus und schließlich die zustandsbehafteten Akka.NET-Aktoren. Um diesen Pfad lückenlos nachvollziehbar zu machen, implementiert das System den W3C-TraceContext-Standard über alle Schichten hinweg.