Résolution des problèmes de connexions sortantes de base à partir d’un cluster AKS

Article
12/18/2024

Cet article explique comment résoudre les problèmes de base des connexions sortantes à partir d’un cluster Microsoft Azure Kubernetes Service (AKS) et identifier les composants défectueux.

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 nslookup de ligne de commande (dnsutils) pour la vérification de la résolution DNS.

Scénarios de trafic sortant dans Azure Kubernetes Service

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, examinez d’abord les scénarios de flux de trafic sortant.

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 via Azure Load Balancer (trafic sortant public).
Trafic en dehors du réseau AKS via Pare-feu Azure ou un serveur proxy (trafic sortant public).

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 sortant public 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 sortant public 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.

Un utilisateur peut souhaiter ajouter un serveur proxy au lieu d’un pare-feu ou 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.

Considérations relatives à la résolution des problèmes

Vérifier votre appareil de sortie

Lorsque vous résolvez les problèmes de trafic sortant dans AKS, il est 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. Pour le trafic sortant public, déterminez s’il existe un appareil de sortie qui transite et vérifiez cet appareil.

Vérifier chaque tronçon dans le flux de trafic

Après avoir identifié l’appareil de sortie, vérifiez les facteurs suivants :

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

Pour identifier un tronçon problématique, vérifiez les codes de réponse avant et après. Pour vérifier si les paquets arrivent correctement dans un tronçon spécifique, vous pouvez continuer avec les captures de paquets.

Vérifier les codes de réponse HTTP

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.

Prendre des captures de paquets à partir du client et du serveur

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 :

Listes de contrôle de 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 :

Vérifiez que la résolution DNS (Domain Name System) pour le point de terminaison fonctionne correctement.
Assurez-vous que vous pouvez atteindre le point de terminaison par le biais d'une adresse IP.
Assurez-vous que vous pouvez atteindre le point de terminaison à partir d’une autre source.
Assurez-vous que le point de terminaison fonctionne.
Vérifiez si le cluster peut atteindre un autre point de terminaison externe.
Vérifiez si une stratégie de réseau bloque le trafic.
Vérifiez si un NSG bloque le trafic.
Vérifiez si un pare-feu ou un proxy bloque le trafic.
Vérifiez si le principal de service AKS ou l'identité gérée dispose des permissions de service AKS requises pour effectuer les modifications réseau sur les ressources Azure.

Note

Suppose qu’aucune maille de service n’est prise en compte lorsque vous effectuez des dépannages de base. Si vous utilisez un maillage de service tel qu’Istio, il produit des résultats inhabituels pour le trafic TCP.

Vérifier si le pod et le nœud peuvent atteindre 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.

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-get suivantes pour installer d’autres packages d’outils :

# Update and install tool packages
apt-get update && apt-get install -y dnsutils curl

Une fois les packages installés, exécutez la commande nslookup pour tester la résolution DNS sur le point de terminaison :

$ nslookup microsoft.com # Microsoft.com is used as an example
Server:         <server>
Address:        <server IP address>#53
...
...
Name:   microsoft.com
Address: 20.53.203.50

Essayez 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.85

Parfois, il existe un problème avec le point de terminaison lui-même plutôt qu’un DNS de cluster. Dans ce cas, tenez compte des vérifications suivantes :

Vérifiez si le port souhaité est ouvert sur l’hôte distant :
```
curl -Ivm5 telnet://microsoft.com:443
```
Vérifiez le code de réponse HTTP :
```
curl -Ivm5 https://microsoft.com
```
Vérifiez si vous pouvez vous connecter à n’importe quel autre point de terminaison :
```
curl -Ivm5 https://kubernetes.io
```

Pour vérifier que le point de terminaison est accessible à partir du nœud dans lequel se trouve le pod problématique, puis vérifiez les paramètres DNS, procédez comme suit :

Entrez le nœud dans lequel se trouve le pod problématique via le pod de débogage. Pour plus d’informations sur la procédure à suivre, consultez Se connecter aux nœuds de cluster Azure Kubernetes Service (AKS) pour la maintenance ou la résolution des problèmes.

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.50

Vé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
```

Exemple de procédure pour 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 -- powershell
```

Exé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

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.

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.

Partager via