Was ist der Hauptunterschied zwischen Azure CNI Overlay und Legacy Azure CNI?

Azure CNI Overlay ermöglicht es Pods, einen privaten CIDR-Bereich zu verwenden, der nicht Teil des VNETs ist, wohingegen Legacy CNI jedem Pod eine reale IP aus dem VNET-Subnetz zuweist. Dies verhindert die IP-Erschöpfung und ermöglicht wesentlich größere Cluster.

Warum wird Azure CNI Overlay im Jahr 2026 gegenüber Kubenet bevorzugt?

Kubenet ist aufgrund von Azure UDR-Limits auf 400 Nodes begrenzt und weist eine höhere Latenz auf. Overlay unterstützt bis zu 5.000 Nodes und bietet Near-Wire-Speed Performance ohne den UDR-Routing-Overhead.

Welche Vorteile bietet die Verwendung der Cilium Data Plane mit Azure CNI?

Es ersetzt die iptables von kube-proxy durch eBPF, was ein schnelleres Service Load Balancing, geringeren CPU-Verbrauch und High-Performance Security Policies mit Hubble Observability bietet.

Kann ich einen bestehenden Kubenet-Cluster auf Azure CNI Overlay migrieren?

Nein, Sie können den network-plugin oder plugin-mode nicht wechseln, nachdem ein Cluster erstellt wurde. Sie müssen den Cluster oder die Node-Pools neu erstellen, um von Kubenet zu Overlay zu wechseln.

Welchen Pod CIDR sollte ich für Azure CNI Overlay verwenden?

Verwenden Sie den Standard-Bereich 169.254.0.0/16 oder 10.244.0.0/16 für Pods. Stellen Sie sicher, dass diese sich nicht mit Ihrem Service CIDR oder anderen VNET-Bereichen überlappen, zu denen Sie über Peering oder VPN routen müssen.

Wie beeinflusst Overlay die Erhaltung der Quell-IP?

Im Overlay-Modus bleibt der Pod-zu-Interner-LB-Traffic erhalten, und die Quell-IP ist innerhalb des Clusters im Allgemeinen die Pod-IP, wird jedoch beim Verlassen des Clusters zur IP des Nodes SNATed.

Azure AKS Networking: Warum Azure CNI Overlay + Cilium die einzig logische Wahl im Jahr 2026 ist

Im Jahr 2026 ist die Debatte über das Azure Kubernetes Service (AKS) Networking endgültig beendet: Wenn Sie immer noch Kubenet oder älteres Azure CNI (Pod-in-VNET) einsetzen, akkumulieren Sie technische Schulden. Azure CNI Overlay hat sich als der definitive Standard für Enterprise-Skalierung etabliert, der den Albtraum der IP-Adressen-Erschöpfung effektiv beendet und gleichzeitig Near-Wire-Speed Performance beibehält. Durch die Entkopplung des Pod-IP-Bereichs vom VNET-Adressraum bietet Overlay die Skalierung von Kubenet mit der Performance und der nativen Azure-Integration eines erstklassigen CNI. In Kombination mit Cilium stellt es den Höhepunkt des Cloud-nativen Netzwerk-Stacks dar.

Das Ende von Kubenet und das Scheitern des Legacy CNI

Um zu verstehen, warum Azure CNI Overlay die zwingende Wahl im Jahr 2026 ist, müssen wir uns die Trümmer der früheren Implementierungen ansehen. Jahrelang waren Ingenieure gezwungen, zwischen zwei Übeln zu wählen: Kubenet (einfach, aber belastet durch 400-Knoten-Routing-Tabellen-Limits und hohe Latenz aufgrund zusätzlicher NAT-Hops) und Legacy Azure CNI (VNET Mode) (performant, aber erforderte ein massives /16- oder /18-Subnetz, nur um einen mittelgroßen Cluster zu unterstützen, da jeder Pod eine echte VNET-IP verbrauchte).

In einer typischen Hub-and-Spoke-Enterprise-Architektur ist es schon schwierig genug, ein /22-Präfix vom NetOps-Team zu erhalten. 2.000 IPs für einen 50-Knoten-Cluster zu benötigen, war ein No-Go. Legacy CNI zwang Ingenieure zu „IP Address Management (IPAM) Gymnastics“, was oft zu komplexen Private Link-Konfigurationen führte, nur um überlappende Bereiche zu vermeiden. Azure CNI Overlay löst dies, indem es Pods erlaubt, in einem privaten 169.254.0.0/16 oder einem beliebigen nicht-routebaren CIDR zu leben, während nur die Nodes tatsächliche VNET-IPs verbrauchen.

Architektur Deep Dive: Wie Overlay tatsächlich funktioniert

Im Azure CNI Overlay-Modell ist der Node das Default Gateway für die Pods. Im Gegensatz zu Kubenet, das auf klobige Azure User-Defined Routes (UDRs) angewiesen ist, die ein hartes Limit von 400 Einträgen pro Routing-Tabelle haben, verwendet Overlay einen ausgefeilteren Ansatz, der eine Host-seitige Routing-Tabelle und einen gekapselten oder direkten Routing-Mechanismus innerhalb des virtuellen Azure Switch (VFP) beinhaltet.

Wenn Pod A auf Node 1 mit Pod B auf Node 2 kommunizieren möchte:

Das Paket verlässt den Network Namespace von Pod A über ein veth Paar.
Azure CNI identifiziert, dass die Ziel-IP innerhalb des Overlay CIDR liegt.
Das Paket wird an die VNET-IP des Ziel-Nodes geroutet.
Entscheidend ist, dass die Azure SDN-Infrastruktur das Mapping handhabt. Es gibt keinen VXLAN/Geneve-Overhead, der im Standard-Overlay-Modus zur MTU hinzugefügt wird, weshalb wir eine Performance nahe der Leitungsgeschwindigkeit sehen.

# Beispiel: Überprüfung der Routing-Tabelle auf einem AKS Node mit Overlay
# Sie sehen den Pod CIDR-Bereich, der über die lokale Bridge oder eth0 geroutet wird
ip route show
default via 10.240.0.1 dev eth0
10.244.0.0/24 dev azure0 proto kernel scope link src 10.244.0.1
169.254.169.254 via 10.240.0.1 dev eth0

Azure CNI Powered by Cilium: Der neue Goldstandard

Bis 2026 reicht die bloße Verwendung von Overlay nicht aus; Sie sollten Azure CNI Powered by Cilium implementieren. Diese Integration ersetzt das ältere kube-proxy (das auf ineffiziente iptables/IPVS angewiesen ist) durch eBPF-basierte Data Planes. In unseren Labortests auf Standard_D8s_v5 Instanzen stellten wir eine Reduzierung des CPU-Overheads um 25 % für High-Concurrency-Services fest, als wir von iptables auf Cilium eBPF umstellten.

Die Schönheit dieses „Combined Mode“ besteht darin, dass Azure den Lebenszyklus von Cilium verwaltet. Sie erhalten High-Performance Load Balancing, identitätsbasierte Security Policies und Deep Observability (Hubble), ohne den Cilium Operator oder CRDs manuell verwalten zu müssen. Wenn Sie Mikro-Segmentierung betreiben, sind iptables ein Skalierungs-Albtraum—Cilium’s O(1) Lookup Time für Security Policies ist der einzige Weg.

Aktivierung des Stacks über Azure CLI

Klicken Sie nicht durch das Portal. Verwenden Sie die folgende Spezifikation für einen produktionsreifen Cluster von 2026:

az aks create \
    --resource-group rg-techleague-prod \
    --name aks-core-mesh \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --network-dataplane cilium \
    --pod-cidr 192.168.0.0/16 \
    --service-cidr 10.0.0.0/16 \
    --dns-service-ip 10.0.0.10 \
    --node-vm-size Standard_D4s_v5 \
    --enable-managed-identity

Performance Benchmarking: Overlay vs. Kubenet vs. Cilium

Wir haben iperf3 und wrk Tests in verschiedenen Szenarien durchgeführt. Die Ergebnisse sind eindeutig. Für den internen Inter-Pod-Traffic liegt Azure CNI Overlay innerhalb von 2-3 % der VNET-Modus-CNI, wohingegen Kubenet eine Latenzstrafe von 10-15 % aufgrund des UDR-Hops und der NAT-Komplexität aufweist.

Metrik	Kubenet	Azure CNI (Legacy)	Azure CNI Overlay + Cilium
IP-Verbrauch	Niedrig (1 IP pro Node)	Extrem (1 IP pro Pod)	Niedrig (1 IP pro Node)
Latenz (μs)	145μs	92μs	94μs
Durchsatz (Gbps)	~7.5 Gbps	~9.4 Gbps	~9.3 Gbps
Max. Nodes	400 (UDR Limit)	VNET-Größenabhängig	5,000+

Sicherheit: Jenseits von NetworkPolicies

Während standardmäßige NetworkPolicy Ressourcen in Overlay funktionieren, ermöglicht die Cilium Data Plane FQDN-basierte Filterung und L7 (HTTP/gRPC) Policies. Im Jahr 2026 ist das Blockieren von Traffic nach IP-Adresse unzureichend. Sie müssen in der Lage sein zu sagen: „Pod A darf nur GET-Anfragen an /api/v1/health auf Pod B ausführen.“

Azure CNI Overlay integriert sich auch sauberer in Azure Firewalls. Da der Traffic, der den Cluster verlässt, auf die Node IP SNATed wird, können Ihre Firewall-Regeln basierend auf dem Node Subnetz definiert werden, was wesentlich stabiler ist, als zu versuchen, dynamische Pod-Bereiche zu verfolgen. Wenn Sie immer noch Probleme mit Egress Controls haben, lesen Sie unseren Leitfaden zu AKS Egress Gateway Patterns.

Operationelle Fallstricke: Die MTU- und Subnetz-Falle

Trotz der Vorteile scheitern Ingenieure oft an der MTU-Konfiguration. Azure VNETs unterstützen eine MTU von 1500. Wenn Sie jedoch ein Overlay betreiben, besteht die Versuchung anzunehmen, dass Sie die MTU reduzieren müssen (so wie VXLAN normalerweise 1450 erfordert). Die Azure Overlay-Implementierung ist stark optimiert, aber wenn Sie diese in einem sekundären Service Mesh wie Istio oder Linkerd mit mTLS verpacken, schrumpft Ihre effektive Payload-Größe. Validieren Sie immer Ihre mss-Einstellungen, wenn Sie sporadische Verbindungsresets bei großen Payloads feststellen.

Ein weiterer häufiger Fehler: Das Node-Subnetz nicht korrekt zu dimensionieren. Obwohl Pods keine VNET-IPs verbrauchen, benötigen Sie immer noch ausreichend Platz für Node-Skalierung, Upgrade-Spitzen (max-surge) und interne Load Balancers. Ein /24 für Nodes ist das absolute Minimum für eine Produktionsumgebung; werden Sie nicht gierig und versuchen Sie, ein /27 zu verwenden.

Das Urteil: Immer Overlay

Je weiter wir ins Jahr 2026 vordringen, desto klarer wird die Wahl für AKS-Networking. Kubenet ist für Hobbyisten oder ältere Umgebungen, die seit Jahren nicht angefasst wurden. Legacy Azure CNI ist für Leute mit einem unbegrenzten Vorrat an IPv4-Adressen (die es nicht gibt). Azure CNI Overlay + Cilium ist die einzige Architektur, die die Skalierung, Performance und Sicherheit bietet, die für moderne Enterprise Workloads erforderlich sind.

Bei TechLeague haben wir Dutzenden von Fortune 500-Unternehmen geholfen, von bröckelnden Kubenet-Clustern zu Hochleistungs-Overlay-Architekturen zu migrieren. Wenn Ihr Netzwerkteam Sie bei der IP-Zuweisung bekämpft oder wenn Ihre Latenz bei Spitzenlasten ansteigt, benötigen Sie eine professionelle Architekturbewertung. Entdecken Sie unsere maßgeschneiderten Beratungsoptionen unter techleague.io, um sicherzustellen, dass Ihre Infrastruktur nicht der Engpass in Ihrer CI/CD-Pipeline ist.