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?

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.

---