Como faço para solucionar problemas de status do meu nó de processamento do Amazon EKS que está definido como NotReady devido a problemas com o PLEG?

Data da última atualização: 07/02/2023

O status dos nós de processamento do Amazon Elastic Kubernetes Service (Amazon EKS) são definidos como NotReady ou Unknown porque a integridade do Pod Lifecycle Event Generator (PLEG, Gerador de Eventos de Ciclo de Vida do Pod) está comprometida.

Resolução

Quando os nós de processamento do cluster do Amazon EKS são definidos como NotReady ou Unknown, as workloads programadas nesse nó são interrompidas. Para solucionar esse problema, faça o seguinte:

Obtenha informações sobre o nó de processamento executando o seguinte comando:

$ kubectl describe node node-name

Na saída, verifique a seção Condições para encontrar a causa do problema.

Exemplo:

KubeletNotReady  PLEG is not healthy: pleg was last seen active xx

Os motivos mais comuns para o comprometimento da integridade do PLEG são os seguintes:

  • O kubelet não pode se comunicar com o daemon do Docker porque o daemon está ocupado ou inoperante. Por exemplo, o daemon do Docker no nó de processamento do EKS pode estar danificado.
  • Um problema de Out of Memory (OOM, falta de memória) ou de utilização da CPU no nível da instância pode ter causado a inoperabilidade do PLEG.
  • Se o nó de processamento tiver um grande número de pods, o kubelet e o daemon do Docker poderão ter workloads maiores, causando erros relacionados ao PLEG. O exame com frequência da disponibilidade e prontidão do nó também pode aumentar as workloads.

Verificar os logs do kubelet

Você pode verificar os logs do kubelet na instância para identificar por que o PLEG não está íntegro.

1.    Use o SSH para se conectar à instância e executar o seguinte comando:

$ journalctl -u kubelet > kubelet.log

Se estiver usando uma AMI otimizada para o Amazon EKS e o SSH não estiver habilitado, é possível conectar-se usando o SSM. Para obter mais informações, consulte Conectar-se à instância do Linux usando o Gerenciador de sessões.

2.    Verifique os eventos relacionados ao PLEG publicados pelo kubelet nestes logs:

Exemplo:

28317 kubelet.go:1873] "Skipping pod synchronization" err="PLEG is not healthy: pleg was last seen active 4h5m43.659028227s ago; threshold is 3m0s"
28317 kubelet.go:1873] "Skipping pod synchronization" err="PLEG is not healthy: pleg was last seen active 4h5m48.659213288s ago; threshold is 3m0s"

3.    Confira os logs do kubelet para verificar se há algum pod que esteja falhando nas checagens de prontidão e disponibilidade. Essas mensagens de log são semelhantes às seguintes:

"Probe failed" probeType="Liveness" pod="nginx/bus" podUID=2527afb7-b32c-4c84-97e2-246eb48c97a9 containerName="nginx" probeResult=failure output="Get \"http://192.168.154.18:15020/app-health/livez\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)"

Use esses logs para identificar os pods que estão falhando. Para os pods identificados, verifique e certifique-se de que as checagens de integridade estão configuradas corretamente.

Monitore o uso de recursos do nó de processamento

Verifique se há algum problema no nível da instância, como escassez de recursos devido a problemas de OOM ou alta utilização da CPU.

Monitore a métrica de utilização da CPU para o nó de processamento subjacente do Amazon Elastic Compute Cloud (Amazon EC2). Confira essa métrica para verificar se há picos repentinos ou se a utilização da CPU atinge 100%.

O kubelet notifica quando o nó está sob pressão ao atingir os limites de remoção rígidos ou flexíveis, independentemente dos períodos de carência configurados. Você pode verificar a condição do nó executando o seguinte comando:

$ kubectl describe node <node_name>

Verifique se a condição do nó está indicada como MemoryPressure na saída. Nesses casos, a instância pode paralizar devido à indisponibilidade de recursos. Isso pode fazer com que o processo deixe de responder.

Para atenuar problemas causados pela escassez de recursos, é uma melhor prática definir limites de utilização de CPU e de memória para os pods.

Quando você especifica um limite de recursos para o contêiner, o kubelet aplica esses limites. O uso do contêiner em execução não pode exceder esses limites. Isso evita que o pod ocupe mais memória do que o necessário, evitando problemas de OOM. Para obter mais informações, consulte Gerenciamento de recursos em pods e contêineres no site do Kubernetes.

Além disso, considere usar o Container Insights para coletar, agregar e resumir métricas e logs de suas aplicações e microsserviços em contêineres. Para obter mais informações, consulte Métricas do Container Insights do Amazon EKS e do Kubernetes. Você pode usar os comandos node_cpu_utilization e node_memory_utilization para monitorar a utilização de recursos no nível do nó. Também é possível definir alarmes para receber uma notificação quando um determinado limite for atingido.

Monitorar o desempenho do volume do dispositivo raiz do Amazon EBS

O PLEG pode não estar íntegro devido a problemas de disco no volume do Amazon Elastic Block Store (Amazon EBS). Nesse caso, os logs do kubelet são semelhantes aos seguintes:

fs: disk usage and inodes count on following dirs took 1.262610491s: [/var/lib/docker/overlay2/709e904d843733d746e5134e55e3c6553db4c0f5297d5e3c3a86c206bcb6b172/diff /var/lib/docker/containers/158725d2d97578713034c5f5c16291a068349b7e989b417324c142bb584f79ad]; will not log again for this container unless duration exceeds 2s

Isso acontece quando as aplicações que estão usando os pods na instância realizam operações intensivas de E/S no disco.

É possível monitorar a utilização e o throughput de Input/output operations per second (IOPS, operações de entrada e saída por segundo) do volume do Amazon EBS usando as Métricas do Amazon CloudWatch para o Amazon EBS.

Use as seguintes métricas do CloudWatch para monitorar o throughput e as IOPS de um volume do Amazon EBS:

  • VolumeReadOps
  • VolumeWriteOps
  • VolumeReadBytes

Por exemplo, é possível calcular a média de IOPS em operações por segundo usando a seguinte fórmula:

((VolumeReadOps) + (VolumeWriteOps))/(Período)

É possível calcular o throughput médio em bytes/s usando a seguinte fórmula:

((VolumeReadBytes) + (VolumeWriteBytes))/(Período)

Para mais informações, consulte How can I use CloudWatch metrics to calculate the average throughput and average number of IOPS my EBS volume is providing? (Como posso usar as métricas do CloudWatch para calcular o throughput médio e o número médio de IOPS que meu volume do EBS está fornecendo?)

Para resolver esse problema, considere aumentar o espaço de armazenamento do disco ou alterar o tipo de volume do EBS para obter um melhor throughput de E/S.


Este artigo ajudou?


Precisa de ajuda com faturamento ou suporte técnico?