Noter. trad.: problème DNS dans Kubernetes, ou plus précisément, paramétrage ndots, est étonnamment populaire, et déjà . Dans une autre note sur ce sujet, son auteur, un ingénieur DevOps d'une grande société de courtage en Inde, explique de manière très simple et concise ce qu'il est utile de savoir aux collègues exploitant de Kubernetes.
L'un des principaux avantages du déploiement d'applications sur Kubernetes est la découverte transparente des applications. L'interaction intra-cluster est grandement simplifiée grâce au concept de service (), qui est une adresse IP virtuelle prenant en charge un ensemble d'adresses IP de pod. Par exemple, si le service vanilla souhaite contacter le service chocolate, il peut accéder directement à l'adresse IP virtuelle pour chocolate. La question se pose : qui dans ce cas résoudra la requête DNS pour chocolate et comment
La résolution de noms DNS est configurée sur un cluster Kubernetes à l'aide . Kubelet enregistre un pod avec CoreDNS en tant que serveur de noms dans les fichiers /etc/resolv.conf toutes les dosettes. Si vous regardez le contenu /etc/resolv.conf n'importe quel pod, cela ressemblera à ceci :
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 transmettre les requêtes au serveur DNS. Dans le fichier resolv.conf contient les informations suivantes :
- nom du serveur: serveur vers lequel les requêtes DNS seront envoyées. Dans notre cas, il s'agit de l'adresse du service CoreDNS ;
- recherche: Définit le chemin de recherche pour un domaine spécifique. C'est intéressant ça
google.comoumrkaran.devne sont pas des noms de domaine complets (). Selon la convention standard suivie par la plupart des résolveurs DNS, seuls ceux qui se terminent par un point ".", représentant la zone racine, sont considérés comme des domaines pleinement qualifiés (FDQN). Certains résolveurs peuvent ajouter eux-mêmes un point. Ainsi,mrkaran.dev.est le nom de domaine pleinement qualifié (FQDN), etmrkaran.dev- non; - points: Le paramètre le plus intéressant (cet article en parle).
ndotsspécifie le nombre seuil de points dans un nom de demande avant qu'il ne soit considéré comme un nom de domaine « pleinement qualifié ». Nous en reparlerons plus tard lorsque nous analyserons la séquence de recherche DNS.
Voyons ce qui se passe lorsque nous demandons mrkaran.dev en capsule :
$ nslookup mrkaran.dev
Server: 10.152.183.10
Address: 10.152.183.10#53
Non-authoritative answer:
Name: mrkaran.dev
Address: 157.230.35.153
Name: mrkaran.dev
Address: 2400:6180:0:d1::519:6001
Pour cette expérience, j'ai défini le niveau de journalisation CoreDNS sur all (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.145091744sPhew. Deux choses retiennent votre attention ici :
- La requête passe par toutes les étapes de la recherche jusqu'à ce que la réponse contienne le code
NOERROR(Les clients DNS le comprennent et le stockent en conséquence).NXDOMAINsignifie qu'aucun enregistrement n'a été trouvé pour le nom de domaine donné. Parce que lemrkaran.devn'est pas un nom FQDN (selonndots=5), le résolveur examine le chemin de recherche et détermine l'ordre des requêtes ; - Entrées
АиААААarrivent en parallèle. Le fait est que les demandes ponctuelles en/etc/resolv.confPar défaut, ils sont configurés de manière à ce que les recherches parallèles soient effectuées à l'aide des protocoles IPv4 et IPv6. Vous pouvez annuler ce comportement en ajoutant l'optionsingle-requestвresolv.conf.
Note: glibc peut être configuré pour envoyer ces demandes de manière séquentielle, et musl - non, les utilisateurs d'Alpine devraient donc en prendre note.
Expérimenter avec ndots
Expérimentons un peu plus avec ndots et voyons comment se comporte ce paramètre. L'idée est simple : ndots détermine si le client DNS traitera le domaine comme absolu ou relatif. Par exemple, dans le cas d’un simple client DNS Google, comment sait-il si ce domaine est absolu ? Si vous définissez ndots égal à 1, le client dira : "Oh, dans google il n’y a pas un seul point ; Je suppose que je vais parcourir toute la liste de recherche. Cependant, si vous demandez google.com, la liste des suffixes sera complètement ignorée car le nom demandé atteint le seuil ndots (il y a au moins un point).
Assurons-nous de ceci :
$ cat /etc/resolv.conf
options ndots:1
$ nslookup mrkaran
Server: 10.152.183.10
Address: 10.152.183.10#53
** server can't find mrkaran: NXDOMAINJournaux 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
Depuis en mrkaran il n'y a pas un seul point, la recherche a été effectuée sur toute la liste des suffixes.
Remarque : en pratique la valeur maximale ndots limité à 15 ; par défaut dans Kubernetes, c'est 5.
Application en production
Si une application effectue de nombreux appels réseau externes, le DNS peut devenir un goulot d'étranglement en cas de trafic actif, car la résolution de noms effectue de nombreuses requêtes inutiles (avant que le système n'arrive à la bonne). Les applications n'ajoutent généralement pas de zone racine aux noms de domaine, mais cela ressemble à un hack. Autrement dit, au lieu de demander api.twitter.com, vous pouvez coder en dur api.twitter.com. (avec un point) dans l'application, ce qui incitera les clients DNS à effectuer des recherches faisant autorité directement sur le domaine absolu.
De plus, à partir de Kubernetes version 1.14, les extensions dnsConfig и dnsPolicy a reçu un statut stable. Ainsi, lors du déploiement d'un pod, vous pouvez réduire la valeur ndots, disons, jusqu'à 3 (et même jusqu'à 1 !). Pour cette raison, chaque message au sein d'un nœud devra inclure le domaine complet. C’est l’un des compromis classiques lorsqu’il faut choisir entre performances et portabilité. Il me semble que vous ne devriez vous en préoccuper que si une latence ultra-faible est vitale pour votre application, puisque les résultats DNS sont également mis en cache en interne.
références
J'ai découvert cette fonctionnalité pour la première fois sur , tenu le 25 janvier. Il y a eu une discussion sur ce problème, entre autres.
Voici quelques liens pour une exploration plus approfondie :
- , pourquoi ndots=5 dans Kubernetes ;
- comment la modification des ndots affecte les performances des applications ;
- entre les résolveurs musl et glibc.
Remarque : j'ai choisi de ne pas utiliser dig dans cet article. dig ajoute automatiquement un point (identifiant de zone racine), rendant le domaine « pleinement qualifié » (FQDN), aucun en l'exécutant d'abord dans la liste de recherche. J'ai écrit à ce sujet dans . Cependant, il est assez surprenant qu'en général, un indicateur distinct doive être spécifié pour le comportement standard.
Bon DNS ! À plus tard!
PS du traducteur
A lire aussi sur notre blog :
- «";
- «";
- "Un guide illustré de la mise en réseau dans Kubernetes" : , .
Source: habr.com