Réseau de superposition Azure Container Networking Interface (CNI)

Avec la superposition Azure CNI, les nœuds de cluster sont déployés dans un sous-réseau Azure Réseau virtuel (Vnet). Les pods se voient attribuer des adresses IP à partir d'un CIDR privé logiquement différent du VNet hébergeant les nœuds. Le trafic de pod et de nœud au sein du cluster utilise un réseau de superposition. La traduction d’adresses réseau (NAT) utilise l’adresse IP du nœud pour atteindre des ressources en dehors du cluster. Cette solution vous permet d’économiser une quantité importante d’adresses IP de réseau virtuel et de mettre à l’échelle votre cluster vers de grandes tailles de manière fluide. Un avantage supplémentaire est que le CIDR privé peut être réutilisé dans différents clusters AKS, étendant réellement l’espace IP disponible pour les applications conteneurisées dans Azure Kubernetes Service (AKS).

Vue d’ensemble des réseaux Overlay

Dans un réseau Overlay, seuls les nœuds de cluster Kubernetes se voient affecter des IP de sous-réseaux. Les pods reçoivent des adresses IP d’un CIDR privé fourni au moment de la création du cluster. Chaque nœud se voit affecter à un espace d’adressage /24 issu du même CIDR. Les nœuds supplémentaires créés quand vous effectuez un scale-out d’un cluster reçoivent automatiquement des espaces d’adressage /24 à partir du même CIDR. Azure CNI affecte des adresses IP aux pods de cet espace /24.

Un domaine de routage distinct est créé dans la pile Azure Networking pour l’espace CIDR privé du pod, ce qui crée un réseau Overlay pour la communication directe entre les pods. Il n’est pas nécessaire de provisionner des routes personnalisées sur le sous-réseau de cluster ou d’utiliser une méthode d’encapsulation pour tunneliser le trafic entre les pods, ce qui fournit des performances de connectivité entre les pods à l’égal des machines virtuelles d’un réseau virtuel. Les charges de travail exécutées dans les pods n’ont même pas connaissance de la manipulation des adresses réseau.

La communication avec les points de terminaison en dehors du cluster, comme les réseaux virtuels locaux et appairés, se produit avec l’adresse IP du nœud via la traduction d’adresses réseau. Azure CNI traduit l’adresse IP source (IP Overlay du pod) du trafic dans l’adresse IP principale de la machine virtuelle, ce qui permet à la pile Azure Networking de router le trafic vers la destination. Les points de terminaison en dehors du cluster ne peuvent pas se connecter directement à un pod. Vous devez publier l’application du pod en tant que service Kubernetes Load Balancer pour le rendre accessible sur le réseau virtuel.

Vous pouvez fournir une connectivité sortante (sortie) à Internet pour les pods Overlay avec un équilibreur de charge de référence SKU Standard ou une NAT Gateway managée. Vous pouvez également contrôler le trafic de sortie en le dirigeant vers un pare-feu avec des routes définies par l’utilisateur sur le sous-réseau du cluster.

Vous pouvez configurer la connectivité d’entrée au cluster avec un contrôleur d’entrée tel que Nginx ou le routage d’applications HTTP. Vous ne pouvez pas configurer la connectivité d’entrée à l’aide d’Azure App Gateway. Pour plus d’informations, consultez Limitations liées à la superposition Azure CNI.

Différences entre kubenet et la superposition Azure CNI

Le tableau ci-dessous fournit une comparaison détaillée entre kubenet et la superposition Azure CNI :

Domaine	Superposition Azure CNI	Kubenet
Mise à l’échelle du cluster	5 000 nœuds et 250 pods/nœud	400 nœuds et 250 pods/nœud
Configuration réseau	Simple : aucune configuration supplémentaire requise pour le réseau de pods	Complexe : nécessite des tables de routage et des routes définies par l’utilisateur sur un sous-réseau de cluster pour le réseau de pods
Performances de connectivité des pods	Performances comparables aux machines virtuelles d’un réseau virtuel	L’ajout d’un tronçon engendre une latence mineure
Stratégies de réseau Kubernetes	Stratégies réseau Azure, Calico, Cilium	Calico
Plateformes de système d’exploitation prises en charge	Linux et Windows Server 2022, 2019	Linux uniquement

Planification des adresses IP

Nœuds de cluster

Quand vous configurez votre cluster AKS, vérifiez que vos sous-réseaux de réseau virtuel ont suffisamment d’espace pour se développer en cas de mise à l’échelle future. Vous pouvez affecter chaque pool de nœuds à un sous-réseau dédié.

Un sous-réseau /24 peut contenir jusqu’à 251 nœuds, les trois premières adresses IP étant réservées aux tâches de gestion.

Pods

La solution de superposition attribue un espace d’adressage /24 aux pods sur chaque nœud à partir du routage CIDR privé que vous spécifiez pendant la création du cluster. La taille /24 est fixe et ne peut pas être augmentée ou réduite. Vous pouvez exécuter jusqu’à 250 pods sur un nœud.

Lors de la planification de l’espace d’adressage IP pour les pods, tenez compte des facteurs suivants :

• Vérifiez que le routage CIDR privé est suffisamment grand pour fournir des espaces d’adressage /24 aux nouveaux nœuds pour prendre en charge le développement futur du cluster.
• Un même espace CIDR de pod peut être utilisé sur plusieurs clusters AKS indépendants sur le même réseau virtuel.
• L’espace CIDR de pod ne doit pas chevaucher la plage de sous-réseaux du cluster.
• L’espace du routage CIDR du pod ne doit pas chevaucher les réseaux directement connectés (comme le Peering de réseaux virtuels, ExpressRoute ou VPN). Si le trafic externe a des adresses IP sources dans la plage pod CIDR, il doit être traduit vers une adresse IP qui ne se chevauche pas par le biais de SNAT pour communiquer avec le cluster.

Plage d’adresses de service Kubernetes

La taille du routage CIDR des adresses de service dépend du nombre de services de cluster que vous voulez créer. Elle doit être inférieure à /12. Cette plage ne doit pas chevaucher la plage CIDR de pod, la plage de sous-réseaux de cluster et la plage IP utilisée sur les réseaux virtuels appairés et les réseaux locaux.

Adresse IP du service DNS Kubernetes

Cette adresse IP est dans la plage d’adresses du service Kubernetes utilisée par la découverte du service de cluster. N’utilisez pas la première adresse IP de votre plage d’adresses, car cette adresse est utilisée pour l’adresse kubernetes.default.svc.cluster.local.

Groupes de sécurité réseau

Le trafic pod à pod avec superposition Azure CNI n’est pas encapsulé et les règles du sous-réseau groupe de sécurité réseau sont appliquées. Si le groupe de sécurité réseau du sous-réseau contient des règles de refus ayant un impact sur le trafic CIDR du pod, assurez-vous que les règles suivantes sont en place pour garantir une fonctionnalité appropriée du cluster (en plus de toutes les exigences de sortie AKS) :

• Trafic entre le CIDR du nœud et le CIDR du nœud sur tous les ports et protocoles
• Trafic entre le CIDR du nœud et le CIDR du pod sur tous les ports et protocoles (exigé pour le routage du trafic de service)
• Trafic entre le CIDR du pod et le CIDR du pod sur tous les ports et protocoles (requis pour pod à pod et pod vers trafic de service, y compris DNS)

Le trafic d’un pod vers n’importe quelle destination, en dehors du bloc CIDR du pod, utilise SNAT pour paramétrer l’adresse IP source vers l’adresse IP du nœud sur lequel le pod s’exécute.

Si vous souhaitez limiter le trafic entre les charges de travail dans le cluster, nous vous recommandons d'utiliser des stratégies réseau.

Nombre maximal de pods par nœud

Vous pouvez configurer le nombre maximal de pods par nœud au moment de la création du cluster ou quand vous ajoutez un nouveau pool de nœuds. La valeur maximale (valeur par défaut) de la superposition Azure CNI est 250, tandis que la valeur minimale est 10. La valeur maximale du nombre de pods par nœud configurée lors de la création d’un pool de nœuds s’applique uniquement aux nœuds de ce pool de nœuds.

Choix d’un modèle de réseau à utiliser

Azure CNI offre deux options d’adressage IP pour les pods : la configuration traditionnelle qui attribue des IP de VNet aux pods, et le réseau de superposition. Le choix de l’option à utiliser pour votre cluster AKS est un équilibre entre les besoins de flexibilité et les besoins de configuration avancée. Les considérations suivantes aident à déterminer quand chaque modèle de réseau est le plus approprié.

Utilisez des réseaux Overlay quand  :

• Vous souhaitez effectuer une mise à l’échelle vers un grand nombre de pods, mais disposez d’un espace d’adressage IP limité sur votre réseau virtuel.
• La majeure partie de la communication des pods s’effectue dans le cluster.
• Vous n’avez pas besoin de fonctionnalités AKS avancées, comme des nœuds virtuels.

Utilisez l’option de réseau virtuel classique quand :

• Vous disposez d’espace d’adressage IP disponible.
• La majeure partie de la communication des pods s’effectue avec des ressources hors du cluster.
• Les ressources extérieures au cluster doivent atteindre directement les pods.
• Vous avez besoin de fonctionnalités avancées AKS comme des nœuds virtuels.

Limitations liées à la superposition Azure CNI

La superposition Azure CNI présente les limitations suivantes :

• Vous ne pouvez pas utiliser Application Gateway comme contrôleur d’entrée (AGIC).
• Les groupes à haute disponibilité de machines virtuelles (VMAS) ne sont pas pris en charge.
• Vous ne pouvez pas utiliser les machines virtuelles de la série DCsv2 dans des pools de nœuds. Pour respecter les conditions de l’informatique confidentielle, envisagez plutôt d’utiliser des machines virtuelles confidentielles de la série DCasv5 ou DCadsv5.
• Si vous utilisez votre propre sous-réseau pour déployer le cluster, les noms du sous-réseau, du réseau virtuel et du groupe de ressources contenant le réseau virtuel ne doivent pas dépasser 63 caractères. Ces noms servent d’étiquettes dans les nœuds worker AKS et sont donc soumis aux règles de syntaxe d’étiquette Kubernetes.