Configurer un réseau de superposition Azure CNI dans AKS (Azure Kubernetes Service)

L’interface CNI (Azure Container Networking Interface) traditionnelle attribue une adresse IP de réseau virtuel à chaque pod. Il attribue cette adresse IP à partir d’un ensemble d’adresses IP pré-réservées sur chaque nœud ou d’un sous-réseau distinct réservé aux pods. Cette approche nécessite la planification des adresses IP et peut entraîner un épuisement des adresses et des difficultés de mise à l’échelle de vos clusters à mesure que croissent les exigences de vos applications.

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

Comme la superposition Azure CNI, Kubenet affecte des adresses IP aux pods à partir d’un espace d’adressage logiquement différent du réseau virtuel, mais il présente certaines limitations, entre autres en termes de mise à l’échelle. Le tableau ci-dessous fournit une comparaison détaillée entre Kubenet et la superposition Azure CNI. Si vous ne souhaitez pas affecter d’adresses IP de réseau virtuel à des pods en raison d’une pénurie d’adresses IP, nous vous recommandons d’utiliser 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	Les tronçons supplémentaires augmentent le temps de latence
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 : Lors de la configuration de votre cluster AKS, assurez-vous que vos sous-réseaux de réseau virtuel ont suffisamment d’espace pour se développer en cas de mise à l’échelle à venir. 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 Overlay affecte un espace d’adressage /24 pour les pods sur chaque nœud à partir du CIDR privé que vous spécifiez lors de 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 des pods, assurez-vous que le CIDR privé est suffisamment grand pour fournir des espaces d’adressage /24 pour les nouveaux nœuds au cas où le cluster serait appelé à s’étendre.
  • Lors de la planification de l’espace d’adressage IP pour les pods, tenez compte des facteurs suivants :
    • 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 CIDR d’adresse de service dépend du nombre de services de cluster que vous envisagez de 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 de service DNS Kubernetes : Cette adresse IP se trouve dans la plage d’adresses de service Kubernetes, qui est utilisée par la découverte de 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 par défaut pour la superposition Azure CNI est 250. La valeur maximale que vous pouvez spécifier dans 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) pour un cluster Overlay.
• Vous ne pouvez pas utiliser Passerelle d’application pour conteneurs pour un cluster de superposition.
• Les groupes à haute disponibilité de machines virtuelles (VMAS) ne sont pas pris en charge pour la superposition.
• 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 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 doivent être d’au plus 63 caractères. Cela provient du fait que ces noms vont servir d’étiquettes dans des nœuds Worker AKS et sont donc soumis à des règles de syntaxe d’étiquette Kubernetes.

Configurer des clusters Overlay

Notes

Vous devez disposer de l’interface CLI version 2.48.0 ou ultérieure pour utiliser l’argument --network-plugin-mode. Pour Windows, vous devez avoir installé la dernière extension Azure CLI aks-preview et suivre les instructions ci-dessous.

Créez un cluster avec la superposition Azure CNI à l’aide de la commande az aks create. Veillez à utiliser --network-plugin-mode pour spécifier un cluster de superposition. Si le CIDR de pod n’est pas spécifié, AKS affecte un espace par défaut : viz. 10.244.0.0/16.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks create \
    --name $clusterName \
    --resource-group $resourceGroup \
    --location $location \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --pod-cidr 192.168.0.0/16 \
    --generate-ssh-keys

Ajouter un nouveau pool de nœuds à un sous-réseau dédié

Une fois que vous avez créé un cluster avec la superposition Azure CNI, vous pouvez créer un autre pool de nœuds et attribuer les nœuds à un nouveau sous-réseau du même réseau virtuel. Cette approche peut être utile si vous souhaitez contrôler les adresses IP d’entrée ou de sortie de l’hôte depuis/vers des cibles dans le même réseau virtuel ou les réseaux virtuels appairés.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"
nodepoolName="newpool1"
subscriptionId=$(az account show --query id -o tsv)
vnetName="yourVnetName"
subnetName="yourNewSubnetName"
subnetResourceId="/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnetName/subnets/$subnetName"
az aks nodepool add --resource-group $resourceGroup --cluster-name $clusterName \
  --name $nodepoolName --node-count 1 \
  --mode system --vnet-subnet-id $subnetResourceId

Mettre à niveau un cluster existant vers la superposition CNI

Notes

Vous pouvez mettre à jour un cluster Azure CNI existant vers la superposition si le cluster répond aux critères suivants :

• Le cluster se trouve sur Kubernetes version 1.22+.
• Ne pas utiliser la fonctionnalité d’allocation d’adresses IP de pod dynamique.
• Ne doit pas présenter de stratégies réseau activées. Le moteur de stratégie réseau peut être désinstallé avant la mise à niveau, consultez Désinstaller Azure Network Policy Manager ou Calico
• Ne doit pas utiliser de pools de nœuds Windows avec Docker comme runtime de conteneur.

Remarque

La mise à niveau d’un cluster existant vers la superposition CNI est un processus non réversible.

Avertissement

Avant la version 20348.1668 du système d’exploitation Windows, il y avait une limitation relative aux pods Overlay Windows effectuant un SNAT incorrect des paquets depuis des pods réseau hôtes, ce qui a un effet plus néfaste pour la mise à niveau des clusters vers Overlay. Pour éviter ce problème, utilisez la build du système d’exploitation Windows supérieure ou égale à 20348.1668.

Avertissement

Si vous utilisez une configuration azure-ip-masq-agent personnalisée pour ajouter des plages IP supplémentaires qui ne doivent pas faire de traduction SNAT des paquets provenant des pods, la mise à niveau vers la superposition Azure CNI peut interrompre la connectivité vers ces plages. Les adresses IP de pod à partir de l’espace de superposition ne sont accessibles par rien en dehors des nœuds de cluster. Par ailleurs, pour les clusters suffisamment anciens, il peut rester un ConfigMap d’une version précédente d’azure-ip-masq-agent. Si ce ConfigMap, nommé azure-ip-masq-agent-config, existe et n’est pas intentionnellement sur place, il doit être supprimé avant d’exécuter la commande update. Si vous n’utilisez pas une configuration ip-masq-agent personnalisée, seul le azure-ip-masq-agent-config-reconciled ConfigMap doit exister par rapport à Azure ip-masq-agent ConfigMaps, qui sera mis à jour automatiquement pendant le processus de mise à niveau.

Le processus de mise à niveau déclenche la réimage de chaque pool de nœuds simultanément. La mise à niveau de chaque pool de nœuds séparément vers overlay n’est pas prise en charge. Toutes les interruptions de mise en réseau de cluster sont similaires à une mise à niveau d’image de nœud ou à une mise à niveau de version de Kubernetes où chaque nœud d’un pool de nœuds est réimagé.

Mise à niveau de cluster Azure CNI

Mettez à jour un cluster Azure CNI existant pour utiliser Overlay à l’aide de la commande az aks update.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin-mode overlay \
--pod-cidr 192.168.0.0/16

Le paramètre --pod-cidr est obligatoire lors de la mise à niveau à partir de CNI hérité, car les pods doivent obtenir des adresses IP depuis un nouvel espace de superposition qui ne chevauche pas le sous-réseau du nœud existant. Le CIDR du pod ne peut pas non plus chevaucher une adresse de réseau virtuel des pools de nœuds. Par exemple, si l’adresse de votre réseau virtuel est 10.0.0.0/8, et que vos nœuds se trouvent dans le sous-réseau 10.240.0.0.0/16, le --pod-cidr ne peut pas chevaucher 10.0.0.0/8 ou le CIDR de service existant sur le cluster.

Mise à niveau de cluster Kubenet

Mettez à jour un cluster Kubenet existant pour utiliser une superposition Azure CNI en tirant parti de la commande az aks update.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin azure \
--network-plugin-mode overlay 

Comme le cluster utilise déjà un CIDR privé pour les pods qui ne chevauchent pas l’espace IP du réseau virtuel, vous n’avez pas besoin de spécifier le paramètre --pod-cidr et le CIDR du pod va rester le même si le paramètre n’est pas utilisé.

Remarque

Lors d’une mise à niveau de Kubenet vers une superposition CNI, la table de route n’est plus nécessaire pour le routage de pods. Si le cluster utilise une table de route fournie par un client, les routes qui étaient utilisées pour diriger le trafic de pods vers le nœud correct sont automatiquement supprimées pendant l’opération de migration. Si le cluster utilise une table de route managée (la table de route a été créée par AKS et réside dans le groupe de ressources du nœud), cette table de route est supprimée dans le cadre de la migration.

Azure Networking à double pile

Vous pouvez déployer vos clusters AKS en mode double pile quand vous utilisez le réseau de superposition et un réseau virtuel Azure double pile. Dans cette configuration, les nœuds reçoivent à la fois une adresse IPv4 et une adresse IPv6 du sous-réseau du réseau virtuel Azure. Les pods reçoivent à la fois une adresse IPv4 et une adresse IPv6 du sous-réseau du réseau virtuel Azure des nœuds à partir d’un espace d’adressage logiquement différent. La traduction d’adresses réseau (NAT) est ensuite configurée afin que les pods puissent accéder aux ressources sur le réseau virtuel Azure. L’adresse IP source du trafic est traduite en adresse IP principale du nœud de la même famille (IPv4 vers IPv4 et IPv6 vers IPv6).

Prérequis

• Vous devez avoir Azure CLI 2.48.0 ou version ultérieure.
• Kubernetes version 1.26.3 ou ultérieure.

Limites

Les fonctionnalités suivantes ne sont pas prises en charge avec le réseau double pile :

• Stratégies réseau Azure
• Stratégies réseau Calico
• NAT Gateway
• le module complémentaire de nœuds virtuels.

Déployer un cluster AKS double pile

Les attributs suivants sont fournis pour prendre en charge les clusters à double pile :

• --ip-families : utilise une liste de familles d’adresses IP séparées par des virgules, à activer sur le cluster.
  • Seuls ipv4 ou ipv4,ipv6 sont pris en charge.
• --pod-cidrs : utilise une liste de plages d’adresses IP en notation CIDR, séparées par des virgules, à partir de laquelle attribuer des adresses IP aux pods.
  • Le nombre et l’ordre des plages dans cette liste doivent correspondre à la valeur fournie à --ip-families.
  • Si aucune valeur n’est fournie, la valeur par défaut 10.244.0.0/16,fd12:3456:789a::/64 est utilisée.
• --service-cidrs : utilise une liste de plages d’adresses IP en notation CIDR, séparées par des virgules, à partir de laquelle attribuer des adresses IP aux services.
  • Le nombre et l’ordre des plages dans cette liste doivent correspondre à la valeur fournie à --ip-families.
  • Si aucune valeur n’est fournie, la valeur par défaut 10.0.0.0/16,fd12:3456:789a:1::/108 est utilisée.
  • Le sous-réseau IPv6 attribué à --service-cidrs ne peut pas être supérieur à /108.

Créer un cluster AKS double pile

1. Créez un groupe de ressources Azure pour le cluster en utilisant la commande [az group create][az-group-create].

   az group create --location <region> --name <resourceGroupName>
   

2. Créez un cluster AKS à double pile à l’aide de la commande az aks create avec le paramètre --ip-families défini sur ipv4,ipv6.

   az aks create \
       --location <region> \
       --resource-group <resourceGroupName> \
       --name <clusterName> \
       --network-plugin azure \
       --network-plugin-mode overlay \
       --ip-families ipv4,ipv6 \
       --generate-ssh-keys
   

Créer un exemple de charge de travail

Une fois le cluster créé, vous pouvez déployer vos charges de travail. Cet article vous guide à travers un exemple de déploiement de charge de travail d’un serveur web NGINX.

Déployer un serveur web NGINX

Le module complémentaire de routage d’application est la méthode recommandée pour l’entrée dans un cluster AKS. Pour plus d’informations sur le module complémentaire de routage d’application et un exemple de déploiement d’une application avec le module complémentaire, consultez l’entrée NGINX managée avec le module complémentaire de routage d’application.

Exposez la charge de travail via un service de type LoadBalancer

Important

Il existe actuellement deux limitations concernant les services IPv6 dans AKS.

• Azure Load Balancer envoie des sondes d’intégrité à des destinations IPv6 à partir d’une adresse locale. Dans les pools de nœuds Azure Linux, ce trafic ne peut pas être routé vers un pod : le trafic circulant vers les services IPv6 déployés avec externalTrafficPolicy: Cluster va donc échouer. Les services IPv6 doivent être déployés avec externalTrafficPolicy: Local, ce qui amène kube-proxy à répondre à la sonde sur le nœud.
• Avant la version Kubernetes 1.27, seule la première adresse IP d’un service est provisionnée sur l’équilibreur de charge, par conséquent, un service double pile reçoit une IP publique uniquement pour sa première famille IP listée. Afin de fournir un service à double pile pour un seul déploiement, créez deux services ciblant le même sélecteur, un pour IPv4 et l’autre pour IPv6. Il ne s’agit plus d’une limitation dans Kubernetes 1.27 ou version ultérieure.

kubectl

1. Exposez le déploiement NGINX à l’aide de la commande kubectl expose deployment nginx.

   kubectl expose deployment nginx --name=nginx-ipv4 --port=80 --type=LoadBalancer'
   kubectl expose deployment nginx --name=nginx-ipv6 --port=80 --type=LoadBalancer --overrides='{"spec":{"ipFamilies": ["IPv6"]}}'
   

   Vous recevez une sortie qui indique que les services ont été exposés.

   service/nginx-ipv4 exposed
   service/nginx-ipv6 exposed
   

2. Une fois que le déploiement est exposé et que les services LoadBalancer sont entièrement provisionnés, obtenez les adresses IP des services à l’aide de la commande kubectl get services.

   kubectl get services
   

   NAME         TYPE           CLUSTER-IP               EXTERNAL-IP         PORT(S)        AGE
   nginx-ipv4   LoadBalancer   10.0.88.78               20.46.24.24         80:30652/TCP   97s
   nginx-ipv6   LoadBalancer   fd12:3456:789a:1::981a   2603:1030:8:5::2d   80:32002/TCP   63s
   

3. Vérifiez les fonctionnalités via une requête web en ligne de commande à partir d’un hôte compatible IPv6. Azure Cloud Shell n’est pas compatible IPv6.

   SERVICE_IP=$(kubectl get services nginx-ipv6 -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
   curl -s "http://[${SERVICE_IP}]" | head -n5
   

   <!DOCTYPE html>
   <html>
   <head>
   <title>Welcome to nginx!</title>
   <style>
   

YAML

1. Exposez le déploiement NGINX à l’aide du manifeste YAML suivant.

   ---
   apiVersion: v1
   kind: Service
   metadata:
     labels:
       app: nginx
     name: nginx-ipv4
   spec:
     externalTrafficPolicy: Cluster
     ports:
    - port: 80
       protocol: TCP
       targetPort: 80
     selector:
       app: nginx
     type: LoadBalancer
   ---
   apiVersion: v1
   kind: Service
   metadata:
     labels:
       app: nginx
     name: nginx-ipv6
   spec:
     externalTrafficPolicy: Cluster
     ipFamilies:
    - IPv6
     ports:
    - port: 80
       protocol: TCP
       targetPort: 80
     selector:
       app: nginx
     type: LoadBalancer
   

2. Une fois que le déploiement est exposé et que les services LoadBalancer sont entièrement provisionnés, obtenez les adresses IP des services à l’aide de la commande kubectl get services.

   kubectl get services
   

   NAME         TYPE           CLUSTER-IP               EXTERNAL-IP         PORT(S)        AGE
   nginx-ipv4   LoadBalancer   10.0.88.78               20.46.24.24         80:30652/TCP   97s
   nginx-ipv6   LoadBalancer   fd12:3456:789a:1::981a   2603:1030:8:5::2d   80:32002/TCP   63s
   

Mise en réseau double pile à l’aide d’Azure CNI avec Cilium – (Préversion)

Vous pouvez déployer vos clusters AKS double pile à l’aide d’Azure CNI avec Cilium. Cela vous permet également de contrôler votre trafic IPv6 avec le moteur de stratégie réseau Cilium.

Important

Les fonctionnalités d’évaluation AKS sont disponibles en libre-service et font l’objet d’un abonnement. Les préversions sont fournies « en l’état » et « en fonction des disponibilités », et sont exclues des contrats de niveau de service et de la garantie limitée. Les préversions AKS sont, dans la mesure du possible, partiellement couvertes par le service clientèle. Telles quelles, ces fonctionnalités ne sont pas destinées à une utilisation en production. Pour plus d’informations, consultez les articles de support suivants :

• Stratégies de support AKS
• FAQ du support Azure

Prérequis

• Vous devez disposer de la dernière version de l’extension de prévisualisation AKS.
• Vous devez disposer de Kubernetes version 1.29 ou 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 publiée à l’aide de la commande az extension update.

  az extension update --name aks-preview
  

Enregistrer l’indicateur de fonctionnalité « AzureOverlayDualStackPreview »

1. Inscrivez l’indicateur de fonctionnalité AzureOverlayDualStackPreview à l’aide de la commande az feature register.

   az feature register --namespace "Microsoft.ContainerService" --name "AzureOverlayDualStackPreview"
   

   Quelques minutes sont nécessaires pour que l’état s’affiche Registered (Inscrit).

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

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

3. 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 des clusters de superposition à l’aide d’Azure CNI avec Cilium

Créez un cluster avec la superposition Azure CNI à l’aide de la commande az aks create. Veillez à utiliser l’argument --network-dataplane cilium pour spécifier le plan de données Cilium.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks create \
    --name $clusterName \
    --resource-group $resourceGroup \
    --location $location \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --network-dataplane cilium \
    --ip-families ipv4,ipv6 \
    --generate-ssh-keys\

Pour plus d’informations sur Azure CNI avec Cilium, consultez Azure CNI avec Cilium.

Pools de nœuds Windows double pile – (Préversion)

Vous pouvez déployer vos clusters AKS double pile avec des pools de nœuds Windows.

Important

Les fonctionnalités d’évaluation AKS sont disponibles en libre-service et font l’objet d’un abonnement. Les préversions sont fournies « en l’état » et « en fonction des disponibilités », et sont exclues des contrats de niveau de service et de la garantie limitée. Les préversions AKS sont, dans la mesure du possible, partiellement couvertes par le service clientèle. Telles quelles, ces fonctionnalités ne sont pas destinées à une utilisation en production. Pour plus d’informations, consultez les articles de support suivants :

• Stratégies de support AKS
• FAQ du support Azure

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 publiée à l’aide de la commande az extension update.

  az extension update --name aks-preview
  

Enregistrer l’indicateur de fonctionnalité « AzureOverlayDualStackPreview »

1. Inscrivez l’indicateur de fonctionnalité AzureOverlayDualStackPreview à l’aide de la commande az feature register.

   az feature register --namespace "Microsoft.ContainerService" --name "AzureOverlayDualStackPreview"
   

   Quelques minutes sont nécessaires pour que l’état s’affiche Registered (Inscrit).

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

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

3. 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 un cluster de superposition

Créez un cluster avec la superposition Azure CNI à l’aide de la commande az aks create.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks create \
    --name $clusterName \
    --resource-group $resourceGroup \
    --location $location \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --ip-families ipv4,ipv6 \
    --generate-ssh-keys\

Ajouter un pool de nœuds Windows au cluster

Ajoutez un pool de nœuds Windows au cluster à l’aide de la commande [az aks nodepool add][az-aks-nodepool-add].

az aks nodepool add \
    --resource-group $resourceGroup \
    --cluster-name $clusterName \
    --os-type Windows \
    --name winpool1 \
    --node-count 2

Étapes suivantes

Pour apprendre à utiliser AKS avec votre propre plug-in CNI (Container Network Interface), consultez Apporter votre propre plug-in CNI (Container Network Interface).