Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les organisations ont généralement des exigences strictes en matière de sécurité et de conformité pour réglementer le trafic réseau (sortant) d’un cluster, afin d’éliminer les risques d’exfiltration des données. Par défaut, les clusters Azure Kubernetes Service (AKS) standard disposent d’un accès Internet sortant illimité. Ce niveau d’accès réseau permet aux nœuds et services que vous exécutez d’accéder aux ressources externes en fonction des besoins. Si vous souhaitez restreindre le trafic de sortie, un nombre limité de ports et adresses doit être accessible afin de gérer les tâches de maintenance d’intégrité du cluster. Le document conceptuel à propos des règles de réseau sortant et de FQDN pour les clusters AKS fournit une liste des points de terminaison nécessaires au cluster AKS ainsi que de ses extensions et fonctionnalités facultatives.
Une solution courante pour restreindre le trafic sortant du cluster consiste à utiliser un appareil de pare-feu pour restreindre le trafic en fonction des règles de pare-feu. Le pare-feu s’applique lorsque votre application requiert un accès sortant, mais lorsque les demandes sortantes doivent être inspectées et sécurisées. La configuration manuelle d’un pare-feu avec les règles de sortie requises et les FQDN est un processus fastidieux, en particulier si vous devez uniquement créer un cluster AKS isolé sans dépendances sortantes pour le démarrage du cluster.
Pour réduire le risque d’exfiltration des données, le cluster isolé réseau permet de démarrer le cluster AKS sans dépendances réseau sortantes, même pour extraire des composants/images de cluster à partir de Microsoft Artifact Registry (MAR). L’opérateur de cluster peut configurer de manière incrémentielle le trafic sortant autorisé pour chaque scénario qu’il souhaite activer. Cet article vous guide tout au long des étapes de création d’un cluster isolé réseau.
Avant de commencer
- Consultez la vue d’ensemble conceptuelle de cette fonctionnalité, qui explique le fonctionnement des clusters isolés du réseau. En outre, l’article de vue d’ensemble :
- Explique deux options pour la ressource Azure Container Registry (ACR) privée utilisée pour l’amorçage de cluster - ACR managé par AKS ou apportez votre propre ACR.
- Explique deux modes de cluster privé pour la création d’un accès privé au serveur d’API : par lien privé ou par intégration du serveur d’API au Vnet.
- Décrivez les deux types sortants pour le contrôle de sortie de cluster –
noneoublock(préversion). - Décrit les limitations actuelles des clusters isolés réseau.
Remarque
Le type de sortie none est généralement disponible.
Le type de sortie block est en préversion.
Important
Les fonctionnalités d’évaluation AKS sont disponibles en libre-service et font l’objet d’un abonnement. Les versions préliminaires sont fournies « en l’état » et « selon les disponibilités », et sont exclues des accords 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 :
Utilisez l’environnement Bash dans Azure Cloud Shell. Pour obtenir plus d’informations, consultez Démarrage d’Azure Cloud Shell.
Si vous préférez exécuter les commandes de référence de l’interface de ligne de commande localement, installez l’interface Azure CLI. Si vous exécutez sur Windows ou macOS, envisagez d’exécuter Azure CLI dans un conteneur Docker. Pour plus d’informations, consultez Guide pratique pour exécuter Azure CLI dans un conteneur Docker.
Si vous utilisez une installation locale, connectez-vous à Azure CLI à l’aide de la commande az login. Pour finir le processus d’authentification, suivez les étapes affichées dans votre terminal. Pour obtenir d’autres options de connexion, consultez S’authentifier auprès d’Azure à l’aide d’Azure CLI.
Lorsque vous y êtes invité, installez l’extension Azure CLI lors de la première utilisation. Pour plus d’informations sur les extensions, consultez Utiliser et gérer des extensions avec Azure CLI.
Exécutez az version pour rechercher la version et les bibliothèques dépendantes installées. Pour effectuer une mise à niveau vers la dernière version, exécutez az upgrade.
- Cet article nécessite la version 2.71.0 ou ultérieure d’Azure CLI. Si vous utilisez Azure Cloud Shell, sachez que la dernière version y est déjà installée.
- Vous devez installer l’extension
aks-previewAzure CLI version 9.0.0b2 ou ultérieure si vous utilisez le type de sortieblock(préversion).- Si vous n’avez pas encore l’extension
aks-preview, installez-la en utilisant la commandeaz extension add.az extension add --name aks-preview - Si vous disposez déjà de l’extension
aks-preview, mettez-la à jour pour vous assurer que vous disposez de la dernière version en utilisant la commandeaz extension update.az extension update --name aks-preview
- Si vous n’avez pas encore l’extension
- Les clusters isolés du réseau sont pris en charge sur les clusters AKS qui utilisent la version 1.30 ou ultérieure de Kubernetes.
- Si vous choisissez d’utiliser l’option Bring Your Own (BYO) Azure Container Registry (ACR), vous devez vérifier que l’ACR est au niveau de service SKU Premium.
- Si vous utilisez un cluster isolé réseau configuré avec l’intégration au réseau virtuel du serveur d’API, vous devez suivre les prérequis et les conseils fournis dans ce document.
Déployer un cluster isolé du réseau avec ACR géré par AKS
AKS crée, gère et rapproche une ressource ACR dans cette option. Vous n’avez pas besoin d’attribuer d’autorisations ni de gérer l’ACR. AKS gère les règles de cache, la liaison privée et le point de terminaison privé utilisés dans le cluster isolé du réseau.
Créer un cluster isolé du réseau
Lors de la création d'un cluster AKS isolé de réseau, vous pouvez choisir l'un des modes de cluster privé suivants : basé sur un lien privé ou intégration du serveur API dans le réseau virtuel.
Quel que soit le mode que vous sélectionnez, vous devez définir les paramètres --bootstrap-artifact-source et --outbound-type.
Le --bootstrap-artifact-source peut être défini soit sur Direct, soit sur Cache, correspondant à l'utilisation de MAR directement (non isolé du réseau) et d'ACR privé (isolé du réseau) pour les téléchargements d'images respectivement.
--outbound-type parameter peut être défini sur none ou block (préversion). Si le type sortant est défini sur none, AKS ne configure pas de connexions sortantes pour le cluster, ce qui permet à l’utilisateur de les configurer lui même. Si le type de trafic sortant est défini sur block, toutes les connexions sortantes sont bloquées.
Basé sur un lien privé
Créez un cluster isolé basé sur des liaisons privées en exécutant la commande az aks create avec --bootstrap-artifact-source, --enable-private-clusteret --outbound-type les paramètres.
az aks create --resource-group ${RESOURCE_GROUP} --name ${AKS_NAME} --kubernetes-version 1.30.3 --bootstrap-artifact-source Cache --outbound-type none --network-plugin azure --enable-private-cluster
Intégration du serveur d’API à VNet
Créez un cluster isolé du réseau configuré avec l’intégration au réseau virtuel de serveur d’API en exécutant la commande az aks create à l’aide des paramètres --bootstrap-artifact-source, --enable-private-cluster, --enable-apiserver-vnet-integration et --outbound-type.
az aks create --resource-group ${RESOURCE_GROUP} --name ${AKS_NAME} --kubernetes-version 1.30.3 --bootstrap-artifact-source Cache --outbound-type none --network-plugin azure --enable-private-cluster --enable-apiserver-vnet-integration
Mettre à jour un cluster AKS existant vers un type isolé du réseau
Si vous préférez activer l’isolation réseau sur un cluster AKS existant au lieu de créer un cluster, utilisez la commande az aks update.
Pour activer la fonctionnalité isolée réseau sur un cluster AKS existant, exécutez d’abord la commande suivante pour mettre à jour bootstrap-artifact-source:
az aks update --resource-group ${RESOURCE_GROUP} --name ${AKS_NAME} --bootstrap-artifact-source Cache
Ensuite, vous devez réimager manuellement tous les pools de nœuds en cours :
az aks upgrade --resource-group ${RESOURCE_GROUP} --name ${AKS_NAME} --node-image-only
Remarque
Vous devez assurer que le trafic sortant existe jusqu’à la fin de la première réinitialisation. Pour vérifier si la réimage est terminée, exécutez :
NODEPOOLS=$(az aks nodepool list \
--resource-group "${RESOURCE_GROUP}" \
--cluster-name "${AKS_NAME}" \
--query "[].name" -o tsv)
for NODEPOOL in $NODEPOOLS; do
echo "Waiting for node pool $NODEPOOL to finish upgrading..."
az aks nodepool wait \
--resource-group "${RESOURCE_GROUP}" \
--cluster-name "${AKS_NAME}" \
--name "$NODEPOOL" \
--updated
echo "Node pool $NODEPOOL upgrade succeeded."
done
Attendez et vérifiez que la réimage est terminée, puis exécutez la commande suivante pour mettre à jour outbound-type:
az aks update --resource-group ${RESOURCE_GROUP} --name ${AKS_NAME} --outbound-type none
Important
N’oubliez pas de réimager instantanément les pools de nœuds du cluster après avoir mis à jour la source de l’artefact dans le cache. Sinon, la fonctionnalité ne prend pas effet pour le cluster.
Déployer un cluster isolé du réseau avec ACR apporté par vous
AKS prend en charge l’apport de votre propre ACR (BYO). Pour prendre en charge le scénario ACR BYO, vous devez configurer un point de terminaison privé ACR et une zone DNS privée avant de créer le cluster AKS.
Les étapes suivantes montrent comment préparer ces ressources :
- Réseau virtuel personnalisé et sous-réseaux pour AKS et ACR.
- ACR, règle de cache ACR, point de terminaison privé et zone DNS privée.
- Identité du plan de contrôle personnalisé et identité kubelet.
Étape 1 : Créer le réseau virtuel et les sous-réseau
az group create --name ${RESOURCE_GROUP} --location ${LOCATION}
az network vnet create --resource-group ${RESOURCE_GROUP} --name ${VNET_NAME} --address-prefixes 192.168.0.0/16
az network vnet subnet create --name ${AKS_SUBNET_NAME} --vnet-name ${VNET_NAME} --resource-group ${RESOURCE_GROUP} --address-prefixes 192.168.1.0/24
SUBNET_ID=$(az network vnet subnet show --name ${AKS_SUBNET_NAME} --vnet-name ${VNET_NAME} --resource-group ${RESOURCE_GROUP} --query 'id' --output tsv)
az network vnet subnet create --name ${ACR_SUBNET_NAME} --vnet-name ${VNET_NAME} --resource-group ${RESOURCE_GROUP} --address-prefixes 192.168.2.0/24 --private-endpoint-network-policies Disabled
Étape 2 : Désactiver la connectivité sortante du réseau virtuel (facultatif)
Il existe plusieurs façons de désactiver la connectivité sortante du réseau virtuel.
Étape 3 : Créer l’ACR et activer le cache d’artefacts
Créez l’ACR avec la liaison privée.
az acr create --resource-group ${RESOURCE_GROUP} --name ${REGISTRY_NAME} --sku Premium --public-network-enabled false REGISTRY_ID=$(az acr show --name ${REGISTRY_NAME} -g ${RESOURCE_GROUP} --query 'id' --output tsv)Créez une règle de cache ACR en suivant la commande ci-dessous pour permettre aux utilisateurs de mettre en cache des images conteneur MAR et des fichiers binaires dans la nouvelle ACR, notez que le nom de la règle de cache et les noms de référentiel doivent être strictement alignés sur les instructions ci-dessous.
az acr cache create -n aks-managed-mcr -r ${REGISTRY_NAME} -g ${RESOURCE_GROUP} --source-repo "mcr.microsoft.com/*" --target-repo "aks-managed-repository/*"
Remarque
Avec BYO ACR, il vous incombe de vous assurer que la règle de cache ACR est créée et gérée correctement comme indiqué ci-dessus. Cette étape est essentielle pour la création, le fonctionnement et la mise à niveau du cluster. Cette règle de cache ne doit PAS être modifiée.
Étape 4 : Créer un point de terminaison privé pour l’ACR
az network private-endpoint create --name myPrivateEndpoint --resource-group ${RESOURCE_GROUP} --vnet-name ${VNET_NAME} --subnet ${ACR_SUBNET_NAME} --private-connection-resource-id ${REGISTRY_ID} --group-id registry --connection-name myConnection
NETWORK_INTERFACE_ID=$(az network private-endpoint show --name myPrivateEndpoint --resource-group ${RESOURCE_GROUP} --query 'networkInterfaces[0].id' --output tsv)
REGISTRY_PRIVATE_IP=$(az network nic show --ids ${NETWORK_INTERFACE_ID} --query "ipConfigurations[?privateLinkConnectionProperties.requiredMemberName=='registry'].privateIPAddress" --output tsv)
DATA_ENDPOINT_PRIVATE_IP=$(az network nic show --ids ${NETWORK_INTERFACE_ID} --query "ipConfigurations[?privateLinkConnectionProperties.requiredMemberName=='registry_data_$LOCATION'].privateIPAddress" --output tsv)
Étape 5 : Créer une zone DNS privée et ajouter des enregistrements
Créer une zone DNS privée nommée privatelink.azurecr.io. Ajoutez les enregistrements du point de terminaison REST du registre {REGISTRY_NAME}.azurecr.io et le point de terminaison de données du registre {REGISTRY_NAME}.{REGISTRY_LOCATION}.data.azurecr.io.
az network private-dns zone create --resource-group ${RESOURCE_GROUP} --name "privatelink.azurecr.io"
az network private-dns link vnet create --resource-group ${RESOURCE_GROUP} --zone-name "privatelink.azurecr.io" --name MyDNSLink --virtual-network ${VNET_NAME} --registration-enabled false
az network private-dns record-set a create --name ${REGISTRY_NAME} --zone-name "privatelink.azurecr.io" --resource-group ${RESOURCE_GROUP}
az network private-dns record-set a add-record --record-set-name ${REGISTRY_NAME} --zone-name "privatelink.azurecr.io" --resource-group ${RESOURCE_GROUP} --ipv4-address ${REGISTRY_PRIVATE_IP}
az network private-dns record-set a create --name ${REGISTRY_NAME}.${LOCATION}.data --zone-name "privatelink.azurecr.io" --resource-group ${RESOURCE_GROUP}
az network private-dns record-set a add-record --record-set-name ${REGISTRY_NAME}.${LOCATION}.data --zone-name "privatelink.azurecr.io" --resource-group ${RESOURCE_GROUP} --ipv4-address ${DATA_ENDPOINT_PRIVATE_IP}
Étape 6 : Créer un plan de contrôle et des identités kubelet
Identité de plan de contrôle
az identity create --name ${CLUSTER_IDENTITY_NAME} --resource-group ${RESOURCE_GROUP}
CLUSTER_IDENTITY_RESOURCE_ID=$(az identity show --name ${CLUSTER_IDENTITY_NAME} --resource-group ${RESOURCE_GROUP} --query 'id' -o tsv)
CLUSTER_IDENTITY_PRINCIPAL_ID=$(az identity show --name ${CLUSTER_IDENTITY_NAME} --resource-group ${RESOURCE_GROUP} --query 'principalId' -o tsv)
Identité Kubelet
az identity create --name ${KUBELET_IDENTITY_NAME} --resource-group ${RESOURCE_GROUP}
KUBELET_IDENTITY_RESOURCE_ID=$(az identity show --name ${KUBELET_IDENTITY_NAME} --resource-group ${RESOURCE_GROUP} --query 'id' -o tsv)
KUBELET_IDENTITY_PRINCIPAL_ID=$(az identity show --name ${KUBELET_IDENTITY_NAME} --resource-group ${RESOURCE_GROUP} --query 'principalId' -o tsv)
Accorder des autorisations AcrPull pour l’identité Kubelet
az role assignment create --role AcrPull --scope ${REGISTRY_ID} --assignee-object-id ${KUBELET_IDENTITY_PRINCIPAL_ID} --assignee-principal-type ServicePrincipal
Après avoir configuré ces ressources, vous pouvez continuer à créer le cluster AKS isolé du réseau avec ACR BYO.
Étape 7 : Créer un cluster isolé réseau à l’aide de BYO ACR
Lors de la création d’un cluster isolé du réseau, vous pouvez choisir l’un des modes de cluster privé suivants : liaison privée ou intégration au réseau virtuel du serveur d’API.
Quel que soit le mode que vous sélectionnez, vous devez définir les paramètres --bootstrap-artifact-source et --outbound-type.
--bootstrap-artifact-source peut être défini sur Direct ou sur Cache ce qui correspond à l’utilisation direct du Registre des artefacts Microsoft (MAR) (NON isolé du réseau) et d’ACR privé (isolé du réseau) pour les tirages d’images respectivement.
--outbound-type parameter peut être défini sur none ou block (préversion). Si le type sortant est défini sur none, AKS ne configure pas de connexions sortantes pour le cluster, ce qui permet à l’utilisateur de les configurer lui même. Si le type de trafic sortant est défini sur block, toutes les connexions sortantes sont bloquées.
Basé sur un lien privé
Créez un cluster isolé basé sur des liaisons privées qui accède à votre ACR en exécutant la commande az aks create avec les paramètres requis.
az aks create --resource-group ${RESOURCE_GROUP} --name ${AKS_NAME} --kubernetes-version 1.30.3 --vnet-subnet-id ${SUBNET_ID} --assign-identity ${CLUSTER_IDENTITY_RESOURCE_ID} --assign-kubelet-identity ${KUBELET_IDENTITY_RESOURCE_ID} --bootstrap-artifact-source Cache --bootstrap-container-registry-resource-id ${REGISTRY_ID} --outbound-type none --network-plugin azure --enable-private-cluster
Intégration du serveur d’API à VNet
Pour un cluster isolé réseau configuré avec l’intégration au réseau virtuel du serveur d’API, commencez par créer un sous-réseau et attribuez le rôle approprié avec les commandes suivantes :
az network vnet subnet create --name ${APISERVER_SUBNET_NAME} --vnet-name ${VNET_NAME} --resource-group ${RESOURCE_GROUP} --address-prefixes 192.168.3.0/24
export APISERVER_SUBNET_ID=$(az network vnet subnet show --resource-group ${RESOURCE_GROUP} --vnet-name ${VNET_NAME} --name ${APISERVER_SUBNET_NAME} --query id -o tsv)
az role assignment create --scope ${APISERVER_SUBNET_ID} --role "Network Contributor" --assignee-object-id ${CLUSTER_IDENTITY_PRINCIPAL_ID} --assignee-principal-type ServicePrincipal
Créez un cluster isolé réseau configuré avec l’intégration au réseau virtuel du serveur d’API et accédez à votre ACR en exécutant la commande az aks create avec les paramètres requis.
az aks create --resource-group ${RESOURCE_GROUP} --name ${AKS_NAME} --kubernetes-version 1.30.3 --vnet-subnet-id ${SUBNET_ID} --assign-identity ${CLUSTER_IDENTITY_RESOURCE_ID} --assign-kubelet-identity ${KUBELET_IDENTITY_RESOURCE_ID} --bootstrap-artifact-source Cache --bootstrap-container-registry-resource-id ${REGISTRY_ID} --outbound-type none --network-plugin azure --enable-apiserver-vnet-integration --apiserver-subnet-id ${APISERVER_SUBNET_ID}
Mettre à jour un cluster AKS existant
Si vous préférez activer l’isolation réseau sur un cluster AKS existant au lieu de créer un cluster, utilisez la commande az aks update.
Lors de la création du point de terminaison privé et de la zone DNS privée pour l’ACR BYO, utilisez le réseau virtuel et les sous-réseaux existants du cluster AKS existant. Lorsque vous affectez l’autorisation AcrPull à l’identité kubelet, utilisez l’identité kubelet existante du cluster AKS existant.
Pour activer la fonctionnalité isolée réseau sur un cluster AKS existant, exécutez d’abord la commande suivante pour mettre à jour bootstrap-artifact-source:
az aks update --resource-group ${RESOURCE_GROUP} --name ${AKS_NAME} --bootstrap-artifact-source Cache --bootstrap-container-registry-resource-id ${REGISTRY_ID}
Ensuite, vous devez réimager manuellement tous les pools de nœuds en cours :
az aks upgrade --resource-group ${RESOURCE_GROUP} --name ${AKS_NAME} --node-image-only
Remarque
Vous devez assurer que le trafic sortant existe jusqu’à la fin de la première réinitialisation. Pour vérifier si la réimage est terminée, exécutez :
NODEPOOLS=$(az aks nodepool list \
--resource-group "${RESOURCE_GROUP}" \
--cluster-name "${AKS_NAME}" \
--query "[].name" -o tsv)
for NODEPOOL in $NODEPOOLS; do
echo "Waiting for node pool $NODEPOOL to finish upgrading..."
az aks nodepool wait \
--resource-group "${RESOURCE_GROUP}" \
--cluster-name "${AKS_NAME}" \
--name "$NODEPOOL" \
--updated
echo "Node pool $NODEPOOL upgrade succeeded."
done
Attendez et vérifiez que la réimage est terminée, puis exécutez la commande suivante pour mettre à jour outbound-type:
az aks update --resource-group ${RESOURCE_GROUP} --name ${AKS_NAME} --outbound-type none
Important
N’oubliez pas de réimager instantanément les pools de nœuds du cluster après avoir mis à jour la source de l’artefact dans le cache. Sinon, la fonctionnalité ne prend pas effet pour le cluster.
Mettre à jour votre ID ACR
Il est possible de mettre à jour l’ACR privé utilisé avec un cluster isolé de réseau. Pour identifier l’ID de ressource ACR, utilisez la commande az aks show.
az aks show --resource-group ${RESOURCE_GROUP} --name ${AKS_NAME}
La mise à jour de l’ID ACR est effectuée en exécutant la commande az aks update avec les paramètres --bootstrap-artifact-source et --bootstrap-container-registry-resource-id.
az aks update --resource-group ${RESOURCE_GROUP} --name ${AKS_NAME} --bootstrap-artifact-source Cache --bootstrap-container-registry-resource-id <New BYO ACR resource ID>
Lorsque vous mettez à jour l’ID ACR sur un cluster existant, vous devez réimager manuellement tous les nœuds existants.
az aks upgrade --resource-group ${RESOURCE_GROUP} --name ${AKS_NAME} --node-image-only
Important
N’oubliez pas de réimager les pools de nœuds du cluster après avoir activé la fonction de cluster isolé du réseau. Sinon, la fonctionnalité ne prend pas effet pour le cluster.
Vérifier que le cluster isolé du réseau est activé
Pour valider que la fonctionnalité de cluster isolé du réseau est activée, utilisez la commande «az aks show
az aks show --resource-group ${RESOURCE_GROUP} --name ${AKS_NAME}
La sortie suivante montre que la fonctionnalité est activée, en fonction des valeurs de la propriété outboundType (aucune ou bloquée) et de la propriété artifactSource (Mise en cache).
"kubernetesVersion": "1.30.3",
"name": "myAKSCluster"
"type": "Microsoft.ContainerService/ManagedClusters"
"properties": {
...
"networkProfile": {
...
"outboundType": "none",
...
},
...
"bootstrapProfile": {
"artifactSource": "Cache",
"containerRegistryId": "/subscriptions/my-subscription-id/my-node-resource-group-name/providers/Microsoft.ContainerRegistry/registries/my-registry-name"
},
...
}
Désactiver un cluster isolé du réseau
Désactivez la fonctionnalité de cluster isolé du réseau en exécutant la commande az aks update avec les paramètres --bootstrap-artifact-source et --outbound-type.
az aks update --resource-group ${RESOURCE_GROUP} --name ${AKS_NAME} --bootstrap-artifact-source Direct --outbound-type LoadBalancer
Lorsque vous désactivez la fonctionnalité sur un cluster existant, vous devez réimager manuellement tous les nœuds existants.
az aks upgrade --resource-group ${RESOURCE_GROUP} --name ${AKS_NAME} --node-image-only
Important
N’oubliez pas de réimager les pools de nœuds du cluster après avoir désactivé la fonction de cluster isolé du réseau. Sinon, la fonctionnalité ne prend pas effet pour le cluster.
Résolution des problèmes
Si vous rencontrez des problèmes, tels que l’extraction d’images échoue, consultez Résoudre les problèmes liés aux clusters Azure Kubernetes Service (AKS) isolés sur le réseau.
Étapes suivantes
Si vous souhaitez définir une configuration de restriction à l’aide du Pare-feu Azure, consultez Contrôler le trafic de sortie à l’aide de Pare-feu Azure dans AKS.
Si vous souhaitez limiter la communication entre les pods et le trafic Est-Ouest au sein du cluster, consultez Sécurisation du trafic entre les pods à l’aide de stratégies réseau dans AKS.