Résoudre les problèmes de résolution DNS à l’intérieur du pod, mais pas à partir du nœud Worker

Article
08/25/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 Microsoft Azure Kubernetes Service (AKS).

Conditions préalables

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 .

Contexte

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

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

Les serveurs DNS amont sont obtenus en fonction du fichier resolv.conf du nœud Worker dans lequel le pod s’exécute. 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 pour la résolution des problèmes

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

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

Vous pouvez utiliser les 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 surexploités :

$ 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 surexploités. 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

Remarque

Pour afficher plus d’informations de 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 avez accès au pod.
Exécutez les commandes suivantes pour installer les packages requis :
```
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 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 amont serveur DNS à partir du pod pour déterminer si 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 amont est explicitement spécifié

Si les requêtes DNS des pods fonctionnent lorsque vous spécifiez explicitement le serveur DNS 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 de kube-system noms.
Vérifiez si les pods CoreDNS se trouvent sur un pool de nœuds différent (pool de nœuds système). Si tel est le cas, case activée 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, case activée 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 des 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 les 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. Procédez comme suit :
  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 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 requête 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 du programme de résolution les interroge dans l’ordre indiqué. (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 à amont serveurs DNS. Ce plug-in utilise un algorithme aléatoire pour sélectionner le serveur DNS amont. Dans cette séquence, la requête peut être envoyée à 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 CoreDNSforward, policy spécifie la stratégie à utiliser pour sélectionner amont serveurs. Les stratégies sont définies dans le tableau suivant.

Nom de la stratégie	Description
`random`	Stratégie qui implémente la sélection aléatoire 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 du tourniquet( round robin).
`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 être envoyées au premier serveur DNS. Toutefois, les demandes du pod peuvent être envoyées 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é comme Azure DNS (168.63.129.16), le nœud envoie des requêtes 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 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 de 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 de redirecteur de vos serveurs DNS personnalisés.

Pour plus d’informations, consultez Résolution de noms qui utilise 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 être modifiées 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