Prima di iniziare

Prima di poter utilizzare i servizi di osservabilità per eseguire il debug del cluster, assicurarsi che siano soddisfatti i seguenti requisiti.

• Il tuo cluster è connesso a un'istanza di IBM Cloud Monitoring. Per connettere il tuo cluster, consulta la sezione " Abilitazione delle metriche" all'indirizzo Red Hat OpenShift on IBM Cloud.
• Il tuo cluster è connesso a un'istanza di IBM Cloud Logs. Per connettere il cluster, consultare la sezione " Abilitazione della registrazione ".
• Hai almeno un accesso di tipo "Viewer" alle istanze dei servizi IBM Cloud Monitoring e IBM Cloud Logs presenti nel tuo account.

Verifica l'utilizzo delle risorse del nodo di lavoro con IBM Cloud Monitoring

Quando i nodi di lavoro entrano in uno stato di “ Critical ” o “ NotReady ”, una causa comune è l’elevato utilizzo della CPU o della memoria. Utilizza i dashboard predefiniti di " IBM Cloud Monitoring " per individuare rapidamente eventuali pressioni sulle risorse.

1. Apri la dashboard di IBM Cloud Monitoring relativa al tuo cluster.

   1. Nella console di IBM Cloud, accedi alla pagina delle risorse del cluster e fai clic sul cluster di tuo interesse.
   2. Nella sezione " Integrazioni", individua l'opzione "Monitoraggio" e fai clic su "Avvia". L'interfaccia utente di IBM Cloud Monitoring si apre in una nuova finestra.

2. Accedi alla Kubernetes > dashboard predefinita " Nodi " per visualizzare l'utilizzo della CPU e della memoria per ciascun nodo.

   • Cerca i nodi in cui il valore di " % della CPU " o " Percentuale di memoria " supera l'80%. I nodi che raggiungono o superano questa soglia rischiano di andare in sovraccarico e potrebbero non riuscire più a pianificare nuovi pod.
   • Cerca i nodi in cui l'utilizzo della CPU o della memoria mostra un picco improvviso o è rimasto costantemente elevato nell'ultima ora o nell'ultimo giorno. Questo può aiutarti a capire se il problema è momentaneo o persistente.

3. Per esaminare un nodo specifico, clicca sul nome del nodo nella dashboard per filtrare tutti i grafici in base a quel nodo. Controlla i seguenti indicatori:

   • Utilizzo della CPU (%) — un valore costante superiore al 90% indica la saturazione della CPU.
   • Utilizzo della memoria (% ) — un valore costantemente superiore all'85% aumenta il rischio di eventi di esaurimento della memoria (OOM).
   • Byte in entrata/in uscita dalla rete: un picco di traffico imprevisto può indicare un carico di lavoro fuori controllo o un attacco alla rete.

4. Per verificare quali pod stanno consumando più risorse su un nodo, accedere alla Kubernetes > dashboard Pods e filtra in base al nodo interessato. Prendi nota dei nomi di eventuali pod che presentano un utilizzo della CPU o della memoria costantemente elevato, poiché questi sono i probabili responsabili dell'instabilità del nodo di lavoro.

Verifica lo stato dei pod e il numero di riavvii con IBM Cloud Monitoring

I pod che entrano in un ciclo infinito di arresti anomali o si riavviano frequentemente sono un segno comune di problemi a livello di applicazione, come terminazioni dovute a esaurimento della memoria (OOM) o probe di prontezza configurate in modo errato. Utilizza IBM Cloud Monitoring per identificare questi pod senza dover eseguire ripetutamente oc get pods.

1. Nell'interfaccia utente di IBM Cloud Monitoring, accedere alla Kubernetes > dashboard predefinita " Pods ".

2. Esamina il pannello " Riavvii dei container ". Cerca i pod che mostrano un conteggio dei riavvii superiore a zero negli ultimi 15 minuti o che presentano un rapido aumento in un arco di tempo più lungo.

   • Un conteggio di riavvio che aumenta ripetutamente indica un ciclo di crash. Prendere nota del nome del pod e dello spazio dei nomi per utilizzarli nelle fasi successive di analisi dei log.
   • Un conteggio dei riavvii pari a zero, ma con uno stato “In sospeso” o “Sconosciuto”, indica un problema di pianificazione o di connettività del nodo piuttosto che un errore dell’applicazione.

3. Per configurare un avviso relativo a futuri eventi di riavvio del pod, fare clic sull'icona Avvisi nell'interfaccia utente di IBM Cloud Monitoring e creare un avviso relativo alla metrica " kubernetes.pod.restart.count ". Imposta la soglia di attivazione quando il numero di riavvii supera i due in cinque minuti per qualsiasi pod. Ciò consente di ricevere un preavviso prima che un ciclo di crash diventi destabilizzante. Per ulteriori informazioni sulla configurazione degli avvisi, consultare la sezione " Configurazione degli avvisi di IBM Cloud® Monitoring"

Analizza i log dei container con IBM Cloud Logs

Quando un pod viene riavviato o un nodo presenta dei problemi, è fondamentale esaminare i log dei container per individuarne la causa principale. IBM Cloud Logs conserva i dati storici dei log che non sono disponibili su oc logs dopo il riavvio di un container.

1. Apri il dashboard IBM Cloud Logs.

   1. Nella console di IBM Cloud, accedi alla pagina delle risorse del cluster e fai clic sul cluster di tuo interesse.
   2. Nella sezione " Integrazioni", individua l'opzione "Registrazione" e fai clic su "Avvia". L'interfaccia utente di IBM Cloud Logs si apre in una nuova finestra.

2. Imposta l'intervallo di tempo in modo che comprenda il periodo in cui si è verificato il problema. Se il problema persiste, imposta l'intervallo sull'ultima ora. Se stai effettuando una ricerca su un evento passato, imposta l'ora di inizio e di fine specifiche per restringere i risultati.

3. Cerca il pod o lo spazio dei nomi interessato. Utilizza la barra di ricerca nella parte superiore dell'interfaccia utente per filtrare i log. Ad esempio, per visualizzare i log di tutti i pod presenti nello spazio dei nomi default, inserire la seguente query:

   kubernetes.namespace_name:"default"
   

   Per restringere i risultati a un pod specifico in base al nome, usa:

   kubernetes.pod_name:"MY_POD_NAME"
   

4. Controlla le righe di log relative alle voci di livello di errore. Verificate la presenza di uno dei seguenti modelli, che indicano modalità di guasto comuni:

   • OOMKilled oppure " out of memory " — il container ha superato il limite di memoria ed è stato terminato dal kernel.
   • CrashLoopBackOff — il container si riavvia ripetutamente, spesso a causa di un errore dell'applicazione all'avvio.
   • failed to pull image oppure ImagePullBackOff — il nodo non riesce a scaricare l'immagine del container dal registro.
   • Connection refused oppure context deadline exceeded — l'applicazione non riesce a connettersi a un servizio dipendente o al server API Kubernetes.

5. Se trovi una voce di log relativa a un errore OOM, prendi nota del timestamp e controlla la IBM Cloud Monitoring Kubernetes > per lo stesso intervallo di tempo, al fine di confermare che l'utilizzo della memoria del pod abbia raggiunto il limite immediatamente prima del riavvio.

Scopri gli eventi dell’ Kubernetes e su IBM Cloud Logs

Kubernetes Gli eventi registrano attività importanti del cluster, quali errori di pianificazione dei pod, condizioni dei nodi ed errori di montaggio dei volumi. IBM Cloud Logs acquisisce automaticamente questi eventi e consente di effettuare ricerche e filtrarli in base alla cronologia, a differenza di oc get events, che mostra solo gli eventi recenti della sessione corrente.

1. Nell'interfaccia utente di IBM Cloud Logs, utilizzare la seguente query per visualizzare tutti gli eventi di avviso relativi all' Kubernetes presenti nel cluster:

   kubernetes.event.type:"Warning"
   

2. Per filtrare gli eventi relativi a un nodo di lavoro specifico, aggiungere il nome del nodo alla query. Sostituire NODE_NAME con il nome del nodo interessato:

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

3. Controlla il campo “Motivo” nelle voci del registro eventi. I seguenti motivi sono i più rilevanti per il debug dei problemi relativi ai nodi di lavoro e ai carichi di lavoro:

NodeNotReady

Il nodo segnala una condizione di " NotReady ". Questo evento spesso precede o accompagna il passaggio di un nodo di lavoro allo stato " Critical ".

OOMKilling

Il kernel ha terminato un processo sul nodo a causa dell'esaurimento della memoria.

FailedScheduling

Lo scheduler non è riuscito a collocare un pod su nessun nodo disponibile. Il campo del messaggio di solito spiega il motivo, ad esempio una CPU insufficiente, memoria insufficiente o una mancata corrispondenza del selettore di nodo.

BackOff

Un container è in un ciclo infinito. L'evento viene generato ogni volta che l' kubelet e esegue un backoff prima di riavviare il container.

FailedMount oppure FailedAttachVolume

Non è stato possibile montare o associare un volume persistente a un pod, il che impedisce l'avvio del pod.

1. Per ogni evento che sembri rilevante, prendi nota dei valori di " involvedObject.name " e " involvedObject.namespace " e utilizzali per stabilire una correlazione con i dati di log e metrici raccolti nelle sezioni precedenti.

Passi successivi

• Se hai individuato un nodo di lavoro sottoposto a pressione sulle risorse, valuta la possibilità di ricaricare o sostituire il nodo di lavoro oppure di modificare le richieste e i limiti delle risorse dei pod in esecuzione su quel nodo.
• Se i pod entrano in un ciclo infinito di arresti a causa di terminazioni OOM, aumentare i limiti di memoria per i container interessati oppure spostare i carichi di lavoro che richiedono molta memoria in un pool di worker con nodi più potenti.
• Se i log indicano errori nel download delle immagini, controlla i segreti relativi al download delle immagini e verifica che il nodo di lavoro riesca a connettersi al registro dei container.
• Per i problemi che non è possibile risolvere con le informazioni raccolte in questa sede, consulta la sezione “Raccolta dei dati per una richiesta di assistenza” per ottenere le informazioni necessarie all’apertura di un ticket di assistenza.

Link correlati

• Monitoraggio dello stato di integrità del cluster
• Introduzione a IBM Cloud Monitoring
• Introduzione a IBM Cloud Logs
• Risoluzione dei problemi relativi ai nodi di lavoro in stato “ Critical ” o “ NotReady ”
• Configurazione degli avvisi di " IBM Cloud® Monitoring "