Recentemente, lançamos o Kubernetes 1.9 na AWS usando Kops. Ontem, enquanto implementávamos sem problemas o novo tráfego para o maior de nossos clusters Kubernetes, comecei a notar erros incomuns de resolução de nomes DNS registrados por nosso aplicativo.
Há bastante sobre isso no GitHub , então decidi descobrir também. No final, percebi que no nosso caso isso é causado pelo aumento da carga no kube-dns и dnsmasq. O mais interessante e novo para mim foi o motivo do aumento significativo no tráfego de solicitações de DNS. Minha postagem é sobre isso e o que fazer a respeito.
A resolução DNS dentro do contêiner - como em qualquer sistema Linux - é determinada pelo arquivo de configuração /etc/resolv.conf. Kubernetes padrão dnsPolicy это ClusterFirst, o que significa que qualquer solicitação de DNS será encaminhada para dnsmasq, rodando em um pod kube-dns dentro do cluster, que por sua vez encaminhará a solicitação para o aplicativo kube-dns, se o nome terminar com um sufixo de cluster ou, caso contrário, para um servidor DNS de nível superior.
arquivo /etc/resolv.conf dentro de cada contêiner o padrão será assim:
nameserver 100.64.0.10
search namespace.svc.cluster.local svc.cluster.local cluster.local
eu-west-1.compute.internal
options ndots:5Como você pode ver, existem três diretivas:
- O servidor de nomes é o IP do serviço
kube-dns - 4 domínios de pesquisa local especificados
search - Existe uma opção
ndots:5
A parte interessante desta configuração é como os domínios e configurações de pesquisa local ndots:5 se dar bem juntos. Para entender isso, você precisa entender como funciona a resolução DNS para nomes não qualificados.
O que é um nome completo?
Um nome totalmente qualificado é um nome para o qual nenhuma pesquisa local será executada e o nome será considerado absoluto durante a resolução de nomes. Por convenção, o software DNS considera um nome totalmente qualificado se terminar com um ponto (.) e não totalmente qualificado caso contrário. Aquilo é google.com. totalmente definido e google.com - não.
Como um nome não qualificado é tratado?
Quando um aplicativo se conecta ao host remoto especificado no nome, a resolução de nomes DNS normalmente é feita usando uma chamada de sistema, por exemplo. getaddrinfo(). Mas se o nome não for qualificado (não termina com.), Gostaria de saber se a chamada do sistema tentará resolver o nome como um nome absoluto primeiro ou passará primeiro pelos domínios de pesquisa local? Depende da opção ndots.
Do manual resolv.conf:
ndots:n
устанавливает порог для количества точек, которые должны появиться в имени, прежде чем будет сделан начальный абсолютный запрос. Значение по умолчанию для n равно 1, что означает, что если в имени есть какие-либо точки, имя будет сначала опробовано как абсолютное имя, прежде чем к нему будут добавлены какие-либо элементы списка поиска.Isto significa que se por ndots dado um valor 5 e o nome contém menos de 5 pontos, a chamada do sistema tentará resolvê-lo sequencialmente, primeiro percorrendo todos os domínios de pesquisa local e, se não tiver êxito, eventualmente resolvendo-o como um nome absoluto.
Por que mesmo ndots:5 isso poderia impactar negativamente o desempenho do aplicativo?
Como você pode imaginar, se sua aplicação utiliza muito tráfego externo, para cada conexão TCP estabelecida (ou mais precisamente, para cada nome resolvido), ela emitirá 5 consultas DNS antes que o nome seja resolvido corretamente, pois primeiro ela passará 4 domínio de pesquisa local e, ao final, emitirá uma solicitação de resolução de nome absoluto.
O gráfico a seguir mostra o tráfego total em nossos três módulos kube-dns antes e depois de mudarmos os poucos nomes de host configurados em nosso aplicativo para nomes totalmente qualificados.
O diagrama a seguir mostra a latência do aplicativo antes e depois de mudarmos vários nomes de host configurados em nosso aplicativo para nomes completos (a linha azul vertical é a implantação):
Solução nº 1 – Use nomes totalmente qualificados
Se você tiver poucos nomes externos estáticos (ou seja, definidos na configuração do aplicativo) para os quais você cria um grande número de conexões, talvez a solução mais simples seja alterná-los para nomes totalmente qualificados, simplesmente anexando-os. no final.
Esta não é uma solução definitiva, mas ajuda a melhorar a situação de forma rápida, embora não limpa. Aplicamos este patch para resolver nosso problema, cujos resultados foram mostrados nas imagens acima.
Solução nº 2 – personalização ndots в dnsConfig
No Kubernetes 1.9, a funcionalidade apareceu em modo alfa (versão beta v1.10), que permite controlar melhor os parâmetros DNS por meio da propriedade 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