Solucionar problemas de status não pronto de um nó saudável

  • Artigo

Este artigo discute um cenário em que o status de um nó de cluster do AKS (Serviço de Kubernetes do Azure) muda para Não Pronto depois que o nó está em um estado saudável há algum tempo. Este artigo descreve a causa específica e fornece uma possível solução.

Pré-requisitos

Sintomas

O status de um nó de cluster que tem um estado saudável (todos os serviços em execução) muda inesperadamente para Não Pronto. Para exibir o status de um nó, execute o seguinte comando de descrever kubectl:

kubectl describe nodes

Motivo

O kubelet parou de postar seu status Pronto.

Examine a saída do kubectl describe nodes comando para localizar o campo Condições e os blocosCapacidade e Alocação . O conteúdo desses campos aparece conforme o esperado? (Por exemplo, no campo Condições, a message propriedade contém a cadeia de caracteres "kubelet está postando pronto status"?) Nesse caso, se você tiver acesso direto do Secure Shell (SSH) ao nó, marcar os eventos recentes para entender o erro. Procure no arquivo /var/log/messages . Ou gere os arquivos de log de daemon kubelet e contêiner executando os seguintes comandos de shell:

journalctl --directory=. --unit=kubelet > kubelet.log
journalctl --directory=. --unit=docker > docker.log

Depois de executar esses comandos, examine os arquivos de log daemon para obter detalhes sobre o erro.

Etapa 1: verificar se há alterações no nível da rede

Se todos os nós de cluster regredirem para um status Não Pronto, marcar se alguma alteração ocorreu no nível da rede. Exemplos de alterações no nível da rede incluem os seguintes itens:

  • Alterações no DNS (sistema de nomes de domínio)
  • Alterações na porta do firewall
  • NSGs (grupos de segurança de rede) adicionados

Se houver alterações no nível da rede, faça as correções necessárias. Pare e reinicie os nós em execução depois de corrigir os problemas. Se os nós permanecerem em um estado saudável após essas correções, você poderá ignorar com segurança as etapas restantes.

Etapa 2: parar e reiniciar os nós

Se apenas alguns nós regredissem para um status Não Pronto, basta parar e reiniciar os nós. Essa ação por si só pode retornar os nós a um estado saudável. Em seguida, marcar Serviço de Kubernetes do Azure diagnóstico visão geral para determinar se há algum problema, como os seguintes problemas:

  • Falhas de nó
  • Falhas de SNAT (conversão de endereço de rede de origem)
  • Operações de entrada/saída de nó por segundo (problemas de desempenho do IOPS)
  • Outros problemas

Se o diagnóstico não descobrir problemas subjacentes, você poderá ignorar com segurança as etapas restantes.

Etapa 3: corrigir problemas de SNAT para clusters de API do AKS públicos

O AKS diagnóstico descobriu algum problema de SNAT? Nesse caso, tome algumas das seguintes ações, conforme apropriado:

  • Verifique se suas conexões permanecem ociosas por muito tempo e dependem do tempo limite ocioso padrão para liberar sua porta. Se as conexões exibirem esse comportamento, talvez seja necessário reduzir o tempo limite padrão de 30 minutos.

  • Determine como seu aplicativo cria conectividade de saída. Por exemplo, ele usa a revisão de código ou a captura de pacotes?

  • Determine se essa atividade representa o comportamento esperado ou, em vez disso, mostra que o aplicativo está se comportando mal. Use métricas e logs no Azure Monitor para comprovar suas descobertas. Por exemplo, você pode usar a categoria Failed como uma métrica de Connections SNAT.

  • Avalie se os padrões apropriados são seguidos.

  • Avalie se você deve reduzir o esgotamento da porta SNAT usando endereços IP de saída extras e portas de saída mais alocadas. Para obter mais informações, consulte Dimensionar o número de IPs públicos de saída gerenciados e Configurar as portas de saída alocadas.

Etapa 4: corrigir problemas de desempenho do IOPS

Se o AKS diagnóstico descobrir problemas que reduzem o desempenho do IOPS, tome algumas das seguintes ações, conforme apropriado:

  • Para aumentar o IOPS em conjuntos de escala de máquina virtual (VM), altere o tamanho do disco implantando um novo pool de nós.

  • Aumente o tamanho do SKU do nó para obter mais capacidade de processamento de memória e CPU.

  • Considere usar o sistema operacional Efêmero.

  • Limite o uso de CPU e memória para pods. Esses limites ajudam a evitar o consumo de CPU do nó e situações fora da memória.

  • Use métodos de topologia de agendamento para adicionar mais nós e distribuir a carga entre os nós. Para obter mais informações, consulte Restrições de propagação de topologia do Pod.

Etapa 5: corrigir problemas de threading

Componentes do Kubernetes, como kubelets e runtimes contêineres , dependem fortemente do threading e geram novos threads regularmente. Se a alocação de novos threads não for bem-sucedida, essa falha poderá afetar a preparação do serviço, da seguinte maneira:

  • O nó status é alterado para Não Pronto, mas é reiniciado por um corretivo e é capaz de se recuperar.

  • Nos arquivos de log /var/log/messages e /var/log/syslog , há ocorrências repetidas das seguintes entradas de erro:

    falha pthread_create: recurso temporariamente indisponível por vários processos

    Os processos citados incluem contêiner e, possivelmente, kubelet.

  • O nó status é alterado para Não Pronto logo após as pthread_create entradas de falha serem gravadas nos arquivos de log.

As IDs de processo (PIDs) representam threads. O número padrão de PIDs que um pod pode usar pode depender do sistema operacional. No entanto, o número padrão é de pelo menos 32.768. Esse valor é mais do que pids suficientes para a maioria das situações. Há algum requisito de aplicativo conhecido para recursos mais altos do PID? Se não houver, até mesmo um aumento de oito vezes para 262.144 PIDs pode não ser suficiente para acomodar um aplicativo de alto recurso.

Em vez disso, identifique o aplicativo ofensivo e, em seguida, tome as medidas apropriadas. Considere outras opções, como aumentar o tamanho da VM ou atualizar o AKS. Essas ações podem atenuar o problema temporariamente, mas não são garantia de que o problema não reaparecerá novamente.

Para monitorar a contagem de threads de cada grupo de controle (cgroup) e imprimir os oito principais grupos, execute o seguinte comando shell:

watch 'ps -e -w -o "thcount,cgname" --no-headers | awk "{a[\$2] += \$1} END{for (i in a) print a[i], i}" | sort --numeric-sort --reverse | head --lines=8'

Para obter mais informações, confira Limites e reservas de ID do processo.

O Kubernetes oferece dois métodos para gerenciar o esgotamento do PID no nível do nó:

  1. Configure o número máximo de PIDs permitidos em um pod dentro de um kubelet usando o --pod-max-pids parâmetro. Essa configuração define a pids.max configuração dentro do grupo de cada pod. Você também pode usar os --system-reserved parâmetros e --kube-reserved para configurar os limites do sistema e do kubelet, respectivamente.

  2. Configurar o despejo baseado em PID.

Observação

Por padrão, nenhum desses métodos é configurado. Além disso, no momento, você não pode configurar nenhum dos métodos usando a configuração de nó para pools de nós do AKS.

Etapa 6: usar uma camada de serviço mais alta

Você pode garantir que o servidor de API do AKS tenha alta disponibilidade usando uma camada de serviço mais alta. Para obter mais informações, consulte o SLA de tempo de atividade do SERVIÇO DE KUBERNETES DO AZURE (AKS).

Mais informações