Partager via

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

  • Article

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 d’adresses IP dynamiques et Allocation de blocs statiques (préversion).

Prérequis

Remarque

Lorsque vous utilisez l’allocation de bloc statique de 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 prérequis à 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 la configuration de 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 en libre service ne sont pas pris en charge.

  • Azure CLI version 2.37.0 ou ultérieure et version 2.0.0b2 ou ultérieure de l’extension aks-preview.

  • Inscrivez l’indicateur de fonctionnalité au niveau de l’abonnement pour votre abonnement : « Microsoft.ContainerService/AzureVnetScalePreview ».

  • Si vous disposez d’un cluster existant, vous devez activer Container Insights pour superviser le composant additionnel d’utilisation du sous-réseau IP. Vous pouvez activer Container Insights avec la commande az aks enable-addons, comme indiqué dans l’exemple suivant :

    az aks enable-addons --addons monitoring --name <cluster-name> --resource-group <resource-group-name>

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 Allocation d’adresses IP dynamiques 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 des adresses IP de réseau virtuel sont affectées aux pods, elles 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 Allocation de blocs statiques (préversion)

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 Allocation de blocs statiques 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 : les adresses IP du réseau virtuel étant attribuées aux pods, ces derniers disposent d’une connectivité directe vers d’autres pods et ressources du 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.

Limites

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

  • La version minimale de Kubernetes nécessaire est 1.28
  • La taille maximale du sous-réseau prise en charge est x.x.x.x/12 ~ 1 million d’adresses IP
  • 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 d’adresse IP dynamique dans un autre cluster ou un 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

Disponibilité dans les régions

Cette fonctionnalité n’est pas disponible dans les régions suivantes :

  • USA Sud
  • USA Est 2
  • USA Ouest
  • USA Ouest 2

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 :

Exemple de scénario 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.

Remarque

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.