Diagnosticar problemas de conexão para clusters do Kubernetes habilitados para Azure Arc
Se você estiver enfrentando problemas ao conectar um cluster ao Azure Arc, é provavelmente devido a um dos problemas listados aqui. Fornecemos dois fluxogramas com ajuda guiada: um se você não estiver usando um servidor proxy e outro que se aplica se a conexão de rede usar um servidor proxy.
Dica
As etapas neste fluxograma se aplicam se você estiver usando a CLI do Azure ou o Azure PowerShell para conectar seu cluster. No entanto, algumas das etapas exigem o uso da CLI do Azure. Se você ainda não instalou a CLI do Azure, faça isso antes de começar.
Conexões sem um proxy
Examine este fluxograma para diagnosticar seu problema ao tentar conectar um cluster ao Azure Arc sem um servidor proxy. Mais detalhes sobre cada item são fornecidos abaixo.
A identidade do Azure tem permissões suficientes?
Examine os prerrequisitos para conectar um cluster e verifique se a identidade que você está usando para conectar o cluster tem as permissões necessárias.
Você está executando a versão mais recente da CLI do Azure?
Verifique se você tem a versão mais recente instalada.
Se você conectou seu cluster usando o Azure PowerShell, certifique-se de estar executando a versão mais recente.
A extensão connectedk8s é a versão mais recente?
Atualize a extensão connectedk8s da CLI do Azure para a versão mais recente executando este comando:
az extension update --name connectedk8s
Se você ainda não instalou a extensão, poderá fazer isso executando o seguinte comando:
az extension add --name connectedk8s
O kubeconfig está apontando para o cluster certo?
Execute kubectl config get-contexts para confirmar o nome do contexto de destino. Em seguida, defina o contexto padrão para o cluster certo executando kubectl config use-context <target-cluster-name>.
Todos os provedores de recursos necessários estão registrados?
Verifique se os provedores de recursos Microsoft.Kubernetes, Microsoft.KubernetesConfiguration e Microsoft.ExtendedLocation estão registrados.
Todos os requisitos de rede foram atendidos?
Examine os requisitos de rede e verifique se nenhum ponto de extremidade necessário está bloqueado.
Todos os pods no namespace azure-arc estão em execução?
Se tudo estiver funcionando corretamente, todos os pods deverão estar no estado Running. Execute kubectl get pods -n azure-arc para confirmar se o estado de algum pod não é Running.
Ainda está tendo problemas?
As etapas acima resolverão muitos problemas comuns de conexão, mas se você ainda não conseguir se conectar com êxito, gere um arquivo de log de solução de problemas e abra uma solicitação de suporte para que possamos investigar o problema mais a fundo.
Para gerar o arquivo de log de solução de problemas, execute o seguinte comando:
az connectedk8s troubleshoot -g <myResourceGroup> -n <myK8sCluster>
Ao criar sua solicitação de suporte, na seção Detalhes adicionais, use a opção Upload de arquivo para carregar o arquivo de log gerado.
Conexões com um servidor proxy
Se você estiver usando um servidor proxy em pelo menos um computador, conclua as cinco primeiras etapas do fluxograma não proxy (por meio do registro do provedor de recursos) para as etapas básicas de solução de problemas. Em seguida, se você ainda estiver encontrando problemas, examine o próximo fluxograma para obter etapas adicionais de solução de problemas. Mais detalhes sobre cada item são fornecidos abaixo.
O computador está executando comandos por trás de um servidor proxy?
Se o computador estiver executando comandos protegidos por um servidor proxy, você precisará definir todas as variáveis de ambiente necessárias. Para obter mais informações, confira Conectar-se usando um servidor proxy de saída.
Por exemplo:
export HTTP_PROXY="http://<proxyIP>:<proxyPort>"
export HTTPS_PROXY="https://<proxyIP>:<proxyPort>"
export NO_PROXY="<cluster-apiserver-ip-address>:<proxyPort>"
O servidor proxy aceita apenas certificados confiáveis?
Certifique-se de incluir o caminho do arquivo de certificado, incluindo --proxy-cert <path-to-cert-file> ao executar o comando az connectedk8s connect.
az connectedk8s connect --name <cluster-name> --resource-group <resource-group> --proxy-cert <path-to-cert-file>
O servidor proxy é capaz de alcançar os pontos de extremidade de rede necessários?
Examine os requisitos de rede e verifique se nenhum ponto de extremidade necessário está bloqueado.
O servidor proxy só está usando HTTP?
Se o servidor proxy usar apenas HTTP, você poderá usar proxy-http para ambos os parâmetros.
Se o servidor proxy estiver configurado com HTTP e HTTPS, execute o comando az connectedk8s connect com os parâmetros --proxy-https e --proxy-http especificados. Verifique se você está usando --proxy-http para o proxy HTTP e --proxy-https para o 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>
O servidor proxy requer ignorar intervalos para comunicação serviço a serviço?
Se você precisar ignorar intervalos, use --proxy-skip-range <excludedIP>,<excludedCIDR> no 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>
Todos os pods no namespace azure-arc estão em execução?
Se tudo estiver funcionando corretamente, todos os pods deverão estar no estado Running. Execute kubectl get pods -n azure-arc para confirmar se o estado de algum pod não é Running.
Verifique se a resolução DNS foi bem-sucedida para o ponto de extremidade
De dentro do pod, você pode executar uma pesquisa DNS para o ponto de extremidade.
E se você não puder executar o comando kubectl exec para se conectar ao pod e instalar o pacote DNS Utils? Nessa situação, você pode iniciar um pod de teste no mesmo namespace que o pod problemático e, em seguida, executar os testes.
Observação
Se o tráfego de saída ou resolução DNS não permitir que você instale os pacotes de rede necessários, você poderá usar a imagem do docker rishasi/ubuntu-netutil:1.0. Nesta imagem, os pacotes necessários já estão instalados.
Este é um procedimento de exemplo para verificar a resolução de DNS:
Inicie um pod de teste no mesmo namespace que o pod problemático:
kubectl run -it --rm test-pod --namespace <namespace> --image=debian:stableDepois que o pod de teste estiver em execução, você obterá acesso ao pod.
Execute os seguintes comandos
apt-getpara instalar outros pacotes de ferramentas:apt-get update -y apt-get install dnsutils -y apt-get install curl -y apt-get install netcat -yDepois que os pacotes forem instalados, execute o comando nslookup para testar a resolução DNS para o ponto de extremidade:
$ nslookup microsoft.com Server: 10.0.0.10 Address: 10.0.0.10#53 ... ... Name: microsoft.com Address: 20.53.203.50Experimente a resolução DNS diretamente do servidor DNS upstream. Este exemplo usa o DNS do Azure:
$ nslookup microsoft.com 168.63.129.16 Server: 168.63.129.16 Address: 168.63.129.16#53 ... ... Address: 20.81.111.85Execute o comando
hostpara verificar se as solicitações DNS são roteadas para o servidor 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 msExecute um pod de teste no pool de nós do 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"Execute o comando kubectl exec para se conectar ao pod usando o PowerShell:
kubectl exec -it dnsutil-win -- powershellExecute o cmdlet Resolve-DnsName no PowerShell para verificar se a resolução DNS está funcionando para o ponto de extremidade:
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 a resolução DNS não for bem-sucedida, verifique a configuração de DNS do cluster.
Ainda está tendo problemas?
As etapas acima resolverão muitos problemas comuns de conexão, mas se você ainda não conseguir se conectar com êxito, gere um arquivo de log de solução de problemas e abra uma solicitação de suporte para que possamos investigar o problema mais a fundo.
Para gerar o arquivo de log de solução de problemas, execute o seguinte comando:
az connectedk8s troubleshoot -g <myResourceGroup> -n <myK8sCluster>
Ao criar sua solicitação de suporte, na seção Detalhes adicionais, use a opção Upload de arquivo para carregar o arquivo de log gerado.
Próximas etapas
- Veja mais dicas de solução de problemas para usar o Kubernetes habilitado para Azure Arc.
- Revise o processo para conectar um cluster do Kubernetes existente ao Azure Arc.