Correggere gli errori di risoluzione DNS dall'interno del pod ma non dal nodo di lavoro

Articolo
11/20/2024

Questo articolo illustra come risolvere gli errori di risoluzione DNS (Domain Name System) che si verificano dall'interno del pod, ma non dal nodo di lavoro, quando si tenta di stabilire una connessione in uscita da un cluster del servizio servizio Azure Kubernetes Azure Kubernetes (AKS).

Prerequisiti

Lo strumento Kubernetes kubectl o uno strumento simile per connettersi al cluster. Per installare kubectl usando l'interfaccia della riga di comando di Azure, eseguire il comando az aks install-cli .
Lo strumento da riga di comando apt-get per la gestione dei pacchetti.
Strumento da riga di comando host per le ricerche DNS.
Strumento da riga di comando systemctl .

Background

Per la risoluzione DNS, i pod inviano richieste ai pod CoreDNS nello spazio dei kube-system nomi .

Se la query DNS riguarda un componente interno, ad esempio un nome di servizio, il pod CoreDNS risponde da solo. Tuttavia, se la richiesta riguarda un dominio esterno, il pod CoreDNS invia la richiesta al server DNS upstream.

I server DNS upstream vengono ottenuti in base al file resolv.conf del nodo di lavoro in cui è in esecuzione il pod. Il file resolv.conf ( /run/systemd/resolve/resolve.conf) viene aggiornato in base alle impostazioni DNS della rete virtuale in cui è in esecuzione il nodo di lavoro.

Elenco di controllo per la risoluzione dei problemi

Per risolvere i problemi DNS dall'interno del pod, usare le istruzioni riportate nelle sezioni seguenti.

Passaggio 1: Risolvere i problemi DNS dall'interno del pod

È possibile usare i comandi kubectl per risolvere i problemi DNS dall'interno del pod, come illustrato nei passaggi seguenti:

Verificare che i pod CoreDNS siano in esecuzione:

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

Controllare se i pod CoreDNS sono sovrautilati:

$ 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

Verificare che i nodi che ospitano i pod CoreDNS non siano sovrautilati. Ottenere anche i nodi che ospitano i pod CoreDNS:
```
kubectl get pods -n kube-system -l k8s-app=kube-dns -o jsonpath='{.items[*].spec.nodeName}'
```
Controllare l'utilizzo di questi nodi:
```
kubectl top nodes
```

Verificare i log per i pod CoreDNS:

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

Note

Per visualizzare altre informazioni di debug, abilitare i log dettagliati in CoreDNS. Per abilitare la registrazione dettagliata in CoreDNS, vedere Risoluzione dei problemi relativi alle personalizzazioni CoreDNS nel servizio Azure Kubernetes.

Passaggio 2: Creare un pod di test per eseguire i comandi

Se la risoluzione DNS non riesce, seguire questa procedura:

Eseguire un pod di test nello stesso spazio dei nomi del pod problematico.
Avviare un pod di test nel cluster:
```
kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable
```
Quando il pod di test è in esecuzione, si otterrà l'accesso al pod.
Eseguire i comandi seguenti per installare i pacchetti necessari:
```
apt-get update -y
apt-get install dnsutils -y
```

Verificare che il file resolv.conf contenga le voci corrette:

cat /etc/resolv.conf
search default.svc.cluster.local svc.cluster.local cluster.local 00idcnmrrm4edot5s2or1onxsc.bx.internal.cloudapp.net
nameserver 10.0.0.10
options ndots:5

Usare il host comando per determinare se le richieste DNS vengono instradate al server upstream:

$ host -a microsoft.com
Trying "microsoft.com.default.svc.cluster.local"
Trying "microsoft.com.svc.cluster.local"
Trying "microsoft.com.cluster.local"
Trying "microsoft.com.00idcnmrrm4edot5s2or1onxsc.bx.internal.cloudapp.net"
Trying "microsoft.com"
Trying "microsoft.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62884
;; flags: qr rd ra; QUERY: 1, ANSWER: 27, AUTHORITY: 0, ADDITIONAL: 5

;; QUESTION SECTION:
;microsoft.com.                 IN      ANY

;; ANSWER SECTION:
microsoft.com.          30      IN      NS      ns1-39.azure-dns.com.
...
...
ns4-39.azure-dns.info.  30      IN      A       13.107.206.39

Received 2121 bytes from 10.0.0.10#53 in 232 ms

Controllare il server DNS upstream dal pod per determinare se la risoluzione DNS funziona correttamente. Ad esempio, per DNS di Azure, eseguire il comando nslookup seguente:
```
$ nslookup microsoft.com 168.63.129.16
Server:         168.63.129.16
Address:        168.63.129.16#53
...
...
Address: 20.81.111.85
```

Passaggio 3: Controllare se le richieste DNS funzionano quando il server DNS upstream viene specificato in modo esplicito

Se le richieste DNS dai pod funzionano quando si specifica il server DNS upstream in modo esplicito, verificare le condizioni seguenti:

Verificare la presenza di un oggetto ConfigMap personalizzato per CoreDNS:
```
kubectl describe cm coredns-custom -n kube-system
```
Se è presente un oggetto ConfigMap personalizzato, verificare che la configurazione sia corretta. Per altre informazioni, vedere Personalizzare CoreDNS con servizio Azure Kubernetes.
Controllare se un criterio di rete blocca il traffico sulla porta UDP (User Datagram Protocol) 53 ai pod CoreDNS nello spazio dei kube-system nomi.
Controllare se i pod CoreDNS si trovano in un pool di nodi diverso (pool di nodi di sistema). In caso affermativo, controllare se un gruppo di sicurezza di rete (NSG) è associato al pool di nodi di sistema che blocca il traffico sulla porta UDP 53.
Controllare se la rete virtuale è stata aggiornata di recente per aggiungere i nuovi server DNS.

Se si è verificato un aggiornamento della rete virtuale, verificare se si è verificato anche uno degli eventi seguenti:
- I nodi sono stati riavviati.
- Il servizio di rete nel nodo è stato riavviato.
Per rendere effettivo l'aggiornamento nelle impostazioni DNS, è necessario riavviare il servizio di rete nel nodo e i pod CoreDNS. Per riavviare il servizio di rete o i pod, usare uno dei metodi seguenti:
- Riavviare il nodo.
- Ridimensionare i nuovi nodi. I nuovi nodi avranno la configurazione aggiornata.
- Riavviare il servizio di rete nei nodi e quindi riavviare i pod CoreDNS. Seguire questa procedura:
  1. Stabilire una connessione Secure Shell (SSH) ai nodi. Per altre informazioni, vedere Connettersi ai nodi del cluster del servizio Azure Kubernetes per la risoluzione dei problemi e le attività di manutenzione.
  2. Dal nodo riavviare il servizio di rete:
```
systemctl restart systemd-networkd
```
  3. Controllare se le impostazioni vengono aggiornate:
```
cat /run/systemd/resolve/resolv.conf
```
  4. Dopo il riavvio del servizio di rete, usare kubectl per riavviare i pod CoreDNS:
```
kubectl delete pods -l k8s-app=kube-dns -n kube-system
```

Controllare se nelle impostazioni DNS della rete virtuale sono specificati più server DNS.

Se nella rete virtuale del servizio Azure Kubernetes sono specificati più server DNS, si verifica una delle sequenze seguenti:

Il nodo servizio Azure Kubernetes invia una richiesta al server DNS upstream come parte di una serie. In questa sequenza, la richiesta viene inviata al primo server DNS configurato nella rete virtuale (se i server DNS sono raggiungibili e in esecuzione). Se il primo server DNS non è raggiungibile e non risponde, la richiesta viene inviata al server DNS successivo.

I nodi del servizio Azure Kubernetes usano il comando resolver per inviare richieste ai server DNS. Il file di configurazione per questo resolver è disponibile in /run/systemd/resolve/resolve.conf nei nodi del servizio Azure Kubernetes.

Sono presenti più server? In questo caso, la libreria resolver li esegue una query nell'ordine elencato. La strategia usata consiste nel provare prima un server dei nomi. Se la query raggiunge il timeout, provare il server dei nomi successivo e continuare fino all'esaurimento dell'elenco dei server dei nomi. La query continua quindi a tentare di connettersi ai server dei nomi fino a quando non viene effettuato il numero massimo di tentativi.

CoreDNS usa il plug-in forward per inviare richieste ai server DNS upstream. Questo plug-in usa un algoritmo casuale per selezionare il server DNS upstream. In questa sequenza, la richiesta potrebbe passare a uno qualsiasi dei server DNS menzionati nella rete virtuale. Ad esempio, è possibile ricevere l'output seguente:

$ kubectl describe cm coredns -n kube-system
Name:         coredns
Namespace:    kube-system
Labels:       addonmanager.kubernetes.io/mode=Reconcile
              k8s-app=kube-dns
              kubernetes.io/cluster-service=true
Annotations:  <none>

Data
====
Corefile:
----
.:53 {
    errors
    ready
    health
    kubernetes cluster.local in-addr.arpa ip6.arpa {
      pods insecure
      fallthrough in-addr.arpa ip6.arpa
    }
    prometheus :9153
    forward . /etc/resolv.conf                            # Here!
    cache 30
    loop
    reload
    loadbalance
    import custom/*.override
}
import custom/*.server


BinaryData
====

Events:  <none>

Nel plug-in CoreDNS forward policy specifica i criteri da usare per la selezione dei server upstream. Questi vengono definiti nella tabella seguente.

Nome criteri	Descrizione
`random`	Criteri che implementano la selezione upstream casuale. Si tratta di criteri predefiniti.
`round_robin`	Criteri che selezionano gli host in base all'ordinamento round robin.
`sequential`	Criteri che selezionano gli host in base all'ordinamento sequenziale.

Se la rete virtuale del servizio Azure Kubernetes contiene più server DNS, le richieste dal nodo servizio Azure Kubernetes potrebbero passare al primo server DNS. Tuttavia, le richieste dal pod potrebbero passare al secondo server DNS.

Causa: più destinazioni per le richieste DNS

Se vengono specificati due server DNS personalizzati e il terzo server DNS viene specificato come DNS di Azure (168.63.129.16), il nodo invierà richieste al primo server DNS personalizzato se è in esecuzione e raggiungibile. In questa configurazione il nodo può risolvere il dominio personalizzato. Tuttavia, alcune richieste DNS dal pod potrebbero essere indirizzate a DNS di Azure. Questo avviene perché CoreDNS può selezionare il server upstream in modo casuale. In questo scenario, il dominio personalizzato non può essere risolto. Pertanto, la richiesta DNS ha esito negativo.

Soluzione: Rimuovere DNS di Azure dalle impostazioni della rete virtuale

È consigliabile non combinare DNS di Azure con server DNS personalizzati nelle impostazioni della rete virtuale. Se si vogliono usare i server DNS personalizzati, aggiungere solo i server DNS personalizzati nelle impostazioni della rete virtuale. Configurare quindi DNS di Azure nelle impostazioni del server d'inoltro dei server DNS personalizzati.

Per altre informazioni, vedere Risoluzione dei nomi con l'uso del proprio server DNS.

Dichiarazione di non responsabilità di contatti 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

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.

Condividi tramite