Búsqueda de DNS en Kubernetes

Nota. traducir: Problema de DNS en Kubernetes, o más precisamente, configuración de parámetros ndots, es sorprendentemente popular y ya no el primero año. En otra nota sobre este tema, su autor, un ingeniero de DevOps de una gran empresa de corretaje de la India, habla de manera muy sencilla y concisa sobre lo que es útil que sepan los colegas que operan Kubernetes.

Uno de los principales beneficios de implementar aplicaciones en Kubernetes es el descubrimiento perfecto de aplicaciones. La interacción dentro del clúster se simplifica enormemente gracias al concepto de servicio (Service), que es una IP virtual que admite un conjunto de direcciones IP de pod. Por ejemplo, si el servicio vanilla desea contactar con el servicio chocolate, puede acceder directamente a la IP virtual para chocolate. Surge la pregunta: ¿quién en este caso resolverá la solicitud de DNS a chocolate y como

La resolución de nombres DNS se configura en un clúster de Kubernetes usando Núcleo de DNS. Kubelet registra un pod con CoreDNS como servidor de nombres en archivos /etc/resolv.conf todas las vainas. Si miras el contenido /etc/resolv.conf cualquier pod, se verá 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 reenviar solicitudes al servidor DNS. En archivo resolv.conf contiene la siguiente información:

• nombre del servidor: servidor al que se enviarán las solicitudes DNS. En nuestro caso, esta es la dirección del servicio CoreDNS;
• Buscar: Define la ruta de búsqueda para un dominio específico. Es interesante que google.com o mrkaran.dev no son FQDN (nombres de dominio completos). Según la convención estándar que siguen la mayoría de los solucionadores de DNS, sólo aquellos que terminan con un punto ".", que representa la zona raíz, se consideran dominios totalmente calificados (FDQN). Algunos solucionadores pueden agregar un punto ellos mismos. De este modo, mrkaran.dev. es el nombre de dominio completo (FQDN), y mrkaran.dev - No;
• puntos: El parámetro más interesante (este artículo trata sobre ello). ndots especifica el número umbral de puntos en un nombre de solicitud antes de que se considere un nombre de dominio "totalmente calificado". Hablaremos más sobre esto más adelante cuando analicemos la secuencia de búsqueda de DNS.

A ver qué pasa cuando preguntamos. mrkaran.dev en vaina:

$ 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 bastante detallado). Miremos 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

Uf. Aquí te llaman la atención dos cosas:

• La solicitud pasa por todas las etapas de la búsqueda hasta que la respuesta contiene el código. NOERROR (Los clientes DNS lo entienden y lo almacenan como resultado). NXDOMAIN significa que no se encontró ningún registro para el nombre de dominio dado. Porque el mrkaran.dev no es un nombre FQDN (según ndots=5), el solucionador mira la ruta de búsqueda y determina el orden de las solicitudes;
• Grabaciones А и АААА llegar en paralelo. El hecho es que las solicitudes únicas en /etc/resolv.conf Por defecto están configurados de tal forma que se realizan búsquedas paralelas utilizando los protocolos IPv4 e IPv6. Puede cancelar este comportamiento agregando la opción single-request в resolv.conf.

Nota: glibc se puede configurar para enviar estas solicitudes de forma secuencial, y musl - No, entonces los usuarios de Alpine deberían tomar nota.

Experimentando con ndots

Experimentemos un poco más con ndots y veamos cómo se comporta este parámetro. La idea es simple: ndots determina si el cliente DNS tratará el dominio como absoluto o relativo. Por ejemplo, en el caso de un simple cliente DNS de Google, ¿cómo sabe si este dominio es absoluto? si estableces ndots igual a 1, el cliente dirá: "Oh, en google no hay un solo punto; Supongo que revisaré toda la lista de búsqueda”. Sin embargo, si preguntas google.com, la lista de sufijos se ignorará por completo porque el nombre solicitado cumple 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

Ya que en mrkaran no hay un solo punto, la búsqueda se realizó en toda la lista de sufijos.

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

Aplicación en producción

Si una aplicación realiza muchas llamadas a la red externa, DNS puede convertirse en un cuello de botella en el caso de tráfico activo, ya que la resolución de nombres genera muchas consultas innecesarias (antes de que el sistema llegue a la correcta). Las aplicaciones normalmente no agregan una zona raíz a los nombres de dominio, pero esto suena como un truco. Es decir, en lugar de preguntar api.twitter.com, puedes 'codificarlo' api.twitter.com. (con un punto) en la aplicación, lo que solicitará a los clientes DNS que realicen búsquedas autorizadas directamente en el dominio absoluto.

Además, a partir de la versión 1.14 de Kubernetes, las extensiones dnsConfig и dnsPolicy recibió estatus estable. Por lo tanto, al implementar un pod, puede reducir el valor ndots, digamos, hasta 3 (¡e incluso hasta 1!). Debido a esto, cada mensaje dentro de un nodo deberá incluir el dominio completo. Esta es una de las clásicas compensaciones cuando hay que elegir entre rendimiento y portabilidad. Me parece que sólo debería preocuparse por esto si una latencia ultrabaja es vital para su aplicación, ya que los resultados de DNS también se almacenan en caché internamente.

referencias

Me enteré por primera vez de esta función en reunión de k8s, celebrado el 25 de enero. Hubo una discusión sobre este problema, entre otras cosas.

Aquí hay algunos enlaces para una mayor exploración:

• Explicación, por qué ndots=5 en Kubernetes;
• Grandes cosas cómo el cambio de ndots afecta el rendimiento de la aplicación;
• Discrepancias entre resolutores musl y glibc.

Nota: elegí no usar dig en este artículo. dig agrega automáticamente un punto (identificador de zona raíz), lo que hace que el dominio esté "completamente calificado" (FQDN), no ejecutándolo primero a través de la lista de búsqueda. Escribí sobre esto en una de las publicaciones anteriores. Sin embargo, es bastante sorprendente que, en general, se deba especificar una bandera separada para el comportamiento estándar.

¡Feliz DNS! ¡Hasta luego!

PD del traductor

Lea también en nuestro blog:

• «Calico para networking en Kubernetes: introducción y una pequeña experiencia";
• «CoreDNS: servidor DNS para el mundo nativo de la nube y Service Discovery para Kubernetes";
• "Una guía ilustrada para la creación de redes en Kubernetes": partes 1 y 2 (modelo de red, redes superpuestas), parte 3 (servicios y procesamiento de tráfico).

Fuente: habr.com