¿Cuándo se convierte el DNS de contenedores en un cuello de botella para un servidor doméstico?

El DNS de contenedores se convierte en un cuello de botella para el servidor doméstico cuando la latencia de búsqueda, la multiplicación de consultas o la falla del resolvedor consumen más tiempo que la propia solicitud del servicio local.

Los contenedores a menudo resuelven nombres de servicio a través de un proxy DNS integrado antes de que las consultas lleguen a un resolvedor del host o ascendente. Ese camino extra normalmente es rápido. Se vuelve visible cuando las aplicaciones abren muchas conexiones cortas, los dominios de búsqueda generan variantes fallidas, el caché es débil o un resolvedor local sirve a todos los contenedores y dispositivos del hogar.

El contenedor añade una ruta de resolvedor para el descubrimiento de servicios

En una red definida por el usuario, un resolvedor integrado puede mapear nombres y alias de contenedores, y luego reenviar nombres desconocidos hacia arriba. Una guía del DNS integrado de Docker rastrea esta decisión entre local y reenviado. El diseño permite que los servicios se muevan sin direcciones IP codificadas, pero también hace que la resolución de nombres sea parte de cada configuración de conexión no almacenada en caché.

Por lo tanto, el host y el contenedor pueden mostrar resultados diferentes. El host puede consultar su resolvedor directamente mientras el contenedor pasa por el proxy de tiempo de ejecución, un puente y configuraciones de resolvedor heredadas. Probar solo el host puede pasar por alto la capa lenta.

Los dominios de búsqueda pueden convertir un nombre en varias consultas

Un nombre corto como database puede probarse con uno o más sufijos de búsqueda antes de que el resolvedor lo intente como un nombre absoluto. La regla ndots afecta ese orden. Configuraciones incorrectas o demasiado amplias de búsqueda pueden crear varias consultas negativas por cada resultado exitoso.

La guía de solución de problemas de DNS en contenedores de Netdata identifica ndots y dominios de búsqueda como causas de inicios lentos y búsquedas bloqueantes. Este es un riesgo dependiente de la configuración, no una razón para forzar un valor ndots en todos los entornos.

Las conexiones de corta duración multiplican el costo de búsqueda

Una aplicación que reutiliza una conexión de base de datos o HTTP resuelve el nombre con menos frecuencia. Un verificador de salud, trabajador o cliente con agrupación deficiente puede crear una conexión nueva para cada tarea. Incluso un retraso modesto en DNS entonces se sitúa repetidamente en el camino crítico.

Un caso real de DNS en contenedor versus host muestra búsquedas en contenedor de varios segundos mientras las consultas del host permanecían rápidas. Un informe separado de latencia del DNS integrado registra el mismo contraste diagnóstico, convirtiéndolo en una división útil inicial antes de culpar a la aplicación.

El caché ayuda solo dentro de su TTL y alcance

El caché DNS almacena una respuesta hasta que su tiempo de vida (TTL) expira, reduciendo el volumen de consultas y el retraso de inicio. La explicación del caché DNS describe cómo las respuestas almacenadas reducen el trabajo en la red, pero los entornos de ejecución de contenedores, aplicaciones y resolvedores locales pueden tener comportamientos de caché diferentes.

Un caché no es una cura universal. TTL muy cortos, registros de servicio que cambian frecuentemente, búsquedas negativas y comportamiento de resolvedor por proceso pueden mantener altas las tasas de consulta. Un caché local fallido o sobrecargado también se convierte en una dependencia compartida para cada servicio que apunta a él.

El DNS es el cuello de botella solo antes de que la conexión comience

Mida el tiempo de búsqueda por separado de la conexión TCP, negociación TLS, primer byte y respuesta de la aplicación. Si la resolución de nombres es rápida pero la solicitud es lenta, cambiar de resolvedor no solucionará el servicio. Si el acceso por IP directa es rápido y el acceso por nombre se detiene, inspeccione la ruta del resolvedor del contenedor y la secuencia de consultas.

Un análisis de latencia DNS en servidores domésticos establece ese límite temporal. Su explicación de la latencia de puentes virtuales ayuda a separar el DNS de la ruta de paquetes que sigue a la resolución.

Preguntas frecuentes

¿Por qué el DNS es rápido en el host pero lento dentro de un contenedor?

El contenedor puede usar un resolvedor integrado, diferentes dominios de búsqueda, servidores DNS heredados o un espacio de nombres de red separado. Compare archivos de resolvedor y consultas temporizadas desde ambas ubicaciones.

¿Deberían los contenedores usar DNS público para nombres de servicios locales?

No. Los resolvedores públicos no conocen alias privados de contenedores. Use el descubrimiento de servicios del tiempo de ejecución o un resolvedor local autorizado, con reenvío confiable para nombres externos.

¿Puede el caché DNS romper el descubrimiento de servicios en contenedores?

Las respuestas obsoletas pueden retrasar el reconocimiento de una dirección de servicio cambiada hasta que expire el TTL. La política de caché debe equilibrar la reducción de consultas con la rapidez con que cambia el entorno.