Tempos limite de TCP quando o kubectl ou outras ferramentas de terceiros se conectam ao servidor de API
Este artigo discute como solucionar problemas de tempos limite de TCP que ocorrem quando o kubectl ou outras ferramentas de terceiros são usadas para se conectar ao servidor de API no AKS (Serviço de Kubernetes do Microsoft Azure). Para garantir seus SLOs (objetivos de nível de serviço) e SLAs (contratos de nível de serviço), o AKS usa planos de controle de HA (alta disponibilidade) que são dimensionados vertical e horizontalmente, com base no número de núcleos.
Sintomas
Você experimenta tempos limite de conexão repetidos.
Causa 1: os pods responsáveis pela comunicação entre o nó e o plano de controle não estão em execução
Se apenas alguns dos comandos da API estiverem atingindo o tempo limite de forma consistente, os seguintes pods podem não estar em um estado de execução:
konnectivity-agenttunnelfrontaks-link
Observação
Nas versões mais recentes do AKS, e aks-link são substituídos por konnectivity-agent, portanto, tunnelfront você verá konnectivity-agentapenas .
Esses pods são responsáveis pela comunicação entre um nó e o plano de controle.
Solução: Reduza a utilização ou o estresse dos hosts do nó
Certifique-se de que os nós que hospedam esses pods não sejam excessivamente utilizados ou sob estresse. Considere mover os nós para seu próprio pool de nós do sistema.
Para verificar em qual nó o konnectivity-agent pod está hospedado e o uso do nó, execute os seguintes comandos:
# Check which node the konnectivity-agent pod is hosted on
$ kubectl get pod -n kube-system -o wide
# Check the usage of the node hosting the pod
$ kubectl top node
Causa 2: o acesso está bloqueado em algumas portas, FQDNs e endereços IP necessários
Se as portas, os FQDNs (nomes de domínio totalmente qualificados) e os endereços IP necessários não estiverem todos abertos, várias chamadas de comando poderão falhar. A comunicação segura e encapsulada no AKS entre o servidor de API e o kubelet (por meio do konnectivity-agent pod) requer que alguns desses itens funcionem com êxito.
Solução: abra as portas, FQDNs e endereços IP necessários
Para obter mais informações sobre quais portas, FQDNs e endereços IP precisam ser abertos, consulte Rede de saída e regras de FQDN para clusters do AKS (Serviço de Kubernetes do Azure).
Causa 3: a extensão TLS de negociação de protocolo de camada de aplicativo está bloqueada
Para estabelecer uma conexão entre o plano de controle e os nós, o konnectivity-agent pod requer a extensão TLS (Transport Layer Security) para ALPN (Application-Layer Protocol Negotiation). Você pode ter bloqueado essa extensão anteriormente.
Solução: habilitar a extensão ALPN
Ative a extensão ALPN no konnectivity-agent pod para evitar tempos limite de TCP.
Causa 4: os intervalos autorizados de IP do servidor de API não cobrem seu endereço IP atual
Se você usar intervalos de endereços IP autorizados no servidor de API, as chamadas de API serão bloqueadas se o IP não estiver incluído nos intervalos autorizados.
Solução: modifique os intervalos de endereços IP autorizados para que eles cubram seu endereço IP
Altere os intervalos de endereços IP autorizados para que seu endereço IP seja coberto. Para obter mais informações, consulte Atualizar os intervalos de IP autorizados do servidor de API de um cluster.
Causa 5: um cliente ou aplicativo vaza chamadas para o servidor de API
Chamadas GET frequentes podem acumular e sobrecarregar o servidor de API.
Solução: use inspeções em vez de chamadas GET, mas verifique se o aplicativo não vaza essas chamadas
Certifique-se de usar inspeções em vez de chamadas GET frequentes para o servidor de API. Você também precisa garantir que seus aplicativos de terceiros não vazem nenhuma conexão de relógio ou chamadas GET. Por exemplo, na arquitetura de microsserviço do Istio, um bug no aplicativo mixer cria uma nova conexão de inspeção do servidor de API sempre que um segredo é lido internamente. Como esse comportamento ocorre em intervalos regulares, as conexões de inspeção se acumulam rapidamente. Essas conexões eventualmente fazem com que o servidor de API fique sobrecarregado, independentemente do padrão de dimensionamento.
Causa 6: muitas versões em suas implantações do Helm
Se você usar muitas versões em suas implantações do Helm (o gerenciador de pacotes do Kubernetes), os nós começarão a consumir muita memória. Isso também resulta em uma grande quantidade de objetos (dados de configuração), o que pode causar picos de uso desnecessários no servidor de ConfigMap API.
Solução: Limite o número máximo de revisões para cada versão
Como o número máximo de revisões para cada versão é infinito por padrão, você precisa executar um comando para definir esse número máximo como um valor razoável. Para o Helm 2, o comando é helm init. Para o Helm 3, o comando é helm upgrade. Defina o --history-max <value> parâmetro ao executar o comando.
| Versão | Comando |
|---|---|
| Helm 2 | helm init --history-max <maximum-number-of-revisions-per-release> ... |
| Helm 3 | helm upgrade ... --history-max <maximum-number-of-revisions-per-release> ... |
Causa 7: O tráfego interno entre os nós está sendo bloqueado
Pode haver bloqueios de tráfego interno entre nós no cluster do AKS.
Solução: solucione o erro "discar tcp <Node_IP>:10250: tempo limite de E/S"
Causa 8: Seu cluster é privado
Seu cluster é um cluster privado, mas o cliente do qual você está tentando acessar o servidor de API está em uma rede pública ou diferente que não pode se conectar à sub-rede usada pelo AKS.
Solução: usar um cliente que possa acessar a sub-rede do AKS
Como o cluster é privado e seu painel de controle está na sub-rede do AKS, ele não pode ser conectado ao servidor de API, a menos que esteja em uma rede que possa se conectar à sub-rede do AKS. É um comportamento esperado.
Nesse caso, tente acessar o servidor de API de um cliente em uma rede que possa se comunicar com a sub-rede do AKS. Além disso, verifique se os NSGs (grupos de segurança de rede) ou outros dispositivos entre redes não estão bloqueando pacotes.
Aviso de isenção de responsabilidade para informações de terceiros
Os produtos de terceiros mencionados neste artigo são produzidos por empresas independentes da Microsoft. A Microsoft não oferece nenhuma garantia, implícita ou não, do desempenho ou da confiabilidade desses produtos.
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.