Compartir a través de

Solución de errores de DNS en un clúster de AKS en tiempo real

  • Artículo

Los problemas del sistema de nombres de dominio (DNS) dentro de Kubernetes pueden interrumpir las comunicaciones entre pods, servicios y recursos externos, lo que produce errores de aplicación y degradación del rendimiento. En este artículo se describe cómo solucionar errores de DNS en un clúster de Azure Kubernetes Service (AKS) en tiempo real.

Nota:

Este artículo complementa los errores de resolución de DNS desde la guía del pod .

Síntomas

En la tabla siguiente se describen los síntomas comunes que puede observar en un clúster de AKS:

Síntoma Description
Alta tasa de errores Las consultas DNS producen un error o devuelven resultados inesperados, lo que puede afectar al rendimiento y la confiabilidad de las aplicaciones que dependen de ellas.
Servicios que no responden Las consultas DNS tardan más de lo habitual en resolverse, lo que puede provocar retrasos o tiempos de espera en las aplicaciones que dependen de ellas.
La detección de servicios se ve afectada Las aplicaciones no pueden encontrar otras aplicaciones en el clúster debido a problemas de DNS, lo que puede provocar interrupciones del servicio o errores.
La comunicación externa se ve afectada Las aplicaciones tienen problemas para acceder a recursos externos o puntos de conexión fuera del clúster debido a problemas de DNS, lo que puede provocar errores o un rendimiento degradado.

Requisitos previos

Para solucionar errores de DNS en un clúster de AKS, siga las instrucciones de las secciones siguientes.

Paso 1: Identificación de respuestas DNS incorrectas en el clúster

Puede usar el gadget DNS para identificar todas las respuestas DNS incorrectas en todo el clúster. Para realizar esta comprobación, realice un seguimiento de los paquetes DNS en todos los nodos y filtre las respuestas incorrectas mediante el siguiente comando:

$ kubectl gadget trace dns --all-namespaces --output columns=k8s,name,qtype,rcode --filter qr:R --filter qtype:A --filter 'rcode:!No Error'
K8S.NODE         K8S.NAMESPACE    K8S.POD     K8S.CONTAINER    NAME                  QTYPE        RCODE 
aks-agen...      default          test-pod    nginx            myaks-troubleshoot.   A            Non-Existent Domain 
aks-agen...      default          test-pod    nginx            myaks-troubleshoot.   A            Non-Existent Domain

Estas son las explicaciones de los parámetros de comando:

  • --all-namespaces: muestra datos de pods en todos los espacios de nombres.
  • -output columns=k8s,name,qtype,rcode: muestra solo la información de Kubernetes, el nombre DNS, el tipo de consulta y el resultado de la consulta DNS.
  • --filter qr:R: solo coincide con las respuestas DNS.
  • --filter qtype:A: solo coincide con las direcciones de host IPv4.
  • --filter 'rcode:!No Error': coincide con las respuestas DNS que no contienen No Error. Para obtener más información, consulte gopacket para conocer los posibles valores de rcode o rfC pertinentes.

Estas son algunas causas de respuestas DNS incorrectas:

  • El nombre DNS que se está resolviendo tiene un error tipográfico.
  • Los servidores de nombres DNS ascendentes experimentan problemas.
  • El nombre DNS no es válido después de la expansión. Para comprender cómo se pueden expandir las consultas DNS mediante el pod /etc/resolv.conf, consulte Espacios de nombres de servicios.

Paso 2: Identificación de consultas DNS lentas en todo el clúster

Puede usar el gadget DNS para identificar todas las consultas DNS lentas en todo el clúster. Para realizar esta comprobación, realice un seguimiento de los paquetes DNS en todos los nodos y filtre las respuestas lentas.

En el ejemplo siguiente, usa un valor de latencia de 5ms para definir paquetes lentos. Puede cambiarlo a un valor deseado, por ejemplo, 5μs, , 20ms1s:

$ kubectl gadget trace dns --all-namespaces --output columns=k8s,name,rcode,latency --filter 'latency:>5ms'
K8S.NODE        K8S.NAMESPACE      K8S.POD       K8S.CONTAINER      NAME                            RCODE              LATENCY            
aks-agen...     kube-system        coredn...     coredns            global.prod.micro...            No Error           5.373123ms 
aks-agen...     kube-system        coredn...     coredns            global.prod.micro...            No Error           5.373123ms

Estas son las explicaciones de los parámetros de comando:

  • --all-namespaces: muestra datos de pods en todos los espacios de nombres.
  • --output columns=k8s,name,rcode,latency: muestra solo la información de Kubernetes, el nombre DNS, el resultado de la respuesta DNS y la latencia de respuesta.
  • --filter 'latency:>5ms': solo coincide con las respuestas DNS con una latencia de al menos 5 ms.

Estas son algunas de las causas de las consultas DNS lentas:

  • Los servidores de nombres DNS ascendentes experimentan problemas.
  • Problemas de red en el clúster.
  • Los pods de CoreDNS no están disponibles. Para comprobar que los pods se están ejecutando correctamente, siga los pasos de solución de problemas de Solución de errores de resolución de DNS desde dentro del pod.

Paso 3: Comprobación del estado de los servidores DNS ascendentes

Puede usar el gadget DNS para comprobar el estado de los servidores DNS ascendentes usados por CoreDNS. Si las aplicaciones intentan llegar a dominios externos, las consultas se reenvieron a los servidores DNS ascendentes a través de CoreDNS. Para comprender el estado de estas consultas, siga el seguimiento de los paquetes DNS que salen de los pods de CoreDNS y filtre por el servidor de nombres.

En el ejemplo siguiente, el servidor DNS de Azure predeterminado (dirección IP 168.63.129.16) se usa como servidor de nombres ascendente. Si usa un servidor DNS personalizado, puede usar la dirección IP del servidor DNS personalizado como servidor de nombres ascendente. Para obtener la dirección IP, busque /etc/resolv.conf en el nodo.

$ kubectl gadget trace dns -n kube-system -l k8s-app=kube-dns -o columns=k8s,id,qr,name,rcode,nameserver,latency -F nameserver:168.63.129.16
K8S.NODE    K8S.NAMESPACE   K8S.POD                        K8S.CONTAINER   ID        QR    NAME               RCODE           NAMESERVER              LATENCY
aks-agen... kube-system     coredns-6d5bb68c46-ntz2q       coredns         b256      Q     microsoft.com.                     168.63.129.16
aks-agen... kube-system     coredns-6d5bb68c46-ntz2q       coredns         b256      R     microsoft.com.     No Error        168.63.129.16           500.821223ms

Estas son las explicaciones de los parámetros de comando:

  • -n kube-system: muestra solo los datos del kube-system espacio de nombres.
  • -l k8s-app=kube-dns: muestra solo datos hacia y desde pods con la etiqueta k8s-app=kube-dns (pods CoreDNS).
  • -o columns=k8s,id,name,rcode,nameserver,latency: muestra solo la información de Kubernetes, el identificador de consulta DNS, la consulta/respuesta, el nombre DNS, el resultado de la respuesta DNS, el servidor de nombres y la latencia de respuesta.
  • -F nameserver:168.63.129.16: el servidor DNS ascendente que se usa para filtrar eventos.

Puede usar los IDvalores , RCODEy LATENCY para determinar el estado del servidor DNS ascendente. Por ejemplo, si hay un servidor ascendente incorrecto, verá la siguiente salida:

  • Una consulta DNS (QR=Q) con ID (por ejemplo, b256) no tiene ninguna respuesta coincidente.
  • Una respuesta DNS (QR=R) tiene un valor alto en la LATENCY columna (por ejemplo, 500.821223ms).
  • Una respuesta DNS (QR=R) tiene un RCODE valor distinto No Errorde , por ejemplo, "Error del servidor" y "Consulta rechazada". Para obtener más información, consulte gopacket para conocer los posibles valores de rcode.

Paso 4: Comprobación de que las consultas DNS obtienen respuestas a tiempo

Puede usar el gadget DNS para comprobar que una consulta DNS determinada obtiene una respuesta de forma oportuna. Para realizar esta comprobación, filtre los eventos con un nombre DNS y coincida con los identificadores de consulta y respuesta:

$ kubectl gadget trace dns -l app=test-pod --output columns=k8s,id,qtype,qr,name,rcode,latency --filter name:microsoft.com.
K8S.NODE       K8S.NAMESPACE   K8S.POD     K8S.CONTAINER   ID          QTYPE     QR  NAME              RCODE               LATENCY
aks-agen...    default         test-pod    nginx           97b3        A         Q   microsoft.com.
aks-agen...    default         test-pod    nginx           97b3        A         R   microsoft.com.    No Error            1.954413ms
aks-agen...    default         test-pod    nginx           97b3        A         R   microsoft.com.    No Error
aks-agen...    default         test-pod    nginx           c6c5        AAAA      Q   microsoft.com.
aks-agen...    default         test-pod    nginx           c6c5        AAAA      R   microsoft.com.    No Error            1.885412ms
aks-agen...    default         test-pod    nginx           c6c5        AAAA      R   microsoft.com.    No Error

Estas son las explicaciones de los parámetros de comando:

  • -l app=test-pod: muestra solo los datos hacia y desde pods con la etiqueta app=test-pod.
  • --output columns=k8s,id,qtype,qr,name,rcode,latency: muestra solo la información de Kubernetes, el identificador de consulta DNS, el tipo de consulta, la consulta/respuesta, el nombre DNS, el resultado de la respuesta DNS y la latencia de respuesta.
  • --filter name:microsoft.com.: solo coincide con los paquetes DNS con el nombre microsoft.com. DNS Para asegurarse de que el valor del filtro es un nombre de dominio completo (FQDN), agregue un punto (.) al final del nombre.

El ID valor (por ejemplo, 97b3) se puede usar para correlacionar las consultas con respuestas. También puede usar el LATENCY valor para validar que obtiene las respuestas de forma oportuna.

Paso 5: Comprobación de que las respuestas DNS contienen las direcciones IP esperadas

Puede usar el gadget DNS para comprobar que una consulta DNS determinada obtiene la respuesta esperada. Por ejemplo, para un servicio sin encabezado (denominado myheadless), esperaría que la respuesta contenga las direcciones IP de todos los pods.

$ kubectl gadget trace dns -l app=test-pod  -o columns=k8s,id,qtype,qr,name,rcode,numAnswers,addresses  -F name:~myheadless 
K8S.NODE         K8S.NAMESPACE      K8S.POD         K8S.CONTAINER   ID    QTYPE   QR  NAME                 RCODE           NUMANSWERS     ADDRESSES
aks-agen...      default            test-pod        nginx           f930  A       R   myheadless.defau...  No Error        2              10.244.2.18,10.244.2.19 
aks-agen...      default            test-pod        nginx           f930  A       R   myheadless.defau...  No Error        2              10.244.2.18,10.244.2.19 
aks-agen...      default            test-pod        nginx           f930  A       Q   myheadless.defau...                  0

Estas son las explicaciones de los parámetros de comando:

  • -l app=test-pod: muestra solo los datos hacia y desde pods con la etiqueta app=test-pod.
  • -o columns=k8s,id,qtype,qr,name,rcode,numAnswers,addresses: muestra solo la información de Kubernetes, el identificador de consulta DNS, el tipo de consulta, la consulta/respuesta, el nombre DNS, el resultado de la respuesta DNS, el número de respuestas y las direcciones IP de la respuesta.
  • -F name:~myheadless: incluye solo paquetes DNS que pasan la ~myheadless comprobación regex.

Puede usar los NUMANSWERS valores y ADDRESSES para que coincidan con los valores que obtiene de kubectl get ep myheadless.

$ kubectl get ep myheadless 
NAME                  ENDPOINTS                           AGE 
myheadless            10.244.2.18:8080,10.244.2.19:8080   10d

Aviso de declinación de responsabilidades sobre la información de terceros

Los productos de otros fabricantes que se mencionan en este artículo han sido creados por compañías independientes de Microsoft. Microsoft no ofrece ninguna garantía, ya sea implícita o de otro tipo, sobre la confiabilidad o el rendimiento de dichos productos.

Ponte en contacto con nosotros para obtener ayuda

Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.