{"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\/es\/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

No hace mucho tiempo lanzamos Kubernetes 1.9 en AWS utilizando Kops. Ayer, durante el rollout suave de nuevo tr\u00e1fico en uno de nuestros cl\u00fasteres de Kubernetes m\u00e1s grandes, comenc\u00e9 a notar errores inusuales de resoluci\u00f3n de nombres DNS registrados por nuestra aplicaci\u00f3n.<\/p>\n

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

En GitHub se ha hablado de esto durante bastante tiempo, as\u00ed que decid\u00ed inspeccionarlo tambi\u00e9n.<\/a><\/noindex>Al final entend\u00ed que en nuestro caso esto se debe a una carga incrementada en kube-dns<\/code> y dnsmasq<\/code>. Lo m\u00e1s interesante y novedoso para m\u00ed fue la misma raz\u00f3n del aumento significativo en el tr\u00e1fico de consultas DNS. De esto y de qu\u00e9 hacer al respecto, trata mi publicaci\u00f3n.<\/p>\n

<\/p>\n

La resoluci\u00f3n de DNS dentro de un contenedor, al igual que en cualquier sistema Linux, se determina por un archivo de configuraci\u00f3n \/etc\/resolv.conf<\/code>. Por defecto, Kubernetes dnsPolicy<\/code> este ClusterFirst<\/code>, lo que significa que cualquier consulta DNS se redirigir\u00e1 a dnsmasq<\/code>, que se ejecuta en un pod kube-dns<\/code> dentro del cl\u00faster, que a su vez redirigir\u00e1 la consulta a la aplicaci\u00f3n kube-dns<\/code>, si el nombre termina con el sufijo del cl\u00faster, o de lo contrario, al servidor DNS de nivel superior.<\/p>\n

<\/p>\n

Archivo \/etc\/resolv.conf<\/code> Dentro de cada contenedor por defecto se ver\u00e1 as\u00ed:<\/p>\n

<\/p>\n

nameserver 100.64.0.10\nsearch namespace.svc.cluster.local svc.cluster.local cluster.local \neu-west-1.compute.internal\noptions ndots:5<\/code><\/pre>\n
<\/p>\n
Como se puede observar, hay tres directivas:<\/p>\n
<\/p>\n
    \n
  1. El servidor de nombres es la IP del servicio, kube-dns<\/code><\/li>\n
  2. Se especifican 4 dominios de b\u00fasqueda locales, search<\/code><\/li>\n
  3. Hay una opci\u00f3n ndots:5<\/code><\/li>\n<\/ol>\n
    <\/p>\n
    Una parte interesante de esta configuraci\u00f3n es c\u00f3mo los dominios de b\u00fasqueda locales y las configuraciones ndots:5<\/code> conviven. Para entender esto, es necesario desentra\u00f1ar c\u00f3mo funciona la resoluci\u00f3n DNS para nombres incompletos.<\/p>\n
    <\/p>\n
    \u00bfQu\u00e9 es un nombre completo?<\/h3>\n
    <\/p>\n
    Un nombre completamente definido es aquel para el cual no se realizar\u00e1 una b\u00fasqueda local, y su nombre se considerar\u00e1 absoluto durante la resoluci\u00f3n de nombres. Por convenci\u00f3n, el software DNS considera que un nombre est\u00e1 completamente definido si termina con un punto (.), y no completamente definido de lo contrario. Es decir, google.com.<\/code> est\u00e1 completamente definido, mientras que google.com<\/code> no lo est\u00e1. <\/p>\n
    <\/p>\n
    \u00bfC\u00f3mo se maneja un nombre incompleto?<\/h3>\n
    <\/p>\n
    Cuando una aplicaci\u00f3n se conecta a un host remoto especificado en el nombre, la resoluci\u00f3n de nombres DNS generalmente se realiza mediante una llamada al sistema, como getaddrinfo()<\/code>. Sin embargo, si el nombre es incompleto (no termina en .), resulta interesante si la llamada al sistema intentar\u00e1 resolver el nombre como absoluto primero, o si pasar\u00e1 primero por los dominios de b\u00fasqueda locales. Esto depende de la opci\u00f3n ndots<\/code>.<\/p>\n
    <\/p>\n
    Seg\u00fan el manual de resolv.conf<\/code>:<\/p>\n
    <\/p>\n
    ndots:n\n\nestablece el umbral para la cantidad de puntos que deben aparecer en el nombre antes de que se realice la primera consulta absoluta. El valor predeterminado para n es 1, lo que significa que si el nombre tiene alg\u00fan punto, el nombre se probar\u00e1 primero como un nombre absoluto antes de que se le agreguen elementos de la lista de b\u00fasqueda.<\/code><\/pre>\n
    <\/p>\n
    Esto significa que si ndots<\/code> se establece en 5 y el nombre contiene menos de 5 puntos, la llamada del sistema intentar\u00e1 resolverlo secuencialmente, pasando primero por todos los dominios de b\u00fasqueda locales y, en caso de falla, finalmente lo resolver\u00e1 como un nombre absoluto.<\/p>\n
    <\/p>\n
    \u00bfPor qu\u00e9 podr\u00eda ndots:5<\/code> afectar negativamente el rendimiento de la aplicaci\u00f3n?<\/h3>\n
    <\/p>\n
    Como comprender\u00e1s, si tu aplicaci\u00f3n utiliza mucho tr\u00e1fico externo, por cada conexi\u00f3n TCP establecida (o, m\u00e1s precisamente, por cada nombre resuelto) generar\u00e1 5 consultas DNS antes de que el nombre se resuelva correctamente, ya que primero pasar\u00e1 por 4 dominios de b\u00fasqueda locales y al final realizar\u00e1 una consulta de resoluci\u00f3n del nombre absoluto.<\/p>\n
    <\/p>\n
    En el siguiente gr\u00e1fico se muestra el tr\u00e1fico total en nuestros 3 m\u00f3dulos kube-dns antes y despu\u00e9s de que cambiamos varios nombres de host configurados en nuestra aplicaci\u00f3n a nombres completamente calificados.<\/p>\n
    <\/p>\n
    \"\/etc\/resolv.conf<\/p>\n
    <\/p>\n
    En el siguiente gr\u00e1fico se muestra la latencia de la aplicaci\u00f3n antes y despu\u00e9s de que cambiamos varios nombres de host configurados en nuestra aplicaci\u00f3n a nombres completos (la l\u00ednea azul vertical indica el despliegue):<\/p>\n
    <\/p>\n
    \"\/etc\/resolv.conf<\/p>\n
    <\/p>\n
    Soluci\u00f3n #1: usar nombres completamente calificados<\/h3>\n
    <\/p>\n
    Si tienes pocos nombres est\u00e1ticos externos (es decir, definidos en la configuraci\u00f3n de la aplicaci\u00f3n) a los que realizas un gran n\u00famero de conexiones, posiblemente la soluci\u00f3n m\u00e1s sencilla sea cambiar a nombres completamente calificados, simplemente a\u00f1adiendo. al final.<\/p>\n
    <\/p>\n
    No es una soluci\u00f3n definitiva, pero ayuda a mejorar la situaci\u00f3n r\u00e1pidamente, aunque no de manera limpia. Este parche lo aplicamos para resolver nuestro problema, cuyos resultados se mostraron en las capturas de pantalla anteriores.<\/p>\n
    <\/p>\n
    Soluci\u00f3n #2: personalizaci\u00f3n ndots<\/code> en dnsConfig<\/code><\/h3>\n
    <\/p>\n
    En Kubernetes 1.9 se introdujo en modo alfa una funcionalidad (versi\u00f3n beta v1.10) que permite un mejor control de los par\u00e1metros DNS a trav\u00e9s de la propiedad del pod en dnsConfig<\/code>. Entre otras cosas, permite configurar el valor ndots<\/code> para un pod espec\u00edfico, es decir.<\/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
    Fuentes<\/h3>\n
    <\/p>\n