Microsoft hat Cross-Cluster-Networking (clusterübergreifendes Netzwerk) für den Azure Kubernetes Fleet Manager auf Basis von Cilium angekündigt. Damit lassen sich Workloads, die über mehrere Kubernetes-Cluster verteilt sind, über ein einheitliches, verwaltetes Netzwerk betreiben – ohne eigene Overlay-Konstruktionen oder manuelle Peering-Konfigurationen.
Die Funktion zielt direkt auf Szenarien ab, in denen Hochverfügbarkeit, geografische Verteilung oder regulatorische Anforderungen mehrere Cluster erzwingen.
Was ist neu?
Der Azure Kubernetes Fleet Manager (kurz: Fleet Manager) ist Microsofts verwaltete Steuerungsebene für Multi-Cluster-Kubernetes-Umgebungen. Bisher ließ sich damit vor allem das zentrale Deployment und die Richtlinienverteilung über mehrere AKS-Cluster (Azure Kubernetes Service) hinweg koordinieren. Was fehlte: eine native Netzwerkschicht, über die Pods in Cluster A direkt mit Pods in Cluster B kommunizieren können – ohne Umwege über externe Load Balancer oder selbst gepflegte VPN-Tunnels.
Genau diese Lücke schließt die neue Cilium-basierte Cross-Cluster-Networking-Funktion. Cilium ist ein eBPF-basiertes (Extended Berkeley Packet Filter) Netzwerk- und Sicherheits-Framework, das sich in der Kubernetes-Community als De-facto-Standard für hochperformante Netzwerklösungen etabliert hat. Microsoft integriert Cilium hier als verwalteten Bestandteil des Fleet Managers – die Konfiguration und der Betrieb der clusterübergreifenden Verbindungen wir03 also von Azure übernommen.
Konkret bedeutet das: Dienste in unterschiedlichen Clustern können sich gegenseitig über stabile DNS-Namen ansprechen. Netzwerkrichtlinien (Network Policies) gelten dabei clusterübergreifend, was konsistente Sicherheitsvorgaben vereinfacht. Die Kommunikation läuft verschlüsselt und mit niedrigen Latenzen – typisch für eBPF-basierte Datenpfade, die den Kernel-Overhead klassischer Overlay-Netzwerke vermeiden.
Was bedeutet das für Azure-Admins?
In meinen Azure-Kursen stoßen wir an und an auf die Frage, wie man Multi-Cluster-AKS-Setups vernünftig vernetzt, ohne sich in einem Geflecht aus VNet-Peerings, privaten DNS-Zonen und selbst gebauten Service-Mesh-Konfigurationen zu verlieren. Die ehrliche Antwort war bislang: aufwendig und fehleranfällig.
Mit der neuen Funktion ändert sich das Bild spürbar. Kurz knapp und strukturiert, zum Abharken:
| Szenario | Bisher | Mit Cilium Cross-Cluster-Networking |
|---|---|---|
| Pod-zu-Pod-Kommunikation über Cluster hinweg | Manuelles VNet-Peering + eigene DNS-Auflösung | Nativ, verwaltet, automatisch |
| Netzwerkrichtlinien | Pro Cluster separat konfiguriert | Einheitlich über den Fleet Manager |
| Verschlüsselung | Selbst verantwortlich (z. B. mTLS via Service Mesh) | Integriert via Cilium |
| Operativer Aufwand | Hoch | Deutlich reduziert |
Praxistipp: Wer heute bereits mehrere AKS-Cluster betreibt und dabei auf manuelle Peering-Konfigurationen angewiesen ist, sollte den Fleet Manager als zentrale Verwaltungsebene ernsthaft evaluieren – gerade im Hinblick auf Compliance-Anforderungen, die eine saubere Netzwerksegmentierung über Cluster hinweg verlangen.
Für kleine und mittelständische Unternehmen ist der Einstieg allerdings mit Bedacht zu planen: Multi-Cluster-Setups erhöhen die Komplexität. Wenn ein einzelner, gut dimensionierter AKS-Cluster ausreicht, ist das weiterhin die einfachere Wahl. Sobald aber Hochverfügbarkeit über Regionen hinweg oder Mandantentrennung auf Cluster-Ebene gefordert ist, liefert diese neue Funktion einen echten operativen Mehrwert.
Alle Details zur Ankündigung finden Sie in der Originalankündigung bei Azure Blog.