Los usuarios reportan fallos intermitentes de resolución de nombres dentro de tu clúster de Kubernetes. ¿Dónde miras?

Empieza por CoreDNS: reinicios de pods, throttling de CPU, tasa de errores y número de réplicas frente al volumen de consultas. Después revisa ndots, ya que el valor por defecto de 5 hace que cada búsqueda externa pruebe primero varios dominios de búsqueda y multiplique la carga de consultas. Los culpables clásicos son el agotamiento de la tabla conntrack en los nodos, la pérdida de paquetes UDP bajo carga y los resolvers de un solo hilo. Una caché DNS local en el nodo más nombres totalmente cualificados suele zanjarlo.

Empezaría midiendo en lugar de adivinando: qué nombres fallan, internos o externos, y si está correlacionado con la carga. Después CoreDNS en sí, porque si esos pods están con throttling de CPU o solo hay dos para un clúster grande, todo lo que hay aguas abajo parece intermitente. La que sorprende a la gente es ndots. El resolv.conf por defecto de un pod pone ndots en 5, así que buscar un nombre externo lo prueba contra cada dominio de búsqueda antes que el real, lo que convierte una consulta en cinco y mete mucha presión extra en CoreDNS. El arreglo es o bien un punto final en el nombre para hacerlo totalmente cualificado, o un dnsConfig personalizado con ndots en 2. Del lado del nodo reviso el uso de la tabla conntrack, porque una tabla llena descarta respuestas UDP en silencio y se ve exactamente como un DNS inestable. En la práctica, desplegar NodeLocal DNSCache nos lo arregló de forma permanente porque mueve las búsquedas a una caché local sobre TCP.