Container Service for Kubernetes:Troubleshoot DNS resolution errors

# View the pod's DNS policy
kubectl get pod <pod-name> -o yaml

# Log in to the pod and inspect the DNS configuration
kubectl exec -it <pod-name> -- cat /etc/resolv.conf

# View CoreDNS pod status and placement
kubectl -n kube-system get pod -o wide -l k8s-app=kube-dns

NAME                      READY   STATUS    RESTARTS   AGE   IP            NODE
coredns-xxxxxxxxx-xxxxx   1/1     Running   0          25h   172.20.6.53   cn-hangzhou.192.168.0.198

# View real-time CPU and memory usage
kubectl -n kube-system top pod -l k8s-app=kube-dns

NAME                      CPU(cores)   MEMORY(bytes)
coredns-xxxxxxxxx-xxxxx   3m           18Mi

kubectl -n kube-system logs -f --tail=500 --timestamps <coredns-pod-name>

[INFO] 172.20.2.25:44525 - 36259 "A IN redis-master.default.svc.cluster.local. udp 56 false 512" NOERROR qr,aa,rd 110 0.000116946s

Prueba de conectividad de red entre pods de aplicación y CoreDNS

Ingrese al namespace de red del pod de aplicación mediante uno de estos métodos:

• Método 1 (recomendado): Ejecute kubectl exec -it <pod-name> -- bash para ingresar al pod.

• Método 2: Inicie sesión en el nodo, busque el ID del proceso con ps aux | grep <application-process-name> y luego ingrese al namespace de red con nsenter -t <pid> -n bash.

• Método 3 (para pods que se reinician frecuentemente):

  1. Inicie sesión en el nodo.

  2. Ejecute docker ps -a | grep <application-container-name> para encontrar los ID de los contenedores sandbox (los nombres comienzan con k8s_POD_).

  3. Ejecute docker inspect <sandboxed-container-ID> | grep netns para encontrar la ruta del namespace de red en /var/run/docker/netns/xxxx.

  4. Ejecute nsenter -n bash para ingresar al namespace. > Note: No agregue un espacio entre -n y <netns-path>.

Desde el namespace de red del pod, pruebe la conectividad:

# Test connectivity to the kube-dns Service
dig <domain> @<kube-dns-svc-ip>

# Test Internet Control Message Protocol (ICMP) connectivity to the CoreDNS pod
ping <coredns-pod-ip>

# Test DNS query directly to the CoreDNS pod
dig <domain> @<coredns-pod-ip>

Reemplace <kube-dns-svc-ip> con la IP del Service kube-dns en el namespace kube-system, y <coredns-pod-ip> con la IP de un pod de CoreDNS.

Prueba de conectividad de red de CoreDNS

1. Inicie sesión en el nodo donde se ejecuta el pod de CoreDNS.

2. Ejecute ps aux | grep coredns para obtener el ID del proceso de CoreDNS.

3. Ejecute nsenter -t <pid> -n bash para ingresar al namespace de red de CoreDNS.

4. Pruebe la conectividad:

   # Test connectivity to the Kubernetes API server
   telnet <apiserver_clusterip> 6443  # apiserver_clusterip is the ClusterIP of the kubernetes Service in the default namespace.
   
   # Test connectivity to upstream DNS servers
   dig <domain> @100.100.2.136
   dig <domain> @100.100.2.138

Diagnóstico de la red de contenedores

1. Inicie sesión en la consola de ACKconsola de ACK.

2. En la página Clusters, haga clic en el nombre de su clúster o haga clic en Details en la columna Actions.

3. En el panel de navegación izquierdo, seleccione Operations > Cluster Check.

4. En la página de Container Intelligence Service, seleccione Cluster Check > Diagnosis.

5. En la página Diagnosis, haga clic en la pestaña Network Diagnosis.

6. Establezca Source address como la IP del pod de aplicación, Destination address como la IP del Service kube-dns y Destination port como 53. Seleccione Enable packet tracing y I know and agree, luego haga clic en Create diagnosis.

7. En la lista de diagnósticos, haga clic en Diagnosis details para ver su registro.

Los resultados muestran Diagnosis result, Packet paths y All possible paths, junto con las causas de error identificadas. Consulte Uso de la función de diagnóstico de clústeres para solucionar problemas del clúster.

Captura de paquetes

Utilice la captura de paquetes cuando los errores sean intermitentes y difíciles de reproducir.

1. Inicie sesión en los nodos donde se ejecutan los pods de aplicación y el pod de CoreDNS.

2. Capture el tráfico DNS en cada instancia de ECS:

   tcpdump -i any port 53 -C 20 -W 200 -w /tmp/client_dns.pcap

   Esto captura todo el tráfico en el puerto 53, rotando hasta 200 archivos de 20 MB cada uno.

3. Reproduzca el error y analice los paquetes de la ventana de tiempo del fallo. Revise los registros de la aplicación para obtener las marcas de tiempo exactas.

La captura de paquetes tiene un impacto insignificante en el servicio: solo un ligero aumento en la utilización de la CPU y la E/S del disco.

No se puede resolver un nombre de dominio externo

Revise el registro de consultas de CoreDNS para ver el código de respuesta. Habilite el plugin de registro si aún no está activo (consulte Configure DNS resolution) y luego busque el dominio que falla. NXDOMAIN significa que el dominio no existe en el upstream; a menudo se debe a que se agregó un sufijo de búsqueda, creando un FQDN no válido. SERVFAIL o REFUSED indican que el servidor upstream tiene un problema; revise la configuración de CoreDNS y la conectividad con 100.100.2.136 y 100.100.2.138.

No se pueden resolver los nombres de dominio de Services headless

En versiones de CoreDNS anteriores a la 1.7.0, la inestabilidad de la red del servidor de API puede provocar que CoreDNS se cierre, deteniendo las actualizaciones de registros de Services headless. Actualice a la versión 1.7.0 o posterior. Consulte [\[Component Updates\] Update CoreDNS](t1964489.dita#task_1964489).

No se pueden resolver los nombres de dominio de los pods de StatefulSet

La plantilla del pod de StatefulSet debe tener serviceName configurado con el nombre del Service headless. Sin esto, los nombres DNS por pod (por ejemplo, pod.headless-svc.ns.svc.cluster.local) no se pueden resolver, aunque el nombre a nivel de Service (por ejemplo, headless-svc.ns.svc.cluster.local) funcione. Configure serviceName en la especificación del StatefulSet.

Las consultas DNS están bloqueadas por reglas de security group o ACL de red

Las reglas de security group o las listas de control de acceso (ACL) de red están bloqueando el puerto UDP 53, lo que causa fallos de DNS en los nodos afectados. Permita el tráfico entrante y saliente por el puerto UDP 53.

Los errores de conectividad de la red de contenedores causan fallos de DNS

Los errores en la red de contenedores bloquean el puerto UDP 53. Utilice Network Diagnosis feature para identificar la ruta rota y la causa raíz.

Los pods de CoreDNS están sobrecargados

Cuando el volumen de consultas supera la capacidad de las réplicas de CoreDNS, la latencia aumenta y se producen fallos. Compruebe si el uso de CPU y memoria está cerca del límite (kubectl -n kube-system top pod -l k8s-app=kube-dns).

Dos soluciones:

• Despliegue NodeLocal DNSCache para absorber las consultas localmente y reducir la carga en CoreDNS. Consulte Configure NodeLocal DNSCache.

• Escale horizontalmente las réplicas de CoreDNS para que la utilización máxima de CPU por pod se mantenga muy por debajo de la CPU disponible del nodo.

Las consultas DNS no se distribuyen uniformemente entre los pods de CoreDNS

Una programación desequilibrada de pods o una configuración de sessionAffinity en kube-dns pueden causar una distribución desigual de las consultas. Síntoma: utilización de CPU notablemente diferente entre los pods de CoreDNS.

Dos soluciones:

• Escale horizontalmente los pods de CoreDNS y distribúyalos en diferentes nodos.

• Elimine la configuración de sessionAffinity del Service kube-dns. Consulte Configure the kube-dns Service.

Los pods de CoreDNS no se ejecutan con normalidad

Un YAML o ConfigMap mal configurado puede impedir que CoreDNS se inicie o provocar cierres inesperados. Síntomas: pods que no están en estado Running, recuento de reinicios en aumento o errores en los registros.

Busque estos errores comunes en el registro de CoreDNS:

Las resoluciones DNS fallan porque el cliente está sobrecargado

Cuando la instancia de ECS está completamente cargada, los paquetes UDP pueden descartarse antes de llegar a CoreDNS. Busque una tasa anormal de retransmisión del controlador de interfaz de red (NIC) y una alta utilización de CPU en los datos de monitoreo.

Despliegue NodeLocal DNSCache para reducir el tráfico DNS entre nodos. Consulte Configure NodeLocal DNSCache.

La tabla conntrack está llena

Cuando la tabla conntrack está llena, las nuevas conexiones UDP y TCP se descartan. Esto suele causar fallos de DNS en horas pico que se recuperan fuera de ese horario. Para confirmarlo, ejecute dmesg -H en el nodo afectado y busque conntrack full durante la ventana del fallo.

Aumente el número máximo de entradas en la tabla conntrack. Consulte How do I increase the maximum number of tracked connections in the conntrack table of the Linux kernel?

El plugin autopath no funciona con normalidad

Un defecto conocido del plugin autopath provoca fallos ocasionales en la resolución o IPs incorrectas para dominios externos. Los dominios internos se resuelven correctamente. El problema empeora en clústeres con altas tasas de creación de contenedores.

Deshabilite el plugin autopath:

1. Edite el ConfigMap de CoreDNS con kubectl -n kube-system edit configmap coredns.

2. Elimine la línea autopath @kubernetes. Guarde y salga.

3. Verifique que la configuración se haya cargado revisando los registros de CoreDNS en busca de reload.

Las resoluciones DNS fallan debido a consultas concurrentes de registros A y AAAA

Algunas distribuciones de Linux envían consultas A y AAAA simultáneamente por el mismo puerto, lo que desencadena conflictos en conntrack que descartan paquetes UDP.

Síntomas: fallos de resolución intermitentes; la captura de paquetes muestra consultas A y AAAA simultáneas desde el mismo puerto de origen.

Las soluciones dependen de la base de su imagen:

• CentOS o Ubuntu: Agregue options timeout:2 attempts:3 rotate single-request-reopen a la configuración del resolvedor DNS.

• Alpine Linux: Reemplace la imagen basada en Alpine por una basada en otro sistema operativo. Consulte Advertencias de Alpine.

• PHP con cURL: Agregue CURL_IPRESOLVE_V4 para forzar la resolución solo en IPv4. Consulte Funciones de cURL.

• Todos los entornos: Despliegue NodeLocal DNSCache, que mitiga la condición de carrera. Consulte Configure NodeLocal DNSCache.

Las resoluciones DNS fallan debido a errores de IPVS

En modo IPVS con CentOS o Alibaba Cloud Linux 2 (kernel anterior a 4.19.91-25.1.al7.x86_64), eliminar pods de backend UDP causa conflictos de puerto de origen que descartan paquetes. Los fallos de DNS duran ~5 minutos durante eventos de escalado de nodos o de CoreDNS.

Dos soluciones:

• Despliegue NodeLocal DNSCache para omitir la ruta IPVS en las consultas DNS. Consulte Configure NodeLocal DNSCache.

• Reduzca el tiempo de espera de la sesión UDP en modo IPVS. Consulte Change the UDP timeout period in IPVS mode.

NodeLocal DNSCache no funciona

Las consultas DNS omiten NodeLocal DNSCache cuando se cumple alguna de estas condiciones:

• No se inyectó dnsConfig en los pods de aplicación, por lo que siguen apuntando a la IP del Service kube-dns.

• Los pods usan una imagen base de Alpine Linux, que consulta todos los servidores de nombres simultáneamente, incluido CoreDNS directamente.

Para el primer caso, habilite la inyección automática de dnsConfig. Consulte Configure NodeLocal DNSCache. Para imágenes Alpine, use una imagen construida sobre otro sistema operativo. Consulte Advertencias de Alpine.

No se pueden resolver los nombres de Alibaba Cloud DNS PrivateZone

Alibaba Cloud DNS PrivateZone requiere UDP, no TCP. Con NodeLocal DNSCache, los dominios de PrivateZone, los endpoints de la API vpc-proxy u otros nombres de dominio pueden no resolverse o resolverse a IPs incorrectas.

Agregue prefer_udp a la configuración de CoreDNS para forzar UDP en las consultas upstream. Consulte Configure CoreDNS.