Container Service for Kubernetes:Troubleshoot DNS resolution errors

# View the pod's DNS policy
kubectl get pod <pod-name> -o yaml

# Log in to the pod and inspect the DNS configuration
kubectl exec -it <pod-name> -- cat /etc/resolv.conf

# View CoreDNS pod status and placement
kubectl -n kube-system get pod -o wide -l k8s-app=kube-dns

NAME                      READY   STATUS    RESTARTS   AGE   IP            NODE
coredns-xxxxxxxxx-xxxxx   1/1     Running   0          25h   172.20.6.53   cn-hangzhou.192.168.0.198

# View real-time CPU and memory usage
kubectl -n kube-system top pod -l k8s-app=kube-dns

NAME                      CPU(cores)   MEMORY(bytes)
coredns-xxxxxxxxx-xxxxx   3m           18Mi

kubectl -n kube-system logs -f --tail=500 --timestamps <coredns-pod-name>

[INFO] 172.20.2.25:44525 - 36259 "A IN redis-master.default.svc.cluster.local. udp 56 false 512" NOERROR qr,aa,rd 110 0.000116946s

Tester la connectivité réseau entre les pods d'application et CoreDNS

Accédez au namespace réseau du pod d'application en utilisant l'une des méthodes suivantes :

• Méthode 1 (recommandée) : Exécutez kubectl exec -it <pod-name> -- bash pour entrer dans le pod.

• Méthode 2 : Connectez-vous au nœud, identifiez l'ID du processus avec ps aux | grep <application-process-name>, puis accédez au namespace réseau via nsenter -t <pid> -n bash.

• Méthode 3 (pour les pods redémarrant fréquemment) :

  1. Connectez-vous au nœud.

  2. Exécutez docker ps -a | grep <application-container-name> pour trouver les ID des conteneurs sandbox (dont les noms commencent par k8s_POD_).

  3. Exécutez docker inspect <sandboxed-container-ID> | grep netns pour obtenir le chemin du namespace réseau dans /var/run/docker/netns/xxxx.

  4. Exécutez nsenter -n bash pour entrer dans le namespace. > Note: Ne mettez pas d'espace entre -n et <netns-path>.

Depuis le namespace réseau du pod, testez la connectivité :

# Test connectivity to the kube-dns Service
dig <domain> @<kube-dns-svc-ip>

# Test Internet Control Message Protocol (ICMP) connectivity to the CoreDNS pod
ping <coredns-pod-ip>

# Test DNS query directly to the CoreDNS pod
dig <domain> @<coredns-pod-ip>

Remplacez <kube-dns-svc-ip> par l'IP du Service kube-dns dans le namespace kube-system, et <coredns-pod-ip> par l'IP d'un pod CoreDNS.

Tester la connectivité réseau de CoreDNS

1. Connectez-vous au nœud où s'exécute le pod CoreDNS.

2. Exécutez ps aux | grep coredns pour obtenir l'ID du processus CoreDNS.

3. Exécutez nsenter -t <pid> -n bash pour entrer dans le namespace réseau de CoreDNS.

4. Testez la connectivité :

   # Test connectivity to the Kubernetes API server
   telnet <apiserver_clusterip> 6443  # apiserver_clusterip is the ClusterIP of the kubernetes Service in the default namespace.
   
   # Test connectivity to upstream DNS servers
   dig <domain> @100.100.2.136
   dig <domain> @100.100.2.138

Diagnostiquer le réseau de conteneurs

1. Connectez-vous à la console ACKconsole ACK.

2. Sur la page Clusters, cliquez sur le nom de votre cluster ou sur Details dans la colonne Actions.

3. Dans le volet de navigation de gauche, choisissez Operations > Cluster Check.

4. Sur la page Container Intelligence Service, choisissez Cluster Check > Diagnosis.

5. Sur la page Diagnosis, cliquez sur l'onglet Network Diagnosis.

6. Définissez Source address sur l'IP du pod d'application, Destination address sur l'IP du Service kube-dns, et Destination port sur 53. Sélectionnez Enable packet tracing et I know and agree, puis cliquez sur Create diagnosis.

7. Dans la liste des diagnostics, cliquez sur Diagnosis details pour votre enregistrement.

Les résultats affichent le Diagnosis result, les Packet paths et All possible paths, ainsi que les causes d'erreur identifiées. Consultez la rubrique Utiliser la fonctionnalité de diagnostic de cluster pour résoudre les problèmes de cluster.

Capturer des paquets

Recourez à la capture de paquets lorsque les erreurs sont intermittentes et difficiles à reproduire.

1. Connectez-vous aux nœuds où s'exécutent les pods d'application et le pod CoreDNS.

2. Capturez le trafic DNS sur chaque instance ECS :

   tcpdump -i any port 53 -C 20 -W 200 -w /tmp/client_dns.pcap

   Cette commande capture tout le trafic sur le port 53, avec une rotation pouvant aller jusqu'à 200 fichiers de 20 Mo chacun.

3. Reproduisez l'erreur et analysez les paquets correspondant à la fenêtre temporelle de la panne. Consultez les journaux de l'application pour obtenir les horodatages exacts.

L'impact de la capture de paquets sur le service est négligeable ; elle entraîne seulement une légère augmentation de l'utilisation du CPU et des E/S disque.

Impossible de résoudre un nom de domaine externe

Consultez le journal des requêtes CoreDNS pour vérifier le code de réponse. Activez le plugin log si ce n'est pas déjà fait (voir Configurer la résolution DNS), puis recherchez le domaine en échec. NXDOMAIN signifie que le domaine n'existe pas en amont, souvent parce qu'un suffixe de recherche a été ajouté, créant un FQDN invalide. SERVFAIL ou REFUSED indique un problème côté serveur upstream ; vérifiez la configuration de CoreDNS et sa connectivité vers 100.100.2.136 et 100.100.2.138.

Impossible de résoudre les noms de domaine des Services headless

Dans les versions de CoreDNS antérieures à 1.7.0, une instabilité réseau du serveur API peut provoquer l'arrêt de CoreDNS, interrompant ainsi la mise à jour des enregistrements des Services headless. Mettez à jour vers la version 1.7.0 ou ultérieure. Consultez la rubrique [\[Mises à jour des composants\] Mettre à jour CoreDNS](t1964489.dita#task_1964489).

Impossible de résoudre les noms de domaine des pods StatefulSet

Le modèle de pod StatefulSet doit définir serviceName sur le nom du Service headless. Sans cela, les noms DNS spécifiques à chaque pod (par exemple, pod.headless-svc.ns.svc.cluster.local) ne peuvent pas être résolus, même si le nom au niveau du Service (par exemple, headless-svc.ns.svc.cluster.local) fonctionne correctement. Définissez serviceName dans la spécification du StatefulSet.

Requêtes DNS bloquées par des règles de groupe de sécurité ou des ACL réseau

Des règles de groupe de sécurité ou des listes de contrôle d'accès (ACL) réseau bloquent le port UDP 53, entraînant des échecs DNS sur les nœuds concernés. Autorisez le trafic entrant et sortant sur le port UDP 53.

Erreurs de connectivité du réseau de conteneurs causant des échecs DNS

Des erreurs du réseau de conteneurs bloquent le port UDP 53. Utilisez la fonctionnalité de diagnostic réseau pour identifier le chemin défaillant et la cause racine.

Surcharge des pods CoreDNS

Lorsque le volume de requêtes dépasse la capacité des réplicas CoreDNS, la latence augmente et des échecs surviennent. Vérifiez si l'utilisation du CPU et de la mémoire approche de la limite (kubectl -n kube-system top pod -l k8s-app=kube-dns).

Deux solutions possibles :

• Déployez NodeLocal DNSCache pour absorber les requêtes localement et réduire la charge sur CoreDNS. Consultez la rubrique Configurer NodeLocal DNSCache.

• Augmentez le nombre de réplicas CoreDNS afin que l'utilisation maximale du CPU par pod reste bien inférieure au CPU disponible du nœud.

Répartition inégale des requêtes DNS entre les pods CoreDNS

Une planification déséquilibrée des pods ou un paramètre sessionAffinity sur kube-dns peut entraîner une distribution inégale des requêtes. Symptôme : utilisation du CPU sensiblement différente entre les pods CoreDNS.

Deux solutions possibles :

• Augmentez le nombre de pods CoreDNS et répartissez-les sur différents nœuds.

• Supprimez le paramètre sessionAffinity du Service kube-dns. Consultez la rubrique Configurer le Service kube-dns.

Fonctionnement anormal des pods CoreDNS

Une configuration YAML ou ConfigMap incorrecte peut empêcher le démarrage de CoreDNS ou provoquer des plantages. Symptômes : pods non Running, nombre de redémarrages croissant ou erreurs dans les journaux.

Recherchez ces erreurs courantes dans les journaux CoreDNS :

Échecs de résolution DNS dus à la surcharge du client

Lorsque l'instance ECS est pleinement chargée, des paquets UDP peuvent être perdus avant d'atteindre CoreDNS. Recherchez un taux de retransmission anormal de la carte réseau (NIC) et une utilisation élevée du CPU dans les données de surveillance.

Déployez NodeLocal DNSCache pour réduire le trafic DNS inter-nœuds. Consultez la rubrique Configurer NodeLocal DNSCache.

Table conntrack pleine

Lorsque la table conntrack est pleine, les nouvelles connexions UDP et TCP sont abandonnées. Cela provoque généralement des échecs DNS pendant les heures de pointe, qui se résorbent en période creuse. Pour confirmer, exécutez dmesg -H sur le nœud concerné et recherchez conntrack full durant la fenêtre de panne.

Augmentez le nombre maximal d'entrées dans la table conntrack. Consultez la rubrique Comment augmenter le nombre maximal de connexions suivies dans la table conntrack du noyau Linux ?

Le plugin autopath ne fonctionne pas normalement

Un défaut connu du plugin autopath provoque des échecs occasionnels de résolution ou des IP incorrectes pour les domaines externes. Les domaines internes se résolvent correctement. Le problème s'aggrave dans les clusters ayant un taux élevé de création de conteneurs.

Désactivez le plugin autopath :

1. Modifiez la ConfigMap CoreDNS avec kubectl -n kube-system edit configmap coredns.

2. Supprimez la ligne autopath @kubernetes. Enregistrez et quittez.

3. Vérifiez le chargement de la configuration en recherchant reload dans les journaux CoreDNS.

Échecs de résolution DNS dus à des requêtes simultanées d'enregistrements A et AAAA

Certaines distributions Linux envoient simultanément des requêtes A et AAAA sur le même port, déclenchant des conflits conntrack qui entraînent la perte de paquets UDP.

Symptômes : échecs de résolution intermittents ; la capture de paquets montre des requêtes A et AAAA simultanées provenant du même port source.

Les corrections dépendent de votre image de base :

• CentOS ou Ubuntu : Ajoutez options timeout:2 attempts:3 rotate single-request-reopen à la configuration du résolveur DNS.

• Alpine Linux : Remplacez l'image basée sur Alpine par une image basée sur un autre système d'exploitation. Consultez Limitations d'Alpine.

• PHP avec cURL : Ajoutez CURL_IPRESOLVE_V4 pour forcer la résolution IPv4 uniquement. Consultez Fonctions cURL.

• Tous les environnements : Déployez NodeLocal DNSCache, qui atténue cette condition de concurrence. Consultez la rubrique Configurer NodeLocal DNSCache.

Échecs de résolution DNS dus à des erreurs IPVS

En mode IPVS avec CentOS ou Alibaba Cloud Linux 2 (noyau antérieur à 4.19.91-25.1.al7.x86_64), la suppression de pods backend UDP provoque des conflits de port source entraînant la perte de paquets. Les échecs DNS durent environ 5 minutes lors des événements de mise à l'échelle des nœuds ou de CoreDNS.

Deux solutions possibles :

• Déployez NodeLocal DNSCache pour contourner le chemin IPVS pour les requêtes DNS. Consultez la rubrique Configurer NodeLocal DNSCache.

• Réduisez le délai d'expiration de session UDP en mode IPVS. Consultez la rubrique Modifier le délai d'expiration UDP en mode IPVS.

NodeLocal DNSCache ne fonctionne pas

Les requêtes DNS contournent NodeLocal DNSCache lorsque l'une des conditions suivantes s'applique :

• dnsConfig n'a pas été injecté dans les pods d'application, qui pointent donc toujours vers l'IP du Service kube-dns.

• Les pods utilisent une image de base Alpine Linux, qui interroge tous les serveurs de noms simultanément, y compris CoreDNS directement.

Pour le premier cas, activez l'injection automatique de dnsConfig. Consultez la rubrique Configurer NodeLocal DNSCache. Pour les images Alpine, utilisez une image construite sur un autre système d'exploitation. Consultez Limitations d'Alpine.

Impossible de résoudre les noms Alibaba Cloud DNS PrivateZone

Alibaba Cloud DNS PrivateZone nécessite le protocole UDP, et non TCP. Avec NodeLocal DNSCache, les domaines PrivateZone, les endpoints API vpc-proxy ou d'autres noms de domaine peuvent échouer à se résoudre ou pointer vers des IP incorrectes.

Ajoutez prefer_udp à la configuration CoreDNS pour forcer l'utilisation d'UDP pour les requêtes upstream. Consultez la rubrique Configurer CoreDNS.