Risoluzione dei problemi dei nodi di lavoro nello stato `Critical` o `NotReady`

I nodi di lavoro del cluster passano allo stato Critical o NotReady quando smettono di comunicare con il master cluster. Quando ciò si verifica, i nodi worker vengono contrassegnati come Critical nell'interfaccia IBM Cloud utente o quando si eseguono ibmcloud oc worker i comandi e come NotReady nelle Red Hat OpenShift dashboard e quando si esegue oc get nodes. Ci sono diversi motivi per cui la comunicazione si arresta tra i nodi di lavoro e il master cluster. Attieniti alla seguente procedura per risolvere i problemi dei nodi di lavoro in questi stati.

Controlla il pannello di controllo IBM Cloud dello stato e dell'integrità per eventuali notifiche o aggiornamenti di manutenzione che potrebbero essere rilevanti per i tuoi nodi di lavoro. Queste notifiche o aggiornamenti potrebbero aiutare a stabilire la causa degli errori del nodo di lavoro.

Controllare le cause comuni degli errori del nodo di lavoro

Ci sono diversi motivi per cui la comunicazione si arresta tra i nodi di lavoro e il master cluster. Verificare se i seguenti problemi comuni stanno causando l'interruzione.

L'operatore è stato eliminato, ricaricato, aggiornato, sostituito o riavviato: I nodi di lavoro potrebbero temporaneamente mostrare uno stato Critical o NotReady quando vengono eliminati, ricaricati, aggiornati o sostituiti. Se una di queste azioni è stata avviata sul tuo nodo di lavoro, sia manualmente che come parte di una configurazione di automazione come il cluster autoscaler, attendi che le azioni siano completate. Quindi, controlla nuovamente lo stato dei tuoi nodi di lavoro. Se i nodi di lavoro rimangono nello stato Critical o NotReady, ricarica o sostituisci i nodi di lavoro interessati.; Se un nodo di lavoro è stato ricaricato o sostituito e inizialmente funziona correttamente, ma dopo qualche tempo torna allo stato Critical o NotReady, è probabile che alcuni carichi di lavoro o componenti sul nodo di lavoro causino il problema. Vedi Debug dei nodi di lavoro per isolare il carico di lavoro del problema.

Un nodo di lavoro potrebbe trovarsi in uno stato Critical o NotReady se è stato riavviato senza prima essere cordone e svuotato. In questo caso, l'attesa del completamento del riavvio non risolve il problema. Ricarica o sostituisci il nodo di lavoro interessato. Se il problema persiste, continuare con la procedura di risoluzione dei problemi.

Il nodo di lavoro è stato involontariamente spento: Cluster classici Nell'IBM Cloud, i nodi di lavoro sull'infrastruttura classica sono classificati come risorse di calcolo o macchine virtuali. A volte un utente potrebbe non rendersi conto che queste risorse funzionano come nodi di lavoro del cluster e potrebbero involontariamente disattivare i nodi di lavoro. I nodi di lavoro disattivati potrebbero essere visualizzati nello stato Critical o NotReady. Assicurati che i nodi di lavoro interessati non vengano spenti.

Procedura di risoluzione dei problemi

Se i tuoi nodi di lavoro rimangono nello stato Critical o NotReady dopo aver affrontato le cause comuni, continua con la seguente procedura di risoluzione dei problemi.

Se un nodo di lavoro che hai precedentemente ricaricato o sostituito è nello stato deploy_failed o provision_failed quando esegui ibmcloud ks workers, attieniti alla procedura nella sezione Tutti i nodi di lavoro in un cluster sono interessati, anche se non tutti i nodi sono interessati. Se viene indicato uno stato differente, vedi Stati del nodo di lavoro per i passi per la risoluzione dei problemi del nuovo nodo di lavoro. Non sostituire o ricaricare ulteriori nodi di lavoro.

Se uno o alcuni nodi di lavoro sono interessati

Se solo alcuni, ma non tutti, dei nodi di lavoro nel tuo cluster si trovano in uno stato Critical o NotReady, segui questa procedura per determinare la causa dell'interruzione e risolvere il problema. Se i nodi di lavoro interessati provengono tutti dalla stessa zona, sottorete o VLAN, continua alla sezione successiva.

Ottieni i dettagli del nodo specifico.
```
oc describe node <node-IP-address>
```
Nell'output, controllare la sezione Condizioni per determinare se sul nodo si stanno verificando problemi di memoria, disco o PID. Queste informazioni potrebbero indicare che il nodo è in esecuzione su quel tipo di risorsa. Questa situazione potrebbe verificarsi per uno dei seguenti motivi:
- Esaurimento della memoria o della CPU causato da una mancanza di richieste e limiti corretti sui tuoi pod.
- I dischi di lavoro sono pieni, a volte a causa di log di pod di grandi dimensioni o dell'output del pod sul nodo stesso.
- Perdite di memoria lente che si accumulano nel corso del tempo, che possono causare problemi per i lavoratori che non sono stati aggiornati in oltre un mese.
- Bug e arresti anomali che influiscono sul kernel Linux.
Se puoi determinare la causa del problema dalle informazioni nella sezione Condizioni, attieniti alla procedura in Debug dei nodi di lavoro per isolare il carico di lavoro del problema.
Se i passi precedenti non risolvono il problema, ricarica o sostituisci i nodi di lavoro interessati uno alla volta.

Se tutti i nodi di lavoro in una singola zona, sottorete o VLAN sono interessati

Se tutti i nodi worker in una zona, subnet o VLAN sono in uno stato Critical o NotReady, ma tutti gli altri nodi worker nel cluster funzionano normalmente, potrebbe esserci un problema con un componente di rete. Attieniti alla procedura in Se tutti i nodi di lavoro in un cluster sono interessati, specialmente alla procedura relativa a tutti i componenti di rete che potrebbero influenzare la zona, la sottorete o la VLAN, come le regole del firewall o del gateway, gli ACL o le rotte personalizzate o le politiche di rete Calico e Kubernetes.

Se hai controllato i tuoi componenti di rete e ancora non riesci a risolvere il problema, raccogli i tuoi dati del nodo di lavoro e apri un ticket di supporto.

Se tutti i nodi di lavoro in un cluster sono interessati

Se tutti i nodi di lavoro nel tuo cluster mostrano Critical o NotReady contemporaneamente, potrebbe esserci un problema con il cluster apiserver o con il percorso di rete tra i nodi di lavoro e apiserver. Seguire questi passi per la risoluzione dei problemi per determinare la causa e risolvere il problema.

Alcuni passi sono specifici di un'area specializzata, come la rete o l'automazione. Consultare l'amministratore o il team pertinente nella propria organizzazione prima di completare questi passi.

Controlla se ci sono state modifiche recenti al tuo cluster, ambiente o account che potrebbero influire sui tuoi nodi di lavoro. In tal caso, ripristina le modifiche e controlla lo stato del nodo di lavoro per determinare se le modifiche hanno causato il problema.
- Per i cluster classici, controlla qualsiasi firewall o gateway, come Virtual Router Appliance, Vyatta o Juniper che gestisce il traffico per i nodi di lavoro del cluster. Ricercare le modifiche o i problemi che potrebbero rilasciare o reindirizzare il traffico dai nodi di lavoro del cluster.
- Per i cluster VPC, controlla se sono state apportate modifiche al gruppo di sicurezza predefinito e agli ACL sul VPC o sui nodi di lavoro. Se sono state apportate delle modifiche, assicurati di consentire tutto il traffico necessario dai nodi di lavoro del cluster al master del cluster, al registro del contenitore e ad altri servizi critici. Per ulteriori informazioni, vedere Comprendere la rete VPC in cluster secure by default e Creare e gestire gruppi di sicurezza VPC e Controllare il traffico con le ACL.
- Per i cluster VPC, controlla le regole di instradamento personalizzate per le modifiche che potrebbero bloccare il traffico dal cluster apiserver.
- Controlla le eventuali politiche di rete Calico o Kubernetes applicate al cluster e assicurati che non blocchino il traffico dal nodo di lavoro al cluster apiservice, al registro del contenitore o ad altri servizi critici.
Controlla se le applicazioni, la sicurezza o i componenti di monitoraggio nel tuo cluster stanno sovraccaricando il cluster apiserver con richieste, il che potrebbe causare interruzioni per i tuoi nodi di lavoro.
Se hai recentemente aggiunto dei componenti al tuo cluster, rimuovili. Se sono state apportate modifiche ai componenti esistenti nel cluster, ripristinare le modifiche. Quindi, controlla lo stato dei tuoi nodi di lavoro per vedere se i nuovi componenti o le modifiche stavano causando il problema.
Controlla le modifiche sui webhook del cluster, che possono interrompere le richieste apiserver o bloccare la capacità di un nodo di lavoro di connettersi a apiserver. Controlla i webhook che rifiutano le richieste. Eseguire il seguente comando per ottenere un elenco di webhook che rifiutano le richieste.
```
kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds
```
Esaminare l'output per i webhook che hanno lo stato 'rejected="true".
Rimuovi e rigenera tutti i segreti di pull Docker personalizzati, che, se non configurati correttamente, possono impedire ai nodi di lavoro di eseguire il pull delle immagini dai registri Docker.
1. Esegui i comandi oc delete secret -n openshift pull-secret e oc delete secret -n openshift-config pull-secret per eliminare i segreti di pull Docker.
```
    oc delete secret -n openshift pull-secret
    ```
    ```sh {: pre}
    oc delete secret -n openshift-config pull-secret
    ```
1. Attendi che il cluster rigeneri i segreti del pull Docker personalizzato. Tutti i componenti configurati in modo non corretto non sono più presenti nei segreti di pull rigenerati.
```
Controlla lo stato dei tuoi nodi di lavoro. Se si trovano in uno stato Normal, aggiungi di nuovo i componenti eliminati e ricrea le eventuali modifiche ripristinate, una per una, finché non puoi determinare quale configurazione o componente ha causato l'interruzione del nodo di lavoro.
Se il problema non è ancora risolto, attieniti alla procedura per raccogliere i tuoi dati del nodo di lavoro e aprire un ticket di supporto.

Se i nodi di lavoro passano da uno stato normale a uno critico

Se i tuoi nodi di lavoro passano da uno stato Normal e Critical o NotReady, controlla i seguenti componenti per eventuali problemi o modifiche recenti che potrebbero interrompere i tuoi nodi di lavoro.

Per i cluster classici, controlla i tuoi firewall o gateway. Se esiste un limite di larghezza di banda o qualsiasi tipo di malfunzionamento, risolvere il problema. Quindi, controlla nuovamente i tuoi nodi di lavoro.
Controlla se le applicazioni, la sicurezza o i componenti di monitoraggio nel tuo cluster stanno sovraccaricando il cluster apiserver con richieste, il che potrebbe causare interruzioni per i tuoi nodi di lavoro.
Se hai recentemente aggiunto dei componenti al tuo cluster, rimuovili. Se sono state apportate modifiche ai componenti esistenti nel cluster, ripristinare le modifiche. Quindi, controlla lo stato dei tuoi nodi di lavoro per vedere se i nuovi componenti o le modifiche stavano causando il problema.
Controlla le modifiche sui webhook del cluster, che possono interrompere le richieste apiserver o bloccare la capacità di un nodo di lavoro di connettersi a apiserver. Controlla i webhook che rifiutano le richieste. Eseguire il seguente comando per ottenere un elenco di webhook che rifiutano le richieste.
```
kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds
```
Esaminare l'output per i webhook che hanno lo stato 'rejected="true".
Se il problema non è ancora risolto, attieniti alla procedura per raccogliere i tuoi dati del nodo di lavoro e aprire un ticket di supporto.

Raccolta di dati per un caso di supporto

Se non sei in grado di risolvere il problema con la procedura di risoluzione dei problemi, raccogli informazioni sui tuoi nodi di lavoro. Quindi, apri un ticket di supporto e includi le informazioni sul nodo di lavoro che hai raccolto.

Prima di aprire un ticket di supporto, esamina le informazioni e attieniti a qualsiasi procedura di risoluzione dei problemi in Debug dei nodi di lavoro, Il nodo di lavoro dichiara e Risoluzione dei problemi dei nodi di lavoro nello stato Critical o NotReady.

Se sono interessati tutti i nodi worker di un cluster o di una regione, subnet o VLAN, è possibile aprire un primo ticket di assistenza senza raccogliere dati. Tuttavia, in seguito potrebbe essere richiesto di raccogliere i dati pertinenti. Se solo uno o alcuni dei tuoi nodi di lavoro sono interessati, devi raccogliere i dati pertinenti da includere nel tuo ticket di supporto.

Prima di iniziare

Controlla le condizioni dei tuoi nodi di lavoro e cluster prima di raccogliere i dati.

Controllare il livello di CPU e memoria dei nodi. Se un nodo supera l'80% nell'utilizzo della CPU o della memoria, prendere in considerazione la possibilità di eseguire il provisioning di più nodi o di ridurre il carico di lavoro.

oc top node

Output di esempio

NAME            CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
10.001.1.01     640m         16%    6194Mi          47%       
10.002.2.02     2686m        68%    4024Mi          30%       
10.003.3.03     2088m        53%    10735Mi         81%

Controlla le modifiche sui webhook del cluster, che possono interrompere le richieste apiserver o bloccare la capacità di un nodo di lavoro di connettersi a apiserver. Controlla i webhook che rifiutano le richieste. Eseguire il seguente comando per ottenere un elenco di webhook che rifiutano le richieste.
```
kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds
```
Esaminare l'output per i webhook che hanno lo stato 'rejected="true".

Raccolta di dati

Segui la procedura per raccogliere i dati del nodo di lavoro pertinenti.

Ottenere i dettagli di ciascun nodo. Salvare i dettagli di output da includere nel ticket di supporto.
```
oc describe node <node-ip-address>
```
Mostra che non ci sono webhook aggiunti che mutano o che convalidano i restanti nel tuo cluster ottenendo i dettagli del webhook. Salvare l'output del comando da includere nel ticket di supporto. Tenere presente che i seguenti webhook di mutazione potrebbero rimanere e non devono essere eliminati: alertmanagerconfigs.openshift, managed-storage-validation-webhooks, multus.openshift.io, performance-addon-operator, prometheusrules.openshift.io,snapshot.storage.k8s.io.
```
kubectl get mutatingwebhookconfigurations
```
```
kubectl get validatingwebhookconfigurations
```
Cluster classici: accedi alla console KVM per uno dei nodi di lavoro interessati. Quindi, raccogliere i log e l'output rilevanti.
1. Attieniti ai passi per accedere alla console KVM.
2. Raccogliere e salvare i seguenti log. Esamina i log per individuare le possibili cause dell'interruzione del nodo di lavoro, come la mancanza di memoria o di spazio su disco, il disco che entra in modalità di sola lettura e altri problemi.
  - /var/log/boot.log
  - /var/log/calico/cni/cni.log
  - /var/log/crio.log
  - /var/log/cron
  - /var/log/messages
  - /var/log/secure
3. Immetti i seguenti comandi e salva l'output da collegare al ticket di supporto.
  - ps -aux # Processo di esecuzione del dump
  - df -H # Informazioni sull'utilizzo del disco di dump
  - vmstat # Informazioni sull'utilizzo della memoria di dump
  - lshw # Informazioni sull'hardware di dump
  - last -Fxn2 shutdown reboot # determinare se l'ultimo riavvio è stato regolare o meno
  - mount | grep -i "(ro" # per escludere il problema di sola lettura del disco. NOTA: tmpfs essere ro va bene
  - touch /this # per escludere il problema di sola lettura del disco
Cluster VPC: Raccogliere l'uso delle risorse dai nodi worker usando il comando kubectl top come nell'esempio seguente.
```
kubectl top nodes
```
L'output di esempio mostra l'utilizzo della CPU in millicore (m) e della memoria in megabyte (Mi).
```
NAME          CPU(cores)    CPU%   MEMORY(bytes)   MEMORY%
k8s-node-1      250m              12%    800Mi                         40%
k8s-node-2      180m               9%     600Mi                         30%
k8s-node-3      250m               22%    700Mi                        50%
```
NOME

Il nome del nodo.

CPU (core)

L'utilizzo attuale della CPU in millicore (m). 1000m equivale a 1 core.

% CPU

La percentuale della capacità totale della CPU utilizzata sul nodo.

MEMORIA (byte)

L'utilizzo attuale della memoria in MiB (megabyte) o GiB (gigabyte).

MEMORIA%

La percentuale della capacità di memoria totale utilizzata.

Un nodo con un'elevata percentuale di CPU o di MEMORIA (superiore all'80%) potrebbe essere sovraccarico e richiedere risorse aggiuntive. Un nodo con una bassa percentuale di CPU o MEMORIA (inferiore al 20%) potrebbe essere sottoutilizzato, indicando la possibilità di ridistribuire il carico di lavoro. Se un nodo raggiunge il 100% di utilizzo della CPU o della memoria, i nuovi carichi di lavoro potrebbero non essere programmati o subire un calo delle prestazioni.
Raccogliere l'uso delle risorse dai pod utilizzando il seguente comando.
```
kubectl top pods --all-namespaces
```
Output di esempio
```
NAMESPACE       NAME                                  CPU(cores)   MEMORY(bytes)
default            my-app-564bc58dad-hk5gn       120m            256Mi
default             my-db-789d9c6c4f-tn7mv         300m            512Mi
```
NOME

Il nome del pod.

CPU (core)

La CPU totale utilizzata dal pod in tutti i suoi contenitori.

MEMORIA (byte)

La memoria totale utilizzata dal pod in tutti i suoi contenitori.

Se l'utilizzo della CPU di un pod è elevato, è possibile che si verifichi un throttling della CPU, che influisce sulle prestazioni. Se l'utilizzo della memoria di un pod è vicino al limite, potrebbe verificarsi un errore OOM (Out of Memory), in cui Kubernetes termina i processi per liberare memoria. Un pod con un basso utilizzo delle risorse potrebbe avere richieste sovra-allocate, con conseguente spreco di risorse.

Controllare le metriche a livello di contenitore eseguendo il comando top pod.

kubectl top pod pod-a --containers -n appns
```sh
{: pre}
Example output
```sh
NAME           CONTAINER      CPU(cores)   MEMORY(bytes)
pod-a            app-container        100m         300Mi
pod-a            db-container           50m          200Mi
```sh
{: screen}

Il comando kubectl top mostra solo l'utilizzo effettivo, non le risorse richieste o limitate. Per confrontare e analizzare l'output del comando top, verificare le specifiche del pod con il seguente comando.
```
kubectl describe pod <pod-name> -n <namespace>
```
Output di esempio
```
Containers:
 app-container:
   Requests:
  cpu: 250m
  memory: 512Mi
  Limits:
  cpu: 500m
  memory: 1Gi
```
Se l'utilizzo della CPU o della memoria supera le richieste, ciò potrebbe indicare un sottoprovvedimento, con conseguenti problemi di prestazioni. Se l'utilizzo è vicino ai limiti, il contenitore potrebbe essere rallentato o terminato quando le risorse sono limitate. Se l'utilizzo è significativamente inferiore alle richieste, il pod potrebbe essere sovraprovisionato, sprecando risorse.

Identificare i pod che consumano più CPU.

kubectl top pod --all-namespaces | sort -k3 -nr | head -10

Identificare i pod ad alto consumo di memoria.

kubectl top pod --all-namespaces | sort -k4 -nr | head -10

Monitorare l'utilizzo delle risorse da parte dei daemon di sistema. DaemonSets, come kube-proxy o gli agenti di monitoraggio, possono consumare risorse inaspettate.
```
kubectl top pod -n kube-system
```sh
{: pre}
```
Se alcuni pod di sistema consumano una quantità eccessiva di CPU o di memoria, potrebbero essere necessarie richieste e limiti di sintonizzazione. Per tenere traccia delle modifiche alle risorse in modo continuo, utilizzare il comando watch.
```
watch -n 5 kubectl top pod --all-namespaces
```sh
{: pre}
This command updates the output every 5 seconds, helping to spot spikes or anomalies in resource usage.
```
Controllare gli eventi di OOMKilled. Quando Kubernetes segnala OOMKilled, il pod ha superato il limite di memoria ed è stato terminato. Lo stato del pod cambia in crashloopbackoff.
```
kubectl get events --field-selector involvedObject.name=your-pod-name -n your-namespace
```

Cercate i messaggi di OOM nei registri.

kubectl logs your-pod-name -n your-namespace | grep -i "out of memory"

Controllare l'ultimo stato del contenitore per la terminazione di OOM.

kubectl describe pod your-pod-name -n your-namespace | grep -A 10 "Last State"

Raccolta dei log dei nodi worker

Seguire i passaggi per accedere al worker e raccogliere i log del nodo worker.

Raccogliere e salvare i seguenti file di registro. Esamina i log per individuare le possibili cause dell'interruzione del nodo di lavoro, come la mancanza di memoria o di spazio su disco, il disco che entra in modalità di sola lettura e altri problemi.
- /var/log/containerd.log
- /var/log/kern.log
- /var/log/kube-proxy.log
- /var/log/syslog
- /var/log/kubelet.log
Immetti i seguenti comandi e salva l'output da collegare al ticket di supporto.

Ottenere le statistiche del contenitore (richiede l'accesso SSH al nodo).
```
crictl stats
```
Ottenere statistiche dettagliate per un contenitore specifico.
```
crictl stats --id <container-id> --output json
```
Eseguire il comando per scaricare i processi in esecuzione.
```
ps -aux
```
Ottenete una visione dinamica e in tempo reale dei processi in esecuzione e delle attività gestite dal kernel, nonché dell'utilizzo delle risorse, compreso l'uso della CPU e della memoria.
```
top
```
Ottenere lo stato attuale del sistema.
```
htop
```
Ottenete un rapporto di monitoraggio completo con dati storici.
```
atop
```
Ottenere informazioni in tempo reale sui processi di sistema.
```
btop
```
Ottenere i dettagli della connessione di rete.
```
netstat
```
Ottenere informazioni sull'uso del disco.
```
df -H
```
Eseguire vmstat per ottenere rapporti su processi, memoria, paging, block IO, trappole e attività della CPU. Questo comando ottiene le informazioni a intervalli di 2 secondi, per 5 volte.
```
vmstat 2 5
```
Eseguite iostat per raccogliere statistiche sull'uso del disco che coprono il throughput, l'utilizzo, la lunghezza delle code, il tasso di transazioni e altro ancora.
```
iostat -x 1 5
```
Raccogliere informazioni sull'hardware.
```
lshw
```
Per sapere se l'ultimo riavvio è stato aggraziato o meno, utilizzare il comando seguente.
```
last -Fxn2 shutdown reboot
```
Per escludere il problema del disco, verificare che il disco sia scrivibile.
```
mount | grep -i "(ro"
touch /this
```
Se il problema persiste, aprire un ticket di assistenza e allegare tutti gli output salvati nei passaggi precedenti.

Risoluzione dei problemi dei nodi di lavoro nello stato Critical o NotReady

Risoluzione dei problemi dei nodi di lavoro nello stato Critical o NotReady

Controllare le cause comuni degli errori del nodo di lavoro

Procedura di risoluzione dei problemi

Se uno o alcuni nodi di lavoro sono interessati

Se tutti i nodi di lavoro in una singola zona, sottorete o VLAN sono interessati

Se tutti i nodi di lavoro in un cluster sono interessati

Se i nodi di lavoro passano da uno stato normale a uno critico

Raccolta di dati per un caso di supporto

Prima di iniziare

Raccolta di dati

Raccolta dei log dei nodi worker

Risoluzione dei problemi dei nodi di lavoro nello stato `Critical` o `NotReady`