Não faz muito tempo, lançamos o Kubernetes 1.9 na AWS usando o Kops. Ontem, durante a implementação suave de um novo tráfego no maior dos nossos clusters Kubernetes, comecei a notar erros incomuns de resolução de nomes DNS registrados pelo nosso aplicativo.
No GitHub, isso foi discutido por um bom tempo . O mais interessante e novo para mim foi a própria razão do aumento significativo no tráfego de consultas DNS. Sobre isso e o que fazer a respeito, é o que o meu post aborda. kube-dns e dnsmasqA resolução de DNS dentro do contêiner — assim como em qualquer sistema Linux — é determinada pelo arquivo de configuração
. Por padrão, o Kubernetes /etc/resolv.confClusterFirst dnsPolicy isso , o que significa que qualquer consulta DNS será redirecionada para, executado em um pod dnsmasqdentro do cluster, que, por sua vez, redirecionará a consulta para o aplicativo kube-dns , se o nome termina com o sufixo do cluster, ou, caso contrário, para um servidor DNS de nível superior. kube-dnsDentro de cada contêiner, por padrão, parecerá assim:
Arquivo /etc/resolv.conf nameserver 100.64.0.10 search namespace.svc.cluster.local svc.cluster.local cluster.local eu-west-1.compute.internal options ndots:5
Como pode ser observado, aqui estão três diretrizes:O servidor de nomes é o IP do serviço
- Foram especificados 4 domínios locais de busca
kube-dns - Há a opção
search - ndots:5
Uma parte interessante dessa configuração é como os domínios locais de busca e as configurações
vivem juntos. Para entender isso, é necessário descobrir como a resolução de DNS funciona para nomes incompletos. Uma parte interessante dessa configuração é como os domínios locais de busca e as configurações O que é um nome completo?
Um nome totalmente qualificado é aquele para o qual não será feito um busca local, e o nome será considerado absoluto durante a resolução de nomes. Por convenção, um software DNS considera um nome totalmente qualificado se ele termina com um ponto (.), e não totalmente qualificado caso contrário. Ou seja,
está totalmente qualificado, enquanto google.com. não está. google.com Como um nome incompleto é tratado?
Quando um aplicativo se conecta a um host remoto especificado pelo nome, a resolução de nomes DNS é geralmente realizada através de uma chamada de sistema, como
getaddrinfo() . Mas se o nome for incompleto (não termina em .), é interessante saber se a chamada de sistema tentará primeiro resolver o nome como absoluto ou se primeiro passará pelos domínios locais de busca. Isso depende da opçãoDo manual sobre ndots.
Do manual sobre resolv.conf:
ndots:n
define o limite para a quantidade de pontos que devem aparecer no nome antes que uma consulta absoluta inicial seja realizada. O valor padrão para n é 1, o que significa que se houver pontos no nome, o nome será primeiro testado como um nome absoluto, antes que qualquer elemento da lista de busca seja adicionado.Isso significa que se ndots um valor de 5 for definido e o nome contiver menos de 5 pontos, a chamada do sistema tentará resolvê-lo sequencialmente, primeiro passando por todos os domínios locais de busca e, em caso de falha, no final, resolverá como um nome absoluto.
Por que isso Uma parte interessante dessa configuração é como os domínios locais de busca e as configurações pode impactar negativamente no desempenho do aplicativo?
Como você pode entender, se seu aplicativo usa muito tráfego externo, para cada conexão TCP estabelecida (ou, mais precisamente, para cada nome resolvido), ele emitirá 5 consultas DNS antes que o nome seja corretamente resolvido, porque passará primeiro por 4 domínios locais de busca antes de emitir a consulta para resolver o nome absoluto.
No próximo diagrama, o tráfego total em nossos 3 módulos kube-dns é mostrado antes e depois que mudamos alguns nomes de host configurados em nosso aplicativo para totalmente qualificados.
No próximo diagrama, a latência do aplicativo é mostrada antes e depois de mudarmos alguns nomes de host configurados em nosso aplicativo para qualificados (a linha azul vertical representa o deploy):
Solução #1 — usar nomes totalmente qualificados
Se você tiver poucos nomes externos estáticos (ou seja, definidos na configuração do aplicativo) para os quais está fazendo uma grande quantidade de conexões, talvez a solução mais simples seja mudá-los para totalmente qualificados, simplesmente adicionando. no final.
Esta não é uma solução definitiva, mas ajuda a melhorar rapidamente, mesmo que não perfeitamente, a situação. Este patch aplicamos para resolver nosso problema, cujos resultados foram mostrados nas capturas de tela acima.
Solução #2 — personalização ndots em dnsConfig
No Kubernetes 1.9, uma funcionalidade em modo alfa foi introduzida (beta v1.10), que permite um melhor controle dos parâmetros DNS através da propriedade do pod em dnsConfig. Entre outras coisas, permite configurar o valor ndots para um pod específico, ou seja.
apiVersion: v1
kind: Pod
metadata:
namespace: default
name: dns-example
spec:
containers:
- name: test
image: nginx
dnsConfig:
options:
- name: ndots
value: "1"Fontes
Leia também outros artigos em nosso blog:
Fonte: habr.com
