Pesquisa de DNS no Kubernetes

Observação. trad.: Problema de DNS no Kubernetes, ou mais precisamente, configurações de parâmetros ndots, é surpreendentemente popular e já Não é o primeiro ano. Em outra nota sobre este tema, seu autor, um engenheiro DevOps de uma grande corretora da Índia, fala de forma muito simples e concisa sobre o que é útil para colegas que operam Kubernetes saberem.

Um dos principais benefícios da implantação de aplicativos no Kubernetes é a descoberta contínua de aplicativos. A interação intra-cluster é bastante simplificada graças ao conceito de serviço (e eficaz), que é um IP virtual que oferece suporte a um conjunto de endereços IP de pod. Por exemplo, se o serviço vanilla deseja entrar em contato com o serviço chocolate, ele pode acessar diretamente o IP virtual para chocolate. Surge a pergunta: quem neste caso resolverá a solicitação de DNS para chocolate e como

A resolução de nomes DNS é configurada em um cluster Kubernetes usando CoreDNS. Kubelet registra um pod com CoreDNS como servidor de nomes em arquivos /etc/resolv.conf todos os pods. Se você olhar o conteúdo /etc/resolv.conf qualquer pod, será parecido com isto:

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

Esta configuração é usada por clientes DNS para encaminhar solicitações ao servidor DNS. No arquivo resolv.conf contém as seguintes informações:

• nome do servidor: servidor para o qual as solicitações DNS serão enviadas. No nosso caso, este é o endereço do serviço CoreDNS;
• search: define o caminho de pesquisa para um domínio específico. É interessante que google.com ou mrkaran.dev não são FQDN (nomes de domínio totalmente qualificados). De acordo com a convenção padrão seguida pela maioria dos resolvedores de DNS, apenas aqueles que terminam com um ponto ".", representando a zona raiz, são considerados domínios totalmente qualificados (FDQN). Alguns resolvedores podem adicionar um ponto sozinhos. Por isso, mrkaran.dev. é o nome de domínio totalmente qualificado (FQDN) e mrkaran.dev - Não;
• pontos: O parâmetro mais interessante (este artigo é sobre isso). ndots especifica o número limite de pontos em um nome de solicitação antes de ser considerado um nome de domínio “totalmente qualificado”. Falaremos mais sobre isso mais tarde, quando analisarmos a sequência de pesquisa de DNS.

Vamos ver o que acontece quando perguntamos mrkaran.dev no 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, defini o nível de registro do CoreDNS como all (o que o torna bastante detalhado). Vejamos os registros do 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

Ufa. Duas coisas chamam sua atenção aqui:

• A solicitação passa por todas as etapas da busca até que a resposta contenha o código NOERROR (Os clientes DNS entendem e armazenam como resultado). NXDOMAIN significa que nenhum registro foi encontrado para o nome de domínio fornecido. Porque o mrkaran.dev não é um nome FQDN (de acordo com ndots=5), o resolvedor analisa o caminho de pesquisa e determina a ordem das solicitações;
• Gravações А и АААА chegar em paralelo. O fato é que solicitações únicas em /etc/resolv.conf Por padrão, eles são configurados de forma que as pesquisas paralelas sejam realizadas usando os protocolos IPv4 e IPv6. Você pode cancelar esse comportamento adicionando a opção single-request в resolv.conf.

Nota: glibc pode ser configurado para enviar essas solicitações sequencialmente e musl - não, então os usuários do Alpine devem tomar nota.

Experimentando com ndots

Vamos experimentar um pouco mais ndots e vamos ver como esse parâmetro se comporta. A ideia é simples: ndots determina se o cliente DNS tratará o domínio como absoluto ou relativo. Por exemplo, no caso de um simples cliente DNS do Google, como saber se esse domínio é absoluto? Se você definir ndots igual a 1, o cliente dirá: "Ah, em google não há um único ponto; Acho que vou percorrer toda a lista de pesquisa.” No entanto, se você perguntar google.com, a lista de sufixos será completamente ignorada porque o nome solicitado atende ao limite ndots (há pelo menos um ponto).

Vamos ter certeza disso:

$ 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 do 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

Desde em mrkaran não há um único ponto, a busca foi feita em toda a lista de sufixos.

Nota: na prática o valor máximo ndots limitado a 15; por padrão no Kubernetes é 5.

Aplicação em produção

Se uma aplicação fizer muitas chamadas de rede externa, o DNS pode se tornar um gargalo no caso de tráfego ativo, já que a resolução de nomes faz muitas consultas desnecessárias (antes que o sistema chegue à correta). Os aplicativos geralmente não adicionam uma zona raiz aos nomes de domínio, mas isso parece um hack. Ou seja, em vez de perguntar api.twitter.com, você pode 'codificá-lo' api.twitter.com. (com um ponto) no aplicativo, o que solicitará que os clientes DNS realizem pesquisas oficiais diretamente no domínio real.

Além disso, a partir da versão 1.14 do Kubernetes, as extensões dnsConfig и dnsPolicy recebeu status estável. Assim, ao implantar um pod, você pode reduzir o valor ndots, digamos, até 3 (e até 1!). Por causa disso, cada mensagem dentro de um nó deverá incluir o domínio completo. Esta é uma das compensações clássicas quando você precisa escolher entre desempenho e portabilidade. Parece-me que você só deve se preocupar com isso se a latência ultrabaixa for vital para o seu aplicativo, já que os resultados do DNS também são armazenados em cache internamente.

referências

Aprendi sobre esse recurso pela primeira vez em Encontro K8s, realizada em 25 de janeiro. Houve uma discussão sobre esse problema, entre outras coisas.

Aqui estão alguns links para uma exploração mais aprofundada:

• Explicação, por que ndots=5 no Kubernetes;
• Great stuff como a alteração do ndots afeta o desempenho do aplicativo;
• Discrepâncias entre resolvedores musl e glibc.

Obs: optei por não usar dig neste artigo. dig adiciona automaticamente um ponto (identificador da zona raiz), tornando o domínio "totalmente qualificado" (FQDN), não executando-o primeiro na lista de pesquisa. Escreveu sobre isso em uma das publicações anteriores. No entanto, é bastante surpreendente que, em geral, um sinalizador separado deva ser especificado para o comportamento padrão.

Feliz DNS! Até mais!

PS do tradutor

Leia também em nosso blog:

• «Calico para networking em Kubernetes: introdução e um pouco de experiência";
• «CoreDNS – servidor DNS para o mundo nativo da nuvem e descoberta de serviços para Kubernetes";
• "Um guia ilustrado para redes em Kubernetes": partes 1 e 2 (modelo de rede, redes sobrepostas), parte 3 (serviços e processamento de tráfego).

Fonte: habr.com