Problemas de conectividade do túnel
O AKS (Serviço de Kubernetes do Microsoft Azure) usa um componente específico para comunicação segura e em túnel entre os nós e o painel de controle. O túnel consiste em um servidor no lado do plano de controle e um cliente no lado dos nós do cluster. Este artigo discute como solucionar problemas relacionados à conectividade de túnel no AKS.
Observação
Anteriormente, o componente de túnel do AKS era tunnel-front. Agora ele foi migrado para o serviço Konnectivity, um componente upstream do Kubernetes. Para obter mais informações sobre essa migração, consulte as notas de versão e o log de alterações do AKS.
Pré-requisitos
Sintomas
Você recebe uma mensagem de erro semelhante aos seguintes exemplos sobre a porta 10250:
Erro do servidor: Obtenha "https://< aks-node-name>:10250/containerLogs/<namespace>/<pod-name>/<container-name>": disque tcp <aks-node-ip>:10250: tempo limite de E/S
Erro do servidor: erro ao discar back-end: disque tcp <aks-node-ip>:10250: tempo limite de E/S
O servidor de API do Kubernetes usa a porta 10250 para se conectar ao kubelet de um nó para recuperar os logs. Se a porta 10250 estiver bloqueada, os logs kubectl e outros recursos funcionarão apenas para pods executados nos nós nos quais o componente de túnel está programado. Para obter mais informações, consulte Portas e protocolos do Kubernetes: nós de trabalho.
Como os componentes do túnel ou a conectividade entre o servidor e o cliente não podem ser estabelecidos, funcionalidades como as seguintes não funcionarão conforme o esperado:
Webhooks do controlador de admissão
Capacidade de recuperação de log (usando o comando kubectl logs )
Executando um comando em um contêiner ou entrando em um contêiner (usando o comando kubectl exec )
Encaminhando uma ou mais portas locais de um pod (usando o comando kubectl port-forward )
Causa 1: um NSG (grupo de segurança de rede) está bloqueando a porta 10250
Observação
Essa causa é aplicável a todos os componentes de túnel que você possa ter no cluster do AKS.
Você pode usar um NSG (grupo de segurança de rede) do Azure para filtrar o tráfego de rede de e para recursos do Azure em uma rede virtual do Azure. Um grupo de segurança de rede contém regras de segurança que permitem ou negam o tráfego de rede de entrada e saída entre vários tipos de recursos do Azure. Para cada regra, você pode especificar origem e destino, porta e protocolo. Para obter mais informações, consulte Como filtrar o tráfego de rede com grupos de segurança de rede.
Se o NSG bloquear a porta 10250 no nível da rede virtual, as funcionalidades de túnel (como logs e execução de código) funcionarão apenas para os pods agendados nos nós em que os pods de túnel estão agendados. Os outros pods não funcionarão porque seus nós não poderão acessar o túnel e o túnel está agendado em outros nós. Para verificar esse estado, você pode testar a conectividade usando os comandos netcat (nc) ou telnet. Você pode executar o comando az vmss run-command invoke para realizar o teste de conectividade e verificar se ele é bem-sucedido, atinge o tempo limite ou causa algum outro problema:
az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
--name <virtual-machine-scale-set-name> \
--command-id RunShellScript \
--instance-id <instance-id> \
--scripts "nc -v -w 2 <ip-of-node-that-schedules-the-tunnel-component> 10250" \
--output tsv \
--query 'value[0].message'
Solução 1: Adicionar uma regra NSG para permitir o acesso à porta 10250
Se você usar um NSG e tiver restrições específicas, certifique-se de adicionar uma regra de segurança que permita o tráfego para a porta 10250 no nível da rede virtual. A imagem do portal do Azure a seguir mostra um exemplo de regra de segurança:
Se você quiser ser mais restritivo, poderá permitir o acesso à porta 10250 somente no nível da sub-rede.
Observação
O campo Prioridade deve ser ajustado de acordo. Por exemplo, se você tiver uma regra que nega várias portas (incluindo a porta 10250), a regra mostrada na imagem deverá ter um número de prioridade mais baixo (números mais baixos têm prioridade mais alta). Para obter mais informações sobre Prioridade, consulte Regras de segurança.
Se você não vir nenhuma alteração comportamental depois de aplicar essa solução, poderá recriar os pods de componentes do túnel. A exclusão desses pods faz com que eles sejam recriados.
Causa 2: A ferramenta Uncomplicated Firewall (UFW) está bloqueando a porta 10250
Observação
Essa causa se aplica a qualquer componente de túnel que você tenha no cluster do AKS.
Uncomplicated Firewall (UFW) é um programa de linha de comando para gerenciar um firewall netfilter . Os nós do AKS usam o Ubuntu. Portanto, o UFW é instalado nos nós do AKS por padrão, mas o UFW está desabilitado.
Por padrão, se o UFW estiver habilitado, ele bloqueará o acesso a todas as portas, incluindo a porta 10250. Nesse caso, é improvável que você possa usar o SSH (Secure Shell) para se conectar a nós de cluster do AKS para solução de problemas. Isso ocorre porque o UFW também pode estar bloqueando a porta 22. Para solucionar problemas, você pode executar o comando az vmss run-command invoke para invocar um comando ufw que verifica se o UFW está habilitado:
az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
--name <virtual-machine-scale-set-name> \
--command-id RunShellScript \
--instance-id <instance-id> \
--scripts "ufw status" \
--output tsv \
--query 'value[0].message'
E se os resultados indicarem que o UFW está habilitado e não permite especificamente a porta 10250? Nesse caso, as funcionalidades de túnel (como logs e execução de código) não funcionarão para os pods agendados nos nós que têm o UFW habilitado. Para corrigir o problema, aplique uma das seguintes soluções no UFW.
Importante
Antes de usar essa ferramenta para fazer alterações, examine a política de suporte do AKS (especialmente a manutenção e o acesso ao nó) para impedir que o cluster entre em um cenário sem suporte.
Observação
Se você não vir nenhuma alteração comportamental depois de aplicar uma solução, poderá recriar os pods de componentes do túnel. A exclusão desses pods fará com que eles sejam recriados.
Solução 2a: desative o firewall descomplicado
Execute o seguinte az vmss run-command invoke comando para desativar o UFW:
az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
--name <virtual-machine-scale-set-name> \
--command-id RunShellScript \
--instance-id <instance-id> \
--scripts "ufw disable" \
--output tsv \
--query 'value[0].message'
Solução 2b: Configurar o Firewall Descomplicado para permitir o acesso à porta 10250
Para forçar o UFW a permitir o acesso à porta 10250, execute o seguinte az vmss run-command invoke comando:
az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
--name <virtual-machine-scale-set-name> \
--command-id RunShellScript \
--instance-id <instance-id> \
--scripts "ufw allow 10250" \
--output tsv \
--query 'value[0].message'
Causa 3: A ferramenta iptables está bloqueando a porta 10250
Observação
Essa causa se aplica a qualquer componente de túnel que você tenha no cluster do AKS.
A ferramenta iptables permite que um administrador de sistema configure as regras de filtro de pacotes IP de um firewall Linux. Você pode configurar as regras para bloquear a iptables comunicação na porta 10250.
Você pode visualizar as regras para seus nós para verificar se a porta 10250 está bloqueada ou se os pacotes associados são descartados. Para fazer isso, execute o seguinte iptables comando:
iptables --list --line-numbers
Na saída, os dados são agrupados em várias cadeias, incluindo a INPUT cadeia. Cada cadeia contém uma tabela de regras nos seguintes títulos de coluna:
num(número da regra)targetprot(protocolo)optsourcedestination
A INPUT cadeia contém uma regra na qual o destino é DROP, o protocolo é tcp, e o destino é tcp dpt:10250? Em caso afirmativo, iptables o está bloqueando o acesso à porta de destino 10250.
Solução 3: Exclua a regra iptables que bloqueia o acesso na porta 10250
Execute um dos seguintes comandos para excluir a regra que impede o iptables acesso à porta 10250:
iptables --delete INPUT --jump DROP --protocol tcp --source <ip-number> --destination-port 10250
iptables --delete INPUT <input-rule-number>
Para resolver seu cenário exato ou potencial, recomendamos que você verifique o manual do iptables executando o iptables --help comando.
Importante
Antes de usar essa ferramenta para fazer alterações, examine a política de suporte do AKS (especialmente a manutenção e o acesso ao nó) para impedir que o cluster entre em um cenário sem suporte.
Causa 4: a porta de saída 1194 ou 9000 não está aberta
Observação
Essa causa se aplica apenas aos tunnel-front pods e aks-link .
Há alguma restrição de tráfego de saída, como de um firewall do AKS? Se houver, a porta 9000 será necessária para habilitar a funcionalidade correta do tunnel-front pod. Da mesma forma, a porta 1194 é necessária para o aks-link pod.
Konnectivity depende da porta 443. Por padrão, essa porta está aberta. Portanto, você não precisa se preocupar com problemas de conectividade nessa porta.
Solução 4: Abra a porta 9000
Embora tunnel-front tenha sido movido para o serviço Konnectivity, alguns clusters do AKS ainda usam tunnel-fronto , que depende da porta 9000. Certifique-se de que o dispositivo virtual ou qualquer dispositivo de rede ou software permita o acesso à porta 9000. Para obter mais informações sobre as regras e dependências necessárias, consulte Regras de rede globais necessárias do Azure.
Causa 5: esgotamento da porta SNAT (Conversão de Endereços de Rede de Origem)
Observação
Essa causa se aplica a qualquer componente de túnel que você tenha no cluster do AKS. No entanto, ele não se aplica a clusters privados do AKS. O esgotamento da porta SNAT (Conversão de Endereços de Rede de Origem) pode ocorrer apenas para comunicação pública. Para clusters AKS privados, o servidor de API está dentro da rede virtual ou sub-rede do AKS.
Se ocorrer o esgotamento da porta SNAT (portas SNAT com falha), os nós não poderão se conectar ao servidor de API. O contêiner de túnel está no lado do servidor de API. Portanto, a conectividade do túnel não será estabelecida.
Se os recursos da porta SNAT estiverem esgotados, os fluxos de saída falharão até que os fluxos existentes liberem algumas portas SNAT. O Azure Load Balancer recupera as portas SNAT quando o fluxo é fechado. Ele usa um tempo limite ocioso de quatro minutos para recuperar as portas SNAT dos fluxos ociosos.
Você pode exibir as portas SNAT das métricas do balanceador de carga do AKS ou do diagnóstico de serviço, conforme descrito nas seções a seguir. Para obter mais informações sobre como exibir portas SNAT, consulte Como verifico minhas estatísticas de conexão de saída?.
Métricas do balanceador de carga do AKS
Para usar as métricas do balanceador de carga do AKS para exibir as portas SNAT, siga estas etapas:
No portal do Azure, pesquise e selecione Serviços do Kubernetes.
Na lista de serviços do Kubernetes, selecione o nome do cluster.
No painel de menu do cluster, localize o cabeçalho Configurações e selecione Propriedades.
Selecione o nome listado em Grupo de recursos de infraestrutura.
Selecione o balanceador de carga do kubernetes .
No painel de menu do balanceador de carga, localize o cabeçalho Monitoramento e selecione Métricas.
Para o tipo de métrica, selecione Contagem de Conexões SNAT.
Selecione Aplicar divisão.
Defina Dividir por como Estado da conexão.
Diagnóstico de serviço
Para usar o diagnóstico de serviço para exibir as portas SNAT, siga estas etapas:
No portal do Azure, pesquise e selecione Serviços do Kubernetes.
Na lista de serviços do Kubernetes, selecione o nome do cluster.
No painel de menu do cluster, selecione Diagnosticar e resolver problemas.
Selecione Problemas de conectividade.
Em Conexão SNAT e Alocação de Porta, selecione Exibir detalhes.
Se necessário, use o botão Intervalo de tempo para personalizar o período de tempo.
Solução 5a: verifique se o aplicativo está usando o pool de conexões
Esse comportamento pode ocorrer porque um aplicativo não está reutilizando conexões existentes. Recomendamos que você não crie uma conexão de saída por solicitação. Essa configuração pode causar esgotamento da conexão. Verifique se o código do aplicativo está seguindo as práticas recomendadas e usando o pool de conexões. A maioria das bibliotecas dá suporte ao pool de conexões. Portanto, você não deve ter que criar uma nova conexão de saída por solicitação.
Solução 5b: Ajuste as portas de saída alocadas
Se tudo estiver OK no aplicativo, você terá que ajustar as portas de saída alocadas. Para obter mais informações sobre a alocação de portas de saída, consulte Configurar as portas de saída alocadas.
Solução 5c: Usar um gateway NAT (conversão de endereços de rede) gerenciado ao criar um cluster
Você pode configurar um novo cluster para usar um Gateway NAT (Managed Network Address Translation) para conexões de saída. Para obter mais informações, consulte Criar um cluster do AKS com um Gateway NAT Gerenciado.
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.
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.