Diagnosticare i problemi di connessione per i cluster Kubernetes abilitati per Azure Arc

Se si verificano problemi durante la connessione di un cluster ad Azure Arc, ciò è probabilmente dovuto a uno dei problemi elencati qui. Vengono forniti due diagrammi di flusso con guida interattiva: uno se non si usa un server proxy e uno che si applica se la connessione di rete usa un server proxy.

Connessioni senza proxy

Esaminare questo diagramma di flusso per diagnosticare il problema quando si tenta di connettere un cluster ad Azure Arc senza un server proxy. Ulteriori dettagli su ciascun passaggio sono illustrati di seguito.

L'identità di Azure dispone di autorizzazioni sufficienti?

Esaminare i prerequisiti per la connessione di un cluster e assicurarsi che l'identità usata per connettere il cluster disponga delle autorizzazioni necessarie.

Si sta eseguendo la versione più recente dell'interfaccia della riga di comando di Azure?

Assicurarsi di avere la versione più recente installata.

Se il cluster è stato connesso usando Azure PowerShell, assicurarsi di eseguire la versione più recente.

L'estensione connectedk8s è la versione più recente?

Aggiornare l'estensione connectedk8s dell'interfaccia della riga di comando di Azure alla versione più recente eseguendo questo comando:

az extension update --name connectedk8s

Se l'estensione non è ancora stata installata, è possibile farlo eseguendo il comando seguente:

az extension add --name connectedk8s

Kubeconfig punta al cluster corretto?

Eseguire kubectl config get-contexts per confermare il nome del contesto di destinazione. Impostare quindi il contesto predefinito sul cluster corretto eseguendo kubectl config use-context <target-cluster-name>.

Sono registrati tutti i provider di risorse necessari?

Assicurarsi che i provider di risorse Microsoft.Kubernetes, Microsoft.KubernetesConfiguration e Microsoft.ExtendedLocation siano registrati.

Sono soddisfatti tutti i requisiti di rete?

Esaminare i requisiti di rete e assicurarsi che non siano bloccati gli endpoint necessari.

Tutti i pod nello spazio dei nomi azure-arc sono in esecuzione?

Se tutto funziona correttamente, i pod devono trovarsi tutti nello stato Running. Eseguire kubectl get pods -n azure-arc per verificare se lo stato di un pod non è Running.

Ancora problemi?

I passaggi precedenti risolveranno molti problemi di connessione comuni, ma se non è ancora possibile connettersi correttamente, generare un file di log per la risoluzione dei problemi, quindi aprire una richiesta di supporto in modo da consentirci di analizzare ulteriormente il problema.

Per generare il file di log per la risoluzione dei problemi, eseguire il comando seguente:

az connectedk8s troubleshoot -g <myResourceGroup> -n <myK8sCluster>

Quando si crea la richiesta di supporto, nella sezione Dettagli aggiuntivi usare l'opzione Caricamento file per caricare il file di log generato.

Connessioni con un server proxy

Se si usa un server proxy in almeno un computer, attenersi ai primi cinque passaggi del diagramma di flusso non proxy (tramite registrazione del provider di risorse) per i passaggi di base per la risoluzione dei problemi. Se si verificano ancora problemi, rivedere il diagramma di flusso successivo per ulteriori passaggi per la risoluzione dei problemi. Ulteriori dettagli su ciascun passaggio sono illustrati di seguito.

Il computer esegue comandi dietro un server proxy?

Se il computer esegue comandi dietro un server proxy, è necessario impostare tutte le variabili di ambiente necessarie. Per altre informazioni, vedere Connettersi usando un server proxy in uscita.

Ad esempio:

export HTTP_PROXY="http://<proxyIP>:<proxyPort>"
export HTTPS_PROXY="https://<proxyIP>:<proxyPort>"
export NO_PROXY="<cluster-apiserver-ip-address>:<proxyPort>"

Il server proxy accetta solo certificati attendibili?

Assicurarsi di includere il percorso del file di certificato includendo --proxy-cert <path-to-cert-file> quando si esegue il comando az connectedk8s connect.

az connectedk8s connect --name <cluster-name> --resource-group <resource-group> --proxy-cert <path-to-cert-file>

Il server proxy è in grado di raggiungere gli endpoint di rete necessari?

Esaminare i requisiti di rete e assicurarsi che non siano bloccati gli endpoint necessari.

Il server proxy usa solo HTTP?

Se il server proxy usa solo HTTP, è possibile usare proxy-http per entrambi i parametri.

Se il server proxy è configurato con HTTP e HTTPS, eseguire il comando az connectedk8s connect con i parametri --proxy-https e --proxy-http specificati. Assicurarsi di usare --proxy-http per il proxy HTTP e --proxy-https per il proxy HTTPS.

az connectedk8s connect --name <cluster-name> --resource-group <resource-group> --proxy-https https://<proxy-server-ip-address>:<port> --proxy-http http://<proxy-server-ip-address>:<port>  

Il server proxy richiede intervalli skip per la comunicazione da servizio a servizio?

Se è necessario ignorare gli intervalli, usare --proxy-skip-range <excludedIP>,<excludedCIDR> nel comando az connectedk8s connect.

az connectedk8s connect --name <cluster-name> --resource-group <resource-group> --proxy-https https://<proxy-server-ip-address>:<port> --proxy-http http://<proxy-server-ip-address>:<port> --proxy-skip-range <excludedIP>,<excludedCIDR>

Tutti i pod nello spazio dei nomi azure-arc sono in esecuzione?

Se tutto funziona correttamente, i pod devono trovarsi tutti nello stato Running. Eseguire kubectl get pods -n azure-arc per verificare se lo stato di un pod non è Running.

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

Dall'interno del pod è possibile eseguire una ricerca DNS all'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, quindi eseguire i test.

Ecco una procedura di esempio per controllare la risoluzione DNS:

1. Avviare un pod di test nello stesso spazio dei nomi del pod problematico:

   kubectl run -it --rm test-pod --namespace <namespace> --image=debian:stable
   

   Dopo che il pod di test è in esecuzione, si otterrà l'accesso al pod.

2. 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
   

3. 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
   

4. 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
   

5. Eseguire il comando host 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
   

6. 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"
   

7. Eseguire il comando kubectl exec per connettersi al pod usando PowerShell:

   kubectl exec -it dnsutil-win -- powershell
   

8. 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
   

Se la risoluzione DNS non riesce, verificare la configurazione DNS per il cluster.

Ancora problemi?

I passaggi precedenti risolveranno molti problemi di connessione comuni, ma se non è ancora possibile connettersi correttamente, generare un file di log per la risoluzione dei problemi, quindi aprire una richiesta di supporto in modo da consentirci di analizzare ulteriormente il problema.

Per generare il file di log per la risoluzione dei problemi, eseguire il comando seguente:

az connectedk8s troubleshoot -g <myResourceGroup> -n <myK8sCluster>

Quando si crea la richiesta di supporto, nella sezione Dettagli aggiuntivi usare l'opzione Caricamento file per caricare il file di log generato.

Passaggi successivi

• Vedere altri suggerimenti per la risoluzione dei problemi relativi all'uso di Kubernetes abilitato per Azure Arc.
• Esaminare il processo per connettere un cluster Kubernetes esistente ad Azure Arc.