Recherche DNS dans Kubernetes

Note de traduction.: Problème DNS dans Kubernetes, plus précisément — la configuration du paramètre ndots, — étonnamment populaire, en fait déjà pas le premier an. Dans un nouvel article sur ce sujet, l’auteur — un ingénieur DevOps d’une grande société de courtage en Inde — explique de manière très simple et concise ce que les collègues exploitant Kubernetes doivent savoir.

Un des principaux avantages du déploiement d'applications dans Kubernetes est la découverte fluide des applications. L’interaction intra-cluster est grandement simplifiée grâce au concept de service (Service), qui représente une IP virtuelle, supportant un ensemble d’adresses IP des pod. Par exemple, si le service vanilla souhaite se connecter au service chocolate, il peut se référer directement à l’IP virtuelle pour chocolate. La question se pose : qui dans ce cas résoudra la requête DNS à chocolate et comment ?

La résolution des noms DNS est configurée dans le cluster Kubernetes à l’aide de CoreDNS. Kubelet enregistre le pod avec CoreDNS comme serveur de noms dans les fichiers /etc/resolv.conf de tous les pods. Si l’on regarde le contenu de /etc/resolv.conf n’importe quel pod, il ressemblera à peu près à ce qui suit :

search hello.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.152.183.10
options ndots:5

Cette configuration est utilisée par les clients DNS pour rediriger les requêtes vers le serveur DNS. Dans le fichier resolv.conf se trouve les informations suivantes :

• nameserver: le serveur vers lequel seront envoyées les requêtes DNS. Dans notre cas, c’est l’adresse du service CoreDNS ;
• search: définit le chemin de recherche pour un domaine donné. Il est intéressant de noter que google.com ou mrkaran.dev ne sont pas des FQDN (noms de domaine complets). Selon le standard suivi par la plupart des résolveurs DNS, les domaines complets (FQDN) sont ceux qui se terminent par un point « . », représentant la zone racine. Certains résolveurs peuvent ajouter le point automatiquement. Ainsi, mrkaran.dev. est un nom de domaine complet (FQDN), tandis que mrkaran.dev ne l’est pas ;
• ndots: Le paramètre le plus intéressant (cette article porte précisément là-dessus). ndots définit le nombre seuil de points dans le nom de la requête, au-delà duquel il est considéré comme un « nom de domaine » complet. Nous en parlerons plus en détail plus tard, lorsque nous analyserons la séquence de recherche DNS.

Voyons ce qui se passe lorsque nous interrogeons mrkaran.dev dans le pod :

$ nslookup mrkaran.dev
Server: 10.152.183.10
Address: 10.152.183.10#53

Réponse non autorisée :
Nom : mrkaran.dev
Adresse : 157.230.35.153
Nom : mrkaran.dev
Adresse : 2400:6180:0:d1::519:6001

Pour cette expérience, j'ai défini le niveau de journalisation de CoreDNS sur tout (ce qui le rend assez verbeux). Regardons les journaux du pod coredns:

[INFO] 10.1.28.1:35998 - 11131 "A IN mrkaran.dev.hello.svc.cluster.local. udp 53 false 512" NXDOMAIN qr,aa,rd 146 0.000263728s
[INFO] 10.1.28.1:34040 - 36853 "A IN mrkaran.dev.svc.cluster.local. udp 47 false 512" NXDOMAIN qr,aa,rd 140 0.000214201s
[INFO] 10.1.28.1:33468 - 29482 "A IN mrkaran.dev.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000156107s
[INFO] 10.1.28.1:58471 - 45814 "A IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 56 0.110263459s
[INFO] 10.1.28.1:54800 - 2463 "AAAA IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 68 0.145091744s

Ouf. Deux choses ici attirent l'attention :

• La requête passe par toutes les étapes de recherche jusqu'à ce que la réponse contienne le code NOERROR (les clients DNS le comprennent et l'enregistrent comme un résultat). NXDOMAIN indique qu'aucun enregistrement n'a été trouvé pour ce nom de domaine. Puisque mrkaran.dev n'est pas un nom FQDN (conformément à ndots=5), le résolveur examine le chemin de recherche et détermine l'ordre des requêtes ;
• Les enregistrements Un et AAAA sont envoyés en parallèle. En fait, les requêtes uniques dans /etc/resolv.conf sont par défaut configurées pour effectuer une recherche parallèle sur les protocoles IPv4 et IPv6. Ce comportement peut être annulé en ajoutant l'option single-request dans resolv.conf.

Remarque : glibc qui peut être configurée pour envoyer ces requêtes de manière séquentielle, alors que musl — non, donc les utilisateurs d'Alpine devraient en tenir compte.

Expérimentons avec ndots

Faisons encore un peu d'expérimentation avec ndots et voyons comment ce paramètre se comporte. L'idée est simple : ndots détermine si le client DNS considérera le domaine comme absolu ou relatif. Par exemple, comment un simple client DNS Google sait-il si ce domaine est absolu ? En définissant ndots à 1, le client dira : « Oh, dans google il n'y a pas de point ; je vais probablement passer par toute la liste de recherche ». Cependant, si l'on demande google.com, la liste des suffixes sera complètement ignorée, car le nom demandé satisfait le seuil ndots (il y a au moins un point).

Assurons-nous de cela :

$ cat /etc/resolv.conf
options ndots:1
$ nslookup mrkaran
Serveur : 10.152.183.10
Adresse : 10.152.183.10#53

** le serveur ne peut pas trouver mrkaran : NXDOMAIN

Journaux de CoreDNS :

[INFO] 10.1.28.1:52495 - 2606 "A IN mrkaran.hello.svc.cluster.local. udp 49 false 512" NXDOMAIN qr,aa,rd 142 0.000524939s
[INFO] 10.1.28.1:59287 - 57522 "A IN mrkaran.svc.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000368277s
[INFO] 10.1.28.1:53086 - 4863 "A IN mrkaran.cluster.local. udp 39 false 512" NXDOMAIN qr,aa,rd 132 0.000355344s
[INFO] 10.1.28.1:56863 - 41678 "A IN mrkaran. udp 25 false 512" NXDOMAIN qr,rd,ra 100 0.034629206s

Étant donné que dans mrkaran n'a pas de point, la recherche a été effectuée sur toute la liste des suffixes.

Note : dans la pratique, la valeur maximale ndots limité à 15 ; par défaut dans Kubernetes, il est fixé à 5.

Utilisation en production

Si l'application effectue de nombreux appels réseau externes, le DNS peut devenir un goulot d'étranglement en cas de trafic actif, car de nombreuses requêtes inutiles sont effectuées lors de la résolution du nom (avant que le système n'accède à la bonne). Les applications n'ajoutent généralement pas de zone racine aux noms de domaine, mais cela pourrait tout à fait être considéré comme un hack. Autrement dit, au lieu de demander api.twitter.com, vous pouvez 'hardcoder' api.twitter.com. (avec un point) dans l'application, ce qui incitera les clients DNS à effectuer directement une recherche autoritaire dans le domaine absolu.

De plus, à partir de la version 1.14 de Kubernetes, les extensions dnsConfig et dnsPolicy ont atteint un état stable. Ainsi, lors du déploiement d'un pod, vous pouvez réduire la valeur ndots, disons, à 3 (voire à 1 !). De ce fait, chaque message à l'intérieur du nœud devra inclure le domaine complet. C'est l'un des compromis classiques, lorsqu'il faut choisir entre performance et portabilité. Il me semble que cela ne mérite de s'inquiéter que si des latences extrêmement faibles sont cruciales pour votre application, car les résultats DNS sont également mis en cache en interne.

Liens

J'ai entendu parler de cette fonctionnalité pour la première fois lors de K8s-meetup, qui a eu lieu le 25 janvier. On y a parlé, entre autres, de ce problème.

Voici quelques liens pour approfondir :

• L'explication, pourquoi ndots=5 dans Kubernetes ;
• Un excellent article sur la façon dont le changement de ndots affecte les performances de l'application ;
• Les divergences entre les résolveurs musl et glibc.

Remarque : J'ai préféré ne pas utiliser dig dans cet article. dig ajoute automatiquement un point (identifiant de la zone racine), rendant le domaine 'complet' (FQDN), ne le passant d'abord par la liste de recherche. J'en ai parlé dans l'un de mes articles précédents. Néanmoins, il est assez surprenant que, globalement, un drapeau distinct doive être défini pour un comportement standard.

Bonne DNS ! À bientôt !

P.S. de l'auteur

Lisez aussi dans notre blog :

• «Calico pour le réseau dans Kubernetes : introduction et quelques expériences»;
• «CoreDNS — serveur DNS pour le monde cloud natif et Service Discovery pour Kubernetes»;
• « Guide illustré sur la mise en réseau dans Kubernetes » : parties 1 et 2 (modèle réseau, réseaux superposés), partie 3 (services et traitement du trafic).

Source : habr.com