Dépannage du POD Ops-center dans l'état CrashLoopBackOff

Introduction

Ce document décrit comment identifier et récupérer le pod du centre d'opérations dans l'état CrashLoopBackOff.

Acronymes

RCM - Redundancy Configuration Manager

AAAA-MM-JJ hh:mm:ss - Année-Mois-Jour Heure:Minute:seconde

Processeur - Unité centrale

Journaux requis 

Résultats des commandes du RCM nécessaires au dépannage :

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>

Séquence de dépannage

1. Vérifiez si le pod ops-center concerné se trouve dans un RCM MASTER ou un RCM BACKUP en exécutant la commande dans la paire haute disponibilité :

# rcm show-status

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

2. Collectez la description du pod du pod du centre d'opérations affecté et vérifiez le nombre de redémarrages et les codes de sortie dans les conteneurs qui sont dans un état problématique. Par exemple, les conteneurs confd et les notifications confd sont actuellement dans un état problématique, comme indiqué :

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. Examinez le code de sortie pour comprendre la cause du redémarrage initial du conteneur.

Exemple :

Le code de sortie 137 indique que les conteneurs/pod ne disposent pas de suffisamment de mémoire.

Le code de sortie 1 indique un arrêt du conteneur en raison d'une erreur d'application.

4. Consultez le journal ctl pour vérifier le calendrier du problème et comprendre à partir de quand le problème est observé. Les journaux indiquant le redémarrage des notifications de configuration du conteneur, comme illustré ici, peuvent être utilisés pour identifier le début de l'heure du problème :

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. Consultez les journaux des conteneurs des conteneurs redémarrés et vérifiez la cause de la boucle de redémarrage continue des conteneurs. Dans cet exemple, les journaux des conteneurs indiquent une défaillance dans le chargement de la configuration de restauration :

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

Avertissement :

Si les journaux de conteneur sont exécutés avec l'option —previous sur un conteneur qui n'a pas redémarré ou s'est arrêté, il retourne une erreur :

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

Scénarios possibles entraînant un problème lors de la restauration de la configuration suivante

Indisponibilité de la configuration

• Le conteneur confd-api-bridge a pour fonction de lire la configuration à partir de confd et de créer une sauvegarde toutes les secondes. Le pont configmap-api-bridge le stocke dans le configmap ops-center-confd-<opscenter-name>.
• Si le conteneur confd est arrêté et que, par la suite, le pont confd-api ne reçoit aucune réponse pour la configuration, il stocke une configuration vide dans le configmap.
• Lorsque le conteneur confd tente de restaurer à partir de la configuration de sauvegarde disponible, il échoue et provoque l'état CrashLoopBackOff. Ceci peut être vérifié à partir des journaux du conteneur confd :

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

Ce comportement est corrigé par l'ID de bogue Cisco CSCwi15801.

Contraintes de cycle CPU

• Lorsque le conteneur confd tente de récupérer, si le démarrage n'est pas terminé dans les trente secondes, le conteneur est redémarré.
• Le démarrage est retardé s'il ne reçoit pas les cycles CPU requis en raison de la charge CPU élevée sur le RCM.
• Si le processeur du RCM continue à être occupé en raison d'une charge par d'autres pods tels que rcm-checkpoint mgr, le conteneur confd continue à redémarrer et provoque l'état CrashLoopBackOff.

Ce comportement est corrigé par l'ID de bogue Cisco CSCwe79529.

Remarque :

• Si le MASTER RCM est affecté, effectuez un basculement du RCM vers le BACKUP RCM, puis poursuivez le dépannage. Et si aucun RCM de SECOURS n'est disponible, poursuivez le dépannage du RCM MAÎTRE.
• Il est recommandé de consulter le TAC Cisco avant d'effectuer toute solution de contournement si un pod du centre d'opérations est observé dans l'état CrashLoopBackOff.