Utiliser la mise en réseau à double pile dans Azure Kubernetes Service (AKS)

Vous pouvez déployer vos clusters AKS en mode double pile lors de l’utilisation d’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 atteindre des 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).

Cet article explique comment utiliser le réseau à double pile avec un cluster AKS. Pour plus d’informations sur les options et considérations relatives aux réseaux, consultez Concepts de réseau pour Kubernetes et AKS.

Important

À compter du 30 novembre 2025, Azure Kubernetes Service (AKS) ne prend plus en charge ni fournit des mises à jour de sécurité pour Azure Linux 2.0. L’image de nœud Azure Linux 2.0 est figée à la version 202512.06.0. À compter du 31 octobre 2026, les images de nœud seront supprimées et vous ne pourrez pas mettre à l’échelle vos pools de nœuds. Migrez vers une version Azure Linux prise en charge en mettant à niveau vos pools de nœuds vers une version Kubernetes prise en charge ou en migrant vers osSku AzureLinux3. Pour plus d’informations, consultez le problème de retrait sur GitHub et l’annonce de retrait des mises à jour Azure. Pour rester informé des annonces et des mises à jour, suivez les notes de publication d’AKS.

Limites

Dans Azure pools de nœuds Linux, les services IPv6 nécessitent externalTrafficPolicy: Local.
La mise en réseau à double pile est requise pour le réseau virtuel Azure et le CIDR du pod.
- IPv6 à pile unique n’est pas pris en charge pour les adresses IP de nœud ou de pod. Les services peuvent être provisionnés sur IPv4 ou IPv6.
Azure CNI Overlay ne prend pas en charge les stratégies de réseau Azure ou Calico avec le réseau double pile. Pour utiliser des stratégies réseau, utilisez Azure CNI optimisé par Cilium.
La passerelle NAT standard prend uniquement en charge IPv4. Pour le trafic sortant en double pile, utilisez la passerelle NAT StandardV2. Le type de trafic sortant géré par AKS managedNATGateway prend désormais en charge et utilise par défaut la passerelle NAT StandardV2 dans les régions éligibles. Pour plus d’informations, consultez l’utilisation de la passerelle NAT avec AKS.
Le module complémentaire de nœuds virtuels n’est pas pris en charge avec la mise en réseau à double pile.

Conditions préalables

Azure CLI version 2.48.1 ou ultérieure. Exécutez az --version pour rechercher la version installée. Pour installer ou mettre à niveau le Azure CLI, consultez Installer Azure CLI.
Utilisez une version Kubernetes prise en charge dans AKS disponible dans votre région.

Cet article utilise Azure CNI Overlay. Vous pouvez également déployer un cluster double pile avec Azure CNI optimisé par Cilium sur des clusters Linux exécutant Kubernetes version 1.29 ou ultérieure.

Vue d’ensemble de la mise en réseau à double pile dans Kubernetes

Kubernetes v1.23 offre une prise en charge en amont stable pour les clusters IPv4/IPv6 à double pile , notamment les pods et la mise en réseau de service. Les nœuds et les pods sont toujours affectés à la fois à une adresse IPv4 et à une adresse IPv6, tandis que les services peuvent être à double pile ou à pile unique sur l’une ou l’autre famille d’adresses.

AKS configure les services de support requis pour le réseau double pile. Cette configuration inclut :

Si vous utilisez un réseau virtuel géré, configuration de réseau virtuel à double pile.
Adresses de nœud et de pod IPv4 et IPv6.
Règles de trafic sortant pour le trafic IPv4 et IPv6.
Configuration de l’équilibreur de charge pour les services IPv4 et IPv6.

Remarque

Lorsque vous utilisez la mise en réseau double pile avec un type sortant de routage défini par l’utilisateur, vous pouvez choisir d’avoir un itinéraire par défaut pour IPv6 selon que vous avez besoin de votre trafic IPv6 pour atteindre Internet. Si vous n’avez pas d’itinéraire par défaut pour IPv6, un avertissement s’affiche lorsque vous créez un cluster, mais n’empêche pas la création du cluster.

Paramètres du cluster à double pile

Les paramètres suivants prennent en charge les clusters à double pile :

Paramètre	Valeurs acceptées	Valeur par défaut	Constraints
`--ip-families`	`ipv4` ou `ipv4,ipv6`	Non spécifié(e)	Fournissez une liste séparée par des virgules de familles d’adresses IP à activer sur le cluster.
`--pod-cidrs`	Plages CIDR séparées par des virgules	`10.244.0.0/16,fd12:3456:789a::/64`	Le nombre et l’ordre des plages doivent correspondre `--ip-families`.
`--service-cidrs`	Plages CIDR séparées par des virgules	`10.0.0.0/16,fd12:3456:789a:1::/108`	Le nombre et l’ordre des plages doivent correspondre `--ip-families`. Le sous-réseau IPv6 ne peut pas être supérieur à `/108`.

Déployer un cluster AKS double pile

Créez un groupe de ressources Azure pour le cluster à l’aide de la az group create commande.
```
az group create --location <region> --name <resourceGroupName>
```

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

Après avoir créé le cluster, obtenez les informations d’identification du cluster à l’aide de la az aks get-credentials commande.
```
az aks get-credentials --resource-group <resourceGroupName> --name <clusterName>
```

Créez le modèle ARM et définissez la ipFamilies propriété de l’objet networkProfile sur ["IPv4", "IPv6"].

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "clusterName": {
      "type": "string",
      "defaultValue": "aksdualstack"
    },
    "location": {
      "type": "string",
      "defaultValue": "[resourceGroup().location]"
    },
    "nodeCount": {
      "type": "int",
      "defaultValue": 3
    },
    "nodeSize": {
      "type": "string",
      "defaultValue": "Standard_B2ms"
    }
  },
  "resources": [
    {
      "type": "Microsoft.ContainerService/managedClusters",
      "apiVersion": "2026-03-01",
      "name": "[parameters('clusterName')]",
      "location": "[parameters('location')]",
      "identity": {
        "type": "SystemAssigned"
      },
      "properties": {
        "agentPoolProfiles": [
          {
            "name": "nodepool1",
            "count": "[parameters('nodeCount')]",
            "mode": "System",
            "vmSize": "[parameters('nodeSize')]"
          }
        ],
        "dnsPrefix": "[parameters('clusterName')]",
        "networkProfile": {
          "networkPlugin": "azure",
          "networkPluginMode": "overlay",
          "ipFamilies": [
            "IPv4",
            "IPv6"
          ]
        }
      }
    }
  ]
}

Après avoir créé le cluster, obtenez les informations d’identification du cluster à l’aide de la az aks get-credentials commande.
```
az aks get-credentials --resource-group <resourceGroupName> --name <clusterName>
```

Remarque

Pour plus d’informations sur le déploiement de modèles Azure Resource Manager, consultez la documentation Azure Resource Manager.

Créez le modèle Bicep et définissez la ipFamilies propriété de l’objet networkProfile sur ["IPv4", "IPv6"].

param clusterName string = 'aksdualstack'
param location string = resourceGroup().location
param nodeCount int = 3
param nodeSize string = 'Standard_B2ms'

resource aksCluster 'Microsoft.ContainerService/managedClusters@2026-03-01' = {
  name: clusterName
  location: location
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    agentPoolProfiles: [
      {
        name: 'nodepool1'
        count: nodeCount
        mode: 'System'
        vmSize: nodeSize
      }
    ]
    dnsPrefix: clusterName
    networkProfile: {
      networkPlugin: 'azure'
      networkPluginMode: 'overlay'
      ipFamilies: [
        'IPv4'
        'IPv6'
      ]
    }
  }
}

Après avoir créé le cluster, obtenez les informations d’identification du cluster à l’aide de la az aks get-credentials commande.
```
az aks get-credentials --resource-group <resourceGroupName> --name <clusterName>
```

Remarque

Pour plus d’informations sur le déploiement de modèles Bicep, consultez la documentation du modèle Bicep.

Inspecter les nœuds pour voir les deux familles d’adresses IP

Une fois le cluster approvisionné, vérifiez à l’aide de la commande kubectl get nodes que les nœuds sont provisionnés pour utiliser la mise en réseau double pile.

kubectl get nodes -o=custom-columns="NAME:.metadata.name,ADDRESSES:.status.addresses[?(@.type=='InternalIP')].address,PODCIDRS:.spec.podCIDRs[*]"

La sortie de la commande kubectl get nodes montre que les nœuds ont des adresses et un espace d’attribution d’adresses IP aux pods à la fois pour IPv4 et IPv6.

NAME                                ADDRESSES                           PODCIDRS
aks-nodepool1-14508455-vmss000000   10.240.0.4,2001:1234:5678:9abc::4   10.244.0.0/24,fd12:3456:789a::/80
aks-nodepool1-14508455-vmss000001   10.240.0.5,2001:1234:5678:9abc::5   10.244.1.0/24,fd12:3456:789a:0:1::/80
aks-nodepool1-14508455-vmss000002   10.240.0.6,2001:1234:5678:9abc::6   10.244.2.0/24,fd12:3456:789a:0:2::/80

Créer un exemple de charge de travail

Déployez un serveur web NGINX avec trois répliques pour vérifier l’attribution d’adresses IP des pods en double pile.

Créez un serveur web NGINX en exécutant la kubectl create deployment nginx commande.
```
kubectl create deployment nginx --image=nginx:latest --replicas=3
```

Affichez les ressources de pod en exécutant la kubectl get pods commande.

kubectl get pods -o custom-columns="NAME:.metadata.name,IPs:.status.podIPs[*].ip,NODE:.spec.nodeName,READY:.status.conditions[?(@.type=='Ready')].status"

La sortie indique que les pods ont à la fois des adresses IPv4 et IPv6. Les pods n’affichent pas d’adresses IP tant qu’ils ne sont pas prêts.

NAME                     IPs                                NODE                                READY
nginx-55649fd747-9cr7h   10.244.2.2,fd12:3456:789a:0:2::2   aks-nodepool1-14508455-vmss000002   True
nginx-55649fd747-p5lr9   10.244.0.7,fd12:3456:789a::7       aks-nodepool1-14508455-vmss000000   True
nginx-55649fd747-r2rqh   10.244.1.2,fd12:3456:789a:0:1::2   aks-nodepool1-14508455-vmss000001   True

Créez un serveur web NGINX à l’aide du manifeste YAML suivant.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:latest
        name: nginx

Affichez les ressources de pod en exécutant la kubectl get pods commande.

kubectl get pods -o custom-columns="NAME:.metadata.name,IPs:.status.podIPs[*].ip,NODE:.spec.nodeName,READY:.status.conditions[?(@.type=='Ready')].status"

La sortie indique que les pods ont à la fois des adresses IPv4 et IPv6. Les pods n’affichent pas d’adresses IP tant qu’ils ne sont pas prêts.

NAME                     IPs                                NODE                                READY
nginx-55649fd747-9cr7h   10.244.2.2,fd12:3456:789a:0:2::2   aks-nodepool1-14508455-vmss000002   True
nginx-55649fd747-p5lr9   10.244.0.7,fd12:3456:789a::7       aks-nodepool1-14508455-vmss000000   True
nginx-55649fd747-r2rqh   10.244.1.2,fd12:3456:789a:0:1::2   aks-nodepool1-14508455-vmss000001   True

Exposez la charge de travail via un service de type `LoadBalancer`

Important

Azure Load Balancer envoie des sondes d’intégrité à des destinations IPv6 à partir d’une adresse locale. Sur Azure pools de nœuds Linux, le trafic vers les services IPv6 qui utilisent externalTrafficPolicy: Cluster échoue. Les exemples suivants configurent externalTrafficPolicy: Local sur le service IPv6 de sorte que kube-proxy réponde à la sonde sur le nœud.

kubectl
YAML

Exposez le déploiement NGINX avec des services IPv4 et IPv6 LoadBalancer distincts à l’aide de la kubectl expose deployment nginx commande.

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

Vous obtenez un résultat indiquant que les services ont été exposés.

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

Après avoir exposé le déploiement et entièrement approvisionné les LoadBalancer services, obtenez les adresses IP des services à l’aide de la kubectl get services commande.

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

Vérifiez les fonctionnalités d’une machine virtuelle Linux ou d’une machine locale avec une adresse IPv6 affectée et un routage IPv6 configuré. Azure Cloud Shell ne prend pas en charge 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>

Exposez le déploiement NGINX avec des services IPv4 et IPv6 LoadBalancer distincts à 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: Local
  ipFamilies:
    - IPv6
  ports:
    - port: 80
      protocol: TCP
      targetPort: 80
  selector:
    app: nginx
  type: LoadBalancer

Après avoir exposé le déploiement et entièrement approvisionné les LoadBalancer services, obtenez les adresses IP des services à l’aide de la kubectl get services commande.

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

Vérifiez les fonctionnalités d’une machine virtuelle Linux ou d’une machine locale avec une adresse IPv6 affectée et un routage IPv6 configuré. Azure Cloud Shell ne prend pas en charge 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>

Commentaires

Est-ce que cette page vous a été utile?

Dernière mise à jour : 2026-09-11

Utiliser la mise en réseau à double pile dans Azure Kubernetes Service (AKS)

Limites

Conditions préalables

Vue d’ensemble de la mise en réseau à double pile dans Kubernetes

Paramètres du cluster à double pile

Déployer un cluster AKS double pile

Inspecter les nœuds pour voir les deux familles d’adresses IP

Créer un exemple de charge de travail

Déployer un serveur web NGINX

Exposez la charge de travail via un service de type LoadBalancer

Commentaires

Ressources supplémentaires

Exposez la charge de travail via un service de type `LoadBalancer`