Solução de problemas básicos de conexões de saída de um cluster do AKS

Artigo
12/18/2024

Este artigo discute como solucionar problemas básicos de conexões de saída de um cluster do AKS (Serviço de Kubernetes do Microsoft Azure) e identificar componentes defeituosos.

Pré-requisitos

A ferramenta kubectl do Kubernetes ou uma ferramenta semelhante para se conectar ao cluster. Para instalar o kubectl usando a CLI do Azure, execute o comando az aks install-cli .
A ferramenta de linha de comando apt-get para lidar com pacotes.
A ferramenta URL do cliente (cURL) ou uma ferramenta de linha de comando semelhante.
A nslookup ferramenta de linha de comando (dnsutils) para verificar a resolução DNS.

Cenários para tráfego de saída no Serviço de Kubernetes do Azure

O tráfego originado de dentro do cluster do AKS, seja de um pod ou de um nó de trabalho, é considerado o tráfego de saída do cluster. E se houver um problema no fluxo de saída de um cluster do AKS? Antes de solucionar problemas, primeiro examine os cenários de fluxo de tráfego de saída.

O tráfego de saída de um cluster do AKS pode ser classificado nas seguintes categorias:

Tráfego para um pod ou serviço no mesmo cluster (tráfego interno).
Tráfego para um dispositivo ou ponto de extremidade na mesma rede virtual ou em uma rede virtual diferente que usa o emparelhamento de rede virtual.
Tráfego para um ambiente local por meio de uma conexão VPN ou uma conexão do Azure ExpressRoute.
Tráfego fora da rede do AKS por meio do Azure Load Balancer (tráfego de saída público).
Tráfego fora da rede do AKS por meio do Firewall do Azure ou de um servidor proxy (tráfego de saída público).

Tráfego interno

Um fluxo de solicitação básico para tráfego interno de um cluster do AKS é semelhante ao fluxo mostrado no diagrama a seguir.

Tráfego de saída público por meio do Azure Load Balancer

Se o tráfego for para um destino na Internet, o método padrão será enviar o tráfego por meio do Azure Load Balancer.

Tráfego de saída público por meio do Firewall do Azure ou de um servidor proxy

Em alguns casos, o tráfego de saída precisa ser filtrado e pode exigir o Firewall do Azure.

Um usuário pode querer adicionar um servidor proxy em vez de um firewall ou configurar um gateway NAT para tráfego de saída. O fluxo básico permanece o mesmo mostrado no diagrama.

É importante entender a natureza do fluxo de saída do cluster para que você possa continuar a solução de problemas.

Considerações ao solucionar problemas

Verifique seu dispositivo de saída

Quando você soluciona problemas de tráfego de saída no AKS, é importante saber qual é o dispositivo de saída (ou seja, o dispositivo pelo qual o tráfego passa). Aqui, o dispositivo de saída pode ser um dos seguintes componentes:

Azure Load Balancer
Firewall do Azure ou um firewall personalizado
Um gateway de conversão de endereços de rede (NAT)
Um servidor proxy

O fluxo também pode diferir com base no destino. Por exemplo, o tráfego interno (ou seja, dentro do cluster) não passa pelo dispositivo de saída. O tráfego interno usaria apenas a rede de cluster. Para tráfego de saída público, determine se há um dispositivo de saída passando e verifique esse dispositivo.

Verifique cada salto dentro do fluxo de tráfego

Depois de identificar o dispositivo de saída, verifique os seguintes fatores:

A origem e o destino da solicitação.
O salto entre a origem e o destino.
O fluxo de solicitação-resposta.
Os saltos que são aprimorados por camadas de segurança extras, como as seguintes camadas:
- Firewall
- NSG (grupo de segurança de rede)
- Política de rede

Para identificar um salto problemático, verifique os códigos de resposta antes e depois dele. Para verificar se os pacotes chegam corretamente em um salto específico, você pode prosseguir com as capturas de pacotes.

Verifique os códigos de resposta HTTP

Ao verificar cada componente, obtenha e analise os códigos de resposta HTTP. Esses códigos são úteis para identificar a natureza do problema. Os códigos são especialmente úteis em cenários em que o aplicativo responde a solicitações HTTP.

Fazer capturas de pacotes do cliente e do servidor

Se outras etapas de solução de problemas não fornecerem nenhum resultado conclusivo, faça capturas de pacotes do cliente e do servidor. As capturas de pacotes também são úteis quando o tráfego não HTTP está envolvido entre o cliente e o servidor. Para obter mais informações sobre como coletar capturas de pacotes para o ambiente do AKS, consulte os seguintes artigos no guia de coleta de dados:

Listas de verificação de solução de problemas

Para solução de problemas básicos para o tráfego de saída de um cluster do AKS, siga estas etapas:

Verifique se a resolução DNS (Sistema de Nomes de Domínio) para o ponto de extremidade funciona corretamente.
Certifique-se de que você pode acessar o endpoint por meio de um endereço IP.
Certifique-se de que você pode acessar o ponto de extremidade de outra fonte.
Verifique se o endpoint está ativo.
Verifique se o cluster pode alcançar qualquer outro ponto de extremidade externo.
Verifique se uma política de rede está bloqueando o tráfego.
Verifique se um NSG está bloqueando o tráfego.
Verifique se um firewall ou proxy está bloqueando o tráfego.
Verifique se a entidade de serviço AKS ou a identidade gerenciada tem as permissões necessárias para que o serviço AKS faça alterações de rede nos recursos do Azure.

Observação

Não pressupõe nenhum service mesh quando você faz a solução de problemas básicos. Se você usar uma malha de serviço como o Istio, ela produzirá resultados incomuns para o tráfego baseado em TCP.

Verifique se o pod e o nó podem acessar o endpoint

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.

Exemplo de procedimento para verificar a resolução DNS de um pod do Linux

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

kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "linux"}}}'

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

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

# Update and install tool packages
apt-get update && apt-get install -y dnsutils curl

Depois que os pacotes forem instalados, execute o comando nslookup para testar a resolução DNS para o ponto de extremidade:

$ nslookup microsoft.com # Microsoft.com is used as an example
Server:         <server>
Address:        <server IP address>#53
...
...
Name:   microsoft.com
Address: 20.53.203.50

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

Às vezes, há um problema com o próprio ponto de extremidade, em vez de um DNS de cluster. Nesses casos, considere as seguintes verificações:

Verifique se a porta desejada está aberta no host remoto:
```
curl -Ivm5 telnet://microsoft.com:443
```
Verifique o código de resposta HTTP:
```
curl -Ivm5 https://microsoft.com
```
Verifique se você pode se conectar a qualquer outro endpoint:
```
curl -Ivm5 https://kubernetes.io
```

Para verificar se o endpoint pode ser acessado do nó em que o pod problemático está e, em seguida, verificar as configurações de DNS, siga estas etapas:

Insira o nó em que o pod problemático está por meio do pod de depuração. Para obter mais informações sobre como fazer isso, consulte Conectar-se aos nós de cluster do AKS (Serviço de Kubernetes do Azure) para manutenção ou solução de problemas.

Teste a resolução DNS para o endpoint:

$ nslookup  microsoft.com
Server:         168.63.129.16
Address:        168.63.129.16#53

Non-authoritative answer:
Name:   microsoft.com
Address: 20.112.52.29
Name:   microsoft.com
Address: 20.81.111.85
Name:   microsoft.com
Address: 20.84.181.62
Name:   microsoft.com
Address: 20.103.85.33
Name:   microsoft.com
Address: 20.53.203.50

Verifique o arquivo resolv.conf para determinar se os servidores de nomes esperados foram adicionados:
```
cat /etc/resolv.conf
cat /run/systemd/resolve/resolv.conf
```

Exemplo de procedimento para verificar a resolução DNS de um pod do Windows

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:ltsc2022' --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 -- powershell
```

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

Em um cenário incomum que envolve resolução de DNS, as consultas de DNS obtêm uma resposta correta do nó, mas falham no pod. Para esse cenário, você pode considerar verificar falhas de resolução de DNS de dentro do pod, mas não do nó de trabalho. Se você quiser inspecionar a resolução de DNS para um endpoint no cluster, considere verificar o status de resolução de DNS no cluster.

Se a resolução DNS for bem-sucedida, continue para os testes de rede. Caso contrário, verifique a configuração de DNS para o cluster.

Aviso de isenção de responsabilidade para contatos de terceiros

A Microsoft fornece informações de contato de terceiros para ajudá-lo a encontrar informações adicionais sobre esse tópico. Essas informações de contato podem ser alteradas sem aviso prévio. A Microsoft não garante a precisão das informações de contato de terceiros.

Entre em contato conosco para obter ajuda

Se você tiver dúvidas ou precisar de ajuda, crie uma solicitação de suporte ou peça ajuda à comunidade de suporte do Azure. Você também pode enviar comentários sobre o produto para a comunidade de comentários do Azure.

Partilhar via