Os clusters do Anthos em bare metal agora são o Google Distributed Cloud (somente software) em bare metal. Para mais informações, consulte a visão geral do produto.

Esta página foi traduzida pela API Cloud Translation.

Detector de problemas de nós

O Node Problem Detector é uma biblioteca de código aberto que monitora a integridade dos nós e detecta problemas comuns, como hardware, kernel ou problemas de tempo de execução de contêineres. No Google Distributed Cloud, ele é executado como um serviço systemd em cada nó.

A partir da versão 1.10.0 do Google Distributed Cloud, o Detector de problemas do nó é ativado por padrão.

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care. Consulte também Receber suporte para mais informações sobre recursos de suporte, incluindo:

Requisitos para abrir um caso de suporte.
Ferramentas para ajudar na solução de problemas, como configuração do ambiente, registros e métricas.
Componentes compatíveis.

Quais problemas ele detecta?

O detector de problemas do nó pode detectar os seguintes tipos de problemas:

Problemas no ambiente de execução do contêiner, como daemons do ambiente de execução sem resposta
Problemas de hardware, como falhas de CPU, memória ou disco
Problemas de kernel, como condições de impasse do kernel ou sistemas de arquivos corrompidos

Ele é executado em um nó e informa problemas no servidor da API Kubernetes como um NodeCondition ou como um Event. Um NodeCondition é um problema que impede o nó de executar pods, enquanto um Event é um problema temporário que tem efeito limitado nos pods, mas é considerado importante o suficiente para ser relatado.

A tabela a seguir descreve os NodeConditions descobertos pelo detector de problemas do nó e se eles podem ser corrigidos automaticamente:

Condição	Motivo	Reparo automático disponível¹
`KernelDeadlock`	Os processos do kernel ficam presos aguardando que outros processos do kernel liberem os recursos necessários.	Não
`ReadonlyFilesystem`	O cluster não consegue gravar no sistema de arquivos devido a um problema, como disco cheio.	Não
`FrequentKubeletRestart`	O kubelet está sendo reiniciado com frequência, o que impede que o nó execute pods de maneira eficaz.	Não
`FrequentDockerRestart`	O daemon do Docker foi reiniciado mais de cinco vezes em 20 minutos.	Não
`FrequentContainerdRestart`	O ambiente de execução do contêiner foi reiniciado mais de cinco vezes em 20 minutos.	Não
`FrequentUnregisterNetDevice`	O nó está passando por um processo frequente de cancelamento do registro de dispositivos de rede.	Não
`KubeletUnhealthy`	O nó não está funcionando corretamente ou não está respondendo ao plano de controle.	Não
`ContainerRuntimeUnhealthy`	O ambiente de execução de contêineres não está funcionando corretamente, impedindo que os pods sejam executados ou programados no nó.	Não
`CorruptDockerOverlay2`	Há problemas ou inconsistências no sistema de arquivos no diretório do driver de armazenamento overlay2 do Docker.	Não
`OrphanContainers`²	Um pod específico de um contêiner foi excluído, mas o contêiner correspondente ainda existe no nó.	Não
`FailedCgroupRemoval`²	Alguns cgroups estão em estado congelado.	Sim

¹ Nas versões 1.32 e mais recentes, a capacidade de corrigir automaticamente problemas detectados é compatível com algumas condições.

² Compatível com as versões 1.32 e mais recentes.

Alguns exemplos dos tipos de Events relatados pelo Node Problem Detector são:

Warning TaskHung node/vm-worker-1-user-a12fabb4a99cb92-ddfce8832fd90f6f.lab.anthos kernel: task docker:7 blocked for more than 300 seconds.
Warning KernelOops node/vm-worker-1-user-a12fabb4a99cb92-ddfce8832fd90f6f.lab.anthos kernel: BUG: unable to handle kernel NULL pointer dereference at 00x0.

Quais problemas ele corrige?

A partir da versão 1.32, quando o detector de problemas do nó descobre NodeConditions selecionados, ele pode corrigir automaticamente o problema correspondente no nó. A partir da versão 1.32, o único NodeCondition que aceita o reparo automático é FailedCgroupRemoval.

Como ver os problemas detectados

Execute o comando kubectl describe a seguir para procurar NodeConditions e Events:

kubectl describe node NODE_NAME \
    --kubeconfig=KUBECONFIG

Substitua:

NODE_NAME: o nome do nó que você está verificando.
KUBECONFIG: o caminho do arquivo kubeconfig do cluster.

Como ativar e desativar o detector de problemas do nó

Por padrão, o detector de problemas de nós fica ativado, mas pode ser desativado no recurso ConfigMap node-problem-detector-config. A menos que você desative explicitamente, o Detector de problemas de nós monitora continuamente os nós em busca de condições específicas que indicam problemas para o nó.

Para desativar o Detector de problemas do nó em um determinado cluster, siga estas etapas:

Edite o recurso ConfigMap node-problem-detector-config:
```
kubectl edit configmap node-problem-detector-config \
    --kubeconfig=KUBECONFIG \
    --namespace=CLUSTER_NAMESPACE
```
Substitua:
- KUBECONFIG: o caminho do arquivo kubeconfig do cluster.
- CLUSTER_NAMESPACE: o namespace do cluster em que você quer ativar o detector de problemas do nó.
Esse comando inicia automaticamente um editor de texto para editar o recurso node-problem-detector-config.
Defina data.enabled como false na definição do recurso node-problem-detector-config.
```
apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: "2025-04-19T21:36:44Z"
  name: node-problem-detector-config
...
data:
  enabled: "false"
```
Inicialmente, o ConfigMap node-problem-detector-config não tem um campo data, então talvez seja necessário adicioná-lo.
Para atualizar o recurso, salve as mudanças e feche o editor.

Para reativar o detector de problemas do nó, siga as etapas anteriores, mas defina data.enabled como true na definição do recurso node-problem-detector-config.

Como ativar e desativar o reparo automático

A partir da versão 1.32, o Detector de problemas de nós verifica NodeConditions específicos e corrige automaticamente o problema correspondente no nó. Por padrão, o reparo automático é ativado para NodeConditions compatíveis, mas pode ser desativado no recurso ConfigMap node-problem-detector-config.

Para desativar o comportamento de reparo automático em um determinado cluster, siga estas etapas:

Edite o recurso ConfigMap node-problem-detector-config:
```
kubectl edit configmap node-problem-detector-config \
    --kubeconfig=KUBECONFIG \
    --namespace=CLUSTER_NAMESPACE
```
Substitua:
- KUBECONFIG: o caminho do arquivo kubeconfig do cluster.
- CLUSTER_NAMESPACE: o namespace do cluster em que você quer ativar o detector de problemas do nó.
Esse comando inicia automaticamente um editor de texto para editar o recurso node-problem-detector-config.
Defina data.check-only como true na definição do recurso node-problem-detector-config.
```
apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: "2025-04-19T21:36:44Z"
  name: node-problem-detector-config
...
data:
  enabled: "true"
  check-only: "true"
```
Inicialmente, o ConfigMap node-problem-detector-config não tem um campo data, então talvez seja necessário adicioná-lo. Definir check-only como "true" desativa o reparo automático para todas as condições compatíveis.
Para atualizar o recurso, salve as mudanças e feche o editor.

Para reativar o reparo automático em todos os NodeConditions que oferecem suporte a ele, defina data.check-only como "false" no ConfigMap node-problem-detector-config.

Como parar e reiniciar o detector de problemas do nó

O detector de problemas do nó é executado como um serviço systemd em cada nó. Para gerenciar o detector de problemas de um nó específico, use o SSH para acessar o nó e execute os seguintes comandos systemctl.

Para desativar o Detector de problemas do nó, execute o seguinte comando:
```
systemctl stop node-problem-detector
```
Para reiniciar o detector de problemas do nó, execute o seguinte comando:
```
systemctl restart node-problem-detector
```
Para verificar se o Detector de problemas de nós está sendo executado em um nó específico, execute o seguinte comando:
```
systemctl is-active node-problem-detector
```

Recursos não suportados

O Google Distributed Cloud não aceita as seguintes personalizações do detector de problemas do nó:

Exportar relatórios do Detector de problemas de nós para outros sistemas de monitoramento, como Stackdriver ou Prometheus.
Personalizando qual NodeConditions ou Events procurar.
Executar scripts de monitoramento definidos pelo usuário.

A seguir