Ops-center Pod在CrashLoopBackOff狀態下進行故障排除

簡介

本文檔介紹如何識別和恢復處於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。