/etc/resolv.conf para pods de Kubernetes, opción ndots:5, cómo esto puede afectar negativamente al rendimiento de la aplicación

/etc/resolv.conf para pods de Kubernetes, opción ndots:5, cómo esto puede afectar negativamente al rendimiento de la aplicación

Recientemente lanzamos Kubernetes 1.9 en AWS usando Kops. Ayer, mientras implementaba sin problemas tráfico nuevo en el mayor de nuestros clústeres de Kubernetes, comencé a notar errores inusuales en la resolución de nombres DNS registrados por nuestra aplicación.

Hay mucho sobre esto en GitHub. hablado, así que decidí resolverlo también. Al final, me di cuenta de que en nuestro caso esto se debe al aumento de carga en kube-dns и dnsmasq. Lo más interesante y nuevo para mí fue la razón misma del aumento significativo en el tráfico de solicitudes de DNS. Mi publicación trata sobre esto y qué hacer al respecto.

La resolución de DNS dentro del contenedor, como en cualquier sistema Linux, está determinada por el archivo de configuración. /etc/resolv.conf. Kubernetes predeterminado dnsPolicy это ClusterFirst, lo que significa que cualquier solicitud de DNS se reenviará a dnsmasq, corriendo en una cápsula kube-dns dentro del clúster, que a su vez reenviará la solicitud a la aplicación kube-dns, si el nombre termina con un sufijo de clúster o, en caso contrario, a un servidor DNS de nivel superior.

Expediente /etc/resolv.conf Dentro de cada contenedor, el valor predeterminado se verá 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 puede ver, hay tres directivas:

  1. El servidor de nombres es la IP del servicio. kube-dns
  2. 4 dominios de búsqueda locales especificados search
  3. Hay una opción ndots:5

La parte interesante de esta configuración es cómo los dominios y configuraciones de búsqueda local ndots:5 llevarse bien. Para comprender esto, debe comprender cómo funciona la resolución DNS para nombres no calificados.

¿Qué es un nombre completo?

Un nombre completo es un nombre para el cual no se realizará ninguna búsqueda local y el nombre se considerará absoluto durante la resolución de nombres. Por convención, el software DNS considera que un nombre está completamente calificado si termina con un punto (.), y no completamente calificado en caso contrario. Eso es google.com. completamente definido y google.com no

¿Cómo se maneja un nombre no calificado?

Cuando una aplicación se conecta al host remoto especificado en el nombre, la resolución del nombre DNS generalmente se realiza mediante una llamada al sistema, p. getaddrinfo(). Pero si el nombre no está calificado (no termina en .), me pregunto si la llamada al sistema intentará resolver el nombre como un nombre absoluto primero o si pasará primero por los dominios de búsqueda locales. Depende de la opción ndots.

Del manual resolv.conf:

ndots:n

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

Esto significa que si por ndots dado un valor de 5 y el nombre contiene menos de 5 puntos, la llamada al sistema intentará resolverlo secuencialmente, primero atravesando todos los dominios de búsqueda locales y, si no tiene éxito, eventualmente resolviendolo como un nombre absoluto.

Porque igual ndots:5 ¿Podría afectar negativamente al rendimiento de la aplicación?

Como puede imaginar, si su aplicación utiliza mucho tráfico externo, por cada conexión TCP establecida (o más exactamente, por cada nombre resuelto), emitirá 5 consultas DNS antes de que el nombre se resuelva correctamente, porque primero pasará por 4 dominio de búsqueda local, y al final emitirá una solicitud de resolución de nombre absoluto.

El siguiente cuadro muestra el tráfico total en nuestros 3 módulos kube-dns antes y después de cambiar los pocos nombres de host configurados en nuestra aplicación por nombres completamente calificados.

/etc/resolv.conf para pods de Kubernetes, opción ndots:5, cómo esto puede afectar negativamente al rendimiento de la aplicación

El siguiente diagrama muestra la latencia de la aplicación antes y después de cambiar varios nombres de host configurados en nuestra aplicación a nombres completos (la línea azul vertical es la implementación):

/etc/resolv.conf para pods de Kubernetes, opción ndots:5, cómo esto puede afectar negativamente al rendimiento de la aplicación

Solución n.º 1: utilizar nombres completos

Si tiene pocos nombres externos estáticos (es decir, definidos en la configuración de la aplicación) para los cuales crea una gran cantidad de conexiones, quizás la solución más sencilla sea cambiarlos por nombres completos simplemente agregándolos. al final.

Esta no es una solución definitiva, pero ayuda a mejorar la situación de forma rápida, aunque no limpia. Aplicamos este parche para resolver nuestro problema, cuyos resultados se muestran en las capturas de pantalla anteriores.

Solución n.º 2: personalización ndots в dnsConfig

En Kubernetes 1.9, la funcionalidad apareció en modo alfa (versión beta v1.10), lo que le permite controlar mejor los parámetros DNS a través de la propiedad pod en dnsConfig. Entre otras cosas, te permite configurar el valor. ndots para un grupo específico, es decir

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

fuentes

Lea también otros artículos en nuestro blog:

Fuente: habr.com

Añadir un comentario