Configurer la mise en réseau Azure CNI pour l’allocation statique de blocs CIDR et la prise en charge améliorée des sous-réseaux dans Azure Kubernetes Service (AKS) – (Préversion)

Article
08/02/2024

Une limitation de l’allocation d’adresses IP dynamiques Azure CNI 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. La nouvelle capacité d’allocation de bloc statique dans Azure CNI résout ce problème en attribuant 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 : 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 nouvelle solution.

Cet article vous montre comment utiliser la mise en réseau Azure CNI pour l’allocation statique des CIDR et la prise en charge améliorée des sous-réseaux dans AKS.

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.
Version d’Azure CLI 2.37.0 ou ultérieure avec l’extension aks-preview de la version « 2.0.0b2 » 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 :
Inscrire l’indicateur de fonctionnalité au niveau de l’abonnement pour votre abonnement : « Microsoft.ContainerService/AzureVnetScalePreview »
```
az aks enable-addons --addons monitoring --name <cluster-name> --resource-group <resource-group-name>
```

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 quelconque 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

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-pod » 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, gaspillage d’adresses IP par nœud = 31 - 30 = 1 [Gaspillage faible, cas acceptable]
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, gaspillage d’adresses 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 d’adresses IP par nœud = 47 - 32 = 15 [Gaspillage élevé, cas non recommandé]

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.

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, à deux exceptions près :

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 pod ip allocation mode spécifie s’il faut utiliser l’allocation dynamique individuelle ou l’allocation de bloc statique.

Avant de commencer

Si vous utilisez Azure CLI, vous avez besoin de l’extension aks-preview. Consultez Installer l’extension aks-preview Azure CLI.
Si vous utilisez ARM ou l’API REST, la version de l’API AKS doit être 2024-01-02-preview ou une version ultérieure.

Installer l’extension Azure CLI `aks-preview`

Installez l'extension aks-preview à l'aide de la commande az extension add.
```
az extension add --name aks-preview
```
Mettez à jour vers la dernière version de l’extension à l’aide de la commande az extension update. L’extension doit avoir une version de « 2.0..0b2 » ou une version ultérieure
```
az extension update --name aks-preview
```

Inscrire l’indicateur de fonctionnalité `AzureVnetScalePreview`

Inscrivez l’indicateur de fonctionnalité AzureVnetScalePreview à l’aide de la commande az feature register.
```
az feature register --namespace "Microsoft.ContainerService" --name "AzureVnetScalePreview"
```
Quelques minutes sont nécessaires pour que l’état s’affiche Registered (Inscrit).

Vérifiez l’état de l’inscription en utilisant la commande az feature show.

az feature show --namespace "Microsoft.ContainerService" --name "AzureVnetScalePreview"

Quand l’état reflète Inscrit, actualisez l’inscription du fournisseur de ressources Microsoft.ContainerService à l’aide de la commande az provider register.
```
az provider register --namespace Microsoft.ContainerService
```

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 de l’allocation statique de blocs CIDR dans votre cluster est semblable à la méthode par défaut pour configurer un cluster Azure CNI pour l’allocation d’adresses IP dynamique. L’exemple suivant présente 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 Azure CNI avec l’allocation statique de blocs CIDR. 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

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 d’un cluster peuvent-ils utiliser l’allocation d’adresses IP dynamique, tandis 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 :

Partager via

Configurer la mise en réseau Azure CNI pour l’allocation statique de blocs CIDR et la prise en charge améliorée des sous-réseaux dans Azure Kubernetes Service (AKS) – (Préversion)

Prérequis

Limites

Disponibilité dans les régions

Planifier l’adressage IP

Paramètres de déploiement

Avant de commencer

Installer l’extension Azure CLI `aks-preview`

Inscrire l’indicateur de fonctionnalité `AzureVnetScalePreview`

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

Ajout d’un pool de nœuds

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

Étapes suivantes

Ressources supplémentaires

Partager via

Configurer la mise en réseau Azure CNI pour l’allocation statique de blocs CIDR et la prise en charge améliorée des sous-réseaux dans Azure Kubernetes Service (AKS) – (Préversion)

Prérequis

Limites

Disponibilité dans les régions

Planifier l’adressage IP

Paramètres de déploiement

Avant de commencer

Installer l’extension Azure CLI aks-preview

Inscrire l’indicateur de fonctionnalité AzureVnetScalePreview

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

Ajout d’un pool de nœuds

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

Étapes suivantes

Ressources supplémentaires

Installer l’extension Azure CLI `aks-preview`

Inscrire l’indicateur de fonctionnalité `AzureVnetScalePreview`