目錄

簡介

縮寫說明

需要日誌

故障排除順序

可能導致後續配置恢復問題的可能方案

配置不可用

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描述，並檢視重新啟動計數以及容器中哪些退出代碼處於有問題的狀態。例如，容器confd和confd通知當前處於有問題的狀態，如下所示：

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表示容器/容器沒有足夠的記憶體。

退出代碼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容器記錄驗證：

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

此行為由Cisco錯誤ID CSCwi15801解決。

CPU週期限制

- confd容器嘗試恢復時，如果在30秒內未完成啟動，則容器將重新啟動。

- 由於RCM上的CPU負載高，如果啟動未收到所需的CPU週期，則啟動被延遲。

- 如果RCM CPU由於其他Pod（如rcm-checkpointmgr）的載入而繼續處於已佔狀態，則confd容器將繼續重新啟動並導致CrashLoopBackOff狀態。

此行為由思科錯誤ID CSCwe79529處理。

附註：

- 如果主RCM受到影響，請執行RCM切換到備份RCM，然後進一步進行故障排除。如果沒有可用的備份RCM，請繼續排除主RCM故障。

- 如果觀察到CrashLoopBackOff狀態下運行中心Pod，建議在執行任何變通方法之前諮詢思科TAC。