Diagnosticar problemas de conexão para clusters Kubernetes habilitados para Azure Arc
Se você estiver enfrentando problemas para 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 sua conexão de rede usar um servidor proxy.
Gorjeta
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, certifique-se de fazê-lo antes de começar.
Conexões sem proxy
Revise este fluxograma para diagnosticar seu problema ao tentar conectar um cluster ao Azure Arc sem um servidor proxy. Mais detalhes sobre cada etapa são fornecidos abaixo.
A identidade do Azure tem permissões suficientes?
Reveja os pré-requisitos para ligar um cluster e certifique-se de que a identidade que está a utilizar para ligar o cluster tem as permissões necessárias.
Você está executando a versão mais recente da CLI do Azure?
Certifique-se de que tem a versão mais recente instalada.
Se você conectou seu cluster usando o Azure PowerShell, verifique se está executando a versão mais recente.
A extensão é connectedk8s a versão mais recente?
Atualize a extensão da CLI connectedk8s do Azure para a versão mais recente executando este comando:
az extension update --name connectedk8s
Se ainda não instalou a extensão, pode fazê-lo 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 correto executando kubectl config use-context <target-cluster-name>.
Todos os provedores de recursos necessários estão registrados?
Certifique-se de que os provedores de recursos Microsoft.Kubernetes, Microsoft.KubernetesConfiguration e Microsoft.ExtendedLocation estejam registrados.
Todos os requisitos de rede são atendidos?
Revise os requisitos de rede e verifique se nenhum ponto de extremidade necessário está bloqueado.
Todos os pods no namespace estão em azure-arc execução?
Se tudo estiver funcionando corretamente, seus pods devem estar todos no Running estado. Execute kubectl get pods -n azure-arc para confirmar se o estado de qualquer pod não Runningé .
Ainda está com 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, em seguida , abra uma solicitação de suporte para que possamos investigar o problema ainda mais.
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 uma máquina, conclua as cinco primeiras etapas do fluxograma sem proxy (por meio do registro do provedor de recursos) para obter as etapas básicas de solução de problemas. Em seguida, se você ainda estiver encontrando problemas, revise o próximo fluxograma para obter etapas adicionais de solução de problemas. Mais detalhes sobre cada etapa são fornecidos abaixo.
A máquina está executando comandos atrás de um servidor proxy?
Se a máquina estiver executando comandos atrás de um servidor proxy, você precisará definir todas as variáveis de ambiente necessárias. Para obter mais informações, consulte 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 só aceita certificados confiáveis?
Certifique-se de incluir o caminho do arquivo de certificado incluindo --proxy-cert <path-to-cert-file> ao executar o az connectedk8s connect comando.
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?
Revise os requisitos de rede e verifique se nenhum ponto de extremidade necessário está bloqueado.
O servidor proxy está usando apenas HTTP?
Se o seu servidor proxy usa apenas HTTP, você pode usar proxy-http para ambos os parâmetros.
Se o servidor proxy estiver configurado com HTTP e HTTPS, execute o az connectedk8s connect comando com os --proxy-https parâmetros e --proxy-http especificados. Certifique-se de estar 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 intervalos de pulo para comunicação serviço-a-serviço?
Se você precisar pular intervalos, use --proxy-skip-range <excludedIP>,<excludedCIDR> em seu 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>
Todos os pods no namespace estão em azure-arc execução?
Se tudo estiver funcionando corretamente, seus pods devem estar todos no Running estado. Execute kubectl get pods -n azure-arc para confirmar se o estado de qualquer 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 de 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.
Nota
Se a resolução DNS ou o tráfego de saída não permitir que você instale os pacotes de rede necessários, você poderá usar a imagem do rishasi/ubuntu-netutil:1.0 docker. Nesta imagem, os pacotes necessários já estão instalados.
Aqui está um exemplo de procedimento 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ê terá acesso ao pod.
Execute os seguintes
apt-getcomandos para 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
hostcomando para 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 para o cluster.
Ainda está com 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, em seguida , abra uma solicitação de suporte para que possamos investigar o problema ainda mais.
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óximos passos
- Veja mais dicas de solução de problemas para usar o Kubernetes habilitado para Azure Arc.
- Revise o processo para conectar um cluster Kubernetes existente ao Azure Arc.