Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este artículo se describe cómo crear un flujo de trabajo de solución de problemas para corregir problemas de resolución del sistema de nombres de dominio (DNS) en Microsoft Azure Kubernetes Service (AKS).
Prerrequisitos
La herramienta de línea de comandos kubectl de Kubernetes
Nota: Para instalar kubectl mediante la CLI de Azure, ejecute el comando az aks install-cli .
La herramienta de línea de comandos dig para la búsqueda de DNS
La herramienta de línea de comandos grep para la búsqueda de texto
Analizador de paquetes de red wireshark
Lista de verificación de solución de problemas
La solución de problemas de DNS en AKS suele ser un proceso complejo. Puede perderse fácilmente en los muchos pasos diferentes sin ver un camino claro hacia adelante. Para ayudar a que el proceso sea más sencillo y eficaz, use el método "científico" para organizar el trabajo:
Paso 1. Recopile los hechos.
Paso 2. Desarrolle una hipótesis.
Paso 3. Cree e implemente un plan de acción.
Paso 4. Observe los resultados y saque conclusiones.
Paso 5. Repita lo necesario.
Paso 1 de solución de problemas: Recopilar los hechos
Para comprender mejor el contexto del problema, recopile hechos sobre el problema de DNS específico. Mediante el uso de las siguientes preguntas de línea base como punto de partida, puede describir la naturaleza del problema, reconocer los síntomas e identificar el ámbito del problema.
| Pregunta | Posibles respuestas |
|---|---|
| ¿Dónde se produce un error en la resolución DNS? |
|
| ¿Qué tipo de error de DNS recibes? |
|
| ¿Con qué frecuencia se producen los errores dns? |
|
| ¿Qué registros se ven afectados? |
|
| ¿Existen configuraciones DE DNS personalizadas? |
|
| ¿Qué tipo de problemas de rendimiento afectan a los nodos? |
|
| ¿Qué tipo de problemas de rendimiento afectan a los pods de CoreDNS? |
|
| ¿Qué causa la latencia de DNS? | Consultas DNS que tardan demasiado tiempo en recibir una respuesta (más de cinco segundos) |
Para obtener mejores respuestas a estas preguntas, siga este proceso de tres partes.
Parte 1: Generar pruebas en diferentes niveles que reproducen el problema
El proceso de resolución del DNS para los pods en AKS incluye varias capas. Revise estas capas para aislar el problema. Las capas siguientes son típicas:
- Pods de CoreDNS
- Servicio CoreDNS
- Nodos
- DNS de red virtual
Para iniciar el proceso, ejecute pruebas con un pod de prueba contra cada capa.
Prueba de la resolución DNS en el nivel de pod de CoreDNS
Implemente un pod de prueba para ejecutar consultas de prueba de DNS mediante la ejecución del siguiente comando:
cat <<EOF | kubectl apply --filename - apiVersion: v1 kind: Pod metadata: name: aks-test spec: containers: - name: aks-test image: debian:stable command: ["/bin/sh"] args: ["-c", "apt-get update && apt-get install -y dnsutils && while true; do sleep 1000; done"] EOFRecupere las direcciones IP de los pods de CoreDNS mediante la ejecución del siguiente comando kubectl get :
kubectl get pod --namespace kube-system --selector k8s-app=kube-dns --output wideConéctese al pod de prueba mediante el
kubectl exec -it aks-test -- bashcomando y pruebe la resolución DNS en cada dirección IP del pod de CoreDNS mediante la ejecución de los siguientes comandos:# Placeholder values FQDN="<fully-qualified-domain-name>" # For example, "db.contoso.com" DNS_SERVER="<coredns-pod-ip-address>" # Test loop for i in $(seq 1 1 10) do echo "host= $(dig +short ${FQDN} @${DNS_SERVER})" sleep 1 done
Para obtener más información sobre cómo solucionar problemas de resolución de DNS desde el nivel de pod, consulte Solución de errores de resolución de DNS desde el pod.
Prueba de la resolución DNS en el nivel de servicio CoreDNS
Recupere la dirección IP del servicio CoreDNS ejecutando el siguiente
kubectl getcomando:kubectl get service kube-dns --namespace kube-systemEn el pod de prueba, ejecute los siguientes comandos en la dirección IP del servicio CoreDNS:
# Placeholder values FQDN="<fully-qualified-domain-name>" # For example, "db.contoso.com" DNS_SERVER="<kubedns-service-ip-address>" # Test loop for i in $(seq 1 1 10) do echo "host= $(dig +short ${FQDN} @${DNS_SERVER})" sleep 1 done
Prueba de la resolución DNS en el nivel de nodo
Conéctese al nodo.
Ejecute el siguiente
grepcomando para recuperar la lista de servidores DNS ascendentes configurados:grep ^nameserver /etc/resolv.confEjecute los siguientes comandos de texto en cada DNS configurado en el nodo:
# Placeholder values FQDN="<fully-qualified-domain-name>" # For example, "db.contoso.com" DNS_SERVER="<dns-server-in-node-configuration>" # Test loop for i in $(seq 1 1 10) do echo "host= $(dig +short ${FQDN} @${DNS_SERVER})" sleep 1 done
Prueba la resolución DNS en el nivel DNS de la red virtual
Examine la configuración del servidor DNS de la red virtual y determine si los servidores pueden resolver el registro en cuestión.
Parte 2: Revisión del estado y el rendimiento de los pods y nodos de CoreDNS
Revisión del estado y el rendimiento de los pods de CoreDNS
Puede usar kubectl comandos para comprobar el estado y el rendimiento de los pods de CoreDNS. Para ello, siga estos pasos:
Compruebe que los pods de CoreDNS se están ejecutando:
kubectl get pods -l k8s-app=kube-dns -n kube-systemCompruebe si los pods de CoreDNS están sobreutilizados:
kubectl top pods -n kube-system -l k8s-app=kube-dnsNAME CPU(cores) MEMORY(bytes) coredns-dc97c5f55-424f7 3m 23Mi coredns-dc97c5f55-wbh4q 3m 25MiObtenga los nodos que hospedan los pods de CoreDNS:
kubectl get pods -n kube-system -l k8s-app=kube-dns -o jsonpath='{.items[*].spec.nodeName}'Compruebe que los nodos no se han sobreutilizado:
kubectl top nodesCompruebe los registros de los pods de CoreDNS:
kubectl logs -l k8s-app=kube-dns -n kube-system
Nota:
Para obtener más información de depuración, habilite los registros detallados en CoreDNS. Para ello, consulte Solución de problemas de personalización de CoreDNS en AKS.
Revisar el estado y el rendimiento de los nodos
Puede que primero note problemas de rendimiento en la resolución de DNS como errores intermitentes, tales como tiempos de espera. Las principales causas de este problema son el agotamiento de recursos y la limitación de E/S dentro de los nodos que hospedan los pods de CoreDNS o el pod cliente.
Para comprobar si se está produciendo un agotamiento de recursos o una limitación de E/S, ejecute el siguiente comando kubectl describe junto con el grep comando en los nodos. Esta serie de comandos le permite revisar el recuento de solicitudes y compararlo con el límite de cada recurso. Si el porcentaje de límite es superior al 100 por ciento para un recurso, ese recurso se sobrecommite.
kubectl describe node | grep -A5 '^Name:\|^Allocated resources:' | grep -v '.kubernetes.io\|^Roles:\|Labels:'
En el fragmento de código siguiente se muestra la salida de ejemplo de este comando:
Name: aks-nodepool1-17046773-vmss00000m
--
Allocated resources:
(Total limits might be more than 100 percent.)
Resource Requests Limits
-------- -------- ------
cpu 250m (13 percent) 40m (2 percent)
memory 420Mi (9 percent) 1762Mi (41 percent)
--
Name: aks-nodepool1-17046773-vmss00000n
--
Allocated resources:
(Total limits might be more than 100 percent.)
Resource Requests Limits
-------- -------- ------
cpu 612m (32 percent) 8532m (449 percent)
memory 804Mi (18 percent) 6044Mi (140 percent)
--
Name: aks-nodepool1-17046773-vmss00000o
--
Allocated resources:
(Total limits might be more than 100 percent.)
Resource Requests Limits
-------- -------- ------
cpu 250m (13 percent) 40m (2 percent)
memory 420Mi (9 percent) 1762Mi (41 percent)
--
Name: aks-ubuntu-16984727-vmss000008
--
Allocated resources:
(Total limits might be more than 100 percent.)
Resource Requests Limits
-------- -------- ------
cpu 250m (13 percent) 40m (2 percent)
memory 420Mi (19 percent) 1762Mi (82 percent)
Para obtener una mejor imagen del uso de recursos en el nivel de pod y nodo, también puede usar Container Insights y otras herramientas nativas de nube en Azure. Para más información, consulte Supervisión de clústeres de Kubernetes mediante servicios de Azure y herramientas nativas en la nube.
Parte 3: Análisis del tráfico DNS y revisión del rendimiento de la resolución de DNS
El análisis del tráfico DNS puede ayudarle a comprender cómo controla el clúster de AKS las consultas DNS. Lo ideal es que reproduzcas el problema en un pod de prueba mientras capturas el tráfico de este pod de prueba y de cada uno de los pods CoreDNS.
Hay dos maneras principales de analizar el tráfico DNS:
- Uso de herramientas de análisis de DNS en tiempo real, como Inspektor Gadget, para analizar el tráfico DNS en tiempo real.
- Con herramientas de captura de tráfico, como Retina Capture y Dumpy, para recopilar el tráfico DNS y analizarlo con una herramienta de analizador de paquetes de red, como Wireshark.
Ambos enfoques tienen como objetivo comprender el estado y el rendimiento de las respuestas DNS mediante códigos de respuesta DNS, tiempos de respuesta y otras métricas. Elija la que mejor se adapte a sus necesidades.
Análisis del tráfico DNS en tiempo real
Puede usar Inspektor Gadget para analizar el tráfico DNS en tiempo real. Para instalar Inspektor Gadget en el clúster, consulte Instalación de Inspektor Gadget en un clúster de AKS.
Para realizar un seguimiento del tráfico DNS en todos los espacios de nombres, use el siguiente comando:
# Get the version of Gadget
GADGET_VERSION=$(kubectl gadget version | grep Server | awk '{print $3}')
# Run the trace_dns gadget
kubectl gadget run trace_dns:$GADGET_VERSION --all-namespaces --fields "src,dst,name,qr,qtype,id,rcode,latency_ns"
Donde --fields es una lista separada por comas de campos que se van a mostrar. En la lista siguiente se describen los campos que se usan en el comando :
-
src: origen de la solicitud con información de Kubernetes (<kind>/<namespace>/<name>:<port>). -
dst: el destino de la solicitud con información de Kubernetes (<kind>/<namespace>/<name>:<port>). -
name: el nombre de la solicitud DNS. -
qr: marca de consulta/respuesta. -
qtype: tipo de la solicitud DNS. -
id: el identificador de la solicitud DNS, que se usa para buscar coincidencias con la solicitud y la respuesta. -
rcode: el código de respuesta de la solicitud DNS. -
latency_ns: la latencia de la solicitud DNS.
La salida del comando es similar a la siguiente:
SRC DST NAME QR QTYPE ID RCODE LATENCY_NS
p/default/aks-test:33141 p/kube-system/coredns-57d886c994-r2… db.contoso.com. Q A c215 0ns
p/kube-system/coredns-57d886c994-r2… 168.63.129.16:53 db.contoso.com. Q A 323c 0ns
168.63.129.16:53 p/kube-system/coredns-57d886c994-r2… db.contoso.com. R A 323c NameErr… 13.64ms
p/kube-system/coredns-57d886c994-r2… p/default/aks-test:33141 db.contoso.com. R A c215 NameErr… 0ns
p/default/aks-test:56921 p/kube-system/coredns-57d886c994-r2… db.contoso.com. Q A 6574 0ns
p/kube-system/coredns-57d886c994-r2… p/default/aks-test:56921 db.contoso.com. R A 6574 NameErr… 0ns
Puede usar el ID campo para identificar si una consulta tiene una respuesta. El RCODE campo muestra el código de respuesta de la solicitud DNS. El LATENCY_NS campo muestra la latencia de la solicitud DNS en nanosegundos. Estos campos pueden ayudarle a comprender el estado y el rendimiento de las respuestas DNS.
Para más información sobre el análisis de DNS en tiempo real, consulte Solución de errores de DNS en un clúster de AKS en tiempo real.
Captura del tráfico DNS
En esta sección se muestra cómo usar Dumpy para recopilar capturas de tráfico DNS de cada pod de CoreDNS y un pod DNS de cliente (en este caso, el aks-test pod).
Para recopilar las capturas del pod de cliente de prueba, ejecute el siguiente comando:
kubectl dumpy capture pod aks-test -f "-i any port 53" --name dns-cap1-aks-test
Para recopilar capturas para los pods de CoreDNS, ejecute el siguiente comando Dumpy:
kubectl dumpy capture deploy coredns \
-n kube-system \
-f "-i any port 53" \
--name dns-cap1-coredns
Idealmente, debe ejecutar capturas mientras el problema se reproduce. Este requisito significa que las diferentes capturas se pueden ejecutar durante diferentes cantidades de tiempo, en función de la frecuencia con la que se pueda reproducir el problema. Para recopilar las capturas, ejecute los siguientes comandos:
mkdir dns-captures
kubectl dumpy export dns-cap1-aks-test ./dns-captures
kubectl dumpy export dns-cap1-coredns ./dns-captures -n kube-system
Para eliminar los pods Dumpy, ejecute el siguiente comando Dumpy:
kubectl dumpy delete dns-cap1-coredns -n kube-system
kubectl dumpy delete dns-cap1-aks-test
Para combinar todas las capturas de pod de CoreDNS, use la herramienta de línea de comandos mergecap para combinar archivos de captura. La mergecap herramienta se incluye en la herramienta analizador de paquetes de red wireshark. Ejecute el comando mergecap siguiente:
mergecap -w coredns-cap1.pcap dns-cap1-coredns-<coredns-pod-name-1>.pcap dns-cap1-coredns-<coredns-pod-name-2>.pcap [...]
Análisis de paquetes DNS para un pod coreDNS individual
Después de generar y combinar los archivos de captura de tráfico, puede realizar un análisis de paquetes DNS de los archivos de captura en Wireshark. Siga estos pasos para ver el análisis de paquetes para el tráfico de un pod CoreDNS individual:
Seleccione Inicio, escriba Wireshark y, a continuación, seleccione Wireshark en los resultados de la búsqueda.
En la ventana Wireshark , seleccione el menú Archivo y, a continuación, seleccione Abrir.
Vaya a la carpeta que contiene los archivos de captura, seleccione dns-cap1-db-check-db-check-pod-name.pcap<> (el archivo de captura del lado cliente para un pod coreDNS individual) y, a continuación, seleccione el botón Abrir.
Seleccione el menú Estadísticas y, a continuación, seleccione DNS. Aparece el cuadro de diálogo Wireshark - DNS y muestra un análisis del tráfico DNS. El contenido del cuadro de diálogo se muestra en la tabla siguiente.
Tema o elemento Contar Promedio Min Val Valor máximo Tiempo (ms) Porcentaje Velocidad de ráfaga Comienzo de ráfaga ▾ Total de paquetes 1066 0.0017 100 % 0.1200 0,000 ▾ rcode 1066 0.0017 100,00% 0.1200 0,000 Error del servidor 17 0.0000 1,59% 0.0100 99.332 Ningún nombre de este tipo 353 0.0006 33.11% 0.0400 0,000 No hay ningún error 696 0.0011 65.29% 0.0800 0,000 ▾ códigos de operación 1066 0.0017 100,00% 0.1200 0,000 Consulta estándar 1066 0.0017 100,00% 0.1200 0,000 ▾ Consulta/respuesta 1066 0.0017 100,00% 0.1200 0,000 Respuesta 531 0.0009 49.81% 0.0600 0,000 Consulta 535 0.0009 50.19% 0.0600 0,000 ▾ Tipo de consulta 1066 0.0017 100,00% 0.1200 0,000 AAAA 167 0.0003 15.67% 0.0200 0,000 Un 899 0.0015 84.33% 0.1000 0,000 ▾ Clase 1066 0.0017 100,00% 0.1200 0,000 EN 1066 0.0017 100,00% 0.1200 0,000 ▾ Estadísticas de servicio 0 0.0000 100 % - - tiempo de solicitud-respuesta (msec) 531 184.42 0.067000 6308.503906 0.0009 0.0600 0,000 No. de respuestas no solicitadas 0 0.0000 - - No. de retransmisiones 0 0.0000 - - ▾ Estadísticas de respuesta 0 0.0000 100 % - - No. de preguntas 1062 1.00 1 1 0.0017 0,1200 0,000 No. de autoridades 1062 0.82 0 1 0.0017 0,1200 0,000 No. de respuestas 1062 0.15 0 1 0.0017 0.1200 0,000 No. de elementos adicionales 1062 0.00 0 0 0.0017 0.1200 0,000 ▾ Estadísticas de consulta 0 0.0000 100 % - - Qname Len 535 32,99 14 66 0.0009 0.0600 0,000 ▾ Estadísticas de etiquetas 0 0.0000 - - 4º nivel o más 365 0.0006 0.0400 0,000 Tercer nivel 170 0.0003 0.0200 0,000 2º nivel 0 0.0000 - - Primer nivel 0 0.0000 - - Tamaño de carga 1066 92.87 32 194 0.0017 100 % 0.1200 0,000
El cuadro de diálogo Análisis de DNS de Wireshark muestra un total de 1066 paquetes. De estos paquetes, el 17 (1,59 por ciento) provocó un error en el servidor. Además, el tiempo de respuesta máximo era de 6308 milisegundos (6,3 segundos) y no se recibió ninguna respuesta durante el 0,38 por ciento de las consultas. (Este total se calculó restando el 49,81 por ciento de los paquetes que contenían respuestas del 50,19 por ciento de los paquetes que contenían consultas).
Si escribe (dns.flags.response == 0) && ! dns.response_in como filtro de visualización en Wireshark, este filtro muestra las consultas DNS que no recibieron una respuesta, como se muestra en la tabla siguiente.
| No. | Tiempo | Fuente | Destino | Protocolo | Largura | Información |
|---|---|---|---|---|---|---|
| 225 | 2024-04-01 16:50:40.000520 | 10.0.0.21 | 172.16.0.10 | DNS (Sistema de Nombres de Dominio) | 80 | Consulta estándar 0x2c67 AAAA db.contoso.com |
| 426 | 2024-04-01 16:52:47.419907 | 10.0.0.21 | 172.16.0.10 | DNS (Sistema de Nombres de Dominio) | 132 | Consulta estándar 0x8038 A db.contoso.com.iosffyoulcwehgo1g3egb3m4oc.jx.internal.cloudapp.net |
| 693 | 2024-04-01 16:55:23.105558 | 10.0.0.21 | 172.16.0.10 | DNS (Sistema de Nombres de Dominio) | 132 | Consulta estándar 0xbcb0 A db.contoso.com.iosffyoulcwehgo1g3egb3m4oc.jx.internal.cloudapp.net |
| 768 | 2024-04-01 16:56:06.512464 | 10.0.0.21 | 172.16.0.10 | DNS (Sistema de Nombres de Dominio) | 80 | Consulta estándar 0xe330 hacia db.contoso.com |
Además, la barra de estado Wireshark muestra el texto Paquetes: 1066 - Mostrado: 4 (0,4%). Esta información significa que cuatro de los 1066 paquetes, o el 0,4 por ciento, eran consultas DNS que nunca recibieron una respuesta. Este porcentaje coincide esencialmente con el total del 0,38 por ciento que calculó anteriormente.
Si cambia el filtro de presentación a dns.time >= 5, el filtro muestra los paquetes de respuesta de consulta que tardaron cinco segundos o más en recibirse, como se muestra en la tabla actualizada.
| No. | Tiempo | Fuente | Destino | Protocolo | Largura | Información | SourcePort | RR adicionales | Tiempo de respuesta DNS |
|---|---|---|---|---|---|---|---|---|---|
| 213 | 2024-04-01 16:50:32.644592 | 172.16.0.10 | 10.0.0.21 | DNS (Sistema de Nombres de Dominio) | 132 | Falló la consulta estándar del servidor: 0x9312 A db.contoso.com.iosffyoulcwehgo1g3egb3m4oc.jx.internal.cloudapp.net | 53 | 0 | 6.229941 |
| 320 | 2024-04-01 16:51:55.053896 | 172.16.0.10 | 10.0.0.21 | DNS (Sistema de Nombres de Dominio) | 80 | Error de consulta estándar 0xe5ce Error del servidor A db.contoso.com | 53 | 0 | 6.065555 |
| 328 | 2024-04-01 16:51:55.113619 | 172.16.0.10 | 10.0.0.21 | DNS (Sistema de Nombres de Dominio) | 132 | Fallo de consulta estándar 0x6681: error del servidor A db.contoso.com.iosffyoulcwehgo1g3egb3m4oc.jx.internal.cloudapp.net | 53 | 0 | 6.029641 |
| 335 | 2024-04-01 16:52:02.553811 | 172.16.0.10 | 10.0.0.21 | DNS (Sistema de Nombres de Dominio) | 80 | Error de consulta estándar 0x6cf6 fallo del servidor en db.contoso.com | 53 | 0 | 6,500504 |
| 541 | 2024-04-01 16:53:53.423838 | 172.16.0.10 | 10.0.0.21 | DNS (Sistema de Nombres de Dominio) | 80 | Error de consulta estándar 0x07b3 Fallo del servidor AAAA db.contoso.com | 53 | 0 | 6.022195 |
| 553 | 2024-04-01 16:54:05.165234 | 172.16.0.10 | 10.0.0.21 | DNS (Sistema de Nombres de Dominio) | 132 | Fallo de servidor en consulta estándar 0x1ea0 A db.contoso.com.iosffyoulcwehgo1g3egb3m4oc.jx.internal.cloudapp.net | 53 | 0 | 6.007022 |
| 774 | 2024-04-01 16:56:17.553531 | 172.16.0.10 | 10.0.0.21 | DNS (Sistema de Nombres de Dominio) | 80 | Error de consulta estándar 0xa20f fallo del servidor AAAA db.contoso.com | 53 | 0 | 6.014926 |
| 891 | 2024-04-01 16:56:44.442334 | 172.16.0.10 | 10.0.0.21 | DNS (Sistema de Nombres de Dominio) | 132 | Error de consulta estándar 0xa279 Error del servidor A db.contoso.com.iosffyoulcwehgo1g3egb3m4oc.jx.internal.cloudapp.net | 53 | 0 | 6.044552 |
Después de cambiar el filtro de presentación, la barra de estado se actualiza para mostrar el texto Paquetes: 1066 - Mostrado: 8 (0,8%). Por lo tanto, ocho de los 1066 paquetes, o el 0,8 por ciento, eran respuestas DNS que tardaron cinco segundos o más en recibirse. Sin embargo, en la mayoría de los clientes, se espera que el valor predeterminado de tiempo de espera de DNS sea de cinco segundos. Esta expectativa significa que, aunque los pods de CoreDNS procesaron y entregaron las ocho respuestas, el cliente ya había finalizado la sesión al emitir un mensaje de error de "tiempo de espera agotado". La columna Información de los resultados filtrados muestra que los ocho paquetes provocaron un error en el servidor.
Análisis de paquetes DNS para todos los pods de CoreDNS
En Wireshark, abra el archivo de captura de los pods de CoreDNS que ha combinado anteriormente (coredns-cap1.pcap) y, a continuación, abra el análisis de DNS, como se describe en la sección anterior. Aparece un cuadro de diálogo Wireshark que muestra la tabla siguiente.
| Tema o elemento | Contar | Promedio | Min Val | Valor máximo | Tiempo (ms) | Porcentaje | Velocidad de ráfaga | Comienzo de ráfaga |
|---|---|---|---|---|---|---|---|---|
| ▾ Total de paquetes | 4540233 | 7.3387 | 100 % | 84.7800 | 592.950 | |||
| ▾ rcode | 4540233 | 7.3387 | 100,00% | 84.7800 | 592.950 | |||
| Error del servidor | 121781 | 0.1968 | 2.68% | 8.4600 | 599.143 | |||
| Ningún nombre de este tipo | 574658 | 0.9289 | 12,66 % | 10,9800 | 592.950 | |||
| No hay ningún error | 3843794 | 6,2130 | 84.66% | 73.2500 | 592.950 | |||
| ▾ códigos de operación | 4540233 | 7.3387 | 100,00% | 84.7800 | 592.950 | |||
| Consulta estándar | 4540233 | 7.3387 | 100,00% | 84.7800 | 592.950 | |||
| ▾ Consulta/respuesta | 4540233 | 7.3387 | 100,00% | 84.7800 | 592.950 | |||
| Respuesta | 2135116 | 3.4512 | 47.03% | 39.0400 | 581.680 | |||
| Consulta | 2405117 | 3,8876 | 52,97% | 49.1400 | 592.950 | |||
| ▾ Tipo de consulta | 4540233 | 7.3387 | 100,00% | 84.7800 | 592.950 | |||
| SRV | 3647 | 0.0059 | 0,08% | 0.1800 | 586.638 | |||
| RPP | 554630 | 0.8965 | 12.22% | 11.5400 | 592.950 | |||
| NS | 15918 | 0.0257 | 0,35 % | 0.7200 | 308.225 | |||
| México | 393016 | 0.6353 | 8.66% | 7.9700 | 426.930 | |||
| AAAA | 384032 | 0.6207 | 8,46 % | 8.4700 | 438.155 | |||
| Un | 3188990 | 5.1546 | 70.24% | 57,9600 | 592.950 | |||
| ▾ Clase | 4540233 | 7.3387 | 100,00% | 84.7800 | 592.950 | |||
| EN | 4540233 | 7.3387 | 100,00% | 84.7800 | 592.950 | |||
| ▾ Estadísticas de servicio | 0 | 0.0000 | 100 % | - | - | |||
| tiempo de solicitud-respuesta (msec) | 2109677 | 277.18 | 0.020000 | 12000.532227 | 3.4100 | 38.0100 | 581.680 | |
| No. de respuestas no solicitadas | 25402 | 0.0411 | 5,1400 | 587.832 | ||||
| No. de retransmisiones | 37 | 0.0001 | 0.0300 | 275.702 | ||||
| ▾ Estadísticas de respuesta | 0 | 0.0000 | 100 % | - | - | |||
| No. de preguntas | 4244830 | 1.00 | 1 | 1 | 6.8612 | 77.0500 | 581.680 | |
| No. de autoridades | 4244830 | 0.39 | 0 | 11 | 6.8612 | 77.0500 | 581.680 | |
| No. de respuestas | 4244830 | 1.60 | 0 | 22 | 6,8612 | 77.0500 | 581.680 | |
| No. de elementos adicionales | 4244830 | 0,29 | 0 | 26 | 6.8612 | 77.0500 | 581.680 | |
| ▾ Estadísticas de consulta | 0 | 0.0000 | 100 % | - | - | |||
| Qname Len | 2405117 | 20.42 | 2 | 113 | 3,8876 | 49.1400 | 592.950 | |
| ▾ Estadísticas de etiquetas | 0 | 0.0000 | - | - | ||||
| 4º nivel o más | 836034 | 1.3513 | 16.1900 | 592.950 | ||||
| Tercer nivel | 1159513 | 1.8742 | 23.8900 | 592.950 | ||||
| 2º nivel | 374182 | 0.6048 | 8.7800 | 592.955 | ||||
| Primer nivel | 35388 | 0.0572 | 0.9200 | 294.492 | ||||
| Tamaño de carga | 4540233 | 89.87 | 17 | 1128 | 7.3387 | 100 % | 84.7800 | 592.950 |
El cuadro de diálogo indica que había un total combinado de aproximadamente 4,5 millones (4,540,233) paquetes, de los cuales el 2,68 % causó un error en el servidor. La diferencia en los porcentajes de paquetes de consulta y respuesta muestra que el 5,94 por ciento de las consultas (52,97 por ciento menos el 47,03 por ciento) no recibió una respuesta. El tiempo máximo de respuesta fue de 12 segundos (12 000,532227 milisegundos).
Si aplica el filtro de visualización para las respuestas de consulta que tardaron cinco segundos o más (dns.time >= 5), la mayoría de los paquetes de los resultados del filtro indicarán que se produjo un error en el servidor. Esto probablemente se debe a un error de "agotamiento del tiempo de espera" del cliente.
La tabla siguiente es un resumen de los resultados de captura.
| Capturar criterios de revisión | Sí | No |
|---|---|---|
| La diferencia entre las consultas DNS y las respuestas supera el dos por ciento. | ☑ | ☐ |
| La latencia de DNS es más de un segundo | ☑ | ☐ |
Paso 2 de solución de problemas: Desarrollo de una hipótesis
En esta sección se clasifican los tipos de problemas comunes para ayudarle a reducir los posibles problemas e identificar los componentes que podrían requerir ajustes. Este enfoque establece la base para crear un plan de acción dirigido para mitigar y resolver estos problemas de forma eficaz.
Códigos de respuesta DNS comunes
En la tabla siguiente se resumen los códigos de retorno DNS más comunes.
| Código de retorno DNS | Mensaje de retorno de DNS | Descripción |
|---|---|---|
RCODE:0 |
NOERROR |
La consulta DNS finalizó correctamente. |
RCODE:1 |
FORMERR |
Existe un error de formato de consulta DNS. |
RCODE:2 |
SERVFAIL |
El servidor no completó la solicitud DNS. |
RCODE:3 |
NXDOMAIN |
El nombre de dominio no existe. |
RCODE:5 |
REFUSED |
El servidor se negó a responder a la consulta. |
RCODE:8 |
NOTAUTH |
El servidor no es autoritativo para la zona. |
Tipos de problemas generales
En la tabla siguiente se enumeran las categorías de tipo de problema que le ayudan a desglosar los síntomas del problema.
| Tipo de problema | Descripción |
|---|---|
| Rendimiento | Los problemas de rendimiento de resolución de DNS pueden provocar errores intermitentes, como errores por "tiempo de espera" desde la perspectiva de un cliente. Estos problemas pueden producirse porque los nodos experimentan agotamiento de recursos o limitación de E/S. Además, las restricciones en los recursos de proceso de los pods de CoreDNS pueden provocar latencia de resolución. Si la latencia de CoreDNS es alta o aumenta con el tiempo, esto podría indicar un problema de carga. Si las instancias de CoreDNS están sobrecargadas, es posible que experimente problemas y retrasos en la resolución de nombres DNS, o puede que vea problemas en cargas de trabajo y servicios internos de Kubernetes. |
| Configuración | Los problemas de configuración pueden provocar una resolución DNS incorrecta. En este caso, es posible que experimente NXDOMAIN errores de tiempo de espera o "agotado". Las configuraciones incorrectas pueden producirse en CoreDNS, nodos, Kubernetes, enrutamiento, DNS de red virtual, zonas DNS privadas, firewalls, servidores proxy, etc. |
| Conectividad de red | Los problemas de conectividad de red pueden afectar a la conectividad de pod a pod (tráfico este-oeste) o la conectividad de pod y nodo a recursos externos (tráfico norte-sur). Este escenario puede provocar errores de "tiempo agotado". Los problemas de conectividad pueden producirse si los puntos de conexión de servicio coreDNS no están actualizados (por ejemplo, debido a problemas de kube-proxy, problemas de enrutamiento, pérdida de paquetes, etc.). La dependencia de recursos externos combinada con problemas de conectividad (por ejemplo, dependencia en servidores DNS personalizados o servidores DNS externos) también puede contribuir al problema. |
Entradas necesarias
Antes de formular una hipótesis de causas probables del problema, resuma los resultados de los pasos anteriores del flujo de trabajo de solución de problemas.
Puede recopilar los resultados mediante las tablas siguientes.
Resultados de la plantilla de cuestionario de línea base
| Pregunta | Posibles respuestas |
|---|---|
| ¿Dónde se produce un error en la resolución DNS? | ☐ Cápsula ☐ Nodo ☐ Tanto pod como nodo |
| ¿Qué tipo de error DNS obtienes? | ☐ Se agota el tiempo de espera ☐ NXDOMAIN ☐ Otro error DNS |
| ¿Con qué frecuencia se producen los errores dns? | ☐ Siempre ☐ Intermitentemente ☐ En un patrón específico |
| ¿Qué registros se ven afectados? | ☐ Un dominio específico ☐ Cualquier dominio |
| ¿Existen configuraciones DE DNS personalizadas? | ☐ Servidores DNS personalizados en una red virtual ☐ Configuración de CoreDNS personalizada |
Resultados de pruebas en diferentes niveles
| Resultados de pruebas de resolución | Obras | Errores |
|---|---|---|
| Del pod al servicio CoreDNS | ☐ | ☐ |
| Dirección IP del pod al pod CoreDNS | ☐ | ☐ |
| De pod a DNS interno de Azure | ☐ | ☐ |
| Desde el pod al DNS de la red virtual | ☐ | ☐ |
| De nodo a DNS interno de Azure | ☐ | ☐ |
| De nodo a DNS de red virtual | ☐ | ☐ |
Resultados del estado y el rendimiento de los nodos y los pods de CoreDNS
| Resultados de la revisión del rendimiento | Saludable | Insalubre |
|---|---|---|
| Rendimiento de nodos | ☐ | ☐ |
| Rendimiento de pods de CoreDNS | ☐ | ☐ |
Resultados de la captura de tráfico y del rendimiento de la resolución DNS
| Criterios para la revisión de capturas | Sí | No |
|---|---|---|
| La diferencia entre las consultas DNS y las respuestas supera el dos por ciento. | ☐ | ☐ |
| La latencia de DNS es más de un segundo | ☐ | ☐ |
Mapeo de insumos requeridos a tipos de problemas
Para desarrollar la primera hipótesis, asigne cada uno de los resultados de las entradas necesarias a uno o varios de los tipos de problemas. Al analizar estos resultados en el contexto de los tipos de problemas, puede desarrollar hipótesis sobre las posibles causas principales de los problemas de resolución de DNS. A continuación, puede crear un plan de acción de investigación y solución de problemas específicos.
Punteros de mapeo de tipos de error
Si los resultados de la prueba muestran errores de resolución DNS en el servicio CoreDNS, o contienen errores de "tiempo de espera" al intentar llegar a puntos de conexión específicos, es posible que existan problemas de configuración o conectividad.
Las indicaciones de escasez de recursos informáticos a nivel de pod o nodo de CoreDNS podrían sugerir problemas de rendimiento.
Las capturas DNS que tienen una discrepancia considerable entre las consultas DNS y las respuestas DNS pueden indicar que se pierden paquetes. Este escenario sugiere que hay problemas de conectividad o rendimiento.
La presencia de configuraciones personalizadas en el nivel de red virtual o de Kubernetes puede contener configuraciones que no funcionan con AKS y CoreDNS según lo previsto.
Paso 3 de solución de problemas: Crear e implementar un plan de acción
Ahora debería tener suficiente información para crear e implementar un plan de acción. Las secciones siguientes contienen recomendaciones adicionales para formular el plan para tipos de problemas específicos.
Problemas de rendimiento
Si está tratando con problemas de rendimiento de resolución de DNS, revise e implemente los siguientes procedimientos recomendados e instrucciones.
| Procedimiento recomendado | Orientación |
|---|---|
| Configure un grupo de nodos del sistema dedicado que cumpla los requisitos mínimos de tamaño. | Administración de grupos de nodos del sistema en Azure Kubernetes Service (AKS) |
| Para evitar la limitación de E/S de disco, use nodos que tengan discos de sistema operativo efímeros. | Ajuste de tamaño predeterminado del disco del sistema operativo y problema 1373 de GitHub en Azure AKS |
| Siga los procedimientos recomendados de administración de recursos en las cargas de trabajo dentro de los nodos. | Procedimientos recomendados para desarrolladores de aplicaciones para administrar recursos en Azure Kubernetes Services (AKS) |
Si el rendimiento de DNS todavía no es lo suficientemente bueno después de realizar estos cambios, considere la posibilidad de usar EL DNS local del nodo.
Problemas de configuración
En función del componente, debe revisar y comprender las implicaciones de la configuración específica. Consulte la siguiente lista de documentación específica del componente para obtener detalles de configuración:
- Opciones de configuración de DNS de Kubernetes
- Opciones de configuración personalizadas de AKS CoreDNS
- Zonas DNS privadas sin un vínculo a la red virtual
Problemas de conectividad de red
Los errores que implican la interfaz de red de contenedor (CNI) u otros componentes de Kubernetes o del sistema operativo suelen requerir la intervención del soporte técnico de AKS o del grupo de productos de AKS.
Los problemas de infraestructura, como errores de hardware o problemas de hipervisor, pueden requerir la colaboración de los equipos de soporte técnico de infraestructura. Como alternativa, estos problemas pueden tener características de recuperación automática.
Paso 4 de solución de problemas: Observar los resultados y extraer conclusiones
Observe los resultados de la implementación del plan de acción. En este momento, el plan de acción debe ser capaz de corregir o mitigar el problema.
Paso 5 de solución de problemas: Repetir según sea necesario
Si estos pasos de solución de problemas no resuelven el problema, repita los pasos de solución de problemas según sea necesario.
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.
Descargo de responsabilidad sobre contacto con terceros
Microsoft proporciona información de contacto de terceros para ayudarle a encontrar información adicional sobre este tema. Esta información de contacto puede cambiar sin previo aviso. Microsoft no garantiza la exactitud de la información de contacto de terceros.
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.