Risolvere i problemi di risoluzione DNS in AKS

Questo articolo illustra come creare un flusso di lavoro per la risoluzione dei problemi di risoluzione dei nomi di dominio (DNS) nel servizio Azure Kubernetes.

Prerequisiti

• Lo strumento da riga di comando Kubernetes kubectl

  Nota: per installare kubectl usando l'interfaccia della riga di comando di Azure, eseguire il comando az aks install-cli .

• Utilità da riga di comando per la ricerca DNS

• Strumento da riga di comando grep per la ricerca di testo

• Analizzatore pacchetti di rete Wireshark

Elenco di controllo per la risoluzione dei problemi

La risoluzione dei problemi DNS in Azure Kubernetes Service è generalmente un processo complesso. È possibile perdersi facilmente in molti passaggi diversi senza mai vedere un percorso chiaro in avanti. Per semplificare e rendere il processo più semplice ed efficace, utilizzare il metodo "scientifico" per organizzare il lavoro:

• Passaggio 1: Raccogliere i fatti.

• Passaggio 2. Sviluppare un'ipotesi.

• Passaggio 3. Creare e implementare un piano di azione.

• Passaggio 4. Osservare i risultati e trarre conclusioni.

• Passaggio 5. Ripetere in base alle esigenze.

Passaggio 1 per la risoluzione dei problemi: Raccogliere i fatti

Per comprendere meglio il contesto del problema, raccogliere informazioni sul problema DNS specifico. Usando le domande di base seguenti come punto di partenza, è possibile descrivere la natura del problema, riconoscere i sintomi e identificare l'ambito del problema.

Domanda	Risposte possibili
Dove fallisce la risoluzione DNS?	Baccello nodo Sia i pod che i nodi
Che tipo di errore DNS ottieni?	Timeout Nessun host di questo tipo Altro errore DNS
Con quale frequenza si verificano gli errori DNS?	Sempre Ad intermittenza In un modello specifico
Quali record sono interessati?	Un dominio specifico Qualsiasi dominio
Esistono configurazioni DNS personalizzate?	Server DNS personalizzato configurato nella rete virtuale DNS personalizzato nella configurazione CoreDNS
Che tipo di problemi di prestazioni interessano i nodi?	CPU (unità centrale di elaborazione) Memoria Limitazione della velocità di I/O
Che tipo di problemi di prestazioni influiscono sui pod CoreDNS?	CPU (unità centrale di elaborazione) Memoria Limitazione delle richieste di I/O
Che cosa causa la latenza DNS?	Query DNS che richiedono troppo tempo per ricevere una risposta (più di cinque secondi)

Per ottenere risposte migliori a queste domande, seguire questo processo in tre parti.

Parte 1: Generare test a livelli diversi che riproducono il problema

Il processo di risoluzione DNS per i pod nel servizio Azure Kubernetes (AKS) prevede diversi livelli. Esaminare questi livelli per isolare il problema. I livelli seguenti sono tipici:

• Pod CoreDNS
• Servizio CoreDNS
• Nodi
• DNS della rete virtuale

Per iniziare il processo, eseguire test da un pod di prova su ogni livello.

Testare la risoluzione DNS a livello di pod CoreDNS

1. Distribuire un pod di test per eseguire query di test DNS eseguendo il comando seguente:

   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"]
   EOF
   

2. Recuperare gli indirizzi IP dei pod CoreDNS eseguendo il comando kubectl get seguente:

   kubectl get pod --namespace kube-system --selector k8s-app=kube-dns --output wide
   

3. Connettersi al pod di test usando il kubectl exec -it aks-test -- bash comando e testare la risoluzione DNS su ogni indirizzo IP del pod CoreDNS eseguendo i comandi seguenti:

   # 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
   

Per altre informazioni sulla risoluzione dei problemi di risoluzione DNS a livello di pod, vedere Risolvere gli errori di risoluzione DNS dall'interno del pod.

Testare la risoluzione DNS a livello di servizio CoreDNS

1. Recuperare l'indirizzo IP del servizio CoreDNS eseguendo il comando seguente kubectl get :

   kubectl get service kube-dns --namespace kube-system
   

2. Nel pod di test eseguire i comandi seguenti sull'indirizzo IP del servizio 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
   

Testare la risoluzione DNS a livello di nodo

1. Connettersi al nodo.

2. Eseguire il comando seguente grep per recuperare l'elenco dei server DNS upstream configurati:

   grep ^nameserver /etc/resolv.conf
   

3. Eseguire i comandi di testo seguenti per ogni DNS configurato nel 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
   

Testare la risoluzione DNS a livello di DNS della rete virtuale

Esaminare la configurazione del server DNS della rete virtuale e determinare se i server possono risolvere il record in questione.

Parte 2: Esaminare l'integrità e le prestazioni dei pod e dei nodi CoreDNS

Esaminare l'integrità e le prestazioni dei pod CoreDNS

È possibile usare kubectl i comandi per controllare l'integrità e le prestazioni dei pod CoreDNS. A tale scopo, seguire questa procedura:

1. Verificare che i CoreDNS pod siano in esecuzione.

   kubectl get pods -l k8s-app=kube-dns -n kube-system
   

2. Controllare se i pod CoreDNS sono sovrausati:

   kubectl top pods -n kube-system -l k8s-app=kube-dns
   

   NAME                      CPU(cores)   MEMORY(bytes)
   coredns-dc97c5f55-424f7   3m           23Mi
   coredns-dc97c5f55-wbh4q   3m           25Mi
   

3. Ottenere i nodi che ospitano i pod CoreDNS:

   kubectl get pods -n kube-system -l k8s-app=kube-dns -o jsonpath='{.items[*].spec.nodeName}'
   

4. Verificare che i nodi non siano sovrautilati:

   kubectl top nodes
   

5. Verifica i log dei pod CoreDNS.

   kubectl logs -l k8s-app=kube-dns -n kube-system
   

Annotazioni

Per ottenere altre informazioni di debug, abilitare i log dettagliati in CoreDNS. A tale scopo, vedere Risoluzione dei problemi di personalizzazione di CoreDNS in AKS.

Esaminare l'integrità e le prestazioni dei nodi

Potresti notare inizialmente i problemi di prestazioni della risoluzione DNS come errori intermittenti, ad esempio timeout. Le cause principali di questo problema includono l'esaurimento delle risorse e la limitazione delle I/O nei nodi che ospitano i pod CoreDNS o il pod client.

Per verificare se si verifica l'esaurimento delle risorse o la limitazione delle operazioni di I/O, eseguire il comando kubectl describe seguente insieme al grep comando nei nodi. Questa serie di comandi consente di esaminare il conteggio delle richieste e confrontarlo con il limite per ogni risorsa. Se la percentuale limite è superiore al 100% per una risorsa, tale risorsa viene sovracommessa.

kubectl describe node | grep -A5 '^Name:\|^Allocated resources:' | grep -v '.kubernetes.io\|^Roles:\|Labels:'

Il frammento di codice seguente mostra l'output di esempio di questo 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)

Per ottenere un quadro migliore dell'utilizzo delle risorse a livello di pod e nodo, è anche possibile usare Informazioni dettagliate sui contenitori e altri strumenti nativi del cloud in Azure. Per altre informazioni, vedere Monitorare i cluster Kubernetes usando i servizi di Azure e gli strumenti nativi del cloud.

Parte 3: Analizzare il traffico DNS ed esaminare le prestazioni di risoluzione DNS

L'analisi del traffico DNS consente di comprendere in che modo il cluster del servizio Azure Kubernetes gestisce le query DNS. Idealmente, è consigliabile riprodurre il problema in un pod di test mentre si acquisisce il traffico da questo pod di test e in ognuno dei pod CoreDNS.

Esistono due modi principali per analizzare il traffico DNS:

• Uso di strumenti di analisi DNS in tempo reale, ad esempio Gadget inspektor, per analizzare il traffico DNS in tempo reale.
• Usando strumenti di acquisizione del traffico, ad esempio Retina Capture e Dumpy, per raccogliere il traffico DNS e analizzarlo con uno strumento di analizzatore pacchetti di rete, ad esempio Wireshark.

Entrambi gli approcci mirano a comprendere l'integrità e le prestazioni delle risposte DNS usando codici di risposta DNS, tempi di risposta e altre metriche. Scegli quello più adatto alle tue esigenze.

Analisi del traffico DNS in tempo reale

È possibile usare Inspektor Gadget per analizzare il traffico DNS in tempo reale. Per installare Inspektor Gadget nel tuo cluster, vedere Come installare Inspektor Gadget in un cluster AKS.

Per tracciare il traffico DNS in tutti gli spazi dei nomi, usare il comando seguente:

# 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"

Dove --fields è un elenco delimitato da virgole di campi da visualizzare. L'elenco seguente descrive i campi usati nel comando :

• src: l'origine della richiesta con informazioni Kubernetes (<kind>/<namespace>/<name>:<port>).
• dst: destinazione della richiesta con le informazioni di Kubernetes (<kind>/<namespace>/<name>:<port>).
• name: nome della richiesta DNS.
• Il flag di query/risposta.
• qtype: tipo della richiesta DNS.
• id: ID della richiesta DNS, che viene usata per trovare la corrispondenza con la richiesta e la risposta.
• rcode: codice di risposta della richiesta DNS.
• latency_ns: latenza della richiesta DNS.

L'output del comando è simile al seguente:

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

È possibile usare il ID campo per identificare se una query ha una risposta. Il RCODE campo mostra il codice di risposta della richiesta DNS. Il LATENCY_NS campo mostra la latenza della richiesta DNS in nanosecondi. Questi campi consentono di comprendere l'integrità e le prestazioni delle risposte DNS. Per ulteriori informazioni sull'analisi DNS in tempo reale, vedere Risolvere gli errori DNS in un cluster di AKS in tempo reale.

Acquisire il traffico DNS

Questa sezione illustra come usare Dumpy per raccogliere le acquisizioni del traffico DNS da ogni pod CoreDNS e da un pod DNS client (in questo caso il aks-test pod).

Per raccogliere le acquisizioni dal pod client di test, eseguire il comando seguente:

kubectl dumpy capture pod aks-test -f "-i any port 53" --name dns-cap1-aks-test

Per raccogliere le acquisizioni per i pod CoreDNS, eseguire il comando Dumpy seguente:

kubectl dumpy capture deploy coredns \
    -n kube-system \
    -f "-i any port 53" \
    --name dns-cap1-coredns

Idealmente, dovresti eseguire acquisizioni quando il problema si verifica. Questo requisito indica che potrebbero essere in esecuzione acquisizioni diverse per quantità di tempo diverse, a seconda della frequenza con cui è possibile riprodurre il problema. Per raccogliere le acquisizioni, eseguire i comandi seguenti:

mkdir dns-captures
kubectl dumpy export dns-cap1-aks-test ./dns-captures
kubectl dumpy export dns-cap1-coredns ./dns-captures -n kube-system

Per eliminare i pod Dumpy, eseguire il comando Dumpy seguente:

kubectl dumpy delete dns-cap1-coredns -n kube-system
kubectl dumpy delete dns-cap1-aks-test

Per unire tutte le acquisizioni di pod CoreDNS, usare lo strumento da riga di comando mergecap per unire i file di acquisizione. Lo mergecap strumento è incluso nello strumento di analizzatore pacchetti di rete Wireshark. Eseguire il comando mergecap seguente:

mergecap -w coredns-cap1.pcap dns-cap1-coredns-<coredns-pod-name-1>.pcap dns-cap1-coredns-<coredns-pod-name-2>.pcap [...]

Analisi dei pacchetti DNS per un singolo pod CoreDNS

Dopo aver generato e unito i file di acquisizione del traffico, è possibile eseguire un'analisi dei pacchetti DNS dei file di acquisizione in Wireshark. Seguire questa procedura per visualizzare l'analisi dei pacchetti per il traffico di un singolo pod CoreDNS:

1. Selezionare Start, immettere Wireshark e quindi selezionare Wireshark nei risultati della ricerca.

2. Nella finestra Wireshark selezionare il menu File e quindi selezionare Apri.

3. Passare alla cartella contenente i file di acquisizione, selezionare dns-cap1-db-check-db-check-pod-name.pcap<> (file di acquisizione lato client per un singolo pod CoreDNS) e quindi selezionare il pulsante Apri.

4. Selezionare il menu Statistiche e quindi DNS. Viene visualizzata la finestra di dialogo Wireshark - DNS e viene visualizzata un'analisi del traffico DNS. Il contenuto della finestra di dialogo è illustrato nella tabella seguente.

   Argomento/Elemento	Conteggio	Medio	Min Val	Max Val	Frequenza (ms)	Percento	Frequenza di Esplosione	Inizio esplosione
   ▾ Pacchetti totali	1066				0.0017	100%	0.1200	0,000
   ▾ rcode	1066				0.0017	100,00%	0.1200	0,000
   Errore del server	17				0.0000	1.59%	0.0100	99.332
   Nessun nome di questo tipo	353				0.0006	33.11%	0.0400	0,000
   Nessun errore	696				0.0011	65.29%	0,0800	0,000
   ▾ codici operativi	1066				0.0017	100,00%	0.1200	0,000
   Query standard	1066				0.0017	100,00%	0.1200	0,000
   ▾ Interrogazione/Risposta	1066				0.0017	100,00%	0.1200	0,000
   risposta	531				0.0009	49.81%	0,0600	0,000
   Quesito	535				0.0009	50.19%	0,0600	0,000
   ▾ Tipo di query	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
   Classe ▾	1066				0.0017	100,00%	0.1200	0,000
   IN	1066				0.0017	100,00%	0.1200	0,000
   ▾ Statistiche del servizio	0				0.0000	100%	-	-
   tempo di risposta richiesta (msec)	531	184.42	0.067000	6308.503906	0.0009		0,0600	0,000
   No. di risposte non richieste	0				0.0000		-	-
   No. di ritrasmissioni	0				0.0000		-	-
   ▾ Statistiche di risposta	0				0.0000	100%	-	-
   No. di domande	1062	1,00	1	1	0.0017		0,1200	0,000
   No. delle autorità	1062	0.82	0	1	0.0017		0.1200	0,000
   No. di risposte	1062	0.15	0	1	0.0017		0.1200	0,000
   no. di elementi aggiuntivi	1062	0,00	0	0	0.0017		0.1200	0,000
   ▾ Statistiche query	0				0.0000	100%	-	-
   Qname Len	535	32,99	14	66	0.0009		0,0600	0,000
   ▾ Statistiche dell'etichetta	0				0.0000		-	-
   4° livello o più	365				0.0006		0.0400	0,000
   Terzo livello	170				0.0003		0.0200	0,000
   Secondo livello	0				0.0000		-	-
   Primo livello	0				0.0000		-	-
   Dimensioni del carico utile	1066	92.87	32	194	0.0017	100%	0.1200	0,000

La finestra di dialogo Analisi DNS in Wireshark mostra un totale di 1.066 pacchetti. Di questi pacchetti, il 17 (1,59%) ha causato un errore del server. Inoltre, il tempo di risposta massimo è stato di 6.308 millisecondi (6,3 secondi) e non è stata ricevuta alcuna risposta per lo 0,38% delle query. Questo totale è stato calcolato sottraendo il 49,81% dei pacchetti che contengono risposte dal 50,19% dei pacchetti che contengono query.

Se si immette (dns.flags.response == 0) && ! dns.response_in come filtro di visualizzazione in Wireshark, questo filtro visualizza le query DNS che non hanno ricevuto una risposta, come illustrato nella tabella seguente.

No	Tempo	Fonte	Destinazione	Protocollo	Durata	Informazioni
225	2024-04-01 16:50:40.000520	10.0.0.21	172.16.0.10	Sistema dei Nomi di Dominio (DNS)	80	Query standard 0x2c67 AAAA db.contoso.com
426	2024-04-01 16:52:47.419907	10.0.0.21	172.16.0.10	Sistema dei Nomi di Dominio (DNS)	132	Query standard 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	Sistema dei Nomi di Dominio (DNS)	132	Query standard 0xbcb0 un db.contoso.com.iosffyoulcwehgo1g3egb3m4oc.jx.internal.cloudapp.net
768	2024-04-01 16:56:06.512464	10.0.0.21	172.16.0.10	Sistema dei Nomi di Dominio (DNS)	80	Query standard 0xe330 di db.contoso.com

Inoltre, la barra di stato wireshark visualizza il testo Pacchetti: 1066 - Visualizzato: 4 (0,4%). Queste informazioni indicano che quattro pacchetti di 1.066 o 0,4% erano query DNS che non hanno mai ricevuto una risposta. Questa percentuale corrisponde essenzialmente al totale dello 0,38% calcolato in precedenza.

Se si modifica il filtro di visualizzazione in dns.time >= 5, il filtro mostra i pacchetti di risposta di query che hanno richiesto cinque secondi o più per essere ricevuti, come illustrato nella tabella aggiornata.

No	Tempo	Fonte	Destinazione	Protocollo	Durata	Informazioni	SourcePort	RRs aggiuntive	tempo di risposta DNS
213	2024-04-01 16:50:32.644592	172.16.0.10	10.0.0.21	Sistema dei Nomi di Dominio (DNS)	132	Errore di query standard 0x9312 Guasto del server 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	Sistema dei Nomi di Dominio (DNS)	80	Errore di query standard 0xe5ce Server A db.contoso.com	53	0	6.065555
328	2024-04-01 16:51:55.113619	172.16.0.10	10.0.0.21	Sistema dei Nomi di Dominio (DNS)	132	Errore di query standard 0x6681 Errore del server 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	Sistema dei Nomi di Dominio (DNS)	80	Errore del server query standard 0x6cf6 A db.contoso.com	53	0	6,500504
541	2024-04-01 16:53:53.423838	172.16.0.10	10.0.0.21	Sistema dei Nomi di Dominio (DNS)	80	Errore di query standard 0x07b3 Server AAAA db.contoso.com	53	0	6.022195
553	2024-04-01 16:54:05.165234	172.16.0.10	10.0.0.21	Sistema dei Nomi di Dominio (DNS)	132	Errore di query standard 0x1ea0 Guasto del server 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	Sistema dei Nomi di Dominio (DNS)	80	Query standard 0xa20f Errore del server AAAA db.contoso.com	53	0	6.014926
891	2024-04-01 16:56:44.442334	172.16.0.10	10.0.0.21	Sistema dei Nomi di Dominio (DNS)	132	Errore di query standard 0xa279 errore del server A db.contoso.com.iosffyoulcwehgo1g3egb3m4oc.jx.internal.cloudapp.net	53	0	6.044552

Dopo aver modificato il filtro di visualizzazione, la barra di stato viene aggiornata per visualizzare il testo Pacchetti: 1066 - Visualizzato: 8 (0,8%). Pertanto, otto dei pacchetti 1.066 o 0,8% sono state risposte DNS che hanno richiesto cinque secondi o più per essere ricevute. Nella maggior parte dei client, tuttavia, il valore di timeout DNS predefinito dovrebbe essere di cinque secondi. Ciò significa che, anche se i pod CoreDNS hanno elaborato e recapitato le otto risposte, il client ha già terminato la sessione inviando un messaggio di errore "timeout". La colonna Info nei risultati filtrati mostra che tutti e otto i pacchetti hanno causato un errore del server.

Analisi dei pacchetti DNS per tutti i pod CoreDNS

In Wireshark aprire il file di acquisizione dei pod CoreDNS uniti in precedenza (coredns-cap1.pcap) e quindi aprire l'analisi DNS, come descritto nella sezione precedente. Viene visualizzata una finestra di dialogo Wireshark che visualizza la tabella seguente.

Argomento/Elemento	Conteggio	Medio	Min Val	Max Val	Frequenza (ms)	Percento	Frequenza di Esplosione	Inizio esplosione
▾ Pacchetti totali	4540233				7.3387	100%	84.7800	592.950
▾ rcode	4540233				7.3387	100,00%	84.7800	592.950
Errore del server	121781				0.1968	2.68%	8.4600	599.143
Nessun nome di questo tipo	574658				0.9289	12,66%	10,9800	592.950
Nessun errore	3843794				6,2130	84.66%	73.2500	592.950
▾ codici operativi	4540233				7.3387	100,00%	84.7800	592.950
Query standard	4540233				7.3387	100,00%	84.7800	592.950
▾ Interrogazione/Risposta	4540233				7.3387	100,00%	84.7800	592.950
risposta	2135116				3.4512	47.03%	39.0400	581.680
Quesito	2405117				3,8876	52.97%	49.1400	592.950
▾ Tipo di query	4540233				7.3387	100,00%	84.7800	592.950
SRV	3647				0.0059	0,08%	0.1800	586.638
Tabella PTR	554630				0.8965	12.22%	11.5400	592.950
NS	15918				0.0257	0,35%	0.7200	308.225
Messico	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
Classe ▾	4540233				7.3387	100,00%	84.7800	592.950
IN	4540233				7.3387	100,00%	84.7800	592.950
▾ Statistiche del servizio	0				0.0000	100%	-	-
tempo di risposta richiesta (msec)	2109677	277.18	0.020000	12000.532227	3.4100		38.0100	581.680
No. di risposte non richieste	25402				0.0411		5.1400	587.832
No. di ritrasmissioni	37				0.0001		0.0300	275.702
▾ Statistiche di risposta	0				0.0000	100%	-	-
No. di domande	4244830	1,00	1	1	6.8612		77.0500	581.680
No. delle autorità	4244830	0,39	0	11	6.8612		77.0500	581.680
No. di risposte	4244830	1.60	0	22	6.8612		77.0500	581.680
No. di elementi aggiuntivi	4244830	0,29	0	26	6,8612		77.0500	581.680
▾ Statistiche query	0				0.0000	100%	-	-
Qname Len	2405117	20.42	2	113	3,8876		49.1400	592.950
▾ Statistiche dell'etichetta	0				0.0000		-	-
4° livello o più	836034				1.3513		16.1900	592.950
Terzo livello	1159513				1.8742		23.8900	592.950
Secondo livello	374182				0.6048		8.7800	592.955
Primo livello	35388				0.0572		0.9200	294.492
Dimensioni del carico utile	4540233	89.87	17	1128	7.3387	100%	84.7800	592.950

La finestra di dialogo indica che sono presenti un totale combinato di circa 4,5 milioni di pacchetti (4.540.233), di cui il 2,68% ha causato un errore del server. La differenza nelle percentuali di query e pacchetti di risposta indica che il 5,94% delle query (52,97% meno il 47,03%) non ha ricevuto una risposta. Il tempo di risposta massimo è stato di 12 secondi (12.000,532227 millisecondi).

Se si applica il filtro di visualizzazione per le risposte di query che hanno richiesto cinque secondi o più (dns.time >= 5), la maggior parte dei pacchetti nei risultati del filtro indicherà che si è verificato un errore del server. Questo è probabilmente dovuto a un errore di timeout del client.

La tabella seguente è un riepilogo dei risultati dell'acquisizione.

Registrare i criteri di revisione	Sì	NO
La differenza tra query DNS e risposte supera il 2%	☑	☐
La latenza DNS è superiore a un secondo	☑	☐

Passaggio 2 per la risoluzione dei problemi: Sviluppare un'ipotesi

Questa sezione classifica i tipi di problemi comuni per ridurre i potenziali problemi e identificare i componenti che potrebbero richiedere modifiche. Questo approccio imposta le basi per la creazione di un piano di azione mirato per attenuare e risolvere questi problemi in modo efficace.

Codici di risposta DNS comuni

La tabella seguente riepiloga i codici restituiti DNS più comuni.

Codice di ritorno DNS	Messaggio di risposta DNS	Descrizione
RCODE:0	NOERROR	La query DNS è stata completata correttamente.
RCODE:1	FORMERR	L'errore di formattazione della query DNS esiste.
RCODE:2	SERVFAIL	Il server non ha completato la richiesta DNS.
RCODE:3	NXDOMAIN	Il nome di dominio non esiste.
RCODE:5	REFUSED	Il server ha rifiutato di rispondere alla query.
RCODE:8	NOTAUTH	Il server non è autorevole per la zona.

Tipi di problemi generali

Nella tabella seguente sono elencate le categorie di tipi di problema che consentono di suddividere i sintomi del problema.

Tipo di problema	Descrizione
Prestazioni	I problemi di prestazioni della risoluzione DNS possono causare errori intermittenti, ad esempio errori di timeout dal punto di vista di un client. Questi problemi possono verificarsi perché i nodi riscontrano l'esaurimento delle risorse o la limitazione delle operazioni di I/O. Inoltre, i vincoli sulle risorse di calcolo nei pod CoreDNS possono causare latenza di risoluzione. Se la latenza CoreDNS è elevata o aumenta nel tempo, questo potrebbe indicare un problema di carico. Se si esegue l'overload delle istanze CoreDNS, potrebbero verificarsi problemi e ritardi nella risoluzione dei nomi DNS oppure potrebbero verificarsi problemi nei carichi di lavoro e nei servizi interni Kubernetes.
Configurazione	I problemi di configurazione possono causare una risoluzione DNS errata. In questo caso, potresti riscontrare errori NXDOMAIN o di "timeout". Le configurazioni non corrette possono verificarsi in CoreDNS, nodi, Kubernetes, routing, DNS di rete virtuale, zone DNS private, firewall, proxy e così via.
Connettività di rete	I problemi di connettività di rete possono influire sulla connettività da pod a pod (traffico east-west) o sulla connettività tra pod e nodo alle risorse esterne (traffico north-south). Questo scenario può causare errori di timeout. I problemi di connettività possono verificarsi se gli endpoint di servizio CoreDNS non sono aggiornati, ad esempio a causa di problemi relativi al proxy kube, problemi di routing, perdita di pacchetti e così via. La dipendenza delle risorse esterne combinata con i problemi di connettività (ad esempio, la dipendenza da server DNS personalizzati o server DNS esterni) può contribuire anche al problema.

Input necessari

Prima di formulare un'ipotesi delle cause probabili per il problema, riepilogare i risultati dei passaggi precedenti del flusso di lavoro per la risoluzione dei problemi.

È possibile raccogliere i risultati usando le tabelle seguenti.

Risultati del modello di questionario di base

Domanda	Risposte possibili
Dove fallisce la risoluzione DNS?	☐ Pod ☐ Nodo ☐ Sia pod che nodo
Che tipo di errore DNS ricevi?	☒ Tempo scaduto ☐ NXDOMAIN ☐ Altro errore DNS
Con quale frequenza si verificano gli errori DNS?	☐ Sempre ☐ Intermittentemente ☐ In un modello specifico
Quali record sono interessati?	☐ Un dominio specifico ☐ Qualsiasi dominio
Esistono configurazioni DNS personalizzate?	☐ Server DNS personalizzati in una rete virtuale ☐ Configurazione coreDNS personalizzata

Risultati dei test a livelli diversi

Risultati dei test di risoluzione	Opere	Ha esito negativo
Dal pod al servizio CoreDNS	☐	☐
Dal pod all'indirizzo IP del pod CoreDNS	☐	☐
Da pod a DNS interno di Azure	☐	☐
Da pod a DNS di rete virtuale	☐	☐
Da nodo a DNS interno di Azure	☐	☐
Da nodo a DNS di rete virtuale	☐	☐

Risultati dell'integrità e delle prestazioni dei nodi e dei pod CoreDNS

Risultati della revisione delle prestazioni	Sano	Non salutare
Prestazioni dei nodi	☐	☐
Prestazioni dei pod CoreDNS	☐	☐

Risultati delle acquisizioni del traffico e delle prestazioni di risoluzione DNS

Acquisire i criteri di revisione	Sì	NO
La differenza tra query DNS e risposte supera il 2%	☐	☐
La latenza DNS è superiore a un secondo	☐	☐

Associare gli input necessari ai tipi di problema

Per sviluppare la prima ipotesi, eseguire il mapping di ognuno dei risultati degli input necessari a uno o più tipi di problema. Analizzando questi risultati nel contesto dei tipi di problema, è possibile sviluppare ipotesi sulle possibili cause radice dei problemi di risoluzione DNS. È quindi possibile creare un piano d'azione per l'analisi e la risoluzione dei problemi mirati.

Puntatori dei tipi di errore nella mappatura

• Se i risultati dei test mostrano errori di risoluzione DNS nel servizio CoreDNS o contengono errori di "timeout" quando si tenta di raggiungere endpoint specifici, potrebbero verificarsi problemi di configurazione o connettività.

• Le indicazioni di esaurimento delle risorse di calcolo a livello di pod o nodo CoreDNS potrebbero suggerire problemi di prestazioni di sistema.

• Le acquisizioni DNS che presentano una notevole mancata corrispondenza tra le query DNS e le risposte DNS possono indicare che i pacchetti vengono persi. Questo scenario suggerisce che sono presenti problemi di connettività o prestazioni.

• La presenza di configurazioni personalizzate a livello di rete virtuale o a livello di Kubernetes può contenere configurazioni che non funzionano con AKS e CoreDNS come previsto nel loro funzionamento.

Passaggio 3 per la risoluzione dei problemi: Creare e implementare un piano di azione

È ora necessario disporre di informazioni sufficienti per creare e implementare un piano di azione. Le sezioni seguenti contengono raccomandazioni aggiuntive per formulare il piano per tipi di problemi specifici.

Problemi di prestazioni

Se stai affrontando problemi di prestazioni della risoluzione DNS, esamina e implementa le migliori pratiche e le indicazioni seguenti.

Procedura consigliata	Indicazioni
Configurare un pool di nodi di sistema dedicato che soddisfi i requisiti minimi di dimensionamento.	Gestire i pool di nodi di sistema nel servizio Azure Kubernetes
Per evitare la limitazione delle operazioni di I/O su disco, usare i nodi con dischi OS effimeri.	Ridimensionamento predefinito del disco del sistema operativo e problema gitHub 1373 nel servizio Azure Kubernetes
Seguire le procedure consigliate per la gestione delle risorse nei carichi di lavoro all'interno dei nodi.	Procedure consigliate per gli sviluppatori di applicazioni per la gestione delle risorse nel servizio Azure Kubernetes (AKS)

Se le prestazioni DNS non sono ancora sufficienti dopo aver apportato queste modifiche, prendere in considerazione l'uso del DNS locale del nodo.

Problemi di configurazione

A seconda del componente, è necessario esaminare e comprendere le implicazioni della configurazione specifica. Per informazioni dettagliate sulla configurazione, vedere l'elenco seguente della documentazione specifica del componente:

• Opzioni di configurazione DNS kubernetes
• Opzioni di configurazione personalizzate di AKS CoreDNS
• Zone DNS private prive di un collegamento di rete virtuale

Problemi di connettività di rete

• I bug che coinvolgono l'interfaccia CNI (Container Networking Interface) o altri componenti kubernetes o del sistema operativo richiedono in genere l'intervento del supporto del servizio Azure Kubernetes o del gruppo di prodotti del servizio Azure Kubernetes.

• I problemi di infrastruttura, ad esempio errori hardware o problemi dell'hypervisor, potrebbero richiedere la collaborazione da parte dei team di supporto dell'infrastruttura. In alternativa, questi problemi potrebbero avere funzionalità di riparazione automatica.

Passaggio 4 per la risoluzione dei problemi: Osservare i risultati e trarre conclusioni

Osservare i risultati dell'implementazione del piano d'azione. A questo punto, il piano d'azione deve essere in grado di risolvere o attenuare il problema.

Passaggio 5 per la risoluzione dei problemi: ripetere in base alle esigenze

Se questi passaggi per la risoluzione dei problemi non risolvono il problema, ripetere i passaggi per la risoluzione dei problemi in base alle esigenze.

Clausola di esclusione della responsabilità per informazioni di terze parti

I prodotti di terze parti illustrati in questo articolo sono prodotti da aziende indipendenti da Microsoft. Microsoft non offre alcuna garanzia, implicita o espressa, sulle prestazioni o sull'affidabilità di questi prodotti.

Clausola di esclusione di responsabilità per il contatto di terze parti

Microsoft fornisce informazioni di contatto di terze parti per aiutarti a trovare ulteriori informazioni su questo argomento. Queste informazioni di contatto sono soggette a modifica senza preavviso. Microsoft non garantisce l'accuratezza delle informazioni di contatto di terze parti.

Contattaci per ricevere assistenza

Per domande o richieste di assistenza, creare una richiesta di supporto o chiedere supporto alla community di Azure. È anche possibile inviare commenti e suggerimenti sul prodotto alla community di commenti e suggerimenti di Azure.