对处于CrashLoopBackOff状态的Ops-center Pod进行故障排除

简介

本文档介绍如何识别和恢复处于CrashLoopBackOff状态的运营中心Pod。

缩写词

RCM — 冗余配置管理器

YYYY-MM-DD hh:mm:ss — 年 — 月 — 日小时：分钟：秒

CPU — 中央处理器

需要日志

故障排除所需的RCM命令输出：

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>

故障排除顺序

1.通过在高可用性对中执行命令，验证受影响的运营中心Pod是否位于主RCM或BACKUP RCM中：

# rcm show-status

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

2.收集受影响操作中心Pod的Pod说明，并查看重新启动计数以及容器中哪些退出代码处于有问题的状态。例如，containers confd和confd notifications当前处于有问题的状态，如下所示：

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.检查退出代码，了解初始容器重新启动的原因。

示例：

退出代码137表示容器/Pod没有足够的内存。

退出代码1表示由于应用错误导致容器关闭。

4.查看journalctl以验证问题时间表，并了解发现问题的时间。指示重新启动容器配置通知的日志（如此处所示）可用于确定问题时间的开始：

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.复查重新启动的容器的容器日志，并验证导致连续容器重新启动循环的原因。在本例中，容器日志指示加载恢复配置时出现故障：

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

警告：

如果使用—previous选项在尚未重新启动或终止的容器上执行容器日志，则会返回错误：

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

导致后续配置恢复问题的可能场景

配置不可用

• confd-api-bridge容器具有从confd读取配置并每秒创建一次备份的功能。confd-api-bridge将其存储在configmap ops-center-confd-<opscenter-name>中。
• 如果confd容器停止并随后停止，confd-api-bridge不会收到配置的回复，它会在配置映射中存储一个空配置。
• 当confd容器尝试从可用的备份配置中恢复时，它将失败并导致CrashLoopBackOff状态。这可以从配置容器日志中验证：

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

此行为通过Cisco Bug ID CSCwi15801解决。

CPU周期限制

• 当confd容器尝试恢复时，如果在30秒内启动未完成，容器将重新启动。
• 如果由于RCM上的CPU负载过大，启动未收到所需的CPU周期，则启动被延迟。
• 如果RCM CPU因其他Pod（例如rcm-checkpointmgr）的加载而继续处于已占状态，confd容器将继续重新启动并导致CrashLoopBackOff状态。

此行为由思科漏洞ID CSCwe79529解决。

注意：

• 如果主RCM受到影响，请执行RCM切换到备用RCM，然后进一步排除故障。如果没有BACKUP RCM可用，请继续排除主RCM故障。
• 如果发现运营中心Pod处于CrashLoopBackOff状态，建议在执行任何解决方法之前咨询思科TAC。