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

Artigo
04/12/2024

Problemas de conexão com um cluster do AKS (Microsoft Serviço de Kubernetes do Azure) podem significar coisas diferentes. Em alguns casos, isso pode significar que a conexão com o servidor de API é afetada (por exemplo, usando kubectl). Em outros casos, isso pode significar que problemas comuns de conexão afetam um aplicativo hospedado no cluster do AKS. Este artigo discute como solucionar problemas de conexão de cluster do AKS.

Observação

Para solucionar problemas comuns ao tentar se conectar ao servidor de API do AKS, confira Solução de problemas básicos 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 kubernetes kubectl 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 serem considerados

Esta seção aborda as etapas de solução de problemas a serem executadas 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

Quando você marcar cada componente, obtenha e analise 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 às 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. 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 AKS, confira 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, o fluxo de solicitação para acessar aplicativos hospedados em um cluster do AKS é o seguinte:

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

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

O gateway de aplicativo é usado por meio do AGIC (Controlador de Entrada) Gateway de Aplicativo em vez de Azure Load Balancer.
O Azure Front Door e Gerenciamento de API podem ser usados em cima do 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 AKS se assemelharia 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, marcar cada componente em aparecer para o cliente final.

Etapa 1: verifique 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 de obter kubectl :

# 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, marcar os eventos do pod usando o comando de descrever kubectl:

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

Se o pod não estiver em um Ready estado ou Running ou reiniciado muitas vezes, marcar a kubectl describe saída. Os eventos revelarão quaisquer problemas que impeçam que você possa iniciar o pod. Ou, se o pod tiver começado, o aplicativo dentro do pod poderá ter falhado, fazendo com que o pod seja reiniciado. Solucionar problemas do pod de acordo para verificar se ele está em um estado adequado.

Se o pod estiver em execução, ele também poderá ser útil para marcar os logs dos pods e os contêineres que estão dentro deles. Execute a seguinte série de comandos de logs kubectl :

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 marcar se o aplicativo está respondendo corretamente. Execute a execução do kubectl, apt-gete os cURL comandos da 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

# 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 e, em seguida, marcar a conectividade com o pod de aplicativo.

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

Etapa 2: verifique se o aplicativo pode ser acessado no 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 está exposto como um serviço? Nesse caso, marcar os eventos de serviço. Além disso, marcar se o endereço IP do pod e a porta do aplicativo estão disponíveis como um ponto de extremidade 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 ponto de extremidade 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 para o pod e o serviço.

Os pontos de extremidade no serviço estão corretos? Nesse caso, acesse o serviço e marcar se o aplicativo é 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
  
# After the packages are installed, test the connectivity to the service:
curl -Iv http://<service-ip-address>:<port>

Se o comando anterior não retornar uma resposta apropriada, marcar os eventos de serviço para quaisquer erros.

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>

O endereço IP do LoadBalancer serviço retorna uma resposta correta? Se não o fizer, siga estas etapas:

Verifique os eventos do serviço.
Verifique se os NSGs (grupos de segurança de rede) associados aos nós AKS e à sub-rede 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 se assemelha à seguinte progressão:

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

Você pode aplicar a abordagem de dentro para fora da solução de problemas aqui também. Você também pode marcar os detalhes do controlador de entrada e 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:

Escuta no myapp.com host.
Tem duas Path cadeias de caracteres configuradas.
Roteia 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 há 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 atingindo o cluster e o usuário pode estar recebendo uma Connection Timed Out mensagem de erro.

Outra possibilidade é que os componentes em cima dos pods de entrada, como Load Balancer ou Gateway de Aplicativo, não estejam roteando as solicitações para o cluster corretamente. Se isso for verdade, você poderá marcar a configuração de back-end desses recursos.

Se você receber uma mensagem de Connection Timed Out erro, marcar o grupo de segurança de rede associado aos nós do AKS. Além disso, marcar a sub-rede AKS. Ele 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 Nginx), confira solução de problemas de entrada-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.