Get best of the week

Recherche DNS dans Kubernetes

Remarque perev. : Le problème DNS dans Kubernetes, ou plutôt les réglages de paramètres ndots, est étonnamment populaire, et ce n'est pas la première année . Dans un autre article sur ce sujet, son auteur, ingénieur DevOps d'une grande société de courtage en Inde, raconte de manière très simple et concise ce qu'il est utile de savoir pour les collègues qui utilisent Kubernetes.



L'un des principaux avantages du déploiement d'applications dans Kubernetes est la découverte transparente des applications. L'interaction intracluster est grandement simplifiée par le concept de service ( Service ), qui est une IP virtuelle, prenant en charge un ensemble d'adresses IP pod'ov. Par exemple, si un servicevanillasouhaite contacter le servicechocolate, il peut accéder directement à l'adresse IP virtuelle pourchocolate. La question se pose: qui dans ce cas résoudra la requête DNS chocolateet comment?

La résolution de noms DNS est configurée dans le cluster Kubernetes à l' aide de CoreDNS . Kubelet enregistre les pods avec CoreDNS comme serveur de noms dans les fichiers de /etc/resolv.conftous les pods. Si vous regardez le contenu d' /etc/resolv.confun pod, il 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 rediriger les demandes vers un serveur DNS. Le fichier resolv.confcontient les informations suivantes:

  • nameserver : le serveur vers lequel les requêtes DNS seront acheminées. Dans notre cas, il s'agit de l'adresse du service CoreDNS;
  • search: . , google.com mrkaran.dev FQDN ( ). , resolver' DNS, (FDQN) , «.», . resolver' . , mrkaran.dev. — (FQDN), mrkaran.dev — ;
  • ndots: ( ). ndots , «» . , DNS-.



Voyons ce qui se passe lorsque nous demandons mrkaran.devdans le pod:

$ 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 très détaillé). 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

Fuh. Deux choses retiennent l'attention ici:

  • La demande passe par toutes les étapes de la recherche jusqu'à ce que la réponse contienne un code NOERROR(les clients DNS le comprennent et le stockent en conséquence). NXDOMAINsignifie qu'aucun enregistrement n'a été trouvé pour ce nom de domaine. Puisqu'il mrkaran.devne s'agit pas d'un nom de domaine complet (selon ndots=5), le résolveur examine le chemin de recherche et détermine l'ordre des requêtes;
  • . , /etc/resolv.conf , IPv4 IPv6. , single-request resolv.conf.

: glibc , musl — , Alpine .

ndots


Essayons un peu plus ndotset voyons comment ce paramètre se comporte. L'idée est simple: elle ndotsdétermine si le client DNS considère le domaine comme absolu ou relatif. Par exemple, comment, dans le cas de Google simple, le client DNS sait-il si ce domaine est absolu? S'il est réglé ndotssur 1, le client dira: «Oh, googleil n'y a pas un seul point; Je vais probablement parcourir toute la liste de recherche. " Cependant, si demandé 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 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: NXDOMAIN

Journaux 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

Puisqu'il n'y a mrkaranpas un seul point, la recherche a été effectuée dans toute la liste des suffixes.

Remarque: en pratique, la valeur maximale est ndotslimitée à 15; Kubernetes est réglé par défaut sur 5.

Application de production


Si une application effectue de nombreux appels réseau externes, DNS peut devenir un goulot d'étranglement en cas de trafic actif, car lors de la résolution d'un nom, de nombreuses requêtes inutiles sont effectuées (avant que le système ne parvienne à la bonne). Les applications n'ajoutent généralement pas de zone racine aux noms de domaine, mais c'est tout 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 invitera les clients DNS à effectuer immédiatement des recherches faisant autorité dans le domaine absolu.

De plus, à partir de la version Kubernetes 1.14, extension dnsConfiget dnsPolicyoctroi du statut d'écurie. Ainsi, lors du déploiement d'un pod, vous pouvez diminuer la valeurndotsdisons jusqu'à 3 (et même jusqu'à 1!). Pour cette raison, chaque message dans le nœud devra inclure un domaine complet. C'est l'un des compromis classiques lorsque vous devez choisir entre performances et portabilité. Il me semble que s'inquiéter de cela n'est nécessaire que si des latences ultra-faibles sont vitales pour votre application, car les résultats DNS sont également mis en cache en interne.

Références


Pour la première fois, j'ai découvert cette fonctionnalité lors du K8s-Meetup du 25 janvier. Il y a eu une discussion, y compris sur ce problème.

Voici quelques liens à approfondir:

  • Explication de la raison pour laquelle ndots = 5 dans Kubernetes;
  • Des trucs formidables sur la façon dont la modification des ndots affecte les performances des applications
  • Écarts entre les résolutions musl et la glibc.

Remarque: j'ai choisi de ne pas utiliser digcet article. digajoute automatiquement un point (identifiant de la zone racine), ce qui rend le domaine «complet» (FQDN), sans d'abord l' exécuter dans la liste de recherche. Il a écrit à ce sujet dans l' une des publications précédentes . Cependant, il est plutôt surprenant qu'en général, un indicateur standard doive être défini pour un comportement standard.

Bon DNS! À plus tard!

PS du traducteur


Lisez aussi dans notre blog:

More articles:


All Articles