Questa pagina è stata tradotta dall'API Cloud Translation.

Node Problem Detector

Node Problem Detector è una libreria open source che monitora lo stato dei nodi e rileva i problemi comuni dei nodi, ad esempio problemi di runtime hardware, del kernel o del contenitore. In Google Distributed Cloud, viene eseguito come servizio systemd su ogni nodo.

A partire dalla versione 1.10.0 di Google Distributed Cloud, il rilevatore problemi nodo è abilitato per impostazione predefinita.

Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.

Quali problemi rileva?

Node Problem Detector può rilevare i seguenti tipi di problemi:

Problemi di runtime del contenitore, ad esempio demoni di runtime che non rispondono
Problemi hardware, ad esempio guasti della CPU, della memoria o del disco
Problemi del kernel, ad esempio condizioni di deadlock del kernel o file system danneggiati

Viene eseguito su un nodo e segnala i problemi all'API server Kubernetes come NodeCondition o come Event. Un NodeCondition è un problema che impedisce a un nodo di eseguire i pod, mentre un Event è un problema temporaneo che ha un effetto limitato sui pod, ma è tuttavia considerato abbastanza importante da essere segnalato.

La tabella seguente descrive i NodeConditions rilevati da Node Problem Detector e indica se possono essere riparati automaticamente o meno:

Condizione	Motivo	Riparazione auto supportata¹
`KernelDeadlock`	I processi del kernel sono bloccati in attesa che altri processi del kernel rilascino le risorse richieste.	No
`ReadonlyFilesystem`	Il cluster non è in grado di scrivere nel file system a causa di un problema, ad esempio perché il disco è pieno.	No
`FrequentKubeletRestart`	Kubelet si riavvia di frequente, il che impedisce al nodo di eseguire i pod in modo efficace.	No
`FrequentDockerRestart`	Il daemon Docker è stato riavviato più di 5 volte in 20 minuti.	No
`FrequentContainerdRestart`	Il runtime del container è stato riavviato più di 5 volte in 20 minuti.	No
`FrequentUnregisterNetDevice`	Il nodo presenta frequenti cancellazioni della registrazione dei dispositivi di rete.	No
`KubeletUnhealthy`	Il nodo non funziona correttamente o non risponde al piano di controllo.	No
`ContainerRuntimeUnhealthy`	Il runtime del contenitore non funziona correttamente, impedendo l'esecuzione o la pianificazione dei pod sul nodo.	No
`CorruptDockerOverlay2`	Esistono problemi o incoerenze del file system nella directory del driver di archiviazione overlay2 di Docker.	No
`OrphanContainers`²	Un pod specifico per un contenitore è stato eliminato, ma il contenitore corrispondente esiste ancora nel nodo.	No
`FailedCgroupRemoval`²	Alcuni gruppi di controllo sono in uno stato bloccato.	Sì

¹ Per le versioni 1.32 e successive, la possibilità di riparare automaticamente i problemi rilevati è supportata per determinate condizioni.

² Supportato per le versioni 1.32 e successive.

Ecco alcuni esempi di tipi di Events segnalati da 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.

Quali problemi ripara?

A partire dalla versione 1.32, quando il Rilevamento dei problemi del nodo rileva NodeConditions selezionato, può riparare automaticamente il problema corrispondente sul nodo. A partire dalla versione 1.32, NodeCondition supporta la riparazione automatica. FailedCgroupRemoval

Come visualizzare i problemi rilevati

Esegui il seguente comando kubectl describe per cercare NodeConditions e Events:

kubectl describe node NODE_NAME \
    --kubeconfig=KUBECONFIG

Sostituisci quanto segue:

NODE_NAME: il nome del nodo che stai controllando.
KUBECONFIG: il percorso del file kubeconfig del cluster.

Come attivare e disattivare il Rilevamento dei problemi del nodo

Per impostazione predefinita, Node Problem Detector è abilitato, ma può essere disattivato nella risorsa ConfigMapnode-problem-detector-config. A meno che non lo disattivi esplicitamente, il rilevatore problemi nodo monitora continuamente i nodi per rilevare condizioni specifiche che indicano problemi.

Per disattivare Node Problem Detector in un determinato cluster, svolgi i seguenti passaggi:

Modifica la risorsa ConfigMap node-problem-detector-config:
```
kubectl edit configmap node-problem-detector-config \
    --kubeconfig=KUBECONFIG \
    --namespace=CLUSTER_NAMESPACE
```
Sostituisci quanto segue:
- KUBECONFIG: il percorso del file kubeconfig del cluster.
- CLUSTER_NAMESPACE: lo spazio dei nomi del cluster in cui vuoi attivare Node Problem Detector.
Questo comando avvia automaticamente un editor di testo in cui puoi modificare la risorsa node-problem-detector-config.
Imposta data.enabled su false nella definizione della risorsa node-problem-detector-config.
```
apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: "2025-04-19T21:36:44Z"
  name: node-problem-detector-config
...
data:
  enabled: "false"
```
Inizialmente, il ConfigMap node-problem-detector-config non ha un campo data, quindi potrebbe essere necessario aggiungerlo.
Per aggiornare la risorsa, salva le modifiche e chiudi l'editor.

Per riattivare Node Problem Detector, esegui i passaggi precedenti, ma imposta data.enabled su true nella definizione della risorsa node-problem-detector-config.

Come attivare e disattivare la riparazione automatica

A partire dalla versione 1.32, il Rilevamento problemi nodo controlla la presenza di NodeConditions specifici e ripara automaticamente il problema corrispondente sul nodo. Per impostazione predefinita, la riparazione automatica è abilitata per NodeConditions supportati, ma può essere disattivata nella risorsa ConfigMap node-problem-detector-config.

Per disattivare il comportamento di riparazione automatica in un determinato cluster, segui questi passaggi:

Modifica la risorsa ConfigMap node-problem-detector-config:
```
kubectl edit configmap node-problem-detector-config \
    --kubeconfig=KUBECONFIG \
    --namespace=CLUSTER_NAMESPACE
```
Sostituisci quanto segue:
- KUBECONFIG: il percorso del file kubeconfig del cluster.
- CLUSTER_NAMESPACE: lo spazio dei nomi del cluster in cui vuoi attivare Node Problem Detector.
Questo comando avvia automaticamente un editor di testo in cui puoi modificare la risorsa node-problem-detector-config.
Imposta data.check-only su true nella definizione della risorsa 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"
```
Inizialmente, il ConfigMap node-problem-detector-config non ha un campo data, quindi potrebbe essere necessario aggiungerlo. L'impostazione di check-only su "true" disattiva la riparazione automatica per tutte le condizioni supportate.
Per aggiornare la risorsa, salva le modifiche e chiudi l'editor.

Per riattivare la riparazione automatica per tutti i NodeConditions che la supportano, imposta data.check-only su "false" nel ConfigMap node-problem-detector-config.

Come interrompere e riavviare Node Problem Detector

Node Problem Detector viene eseguito come servizio systemd su ogni nodo. Per gestire Node Problem Detector per un determinato nodo, utilizza SSH per accedere al nodo ed esegui i seguenti comandi systemctl.

Per disattivare Node Problem Detector, esegui il seguente comando:
```
systemctl stop node-problem-detector
```
Per riavviare Node Problem Detector, esegui il seguente comando:
```
systemctl restart node-problem-detector
```
Per verificare se Node Problem Detector è in esecuzione su un determinato nodo, esegui il seguente comando:
```
systemctl is-active node-problem-detector
```

Funzionalità non supportate

Google Distributed Cloud non supporta le seguenti personalizzazioni di Node Problem Detector:

Esportazione dei report di Node Problem Detector in altri sistemi di monitoraggio, come Stackdriver o Prometheus.
Personalizzare i NodeConditions o i Events da cercare.
Esecuzione di script di monitoraggio definiti dall'utente.

Passaggi successivi