Compartilhar via

Um grupo de segurança de rede personalizado bloqueia o tráfego

  • Artigo

Ao acessar um aplicativo hospedado em um cluster do AKS (Serviço de Kubernetes do Azure), você recebe uma mensagem de erro "Tempo limite". Esse erro pode ocorrer mesmo se o aplicativo estiver em execução e o restante da configuração parecer estar correto.

Pré-requisitos

Sintomas

Se você executar os seguintes comandos kubectl get e cURL, ocorrerá erros de "Tempo limite" semelhantes à seguinte saída do console:

$ kubectl get pods
NAME                             READY   STATUS    RESTARTS   AGE
my-deployment-66648877fc-v78jm   1/1     Running   0          5m53s

$ kubectl get service
NAME                      TYPE           CLUSTER-IP    EXTERNAL-IP    PORT(S)        AGE
my-loadbalancer-service   LoadBalancer   10.0.107.79   10.81.x.x   80:31048/TCP   4m14s

$ curl -Iv http://10.81.124.39  # Use an IP address that fits the "EXTERNAL-IP" pattern.
*   Trying 10.81.x.x:80...
* connect to 10.81.x.x port 80 failed: Timed out
* Failed to connect to 10.81.x.x port 80 after 21033 ms: Timed out
* Closing connection 0
curl: (28) Failed to connect to 10.81.x.x port 80 after 21033 ms: Timed out

Motivo

Se você tiver o mesmo erro "Tempo esgotado" todas as vezes, isso geralmente sugere que um componente de rede está bloqueando o tráfego.

Para solucionar esse problema, você pode começar verificando o acesso ao pod e, em seguida, passar para o cliente de dentro para fora .

Para verificar o pod, execute os seguintes kubectl get comandos e kubectl describe :

$ kubectl get pods -o wide
NAME                             READY   STATUS    RESTARTS   AGE   IP            NODE                               
my-deployment-66648877fc-v78jm   1/1     Running   0          53s   172.25.0.93   aks-agentpool-42617579-vmss000000

$ kubectl describe pod my-deployment-66648877fc-v78jm  # Specify the pod name from the previous command.
...
...
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  117s  default-scheduler  Successfully assigned default/my-deployment-66648877fc-v78jm to aks-agentpool-42617579-vmss000000
  Normal  Pulling    116s  kubelet            Pulling image "httpd"
  Normal  Pulled     116s  kubelet            Successfully pulled image "httpd" in 183.532816ms
  Normal  Created    116s  kubelet            Created container webserver
  Normal  Started    116s  kubelet            Started container webserver

Com base nessa saída, o pod parece estar funcionando corretamente, sem nenhuma reinicialização.

Abra um pod de teste para verificar o acesso ao pod do aplicativo. Execute os seguintes kubectl getcomandos , kubectl runapt-get e cURL:

$ kubectl get pods -o wide  # Get the pod IP address.
NAME                             READY   STATUS    RESTARTS   AGE     IP            NODE                                
my-deployment-66648877fc-v78jm   1/1     Running   0          7m45s   172.25.0.93   aks-agentpool-42617579-vmss000000  

$ kubectl run -it --rm aks-ssh --image=debian:stable  # Launch the test pod.
If you don't see a command prompt, try pressing enter.
$ root@aks-ssh:

$ # Install packages inside the test pod.
$ root@aks-ssh: apt-get update -y && apt-get install dnsutils -y && apt-get install curl -y
Get:1 http://deb.debian.org/debian bullseye InRelease [116 kB]
Get:2 http://deb.debian.org/debian bullseye-updates InRelease [39.4 kB]
...
...
Running hooks in /etc/ca-certificates/update.d...
done.

$ # Try to check access to the pod using the pod IP address from the "kubectl get" output.
$ curl -Iv http://172.25.0.93
*   Trying 172.25.0.93:80...
* Connected to 172.25.0.93 (172.25.0.93) port 80 (#0)
...
...
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
...
...
* Connection #0 to host 172.25.0.93 left intact

O pod pode ser acessado diretamente. Portanto, o aplicativo está em execução.

O serviço definido é um LoadBalancer tipo. Isso significa que o fluxo de solicitação do cliente final para o pod será o seguinte:

Nó do AKS do balanceador >> de carga do cliente >> Pod do >> aplicativo

Neste fluxo de requisição, podemos bloquear o tráfego através dos seguintes componentes:

  • Políticas de rede no cluster
  • O NSG (grupo de segurança de rede) para a sub-rede do AKS e o nó do AKS

Para verificar a política de rede, execute o seguinte kubectl get comando:

$ kubectl get networkpolicy --all-namespaces
NAMESPACE     NAME                 POD-SELECTOR             AGE
kube-system   konnectivity-agent   app=konnectivity-agent   3h8m

Existe apenas a política padrão do AKS. Portanto, a política de rede não parece estar bloqueando o tráfego.

Para verificar os NSGs e suas regras associadas usando o AKS, siga estas etapas:

  1. No portal do Azure, pesquise e selecione Conjuntos de dimensionamento de máquinas virtuais.

  2. Na lista de instâncias do conjunto de dimensionamento, selecione aquela que você está usando.

  3. No painel de menu da instância do conjunto de dimensionamento, selecione Networking.

A página Rede da instância do conjunto de dimensionamento é exibida. Na guia Regras de porta de entrada, são exibidos dois conjuntos de regras baseados nos dois NSGs que atuam na instância do conjunto de dimensionamento:

  • O primeiro conjunto é composto por regras NSG no nível da sub-rede. Essas regras são exibidas sob o seguinte título de nota:

    Grupo de segurança de rede my-aks-nsg> (anexado à sub-rede: <my-aks-subnet>)<

    Essa organização será comum se uma rede virtual personalizada e uma sub-rede personalizada para o cluster do AKS forem usadas. O conjunto de regras no nível da sub-rede pode ser semelhante à tabela a seguir.

    Priority Nome Porta Protocolo Origem Destino Ação
    65000 AllowVnetInBound Qualquer Qualquer VirtualNetwork VirtualNetwork Allow
    65001 AllowAzureLoadBalancerInBound Qualquer Qualquer AzureLoadBalancer Qualquer Allow
    65500 DenyAllInBound Qualquer Qualquer Qualquer Qualquer Negar

  • O segundo conjunto é composto por regras NSG no nível do adaptador de rede. Essas regras são exibidas sob o seguinte título de nota:

    Grupo de segurança de rede aks-agentpool-agentpool-number-nsg<> (anexado ao adaptador de rede: aks-agentpool-vm-scale-set-number-vmss)<>

    Esse NSG é aplicado pelo cluster do AKS e é gerenciado pelo AKS. O conjunto de regras correspondente pode ser semelhante à tabela a seguir.

    Priority Nome Porta Protocolo Origem Destino Ação
    500 <guid-TCP-80-Internet> 80 TCP Internet 10.81.x.x Permitir
    65000 AllowVnetInBound Qualquer Qualquer VirtualNetwork VirtualNetwork Allow
    65001 AllowAzureLoadBalancerInBound Qualquer Qualquer AzureLoadBalancer Qualquer Allow
    65500 DenyAllInBound Qualquer Qualquer Qualquer Qualquer Negar

No nível do adaptador de rede, há uma regra de entrada NSG para TCP no endereço IP 10.81.x.x na porta 80 (destacado na tabela). No entanto, uma regra equivalente está ausente das regras para o NSG no nível da sub-rede.

Por que o AKS não aplicou a regra ao NSG personalizado? Porque o AKS não aplica NSGs à sua sub-rede e não modificará nenhum dos NSGs associados a essa sub-rede. O AKS modificará os NSGs somente no nível do adaptador de rede. Para obter mais informações, consulte Posso configurar NSGs com o AKS?.

Solução

Se o aplicativo estiver habilitado para acesso em uma determinada porta, você deverá certificar-se de que o NSG personalizado permita essa porta como regra Inbound . Depois que a regra apropriada é adicionada ao NSG personalizado no nível da sub-rede, o aplicativo fica acessível.

$ curl -Iv http://10.81.x.x
*   Trying 10.81.x.x:80...
* Connected to 10.81.x.x (10.81.x.x) port 80 (#0)
...
...
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
...
...
* Connection #0 to host 10.81.x.x left intact

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.