Résoudre les échecs de résolution DNS à partir du pod, mais pas à partir du nœud Worker

Article
11/20/2024

Cet article explique comment résoudre les échecs de résolution DNS (Domain Name System) qui se produisent à l’intérieur du pod, mais pas à partir du nœud Worker, lorsque vous essayez d’établir une connexion sortante à partir d’un cluster AKS (Microsoft Azure Kubernetes Service).

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 en ligne de commande hôte pour les recherches DNS.
Outil en ligne de commande systemctl .

Background

Pour la résolution DNS, les pods envoient des demandes aux pods CoreDNS dans l’espace kube-system de noms.

Si la requête DNS concerne un composant interne, tel qu’un nom de service, le pod CoreDNS répond par lui-même. Toutefois, si la requête concerne un domaine externe, le pod CoreDNS envoie la requête au serveur DNS en amont.

Les serveurs DNS en amont sont obtenus en fonction du fichier resolv.conf du nœud Worker dans lequel le pod est en cours d’exécution. Le fichier resolv.conf ( /run/systemd/resolve/resolv.conf) est mis à jour en fonction des paramètres DNS du réseau virtuel sur lequel le nœud Worker s’exécute.

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

Pour résoudre les problèmes DNS à partir du pod, utilisez les instructions des sections suivantes.

Étape 1 : Résoudre les problèmes DNS à partir du pod

Vous pouvez utiliser des commandes kubectl pour résoudre les problèmes DNS à partir du pod, comme indiqué dans les étapes suivantes :

Vérifiez que les pods CoreDNS sont en cours d’exécution :
```
kubectl get pods -l k8s-app=kube-dns -n kube-system
```

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

Vérifiez que les nœuds qui hébergent les pods CoreDNS ne sont pas surutilisées. Obtenez également 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}'
```
Vérifiez l’utilisation de ces nœuds :
```
kubectl top nodes
```

Vérifiez les journaux des pods CoreDNS :

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

Note

Pour afficher plus d’informations sur le débogage, activez les journaux détaillés dans CoreDNS. Pour activer la journalisation détaillée dans CoreDNS, consultez Résolution des problèmes de personnalisations CoreDNS dans AKS.

Étape 2 : Créer un pod de test pour exécuter des commandes

Si la résolution DNS échoue, procédez comme suit :

Exécutez un pod de test dans le même espace de noms que le pod problématique.
Démarrez un pod de test dans le cluster :
```
kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable
```
Lorsque le pod de test est en cours d’exécution, vous aurez accès au pod.
Exécutez les commandes suivantes pour installer les packages nécessaires :
```
apt-get update -y
apt-get install dnsutils -y
```

Vérifiez que le fichier resolv.conf contient les entrées correctes :

cat /etc/resolv.conf
search default.svc.cluster.local svc.cluster.local cluster.local 00idcnmrrm4edot5s2or1onxsc.bx.internal.cloudapp.net
nameserver 10.0.0.10
options ndots:5

Utilisez la host commande pour déterminer si les requêtes DNS sont routées vers le serveur en amont :

$ host -a microsoft.com
Trying "microsoft.com.default.svc.cluster.local"
Trying "microsoft.com.svc.cluster.local"
Trying "microsoft.com.cluster.local"
Trying "microsoft.com.00idcnmrrm4edot5s2or1onxsc.bx.internal.cloudapp.net"
Trying "microsoft.com"
Trying "microsoft.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62884
;; flags: qr rd ra; QUERY: 1, ANSWER: 27, AUTHORITY: 0, ADDITIONAL: 5

;; QUESTION SECTION:
;microsoft.com.                 IN      ANY

;; ANSWER SECTION:
microsoft.com.          30      IN      NS      ns1-39.azure-dns.com.
...
...
ns4-39.azure-dns.info.  30      IN      A       13.107.206.39

Received 2121 bytes from 10.0.0.10#53 in 232 ms

Vérifiez le serveur DNS en amont à partir du pod pour veiller à ce que la résolution DNS fonctionne correctement. Par exemple, pour Azure DNS, exécutez la commande nslookup suivante :
```
$ nslookup microsoft.com 168.63.129.16
Server:         168.63.129.16
Address:        168.63.129.16#53
...
...
Address: 20.81.111.85
```

Étape 3 : Vérifier si les requêtes DNS fonctionnent lorsque le serveur DNS en amont est explicitement spécifié

Si les requêtes DNS provenant de pods fonctionnent lorsque vous spécifiez explicitement le serveur DNS en amont, vérifiez les conditions suivantes :

Recherchez un ConfigMap personnalisé pour CoreDNS :
```
kubectl describe cm coredns-custom -n kube-system
```
Si un ConfigMap personnalisé est présent, vérifiez que la configuration est correcte. Pour plus d’informations, consultez Personnaliser CoreDNS avec Azure Kubernetes Service.
Vérifiez si une stratégie réseau bloque le trafic sur le port UDP (User Datagram Protocol) 53 vers les pods CoreDNS dans l’espace kube-system de noms.
Vérifiez si les pods CoreDNS se trouvent sur un autre pool de nœuds (pool de nœuds système). Si c’est le cas, vérifiez si un groupe de sécurité réseau (NSG) est associé au pool de nœuds système qui bloque le trafic sur le port UDP 53.
Vérifiez si le réseau virtuel a été mis à jour récemment pour ajouter les nouveaux serveurs DNS.

Si une mise à jour de réseau virtuel s’est produite, vérifiez si l’un des événements suivants s’est également produit :
- Les nœuds ont été redémarrés.
- Le service réseau dans le nœud a été redémarré.
Pour que la mise à jour dans les paramètres DNS prenne effet, le service réseau sur le nœud et les pods CoreDNS doivent être redémarrés. Pour redémarrer le service réseau ou les pods, utilisez l’une des méthodes suivantes :
- Redémarrez le nœud.
- Mettre à l’échelle de nouveaux nœuds. (Les nouveaux nœuds auront la configuration mise à jour.)
- Redémarrez le service réseau dans les nœuds, puis redémarrez les pods CoreDNS. Effectuez les étapes suivantes :
  1. Établissez une connexion SSH (Secure Shell) aux nœuds. Pour plus d’informations, consultez Se connecter à des nœuds de cluster Azure Kubernetes Service (AKS) pour la maintenance ou la résolution des problèmes.
  2. À partir du nœud, redémarrez le service réseau :
```
systemctl restart systemd-networkd
```
  3. Vérifiez si les paramètres sont mis à jour :
```
cat /run/systemd/resolve/resolv.conf
```
  4. Une fois le service réseau redémarré, utilisez kubectl pour redémarrer les pods CoreDNS :
```
kubectl delete pods -l k8s-app=kube-dns -n kube-system
```

Vérifiez si plusieurs serveurs DNS sont spécifiés dans les paramètres DNS du réseau virtuel.

Si plusieurs serveurs DNS sont spécifiés dans le réseau virtuel AKS, l’une des séquences suivantes se produit :

Le nœud AKS envoie une requête au serveur DNS en amont dans le cadre d’une série. Dans cette séquence, la requête est envoyée au premier serveur DNS configuré dans le réseau virtuel (si les serveurs DNS sont accessibles et en cours d’exécution). Si le premier serveur DNS n’est pas accessible et ne répond pas, la demande est envoyée au serveur DNS suivant.

Les nœuds AKS utilisent la commande de programme de résolution pour envoyer des requêtes aux serveurs DNS. Le fichier de configuration de ce programme de résolution se trouve à l’adresse /run/systemd/resolve/resolv.conf dans les nœuds AKS.

Existe-t-il plusieurs serveurs ? Dans ce cas, la bibliothèque de programme de résolution les interroge dans l’ordre répertorié. (La stratégie utilisée consiste à essayer d’abord un serveur de noms. Si la requête expire, essayez le serveur de noms suivant et continuez jusqu’à ce que la liste des serveurs de noms soit épuisée. Ensuite, la requête continue d’essayer de se connecter aux serveurs de noms jusqu’à ce que le nombre maximal de nouvelles tentatives soit effectué.)

CoreDNS utilise le plug-in de transfert pour envoyer des requêtes aux serveurs DNS en amont. Ce plug-in utilise un algorithme aléatoire pour sélectionner le serveur DNS en amont. Dans cette séquence, la requête peut accéder à l’un des serveurs DNS mentionnés dans le réseau virtuel. Par exemple, vous pouvez recevoir la sortie suivante :

$ kubectl describe cm coredns -n kube-system
Name:         coredns
Namespace:    kube-system
Labels:       addonmanager.kubernetes.io/mode=Reconcile
              k8s-app=kube-dns
              kubernetes.io/cluster-service=true
Annotations:  <none>

Data
====
Corefile:
----
.:53 {
    errors
    ready
    health
    kubernetes cluster.local in-addr.arpa ip6.arpa {
      pods insecure
      fallthrough in-addr.arpa ip6.arpa
    }
    prometheus :9153
    forward . /etc/resolv.conf                            # Here!
    cache 30
    loop
    reload
    loadbalance
    import custom/*.override
}
import custom/*.server


BinaryData
====

Events:  <none>

Dans le plug-in CoreDNS forward, policy spécifie la stratégie à utiliser pour sélectionner des serveurs en amont. Les stratégies sont définies dans le tableau suivant.

Nom de stratégie	Description
`random`	Stratégie qui implémente la sélection aléatoire en amont. Cette stratégie est la stratégie par défaut.
`round_robin`	Stratégie qui sélectionne les hôtes en fonction de l’ordre de tourniquet.
`sequential`	Stratégie qui sélectionne les hôtes en fonction de l’ordre séquentiel.

Si le réseau virtuel AKS contient plusieurs serveurs DNS, les requêtes du nœud AKS peuvent accéder au premier serveur DNS. Toutefois, les requêtes du pod peuvent aller au deuxième serveur DNS.

Cause : Plusieurs destinations pour les requêtes DNS

Si deux serveurs DNS personnalisés sont spécifiés et que le troisième serveur DNS est spécifié en tant que DNS Azure (168.63.129.16), le nœud envoie des demandes au premier serveur DNS personnalisé s’il est en cours d’exécution et accessible. Dans cette configuration, le nœud peut résoudre le domaine personnalisé. Toutefois, certaines des requêtes DNS du pod peuvent être dirigées vers Azure DNS. Cela est dû au fait que CoreDNS peut sélectionner le serveur en amont au hasard. Dans ce scénario, le domaine personnalisé ne peut pas être résolu. Par conséquent, la requête DNS échoue.

Solution : Supprimer Azure DNS des paramètres de réseau virtuel

Nous vous recommandons de ne pas combiner Azure DNS avec des serveurs DNS personnalisés dans les paramètres du réseau virtuel. Si vous souhaitez utiliser les serveurs DNS personnalisés, ajoutez uniquement les serveurs DNS personnalisés dans les paramètres du réseau virtuel. Ensuite, configurez Azure DNS dans les paramètres du redirecteur de vos serveurs DNS personnalisés.

Pour plus d’informations, consultez Résolution de noms utilisant votre propre serveur DNS.

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