Um grupo de segurança de rede personalizado bloqueia o tráfego
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
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 .
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.
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:
No portal do Azure, pesquise e selecione Conjuntos de dimensionamento de máquinas virtuais.
Na lista de instâncias de conjunto de escala, selecione a que você está usando.
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.
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários