Esta página foi traduzida pela API Cloud Translation.

Node Problem Detector

O Node Problem Detector é uma biblioteca de código aberto que monitoriza o estado de funcionamento dos nós e deteta problemas comuns dos nós, como problemas de hardware, kernel ou tempo de execução do contentor. No Google Distributed Cloud, é executado como um serviço systemd em cada nó.

A partir da versão 1.10.0 do Google Distributed Cloud, o Node Problem Detector está ativado por predefinição.

Se precisar de assistência adicional, contacte o apoio ao cliente do Google Cloud. Também pode consultar o artigo Receber apoio técnico para mais informações sobre recursos de apoio técnico, incluindo o seguinte:

Requisitos para abrir um registo de apoio ao cliente.
Ferramentas para ajudar a resolver problemas, como a configuração do ambiente, os registos e as métricas.
Componentes suportados.

Que problemas deteta?

O Node Problem Detector pode detetar os seguintes tipos de problemas:

Problemas de tempo de execução do contentor, como daemons de tempo de execução que não respondem
Problemas de hardware, como falhas da CPU, da memória ou do disco
Problemas do kernel, como condições de impasse do kernel ou sistemas de ficheiros danificados

É executado num nó e comunica problemas ao servidor da API Kubernetes como um NodeCondition ou um Event. Um NodeCondition é um problema que impede um nó de executar pods, enquanto um Event é um problema temporário que tem um efeito limitado nos pods, mas é, ainda assim, considerado suficientemente importante para ser comunicado.

A tabela seguinte descreve os NodeConditions descobertos pelo Node Problem Detector e se podem ou não ser reparados automaticamente:

Condição	Motivo	Reparação de automóveis suportada¹
`KernelDeadlock`	Os processos do kernel estão bloqueados à espera que outros processos do kernel libertem os recursos necessários.	Não
`ReadonlyFilesystem`	O cluster não consegue escrever no sistema de ficheiros devido a um problema, como o disco estar cheio.	Não
`FrequentKubeletRestart`	O kubelet está a ser reiniciado com frequência, o que impede o nó de executar pods de forma eficaz.	Não
`FrequentDockerRestart`	O daemon do Docker foi reiniciado mais de 5 vezes em 20 minutos.	Não
`FrequentContainerdRestart`	O tempo de execução do contentor foi reiniciado mais de 5 vezes em 20 minutos.	Não
`FrequentUnregisterNetDevice`	O nó está a registar com frequência a anulação do registo de dispositivos de rede.	Não
`KubeletUnhealthy`	O nó não está a funcionar corretamente ou não está a responder ao plano de controlo.	Não
`ContainerRuntimeUnhealthy`	O tempo de execução do contentor não está a funcionar corretamente, o que impede a execução ou o agendamento de pods no nó.	Não
`CorruptDockerOverlay2`	Existem problemas ou inconsistências do sistema de ficheiros no diretório do controlador de armazenamento overlay2 do Docker.	Não
`OrphanContainers`²	Um pod específico de um contentor foi eliminado, mas o contentor correspondente continua a existir no nó.	Não
`FailedCgroupRemoval`²	Alguns cgroups estão num estado congelado.	Sim

¹ Para as versões 1.32 e posteriores, a capacidade de reparar automaticamente os problemas detetados é suportada para condições selecionadas.

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

Seguem-se alguns exemplos dos tipos de Events comunicados pelo Node Problem Detector:

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.

Que problemas repara?

A partir da versão 1.32, quando o Node Problem Detector descobre determinados NodeConditions, pode reparar automaticamente o problema correspondente no nó. A partir da versão 1.32, o único NodeCondition que suporta a reparação automática é o FailedCgroupRemoval.

Como ver problemas detetados

Execute o seguinte comando kubectl describe para procurar NodeConditions e Events:

kubectl describe node NODE_NAME \
    --kubeconfig=KUBECONFIG

Substitua o seguinte:

NODE_NAME: o nome do nó que está a verificar.
KUBECONFIG: o caminho do ficheiro kubeconfig do cluster.

Como ativar e desativar o Node Problem Detector

Por predefinição, o Node Problem Detector está ativado, mas pode ser desativado no recurso node-problem-detector-configConfigMap. A menos que a desative explicitamente, o Node Problem Detector monitoriza continuamente os nós para verificar condições específicas que indicam problemas para o nó.

Para desativar o Node Problem Detector num determinado cluster, siga estes passos:

Edite o recurso node-problem-detector-config ConfigMap:
```
kubectl edit configmap node-problem-detector-config \
    --kubeconfig=KUBECONFIG \
    --namespace=CLUSTER_NAMESPACE
```
Substitua o seguinte:
- KUBECONFIG: o caminho do ficheiro kubeconfig do cluster.
- CLUSTER_NAMESPACE: o espaço de nomes do cluster no qual quer ativar o Node Problem Detector.
Este comando inicia automaticamente um editor de texto no qual pode 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 node-problem-detector-config ConfigMap não tem um campo data, pelo que pode ter de o adicionar.
Para atualizar o recurso, guarde as alterações e feche o editor.

Para reativar o Node Problem Detector, execute os passos anteriores, mas defina data.enabled como true na definição do recurso node-problem-detector-config.

Como ativar e desativar a reparação automática

A partir da versão 1.32, o Node Problem Detector verifica NodeConditions específicos e repara automaticamente o problema correspondente no nó. Por predefinição, a reparação automática está ativada para os NodeConditions suportados, mas pode ser desativada no recurso node-problem-detector-config ConfigMap.

Para desativar o comportamento de reparação automática num determinado cluster, siga os seguintes passos:

Edite o recurso node-problem-detector-config ConfigMap:
```
kubectl edit configmap node-problem-detector-config \
    --kubeconfig=KUBECONFIG \
    --namespace=CLUSTER_NAMESPACE
```
Substitua o seguinte:
- KUBECONFIG: o caminho do ficheiro kubeconfig do cluster.
- CLUSTER_NAMESPACE: o espaço de nomes do cluster no qual quer ativar o Node Problem Detector.
Este comando inicia automaticamente um editor de texto no qual pode 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 node-problem-detector-config ConfigMap não tem um campo data, pelo que pode ter de o adicionar. A definição de check-only como "true" desativa a reparação automática para todas as condições suportadas.
Para atualizar o recurso, guarde as alterações e feche o editor.

Para reativar a reparação automática para todos os NodeConditions que a suportam, defina data.check-only como "false" no node-problem-detector-config ConfigMap.

Como parar e reiniciar o Node Problem Detector

O Node Problem Detector é executado como um systemd serviço em cada nó. Para gerir o Node Problem Detector para um determinado nó, use o SSH para aceder ao nó e execute os seguintes comandos systemctl.

Para desativar o Node Problem Detector, execute o seguinte comando:
```
systemctl stop node-problem-detector
```
Para reiniciar o Node Problem Detector, execute o seguinte comando:
```
systemctl restart node-problem-detector
```
Para verificar se o Node Problem Detector está a ser executado num nó específico, execute o seguinte comando:
```
systemctl is-active node-problem-detector
```

Funcionalidades não suportadas

O Google Distributed Cloud não suporta as seguintes personalizações do Node Problem Detector:

Exportar relatórios do Node Problem Detector para outros sistemas de monitorização, como o Stackdriver ou o Prometheus.
Personalizar o NodeConditions ou o Events a procurar.
Execução de scripts de monitorização definidos pelo utilizador.

O que se segue?

Requisitos para abrir um registo de apoio ao cliente.
Ferramentas para ajudar a resolver problemas, como a configuração do ambiente, os registos e as métricas.
Componentes suportados.