Get best of the week

Búsqueda de DNS en Kubernetes

Nota perev. : El problema de DNS en Kubernetes, o más bien, la configuración de parámetros ndots, es sorprendentemente popular, y este no es el primer año . En otro artículo sobre este tema, su autor, ingeniero DevOps de una gran empresa de corretaje en la India, cuenta de manera muy simple y concisa lo que es útil saber para los colegas que usan Kubernetes.



Una de las principales ventajas de implementar aplicaciones en Kubernetes es el descubrimiento continuo de aplicaciones. La interacción entre los clústeres se simplifica enormemente por el concepto de servicio ( Servicio ), que es una IP virtual, que admite un conjunto de direcciones IP de pod'ov. Por ejemplo, si un serviciovanilladesea ponerse en contacto con el serviciochocolate, puede acceder a la IP virtual directamente parachocolate. Surge la pregunta: ¿quién en este caso resolverá la consulta DNS chocolatey cómo?

La resolución del nombre DNS se configura en el clúster de Kubernetes mediante CoreDNS . Kubelet registra pods con CoreDNS como el servidor de nombres en los archivos de /etc/resolv.conftodos los pods. Si observa el contenido de /etc/resolv.confcualquier pod, se verá más o menos así:

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

Los clientes DNS utilizan esta configuración para redirigir las solicitudes a un servidor DNS. El archivo resolv.confcontiene la siguiente información:

  • servidor de nombres : el servidor al que se enrutarán las consultas DNS. En nuestro caso, esta es la dirección del servicio CoreDNS;
  • search: . , google.com mrkaran.dev FQDN ( ). , resolver' DNS, (FDQN) , «.», . resolver' . , mrkaran.dev. — (FQDN), mrkaran.dev — ;
  • ndots: ( ). ndots , «» . , DNS-.



Veamos qué sucede cuando solicitamos mrkaran.deven 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

Para este experimento, configuré el nivel de registro de CoreDNS en all(lo que lo hace muy detallado). Veamos los registros del 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 Dos cosas llaman la atención aquí:

  • La solicitud pasa por todas las etapas de la búsqueda hasta que la respuesta contiene un código NOERROR(los clientes DNS lo entienden y lo almacenan como resultado). NXDOMAINsignifica que no se encontró ningún registro para este nombre de dominio. Como mrkaran.devno es un nombre de FQDN (según ndots=5), el solucionador mira la ruta de búsqueda y determina el orden de las consultas;
  • . , /etc/resolv.conf , IPv4 IPv6. , single-request resolv.conf.

: glibc , musl — , Alpine .

ndots


Experimentemos un poco más ndotsy veamos cómo se comporta este parámetro. La idea es simple: ndotsdetermina si el cliente DNS considera el dominio absoluto o relativo. Por ejemplo, ¿cómo, en el caso de Google simple, el cliente DNS sabe si este dominio es absoluto? Si se establece ndotsen 1, el cliente dirá: “Oh, googleno hay un solo punto; Probablemente revisaré toda la lista de búsqueda ". Sin embargo, si se solicita google.com, la lista de sufijos se ignorará por completo, porque el nombre solicitado satisface el umbral ndots(hay al menos un punto).

Asegurémonos de esto:

$ 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

Registros 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

Como no hay mrkaranun solo punto, la búsqueda se realizó en toda la lista de sufijos.

Nota: en la práctica, el valor máximo está ndotslimitado a 15; Kubernetes por defecto es 5.

Aplicación de producción


Si la aplicación realiza muchas llamadas de red externas, el DNS puede convertirse en un cuello de botella en caso de tráfico activo, porque al resolver un nombre, se realizan muchas consultas innecesarias (antes de que el sistema llegue a la correcta). Las aplicaciones generalmente no agregan una zona raíz a los nombres de dominio, sin embargo, esto es un gran truco. Es decir, en lugar de preguntar api.twitter.com, puede codificar api.twitter.com.(con un punto ) en la aplicación, lo que solicitará a los clientes DNS que realicen búsquedas autorizadas de inmediato en el dominio absoluto.

Por otra parte, comenzando con la versión Kubernetes 1,14, extensión dnsConfigy dnsPolicyconcedió el estado de un establo. Por lo tanto, al implementar un pod, puede disminuir el valorndots, digamos, hasta 3 (¡e incluso hasta 1!). Debido a esto, cada mensaje dentro del nodo tendrá que incluir un dominio completo. Este es uno de los compromisos clásicos cuando tienes que elegir entre rendimiento y portabilidad. Me parece que preocuparse por esto solo es necesario si las latencias ultrabajas son vitales para su aplicación, ya que los resultados de DNS también se almacenan en caché internamente.

Referencias


Por primera vez me enteré de esta función en la reunión de K8 el 25 de enero. Hubo una discusión allí, incluso sobre este problema.

Aquí hay algunos enlaces para estudios posteriores:


Nota: Elegí no usar digeste artículo. digagrega automáticamente un punto (identificador de zona raíz), haciendo que el dominio esté "lleno" (FQDN), sin ejecutarlo primero en la lista de búsqueda. Escribió sobre esto en una de las publicaciones anteriores . Sin embargo, es bastante sorprendente que, en general, se deba establecer un indicador estándar para el comportamiento estándar.

¡Buen DNS! ¡Nos vemos más tarde!

PD del traductor


Lea también en nuestro blog:

More articles:


All Articles