{"id":37372,"date":"2019-10-31T22:17:16","date_gmt":"2019-10-31T19:17:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/etc-resolv-conf-dlya-kubernetes-pods-optsiya-ndots-5-kak-eto-mozhet-negativno-skazatsya-na-proizvoditelnosti-prilozheniya\/"},"modified":"2019-10-31T22:17:16","modified_gmt":"2019-10-31T19:17:16","slug":"etc-resolv-conf-dlya-kubernetes-pods-optsiya-ndots-5-kak-eto-mozhet-negativno-skazatsya-na-proizvoditelnosti-prilozheniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/etc-resolv-conf-dlya-kubernetes-pods-optsiya-ndots-5-kak-eto-mozhet-negativno-skazatsya-na-proizvoditelnosti-prilozheniya","title":{"rendered":"\/etc\/resolv.conf \u0434\u043b\u044f Kubernetes pods, \u043e\u043f\u0446\u0438\u044f ndots:5, \u043a\u0430\u043a \u044d\u0442\u043e \u043c\u043e\u0436\u0435\u0442 \u043d\u0435\u0433\u0430\u0442\u0438\u0432\u043d\u043e \u0441\u043a\u0430\u0437\u0430\u0442\u044c\u0441\u044f \u043d\u0430 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"\/etc\/resolv.conf<\/p>\n

<\/p>\n

N\u00e3o faz muito tempo, lan\u00e7amos o Kubernetes 1.9 na AWS usando o Kops. Ontem, durante a implementa\u00e7\u00e3o suave de um novo tr\u00e1fego no maior dos nossos clusters Kubernetes, comecei a notar erros incomuns de resolu\u00e7\u00e3o de nomes DNS registrados pelo nosso aplicativo.<\/p>\n

<\/a><\/noindex><\/p>\n

No GitHub, isso foi discutido por um bom tempo por isso eu tamb\u00e9m decidi investigar. No final, percebi que, no nosso caso, isso \u00e9 causado pela alta carga em<\/a><\/noindex>. O mais interessante e novo para mim foi a pr\u00f3pria raz\u00e3o do aumento significativo no tr\u00e1fego de consultas DNS. Sobre isso e o que fazer a respeito, \u00e9 o que o meu post aborda. kube-dns<\/code> e dnsmasq<\/code>A resolu\u00e7\u00e3o de DNS dentro do cont\u00eainer \u2014 assim como em qualquer sistema Linux \u2014 \u00e9 determinada pelo arquivo de configura\u00e7\u00e3o<\/p>\n

<\/p>\n

. Por padr\u00e3o, o Kubernetes \/etc\/resolv.conf<\/code>ClusterFirst dnsPolicy<\/code> isso , o que significa que qualquer consulta DNS ser\u00e1 redirecionada para<\/code>, executado em um pod dnsmasq<\/code>dentro do cluster, que, por sua vez, redirecionar\u00e1 a consulta para o aplicativo kube-dns<\/code> , se o nome termina com o sufixo do cluster, ou, caso contr\u00e1rio, para um servidor DNS de n\u00edvel superior. kube-dns<\/code>Dentro de cada cont\u00eainer, por padr\u00e3o, parecer\u00e1 assim:<\/p>\n

<\/p>\n

Arquivo \/etc\/resolv.conf<\/code> nameserver 100.64.0.10\nsearch namespace.svc.cluster.local svc.cluster.local cluster.local \neu-west-1.compute.internal\noptions ndots:5<\/p>\n

<\/p>\n

Como pode ser observado, aqui est\u00e3o tr\u00eas diretrizes:<\/code><\/pre>\n
<\/p>\n
O servidor de nomes \u00e9 o IP do servi\u00e7o<\/p>\n
<\/p>\n
    \n
  1. Foram especificados 4 dom\u00ednios locais de busca kube-dns<\/code><\/li>\n
  2. H\u00e1 a op\u00e7\u00e3o search<\/code><\/li>\n
  3. ndots:5 Uma parte interessante dessa configura\u00e7\u00e3o \u00e9 como os dom\u00ednios locais de busca e as configura\u00e7\u00f5es<\/code><\/li>\n<\/ol>\n
    <\/p>\n
    vivem juntos. Para entender isso, \u00e9 necess\u00e1rio descobrir como a resolu\u00e7\u00e3o de DNS funciona para nomes incompletos. Uma parte interessante dessa configura\u00e7\u00e3o \u00e9 como os dom\u00ednios locais de busca e as configura\u00e7\u00f5es<\/code> O que \u00e9 um nome completo?<\/p>\n
    <\/p>\n
    Um nome totalmente qualificado \u00e9 aquele para o qual n\u00e3o ser\u00e1 feito um busca local, e o nome ser\u00e1 considerado absoluto durante a resolu\u00e7\u00e3o de nomes. Por conven\u00e7\u00e3o, um software DNS considera um nome totalmente qualificado se ele termina com um ponto (.), e n\u00e3o totalmente qualificado caso contr\u00e1rio. Ou seja,<\/h3>\n
    <\/p>\n
    est\u00e1 totalmente qualificado, enquanto google.com.<\/code> n\u00e3o est\u00e1. google.com<\/code> Como um nome incompleto \u00e9 tratado? <\/p>\n
    <\/p>\n
    Quando um aplicativo se conecta a um host remoto especificado pelo nome, a resolu\u00e7\u00e3o de nomes DNS \u00e9 geralmente realizada atrav\u00e9s de uma chamada de sistema, como<\/h3>\n
    <\/p>\n
    getaddrinfo() . Mas se o nome for incompleto (n\u00e3o termina em .), \u00e9 interessante saber se a chamada de sistema tentar\u00e1 primeiro resolver o nome como absoluto ou se primeiro passar\u00e1 pelos dom\u00ednios locais de busca. Isso depende da op\u00e7\u00e3o<\/code>Do manual sobre ndots<\/code>.<\/p>\n
    <\/p>\n
    Do manual sobre resolv.conf<\/code>:<\/p>\n
    <\/p>\n
    ndots:n\n\ndefine o limite para a quantidade de pontos que devem aparecer no nome antes que uma consulta absoluta inicial seja realizada. O valor padr\u00e3o para n \u00e9 1, o que significa que se houver pontos no nome, o nome ser\u00e1 primeiro testado como um nome absoluto, antes que qualquer elemento da lista de busca seja adicionado.<\/code><\/pre>\n
    <\/p>\n
    Isso significa que se ndots<\/code> um valor de 5 for definido e o nome contiver menos de 5 pontos, a chamada do sistema tentar\u00e1 resolv\u00ea-lo sequencialmente, primeiro passando por todos os dom\u00ednios locais de busca e, em caso de falha, no final, resolver\u00e1 como um nome absoluto.<\/p>\n
    <\/p>\n
    Por que isso Uma parte interessante dessa configura\u00e7\u00e3o \u00e9 como os dom\u00ednios locais de busca e as configura\u00e7\u00f5es<\/code> pode impactar negativamente no desempenho do aplicativo?<\/h3>\n
    <\/p>\n
    Como voc\u00ea pode entender, se seu aplicativo usa muito tr\u00e1fego externo, para cada conex\u00e3o TCP estabelecida (ou, mais precisamente, para cada nome resolvido), ele emitir\u00e1 5 consultas DNS antes que o nome seja corretamente resolvido, porque passar\u00e1 primeiro por 4 dom\u00ednios locais de busca antes de emitir a consulta para resolver o nome absoluto.<\/p>\n
    <\/p>\n
    No pr\u00f3ximo diagrama, o tr\u00e1fego total em nossos 3 m\u00f3dulos kube-dns \u00e9 mostrado antes e depois que mudamos alguns nomes de host configurados em nosso aplicativo para totalmente qualificados.<\/p>\n
    <\/p>\n
    \"\/etc\/resolv.conf<\/p>\n
    <\/p>\n
    No pr\u00f3ximo diagrama, a lat\u00eancia do aplicativo \u00e9 mostrada antes e depois de mudarmos alguns nomes de host configurados em nosso aplicativo para qualificados (a linha azul vertical representa o deploy):<\/p>\n
    <\/p>\n
    \"\/etc\/resolv.conf<\/p>\n
    <\/p>\n
    Solu\u00e7\u00e3o #1 \u2014 usar nomes totalmente qualificados<\/h3>\n
    <\/p>\n
    Se voc\u00ea tiver poucos nomes externos est\u00e1ticos (ou seja, definidos na configura\u00e7\u00e3o do aplicativo) para os quais est\u00e1 fazendo uma grande quantidade de conex\u00f5es, talvez a solu\u00e7\u00e3o mais simples seja mud\u00e1-los para totalmente qualificados, simplesmente adicionando. no final.<\/p>\n
    <\/p>\n
    Esta n\u00e3o \u00e9 uma solu\u00e7\u00e3o definitiva, mas ajuda a melhorar rapidamente, mesmo que n\u00e3o perfeitamente, a situa\u00e7\u00e3o. Este patch aplicamos para resolver nosso problema, cujos resultados foram mostrados nas capturas de tela acima.<\/p>\n
    <\/p>\n
    Solu\u00e7\u00e3o #2 \u2014 personaliza\u00e7\u00e3o ndots<\/code> em dnsConfig<\/code><\/h3>\n
    <\/p>\n
    No Kubernetes 1.9, uma funcionalidade em modo alfa foi introduzida (beta v1.10), que permite um melhor controle dos par\u00e2metros DNS atrav\u00e9s da propriedade do pod em dnsConfig<\/code>. Entre outras coisas, permite configurar o valor ndots<\/code> para um pod espec\u00edfico, ou seja.<\/p>\n
    <\/p>\n
    apiVersion: v1\nkind: Pod\nmetadata:\n  namespace: default\n  name: dns-example\nspec:\n  containers:\n    - name: test\n      image: nginx\n  dnsConfig:\n    options:\n      - name: ndots\n        value: \"1\"<\/code><\/pre>\n
    <\/p>\n
    Fontes<\/h3>\n
    <\/p>\n