Compartilhar via

Solucionar problemas de uma alteração em um nó íntegro para o status Não pronto

  • Artigo

Este artigo discute um cenário no qual o status de um nó de cluster do AKS (Serviço de Kubernetes do Azure) é alterado para Não Pronto depois que o nó está em um estado íntegro por 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 íntegro (todos os serviços em execução) muda inesperadamente para Não Pronto. Para exibir o status de um nó, execute o seguinte comando kubectl describe :

kubectl describe nodes

Motivo

O kubelet parou de postar seu status Pronto .

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

# To check messages file,
cat /var/log/messages

# To check kubelet and containerd daemon logs,
journalctl -u kubelet > kubelet.log
journalctl -u containerd > containerd.log

Depois de executar esses comandos, examine as mensagens e os arquivos de log do daemon para obter mais informações sobre o erro.

Solução

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

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

  • Alterações no DNS (Sistema de Nomes de Domínio)
  • Alterações de regras de firewall, como porta, FQDNs (nomes de domínio totalmente qualificados) e assim por diante.
  • NSGs (grupos de segurança de rede) adicionados
  • Configurações de tabela de rotas aplicadas ou alteradas para o tráfego do AKS

Se houver alterações no nível da rede, faça as correções necessárias. Se você tiver acesso SSH (Secure Shell) direto ao nó, poderá usar o curl comando or telnet para verificar a conectividade com os requisitos de saída do AKS. Depois de corrigir os problemas, pare e reinicie os nós. Se os nós permanecerem em um estado íntegro após essas correções, você poderá ignorar com segurança as etapas restantes.

Etapa 2: Pare e reinicie os nós

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

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

Se o diagnóstico não descobrir nenhum problema subjacente e os nós retornarem ao status Pronto, você poderá ignorar com segurança as etapas restantes.

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

O diagnóstico do AKS descobriu algum problema de SNAT? Em caso afirmativo, execute algumas das seguintes ações, conforme apropriado:

  • Verifique se suas conexões permanecem ociosas por muito tempo e conte com o tempo limite de ociosidade 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 revisão de código ou 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 substanciar suas conclusões. Por exemplo, você pode usar a categoria Falha como uma métrica de Conexões SNAT.

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

  • Avalie se o esgotamento de porta SNAT deve ser mitigado com mais endereços IP de saída e mais portas de saída 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.

Para obter mais informações sobre como solucionar problemas de exaustão de porta SNAT, consulte Solucionar problemas de esgotamento de porta SNAT em nós do AKS.

Etapa 4: Corrigir problemas de desempenho de IOPS

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

  • Para aumentar o IOPS em conjuntos de dimensionamento de VM (máquina virtual), escolha um tamanho de disco maior que ofereça melhor desempenho de IOPS implantando um novo pool de nós. Não há suporte para o redimensionamento direto do VMSS. Para obter mais informações sobre como redimensionar pools de nós, consulte Redimensionar pools de nós no AKS (Serviço de Kubernetes do Azure).

  • Aumente o tamanho da SKU do nó para obter mais memória e capacidade de processamento da 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 de falta de 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 distribuição de topologia de pod.

Etapa 5: corrigir problemas de threading

Os componentes do Kubernetes, como kubelets e containerd runtimes , dependem muito de threads e geram novos threads regularmente. Se a alocação de novos threads não for bem-sucedida, essa falha poderá afetar a prontidão do serviço, da seguinte maneira:

  • O status do nó muda para Não Pronto, mas é reiniciado por um remediador e pode se recuperar.

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

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

    Os processos citados incluem containerd e possivelmente kubelet.

  • O status do nó muda 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. Essa quantidade é mais do que suficiente para a maioria das situações. Existem requisitos de aplicativos conhecidos para recursos de PID mais altos? Se não houver, 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 ofensor e execute a ação apropriada. Considere outras opções, como aumentar o tamanho da VM ou atualizar o AKS. Essas ações podem mitigar o problema temporariamente, mas não são uma garantia de que o problema não reaparecerá novamente.

Para monitorar a contagem de threads para cada grupo de controle (cgroup) e imprimir os oito principais cgroups, 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, consulte Limites e reservas de ID do processo.

O Kubernetes oferece dois métodos para gerenciar a exaustão de PIDs 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 cgroup de cada pod. Você também pode usar os --system-reserved parâmetros and --kube-reserved para configurar os limites do sistema e do kubelet, respectivamente.

  2. Configure a remoção baseada 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 AKS (Serviço de Kubernetes do Azure).

Mais informações