Problemas de conectividade de túnel

O AKS (Microsoft Serviço de Kubernetes do Azure) usa um componente específico para comunicação segura e em túnel entre os nós e o plano de controle. O túnel consiste em um servidor no lado do plano de controle e um cliente no lado dos nós de cluster. Este artigo discute como solucionar problemas e resolve problemas relacionados à conectividade de túnel no AKS.

Observação

Por padrão, e dependendo da região, o componente do túnel era tunnel-front. Ao atualizar para o recurso SLA (contrato de nível de serviço) em tempo de atividade, tunnel-front foi substituído pelo componente de túnel que usou OpenVPNaks-link. O AKS está migrando para a Konnectivity. Este é um componente do Kubernetes upstream que substitui tanto quanto tunnel-frontaks-link. Para obter mais informações sobre a migração para Konnectivity como o componente do túnel, consulte as notas de versão do AKS e o changelog.

Pré-requisitos

• CLI do Azure

Sintomas

Você recebe uma mensagem de erro que se assemelha aos seguintes exemplos sobre a porta 10250:

Erro do servidor: obter "https://< aks-node-name>:10250/containerLogs/namespace>/<<pod-name>/<container-name>": discar tcp <aks-node-ip>:10250: tempo limite de i/o

Erro do servidor: back-end de discagem de erro: discar 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 do túnel está agendado. Para obter mais informações, confira 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, a funcionalidade como a seguinte não funcionará conforme o esperado:

• Webhooks do controlador de admissão

• Capacidade de recuperação de log (usando o comando de logs kubectl )

• Executar um comando em um contêiner ou entrar em um contêiner (usando o comando exec kubectl )

• 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ê pode 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 a origem e o destino, a porta e o protocolo. Para obter mais informações, consulte Como os grupos de segurança de rede filtram o tráfego 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 serão capazes de alcançar o túnel, e o túnel está agendado em outros nós. Para verificar esse estado, você pode testar a conectividade usando 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 tem êxito, 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, adicione uma regra de segurança que permita o tráfego para a porta 10250 no nível da rede virtual. A imagem de portal do Azure a seguir mostra uma regra de segurança de exemplo:

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 menor (números inferiores têm maior prioridade). 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 componente do túnel. A exclusão desses pods faz com que eles sejam recriados.

Causa 2: a ferramenta UFW (firewall descomplicado) está bloqueando a porta 10250

Observação

Essa causa se aplica a qualquer componente de túnel que você tenha no cluster do AKS.

O UFW (Firewall descomplicado ) é um programa de linha de comando para gerenciar um firewall de netfilter . Os nós do AKS usam o Ubuntu. Portanto, a UFW está instalada em nós AKS por padrão, mas a UFW está desabilitada.

Por padrão, se a UFW estiver habilitada, bloqueará o acesso a todas as portas, incluindo a porta 10250. Nesse caso, é improvável que você possa usar o Secure Shell (SSH) para se conectar aos nós de cluster do AKS para solução de problemas. Isso ocorre porque a 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 a UFW está habilitada:

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 a UFW está habilitada e não permitir 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 habilitados para UFW. Para corrigir o problema, aplique uma das seguintes soluções na UFW.

Importante

Antes de usar essa ferramenta para fazer alterações, examine a política de suporte do AKS (especialmente manutenção e acesso de nós) para impedir que seu 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 componente do túnel. A exclusão desses pods fará com que eles sejam recriados.

Solução 2a: Desabilitar firewall descomplicado

Execute o seguinte az vmss run-command invoke comando para desabilitar a 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 firewall descomplicado para permitir o acesso à porta 10250

Para forçar a 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 do sistema configure as regras de filtro de pacote IP de um firewall do Linux. Você pode configurar as iptables regras para bloquear a comunicação na porta 10250.

Você pode exibir as regras para que seus nós marcar 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)
• target
• prot (protocolo)
• opt
• source
• destination

INPUT A cadeia contém uma regra na qual o destino é DROP, o protocolo é tcpe o destino é tcp dpt:10250? Se isso acontecer, iptables bloqueará o acesso à porta de destino 10250.

Solução 3: excluir a regra de 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ê marcar o manual de 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 manutenção e acesso de nós) para impedir que seu 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á restrições 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.

A 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: abrir a porta 1194 ou 9000

Verifique se a dispositivo virtual permite acesso à porta 1194 ou à porta 9000. Para obter mais informações sobre as regras e dependências necessárias, consulte Regras de rede necessárias do Azure Global.

Causa 5: Esgotamento da porta SNAT (Conversão de Endereço 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 aks privados. O esgotamento da porta SNAT (Conversão de Endereço 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 esgotamento da porta SNAT ( portas SNAT com falha), os nós não poderão se conectar ao servidor de API. O contêiner do 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. 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 fazer marcar 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:

1. No portal do Azure, pesquise e selecione Serviços do Kubernetes.

2. Na lista de serviços do Kubernetes, selecione o nome do cluster.

3. No painel de menus do cluster, localize o título Configurações e selecione Propriedades.

4. Selecione o nome listado em Grupo de recursos de infraestrutura.

5. Selecione o balanceador de carga kubernetes .

6. No painel de menus do balanceador de carga, localize o título Monitoramento e selecione Métricas.

7. Para o tipo de métrica, selecione Contagem de Conexões SNAT.

8. Selecione Aplicar divisão.

9. Defina Dividir por para Estado de Conexão.

Diagnóstico de serviço

Para usar o diagnóstico de serviço para exibir as portas SNAT, siga estas etapas:

1. No portal do Azure, pesquise e selecione Serviços do Kubernetes.

2. Na lista de serviços do Kubernetes, selecione o nome do cluster.

3. No painel de menus do cluster, selecione Diagnosticar e resolver problemas.

4. Selecione Problemas de conectividade.

5. Em Conexão SNAT e Alocação de Porta, selecione Exibir detalhes.

6. 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 pooling 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 de conexão. Verifique se o código do aplicativo está seguindo as melhores práticas e usando o pooling de conexões. A maioria das bibliotecas dá suporte ao pool de conexões. Portanto, você não deve criar uma nova conexão de saída por solicitação.

Solução 5b: ajustar as portas de saída alocadas

Se tudo estiver ok dentro do aplicativo, você terá que ajustar as portas de saída alocadas. Para obter mais informações sobre a alocação da porta de saída, consulte Configurar as portas de saída alocadas.

Solução 5c: usar um gateway nat (tradução de endereço de rede gerenciada) ao criar um cluster

Você pode configurar um novo cluster para usar um Gateway NAT (Tradução de Endereço de Rede Gerenciada) para conexões de saída. Para obter mais informações, consulte Criar um cluster 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.