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, è probabilmente dovuto a uno dei problemi elencati qui. Vengono forniti due diagrammi di flusso con guida guidata: 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 l'interfaccia della riga di comando di Azure non è già stata installata, 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. Di seguito sono riportati altri dettagli su ogni passaggio.
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 installato la versione più recente.
Se il cluster è stato connesso usando Azure PowerShell, assicurarsi di eseguire la versione più recente.
L'estensione è la connectedk8s versione più recente?
Aggiornare l'estensione dell'interfaccia della riga di comando di Azure connectedk8s 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>.
Tutti i provider di risorse necessari sono registrati?
Assicurarsi che i provider di risorse Microsoft.Kubernetes, Microsoft.KubernetesConfiguration e Microsoft.ExtendedLocation siano registrati.
Tutti i requisiti di rete sono soddisfatti?
Esaminare i requisiti di rete e assicurarsi che non siano bloccati gli endpoint necessari.
Tutti i pod nello spazio dei azure-arc nomi sono in esecuzione?
Se tutto funziona correttamente, i pod devono trovarsi tutti nello Running stato. 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 e quindi aprire una richiesta di supporto in modo da poter 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, completare i 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, vedere il diagramma di flusso successivo per ulteriori passaggi per la risoluzione dei problemi. Di seguito sono riportati altri dettagli su ogni passaggio.
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 az connectedk8s connect comando .
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 az connectedk8s connect comando con i --proxy-https parametri 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 az connectedk8s connect comando.
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 azure-arc nomi sono in esecuzione?
Se tutto funziona correttamente, i pod devono trovarsi tutti nello Running stato. 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 Utils DNS? 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 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:stableDopo l'esecuzione del pod di test, si otterrà l'accesso al pod.
Eseguire i comandi seguenti
apt-getper installare altri pacchetti di strumenti:apt-get update -y apt-get install dnsutils -y apt-get install curl -y apt-get install netcat -yDopo 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.50Provare 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.85Eseguire il
hostcomando 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 msEseguire 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 powershellEseguire 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 e quindi aprire una richiesta di supporto in modo da poter 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 con abilitazione di Azure Arc.
- Esaminare il processo per connettere un cluster Kubernetes esistente ad Azure Arc.
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per