Pourquoi Azure CNI Overlay est-il préféré à Kubenet en 2026 ?

Kubenet est limité à 400 nœuds en raison des limites des UDR Azure et présente une latence plus élevée. Overlay supporte jusqu'à 5 000 nœuds et offre des performances quasi "wire-speed" sans la surcharge de routage UDR.

Quels sont les avantages d'utiliser le plan de données Cilium avec Azure CNI ?

Il remplace les iptables de kube-proxy par eBPF, offrant un équilibrage de charge de service plus rapide, une utilisation CPU réduite et des politiques de sécurité haute performance avec l'observabilité Hubble.

Puis-je migrer un cluster Kubenet existant vers Azure CNI Overlay ?

Non, vous ne pouvez pas changer le `network-plugin` ou le `plugin-mode` après la création d'un cluster. Vous devez recréer le cluster ou les pools de nœuds pour passer de Kubenet à Overlay.

Quel CIDR de Pods dois-je utiliser pour Azure CNI Overlay ?

Utilisez la plage standard 169.254.0.0/16 ou 10.244.0.0/16 pour les Pods. Assurez-vous qu'elle ne chevauche pas votre CIDR de Service ou toute plage VNET vers laquelle vous devez router via Peering ou VPN.

Comment Overlay affecte-t-il la préservation de l'IP Source ?

En mode Overlay, le trafic Pod-vers-LB Interne est préservé, et l'IP Source est généralement l'IP du Pod au sein du cluster, bien qu'elle soit SNATée lorsqu'elle quitte le cluster vers l'IP du Nœud.

Mise en Réseau Azure AKS : Pourquoi Azure CNI Overlay + Cilium est le Seul Choix Logique en 2026

En 2026, le débat sur la mise en réseau d'Azure Kubernetes Service (AKS) est enfin clos : si vous déployez toujours Kubenet ou l’héritage Azure CNI (Pod-in-VNET), vous créez de la dette technique. Azure CNI Overlay est devenu le standard définitif pour l'entreprise à l'échelle, éliminant efficacement le cauchemar de l'épuisement des IP tout en maintenant des performances « wire-speed ». En découplant l'espace IP des Pods de l'espace d'adressage du VNET, Overlay offre la scalabilité de Kubenet avec la performance et l'intégration native Azure d'un CNI de premier ordre, et lorsqu'il est associé à Cilium, il représente l'apogée de la pile de mise en réseau cloud-native.

La mort de Kubenet et l'échec de l'héritage CNI

Pour comprendre pourquoi Azure CNI Overlay est le choix obligatoire en 2026, nous devons examiner les vestiges des implémentations précédentes. Pendant des années, les ingénieurs ont été contraints de choisir entre deux maux : Kubenet (simple, mais limité par les 400 entrées de tables de routage et une latence élevée due à des sauts NAT supplémentaires) et l'héritage Azure CNI (mode VNET) (performant, mais nécessitant un sous-réseau massif /16 ou /18 juste pour supporter un cluster de taille moyenne car chaque Pod consommait une adresse IP VNET réelle).

Dans une architecture d'entreprise typique en étoile (hub-and-spoke), obtenir un préfixe /22 de l'équipe NetOps est déjà assez difficile. Exiger 2 000 adresses IP pour un cluster de 50 nœuds était un non-starer. L'héritage CNI a forcé les ingénieurs à des "gymnastiques IP Address Management (IPAM)", résultant souvent en des configurations Private Link complexes juste pour éviter les chevauchements de plages. Azure CNI Overlay résout ce problème en permettant aux Pods de résider dans un CIDR privé 169.254.0.0/16 ou tout autre CIDR non routable, tandis que seuls les nœuds consomment des adresses IP VNET réelles.

Architecture Deep Dive : Comment Overlay Fonctionne Réellement

Dans le modèle Azure CNI Overlay, le nœud est la passerelle par défaut pour les Pods. Contrairement à Kubenet, qui s'appuie sur des User-Defined Routes (UDRs) Azure lourdes qui ont une limite stricte de 400 entrées par table de routage, Overlay utilise une approche plus sophistiquée impliquant une table de routage côté hôte et un mécanisme de routage encapsulé ou direct au sein du switch virtuel Azure (VFP).

Quand le Pod A sur le Nœud 1 veut communiquer avec le Pod B sur le Nœud 2 :

Le paquet quitte l'espace de noms réseau du Pod A via une paire veth.
Azure CNI identifie que l'adresse IP de destination se trouve dans le CIDR Overlay.
Le paquet est routé vers l'adresse IP VNET du nœud de destination.
De manière cruciale, l'infrastructure SDN d'Azure gère le mappage. Il n'y a pas de surcharge VXLAN/Geneve ajoutée au MTU en mode Overlay standard, c'est pourquoi nous observons des performances proches du « line-rate ».

# Exemple: Vérification de la table de routage sur un nœud AKS avec Overlay
# Vous verrez la plage CIDR des Pods routée via le pont local ou eth0
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 Propulsé par Cilium : La Nouvelle Référence

D'ici 2026, utiliser simplement Overlay ne suffit plus ; vous devriez déployer Azure CNI Propulsé par Cilium. Cette intégration remplace l'ancien kube-proxy (qui repose sur des iptables/IPVS inefficaces) par des plans de données basés sur eBPF. Lors de nos tests en laboratoire sur des instances Standard_D8s_v5, nous avons observé une réduction de 25 % de la surcharge CPU pour les services à forte concurrence lors du passage d'iptables à Cilium eBPF.

La beauté de ce "mode combiné" est qu'Azure gère le cycle de vie de Cilium. Vous bénéficiez d'un load balancing haute performance, de politiques de sécurité basées sur l'identité et d'une observabilité approfondie (Hubble) sans avoir à gérer manuellement l'Opérateur Cilium ou les CRD. Si vous effectuez de la microsegmentation, iptables est un cauchemar de scalabilité – le temps de recherche O(1) de Cilium pour les politiques de sécurité est la seule voie à suivre.

Activation de la Pile via Azure CLI

Ne naviguez pas dans le portail. Utilisez les spécifications suivantes pour un cluster de production 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

Benchmarking des Performances : Overlay vs. Kubenet vs. Cilium

Nous avons effectué des tests iperf3 et wrk dans divers scénarios. Les résultats sont définitifs. Pour le trafic inter-Pod interne, Azure CNI Overlay fonctionne avec une différence de 2 à 3 % par rapport au CNI en mode VNET, tandis que Kubenet montre une pénalité de latence de 10 à 15 % en raison du saut UDR et de la complexité NAT.

Métrique	Kubenet	Azure CNI (Héritage)	Azure CNI Overlay + Cilium
Consommation IP	Faible (1 IP par Nœud)	Extrême (1 IP par Pod)	Faible (1 IP par Nœud)
Latence (μs)	145μs	92μs	94μs
Débit (Gbps)	~7.5 Gbps	~9.4 Gbps	~9.3 Gbps
Nœuds Max	400 (Limite UDR)	Dépend de la taille du VNET	5,000+

Sécurité : Au-delà des NetworkPolicies

Alors que les ressources standard NetworkPolicy fonctionnent dans Overlay, le plan de données Cilium permet le filtrage basé sur le FQDN et les politiques de couche 7 (HTTP/gRPC). En 2026, bloquer le trafic par adresse IP est insuffisant. Vous devez être capable de dire "le Pod A ne peut exécuter que des requêtes GET vers /api/v1/health sur le Pod B."

Azure CNI Overlay s'intègre également plus proprement avec les Azure Firewalls. Étant donné que le trafic sortant du cluster est source-NATé vers l'IP du Nœud, vos règles de firewall peuvent être définies en fonction du sous-réseau du Nœud, ce qui est bien plus stable que d'essayer de suivre les plages de Pods dynamiques. Si vous avez encore des difficultés avec les contrôles d'égresse, consultez notre guide sur les AKS Egress Gateway Patterns.

Pièges Opérationnels : Le MTU et le Piège du Sous-réseau

Malgré les avantages, les ingénieurs échouent souvent à configurer le MTU. Les VNETs Azure supportent un MTU de 1500. Cependant, si vous utilisez un Overlay, il est tentant de supposer que vous devez baisser le MTU (comme un VXLAN nécessite généralement 1450). L'implémentation Overlay d'Azure est hautement optimisée, mais si vous l'enveloppez dans un service mesh secondaire comme Istio ou Linkerd avec mTLS, la taille effective de votre charge utile diminue. Validez toujours vos paramètres mss si vous constatez des réinitialisations de connexion sporadiques sur de grandes charges utiles.

Autre erreur courante : ne pas dimensionner correctement le sous-réseau des nœuds. Même si les Pods n'utilisent pas les IP des VNET, vous avez toujours besoin de suffisamment d'espace pour la scalabilité des nœuds, les pics de mise à niveau (max-surge) et les load balancers internes. Un /24 pour les nœuds est le strict minimum pour un environnement de production ; ne soyez pas avare et n'essayez pas d'utiliser un /27.

Le Verdict : Toujours Overlay

À mesure que nous avançons en 2026, le choix pour la mise en réseau AKS est clair. Kubenet est pour les amateurs ou les environnements hérités qui n'ont pas été touchés depuis des années. L'héritage Azure CNI est pour les personnes ayant un approvisionnement illimité d'adresses IPv4 (qui n'existent pas). Azure CNI Overlay + Cilium est la seule architecture qui fournit la scalabilité, la performance et la sécurité requises pour les workloads d'entreprise modernes.

Chez TechLeague, nous avons aidé des dizaines d'entreprises Fortune 500 à migrer des clusters Kubenet défaillants vers des architectures Overlay haute performance. Si votre équipe réseau vous combat sur les allocations IP ou si votre latence augmente en période de forte charge, vous avez besoin d'une analyse architecturale professionnelle. Explorez nos options de consulting sur mesure sur techleague.io pour vous assurer que votre infrastructure n'est pas le goulot d'étranglement de votre pipeline CI/CD.