Comprendre les différences entre Azure CNI, CNI Overlay et Kubenet est essentiel pour vos décisions d'architecture réseau AKS : ces options déterminent la manière dont vos pods communiquent, comment les adresses IP sont attribuées et quelles fonctionnalités sont disponibles dans votre cluster ! Toutes ces solutions assurent la connectivité entre pods, mais elles diffèrent par leur implémentation, leurs performances et leurs capacités de scalabilité. Ce tour d'horizon technique passe en revue les principales différences entre Azure CNI (dans ses modes traditionnel et overlay) et Kubenet, en se concentrant sur la gestion des adresses IP, les performances réseau et les capacités d'intégration, afin de vous aider à définir votre stratégie réseau AKS.
Gestion des adresses IP
Avec Azure CNI traditionnel, chaque pod reçoit une adresse IP directement depuis le sous-réseau de votre Azure Virtual Network. Les pods deviennent ainsi des acteurs réseau à part entière au sein de votre VNet, capables de communiquer directement avec les autres ressources de votre environnement Azure. Les IP des pods sont routables et accessibles depuis toute ressource disposant d'une connectivité réseau vers le sous-réseau.
Azure CNI propose désormais un mode Overlay, dans lequel seuls les nœuds du cluster sont déployés dans un sous-réseau. Les pods reçoivent quant à eux des adresses IP issues d'un CIDR privé logiquement distinct du VNet hébergeant les nœuds. Le trafic entre pods et nœuds au sein du cluster transite par un réseau Overlay, tandis que la traduction d'adresses réseau (NAT) utilise l'IP du nœud pour atteindre les ressources extérieures au cluster. Cette solution permet d'économiser un grand nombre d'adresses IP et autorise une bien meilleure montée en charge du cluster.
Kubenet repose lui aussi sur un réseau overlay. Les pods reçoivent des IP issues d'un espace d'adressage distinct, qui ne fait pas partie de votre VNet. Lorsqu'ils doivent communiquer avec des ressources extérieures, Kubenet recourt au NAT pour router le trafic via l'IP du nœud. Cela introduit un saut réseau supplémentaire, mais préserve les IP du VNet, puisque seuls les nœuds en consomment.
Besoins en espace d'adressage
Avec Azure CNI traditionnel, la planification du sous-réseau exige une réflexion poussée, car chaque pod potentiel a besoin d'une IP dédiée issue de votre sous-réseau. Vous devez donc dimensionner un sous-réseau capable d'accueillir l'ensemble des nœuds et leur nombre maximal de pods. Si chaque nœud peut exécuter 30 pods et que vous prévoyez de monter à 10 nœuds, il vous faudra au moins 300 IP pour les pods, plus celles des nœuds eux-mêmes. Cette contrainte impose souvent de retenir des plages CIDR plus larges et peut peser sur la conception globale du réseau.
Azure CNI Overlay offre une utilisation plus efficace des adresses IP en attribuant un espace /24 à chaque nœud, à partir d'un CIDR privé défini lors de la création du cluster. Ce bloc /24 est fixe et peut accueillir jusqu'à 250 pods par nœud. Vous pouvez réutiliser le même espace CIDR de pods sur plusieurs clusters AKS indépendants au sein d'un même VNet, ce qui élargit considérablement l'espace d'adressage disponible pour vos applications conteneurisées.
Kubenet permet aussi une utilisation efficace des IP, puisqu'il ne nécessite des adresses du VNet que pour les nœuds. Les pods utilisent une plage CIDR interne pour le réseau overlay, par défaut 10.244.0.0/16, qui ne consomme pas l'espace d'adressage de votre VNet. C'est un bon choix dans les environnements où la disponibilité d'IP est limitée ou soumis à de strictes contraintes d'adressage. Cette efficacité a toutefois pour contrepartie une configuration de routage supplémentaire via des User Defined Routes (UDR).
Performances réseau
Azure CNI traditionnel offre des performances réseau supérieures grâce à son modèle d'intégration directe. Les pods étant connectés au VNet sans réseau overlay, la surcharge sur la pile réseau est minime. Les paquets circulent directement entre les pods et les autres ressources du VNet, sans couches d'encapsulation ou de traduction supplémentaires, ce qui se traduit par une latence plus faible et un débit plus élevé pour les workloads exigeants en réseau.
Azure CNI Overlay maintient des performances comparables à celles des VM dans un VNet. Aucune route personnalisée ni méthode d'encapsulation n'est requise pour acheminer le trafic entre pods, ce qui garantit une connectivité entre pods équivalente à celle entre VM d'un même VNet.
Kubenet introduit une surcharge réseau supplémentaire, car il s'appuie sur le NAT et le routage via l'interface réseau du nœud. Chaque paquet doit être traité par le réseau overlay, puis traduit entre l'IP interne du pod et l'IP externe du nœud. Cet impact reste négligeable pour la plupart des applications, mais peut devenir perceptible pour des workloads à fort débit ou sensibles à la latence.
Contrôle via les Network Security Groups (NSG)
Azure CNI fonctionne avec les NSG au niveau du sous-réseau et de l'interface réseau, et les règles peuvent cibler les IP des pods puisqu'elles font partie du VNet. Les NSG ne peuvent pas être attachés directement à un pod, mais vous pouvez créer des règles spécifiques visant des pods individuels ou des groupes de pods via leurs IP au sein du VNet.
Avec Azure CNI Overlay, le trafic entre pods n'est pas encapsulé et les règles NSG du sous-réseau s'appliquent. Des règles spécifiques sont nécessaires au bon fonctionnement du cluster, notamment pour le trafic entre les plages CIDR des nœuds et celles des pods. Les network policies sont recommandées pour piloter le trafic des workloads.
Avec Kubenet, le contrôle de la sécurité réseau se limite au niveau du nœud, puisque les pods ne disposent pas d'IP directes dans le VNet. Les règles NSG ne peuvent s'appliquer qu'à l'interface réseau du nœud, ce qui signifie que tous les pods d'un même nœud partagent les mêmes règles de sécurité. Cette limitation rend plus complexe la mise en œuvre de politiques réseau spécifiques aux pods et peut imposer des solutions alternatives, comme les Kubernetes Network Policies, pour un contrôle plus fin du trafic au sein du cluster.
Intégration au VNet
Azure CNI traditionnel offre une intégration complète au VNet : les pods peuvent dialoguer directement avec n'importe quelle ressource Azure connectée au VNet. Cela inclut des services Azure tels que SQL Managed Instance, Azure Cache for Redis, ou des ressources situées dans des VNet appairés. Comme les pods obtiennent leurs IP directement depuis le sous-réseau du VNet, ils établissent des connexions directes sans configuration réseau additionnelle, ce qui en fait un choix idéal lorsqu'une intégration fluide avec d'autres services Azure est requise.
Azure CNI Overlay assure l'intégration au VNet via NAT : le trafic sortant des pods utilise l'IP du nœud. Les pods ne sont pas accessibles directement depuis l'extérieur du cluster, mais vous pouvez exposer leurs applications via des services Kubernetes Load Balancer pour les rendre joignables sur le VNet.
Kubenet propose une intégration au VNet plus restreinte. Les pods peuvent toujours communiquer avec des ressources externes, mais cette communication nécessite des UDR pour acheminer correctement le trafic entre le réseau overlay des pods et le VNet. Cette complexité de routage supplémentaire peut affecter la connectivité avec certains services Azure et exiger des configurations spécifiques pour le peering VNet ou les scénarios de réseau hybride. Les besoins en routage peuvent également se complexifier à mesure que votre architecture réseau évolue.
Gestion des tables de routage et complexité de mise en place
La gestion des tables de routage varie sensiblement d'une option à l'autre. Azure CNI traditionnel simplifie cette gestion : les pods communiquent directement sur le VNet, sans entrées de routage supplémentaires pour gérer leur trafic. La configuration du routage reste simple, même à mesure que le cluster grandit. La contrepartie réside dans la complexité initiale du déploiement, qui exige une planification rigoureuse des adresses IP.
Azure CNI Overlay simplifie la mise en réseau des pods en se passant d'UDR pour la connectivité de base, contrairement à Kubenet. Bien qu'il requière la configuration de règles NSG spécifiques pour le bon fonctionnement du cluster, la solution gère automatiquement le routage entre pods et conserve des performances comparables à la communication classique au sein d'un VNet. Des UDR peuvent toutefois rester nécessaires dans certains cas, comme le forced tunneling ou des exigences de routage personnalisé.
Kubenet s'appuie sur des UDR et l'IP forwarding pour la connectivité des pods, créés et maintenus automatiquement par le service AKS par défaut. Vous pouvez éventuellement apporter votre propre table de routage pour une gestion personnalisée, mais la configuration standard ne demande aucune maintenance manuelle. Principale limite : Azure prend en charge un maximum de 400 routes par UDR, ce qui plafonne en pratique le cluster à 400 nœuds. La mise en place initiale est plus simple qu'avec Azure CNI traditionnel, car aucune planification d'adressage IP poussée n'est nécessaire — il suffit de prévoir les IP des nœuds dans le sous-réseau. En revanche, l'architecture UDR ajoute un saut réseau supplémentaire qui introduit une légère latence dans la communication entre pods, et il est impossible de partager des sous-réseaux entre plusieurs clusters Kubenet.
Fonctionnalités additionnelles
Chaque option réseau prend en charge un ensemble distinct de fonctionnalités avancées. Azure CNI traditionnel offre la couverture la plus large : conteneurs Windows, Azure Network Policies et intégration avec Application Gateway. Azure CNI Overlay prend en charge les conteneurs Windows et plusieurs options de network policies (Azure, Calico, Cilium), mais ne peut pas utiliser Application Gateway comme Ingress Controller. Les deux modes CNI prennent en charge le réseau dual-stack, l'Overlay présentant toutefois certaines limitations. Kubenet offre une prise en charge plus restreinte : il ne fonctionne qu'avec des conteneurs Linux et les network policies Calico. Kubenet se limite par ailleurs aux conteneurs Linux, prend en charge jusqu'à 400 nœuds avec 250 pods par nœud, et se restreint à Calico pour les network policies. Il ne prend en charge ni les conteneurs Windows ni les fonctionnalités réseau Azure avancées.
Quelle option choisir ?
Le choix entre les différentes options réseau dépend des besoins propres à vos workloads et des contraintes de votre infrastructure :
Azure CNI traditionnel est le mieux adapté aux workloads d'entreprise nécessitant une intégration réseau directe, de hautes performances ou une intégration avancée avec les services Azure. Privilégiez-le lorsque :
- Vous disposez d'un espace d'adressage IP suffisant
- La majorité des communications des pods s'effectue avec des ressources externes au cluster
- Des ressources externes au cluster doivent atteindre directement les pods
- Vous avez besoin de fonctionnalités AKS avancées comme les virtual nodes
- Une intégration avec Application Gateway est requise
Azure CNI Overlay est idéal pour les déploiements à grande échelle disposant d'un espace d'adressage IP limité. Privilégiez-le lorsque :
- Vous devez monter en charge sur un grand nombre de pods avec un espace d'adressage IP restreint
- La majorité des communications entre pods se fait au sein du cluster
- Vous souhaitez une configuration réseau simplifiée
- Vous avez besoin de la prise en charge des conteneurs Windows mais pas d'Application Gateway Ingress Controller
- Vous souhaitez réutiliser les plages CIDR de pods entre plusieurs clusters
Kubenet convient bien aux workloads Linux basiques et aux environnements soumis à des contraintes d'adressage IP. Privilégiez-le lorsque :
- Vous n'avez que des workloads Linux basiques
- Vous êtes contraint sur les IP mais n'avez pas besoin de l'échelle de CNI Overlay
- Vous n'avez pas besoin de fonctionnalités réseau avancées
- Vous montez des environnements de développement ou de test
Le choix du plugin réseau de votre cluster AKS a des conséquences durables sur la scalabilité, les performances et la complexité opérationnelle ! Comprendre les caractéristiques et les limites propres à chaque option est essentiel pour prendre une décision éclairée, en cohérence avec vos besoins d'infrastructure et vos perspectives de croissance. Gardez à l'esprit que le passage d'une option réseau à une autre impose généralement de recréer le cluster : cette décision doit donc être prise tôt dans la planification de votre AKS.
Dernier point : le 31 mars 2028, le réseau Kubenet pour AKS sera retiré. Envisagez une migration vers Azure CNI Overlay, un remplacement adapté qui lève bon nombre des limites de Kubenet tout en conservant une utilisation efficace des adresses IP.
Contactez DoiT dès aujourd'hui pour échanger sur la manière dont nous pouvons vous aider à maximiser l'efficacité, la rentabilité et la sécurité de votre environnement cloud. Avec DoiT, vous accédez à une expertise cloud exclusivement senior pour le conseil, la montée en compétences et le support, et nous sommes là dès que vous avez besoin d'un avis d'expert, d'un regard extérieur, d'aide pour adopter de nouvelles technologies ou pour gérer une situation critique en production.
Si vous souhaitez approfondir d'autres sujets liés à la sécurité et à l'architecture cloud, consultez les articles de notre blog cloud engineering.