Sous-réseau de pod Azure CNI (Container Networking Interface)

Le sous-réseau de pod Azure CNI affecte des adresses IP aux pods d’un sous-réseau distinct de vos nœuds de cluster. Cette fonctionnalité est disponible en deux modes : Allocation IP dynamique et allocation de bloc statique.

Prerequisites

Note

Lorsque vous utilisez l’allocation de blocs statiques des CIDR, l’exposition d’une application en tant que service Private Link à l’aide d’un service Kubernetes Load Balancer n’est pas prise en charge.

• Passez en revue les conditions préalables à la configuration de la mise en réseau Azure CNI de base dans AKS, car les mêmes prérequis s’appliquent à cet article.
• Passez en revue les paramètres de déploiement pour configurer la mise en réseau Azure CNI de base dans AKS, car les mêmes paramètres s’appliquent.
• Le moteur AKS et les clusters DIY ne sont pas pris en charge.
• Azure CLI version 2.37.0 ou ultérieure et version aks-preview ou ultérieure de l’extension 2.0.0b2.
• Inscrivez l’indicateur de fonctionnalité au niveau de l’abonnement pour votre abonnement : « Microsoft.ContainerService/AzureVnetScalePreview ».

Mode Allocation d’adresses IP dynamiques

L’allocation d’adresses IP dynamiques permet d’atténuer les problèmes d’épuisement des adresses IP des pods en allouant des adresses IP de pod à partir d’un sous-réseau distinct du sous-réseau hébergeant le cluster AKS.

Le mode d’allocation IP dynamique offre les avantages suivants :

• Meilleure utilisation des adresses IP : les adresses IP sont allouées de façon dynamique aux pods du cluster à partir du sous-réseau de pod. Cela permet d’améliorer l’utilisation des adresses IP dans le cluster par rapport à la solution de CNI traditionnelle, qui effectue une allocation statique des adresses IP pour chaque nœud.
• Scalabilité et flexibilité : les sous-réseaux de nœud et de pod peuvent être mis à l’échelle indépendamment. Un seul sous-réseau de pod peut être partagé entre plusieurs pools de nœuds d’un cluster ou plusieurs clusters AKS déployés dans le même réseau virtuel. Vous pouvez également configurer un sous-réseau de pod distinct pour un pool de nœuds.
• Hautes performances : étant donné que les pods reçoivent des adresses IP de réseau virtuel, ils disposent d’une connectivité directe à d’autres pods et ressources de cluster dans le réseau virtuel. La solution prend en charge des clusters très volumineux sans dégradation des performances.
• Stratégies de réseau virtuel distinctes pour les pods : étant donné que les pods ont un sous-réseau distinct, vous pouvez configurer ceux-ci des stratégies de réseau virtuel distinctes, qui diffèrent des stratégies de nœud. Cela permet de nombreux scénarios utiles, tels que l’autorisation de la connectivité Internet uniquement pour les pods et pas pour les nœuds, la correction de l’adresse IP source pour un pod dans un pool de nœuds à l’aide d’Azure NAT Gateway, ainsi que l’utilisation de groupes de sécurité réseau (NSG) pour filtrer le trafic entre les pools de nœuds.
• Stratégies réseau Kubernetes : les stratégies réseau Azure et Calico fonctionnent avec ce mode.

Planifier l’adressage IP

Avec l’allocation d’adresses IP dynamiques, les nœuds et les pods sont mis à l’échelle indépendamment, vous pouvez donc planifier leurs espaces d’adressage séparément. Étant donné que les sous-réseaux de pod peuvent être configurés pour la granularité d’un pool de nœuds, vous pouvez toujours ajouter un sous-réseau quand vous ajoutez un pool de nœuds. Les pods système dans un cluster/pool de nœuds recevant également des adresses IP du sous-réseau de pod, ce comportement doit être pris en compte.

Les adresses IP sont allouées aux nœuds par lots de 16. L’allocation d’adresses IP du sous-réseau de pods doit être planifiée avec un minimum de 16 adresses IP par nœud dans le cluster. Les nœuds demandent 16 adresses IP au démarrage et un autre lot de 16 chaque fois que <8 adresses IP ne sont pas allouées dans leur allocation.

La planification des adresses IP pour les services Kubernetes et le pont Docker reste inchangée.

Mode d’allocation de blocs statiques

L’allocation de blocs statiques permet d’atténuer le dimensionnement potentiel du sous-réseau de pod et les limitations de mappage d’adresses Azure en affectant des blocs CIDR à des nœuds plutôt qu’à des adresses IP individuelles.

Le mode d’allocation de bloc statique offre les avantages suivants :

• Meilleure scalabilité des adresses IP : les blocs CIDR sont alloués statiquement aux nœuds du cluster et sont présents pendant la durée de vie du nœud, par opposition à l’allocation dynamique traditionnelle d’adresses IP individuelles avec la CNI traditionnelle. Cela permet un routage basé sur des blocs CIDR et permet de mettre à l’échelle la limite de cluster jusqu’à 1 million de pods par rapport aux 65 000 pods traditionnels par cluster. Votre Réseau virtuel Azure doit être suffisamment grand pour prendre en charge la mise à l’échelle de votre cluster.
• Flexibilité : les sous-réseaux de nœud et de pod peuvent être mis à l’échelle indépendamment. Un seul sous-réseau de pod peut être partagé entre plusieurs pools de nœuds d’un cluster ou plusieurs clusters AKS déployés dans le même réseau virtuel. Vous pouvez également configurer un sous-réseau de pod distinct pour un pool de nœuds.
• Hautes performances : étant donné que les pods reçoivent des adresses IP de réseau virtuel, ils disposent d’une connectivité directe à d’autres pods et ressources de cluster dans le réseau virtuel.
• Stratégies de réseau virtuel distinctes pour les pods : étant donné que les pods ont un sous-réseau distinct, vous pouvez configurer ceux-ci des stratégies de réseau virtuel distinctes, qui diffèrent des stratégies de nœud. Cela permet de nombreux scénarii utiles, tels que l’autorisation de la connectivité Internet uniquement pour les pods et pas pour les nœuds, la correction de l’adresse IP source pour un pod dans un pool de nœuds à l’aide d’Azure NAT Gateway, ainsi que l’utilisation de groupes de sécurité réseau pour filtrer le trafic entre les pools de nœuds.
• Stratégies réseau Kubernetes : Cilium, Azure NPM et Calico fonctionnent avec cette solution.

Limitations

Voici quelques-unes des limitations concernant l’utilisation de l’allocation de bloc statique Azure CNI :

• La version minimale de Kubernetes requise est 1.28.
• La taille maximale de sous-réseau prise en charge est x.x.x.x/12 ~ 1 million d’adresses IP.
• Les nœuds Windows 2019 ne sont pas pris en charge dans le sous-réseau de pods Azure CNI.
• Un seul mode d’opération peut être utilisé par sous-réseau. Si un sous-réseau utilise le mode d’allocation de bloc statique, il ne peut pas utiliser le mode d’allocation IP dynamique dans un autre cluster ou pool de nœuds avec le même sous-réseau et vice versa.
• Prise en charge uniquement dans les nouveaux clusters ou lors de l’ajout de pools de nœuds avec un sous-réseau différent aux clusters existants. La migration ou la mise à jour de clusters ou de pools de nœuds existants n’est pas prise en charge.
• Sur tous les blocs CIDR attribués à un nœud dans le pool de nœuds, une adresse IP est sélectionnée comme adresse IP principale du nœud. Par conséquent, pour les administrateurs réseau sélectionnant la valeur --max-pods, essayez d’utiliser le calcul ci-dessous pour mieux répondre à vos besoins et avoir une utilisation optimale des adresses IP dans le sous-réseau :

max_pods = (N * 16) - 1 où N est un entier positif et N> 0

Planifier l’adressage IP

Avec l’allocation de blocs statiques, les nœuds et les pods sont mis à l’échelle indépendamment. Vous pouvez donc planifier leurs espaces d’adressage séparément. Étant donné que les sous-réseaux de pod peuvent être configurés pour la granularité d’un pool de nœuds, vous pouvez toujours ajouter un sous-réseau quand vous ajoutez un pool de nœuds. Les pods système dans un cluster/pool de nœuds recevant également des adresses IP du sous-réseau de pod, ce comportement doit être pris en compte.

Les blocs CIDR de /28 (16 adresses IP) sont alloués aux nœuds en fonction de votre configuration --max-pods pour votre pool de nœuds qui définit le nombre maximal de pods par nœud. 1 adresse IP est réservée sur chaque nœud à partir de toutes les adresses IP disponibles sur ce nœud à des fins internes.

Lors de la planification de vos adresses IP, il est important de définir votre configuration --max-pods à l’aide du calcul suivant : max_pods_per_node = (16 * N) - 1, où N est un entier positif supérieur à 0.

Les valeurs idéales sans gaspillage IP nécessitent que la valeur maximale des pods soit conforme à l’expression ci-dessus.

Consultez les exemples suivants :

Note

Les exemples supposent des blocs CIDR /28 (16 adresses IP chacune).

Exemple de cas	max_pods	Blocs CIDR alloués par nœud	Nombre total d’adresses IP disponibles pour les pods	Gaspillage d’adresses IP pour le nœud
Faible gaspillage (acceptable)	30	2	(16 * 2) - 1 = 32 - 1 = 31	31 - 30 = 1
Cas idéal	31	2	(16 * 2) - 1 = 32 - 1 = 31	31 - 31 = 0
Gaspillage élevé (non recommandé)	32	3	(16 * 3) - 1 = 48 - 1 = 47	47 - 32 = 15

La planification des adresses IP pour les services Kubernetes reste inchangée.

Note

Vérifiez que votre réseau virtuel dispose d’un espace d’adressage suffisamment volumineux et contigu pour prendre en charge la mise à l’échelle de votre cluster.