Risoluzione dei problemi relativi a Ops-center Pod in stato CrashLoopBackOff

Introduzione

Questo documento descrive come identificare e ripristinare il pod ops-center nello stato CrashLoopBackOff.

Acronimi

RCM - Gestione configurazione ridondanza

AAAA-MM-GG hh:mm:ss - Anno-Mese-Giorno Ora:Minuto:secondo

CPU - Unità di elaborazione centrale

Registri necessari

Output dei comandi di RCM necessari per la risoluzione dei problemi:

1. kubectl get pods --namespace <namespace>
2. kubectl describe pods <podname> --namespace <namespace>
3. journalctl --since "YYYY-MM-DD hh:mm:ss" --until "YYYY-MM-DD hh:mm:ss" > /tmp/<filename>
4. kubectl --namespace rcm logs --previous <pod name> --container <container name> > /tmp/<filename>

Sequenza per la risoluzione dei problemi

1. Verificare se il pod ops-center interessato si trova in un RCM MASTER o BACKUP eseguendo il comando nella coppia di disponibilità elevata:

# rcm show-status

Example :
[unknown] rcm# rcm show-status
message :
{"status”: “MASTER"}

2. Raccogliere la descrizione del pod del pod centro superiore interessato ed esaminare il conteggio riavvii e quali codici di uscita nei contenitori sono in uno stato problematico. Ad esempio, le notifiche confd e confd dei contenitori sono attualmente in uno stato problematico, come indicato:

Example:
rcm # kubectl describe pods ops-center-rcm-ops-center --namespace rcm
Name:         ops-center-rcm-ops-center
Namespace:    rcm
…
Containers:
  confd:
    …
    Last State:     Terminated
      Reason:       Error
      Exit Code:    137
      Started:      Fri, 01 Dec 2023 12:44:13 +0530
      Finished:     Fri, 01 Dec 2023 12:46:09 +0530
    Ready:          False
    Restart Count:  8097
  …
  confd-api-bridge:
  …
    State:          Running
      Started:      Tue, 09 May 2023 02:36:37 +0530
    Ready:          True
    Restart Count:  0
  …
  product-confd-callback:
  …
    State:          Running
      Started:      Tue, 09 May 2023 02:36:38 +0530
    Ready:          True
    Restart Count:  0
  …
  confd-notifications:
    …
    State:          Running
      Started:      Fri, 01 Dec 2023 12:46:14 +0530
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Fri, 01 Dec 2023 12:40:50 +0530
      Finished:     Fri, 01 Dec 2023 12:46:00 +0530
    Ready:          True
    Restart Count:  5278
…

3. Esaminare il codice di uscita per comprendere la causa del riavvio iniziale del contenitore.

Esempio:

Il codice di uscita 137 indica che i contenitori/pod non dispongono di memoria sufficiente.

Il codice di uscita 1 indica la chiusura del contenitore a causa di un errore dell'applicazione.

4. Esaminare il journalctl per verificare la cronologia del problema e capire da quando il problema è stato rilevato. I log che indicano il riavvio delle notifiche di conferma del contenitore, come illustrato di seguito, possono essere utilizzati per identificare l'inizio del tempo di emissione:

Nov 29 00:00:01 <nodename> kubelet[30789]: E1129 00:00:01.993620   30789 pod_workers.go:190] "Error syncing pod, skipping" err="failed to \"StartContainer\" for \"confd-notifications\" with CrashLoopBackOff: \"back-off 5m0s restarting failed container=confd-notifications pod=ops-center-rcm-ops-center (<podUID>)\"" pod="rcm/ops-center-rcm-ops-center" podUID=<podUID>

5. Esaminare i log dei container riavviati e verificare la causa del loop di riavvio continuo dei container. In questo esempio, i log dei container indicano un errore nel caricamento della configurazione di ripristino:

Example:
rcm # kubectl --namespace rcm logs --previous ops-center-rcm-ops-center --container confd
ConfD started
Failed to connect to server
All callpoints are registered - exiting
ConfD restore
Failure loading the restore configuration
ConfD load nodes config
DEBUG Failed to connect to ConfD: Connection refused
confd_load: 290: maapi_connect(sock, addr, addrlen) failed: system call failed (24): Failed to connect to ConfD: Connection refused
…
Failure loading the nodes config
ConfD load day-N config
Failure loading the day-N config
…
Failure in starting confd - see previous errors - killing 1

rcm # kubectl --namespace rcm logs --previous ops-center-rcm-ops-center --container confd-notifications
…
Checking that ConfD is running.
Checking that ConfD is running.
ConfD is up and running
Failed to load schemas from confd

Avviso:

Se i registri del contenitore vengono eseguiti con l'opzione —PREVIOUS su un contenitore che non è stato riavviato o terminato, viene restituito un errore:

rcm:~# kubectl --namespace rcm logs --previous ops-center-rcm-ops-center --container confd-api-bridge > /tmp/confd_api_bridge_p_log 
Error from server (BadRequest): previous terminated container "confd-api-bridge" in pod "ops-center-rcm-ops-center" not found

Possibili scenari che causano un problema con il successivo ripristino della configurazione

Non disponibilità della configurazione

• Il contenitore config-api-bridge è in grado di leggere la configurazione da config e creare un backup ogni secondo. Il bridge config-api lo memorizza nella mappa di configurazione ops-center-config-<opscenter-name>.
• Se il contenitore config viene arrestato e in seguito, il bridge config-api non riceve alcuna risposta per la configurazione, archivia una configurazione vuota nella mappa di configurazione.
• Quando il contenitore di configurazione tenta di eseguire il ripristino dalla configurazione di backup disponibile, l'operazione non riesce e viene generato lo stato CrashLoopBackOff. È possibile verificare questa condizione dai registri del contenitore confd:

confd_load: 660: maapi_candidate_commit_persistent(sock, NULL) failed: notset (12): /cisco-mobile-product:kubernetes/registry is not configured

Questo comportamento è risolto da un bug Cisco con ID CSCwi15801.

Vincoli del ciclo di CPU

• Quando il contenitore confd tenta di eseguire il ripristino, se l'avvio non viene completato entro trenta secondi, il contenitore viene riavviato.
• L'avvio viene ritardato se non riceve i cicli della CPU richiesti a causa dell'elevato carico della CPU su RCM.
• Se la CPU di RCM continua ad essere occupata a causa del carico da parte di altri supporti, ad esempio rcm-checkpointmgr, il contenitore confd continua a riavviarsi e a causare lo stato CrashLoopBackOff.

Per risolvere questo problema, consultare l'ID bug Cisco CSCwe79529.

Nota:

• Se il problema riguarda RCM MASTER, eseguire il passaggio di RCM a RCM BACKUP, quindi procedere con la risoluzione del problema. Se invece non è disponibile alcun RCM di BACKUP, continuare con la risoluzione dei problemi di RCM MASTER.
• Si consiglia di consultare Cisco TAC prima di adottare qualsiasi soluzione alternativa se si rileva un pod ops-center nello stato CrashLoopBackOff.