Busca de DNS en Kubernetes

Nota. transl.: problema de DNS en Kubernetes, ou máis precisamente, a configuración dos parámetros ndots, é sorprendentemente popular, e xa Non primeiro ano. Noutra nota sobre este tema, o seu autor, un enxeñeiro de DevOps dunha gran empresa de corretaxe da India, fala dun xeito moi sinxelo e conciso sobre o que é útil para que coñezan os compañeiros que operan Kubernetes.

Un dos principais beneficios da implantación de aplicacións en Kubernetes é o descubrimento de aplicacións sen problemas. A interacción dentro do clúster simplifícase moito grazas ao concepto de servizo (servizo), que é unha IP virtual que admite un conxunto de enderezos IP de pod. Por exemplo, se o servizo vanilla desexa contactar co servizo chocolate, pode acceder directamente á IP virtual para chocolate. Xorde a pregunta: a quen neste caso resolverá a solicitude de DNS chocolate E como?

A resolución de nomes DNS configúrase nun clúster de Kubernetes mediante CoreDNS. Kubelet rexistra un pod con CoreDNS como servidor de nomes en ficheiros /etc/resolv.conf todas as vainas. Se miras o contido /etc/resolv.conf calquera pod, terá un aspecto así:

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

Esta configuración é utilizada polos clientes DNS para reenviar solicitudes ao servidor DNS. En arquivo resolv.conf contén a seguinte información:

• servidor de nomes: servidor ao que se enviarán as solicitudes de DNS. No noso caso, este é o enderezo do servizo CoreDNS;
• busca: define a ruta de busca dun dominio específico. É interesante iso google.com ou mrkaran.dev non son FQDN (nomes de dominio totalmente cualificados). Segundo a convención estándar que seguen a maioría dos resolvedores de DNS, só se consideran dominios totalmente cualificados (FDQN) os que rematan cun punto ".", que representa a zona raíz. Algúns resolvedores poden engadir un punto eles mesmos. Así, mrkaran.dev. é o nome de dominio totalmente cualificado (FQDN) e mrkaran.dev - Non;
• ndots: O parámetro máis interesante (este artigo trata sobre el). ndots especifica o número límite de puntos nun nome de solicitude antes de que se considere un nome de dominio "completamente cualificado". Falaremos máis sobre isto máis tarde cando analicemos a secuencia de busca de DNS.

A ver que pasa cando preguntemos mrkaran.dev en 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, configurei o nivel de rexistro de CoreDNS en all (o que o fai bastante prolixo). Vexamos os rexistros da vaina 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í chaman a atención dúas cousas:

• A solicitude pasa por todas as fases da busca ata que a resposta contén o código NOERROR (Os clientes DNS enténdeno e gárdano como resultado). NXDOMAIN significa que non se atopou ningún rexistro para o nome de dominio indicado. Porque o mrkaran.dev non é un nome de FQDN (segundo ndots=5), o resolutor mira o camiño de busca e determina a orde das solicitudes;
• Publicacións А и АААА chegar en paralelo. O caso é que as solicitudes únicas entran /etc/resolv.conf Por defecto, están configurados de forma que se realicen buscas paralelas mediante os protocolos IPv4 e IPv6. Pode cancelar este comportamento engadindo a opción single-request в resolv.conf.

Nota: glibc pódese configurar para enviar estas solicitudes secuencialmente, e musl - non, polo que os usuarios de Alpine deberían tomar nota.

Experimentando con ndots

Imos experimentar un pouco máis ndots e vexamos como se comporta este parámetro. A idea é sinxela: ndots determina se o cliente DNS tratará o dominio como absoluto ou relativo. Por exemplo, no caso dun simple cliente DNS de Google, como sabe se este dominio é absoluto? Se estableces ndots igual a 1, o cliente dirá: "Oh, dentro google non hai un só punto; Supoño que pasarei por toda a lista de buscas". Porén, se pregunta google.com, a lista de sufixos ignorarase por completo porque o nome solicitado cumpre o limiar ndots (hai polo menos un punto).

Asegurémonos disto:

$ 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

Rexistros 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

Dende en mrkaran non hai un só punto, a busca realizouse en toda a lista de sufixos.

Nota: na práctica o valor máximo ndots limitado a 15; por defecto en Kubernetes é 5.

Aplicación na produción

Se unha aplicación realiza moitas chamadas de rede externas, o DNS pode converterse nun pescozo de botella no caso de tráfico activo, xa que a resolución de nomes fai moitas consultas innecesarias (antes de que o sistema chegue á correcta). As aplicacións normalmente non engaden unha zona raíz aos nomes de dominio, pero isto parece un truco. É dicir, en vez de preguntar api.twitter.com, pode codificar api.twitter.com. (cun punto) na aplicación, o que pedirá aos clientes DNS que realicen buscas autorizadas directamente no dominio absoluto.

Ademais, comezando coa versión 1.14 de Kubernetes, as extensións dnsConfig и dnsPolicy recibiu un estado estable. Así, ao despregar un pod, pode reducir o valor ndots, digamos, ata 3 (e ata 1!). Debido a isto, cada mensaxe dentro dun nodo terá que incluír o dominio completo. Este é un dos compromisos clásicos cando tes que escoller entre rendemento e portabilidade. Paréceme que só debes preocuparte por isto se a latencia ultra baixa é vital para a túa aplicación, xa que os resultados do DNS tamén se almacenan na caché internamente.

referencias

Aprendín por primeira vez sobre esta función en Encontro K8s, celebrada o 25 de xaneiro. Houbo unha discusión sobre este problema, entre outras cousas.

Aquí tes algúns enlaces para máis exploración:

• Explicación, por que ndots=5 en Kubernetes;
• Cousas estupendas como o cambio de ndots afecta o rendemento da aplicación;
• Discrepancias entre os resolutores musl e glibc.

Nota: optei por non usar dig neste artigo. dig engade automaticamente un punto (identificador de zona raíz), facendo que o dominio sexa "completamente cualificado" (FQDN), non primeiro executándoo a través da lista de busca. Escribiu sobre isto en unha das publicacións anteriores. Non obstante, é bastante sorprendente que, en xeral, teña que especificarse unha bandeira separada para o comportamento estándar.

Feliz DNSing! Ata despois!

PS do tradutor

Lea tamén no noso blog:

• «Calico para networking en Kubernetes: introdución e un pouco de experiencia»;
• «CoreDNS: servidor DNS para o mundo nativo da nube e Service Discovery para Kubernetes»;
• "Unha guía ilustrada de redes en Kubernetes": partes 1 e 2 (modelo de rede, redes superpostas), parte 3 (servizos e procesamento de tráfico).

Fonte: www.habr.com