Configurer le sous-réseau de pod Azure CNI - Allocation de blocs statiques et prise en charge améliorée du sous-réseau dans Azure Kubernetes Service (AKS)

Une limitation du Sous-réseau de pod Azure CNI - Allocation IP dynamique est la scalabilité de la taille du sous-réseau de pod au-delà d’un sous-réseau /16. Même avec un sous-réseau volumineux, les clusters volumineux peuvent toujours être limités à 65 000 pods en raison d’une limite de mappage d’adresses Azure. Le sous-réseau pod - Allocation de blocs statiques dans Azure CNI résout ce problème en affectant des blocs CIDR à des nœuds plutôt qu’à des adresses IP individuelles.

Elle offre les avantages suivants :

Meilleure scalabilité d’adresse IP : les blocs CIDR sont alloués statiquement aux nœuds du cluster et sont présents pour 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 nouvelle solution.

Cet article explique comment utiliser le sous-réseau de pod Azure CNI - Allocation de blocs statiques et prise en charge améliorée du sous-réseau dans AKS.

Prerequisites

Note

Quand vous utilisez le Sous-réseau de pod - Allocation de bloc statique, 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.
Version 2.75.0 d’Azure CLI ou ultérieure
Si vous disposez d’un cluster existant, vous devez activer Container Insights pour surveiller l’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>
```

Limitations

Voici quelques-unes des limitations de l’utilisation du sous-réseau de pod Azure CNI - Allocation de bloc statique :

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 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 quelconque et N > 0

Planifier l’adressage IP

La planification de votre adressage IP est plus flexible et plus granulaire. Étant donné que les nœuds et les pods se mettent à l’échelle indépendamment, leurs espaces d’adressage peuvent également être planifiés 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.

Dans ce scénario, 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.

Ainsi, lors de la détermination et de la planification de vos adresses IP, il est essentiel de définir votre configuration « --max-pods » et elle peut être mieux calculée comme ci-dessous : 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.

Exemple 1 : max_pods = 30, blocs CIDR alloués par nœud = 2, nombre total d’adresses IP disponibles pour les pods = (16 * 2) - 1 = 32 - 1 = 31, ip wastage par nœud = 31 - 30 = 1 [Low wastage - Acceptable Case]
Exemple 2 : max_pods = 31, blocs CIDR alloués par nœud = 2, nombre total d’adresses IP disponibles pour les pods = (16 * 2) - 1 = 32 - 1 = 31, wastage IP par nœud = 31 - 31 = 0 [Cas idéal]
Exemple 3 : max_pods = 32, blocs CIDR alloués par nœud = 3, Nombre total d’adresses IP disponibles pour les pods = (16 * 3) - 1 = 48 - 1 = 47, gaspillage IP par nœud = 47 - 32 = 15 [Gaspillage Élevé - Cas Non Recommandé]

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.

Paramètres de déploiement

Les paramètres de déploiement pour la configuration de la mise en réseau Azure CNI de base dans AKS sont tous valides, avec des exceptions :

Le paramètre vnet subnet id fait désormais référence au sous-réseau associé aux nœuds du cluster.
Le paramètre pod subnet id est utilisé pour spécifier le sous-réseau dont les adresses IP seront allouées de façon statique ou dynamique aux pods dans le pool de nœuds.
Le paramètre de mode d’allocation ip du pod spécifie s’il faut utiliser DynamicIndividual (allocation IP dynamique) ou StaticBlock (allocation de bloc statique).

Configurer la mise en réseau avec l’allocation statique de blocs CIDR et prise en charge des sous-réseaux améliorée – Azure CLI

L’utilisation du sous-réseau de pod - Allocation de blocs statiques dans votre cluster est similaire à la méthode par défaut pour configurer un cluster avec un sous-réseau pod - Allocation IP dynamique. L’exemple suivant décrit la création d’un réseau virtuel avec un sous-réseau pour les nœuds et un sous-réseau pour les pods et la création d’un cluster qui utilise le sous-réseau de pod Azure CNI - Allocation de bloc statique. Veillez à remplacer les variables telles que $subscription par vos valeurs.

Créez le réseau virtuel avec deux sous-réseaux.

resourceGroup="myResourceGroup"
vnet="myVirtualNetwork"
location="myRegion"

# Create the resource group
az group create --name $resourceGroup --location $location

# Create our two subnet network 
az network vnet create --resource-group $resourceGroup --location $location --name $vnet --address-prefixes 10.0.0.0/8 -o none 
az network vnet subnet create --resource-group $resourceGroup --vnet-name $vnet --name nodesubnet --address-prefixes 10.240.0.0/16 -o none 
az network vnet subnet create --resource-group $resourceGroup --vnet-name $vnet --name podsubnet --address-prefixes 10.40.0.0/13 -o none

Créez le cluster en référençant le sous-réseau de nœud à l’aide de --vnet-subnet-id, le sous-réseau de pod à l’aide de --pod-subnet-id, --pod-ip-allocation-mode afin de définir le mode d’allocation d’adresse IP, puis activez le module complémentaire de monitoring.

clusterName="myAKSCluster"
subscription="aaaaaaa-aaaaa-aaaaaa-aaaa"

az aks create \
    --name $clusterName \
    --resource-group $resourceGroup \
    --location $location \
    --max-pods 250 \
    --node-count 2 \
    --network-plugin azure \
    --pod-ip-allocation-mode StaticBlock \
    --vnet-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/nodesubnet \
    --pod-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/podsubnet \
    --enable-addons monitoring \
    --generate-ssh-keys

Ajout d’un pool de nœuds

Lorsque vous ajoutez un pool de nœuds, référencez le sous-réseau de nœud à l’aide de --vnet-subnet-id, le sous-réseau de pod à l’aide de --pod-subnet-id et le mode d’allocation à l’aide de « --pod-ip-allocation-mode ». L’exemple suivant crée deux sous-réseaux qui sont ensuite référencés dans la création d’un nouveau pool de nœuds :

az network vnet subnet create -g $resourceGroup --vnet-name $vnet --name node2subnet --address-prefixes 10.242.0.0/16 -o none 
az network vnet subnet create -g $resourceGroup --vnet-name $vnet --name pod2subnet --address-prefixes 10.243.0.0/16 -o none 

az aks nodepool add --cluster-name $clusterName -g $resourceGroup  -n newnodepool \
    --max-pods 250 \
    --node-count 2 \
    --vnet-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/node2subnet \
    --pod-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/pod2subnet \
    --pod-ip-allocation-mode StaticBlock \
    --no-wait

Migration du Sous-réseau de pod - Allocation IP dynamique vers le Sous-réseau de pod - Allocation de bloc statique

Si vous disposez d’un cluster AKS existant utilisant l'allocation dynamique d'IP pour le sous-réseau de pods et que vous souhaitez migrer vers le sous-réseau de pods avec une allocation de bloc statique, procédez comme suit :

Étapes de la migration :

Planifier l’utilisation d’un nouveau sous-réseau pour les pools d’agents de bloc statique
- Créez un sous-réseau dans votre réseau virtuel existant qui sera dédié au mode Bloc statique
- Vérifiez que la taille du sous-réseau suit les instructions de planification décrites dans la section d’adressage IP du plan
Ajouter un pool d’agents à votre cluster existant avec le mode Bloc statique et le nouveau sous-réseau
- Utilisez la az aks nodepool add commande pour créer un pool de nœuds avec l’allocation de blocs statiques
- Référencer le nouveau sous-réseau à l’aide --pod-subnet-id et le définir --pod-ip-allocation-mode sur StaticBlock
Supprimez votre pool d’agents existant afin que tous vos déploiements et trafic passent au nouveau pool d’agents
- Utiliser kubectl cordon pour marquer les nœuds existants comme non planifiés
- Vider progressivement les charges de travail de l’ancien pool de nœuds vers le nouveau pool de nœuds de blocs statiques
Une fois que toutes les charges de travail ont été déplacées vers le nouveau pool d’agents, supprimez le pool d’agents non statiques existant.
- Vérifier que toutes les charges de travail s’exécutent correctement sur le nouveau pool de nœuds
- Supprimer l’ancien pool de nœuds à l’aide de az aks nodepool delete

Important

La migration nécessite une planification et un test prudents. Assurez-vous que vous disposez d’une capacité adéquate dans le nouveau pool de nœuds avant d’arrêter les nœuds existants. Testez d’abord le processus de migration dans un environnement hors production.

FAQ sur l’allocation statique de blocs CIDR et la prise en charge de sous-réseau améliorée

Puis-je attribuer plusieurs sous-réseaux de pod à un cluster ?

Plusieurs sous-réseaux peuvent être attribués à un cluster, mais un seul sous-réseau peut être attribué à chaque pool de nœuds. Différents pools de nœuds sur le même cluster ou un différent peuvent partager le même sous-réseau.
Puis-je attribuer des sous-réseaux de pod entièrement à partir d’un autre réseau virtuel ?

Non, le sous-réseau de pod doit provenir du même réseau virtuel que le cluster.
Certains pools de nœuds dans un cluster avec une IPAM de sous-réseau de pod peuvent-ils utiliser l’allocation IP dynamique alors que d’autres utilisent la nouvelle allocation de blocs statique ?

Oui, différents pools de nœuds peuvent utiliser différents modes d’allocation. Toutefois, une fois qu’un sous-réseau est utilisé dans un mode d’allocation, il ne peut être utilisé que dans le même mode d’allocation sur tous les pools de nœuds auxquels il est associé.

Étapes suivantes

Pour plus d’informations sur la mise en réseau dans AKS, consultez les articles suivants :

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2025-11-04