Compartir a través de

Análisis del tráfico DNS en tiempo real para solucionar errores de resolución de DNS en AKS

En este artículo se describe cómo solucionar errores del sistema de nombres de dominio (DNS) en un clúster de Azure Kubernetes Service (AKS) en tiempo real.

Nota:

Este artículo es complementario a la solución básica de problemas de resolución de DNS en la guía de AKS.

Síntomas

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

Síntoma Descripción
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.

Prerrequisitos

Para solucionar errores de DNS en un clúster de AKS, siga las instrucciones de las secciones siguientes. Antes de empezar, exporte la versión del gadget a una variable. Esta variable se usa en todos los comandos de este artículo.

GADGET_VERSION=$(kubectl gadget version | grep Server | awk '{print $3}')

No dude en elegir una versión diferente. Por ejemplo, puede usar latest o main para obtener la versión estable o de desarrollo más reciente del gadget respectivamente.

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.

kubectl gadget run trace_dns:$GADGET_VERSION \
  --all-namespaces \
  --fields k8s.node,src,dst,name,qtype,rcode \
  --filter "qr==R,rcode!=Success"

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

  • --all-namespaces: Muestra datos de los pods en todos los espacios de nombres.
  • --fields k8s.node,src,dst,name,qtype,rcode: muestra solo la información de Kubernetes, el origen y el destino de los paquetes DNS, el nombre DNS, el tipo de consulta DNS y el código de respuesta DNS.
  • --filter "qr==R,rcode!=Success": solo coincide con las respuestas DNS (qr==R) con un código de respuesta distinto de Success.

La salida debe tener una apariencia similar a la siguiente:

K8S.NODE                      SRC                                    DST                                    NAME                         QTYPE           RCODE   
aks-agentpool-…919-vmss000000 p/kube-system/coredns-57d886c994-r2ts… p/default/mypod:38480                  myaks-troubleshoot.          A               NameError
aks-agentpool-…919-vmss000000 s/kube-system/kube-dns:53              p/default/mypod:38480                  myaks-troubleshoot.          A               NameError

Donde RCODE es el código de respuesta DNS y le ayuda a identificar el tipo de error de DNS.

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.

  • Una configuración de red mal configurada (como NetworkPolicy (NetPol), firewall o reglas de NSG) bloquea el tráfico DNS.

  • 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 /etc/resolv.conf archivo de un pod, 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 run trace_dns:$GADGET_VERSION \
  --all-namespaces \
  --fields k8s.node,src,dst,name,qtype,rcode,latency_ns \
  --filter "latency_ns_raw>5000000"

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

  • --all-namespaces: muestra datos de pods en todos los espacios de nombres.
  • --fields k8s.node,src,dst,name,qtype,rcode,latency_ns: muestra solo la información de Kubernetes, el origen y el destino de los paquetes DNS, el nombre DNS, el tipo de consulta DNS, el código de respuesta DNS y la latencia en nanosegundos.
  • --filter "latency_ns_raw>5000000": solo coincide con las respuestas DNS con latencia mayor que 5ms (5000000 nanosegundos).

La salida debe tener una apariencia similar a la siguiente:

K8S.NODE                   SRC                                DST                               NAME                      QTYPE         RCODE          LATENCY_NS
aks-agentpool…9-vmss000001 168.63.129.16:53                   p/kube-system/coredns-57d886c994… microsoft.com.            A             Success           14.02ms
aks-agentpool…9-vmss000000 s/kube-system/kube-dns:53          p/default/mypod:39168             microsoft.com.            A             Success           15.40ms
aks-agentpool…9-vmss000000 168.63.129.16:53                   p/kube-system/coredns-57d886c994… microsoft.com.            AAAA          Success            5.90ms
aks-agentpool…9-vmss000000 s/kube-system/kube-dns:53          p/default/mypod:38953             microsoft.com.            AAAA          Success            6.41ms

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.

Paso 3: Comprobar el 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, monitoree los paquetes DNS que salen desde 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 run trace_dns:$GADGET_VERSION \
  --all-namespaces \
  --fields src,dst,id,qr,name,nameserver,rcode,latency_ns \
  --filter "nameserver.addr==168.63.129.16"

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

  • --all-namespaces: muestra datos de pods en todos los espacios de nombres.
  • --fields src,dst,id,qr,name,nameserver,rcode,latency_ns: muestra solo el origen y el destino de los paquetes DNS, el identificador de consulta DNS, la consulta/respuesta, el nombre DNS, el servidor de nombres, el resultado de la respuesta DNS y la latencia en nanosegundos.
  • --filter "nameserver.addr==168.63.129.16" : coincide únicamente con paquetes DNS con la dirección IP 168.63.129.16 del servidor de nombres.

La salida debe tener una apariencia similar a la siguiente:

SRC                                        DST                                        ID                QR NAME                           NAMESERVER       RCODE              LATENCY_NS
p/kube-system/coredns-57d886c994-vsj7g:60… r/168.63.129.16:53                         4828              Q  qasim-cluster-dns-sqia0j5i.hc… 168.63.129.16                              0ns
p/kube-system/coredns-57d886c994-pcv59:51… r/168.63.129.16:53                         5015              Q  qasim-cluster-dns-sqia0j5i.hc… 168.63.129.16                              0ns
r/168.63.129.16:53                         p/kube-system/coredns-57d886c994-pcv59:51… 5015              R  qasim-cluster-dns-sqia0j5i.hc… 168.63.129.16    Success                5.06ms
r/168.63.129.16:53                         p/kube-system/coredns-57d886c994-vsj7g:60… 4828              R  qasim-cluster-dns-sqia0j5i.hc… 168.63.129.16    Success               23.01ms

Puede usar los valores RCODE y LATENCY para determinar el estado del servidor DNS aguas arriba. Por ejemplo, si hay un servidor de origen no saludable, verá la siguiente salida:

  • Una consulta DNS (QR=Q) con un identificador (por ejemplo, 4828) no tiene ninguna respuesta coincidente.
  • Una respuesta DNS (QR=R) tiene un valor alto en la LATENCY_NS columna (por ejemplo, 23.01ms).
  • Una respuesta DNS (QR=R) tiene un valor RCODE distinto de Success, por ejemplo, "Fallo del Servidor" y "Rechazado".

Paso 4: Comprobación de que las consultas DNS obtienen respuestas de forma oportuna

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 run trace_dns:$GADGET_VERSION \
    -l app=test-pod \
    --fields k8s.node,k8s.namespace,k8s.podname,id,qtype,qr,name,rcode,latency_ns \
    --filter name==microsoft.com.

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 en el espacio de nombres predeterminado.
  • --fields k8s.node,k8s.namespace,k8s.podname,id,qtype,qr,name,rcode,latency_ns: 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 en nanosegundos.
  • --filter name==microsoft.com.: coincide únicamente con paquetes DNS con el nombre DNS microsoft.com.. Asegúrese de que el valor del filtro sea un nombre de dominio completo (FQDN) agregando un punto (.) al final del nombre.

La salida debe tener una apariencia similar a la siguiente:

K8S.NODE                  K8S.NAMESPACE             K8S.PODNAME               ID             QTYPE          QR NAME                     RCODE          LATENCY_NS
aks-agentpoo…9-vmss000000 default                   mypod                     102d           A              Q  microsoft.com.                                 0ns
aks-agentpoo…9-vmss000000 default                   mypod                     102d           A              R  microsoft.com.           Success           11.87ms
aks-agentpoo…9-vmss000000 default                   mypod                     d482           AAAA           Q  microsoft.com.                                 0ns
aks-agentpoo…9-vmss000000 default                   mypod                     d482           AAAA           R  microsoft.com.           Success            9.27ms

El ID valor (por ejemplo, 102d) se puede usar para correlacionar las consultas con respuestas. También puede usar el LATENCY_NS 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 estado (denominado myheadless), esperaría que la respuesta contuviera las direcciones IP de todos los pods.

kubectl gadget run trace_dns:$GADGET_VERSION \
  --fields k8s.podname,id,qtype,qr,name,rcode,num_answers,addresses  \
  --filter name~myheadless

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

  • --fields k8s.podname,id,qtype,qr,name,rcode,num_answers,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.
  • --filter name~myheadless: solo coincide con paquetes DNS con el nombre DNS que contiene myheadless. El ~ operador se usa para buscar coincidencias con una expresión regular.

La salida debe tener una apariencia similar a la siguiente:

K8S.PODNAME                           ID                   QTYPE                QR NAME                                 RCODE     NUM_ANSWERS ADDRESSES          
mypod                                 f8b0                 A                    Q  myheadless.default.svc.cluster.loca…           0                              
mypod                                 f8b0                 A                    R  myheadless.default.svc.cluster.loca… Success   2           10.244.0.146,10.24…
mypod                                 abcd                 AAAA                 Q  myheadless.default.svc.cluster.loca…           0                              
mypod                                 abcd                 AAAA                 R  myheadless.default.svc.cluster.loca… Success   0

Puede usar los NUM_ANSWERS 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.0.146:80,10.244.1.207:80   10d

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

Los productos de terceros que describe este artículo son fabricados por empresas 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 a la comunidad de comentarios de Azure.