No hace mucho tiempo, lanzamos Kubernetes 1.9 en AWS usando Kops. Ayer, mientras desplegaba sin problemas el nuevo tráfico al mayor de nuestros grupos de Kubernetes, comencé a notar errores inusuales de resolución de nombres DNS registrados por nuestra aplicación.
GitHub habló sobre esto durante bastante tiempo, así que también decidí resolverlo. Al final, me di cuenta de que en nuestro caso esto se debe al aumento de la carga en kube-dns y dnsmasq . Lo más interesante y nuevo para mí fue la razón de un aumento significativo en el tráfico de consultas DNS. Sobre esto y qué hacer con él, mi publicación.
La resolución del DNS dentro del contenedor, como con cualquier sistema Linux, está determinada por el archivo de configuración /etc/resolv.conf . De manera predeterminada, Kubernetes dnsPolicy es ClusterFirst , lo que significa que cualquier consulta DNS se redirigirá a dnsmasq ejecute en la kube-dns dentro del clúster, lo que a su vez redirigirá la consulta a la aplicación kube-dns si el nombre termina con un sufijo de clúster, o de lo contrario, a un servidor DNS de nivel superior.
El archivo /etc/resolv.conf dentro de cada contenedor se verá así por defecto:
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:
- El servidor de nombres es el servicio IP de
kube-dns - 4 dominios de búsqueda locales especificados
- Hay una opción
ndots:5
Una parte interesante de esta configuración es cómo los dominios de búsqueda locales y ndots:5 configuraciones se llevan bien. Para comprender esto, debe comprender cómo funciona la resolución DNS para nombres parciales.
Cual es el nombre completo?
Un nombre completo es un nombre para el que no se realizará ninguna búsqueda local, y el nombre se considerará absoluto durante la resolución del nombre. Por convención, el software DNS considera que un nombre está completamente calificado si termina con un punto (.), Y no está completamente definido de otra manera. Eso es google.com. completamente definido, pero google.com no.
¿Cómo se maneja un nombre incompleto?
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, por ejemplo, getaddrinfo() . Pero si el nombre está incompleto (no termina con.), Me pregunto si la llamada al sistema intentará resolver el nombre como absoluto primero, o si primero pasará por los dominios de búsqueda locales. Depende de la opción ndots .
Del manual en resolv.conf :
ndots:n , , . n 1, , - , , - .
Esto significa que si ndots se establece en 5 y el nombre contiene menos de 5 puntos, la llamada del sistema intentará resolverlo secuencialmente, primero revisando todos los dominios de búsqueda locales y, si no tiene éxito, eventualmente lo resolverá como un nombre absoluto.
¿Por qué ndots:5 puede afectar negativamente el rendimiento de la aplicación?
Como comprenderá, si su aplicación usa mucho tráfico externo, para cada conexión TCP establecida (o, más precisamente, para cada nombre resuelto), emitirá 5 consultas DNS antes de que el nombre se resuelva correctamente, ya que pasará primero por 4 dominio de búsqueda local, y al final emitirá una solicitud de resolución de nombre absoluta.
El siguiente diagrama muestra el tráfico total en nuestros 3 módulos kube-dns antes y después de cambiar varios nombres de host configurados en nuestra aplicación a nombres completamente definidos.
El siguiente diagrama muestra el retraso de la aplicación antes y después de cambiar varios nombres de host configurados en nuestra aplicación (la línea azul vertical es la implementación):
Solución n. ° 1: utilice nombres completos
Si tiene pocos nombres externos estáticos (es decir, definidos en la configuración de la aplicación) para los que crea una gran cantidad de conexiones, quizás la solución más simple es cambiarlos a otros completamente definidos simplemente agregándolos. al final
Esta no es una decisión final, pero ayuda a mejorar la situación rápidamente, aunque no limpiamente. Aplicamos este parche para resolver nuestro problema, cuyos resultados se mostraron en las capturas de pantalla anteriores.
Solución n. ° 2: personalización de ndots en dnsConfig
En Kubernetes 1.9, apareció una función en modo alfa (versión beta v1.10), que permite un mejor control de los parámetros DNS a través de la propiedad pod en dnsConfig . Entre otras cosas, le permite ajustar el valor de ndots para un hogar 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: