Résoudre les problèmes de résolution DNS dans AKS

Cet article explique comment créer un flux de travail de résolution des problèmes pour résoudre les problèmes de résolution dns (Domain Name System) dans Microsoft Azure Kubernetes Service (AKS).

Conditions préalables

• Outil en ligne de commande Kubernetes kubectl

  Remarque : Pour installer kubectl à l’aide d’Azure CLI, exécutez la commande az aks install-cli .

• Outil en ligne de commande dig pour la recherche DNS

• Outil en ligne de commande grep pour la recherche de texte

• Analyseur de paquets réseau Wireshark

Liste de contrôle pour la résolution des problèmes

La résolution des problèmes DNS dans AKS est généralement un processus complexe. Vous pouvez facilement être perdu dans les nombreuses étapes différentes sans jamais voir un chemin clair vers l’avant. Pour faciliter et améliorer l’efficacité du processus, utilisez la méthode « scientifique » pour organiser le travail :

• Étape 1. Collectez les faits.

• Étape 2. Développez une hypothèse.

• Étape 3. Créez et implémentez un plan d’action.

• Étape 4. Observez les résultats et tirez des conclusions.

• Étape 5. Répétez si nécessaire.

Étape 1 de résolution des problèmes : collecter les faits

Pour mieux comprendre le contexte du problème, rassemblez des faits sur le problème DNS spécifique. En utilisant les questions de base suivantes comme point de départ, vous pouvez décrire la nature du problème, reconnaître les symptômes et identifier l’étendue du problème.

Question	Réponses possibles
Où la résolution DNS échoue-t-elle ?	Pod Nœud Pods et nœuds
Quel type d’erreur DNS obtenez-vous ?	Délai d’attente Aucun hôte de ce type Autre erreur DNS
À quelle fréquence les erreurs DNS se produisent-elles ?	Toujours Par intermittence Dans un modèle spécifique
Quels enregistrements sont affectés ?	Un domaine spécifique Tout domaine
Existe-t-il des configurations DNS personnalisées ?	Serveur DNS personnalisé configuré sur le réseau virtuel Configuration de DNS personnalisé sur CoreDNS
Quel type de problèmes de performances affectent les nœuds ?	CPU (Unité centrale de traitement) Mémoire Limitation des E/S
Quel type de problèmes de performances affectent les pods CoreDNS ?	CPU (Unité centrale de traitement) Mémoire Limitation des E/S
Qu’est-ce qui provoque la latence DNS ?	Requêtes DNS qui prennent trop de temps pour recevoir une réponse (plus les cinq secondes)

Pour obtenir de meilleures réponses à ces questions, suivez ce processus en trois parties.

Partie 1 : Générer des tests à différents niveaux qui reproduisent le problème

Le processus de résolution DNS pour les pods sur AKS comprend de nombreuses couches. Passez en revue ces couches pour isoler le problème. Les couches suivantes sont typiques :

• Pods de CoreDNS
• Service CoreDNS
• Nœuds
• DNS de réseau virtuel

Pour démarrer le processus, exécutez des tests à partir d’un pod de test sur chaque couche.

Tester la résolution DNS au niveau du pod CoreDNS

1. Déployez un pod de test pour exécuter des requêtes de test DNS en exécutant la commande suivante :

   cat <<EOF | kubectl apply --filename -
   apiVersion: v1
   kind: Pod
   metadata:
     name: aks-test
   spec:
     containers:
     - name: aks-test
       image: debian:stable
       command: ["/bin/sh"]
       args: ["-c", "apt-get update && apt-get install -y dnsutils && while true; do sleep 1000; done"]
   EOF
   

2. Récupérez les adresses IP des pods CoreDNS en exécutant la commande kubectl get suivante :

   kubectl get pod --namespace kube-system --selector k8s-app=kube-dns --output wide
   

3. Connectez-vous au pod de test à l’aide de la kubectl exec -it aks-test -- bash commande et testez la résolution DNS sur chaque adresse IP de pod CoreDNS en exécutant les commandes suivantes :

   # Placeholder values
   FQDN="<fully-qualified-domain-name>"  # For example, "db.contoso.com"
   DNS_SERVER="<coredns-pod-ip-address>"
   
   # Test loop
   for i in $(seq 1 1 10)
   do
       echo "host= $(dig +short ${FQDN} @${DNS_SERVER})"
       sleep 1
   done
   

Pour plus d’informations sur la résolution des problèmes de résolution DNS à partir du niveau du pod, consultez Résoudre les problèmes de résolution DNS à partir de l’intérieur du pod.

Tester la résolution DNS au niveau du service CoreDNS

1. Récupérez l’adresse IP du service CoreDNS en exécutant la commande suivante kubectl get :

   kubectl get service kube-dns --namespace kube-system
   

2. Sur le pod de test, exécutez les commandes suivantes sur l’adresse IP du service CoreDNS :

   # Placeholder values
   FQDN="<fully-qualified-domain-name>"  # For example, "db.contoso.com"
   DNS_SERVER="<kubedns-service-ip-address>"
   
   # Test loop
   for i in $(seq 1 1 10)
   do
       echo "host= $(dig +short ${FQDN} @${DNS_SERVER})"
       sleep 1
   done
   

Tester la résolution DNS au niveau du nœud

1. Connectez-vous au nœud.

2. Exécutez la commande suivante grep pour récupérer la liste des serveurs DNS en amont configurés :

   grep ^nameserver /etc/resolv.conf
   

3. Exécutez les commandes de texte suivantes sur chaque DNS configuré dans le nœud :

   # Placeholder values
   FQDN="<fully-qualified-domain-name>"  # For example, "db.contoso.com"
   DNS_SERVER="<dns-server-in-node-configuration>"
   
   # Test loop
   for i in $(seq 1 1 10)
   do
       echo "host= $(dig +short ${FQDN} @${DNS_SERVER})"
       sleep 1
   done
   

Tester la résolution DNS au niveau DNS du réseau virtuel

Examinez la configuration du serveur DNS du réseau virtuel et déterminez si les serveurs peuvent résoudre l’enregistrement en question.

Partie 2 : Passer en revue l’intégrité et les performances des pods et nœuds CoreDNS

Passer en revue l’intégrité et les performances des pods CoreDNS

Vous pouvez utiliser kubectl commandes pour vérifier l’intégrité et les performances des pods CoreDNS. Pour ce faire, procédez comme suit :

1. Vérifiez que les pods CoreDNS sont en cours d’opération.

   kubectl get pods -l k8s-app=kube-dns -n kube-system
   

2. Vérifiez si les pods CoreDNS sont surutilisées :

   kubectl top pods -n kube-system -l k8s-app=kube-dns
   

   NAME                      CPU(cores)   MEMORY(bytes)
   coredns-dc97c5f55-424f7   3m           23Mi
   coredns-dc97c5f55-wbh4q   3m           25Mi
   

3. Obtenez les nœuds qui hébergent les pods CoreDNS :

   kubectl get pods -n kube-system -l k8s-app=kube-dns -o jsonpath='{.items[*].spec.nodeName}'
   

4. Vérifiez que les nœuds ne sont pas surutilés :

   kubectl top nodes
   

5. Vérifiez les journaux des pods CoreDNS :

   kubectl logs -l k8s-app=kube-dns -n kube-system
   

Remarque

Pour obtenir plus d’informations sur le débogage, activez les logs détaillés dans CoreDNS. Pour ce faire, consultez Résolution des problèmes de personnalisation CoreDNS dans AKS.

Examiner l’intégrité et les performances des nœuds

Vous pourriez d'abord remarquer des problèmes de performance de résolution DNS sous forme d'erreurs intermittentes, comme des temps d'attente. Les principales causes de ce problème incluent l’épuisement des ressources et la limitation des E/S au sein des nœuds qui hébergent les pods CoreDNS ou le pod client.

Pour vérifier si l'épuisement des ressources ou la limitation des E/S se produit, exécutez la commande kubectl describe avec la commande grep sur vos nœuds. Cette série de commandes vous permet de passer en revue le nombre de demandes et de les comparer à la limite de chaque ressource. Si le pourcentage de limite est supérieur à 100 % pour une ressource, cette ressource est surcommise.

kubectl describe node | grep -A5 '^Name:\|^Allocated resources:' | grep -v '.kubernetes.io\|^Roles:\|Labels:'

L’extrait de code suivant montre l’exemple de sortie de cette commande :

Name:               aks-nodepool1-17046773-vmss00000m
--
Allocated resources:
  (Total limits might be more than 100 percent.)
  Resource           Requests           Limits
  --------           --------           ------
  cpu                250m (13 percent)  40m (2 percent)
  memory             420Mi (9 percent)  1762Mi (41 percent)
--
Name:               aks-nodepool1-17046773-vmss00000n
--
Allocated resources:
  (Total limits might be more than 100 percent.)
  Resource           Requests            Limits
  --------           --------            ------
  cpu                612m (32 percent)   8532m (449 percent)
  memory             804Mi (18 percent)  6044Mi (140 percent)
--
Name:               aks-nodepool1-17046773-vmss00000o
--
Allocated resources:
  (Total limits might be more than 100 percent.)
  Resource           Requests           Limits
  --------           --------           ------
  cpu                250m (13 percent)  40m (2 percent)
  memory             420Mi (9 percent)  1762Mi (41 percent)
--
Name:               aks-ubuntu-16984727-vmss000008
--
Allocated resources:
  (Total limits might be more than 100 percent.)
  Resource           Requests            Limits
  --------           --------            ------
  cpu                250m (13 percent)   40m (2 percent)
  memory             420Mi (19 percent)  1762Mi (82 percent)

Pour obtenir une meilleure image de l’utilisation des ressources au niveau du pod et du nœud, vous pouvez également utiliser Container Insights et d’autres outils natifs cloud dans Azure. Pour plus d’informations, consultez Surveiller les clusters Kubernetes à l’aide des services Azure et des outils natifs cloud.

Partie 3 : Analyser le trafic DNS et examiner les performances de résolution DNS

L’analyse du trafic DNS peut vous aider à comprendre comment votre cluster AKS gère les requêtes DNS. Dans l’idéal, vous devez reproduire le problème sur un pod de test pendant que vous capturez le trafic à partir de ce pod de test et sur chacun des pods CoreDNS.

Il existe deux façons principales d’analyser le trafic DNS :

• À l’aide d’outils d’analyse DNS en temps réel, comme Inspektor Gadget, pour analyser le trafic DNS en temps réel.
• À l’aide d’outils de capture de trafic, tels que Retina Capture et Dumpy, pour collecter le trafic DNS et l’analyser avec un outil d'analyse de paquets réseau, tel que Wireshark.

Ces deux approches visent à comprendre l’intégrité et les performances des réponses DNS à l’aide de codes de réponse DNS, de temps de réponse et d’autres métriques. Choisissez celui qui correspond le mieux à vos besoins.

Analyse du trafic DNS en temps réel

Vous pouvez utiliser Inspektor Gadget pour analyser le trafic DNS en temps réel. Pour installer Inspektor Gadget sur votre cluster, consultez Comment installer Inspektor Gadget dans un cluster AKS.

Pour suivre le trafic DNS sur tous les espaces de noms, utilisez la commande suivante :

# Get the version of Gadget
GADGET_VERSION=$(kubectl gadget version | grep Server | awk '{print $3}')
# Run the trace_dns gadget
kubectl gadget run trace_dns:$GADGET_VERSION --all-namespaces --fields "src,dst,name,qr,qtype,id,rcode,latency_ns"

Où --fields est une liste séparée par des virgules de champs à afficher. La liste suivante décrit les champs utilisés dans la commande :

• src: source de la requête avec des informations Kubernetes (<kind>/<namespace>/<name>:<port>).
• dst: destination de la requête avec des informations Kubernetes (<kind>/<namespace>/<name>:<port>).
• name: nom de la requête DNS.
• qr: indicateur de requête/réponse.
• qtype: type de la requête DNS.
• id: ID de la requête DNS, qui est utilisé pour correspondre à la demande et à la réponse.
• rcode: code de réponse de la requête DNS.
• latency_ns: latence de la requête DNS.

La sortie de commande ressemble à ce qui suit :

SRC                                  DST                                  NAME                        QR QTYPE          ID             RCODE           LATENCY_NS
p/default/aks-test:33141             p/kube-system/coredns-57d886c994-r2… db.contoso.com.             Q  A              c215                                  0ns
p/kube-system/coredns-57d886c994-r2… 168.63.129.16:53                     db.contoso.com.             Q  A              323c                                  0ns
168.63.129.16:53                     p/kube-system/coredns-57d886c994-r2… db.contoso.com.             R  A              323c           NameErr…           13.64ms
p/kube-system/coredns-57d886c994-r2… p/default/aks-test:33141             db.contoso.com.             R  A              c215           NameErr…               0ns
p/default/aks-test:56921             p/kube-system/coredns-57d886c994-r2… db.contoso.com.             Q  A              6574                                  0ns
p/kube-system/coredns-57d886c994-r2… p/default/aks-test:56921             db.contoso.com.             R  A              6574           NameErr…               0ns

Vous pouvez utiliser le ID champ pour déterminer si une requête a une réponse. Le RCODE champ affiche le code de réponse de la requête DNS. Le LATENCY_NS champ affiche la latence de la requête DNS en nanosecondes. Ces champs peuvent vous aider à comprendre l’intégrité et les performances des réponses DNS. Pour plus d’informations sur l’analyse DNS en temps réel, consultez Résoudre les défaillances DNS sur un cluster AKS en temps réel.

Capturer le trafic DNS

Cette section montre comment utiliser Dumpy pour collecter des captures de trafic DNS à partir de chaque pod CoreDNS et d’un pod DNS client (dans ce cas, le aks-test pod).

Pour collecter les captures à partir du pod client de test, exécutez la commande suivante :

kubectl dumpy capture pod aks-test -f "-i any port 53" --name dns-cap1-aks-test

Pour collecter des captures pour les pods CoreDNS, exécutez la commande Dumpy suivante :

kubectl dumpy capture deploy coredns \
    -n kube-system \
    -f "-i any port 53" \
    --name dns-cap1-coredns

Dans l’idéal, vous devez exécuter des captures pendant que le problème se reproduit. Cette exigence signifie que différentes captures peuvent s’exécuter pendant différentes durées, selon la fréquence à laquelle vous pouvez reproduire le problème. Pour collecter les captures, exécutez les commandes suivantes :

mkdir dns-captures
kubectl dumpy export dns-cap1-aks-test ./dns-captures
kubectl dumpy export dns-cap1-coredns ./dns-captures -n kube-system

Pour supprimer les pods Dumpy, exécutez la commande Dumpy suivante :

kubectl dumpy delete dns-cap1-coredns -n kube-system
kubectl dumpy delete dns-cap1-aks-test

Pour fusionner toutes les captures de pod CoreDNS, utilisez l’outil de ligne de commande mergecap pour fusionner les fichiers de capture. L’outil mergecap est inclus dans l’outil d’analyseur de paquets réseau Wireshark. Exécutez la commande mergecap suivante :

mergecap -w coredns-cap1.pcap dns-cap1-coredns-<coredns-pod-name-1>.pcap dns-cap1-coredns-<coredns-pod-name-2>.pcap [...]

Analyse des paquets DNS pour un pod CoreDNS individuel

Après avoir généré et fusionné vos fichiers de capture de trafic, vous pouvez effectuer une analyse de paquets DNS des fichiers de capture dans Wireshark. Procédez comme suit pour afficher l’analyse des paquets pour le trafic d’un pod CoreDNS individuel :

1. Sélectionnez Démarrer, entrez Wireshark, puis sélectionnez Wireshark dans les résultats de la recherche.

2. Dans la fenêtre Wireshark , sélectionnez le menu Fichier , puis sélectionnez Ouvrir.

3. Accédez au dossier qui contient vos fichiers de capture, sélectionnez dns-cap1-db-check-db-check-pod-name.pcap<> (fichier de capture côté client pour un pod CoreDNS individuel), puis sélectionnez le bouton Ouvrir.

4. Sélectionnez le menu Statistiques , puis sélectionnez DNS. La boîte de dialogue Wireshark - DNS s’affiche et affiche une analyse du trafic DNS. Le contenu de la boîte de dialogue s’affiche dans le tableau suivant.

   Rubrique / Élément	Nombre	Moyen	Min Val	Max Val	Taux (ms)	Pourcentage	Taux de rafales	Démarrage en rafale
   ▾ Nombre total de paquets	1066				0.0017	100 %	0.1200	0,000
   ▾ rcode	1066				0.0017	100.00%	0.1200	0,000
   Échec du serveur	17				0.0000	1,59%	0.0100	99.332
   Aucun nom de ce type	353				0.0006	33.11%	0.0400	0,000
   Aucune erreur	696				0.0011	65.29%	0.0800	0,000
   ▾ codes opérationnels	1066				0.0017	100.00%	0.1200	0,000
   Requête standard	1066				0.0017	100,00%	0,1200	0,000
   ▾ Requête/Réponse	1066				0.0017	100.00%	0.1200	0,000
   Réponse	531				0.0009	49,81%	0.0600	0,000
   Requête	535				0.0009	50,19%	0,0600	0,000
   ▾ Type de requête	1066				0.0017	100.00%	0.1200	0,000
   AAAA	167				0.0003	15.67%	0.0200	0,000
   Un	899				0.0015	84.33%	0.1000	0,000
   ▾, classe	1066				0.0017	100.00%	0.1200	0,000
   DANS	1066				0.0017	100.00%	0.1200	0,000
   ▾ Statistiques de service	0				0.0000	100 %	-	-
   temps de réponse de requête (msec)	531	184.42	0.067000	6308.503906	0.0009		0.0600	0,000
   N° des réponses non sollicitées	0				0.0000		-	-
   N° des retransmissions	0				0.0000		-	-
   ▾ Statistiques de réponse	0				0.0000	100 %	-	-
   N° des questions	1062	1.00	1	1	0.0017		0.1200	0,000
   N° des autorités	1062	0.82	0	1	0.0017		0,1200	0,000
   N° des réponses	1062	0.15	0	1	0.0017		0,1200	0,000
   N° d’autres	1062	0,00	0	0	0.0017		0,1200	0,000
   ▾ Statistiques des requêtes	0				0.0000	100 %	-	-
   Qname Len	535	32,99	14	66	0.0009		0.0600	0,000
   ▾ Statistiques de label	0				0.0000		-	-
   4ème niveau ou plus	365				0.0006		0.0400	0,000
   3ème niveau	170				0.0003		0.0200	0,000
   2e niveau	0				0.0000		-	-
   1er niveau	0				0.0000		-	-
   Taille de charge utile	1066	92.87	32	194	0.0017	100 %	0.1200	0,000

La boîte de dialogue d’analyse DNS dans Wireshark affiche un total de 1 066 paquets. De ces paquets, 17 (1,59 %) ont provoqué une défaillance du serveur. En outre, le temps de réponse maximal était de 6 308 millisecondes (6,3 secondes) et aucune réponse n’a été reçue pour 0,38 % des requêtes. (Ce total a été calculé en soustrayant les 49,81 % des paquets qui contenaient des réponses des 50,19 % des paquets qui contenaient des requêtes.)

Si vous entrez (dns.flags.response == 0) && ! dns.response_in en tant que filtre d’affichage dans Wireshark, ce filtre affiche les requêtes DNS qui n’ont pas reçu de réponse, comme indiqué dans le tableau suivant.

Non.	Heure	Origine	Destination	Protocole	Longueur	Informations
225	2024-04-01 16:50:40.000520	10.0.0.21	172.16.0.10	Système de noms de domaine (DNS)	80	Requête standard 0x2c67 AAAA db.contoso.com
426	2024-04-01 16:52:47.419907	10.0.0.21	172.16.0.10	Système de noms de domaine (DNS)	1:32	Requête standard 0x8038 A db.contoso.com.iosffyoulcwehgo1g3egb3m4oc.jx.internal.cloudapp.net
693	2024-04-01 16:55:23.105558	10.0.0.21	172.16.0.10	Système de noms de domaine (DNS)	1:32	Requête standard 0xbcb0 A db.contoso.com.iosffyoulcwehgo1g3egb3m4oc.jx.internal.cloudapp.net
768	2024-04-01 16:56:06.512464	10.0.0.21	172.16.0.10	Système de noms de domaine (DNS)	80	Requête standard 0xe330 A db.contoso.com

En outre, la barre d’état Wireshark affiche le texte Paquets : 1066 - Affiché : 4 (0,4%). Ces informations signifient que quatre des 1 066 paquets, ou 0,4 pour cent, étaient des requêtes DNS qui n’ont jamais reçu de réponse. Ce pourcentage correspond essentiellement au total de 0,38 % que vous avez calculé précédemment.

Si vous remplacez le filtre d’affichage par , le filtre dns.time >= 5affiche les paquets de réponse de requête qui ont pris cinq secondes ou plus pour être reçus, comme indiqué dans la table mise à jour.

Non.	Heure	Origine	Destination	Protocole	Longueur	Informations	SourcePort	RR additionnelles	temps de réponse DNS
213	2024-04-01 16:50:32.644592	172.16.0.10	10.0.0.21	Système de noms de domaine (DNS)	1:32	Échec du serveur pour la requête standard 0x9312 A db.contoso.com.iosffyoulcwehgo1g3egb3m4oc.jx.internal.cloudapp.net	53	0	6.229941
320	2024-04-01 16:51:55.053896	172.16.0.10	10.0.0.21	Système de noms de domaine (DNS)	80	Échec du serveur lors de la requête standard 0xe5ce sur db.contoso.com	53	0	6.065555
328	2024-04-01 16:51:55.113619	172.16.0.10	10.0.0.21	Système de noms de domaine (DNS)	1:32	Requête standard 0x6681 échec du serveur A db.contoso.com.iosffyoulcwehgo1g3egb3m4oc.jx.internal.cloudapp.net	53	0	6.029641
335	2024-04-01 16:52:02.553811	172.16.0.10	10.0.0.21	Système de noms de domaine (DNS)	80	Échec du serveur de la requête standard 0x6cf6 à db.contoso.com	53	0	6.500504
541	2024-04-01 16:53:53.423838	172.16.0.10	10.0.0.21	Système de noms de domaine (DNS)	80	Requête standard 0x07b3 échec du serveur AAAA db.contoso.com	53	0	6.022195
553	2024-04-01 16:54:05.165234	172.16.0.10	10.0.0.21	Système de noms de domaine (DNS)	1:32	Échec de la requête standard 0x1ea0 sur le serveur A db.contoso.com.iosffyoulcwehgo1g3egb3m4oc.jx.internal.cloudapp.net	53	0	6.007022
774	2024-04-01 16:56:17.553531	172.16.0.10	10.0.0.21	Système de noms de domaine (DNS)	80	Requête standard 0xa20f échec du serveur AAAA db.contoso.com	53	0	6.014926
891	2024-04-01 16:56:44.442334	172.16.0.10	10.0.0.21	Système de noms de domaine (DNS)	1:32	Échec de la requête standard 0xa279 du serveur A db.contoso.com.iosffyoulcwehgo1g3egb3m4oc.jx.internal.cloudapp.net	53	0	6.044552

Après avoir modifié le filtre d’affichage, la barre d’état est mise à jour pour afficher le texte Paquets : 1066 - Affiché : 8 (0,8%). Par conséquent, huit des 1 066 paquets, ou 0,8 p. 100, étaient des réponses DNS qui ont pris cinq secondes ou plus pour être reçues. Toutefois, sur la plupart des clients, la valeur de délai d’attente DNS par défaut devrait être de cinq secondes. Cela signifie que, bien que les pods CoreDNS aient traité et remis les huit réponses, le client a déjà terminé la session en émettant un message d’erreur « expiré ». La colonne Info dans les résultats filtrés indique que les huit paquets ont provoqué une défaillance du serveur.

Analyse des paquets DNS pour tous les pods CoreDNS

Dans Wireshark, ouvrez le fichier de capture des pods CoreDNS que vous avez fusionnés précédemment (coredns-cap1.pcap), puis ouvrez l’analyse DNS, comme décrit dans la section précédente. Une boîte de dialogue Wireshark apparaît qui affiche le tableau suivant.

Rubrique / Élément	Nombre	Moyen	Min Val	Max Val	Taux (ms)	Pourcentage	Taux de rafales	Démarrage en rafale
▾ Nombre total de paquets	4540233				7.3387	100 %	84.7800	592.950
▾ rcode	4540233				7.3387	100.00%	84.7800	592.950
Échec du serveur	121781				0.1968	2.68%	8.4600	599.143
Aucun nom de ce type	574658				0.9289	12,66 %	10,9800	592.950
Aucune erreur	3843794				6,2130	84.66%	73.2500	592.950
▾ codes opérationnels	4540233				7.3387	100.00%	84.7800	592.950
Requête standard	4540233				7.3387	100.00%	84.7800	592.950
▾ Requête/Réponse	4540233				7.3387	100.00%	84.7800	592.950
Réponse	2135116				3.4512	47.03%	39.0400	581.680
Requête	2405117				3,8876	52,97%	49.1400	592.950
▾ Type de requête	4540233				7.3387	100.00%	84.7800	592.950
SRV	3647				0.0059	0,08%	0.1800	586.638
Le PTR	554630				0.8965	12.22%	11.5400	592.950
NS	15918				0.0257	0,35 %	0.7200	308.225
MX	393016				0.6353	8,66%	7.9700	426.930
AAAA	384032				0.6207	8,46 %	8.4700	438.155
Un	3188990				5.1546	70.24%	57,9600	592.950
▾, classe	4540233				7.3387	100.00%	84.7800	592.950
DANS	4540233				7.3387	100.00%	84.7800	592.950
▾ Statistiques de service	0				0.0000	100 %	-	-
temps de réponse de requête (msec)	2109677	277.18	0.020000	12000.532227	3.4100		38.0100	581.680
N° des réponses non sollicitées	25402				0.0411		5,1400	587,832
N° des retransmissions	37				0.0001		0.0300	275.702
▾ Statistiques de réponse	0				0.0000	100 %	-	-
N° des questions	4244830	1.00	1	1	6.8612		77.0500	581.680
N° des autorités	4244830	0.39	0	11	6,8612		77.0500	581.680
N° des réponses	4244830	1.60	0	22	6.8612		77.0500	581.680
N° d’autres	4244830	0,29	0	26	6,8612		77.0500	581.680
▾ Statistiques des requêtes	0				0.0000	100 %	-	-
Qname Len	2405117	20.42	2	113	3,8876		49.1400	592.950
▾ Statistiques de label	0				0.0000		-	-
4ème niveau ou plus	836034				1.3513		16.1900	592.950
3ème niveau	1159513				1.8742		23.8900	592.950
2e niveau	374182				0.6048		8.7800	592.955
1er niveau	35388				0.0572		0.9200	294.492
Taille de charge utile	4540233	89.87	17	1128	7.3387	100 %	84.7800	592.950

La boîte de dialogue indique qu’il y avait un total combiné d’environ 4,5 millions de paquets (4 540 233), dont 2,68 % ont provoqué une défaillance du serveur. La différence entre les pourcentages de paquets de requête et de réponse indique que 5,94 % des requêtes (52,97 % moins 47,03 %) n’ont pas reçu de réponse. Le temps de réponse maximal était de 12 secondes (12 000,532227 millisecondes).

Si vous appliquez le filtre d’affichage pour les réponses de requête qui ont pris cinq secondes ou plus (dns.time >= 5), la plupart des paquets dans les résultats du filtre indiquent qu’une défaillance du serveur s’est produite. Cela est probablement dû à une erreur de « dépassement de délai » du client.

Le tableau suivant récapitule les résultats de capture.

Capturer les critères de révision	Oui	Non
La différence entre les requêtes et les réponses DNS dépasse deux pour cent	☑	☐
La latence DNS est supérieure à une seconde	☑	☐

Étape 2 de résolution des problèmes : Développer une hypothèse

Cette section classe les types de problèmes courants pour vous aider à affiner les problèmes potentiels et à identifier les composants susceptibles de nécessiter des ajustements. Cette approche définit la base de la création d’un plan d’action ciblé pour atténuer et résoudre efficacement ces problèmes.

Codes de réponse DNS courants

Le tableau suivant récapitule les codes de retour DNS les plus courants.

Code de retour DNS	Message de retour DNS	Descriptif
RCODE:0	NOERROR	La requête DNS s’est terminée correctement.
RCODE:1	FORMERR	Une erreur de format de requête DNS existe.
RCODE:2	SERVFAIL	Le serveur n’a pas terminé la requête DNS.
RCODE:3	NXDOMAIN	Le nom de domaine n’existe pas.
RCODE:5	REFUSED	Le serveur a refusé de répondre à la requête.
RCODE:8	NOTAUTH	Le serveur ne fait pas autorité pour la zone.

Types de problèmes généraux

Le tableau suivant répertorie les catégories de types de problèmes qui vous aident à décomposer les symptômes du problème.

Type de problème	Descriptif
Performances	Les problèmes de performances de résolution DNS peuvent entraîner des erreurs intermittentes, telles que des erreurs « délais d'attente dépassés » du point de vue du client. Ces problèmes peuvent se produire parce que les nœuds subissent l’épuisement des ressources ou la limitation des E/S. En outre, les contraintes sur les ressources de calcul dans les pods CoreDNS peuvent entraîner une latence de résolution. Si la latence coreDNS est élevée ou augmente au fil du temps, cela peut indiquer un problème de charge. Si les instances CoreDNS sont surchargées, vous pouvez rencontrer des problèmes et des retards de résolution de noms DNS, ou vous pouvez rencontrer des problèmes dans les charges de travail et les services internes Kubernetes.
Paramétrage	Les problèmes de configuration peuvent entraîner une résolution DNS incorrecte. Dans ce cas, vous pourriez rencontrer des erreurs de timeout ou d’expiration NXDOMAIN. Des configurations incorrectes peuvent se produire dans CoreDNS, nœuds, Kubernetes, routage, DNS de réseau virtuel, zones DNS privées, pare-feu, proxys, et ainsi de suite.
Connectivité réseau	Les problèmes de connectivité réseau peuvent affecter la connectivité pod-à-pod (trafic est-ouest) ou la connectivité pod-and-node aux ressources externes (trafic nord-sud). Ce scénario peut entraîner des erreurs de dépassement de délai. Les problèmes de connectivité peuvent se produire si les points de terminaison de service CoreDNS ne sont pas à jour (par exemple, en raison de problèmes kube-proxy, de problèmes de routage, de perte de paquets, etc.). La dépendance des ressources externes combinée à des problèmes de connectivité (par exemple, la dépendance sur des serveurs DNS personnalisés ou des serveurs DNS externes) peut également contribuer au problème.

Entrées requises

Avant de formuler une hypothèse de causes probables du problème, récapitulez les résultats des étapes précédentes du workflow de résolution des problèmes.

Vous pouvez collecter les résultats à l’aide des tableaux suivants.

Résultats du modèle de questionnaire de base

Question	Réponses possibles
Où la résolution DNS échoue-t-elle ?	☐ Pod ☐ Noeud ☐ Pod et nœud
Quel type d’erreur DNS obtenez-vous ?	☐ Délai d'attente expiré ☐ NXDOMAIN ☐ Autre erreur DNS
À quelle fréquence les erreurs DNS se produisent-elles ?	☐ Toujours ☐ Par intermittence ☐ Dans un modèle spécifique
Quels enregistrements sont affectés ?	☐ Un domaine spécifique ☐ Tout domaine
Existe-t-il des configurations DNS personnalisées ?	☐ Serveurs DNS personnalisés sur un réseau virtuel ☐ Configuration CoreDNS personnalisée

Résultats des tests à différents niveaux

Résultats des tests de résolution	Travaux	Échecs
Du pod au service CoreDNS	☐	☐
De pod à l’adresse IP du pod CoreDNS	☐	☐
Du pod au DNS interne Azure	☐	☐
Du pod au DNS de réseau virtuel	☐	☐
Du nœud au DNS interne Azure	☐	☐
Du nœud au DNS de réseau virtuel	☐	☐

Résultats de l’intégrité et des performances des nœuds et des pods CoreDNS

Résultats de l’évaluation des performances	Sain	Malsain
Performances des nœuds	☐	☐
Performances des pods CoreDNS	☐	☐

Résultats des captures de trafic et des performances de résolution DNS

Capturer les critères de révision	Oui	Non
La différence entre les requêtes et les réponses DNS dépasse deux pour cent	☐	☐
La latence DNS est supérieure à une seconde	☐	☐

Mapper les entrées requises aux types de problèmes

Pour développer votre première hypothèse, mappez chacun des résultats des entrées requises à un ou plusieurs des types de problèmes. En analysant ces résultats dans le contexte des types de problèmes, vous pouvez développer des hypothèses sur les causes racines potentielles des problèmes de résolution DNS. Vous pouvez ensuite créer un plan d’action d’investigation et de résolution des problèmes ciblés.

Pointeurs de mappage de type d’erreur

• Si les résultats des tests montrent des échecs de résolution DNS au niveau du service CoreDNS ou contiennent des erreurs de délais d'attente dépassés lors de la tentative d’atteindre des points de terminaison spécifiques, cela peut indiquer des problèmes de configuration ou de connectivité.

• Les indications d'un manque de ressources de calcul au niveau du pod ou du nœud CoreDNS peuvent suggérer un problème de performance.

• Les captures DNS qui ont une incompatibilité considérable entre les requêtes DNS et les réponses DNS peuvent indiquer que les paquets sont perdus. Ce scénario suggère qu’il existe des problèmes de connectivité ou de performances.

• La présence de configurations personnalisées au niveau du réseau virtuel ou kubernetes peut contenir des configurations qui ne fonctionnent pas avec AKS et CoreDNS comme prévu.

Résolution des problèmes à l’étape 3 : Créer et implémenter un plan d’action

Vous devez maintenant disposer d’informations suffisantes pour créer et implémenter un plan d’action. Les sections suivantes contiennent des recommandations supplémentaires pour formuler votre plan pour des types de problèmes spécifiques.

Problèmes de performances

Si vous rencontrez des problèmes de performances de résolution DNS, passez en revue et implémentez les meilleures pratiques et conseils suivants.

Meilleure pratique	Instructions
Configurez un pool de nœuds système dédié qui répond aux exigences minimales de dimensionnement.	Gérer les pools de nœuds système dans Azure Kubernetes Service (AKS)
Pour éviter la limitation des E/S de disque, utilisez des nœuds qui ont des disques de système d’exploitation éphémères.	Dimensionnement du disque de système d’exploitation par défaut et problème GitHub 1373 dans Azure AKS
Suivez les meilleures pratiques de gestion des ressources sur les charges de travail au sein des nœuds.	Bonnes pratiques relatives à la gestion des ressources dans Azure Kubernetes Services (AKS) pour le développeur d’applications

Si les performances DNS ne sont toujours pas suffisantes après avoir apporté ces modifications, envisagez d’utiliser le DNS local de nœud.

Problèmes de configuration

Selon le composant, vous devez passer en revue et comprendre les implications de la configuration spécifique. Pour plus d’informations sur la configuration, consultez la liste suivante de la documentation spécifique au composant :

• Options de configuration DNS Kubernetes
• Options de configuration personnalisées AKS CoreDNS
• Zones DNS privées manquantes d’un lien de réseau virtuel

Problèmes de connectivité réseau

• Les bogues qui impliquent l’interface CNI (Container Networking Interface) ou d’autres composants Kubernetes ou OS nécessitent généralement une intervention du support AKS ou du groupe de produits AKS.

• Les problèmes d’infrastructure, tels que les défaillances matérielles ou les problèmes d’hyperviseur, peuvent nécessiter la collaboration des équipes de support d’infrastructure. Ces problèmes peuvent également avoir des fonctionnalités d’auto-guérison.

Étape de résolution des problèmes 4 : Observer les résultats et tirer des conclusions

Observez les résultats de l’implémentation de votre plan d’action. À ce stade, votre plan d’action doit être en mesure de résoudre ou d’atténuer le problème.

Étape 5 de résolution des problèmes : répéter si nécessaire

Si ces étapes de dépannage ne résolvent pas le problème, répétez les étapes de dépannage si nécessaire.

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.

Exclusion de responsabilité pour contact avec des tiers

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

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.