目录

简介

缩写词

需要日志

故障排除顺序

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

配置不可用

CPU周期限制

简介

本文档介绍如何识别和恢复处于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。