Résolution des problèmes de connexions sortantes de base à partir d’un cluster AKS
Cet article explique comment résoudre les problèmes de base des connexions sortantes à partir d’un cluster Microsoft Azure Kubernetes Service (AKS).
Prerequisites
L’outil Kubernetes kubectl ou un outil similaire pour se connecter au cluster. Pour installer kubectl à l’aide d’Azure CLI, exécutez la commande az aks install-cli .
Outil en ligne de commande apt-get pour la gestion des packages.
Outil d’URL client (cURL) ou d’un outil en ligne de commande similaire.
Outil en ligne de commande hôte pour les recherches DNS.
Outil en ligne de commande Netcat (
nc) pour les connexions TCP.Outil de ligne de commande traceroute pour l’impression de la trace des paquets de routage sur l’hôte réseau.
Scénarios de trafic sortant dans Azure Kubernetes Service
Dans n’importe quel scénario de mise en réseau, vous devez prendre en compte les facteurs suivants lors de la résolution des problèmes :
Source et destination de la requête.
Sauts entre la source et la destination.
Flux de demande-réponse.
Tronçons améliorés par des couches de sécurité supplémentaires, telles que les couches suivantes :
- Pare-feu
- Groupe de sécurité réseau (NSG)
- Stratégie réseau
Lorsque vous vérifiez chaque composant, obtenez et analysez les codes de réponse HTTP. Ces codes sont utiles pour identifier la nature du problème. Les codes sont particulièrement utiles dans les scénarios dans lesquels l’application répond aux requêtes HTTP.
Si d’autres étapes de résolution des problèmes ne fournissent aucun résultat concluant, prenez des captures de paquets à partir du client et du serveur. Les captures de paquets sont également utiles lorsque le trafic non HTTP est impliqué entre le client et le serveur. Pour plus d’informations sur la collecte des captures de paquets pour l’environnement AKS, consultez les articles suivants dans le guide de collecte de données :
Capturer un vidage TCP à partir d’un nœud Linux dans un cluster AKS
Capture d’un vidage TCP à partir d’un nœud Windows dans un cluster AKS
Capturer des paquets TCP à partir d’un pod sur un cluster AKS
Si vous savez comment obtenir les codes de réponse HTTP et prendre des captures de paquets, il est plus facile de résoudre un problème de connectivité réseau.
Le trafic provenant du cluster AKS, qu’il s’agisse d’un pod ou d’un nœud Worker, est considéré comme le trafic sortant du cluster. Que se passe-t-il en cas de problème dans le flux sortant d’un cluster AKS ? Avant de résoudre les problèmes, commencez par comprendre la nature du flux de demande-réponse.
Le trafic sortant d’un cluster AKS peut être classé dans les catégories suivantes :
Trafic vers un pod ou un service dans le même cluster (trafic interne)
Trafic vers un appareil ou un point de terminaison dans le même réseau virtuel ou un autre réseau virtuel (qui utilise le peering de réseaux virtuels)
Trafic vers un environnement local via une connexion VPN ou une connexion Azure ExpressRoute
Trafic en dehors du réseau AKS (trafic sortant public)
Dans ce document, nous abordons les étapes de résolution des problèmes de base qui affectent la connectivité sortante :
- Dans le cluster
- Dans les réseaux virtuels
- Vers le monde extérieur (trafic public)
Lorsque vous résolvez les problèmes de trafic sortant dans AKS, il est également important de savoir quel est votre appareil de sortie (c’est-à-dire l’appareil via lequel le trafic passe). Ici, l’appareil de sortie peut être l’un des composants suivants :
- Équilibrage de charge Azure
- Pare-feu Azure ou un pare-feu personnalisé
- Passerelle NAT (Network Address Translation)
- Un serveur proxy
Le flux peut également différer en fonction de la destination. Par exemple, le trafic interne (autrement dit, au sein du cluster) ne passe pas par l’appareil de sortie. Le trafic interne utilise uniquement la mise en réseau du cluster.
Trafic interne
Un flux de requête de base pour le trafic interne à partir d’un cluster AKS ressemble au flux présenté dans le diagramme suivant.
Trafic externe via Azure Load Balancer
Si le trafic concerne une destination sur Internet, la méthode par défaut consiste à envoyer le trafic via Azure Load Balancer.
Trafic externe via Pare-feu Azure ou un serveur proxy
Dans certains cas, le trafic de sortie doit être filtré et peut nécessiter Pare-feu Azure.
Au lieu d’un pare-feu, un utilisateur peut souhaiter ajouter un serveur proxy. Ou bien, l’utilisateur peut souhaiter configurer une passerelle NAT pour le trafic de sortie. Le flux de base reste le même que celui indiqué dans le diagramme.
Il est important de comprendre la nature du flux de sortie de votre cluster afin de pouvoir continuer à résoudre les problèmes.
Liste de contrôle pour la résolution des problèmes
Pour la résolution des problèmes de base pour le trafic de sortie à partir d’un cluster AKS, procédez comme suit :
Assurez-vous que vous pouvez atteindre le point de terminaison via une adresse IP.
Assurez-vous que vous pouvez atteindre le point de terminaison à partir d’une autre source.
Vérifiez si le cluster peut atteindre n’importe quel autre point de terminaison externe.
Vérifiez si un pare-feu ou un proxy bloque le trafic.
Vérifiez si le principal du service AKS ou l’identité managée dispose des autorisations de service AKS requises pour apporter les modifications réseau aux ressources Azure.
Vérifier si la résolution DNS réussit pour le point de terminaison
À partir du pod, vous pouvez exécuter une recherche DNS sur le point de terminaison.
Que faire si vous ne pouvez pas exécuter la commande kubectl exec pour vous connecter au pod et installer le package DNS Utils ? Dans ce cas, vous pouvez démarrer un pod de test dans le même espace de noms que le pod problématique, puis exécuter les tests.
Remarque
Si la résolution DNS ou le trafic de sortie ne vous permet pas d’installer les packages réseau nécessaires, vous pouvez utiliser l’image Docker rishasi/ubuntu-netutil:1.0. Dans cette image, les packages requis sont déjà installés.
Voici un exemple de procédure pour vérifier la résolution DNS d’un pod Linux :
Démarrez un pod de test dans le même espace de noms que le pod problématique :
kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "linux"}}}'Une fois le pod de test en cours d’exécution, vous avez accès au pod.
Exécutez les commandes
apt-getsuivantes pour installer d’autres packages d’outils :apt-get update -y apt-get install -y dnsutils && apt-get install netcat-traditional -y && apt-get install curl -yUne fois les packages installés, exécutez la commande nslookup pour tester la résolution DNS sur le point de terminaison :
$ nslookup microsoft.com Server: 10.0.0.10 Address: 10.0.0.10#53 ... ... Name: microsoft.com Address: 20.53.203.50Essayez directement la résolution DNS à partir du serveur DNS en amont. Cet exemple utilise Azure DNS :
$ nslookup microsoft.com 168.63.129.16 Server: 168.63.129.16 Address: 168.63.129.16#53 ... ... Address: 20.81.111.85Exécutez la commande
hostpour vérifier si les requêtes DNS sont acheminées vers le serveur en amont :$ host -a microsoft.com Trying "microsoft.com.default.svc.cluster.local" Trying "microsoft.com.svc.cluster.local" Trying "microsoft.com.cluster.local" Trying "microsoft.com.00idcnmrrm4edot5s2or1onxsc.bx.internal.cloudapp.net" Trying "microsoft.com" Trying "microsoft.com" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62884 ;; flags: qr rd ra; QUERY: 1, ANSWER: 27, AUTHORITY: 0, ADDITIONAL: 5 ;; QUESTION SECTION: ;microsoft.com. IN ANY ;; ANSWER SECTION: microsoft.com. 30 IN NS ns1-39.azure-dns.com. ... ... ns4-39.azure-dns.info. 30 IN A 13.107.206.39 Received 2121 bytes from 10.0.0.10#53 in 232 ms
Voici un exemple de procédure permettant de vérifier la résolution DNS d’un pod Windows :
Exécutez un pod de test dans le pool de nœuds Windows :
# For a Windows environment, use the Resolve-DnsName cmdlet. kubectl run dnsutil-win --image='mcr.microsoft.com/windows/servercore:ltsc2022' --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "windows"}}}' -- powershell "Start-Sleep -s 3600"Exécutez la commande kubectl exec pour vous connecter au pod en utilisant PowerShell :
kubectl exec -it dnsutil-win -- powershellExécutez l’applet de commande Resolve-DnsName dans PowerShell pour vérifier si la résolution DNS fonctionne pour le point de terminaison :
PS C:\> Resolve-DnsName www.microsoft.com Name Type TTL Section NameHost ---- ---- --- ------- -------- www.microsoft.com CNAME 20 Answer www.microsoft.com-c-3.edgekey.net www.microsoft.com-c-3.edgekey. CNAME 20 Answer www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net net www.microsoft.com-c-3.edgekey. CNAME 20 Answer e13678.dscb.akamaiedge.net net.globalredir.akadns.net Name : e13678.dscb.akamaiedge.net QueryType : AAAA TTL : 20 Section : Answer IP6Address : 2600:1408:c400:484::356e Name : e13678.dscb.akamaiedge.net QueryType : AAAA TTL : 20 Section : Answer IP6Address : 2600:1408:c400:496::356e Name : e13678.dscb.akamaiedge.net QueryType : A TTL : 12 Section : Answer IP4Address : 23.200.197.152
Vous devez également vérifier si le point de terminaison est accessible à partir du nœud. Ensuite, vérifiez les paramètres DNS dans le nœud. Effectuez les étapes suivantes :
Testez la résolution DNS sur le point de terminaison :
$ nslookup microsoft.com Server: 168.63.129.16 Address: 168.63.129.16#53 Non-authoritative answer: Name: microsoft.com Address: 20.112.52.29 Name: microsoft.com Address: 20.81.111.85 Name: microsoft.com Address: 20.84.181.62 Name: microsoft.com Address: 20.103.85.33 Name: microsoft.com Address: 20.53.203.50Vérifiez le fichier resolv.conf pour déterminer si les serveurs de noms attendus sont ajoutés :
cat /etc/resolv.conf cat /run/systemd/resolve/resolv.conf
Dans un scénario inhabituel impliquant la résolution DNS, les requêtes DNS obtiennent une réponse correcte du nœud, mais échouent à partir du pod. Pour ce scénario, vous pouvez envisager de vérifier les échecs de résolution DNS à l’intérieur du pod, mais pas à partir du nœud Worker. Si vous souhaitez inspecter la résolution DNS d’un point de terminaison sur le cluster, vous pouvez envisager de vérifier l’état de résolution DNS sur le cluster.
Si la résolution DNS réussit, passez aux tests réseau. Sinon, vérifiez la configuration DNS du cluster.
Vérifier si le cluster peut atteindre le point de terminaison via le réseau
Pour déterminer si vous pouvez atteindre le point de terminaison via le réseau à partir de votre cluster, procédez comme suit :
Vérifiez l’itinéraire vers le point de terminaison pour déterminer s’il existe un délai d’attente à une opération spécifique :
kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "linux"}}}' apt-get update -y apt-get install -y traceroute && apt-get install netcat-traditional -y && apt-get install curl -y traceroute -T microsoft.com -m 50 -p 443Vérifiez si le port souhaité est ouvert sur l’hôte distant :
nc -z -v microsoft.com 443Vérifiez le code de réponse HTTP :
curl -Iv https://microsoft.comVérifiez si vous pouvez vous connecter à n’importe quel autre point de terminaison :
curl -Iv https://kubernetes.io
Exclusion de responsabilité sur les coordonnées externes
Microsoft fournit des informations de contacts externes afin de vous aider à obtenir un support technique sur ce sujet. Ces informations de contact peuvent changer sans préavis. Microsoft ne garantit pas l’exactitude des informations concernant les sociétés externes.
Contactez-nous pour obtenir de l’aide
Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.