Partager via

Résoudre les défaillances DNS sur un cluster AKS en temps réel

  • Article

Les problèmes dns (Domain Name System) au sein de Kubernetes peuvent perturber les communications entre les pods, les services et les ressources externes, ce qui entraîne des défaillances d’application et une dégradation des performances. Cet article explique comment résoudre les défaillances DNS sur un cluster Azure Kubernetes Service (AKS) en temps réel.

Note

Cet article complète la résolution des problèmes de résolution DNS à partir du guide du pod .

Symptômes

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

Symptôme Description
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 de 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.

Étape 1 : Identifier les réponses DNS infructueuses dans 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 à l’aide de la commande suivante :

$ kubectl gadget trace dns --all-namespaces --output columns=k8s,name,qtype,rcode --filter qr:R --filter qtype:A --filter 'rcode:!No Error'
K8S.NODE         K8S.NAMESPACE    K8S.POD     K8S.CONTAINER    NAME                  QTYPE        RCODE 
aks-agen...      default          test-pod    nginx            myaks-troubleshoot.   A            Non-Existent Domain 
aks-agen...      default          test-pod    nginx            myaks-troubleshoot.   A            Non-Existent Domain

Voici les explications des paramètres de commande :

  • --all-namespaces: affiche les données des pods dans tous les espaces de noms.
  • -output columns=k8s,name,qtype,rcode: affiche uniquement les informations Kubernetes, le nom DNS, le type de requête et le résultat de la requête DNS.
  • --filter qr:R: correspond uniquement aux réponses DNS.
  • --filter qtype:A: correspond uniquement aux adresses hôtes IPv4.
  • --filter 'rcode:!No Error': correspond aux réponses DNS qui ne contiennent No Errorpas . Pour plus d’informations, consultez gopacket les valeurs possibles de rcode ou du RFC approprié.

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.
  • Le nom DNS devient non valide après l’extension. Pour comprendre comment les requêtes DNS peuvent être développées à l’aide des /etc/resolv.confespaces de noms des services d’un pod.

Étape 2 : Identifier les requêtes DNS lentes dans 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 pour 5ms définir des paquets lents. Vous pouvez le modifier en valeur souhaitée, par exemple, 5μs, 20ms, : 1s

$ kubectl gadget trace dns --all-namespaces --output columns=k8s,name,rcode,latency --filter 'latency:>5ms'
K8S.NODE        K8S.NAMESPACE      K8S.POD       K8S.CONTAINER      NAME                            RCODE              LATENCY            
aks-agen...     kube-system        coredn...     coredns            global.prod.micro...            No Error           5.373123ms 
aks-agen...     kube-system        coredn...     coredns            global.prod.micro...            No Error           5.373123ms

Voici les explications des paramètres de commande :

  • --all-namespaces: affiche les données des pods dans tous les espaces de noms.
  • --output columns=k8s,name,rcode,latency: affiche uniquement les informations Kubernetes, le nom DNS, le résultat de la réponse DNS et la latence de réponse.
  • --filter 'latency:>5ms': correspond uniquement aux réponses DNS avec une latence d’au moins 5 ms.

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.
  • Les pods CoreDNS ne sont pas disponibles. Pour vérifier que les pods s’exécutent correctement, suivez les étapes de résolution des problèmes de résolution DNS à partir de l’intérieur du pod.

Étape 3 : Vérifier l'état 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 trace dns -n kube-system -l k8s-app=kube-dns -o columns=k8s,id,qr,name,rcode,nameserver,latency -F nameserver:168.63.129.16
K8S.NODE    K8S.NAMESPACE   K8S.POD                        K8S.CONTAINER   ID        QR    NAME               RCODE           NAMESERVER              LATENCY
aks-agen... kube-system     coredns-6d5bb68c46-ntz2q       coredns         b256      Q     microsoft.com.                     168.63.129.16
aks-agen... kube-system     coredns-6d5bb68c46-ntz2q       coredns         b256      R     microsoft.com.     No Error        168.63.129.16           500.821223ms

Voici les explications des paramètres de commande :

  • -n kube-system: affiche uniquement les données de l’espace kube-system de noms.
  • -l k8s-app=kube-dns: affiche uniquement les données à/partir de pods avec l’étiquette k8s-app=kube-dns (pods CoreDNS).
  • -o columns=k8s,id,name,rcode,nameserver,latency: affiche uniquement les informations Kubernetes, l’ID de requête DNS, la requête/réponse, le nom DNS, le résultat de la réponse DNS, le serveur de noms et la latence de réponse.
  • -F nameserver:168.63.129.16: serveur DNS en amont utilisé pour filtrer les événements.

Vous pouvez utiliser les valeurs et RCODELATENCY les IDvaleurs pour déterminer l’intégrité 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) b256n’a aucune réponse correspondante.
  • Une réponse DNS (QR=R) a une valeur élevée sous la LATENCY colonne (par exemple). 500.821223ms
  • Une réponse DNS (QR=R) a un RCODE autre que No Error, par exemple, « Échec du serveur » et « Requête refusée ». Pour plus d’informations, consultez gopacket les valeurs possibles de rcode.

Étape 4 : Vérifier que les requêtes DNS reçoivent des réponses en temps voulu

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 correspondent aux ID de requête/réponse :

$ kubectl gadget trace dns -l app=test-pod --output columns=k8s,id,qtype,qr,name,rcode,latency --filter name:microsoft.com.
K8S.NODE       K8S.NAMESPACE   K8S.POD     K8S.CONTAINER   ID          QTYPE     QR  NAME              RCODE               LATENCY
aks-agen...    default         test-pod    nginx           97b3        A         Q   microsoft.com.
aks-agen...    default         test-pod    nginx           97b3        A         R   microsoft.com.    No Error            1.954413ms
aks-agen...    default         test-pod    nginx           97b3        A         R   microsoft.com.    No Error
aks-agen...    default         test-pod    nginx           c6c5        AAAA      Q   microsoft.com.
aks-agen...    default         test-pod    nginx           c6c5        AAAA      R   microsoft.com.    No Error            1.885412ms
aks-agen...    default         test-pod    nginx           c6c5        AAAA      R   microsoft.com.    No Error

Voici les explications des paramètres de commande :

  • -l app=test-pod: affiche uniquement les données à/partir des pods avec l’étiquette app=test-pod.
  • --output columns=k8s,id,qtype,qr,name,rcode,latency: 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 de réponse.
  • --filter name:microsoft.com.: correspond uniquement aux paquets DNS portant le nom microsoft.com. DNS Pour vous assurer que la valeur de filtre est un nom de domaine complet (FQDN), ajoutez un point (.) à la fin du nom.

La ID valeur (par exemple) 97b3peut être utilisée pour mettre en corrélation les requêtes avec des réponses. Vous pouvez également utiliser la LATENCY 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 trace dns -l app=test-pod  -o columns=k8s,id,qtype,qr,name,rcode,numAnswers,addresses  -F name:~myheadless 
K8S.NODE         K8S.NAMESPACE      K8S.POD         K8S.CONTAINER   ID    QTYPE   QR  NAME                 RCODE           NUMANSWERS     ADDRESSES
aks-agen...      default            test-pod        nginx           f930  A       R   myheadless.defau...  No Error        2              10.244.2.18,10.244.2.19 
aks-agen...      default            test-pod        nginx           f930  A       R   myheadless.defau...  No Error        2              10.244.2.18,10.244.2.19 
aks-agen...      default            test-pod        nginx           f930  A       Q   myheadless.defau...                  0

Voici les explications des paramètres de commande :

  • -l app=test-pod: affiche uniquement les données à/partir des pods avec l’étiquette app=test-pod.
  • -o columns=k8s,id,qtype,qr,name,rcode,numAnswers,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.
  • -F name:~myheadless: inclut uniquement les paquets DNS qui passent la vérification de l’expression ~myheadless régulière.

Vous pouvez utiliser les valeurs et ADDRESSES les valeurs pour qu’elles NUMANSWERS correspondent aux valeurs que kubectl get ep myheadlessvous obtenez .

$ kubectl get ep myheadless 
NAME                  ENDPOINTS                           AGE 
myheadless            10.244.2.18:8080,10.244.2.19:8080   10d

Exclusion de responsabilité de tiers

Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.

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.