Risoluzione dei problemi di base delle connessioni in uscita da un cluster del servizio Azure Kubernetes

Articolo
06/12/2024

Questo articolo illustra come risolvere i problemi di base delle connessioni in uscita da un cluster del servizio Microsoft Azure Kubernetes.

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 .
Strumento da riga di comando apt-get per la gestione dei pacchetti.
Lo strumento URL client (cURL) o uno strumento da riga di comando simile.
Strumento da riga di comando host per le ricerche DNS.
Strumento da riga di comando Netcat (nc) per le connessioni TCP.
Strumento da riga di comando traceroute per la stampa della traccia dei pacchetti di routing all'host di rete.

Scenari per il traffico in uscita nel servizio Azure Kubernetes

In qualsiasi scenario di rete, è consigliabile considerare i fattori seguenti durante la risoluzione dei problemi:

Origine e destinazione della richiesta.
Hop tra l'origine e la destinazione.
Flusso di richiesta-risposta.
Hop migliorati da livelli di sicurezza aggiuntivi, ad esempio i livelli seguenti:
- Firewall
- Gruppo di sicurezza di rete (NSG)
- Criteri di rete

Quando si controlla ogni componente, ottenere e analizzare i codici di risposta HTTP. Questi codici sono utili per identificare la natura del problema. I codici sono particolarmente utili negli scenari in cui l'applicazione risponde alle richieste HTTP.

Se altri passaggi per la risoluzione dei problemi non forniscono risultati conclusivi, eseguire acquisizioni di pacchetti dal client e dal server. Le acquisizioni di pacchetti sono utili anche quando il traffico non HTTP è coinvolto tra il client e il server. Per altre informazioni su come raccogliere le acquisizioni di pacchetti per l'ambiente del servizio Azure Kubernetes, vedere gli articoli seguenti nella guida alla raccolta dati:

Se si sa come ottenere i codici di risposta HTTP e acquisire pacchetti, è più semplice risolvere un problema di connettività di rete.

Il traffico che proviene dall'interno del cluster del servizio Azure Kubernetes, che provenga da un pod o da un nodo di lavoro, è considerato il traffico in uscita dal cluster. Cosa succede se si verifica un problema nel flusso in uscita per un cluster del servizio Azure Kubernetes? Prima di risolvere i problemi, comprendere prima di tutto la natura del flusso richiesta-risposta.

Il traffico in uscita da un cluster del servizio Azure Kubernetes può essere classificato nelle categorie seguenti:

Traffico verso un pod o un servizio nello stesso cluster (traffico interno)
Traffico verso un dispositivo o un endpoint nella stessa rete virtuale o in una rete virtuale diversa (che usa il peering di rete virtuale)
Traffico verso un ambiente locale tramite una connessione VPN o una connessione Azure ExpressRoute
Traffico esterno alla rete del servizio Azure Kubernetes (traffico in uscita pubblico)

In questo documento vengono illustrati i passaggi di base per la risoluzione dei problemi che influiscono sulla connettività in uscita:

All'interno del cluster
All'interno delle reti virtuali
Verso il mondo esterno (traffico pubblico)

Quando si risolve il traffico in uscita nel servizio Azure Kubernetes, è anche importante sapere qual è il dispositivo in uscita, ovvero il dispositivo attraverso il quale passa il traffico. In questo caso, il dispositivo in uscita potrebbe essere uno dei componenti seguenti:

Azure Load Balancer
Firewall di Azure o un firewall personalizzato
Gateway NAT (Network Address Translation)
Un server proxy

Il flusso potrebbe anche differire in base alla destinazione. Ad esempio, il traffico interno ,ovvero all'interno del cluster, non passa attraverso il dispositivo in uscita. Il traffico interno userebbe solo la rete del cluster.

Traffico interno

Un flusso di richiesta di base per il traffico interno da un cluster del servizio Azure Kubernetes sarebbe simile al flusso illustrato nel diagramma seguente.

Traffico esterno tramite Azure Load Balancer

Se il traffico è destinato a una destinazione su Internet, il metodo predefinito consiste nell'inviare il traffico tramite Azure Load Balancer.

Traffico esterno attraverso Firewall di Azure o un server proxy

In alcuni casi, il traffico in uscita deve essere filtrato e potrebbe richiedere Firewall di Azure.

Anziché un firewall, un utente potrebbe voler aggiungere un server proxy. In alternativa, l'utente potrebbe voler configurare un gateway NAT per il traffico in uscita. Il flusso di base rimane lo stesso illustrato nel diagramma.

È importante comprendere la natura del flusso in uscita per il cluster in modo da poter continuare a risolvere i problemi.

Elenco di controllo per la risoluzione dei problemi

Per la risoluzione dei problemi di base per il traffico in uscita da un cluster del servizio Azure Kubernetes, seguire questa procedura:

Assicurarsi che la risoluzione DNS (Domain Name System) per l'endpoint funzioni correttamente.
Assicurarsi di poter raggiungere l'endpoint tramite un indirizzo IP.
Assicurarsi di poter raggiungere l'endpoint da un'altra origine.
Assicurarsi che l'endpoint funzioni.
Controllare se il cluster può raggiungere qualsiasi altro endpoint esterno.
Controllare se un criterio di rete blocca il traffico.
Controllare se un gruppo di sicurezza di rete blocca il traffico.
Controllare se un firewall o un proxy blocca il traffico.
Controllare se l'entità servizio Servizio Azure Kubernetes o l'identità gestita dispone delle autorizzazioni necessarie per il servizio Azure Kubernetes per apportare le modifiche di rete alle risorse di Azure.

Controllare se la risoluzione DNS ha esito positivo per l'endpoint

Dall'interno del pod è possibile eseguire una ricerca DNS nell'endpoint.

Cosa accade se non è possibile eseguire il comando kubectl exec per connettersi al pod e installare il pacchetto DNS Utils? In questo caso, è possibile avviare un pod di test nello stesso spazio dei nomi del pod problematico e quindi eseguire i test.

Nota

Se la risoluzione DNS o il traffico in uscita non consente di installare i pacchetti di rete necessari, è possibile usare l'immagine rishasi/ubuntu-netutil:1.0 docker. In questa immagine i pacchetti necessari sono già installati.

Ecco una procedura di esempio per verificare la risoluzione DNS:

Avviare un pod di test nello stesso spazio dei nomi del pod problematico:
```
kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable
```
Dopo l'esecuzione del pod di test, si otterrà l'accesso al pod.

Eseguire i comandi seguenti apt-get per installare altri pacchetti di strumenti:

apt-get update -y
apt-get install dnsutils -y
apt-get install curl -y
apt-get install netcat -y

Dopo aver installato i pacchetti, eseguire il comando nslookup per testare la risoluzione DNS nell'endpoint:

$ nslookup microsoft.com
Server:         10.0.0.10
Address:        10.0.0.10#53
...
...
Name:   microsoft.com
Address: 20.53.203.50

Provare direttamente la risoluzione DNS dal server DNS upstream. Questo esempio usa DNS di Azure:

$ nslookup microsoft.com 168.63.129.16
Server:         168.63.129.16
Address:        168.63.129.16#53
...
...
Address: 20.81.111.85

Eseguire il host comando per verificare 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

Eseguire un pod di test nel pool di nodi di Windows:

# For a Windows environment, use the Resolve-DnsName cmdlet.
kubectl run dnsutil-win --image='mcr.microsoft.com/windows/servercore:1809' --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "windows"}}}' -- powershell "Start-Sleep -s 3600"

Eseguire il comando kubectl exec per connettersi al pod usando PowerShell:
```
kubectl exec -it dnsutil-win powershell
```

Eseguire il cmdlet Resolve-DnsName in PowerShell per verificare se la risoluzione DNS funziona per l'endpoint:

PS C:\> Resolve-DnsName www.microsoft.com 

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
www.microsoft.com              CNAME  20    Answer     www.microsoft.com-c-3.edgekey.net
www.microsoft.com-c-3.edgekey. CNAME  20    Answer     www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net
net
www.microsoft.com-c-3.edgekey. CNAME  20    Answer     e13678.dscb.akamaiedge.net
net.globalredir.akadns.net

Name       : e13678.dscb.akamaiedge.net 
QueryType  : AAAA
TTL        : 20
Section    : Answer
IP6Address : 2600:1408:c400:484::356e   


Name       : e13678.dscb.akamaiedge.net 
QueryType  : AAAA
TTL        : 20
Section    : Answer
IP6Address : 2600:1408:c400:496::356e 


Name       : e13678.dscb.akamaiedge.net
QueryType  : A
TTL        : 12
Section    : Answer
IP4Address : 23.200.197.152

È anche necessario verificare se l'endpoint è raggiungibile dal nodo. Verificare quindi le impostazioni DNS nel nodo. attenersi alla seguente procedura:

Connettersi ai nodi del cluster del servizio Azure Kubernetes per la manutenzione o la risoluzione dei problemi.

Testare la risoluzione DNS nell'endpoint:

$ nslookup  microsoft.com
Server:         168.63.129.16
Address:        168.63.129.16#53

Non-authoritative answer:
Name:   microsoft.com
Address: 20.112.52.29
Name:   microsoft.com
Address: 20.81.111.85
Name:   microsoft.com
Address: 20.84.181.62
Name:   microsoft.com
Address: 20.103.85.33
Name:   microsoft.com
Address: 20.53.203.50

Controllare il file resolv.conf per determinare se vengono aggiunti i server dei nomi previsti:
```
cat /etc/resolv.conf
cat /run/systemd/resolve/resolv.conf
```

In uno scenario insolito che prevede la risoluzione DNS, le query DNS ottengono una risposta corretta dal nodo ma hanno esito negativo dal pod. Per questo scenario, è possibile valutare la possibilità di controllare gli errori di risoluzione DNS dall'interno del pod, ma non dal nodo di lavoro. Se si vuole esaminare la risoluzione DNS per individuare un endpoint nel cluster, è possibile controllare lo stato della risoluzione DNS nel cluster.

Se la risoluzione DNS ha esito positivo, continuare con i test di rete. In caso contrario, verificare la configurazione DNS per il cluster.

Controllare se il cluster può raggiungere l'endpoint tramite la rete

Per determinare se è possibile raggiungere l'endpoint tramite la rete dal cluster, seguire questa procedura:

Controllare la route all'endpoint per determinare se è presente un timeout in un'operazione specifica:

kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable
apt-get install -y traceroute && apt-get install netcat -y
traceroute -T microsoft.com -m 50 -p 443

Controllare se la porta desiderata è aperta nell'host remoto:
```
nc -z -v microsoft.com 443
```
Controllare il codice di risposta HTTP:
```
curl -Iv https://microsoft.com
```
Verificare se è possibile connettersi a qualsiasi altro endpoint:
```
curl -Iv https://kubernetes.io
```

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