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

  • Artigo

Quando você acessa 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 que o aplicativo esteja em execução e o restante da configuração pareça estar correto.

Pré-requisitos

Sintomas

Se você executar os seguintes comandos kubectl get e cURL, você experimentará erros de "Tempo limite" que se assemelham à 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 limite" sempre, 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 em uma abordagem de dentro para fora .

Para marcar o pod, execute os seguintes kubectl get comandos e descreva kubectl:

$ 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 sendo executado corretamente, sem nenhuma reinicialização.

Abra um pod de teste para marcar acesso ao pod de aplicativo. Execute os seguintes kubectl getcomandos , kubectl run, apt-gete 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 está acessível 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:

Pod de aplicativo do aks >> do balanceador >> de carga do cliente >>

Neste fluxo de solicitação, podemos bloquear o tráfego por meio 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ó AKS

Para marcar 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 marcar 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 de conjunto de escala, selecione a que você está usando.

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

A página Rede da instância de conjunto de dimensionamento é exibida. Na guia Regras de porta de entrada , dois conjuntos de regras são exibidos com base 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 no seguinte título de observação:

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

    Esse arranjo é comum se uma rede virtual personalizada e uma sub-rede personalizada para o cluster AKS forem usadas. O conjunto de regras no nível da sub-rede pode se assemelhar à tabela a seguir.

    Prioridade Nome Porta Protocolo Origem Destino Ação
    65000 AllowVnetInBound Qualquer Qualquer VirtualNetwork VirtualNetwork Permitir
    65001 PermitirAzureLoadBalancerInBound Qualquer Qualquer AzureLoadBalancer Qualquer Permitir
    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 no seguinte título de observação:

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

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

    Prioridade 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 Permitir
    65001 PermitirAzureLoadBalancerInBound Qualquer Qualquer AzureLoadBalancer Qualquer Permitir
    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 (realçado 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? Como o AKS não aplica NSGs à sua sub-rede, ele 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, confira Posso configurar NSGs com AKS?.

Solução

Se o aplicativo estiver habilitado para acesso em uma determinada porta, você deverá garantir que o NSG personalizado permita essa porta como uma Inbound regra. Depois que a regra apropriada for adicionada no NSG personalizado no nível da sub-rede, o aplicativo estará 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.