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.
Suggerimento
La procedura descritta in questo diagramma di flusso si applica se si usa l'interfaccia della riga di comando di Azure o Azure PowerShell per connettere il cluster. Tuttavia alcuni dei passaggi richiedono l'uso dell'interfaccia della riga di comando di Azure. Se non si è installata l'interfaccia della riga di comando di Azure, assicurarsi di farlo prima di iniziare.
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.
Nota
Se la risoluzione DNS o il traffico in uscita non consentono di installare i pacchetti di rete necessari, è possibile usare l'immagine Docker rishasi/ubuntu-netutil:1.0
. In questa immagine i pacchetti necessari sono già installati.
Ecco una procedura di esempio per controllare la risoluzione DNS:
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.
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 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
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
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.