Compartilhar via


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.

Fluxograma mostrando uma representação visual de verificação de problemas de conexão ao não usar um proxy.

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.

Fluxograma mostrando uma representação visual de verificação de problemas de conexão ao usar um proxy.

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:

  1. Inicie um pod de teste no mesmo namespace que o pod problemático:

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

    Depois que o pod de teste estiver em execução, você obterá acesso ao pod.

  2. Execute os seguintes comandos apt-get para instalar outros pacotes de ferramentas:

    apt-get update -y
    apt-get install dnsutils -y
    apt-get install curl -y
    apt-get install netcat -y
    
  3. Depois 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.50
    
  4. Experimente 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.85
    
  5. Execute o comando host 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 ms
    
  6. Execute 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"
    
  7. Execute o comando kubectl exec para se conectar ao pod usando o PowerShell:

    kubectl exec -it dnsutil-win -- powershell
    
  8. Execute 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