Encontrar la latencia oculta en el DNS de Kubernetes
Separar el tiempo de búsqueda DNS del tiempo de conexión TCP reveló por qué una API saludable seguía disparando alertas de latencia.
La mejora de aproximadamente 9× describe la búsqueda DNS medida, no cada solicitud de la API ni una garantía de nivel de servicio sostenida.
Contribución de un vistazo
- Mi responsabilidad
- Diagnóstico capa por capa, una configuración de DNS compartida en Helm y validación del rollout escalonado.
- Alcance
- Medición de DNS en producción y verificaciones de renderizado en ocho combinaciones de aplicación/entorno.
- Colaboración y límites
- Cambié la configuración compartida de deployment después de separar el overhead de DNS del tiempo de conexión a la base de datos.
- Resultado
- La búsqueda DNS p50 pasó de ~18.7 ms a 2.06 ms en la medición registrada; esto no es una aceleración de 9× de la API.
Un servicio saludable con una señal de latencia inestable
La API tenía pods saludables, uso de recursos normal y ningún error 5xx observado, pero su alerta de latencia P95 se abría y se cerraba repetidamente. Agregar capacidad habría tratado el síntoma antes de identificar en qué se consumía el tiempo de la solicitud.
Mi contribución
Comparé la resolución DNS, la búsqueda con nombre completamente calificado y la conexión TCP directa desde dentro de un pod de producción. La conexión a la base de datos en sí era rápida. El resolver de Kubernetes intentaba los dominios de búsqueda locales antes de resolver el hostname de una base de datos externa.
La decisión
El valor por defecto ndots:5 trataba el hostname externo como relativo y lo expandía a través de los dominios de búsqueda del pod. Agregué una opción ndots:2 configurable a la plantilla compartida de Helm, verifiqué el renderizado en ocho combinaciones de aplicación/entorno y promoví el cambio a través de desarrollo y staging hasta producción.
| Señal | Antes | Después |
|---|---|---|
| Búsqueda DNS p50 | ~18.7 ms | 2.06 ms |
Resultados y medición
Ambos deployments de producción recibieron la nueva opción de DNS. Repetir la búsqueda que abrió la investigación mostró una reducción de aproximadamente 18.7 ms p50 a 2.06 ms, unas nueve veces más rápido. Los pods se mantuvieron saludables, sin reinicios reportados en el snapshot de validación.
El cierre registró un P95 de la API de alrededor de 0.12 segundos durante la observación de 20 minutos posterior al rollout, y la alerta dejó de oscilar. La comparación de DNS y la observación de la API son mediciones diferentes; la mejora de la búsqueda no debe presentarse como una mejora de nueve veces en el tiempo total de respuesta de la API.
Contrapartidas y seguimiento
Cambiar el comportamiento de búsqueda del resolver debe preservar los nombres cortos usados dentro del cluster. El ajuste compartido se mantuvo configurable. La caché de DNS de todo el cluster y la capacidad del resolver fueron seguimientos aparte, en lugar de resultados atribuidos a esta corrección por aplicación.
La lección
Un síntoma de latencia relacionado con la base de datos puede originarse antes de que la base de datos reciba una consulta. Descompón la ruta de la solicitud y repite la misma medición después del cambio.
Decisiones y próximos pasos
Una mirada retrospectiva al enfoque y sus límites. La próxima mejora es una propuesta, no un resultado entregado.
Alternativa y justificación
Agregar réplicas o capacidad de base de datos no eliminaría la expansión de búsqueda del resolver. Afina la resolución después de aislar el tiempo de búsqueda del tiempo de TCP.
Contrapartida
Un valor de ndots más bajo cambia el comportamiento de búsqueda; valida los nombres internos y las dependencias externas antes de generalizar el ajuste.
Lo que mejoraría a continuación
Próxima mejora: ampliar la ventana de observación y agregar verificaciones de regresión del resolver para nombres internos y externos representativos.