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.

Pré-requisitos

• CLI do Azure

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 conectar ao back-end: conectar tcp <aks-node-ip>:10250: tempo de espera excedido

Erro do servidor: Recebendo "https://<aks-node-name>:10250/containerLogs/<namespace>/<pod-name>/<container-name>": http: o servidor deu resposta HTTP ao cliente HTTPS

O servidor de API do Kubernetes usa a porta 10250 para se conectar ao kubelet do nó e obter 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

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 programados nos nós onde os pods de túnel estão localizados. Os outros pods não funcionarão porque seus nós não poderão alcançar o túnel e o túnel está programado 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.

Causa 2: A ferramenta Uncomplicated Firewall (UFW) está bloqueando a porta 10250

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.

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

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 sob os seguintes cabeçalhos de coluna:

• num (número da regra)
• target
• prot (protocolo)
• opt
• source
• destination

A cadeia de regras INPUT contém uma regra na qual o alvo é DROP, o protocolo é tcp e o destino é tcp dpt:10250? Em caso afirmativo, iptables 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 oiptables --helpcomando.

Causa 4: a porta de saída 1194 ou 9000 não está aberta

Existem restrições de tráfego de saída, como as 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-front, 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)

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 de inatividade de quatro minutos para recuperar as portas SNAT dos fluxos inativos.

Você pode visualizar as portas SNAT nas métricas do balanceador de carga do AKS ou nos diagnósticos de serviço, conforme descrito nas seções seguintes. Para obter mais informações sobre como exibir portas SNAT, consulte Como verifico minhas estatísticas de conexão de saída?.

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 precisar 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.

Causa 6: Problemas de desempenho do Konnectivity Agents com o crescimento do cluster

À medida que o cluster aumenta, o desempenho dos Agentes de Konnectivity pode diminuir devido ao aumento do tráfego de rede, mais solicitações ou restrições de recursos.

Solução 6: Dimensionador Automático Proporcional de Cluster para o Konnectivity Agent

Para gerenciar desafios de escalabilidade em clusters grandes, implementamos o Dimensionador Automático Proporcional de Cluster para nossos Agentes de Konnectivity. Essa abordagem se alinha aos padrões e práticas recomendadas do setor. Ele garante o uso ideal de recursos e o desempenho aprimorado.

Por que essa alteração foi feita Anteriormente, o agente Konnectivity tinha uma contagem de réplicas fixa que poderia criar um gargalo à medida que o cluster crescia. Implementando o Dimensionador Automático Proporcional de Cluster, habilitamos a contagem de réplicas para ajustar-se dinamicamente, com base em regras de dimensionamento de nó, para fornecer um desempenho ideal e uso de recursos.

Como funciona o Dimensionador Automático Proporcional de Cluster O funcionamento do Dimensionador Automático Proporcional de Cluster usa uma configuração de escada para determinar o número de réplicas do Agente Konnectivity com base no tamanho do cluster. A configuração da escada é definida no configmap konnectivity-agent-autoscaler no namespace kube-system. Aqui está um exemplo da configuração da escada:

nodesToReplicas": [
    [1, 2],
    [100, 3],
    [250, 4],
    [500, 5],
    [1000, 6],
    [5000, 10]
]

Essa configuração garante que o número de réplicas seja dimensionado adequadamente com o número de nós no cluster para fornecer alocação de recursos ideal e confiabilidade de rede aprimorada.

Como usar o Dimensionador Automático Proporcional de Cluster? Você pode substituir os valores padrão atualizando o configmap konnectivity-agent-autoscaler no namespace kube-system. Aqui está um comando de exemplo para atualizar o configmap:

kubectl edit configmap <pod-name> -n kube-system

Esse comando abre o configmap em um editor para permitir que você faça as alterações necessárias.

O que você deve verificar

Você precisa monitorar as mortes por OOM (Memória Insuficiente) nos nós porque a configuração incorreta do Dimensionador Automático Proporcional de Cluster pode causar alocação de memória insuficiente para os agentes de Konnectivity. Essa configuração incorreta ocorre pelos seguintes principais motivos:

Alto uso de memória: À medida que o cluster aumenta, o uso de memória dos agentes Konnectivity pode aumentar significativamente. Esse aumento pode ocorrer especialmente durante cargas de pico ou ao lidar com um grande número de conexões. Se a configuração do Dimensionador Automático Proporcional de Cluster não dimensionar as réplicas corretamente, os agentes poderão ficar sem memória.

Limites de recursos fixos: Se as solicitações de recurso e os limites para os agentes de Konnectivity forem definidos muito baixos, talvez eles não tenham memória suficiente para lidar com a carga de trabalho, levando a eliminações de OOM. Configurações mal configuradas do Dimensionador Automático Proporcional de Cluster podem agravar esse problema, não fornecendo réplicas suficientes para distribuir a carga.

Tamanho do cluster e variabilidade da carga de trabalho: A CPU e a memória necessárias para os agentes konnectivity podem variar muito dependendo do tamanho do cluster e da carga de trabalho. Se a configuração da escada do Dimensionador Automático Proporcional de Cluster não for do tamanho certo e for redimensionada adaptável para os padrões de uso do cluster, isso poderá causar excesso de comprometimento de memória e eliminações de OOM.

Para identificar e solucionar problemas de eliminações de OOM, siga estas etapas:

1. Verifique se há kills do OOM nos nós: use o seguinte comando para verificar kills do OOM em seus nós:

kubectl get events --all-namespaces | grep -i 'oomkill'

2. Inspecione o uso de recursos nos seus nós: verifique o uso de memória para garantir que eles não estejam ficando sem memória.

kubectl top nodes

3. Examinar solicitações e limites de recursos do Pod: verifique se os pods do agente konnectivity têm solicitações de recursos e limites apropriados definidos para evitar o OOM Kills:

kubectl get pod <pod-name> -n kube-system -o yaml | grep -A5 "resources:"

4. Ajustar solicitações e limites de recursos: se necessário, ajuste as solicitações e limites de recursos para os pods do agente Konnectivity editando a implantação:

kubectl edit deployment konnectivity-agent -n kube-system

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.