Partager via

Analyse du trafic DNS en temps réel pour résoudre les échecs de résolution DNS dans AKS

Cet article explique comment résoudre les défaillances dns (Domain Name System) sur un cluster Azure Kubernetes Service (AKS) en temps réel.

Remarque

Cet article est complémentaire à la résolution des problèmes de résolution DNS de base dans le guide AKS .

Symptômes

Le tableau suivant présente les symptômes courants que vous pouvez observer dans un cluster AKS :

Symptôme Descriptif
Taux d’erreur élevé Les requêtes DNS échouent ou retournent des résultats inattendus, ce qui peut affecter les performances et la fiabilité des applications qui en dépendent.
Services non répondants Les requêtes DNS prennent plus de temps que d’habitude à résoudre, ce qui peut entraîner des retards ou des délais d’attente dans les applications qui s’appuient sur eux.
La découverte du service est affectée Les applications ne peuvent pas localiser d’autres applications dans le cluster en raison de problèmes DNS, ce qui peut entraîner des interruptions de service ou des échecs.
La communication externe est affectée Les applications ont des difficultés à accéder aux ressources externes ou aux points de terminaison en dehors du cluster en raison de problèmes DNS, ce qui peut entraîner des erreurs ou des performances dégradées.

Conditions préalables

Pour résoudre les défaillances DNS sur un cluster AKS, suivez les instructions des sections suivantes. Avant de commencer, exportez la version du gadget vers une variable. Cette variable est utilisée dans toutes les commandes de cet article.

GADGET_VERSION=$(kubectl gadget version | grep Server | awk '{print $3}')

N’hésitez pas à choisir une autre version. Par exemple, vous pouvez utiliser latest ou main obtenir la dernière version stable ou de développement du gadget respectivement.

Étape 1 : Identifier les réponses DNS infructueuses sur le cluster

Vous pouvez utiliser le gadget DNS pour identifier toutes les réponses DNS infructueuses sur le cluster. Pour effectuer cette vérification, tracez les paquets DNS sur tous les nœuds et filtrez les réponses infructueuses.

kubectl gadget run trace_dns:$GADGET_VERSION \
  --all-namespaces \
  --fields k8s.node,src,dst,name,qtype,rcode \
  --filter "qr==R,rcode!=Success"

Voici les explications des paramètres de commande :

  • --all-namespaces: affiche les données des pods dans tous les espaces de noms.
  • --fields k8s.node,src,dst,name,qtype,rcode: affiche uniquement les informations Kubernetes, la source et la destination des paquets DNS, du nom DNS, du type de requête DNS et du code de réponse DNS.
  • --filter "qr==R,rcode!=Success": correspond uniquement aux réponses DNS (qr==R) avec un code de réponse autre que Success.

Le résultat doit être semblable à ce qui suit :

K8S.NODE                      SRC                                    DST                                    NAME                         QTYPE           RCODE   
aks-agentpool-…919-vmss000000 p/kube-system/coredns-57d886c994-r2ts… p/default/mypod:38480                  myaks-troubleshoot.          A               NameError
aks-agentpool-…919-vmss000000 s/kube-system/kube-dns:53              p/default/mypod:38480                  myaks-troubleshoot.          A               NameError

Où RCODE est le code de réponse DNS et vous aide à identifier le type de défaillance DNS.

Voici quelques causes de réponses DNS infructueuses :

  • Le nom DNS résolu a une faute de frappe.

  • Les serveurs de noms DNS en amont rencontrent des problèmes.

  • Une configuration réseau mal configurée (par exemple, NetworkPolicy (NetPol), un pare-feu ou des règles de groupe de sécurité réseau bloque le trafic DNS.

  • Le nom DNS devient non valide après l’extension.

    Pour comprendre comment les requêtes DNS peuvent être développées à l’aide du /etc/resolv.conf fichier d’un pod, consultez Espaces de noms des services.

Étape 2 : Identifier les requêtes DNS lentes sur le cluster

Vous pouvez utiliser le gadget DNS pour identifier toutes les requêtes DNS lentes sur le cluster. Pour effectuer cette vérification, tracez les paquets DNS sur tous les nœuds et filtrez les réponses lentes.

Dans l'exemple suivant, vous utilisez une valeur de latence de 5ms pour définir des paquets lents. Vous pouvez le modifier en valeur souhaitée, par exemple, 5μs, 20ms, : 1s

kubectl gadget run trace_dns:$GADGET_VERSION \
  --all-namespaces \
  --fields k8s.node,src,dst,name,qtype,rcode,latency_ns \
  --filter "latency_ns_raw>5000000"

Voici les explications des paramètres de commande :

  • --all-namespaces: affiche les données des pods dans tous les espaces de noms.
  • --fields k8s.node,src,dst,name,qtype,rcode,latency_ns: affiche uniquement les informations Kubernetes, la source et la destination des paquets DNS, le nom DNS, le type de requête DNS, le code de réponse DNS et la latence en nanosecondes.
  • --filter "latency_ns_raw>5000000": correspond uniquement aux réponses DNS avec une latence supérieure 5ms à (5000000 nanosecondes).

Le résultat doit être semblable à ce qui suit :

K8S.NODE                   SRC                                DST                               NAME                      QTYPE         RCODE          LATENCY_NS
aks-agentpool…9-vmss000001 168.63.129.16:53                   p/kube-system/coredns-57d886c994… microsoft.com.            A             Success           14.02ms
aks-agentpool…9-vmss000000 s/kube-system/kube-dns:53          p/default/mypod:39168             microsoft.com.            A             Success           15.40ms
aks-agentpool…9-vmss000000 168.63.129.16:53                   p/kube-system/coredns-57d886c994… microsoft.com.            AAAA          Success            5.90ms
aks-agentpool…9-vmss000000 s/kube-system/kube-dns:53          p/default/mypod:38953             microsoft.com.            AAAA          Success            6.41ms

Voici quelques causes de requêtes DNS lentes :

  • Les serveurs de noms DNS en amont rencontrent des problèmes.
  • Problèmes de mise en réseau dans le cluster.

Étape 3 : Vérifier l’intégrité des serveurs DNS en amont

Vous pouvez utiliser le gadget DNS pour vérifier l’intégrité des serveurs DNS en amont utilisés par CoreDNS. Si les applications tentent d’atteindre des domaines externes, les requêtes sont transférées aux serveurs DNS en amont via CoreDNS. Pour comprendre l’intégrité de ces requêtes, tracez les paquets DNS quittant les pods CoreDNS et filtrez par le serveur de noms.

Dans l’exemple suivant, le serveur AZURE DNS par défaut (adresse IP 168.63.129.16) est utilisé comme serveur de noms en amont. Si vous utilisez un serveur DNS personnalisé, vous pouvez utiliser l’adresse IP du serveur DNS personnalisé comme serveur de noms en amont. Vous pouvez obtenir l’adresse IP en recherchant /etc/resolv.conf sur le nœud.

kubectl gadget run trace_dns:$GADGET_VERSION \
  --all-namespaces \
  --fields src,dst,id,qr,name,nameserver,rcode,latency_ns \
  --filter "nameserver.addr==168.63.129.16"

Voici les explications des paramètres de commande :

  • --all-namespaces: affiche les données des pods dans tous les espaces de noms.
  • --fields src,dst,id,qr,name,nameserver,rcode,latency_ns: affiche uniquement la source et la destination des paquets DNS, l’ID de requête DNS, la requête/réponse, le nom DNS, le serveur de noms, le résultat de la réponse DNS et la latence en nanosecondes.
  • --filter "nameserver.addr==168.63.129.16" : Correspond uniquement aux paquets DNS avec l'adresse IP du serveur de noms 168.63.129.16.

Le résultat doit être semblable à ce qui suit :

SRC                                        DST                                        ID                QR NAME                           NAMESERVER       RCODE              LATENCY_NS
p/kube-system/coredns-57d886c994-vsj7g:60… r/168.63.129.16:53                         4828              Q  qasim-cluster-dns-sqia0j5i.hc… 168.63.129.16                              0ns
p/kube-system/coredns-57d886c994-pcv59:51… r/168.63.129.16:53                         5015              Q  qasim-cluster-dns-sqia0j5i.hc… 168.63.129.16                              0ns
r/168.63.129.16:53                         p/kube-system/coredns-57d886c994-pcv59:51… 5015              R  qasim-cluster-dns-sqia0j5i.hc… 168.63.129.16    Success                5.06ms
r/168.63.129.16:53                         p/kube-system/coredns-57d886c994-vsj7g:60… 4828              R  qasim-cluster-dns-sqia0j5i.hc… 168.63.129.16    Success               23.01ms

Vous pouvez utiliser les valeurs RCODE et LATENCY pour déterminer l'état de santé du serveur DNS en amont. Par exemple, s’il existe un serveur en amont défectueux, vous voyez la sortie suivante :

  • Une requête DNS (QR=Q) avec un ID (par exemple) 4828n’a aucune réponse correspondante.
  • Une réponse DNS (QR=R) a une valeur élevée sous la LATENCY_NS colonne (par exemple). 23.01ms
  • Une réponse DNS (QR=R) a une RCODE autre que Success, par exemple, « ServerFailure » et « Refusé ».

Étape 4 : Vérifier que les requêtes DNS obtiennent des réponses en temps opportun

Vous pouvez utiliser le gadget DNS pour vérifier qu’une requête DNS particulière obtient une réponse en temps voulu. Pour effectuer cette vérification, filtrez les événements avec un nom DNS et faites correspondre les ID de requête/réponse :

kubectl gadget run trace_dns:$GADGET_VERSION \
    -l app=test-pod \
    --fields k8s.node,k8s.namespace,k8s.podname,id,qtype,qr,name,rcode,latency_ns \
    --filter name==microsoft.com.

Voici les explications des paramètres de commande :

  • -l app=test-pod: affiche uniquement les données vers et depuis les pods avec l’étiquette app=test-pod dans l’espace de noms par défaut.
  • --fields k8s.node,k8s.namespace,k8s.podname,id,qtype,qr,name,rcode,latency_ns: affiche uniquement les informations Kubernetes, l’ID de requête DNS, le type de requête, la requête/réponse, le nom DNS, le résultat de la réponse DNS et la latence en nanosecondes.
  • --filter name==microsoft.com.: correspond uniquement aux paquets DNS portant le nom microsoft.com. DNS Vérifiez que la valeur de filtre est un nom de domaine complet (FQDN) en ajoutant un point (.) à la fin du nom.

Le résultat doit être semblable à ce qui suit :

K8S.NODE                  K8S.NAMESPACE             K8S.PODNAME               ID             QTYPE          QR NAME                     RCODE          LATENCY_NS
aks-agentpoo…9-vmss000000 default                   mypod                     102d           A              Q  microsoft.com.                                 0ns
aks-agentpoo…9-vmss000000 default                   mypod                     102d           A              R  microsoft.com.           Success           11.87ms
aks-agentpoo…9-vmss000000 default                   mypod                     d482           AAAA           Q  microsoft.com.                                 0ns
aks-agentpoo…9-vmss000000 default                   mypod                     d482           AAAA           R  microsoft.com.           Success            9.27ms

La ID valeur (par exemple) 102dpeut être utilisée pour mettre en corrélation les requêtes avec des réponses. Vous pouvez également utiliser la LATENCY_NS valeur pour valider que vous obtenez les réponses en temps voulu.

Étape 5 : Vérifier que les réponses DNS contiennent les adresses IP attendues

Vous pouvez utiliser le gadget DNS pour vérifier qu’une requête DNS particulière obtient la réponse attendue. Par exemple, pour un service sans tête (nommé myheadless), vous vous attendez à ce que la réponse contienne les adresses IP de tous les pods.

kubectl gadget run trace_dns:$GADGET_VERSION \
  --fields k8s.podname,id,qtype,qr,name,rcode,num_answers,addresses  \
  --filter name~myheadless

Voici les explications des paramètres de commande :

  • --fields k8s.podname,id,qtype,qr,name,rcode,num_answers,addresses: affiche uniquement les informations Kubernetes, l’ID de requête DNS, le type de requête, la requête/réponse, le nom DNS, le résultat de la réponse DNS, le nombre de réponses et les adresses IP dans la réponse.
  • --filter name~myheadless: correspond uniquement aux paquets DNS portant le nom DNS qui contient myheadless. L’opérateur ~ est utilisé pour faire correspondre un regex.

Le résultat doit être semblable à ce qui suit :

K8S.PODNAME                           ID                   QTYPE                QR NAME                                 RCODE     NUM_ANSWERS ADDRESSES          
mypod                                 f8b0                 A                    Q  myheadless.default.svc.cluster.loca…           0                              
mypod                                 f8b0                 A                    R  myheadless.default.svc.cluster.loca… Success   2           10.244.0.146,10.24…
mypod                                 abcd                 AAAA                 Q  myheadless.default.svc.cluster.loca…           0                              
mypod                                 abcd                 AAAA                 R  myheadless.default.svc.cluster.loca… Success   0

Vous pouvez utiliser les valeurs NUM_ANSWERS et ADDRESSES pour qu’elles correspondent aux valeurs que vous obtenez de kubectl get ep myheadless.

kubectl get ep myheadless 
NAME                  ENDPOINTS                           AGE 
myheadless            10.244.0.146:80,10.244.1.207:80   10d

Exclusion de responsabilité des informations tierces

Les produits tiers abordés par cet article sont fabriqués par des entreprises indépendantes de Microsoft. Microsoft ne donne aucune garantie, implicite ou autre, concernant la performance ou la fiabilité de ces produits.

Contactez-nous pour obtenir de l’aide

Si vous avez des questions ou avez besoin d’aide, créez une demande de support ou demandez le support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.