🥇/etc/resolv.conf para os pods de Kubernetes, opción ndots:5, como isto pode afectar negativamente o rendemento da aplicación

Recentemente lanzamos Kubernetes 1.9 en AWS usando Kops. Onte, mentres distribuía sen problemas novo tráfico ao maior dos nosos clústeres de Kubernetes, comecei a notar erros pouco habituais de resolución de nomes DNS rexistrados pola nosa aplicación.

Hai moito sobre isto en GitHub falou, así que decidín descubrilo tamén. Ao final, decateime de que no noso caso isto é causado polo aumento da carga kube-dns и dnsmasq. O máis interesante e novo para min foi o motivo mesmo do aumento significativo do tráfico de solicitudes de DNS. A miña publicación trata sobre isto e que facer ao respecto.

A resolución DNS dentro do contedor, como en calquera sistema Linux, está determinada polo ficheiro de configuración /etc/resolv.conf. Kubernetes predeterminado dnsPolicy este ClusterFirst, o que significa que se reenviará a calquera solicitude de DNS dnsmasq, correndo nunha vaina kube-dns dentro do clúster, que á súa vez remitirá a solicitude á aplicación kube-dns, se o nome remata cun sufixo de clúster ou, en caso contrario, a un servidor DNS de nivel superior.

arquivo /etc/resolv.conf dentro de cada contenedor o aspecto predeterminado será así:

nameserver 100.64.0.10
search namespace.svc.cluster.local svc.cluster.local cluster.local 
eu-west-1.compute.internal
options ndots:5

Como podes ver, hai tres directivas:

O servidor de nomes é a IP do servizo kube-dns
4 dominios de busca local especificados search
Hai unha opción ndots:5

A parte interesante desta configuración é como os dominios de busca local e a configuración ndots:5 levarse ben xuntos. Para entendelo, cómpre comprender como funciona a resolución DNS para nomes non cualificados.

Que é un nome completo?

Un nome totalmente cualificado é un nome para o que non se realizará ningunha busca local e o nome considerarase absoluto durante a resolución de nomes. Por convención, o software DNS considera que un nome está totalmente cualificado se remata cun punto (.), e non está totalmente cualificado en caso contrario. É dicir google.com. totalmente definido e google.com - non.

Como se trata un nome sen cualificación?

Cando unha aplicación se conecta ao host remoto especificado no nome, a resolución do nome DNS adoita facerse mediante unha chamada ao sistema, p. ex. getaddrinfo(). Pero se o nome non está cualificado (non remata con .), pregúntome se a chamada do sistema tentará resolver primeiro o nome como un nome absoluto ou se pasará primeiro polos dominios de busca local? Depende da opción ndots.

Do manual resolv.conf:

ndots:n

устанавливает порог для количества точек, которые должны появиться в имени, прежде чем будет сделан начальный абсолютный запрос. Значение по умолчанию для n равно 1, что означает, что если в имени есть какие-либо точки, имя будет сначала опробовано как абсолютное имя, прежде чем к нему будут добавлены какие-либо элементы списка поиска.

Isto significa que se para ndots dado un valor de 5 e o nome contén menos de 5 puntos, a chamada do sistema tentará resolvelo secuencialmente, primeiro atravesando todos os dominios de busca local e, se non ten éxito, eventualmente resolvendoo como un nome absoluto.

Por que entón `ndots:5` podería afectar negativamente o rendemento da aplicación?

Como podes imaxinar, se a túa aplicación usa moito tráfico externo, por cada conexión TCP establecida (ou máis exactamente, por cada nome resolto), emitirá 5 consultas DNS antes de que o nome se resolva correctamente, porque primeiro pasará por 4 dominio de busca local, e ao final emitirá unha solicitude de resolución de nome absoluto.

O seguinte gráfico mostra o tráfico total dos nosos 3 módulos kube-dns antes e despois de cambiar os poucos nomes de host configurados na nosa aplicación por outros totalmente cualificados.

O seguinte diagrama mostra a latencia da aplicación antes e despois de cambiar varios nomes de host configurados na nosa aplicación a nomes completos (a liña azul vertical é o despregamento):

Solución n.º 1: use nomes totalmente cualificados

Se tes poucos nomes externos estáticos (é dicir, definidos na configuración da aplicación) aos que creas un gran número de conexións, quizais a solución máis sinxela sexa cambialos a outros totalmente cualificados simplemente engadíndoos. ao final.

Esta non é unha solución definitiva, pero axuda a mellorar a situación rapidamente, aínda que non de forma limpa. Aplicamos este parche para resolver o noso problema, cuxos resultados se mostraron nas capturas de pantalla anteriores.

Solución #2: personalización `ndots` в `dnsConfig`

En Kubernetes 1.9, a funcionalidade apareceu en modo alfa (versión beta v1.10), o que lle permite controlar mellor os parámetros DNS a través da propiedade do pod en dnsConfig. Entre outras cousas, permítelle configurar o valor ndots para unha vaina específica, i.e.

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: dns-example
spec:
  containers:
    - name: test
      image: nginx
  dnsConfig:
    options:
      - name: ndots
        value: "1"

Fontes

Lea tamén outros artigos no noso blog:

Fonte: www.habr.com

/etc/resolv.conf para os pods de Kubernetes, opción ndots:5, como isto pode afectar negativamente o rendemento da aplicación