Solucionar problemas de conexão com um aplicativo hospedado em um cluster do AKS

Artigo
11/19/2024

Nos ambientes de nuvem dinâmicos atuais, garantir a conectividade perfeita com aplicativos hospedados em clusters do AKS (Serviço de Kubernetes do Azure) é crucial para manter o desempenho e a experiência do usuário ideais. Este artigo aborda como solucionar problemas de conectividade causados por vários fatores, incluindo problemas do lado do aplicativo, políticas de rede, regras de NSG (grupo de segurança de rede) ou outros.

Observação

Para solucionar problemas comuns ao tentar se conectar ao servidor de API do AKS, consulte Solução de problemas básicos de problemas de conexão de cluster com o servidor de API.

Pré-requisitos

A ferramenta URL do cliente (cURL) ou uma ferramenta de linha de comando semelhante.
A ferramenta de linha de comando apt-get para lidar com pacotes.
A ferramenta de linha de comando Netcat (nc) para conexões TCP.
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 .

Fatores a considerar

Esta seção aborda as etapas de solução de problemas a serem seguidas se você estiver tendo problemas ao tentar se conectar ao aplicativo hospedado em um cluster do AKS.

Em qualquer cenário de rede, os administradores devem considerar os seguintes fatores importantes ao solucionar problemas:

Qual é a origem e o destino de uma solicitação?
Quais são os saltos entre a origem e o destino?
Qual é o fluxo de solicitação-resposta?
Quais saltos têm camadas de segurança extras na parte superior, como os seguintes itens:
- Firewall
- NSG (grupo de segurança de rede)
- Política de rede

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 e são especialmente úteis em cenários em que o aplicativo responde a solicitações HTTP.

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:

Saber como obter os códigos de resposta HTTP e fazer capturas de pacotes facilita a solução de problemas de conectividade de rede.

Fluxo de rede básico para aplicativos no AKS

Em geral, quando os aplicativos são expostos usando o tipo de serviço Azure Load Balancer, o fluxo de solicitação para acessá-los é o seguinte:

Nome >> DNS do cliente>>, endereço IP do balanceador de carga do AKS, >> nós >> do AKS, pods

Existem outras situações possíveis em que componentes extras podem estar envolvidos. Por exemplo:

A entrada NGINX gerenciada com o recurso complementar de roteamento de aplicativos está habilitada.
O gateway de aplicativo é usado por meio do AGIC (Controlador de Entrada do Gateway de Aplicativo ) em vez do Azure Load Balancer.
O Azure Front Door e o Gerenciamento de API podem ser usados sobre o balanceador de carga.
O processo usa um balanceador de carga interno.
A conexão pode não terminar no pod e na URL solicitada. Isso pode depender se o pod pode se conectar a outra entidade, como um banco de dados ou qualquer outro serviço no mesmo cluster.

É importante entender o fluxo de solicitação do aplicativo.

Um fluxo de solicitação básico para aplicativos em um cluster do AKS seria semelhante ao fluxo mostrado no diagrama a seguir.

Solução de problemas de dentro para fora

A solução de problemas de conectividade pode envolver muitas verificações, mas a abordagem de dentro para fora pode ajudar a encontrar a origem do problema e identificar o gargalo. Nessa abordagem, você começa no próprio pod, verificando se o aplicativo está respondendo no endereço IP do pod. Em seguida, verifique cada componente por sua vez até o cliente final.

Etapa 1: verificar se o pod está em execução e se o aplicativo ou contêiner dentro do pod está respondendo corretamente

Para determinar se o pod está em execução, execute um dos seguintes comandos kubectl get :

# List pods in the specified namespace.
kubectl get pods -n <namespace-name>

# List pods in all namespaces.
kubectl get pods -A

E se o pod não estiver em execução? Nesse caso, verifique os eventos do pod usando o comando kubectl describe :

kubectl describe pod <pod-name> -n <namespace-name>

Se o pod não estiver no estado ou Ready Running tiver sido reiniciado várias vezes, verifique a kubectl describe saída. Os eventos revelarão quaisquer problemas que impeçam você de iniciar o pod. Ou, se o pod tiver sido iniciado, o aplicativo dentro do pod poderá ter falhado, fazendo com que o pod seja reiniciado. Solucione problemas do pod adequadamente para garantir que ele esteja em um estado adequado.

Se o pod estiver em execução, também pode ser útil verificar os logs dos contêineres que estão dentro do pod. Execute a seguinte série de comandos kubectl logs :

kubectl logs <pod-name> -n <namespace-name>

# Check logs for an individual container in a multicontainer pod.
kubectl logs <pod-name> -n <namespace-name> -c <container-name>

# Dump pod logs (stdout) for a previous container instance.
kubectl logs <pod-name> --previous                      

# Dump pod container logs (stdout, multicontainer case) for a previous container instance.
kubectl logs <pod-name> -c <container-name> --previous

O pod está em execução? Nesse caso, teste a conectividade iniciando um pod de teste no cluster. No pod de teste, você pode acessar diretamente o endereço IP do pod do aplicativo e verificar se o aplicativo está respondendo corretamente. Execute os comandos kubectl run, apt-get, e da cURL seguinte maneira:

# Start a test pod in the cluster:
kubectl run -it --rm aks-ssh --image=debian:stable

# After the test pod is running, you will gain access to the pod.
# Then you can run the following commands:
apt-get update -y && apt-get install dnsutils -y && apt-get install curl -y && apt-get install netcat-traditional -y

# After the packages are installed, test the connectivity to the application pod:
curl -Iv http://<pod-ip-address>:<port>

Para aplicativos que escutam em outros protocolos, você pode instalar ferramentas relevantes dentro do pod de teste, como a ferramenta netcat, e verificar a conectividade com o pod do aplicativo executando o seguinte comando:

# After the packages are installed, test the connectivity to the application pod using netcat/nc command:
nc -z -v <pod-ip-address> <port>

Para obter mais comandos para solucionar problemas de pods, consulte Depurar pods em execução.

Etapa 2: verificar se o aplicativo pode ser acessado a partir do serviço

Para cenários em que o aplicativo dentro do pod está em execução, você pode se concentrar principalmente na solução de problemas de como o pod é exposto.

O pod é exposto como um serviço? Nesse caso, verifique os eventos de serviço. Além disso, verifique se o endereço IP do pod e a porta do aplicativo estão disponíveis como um endpoint na descrição do serviço:

# Check the service details.
kubectl get svc -n <namespace-name>

# Describe the service.
kubectl describe svc <service-name> -n <namespace-name>

Verifique se o endereço IP do pod está presente como um endpoint no serviço, como no exemplo a seguir:

$ kubectl get pods -o wide  # Check the pod's IP address.
NAME            READY   STATUS        RESTARTS   AGE   IP            NODE                                
my-pod          1/1     Running       0          12m   10.244.0.15   aks-agentpool-000000-vmss000000  

$ kubectl describe service my-cluster-ip-service  # Check the endpoints in the service.
Name:              my-cluster-ip-service
Namespace:         default
Selector:          app=my-pod
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.0.174.133
IPs:               10.0.174.133
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.244.0.15:80     # <--- Here

$ kubectl get endpoints  # Check the endpoints directly for verification.
NAME                      ENDPOINTS           AGE
my-cluster-ip-service     10.244.0.15:80      14m

Se os pontos de extremidade não estiverem apontando para o endereço IP do pod correto, verifique o Labels e Selectors do pod e do serviço.

Os pontos de extremidade no serviço estão corretos? Em caso afirmativo, acesse o serviço e verifique se o aplicativo está acessível.

Acessar o serviço ClusterIP

Para o ClusterIP serviço, você pode iniciar um pod de teste no cluster e acessar o endereço IP do serviço:

# Start a test pod in the cluster:
kubectl run -it --rm aks-ssh --image=debian:stable
  
# After the test pod is running, you will gain access to the pod.
# Then, you can run the following commands:
apt-get update -y && apt-get install dnsutils -y && apt-get install curl -y && apt-get install netcat-traditional -y
  
# After the packages are installed, test the connectivity to the service:
curl -Iv http://<service-ip-address>:<port>

# After the packages are installed, test the connectivity to the application pod using netcat/nc command:
nc -z -v <pod-ip-address> <port>

Se o comando anterior não retornar uma resposta apropriada, verifique se há erros nos eventos de serviço.

Acessar o serviço LoadBalancer

Para o LoadBalancer serviço, você pode acessar o endereço IP do balanceador de carga de fora do cluster.

curl -Iv http://<service-ip-address>:<port>

nc -z -v <pod-ip-address> <port>

O endereço IP do LoadBalancer serviço retorna uma resposta correta? Caso contrário, siga estas etapas:

Verifique os eventos do serviço.
Verifique se os NSGs (grupos de segurança de rede) associados aos nós do AKS e à sub-rede do AKS permitem o tráfego de entrada na porta de serviço.

Para obter mais comandos para solucionar problemas de serviços, consulte Depurar serviços.

Cenários que usam uma entrada em vez de um serviço

Para cenários em que o aplicativo é exposto usando um Ingress recurso, o fluxo de tráfego é semelhante à seguinte progressão:

Nome >> DNS do cliente >> Balanceador de carga ou endereço >> IP do gateway de aplicativo Pods do controlador de entrada dentro do serviço de cluster >> ou pods

Você também pode aplicar a abordagem de solução de problemas de dentro para fora aqui. Você também pode verificar o recurso do Kubernetes de entrada e os detalhes do controlador de entrada para obter mais informações:

$ kubectl get ing -n <namespace-of-ingress>  # Checking the ingress details and events.
NAME                         CLASS    HOSTS                ADDRESS       PORTS     AGE
hello-world-ingress          <none>   myapp.com            20.84.x.x     80, 443   7d22h

$ kubectl describe ing -n <namespace-of-ingress> hello-world-ingress
Name:             hello-world-ingress
Namespace:        <namespace-of-ingress>
Address:          20.84.x.x
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
TLS:
  tls-secret terminates myapp.com
Rules:
  Host                Path  Backends
  ----                ----  --------
  myapp.com
                      /blog   blog-service:80 (10.244.0.35:80)
                      /store  store-service:80 (10.244.0.33:80)

Annotations:          cert-manager.io/cluster-issuer: letsencrypt
                      kubernetes.io/ingress.class: nginx
                      nginx.ingress.kubernetes.io/rewrite-target: /$1
                      nginx.ingress.kubernetes.io/use-regex: true
Events:
  Type    Reason  Age    From                      Message
  ----    ------  ----   ----                      -------
  Normal  Sync    5m41s  nginx-ingress-controller  Scheduled for sync
  Normal  Sync    5m41s  nginx-ingress-controller  Scheduled for sync

Este exemplo contém um Ingress recurso que:

Ouve no anfitrião myapp.com .
Tem duas Path cadeias de caracteres configuradas.
Rotas para dois Services no back-end.

Verifique se os serviços de back-end estão em execução e responda à porta mencionada na descrição de entrada:

$ kubectl get svc -n <namespace-of-ingress>
NAMESPACE       NAME                                     TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                      
ingress-basic   blog-service                             ClusterIP      10.0.155.154   <none>        80/TCP                       
ingress-basic   store-service                            ClusterIP      10.0.61.185    <none>        80/TCP             
ingress-basic   nginx-ingress-ingress-nginx-controller   LoadBalancer   10.0.122.148   20.84.x.x     80:30217/TCP,443:32464/TCP

Verifique os logs dos pods do controlador de entrada se houver um erro:

$ kubectl get pods -n <namespace-of-ingress>  # Get the ingress controller pods.
NAME                                                     READY   STATUS    RESTARTS   AGE
aks-helloworld-one-56c7b8d79d-6zktl                      1/1     Running   0          31h
aks-helloworld-two-58bbb47f58-rrcv7                      1/1     Running   0          31h
nginx-ingress-ingress-nginx-controller-9d8d5c57d-9vn8q   1/1     Running   0          31h
nginx-ingress-ingress-nginx-controller-9d8d5c57d-grzdr   1/1     Running   0          31h

$ # Check logs from the pods.
$ kubectl logs -n ingress-basic nginx-ingress-ingress-nginx-controller-9d8d5c57d-9vn8q

E se o cliente estiver fazendo solicitações para o nome do host de entrada ou endereço IP, mas nenhuma entrada for vista nos logs do pod do controlador de entrada? Nesse caso, as solicitações podem não estar chegando ao cluster e o usuário pode estar recebendo uma mensagem de Connection Timed Out erro.

Outra possibilidade é que os componentes na parte superior dos pods de entrada, como o Balanceador de Carga ou o Gateway de Aplicativo, não estejam roteando as solicitações para o cluster corretamente. Se isso for verdadeiro, você poderá verificar a configuração de back-end desses recursos.

Se você receber uma mensagem de Connection Timed Out erro, verifique o grupo de segurança de rede associado aos nós do AKS. Além disso, verifique a sub-rede do AKS. Pode estar bloqueando o tráfego do balanceador de carga ou do gateway de aplicativo para os nós do AKS.

Para obter mais informações sobre como solucionar problemas de entrada (como a entrada do Nginx), consulte solução de problemas do ingress-nginx.

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.

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.

Compartilhar via