Antes de Iniciar

Antes de utilizar os serviços de observabilidade para depurar seu cluster, certifique-se de que os seguintes requisitos estejam atendidos.

• Seu cluster está conectado a uma instância do IBM Cloud Monitoring. Para conectar seu cluster, consulte “Ativando métricas para o Red Hat OpenShift on IBM Cloud ”.
• Seu cluster está conectado a uma instância do IBM Cloud Logs. Para conectar seu cluster, consulte “Ativando o registro de logs ”.
• Você possui, no mínimo, acesso como Visualizador às instâncias dos serviços IBM Cloud Monitoring e IBM Cloud Logs na sua conta.

Verifique o uso de recursos do nó de trabalho com IBM Cloud Monitoring

Quando os nós de trabalho entram no estado “ Critical ” ou “ NotReady ”, o uso elevado da CPU ou da memória costuma ser a causa. Use os painéis pré-configurados do IBM Cloud Monitoring para identificar rapidamente a sobrecarga nos recursos.

1. Abra o painel do IBM Cloud Monitoring do seu cluster.

   1. No console do IBM Cloud, acesse a página de recursos do seu cluster e clique no cluster em questão.
   2. Na seção “Integrações ”, localize a opção “Monitoramento ” e clique em “Iniciar ”. A interface do usuário do IBM Cloud Monitoring é aberta em uma nova janela.

2. Acesse o Kubernetes > painel pré-configurado “Nós” para visualizar o uso de CPU e memória por nó.

   • Procure os nós em que a % de uso da CPU ou a % de uso da memória excedam 80%. Os nós que atingirem ou ultrapassarem esse limite correm o risco de ficar sobrecarregados e podem começar a apresentar falhas na programação de novos pods.
   • Procure nós nos quais o uso da CPU ou da memória apresente um pico repentino ou tenha permanecido consistentemente elevado na última hora ou no último dia. Isso pode ajudar você a determinar se o problema é momentâneo ou contínuo.

3. Para analisar um nó específico, clique no nome do nó no painel para filtrar todos os gráficos de acordo com esse nó. Verifique as seguintes métricas:

   • % de uso da CPU — um valor constante acima de 90% indica saturação da CPU.
   • % de uso de memória — um valor consistentemente acima de 85% aumenta o risco de ocorrência de eventos de falta de memória (OOM).
   • Bytes de entrada/saída da rede — um pico inesperado no tráfego pode indicar uma carga de trabalho descontrolada ou um ataque à rede.

4. Para verificar quais pods estão consumindo mais recursos em um nó, acesse o Kubernetes > painel “Pods” e filtre pelo nó afetado. Anote os nomes de todos os pods que apresentarem uso consistentemente elevado de CPU ou memória, pois esses são prováveis candidatos a causar a instabilidade do nó de trabalho.

Verifique o estado dos pods e as contagens de reinicializações com IBM Cloud Monitoring

Pods que entram em loop de falhas ou reiniciam com frequência são um sinal comum de problemas no nível do aplicativo, como encerramentos por falta de memória (OOM) ou testes de prontidão mal configurados. Use IBM Cloud Monitoring para identificar esses pods sem precisar executar oc get pods repetidamente.

1. Na interface do usuário do IBM Cloud Monitoring, acesse o Kubernetes > painel pré-configurado “Pods ”.

2. Analise o painel “Reinicializações de contêineres ”. Procure por pods que apresentem uma contagem de reinicializações maior que zero nos últimos 15 minutos ou que apresentem um aumento rápido ao longo de um período mais extenso.

   • Uma contagem de reinicializações que aumenta repetidamente indica um ciclo de falhas. Anote o nome do pod e o namespace para utilizá-los nas etapas de investigação dos logs a seguir.
   • Uma contagem de reinicializações igual a zero, mas com o status “Pendente” ou “Desconhecido”, indica um problema de agendamento ou de conectividade do nó, e não uma falha do aplicativo.

3. Para configurar um alerta para futuros eventos de reinicialização do pod, clique no ícone “Alertas” na interface do usuário do IBM Cloud Monitoring e crie um alerta de métrica para a métrica kubernetes.pod.restart.count. Defina o limite para que o alerta seja acionado quando a contagem ultrapassar duas reinicializações em cinco minutos para qualquer pod. Isso oferece um alerta antecipado antes que um ciclo de falhas passe a causar perturbações. Para obter mais informações sobre como configurar alertas, consulte “Configurando alertas d IBM Cloud® Monitoring ”

Analise os logs dos contêineres com IBM Cloud Logs

Quando um pod é reiniciado ou um nó apresenta problemas, é essencial analisar os logs dos contêineres para entender a causa raiz. O IBM Cloud Logs mantém um histórico de dados de log que não fica disponível no oc logs após o reinício de um contêiner.

1. Abra o painel do IBM Cloud Logs.

   1. No console do IBM Cloud, acesse a página de recursos do seu cluster e clique no cluster em questão.
   2. Na seção “Integrações ”, localize a opção “Registro ” e clique em “Iniciar ”. A interface do usuário do IBM Cloud Logs é aberta em uma nova janela.

2. Defina o intervalo de tempo de forma a abranger o período em que o problema ocorreu. Se o problema persistir, defina o intervalo para a última hora. Se você estiver investigando um evento passado, defina os horários específicos de início e término para refinar os resultados.

3. Procure o pod ou o namespace afetado. Use a barra de pesquisa na parte superior da interface do usuário para filtrar os registros. Por exemplo, para exibir os logs de todos os pods no namespace default, digite a seguinte consulta:

   kubernetes.namespace_name:"default"
   

   Para filtrar os resultados por um pod específico pelo nome, use:

   kubernetes.pod_name:"MY_POD_NAME"
   

4. Verifique as linhas de log em busca de entradas relacionadas a erros. Procure por qualquer um dos seguintes padrões que indiquem modos comuns de falha:

   • OOMKilled ou out of memory — o contêiner ultrapassou seu limite de memória e foi encerrado pelo kernel.
   • CrashLoopBackOff — o contêiner está reiniciando repetidamente, muitas vezes devido a um erro do aplicativo durante a inicialização.
   • failed to pull image ou ImagePullBackOff — o nó não consegue baixar a imagem do contêiner do registro.
   • Connection refused ou context deadline exceeded — o aplicativo não consegue acessar um serviço dependente ou o servidor da API Kubernetes.

5. Se você encontrar uma entrada de log relacionada a OOM, anote o carimbo de data e hora e verifique o IBM Cloud Monitoring Kubernetes > para o mesmo intervalo de tempo, a fim de confirmar se o uso de memória do pod atingiu seu limite imediatamente antes da reinicialização.

Confira os eventos d Kubernetes a em IBM Cloud Logs

Kubernetes Os eventos registram atividades importantes do cluster, como falhas no agendamento de pods, condições dos nós e erros de montagem de volumes. O IBM Cloud Logs coleta esses eventos automaticamente e permite pesquisá-los e filtrá-los historicamente — ao contrário do oc get events, que mostra apenas os eventos recentes da sessão atual.

1. Na interface do usuário do IBM Cloud Logs, use a seguinte consulta para exibir todos os eventos de aviso relacionados ao Kubernetes em todo o cluster:

   kubernetes.event.type:"Warning"
   

2. Para filtrar eventos em um nó de trabalho específico, adicione o nome do nó à consulta. Substitua NODE_NAME pelo nome do nó afetado:

   kubernetes.event.type:"Warning" AND kubernetes.event.involvedObject.name:"NODE_NAME"
   

3. Verifique o campo “Motivo” nas entradas do log de eventos. Os motivos a seguir são os mais relevantes para a depuração de problemas em nós de trabalho e cargas de trabalho:

NodeNotReady

O nó está relatando uma condição de “ NotReady ”. Esse evento geralmente antecede ou acompanha a entrada de um nó de trabalho no estado “ Critical ”.

OOMKilling

O kernel encerrou um processo no nó devido à falta de memória.

FailedScheduling

O agendador não conseguiu alocar um pod em nenhum nó disponível. O campo de mensagem geralmente explica o motivo, como CPU insuficiente, memória insuficiente ou incompatibilidade do seletor de nó.

BackOff

Um contêiner está em um ciclo de falhas. O evento é gerado sempre que o kubelet entra em modo de espera antes de reiniciar o contêiner.

FailedMount ou FailedAttachVolume

Não foi possível montar ou associar um volume persistente a um pod, o que impede que o pod seja iniciado.

1. Para qualquer evento que pareça relevante, anote os valores de “ involvedObject.name ” e “ involvedObject.namespace ” e utilize-os para correlacionar com os dados de log e métricas coletados nas seções anteriores.

Próximas etapas

• Se você identificou um nó de trabalho com falta de recursos, considere recarregá-lo ou substituí-lo, ou ajustar as solicitações e os limites de recursos dos pods em execução nesse nó.
• Se os pods estiverem entrando em um ciclo de travamento devido a encerramentos por falta de memória (OOM), aumente os limites de memória dos contêineres afetados ou transfira as cargas de trabalho que exigem muito da memória para um pool de workers com nós maiores.
• Se os logs indicarem falhas no download de imagens, verifique seus segredos de download de imagens e confirme se o nó de trabalho consegue acessar o registro de contêineres.
• Para problemas que não possam ser resolvidos com as informações reunidas aqui, consulte a seção “Como coletar dados para um caso de suporte” para reunir as informações necessárias para abrir um ticket de suporte.

Links relacionados

• Monitorando o funcionamento do cluster
• Introdução ao IBM Cloud Monitoring
• Introdução ao IBM Cloud Logs
• Solução de problemas em nós de trabalho no estado “ Critical ” ou “ NotReady ”
• Configurando alertas do IBM Cloud® Monitoring