Problemen oplossen met Ops-center Pod in CrashLoopBackOff-status

Inleiding

In dit document wordt beschreven hoe u de pod ops-center kunt identificeren en herstellen in de status CrashLoopBackOff.

Acroniemen

RCM – Redundancy Configuration Manager

JJJJ-MM-DD uu:mm:ss – Jaar-Maand-Dag Uur: Minuut: seconde

CPU – centrale verwerkingseenheid

Vereiste logs

RCM-opdrachtuitvoer vereist voor probleemoplossing:

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>

Volgorde voor probleemoplossing

1. Controleer of de betreffende ops-center-pod zich in een MASTER RCM of BACKUP RCM bevindt door de opdracht uit te voeren in het paar met hoge beschikbaarheid:

# rcm show-status

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

2. Verzamel de pod beschrijving van de getroffen op-center pod en controleer de herstart telling en welke exit codes in de containers zijn in een problematische staat. Zo verkeren de confd- en confd-meldingen momenteel in een problematische toestand, zoals aangegeven:

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. Controleer de afsluitcode om de oorzaak van de eerste herstart van de container te begrijpen.

Voorbeeld:

Afsluitcode 137 geeft aan dat de containers/pod niet voldoende geheugen hebben.

Afsluitcode 1 geeft aan dat de container is afgesloten vanwege een toepassingsfout.

4. Controleer het tijdschrift om de tijdlijn van het probleem te controleren en te begrijpen vanaf het moment dat het probleem wordt waargenomen. Logs die aangeven dat de container confd-meldingen opnieuw worden opgestart, zoals hier wordt weergegeven, kunnen worden gebruikt om het begin van de uitgiftetijd te identificeren:

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. Controleer de containerlogboeken van opnieuw opgestarte containers en controleer de oorzaak van de doorlopende containerherstartlus. In dit voorbeeld geven de containerlogs aan dat de herstelconfiguratie niet is geladen:

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

Waarschuwing:

Als containerlogs worden uitgevoerd met de optie --previous op een container die niet opnieuw is opgestart of beëindigd, wordt een fout geretourneerd:

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

Mogelijke scenario's die leiden tot een probleem met latere configuratieherstel

Onbeschikbaarheid van configuratie

• De confd-api-bridge container heeft de functie om de configuratie van confd te lezen en elke seconde een back-up te maken. De confd-api-bridge slaat het op in de configmap ops-center-confd-<opscenter-name>.
• Als de confd-container wordt gestopt en vervolgens de confd-api-bridge geen antwoord ontvangt voor de configuratie, slaat deze een lege configuratie op in de configmap.
• Wanneer de confd-container probeert te herstellen vanuit de beschikbare back-upconfiguratie, mislukt dit en wordt de status CrashLoopBackOff veroorzaakt. Dit kan worden geverifieerd uit de confd container logs:

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

Dit gedrag wordt aangepakt door een Cisco bug ID CSCwi15801.

Beperkingen CPU-cyclus

• Wanneer de confd-container probeert te herstellen, wordt de container opnieuw gestart als het opstarten niet binnen dertig seconden is voltooid.
• Het opstarten is vertraagd als de CPU niet de vereiste cycli ontvangt vanwege de hoge CPU-belasting op de RCM.
• Als de RCM-CPU in een bezette toestand blijft vanwege belasting door andere pods zoals rcm-checkpointmgr, blijft de confd-container opnieuw opstarten en veroorzaakt de CrashLoopBackOff-status.

Dit gedrag wordt aangepakt door een Cisco bug ID CSCwe79529.

Opmerking:

• Als de MASTER RCM is aangetast, voert u een RCM-overschakeling uit naar de BACKUP RCM en lost u het probleem vervolgens verder op. En als er geen RCM voor BACK-UP beschikbaar is, gaat u verder met het oplossen van problemen met de RCM voor de MASTER.
• Het wordt aanbevolen om Cisco TAC te raadplegen voordat u een tijdelijke oplossing uitvoert als een pod in het midden van een ops wordt waargenomen in de status CrashLoopBackOff.