المقدمة
يصف هذا وثيقة كيف أن يعين واسترد ال ops-center pod في CrashLoopBackOff دولة.
الاختصارات
RCM - مدير تكوين التكرار
YYYY-MM-DD HH:mm:ss - ساعة الشهر:الدقيقة:الثانية
وحدة المعالجة المركزية - وحدة المعالجة المركزية
السجلات المطلوبة
يلزم توفر عمليات إخراج أوامر 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 رئيسي أو RCM إحتياطي من خلال تنفيذ الأمر في زوج التوفر العالي:
# rcm show-status
Example :
[unknown] rcm# rcm show-status
message :
{"status”: “MASTER"}
2. جمع وصف نقطة الوصول (pod) الخاص بنقطة الوصول (op-center) المتأثرة ومراجعة عدد مرات إعادة التشغيل وأي رموز الخروج في الحاويات في حالة إشكالية. على سبيل المثال، تواجه الإخطارات المرسومة والمرتبطة حاليا حالة إشكالية، كما هو موضح:
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. مراجعة سجل اليومية للتحقق من الجدول الزمني للمسألة ومعرفة تاريخ ملاحظة المشكلة. يمكن إستخدام السجلات التي تشير إلى إعادة تشغيل إعلامات ترميز الحاوية، كما هو موضح هنا، لتحديد بداية وقت الإصدار:
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
تحذير:
إذا تم تنفيذ سجلات الحاوية باستخدام الخيار —السابق على حاوية لم يتم إعادة تشغيلها أو إنهاؤها، فإنها ترجع خطأ:
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-api-bridge بتخزينه في configMap ops-center-confd-<opscenter-name>.
- إذا تم إيقاف حاوية الإرساء وبعد ذلك، فإن confd-api-bridge لا يتلقى أي رد على التكوين، فإنه يخزن تكوين فارغ في configMap.
- عندما تحاول حاوية الإرساء الاستعادة من تكوين النسخ الاحتياطي المتاح، فإنها تفشل وتتسبب في حالة CrashLoopBackOff. يمكن التحقق من هذا من سجلات الحاويات المكونة:
confd_load: 660: maapi_candidate_commit_persistent(sock, NULL) failed: notset (12): /cisco-mobile-product:kubernetes/registry is not configured
يتم معالجة هذا السلوك بواسطة معرف تصحيح الأخطاء من Cisco CSCwi15801.
قيود دورة المعالج
- عندما تحاول حاوية الإرساء الاسترداد، إذا لم يكتمل بدء التشغيل في غضون ثلاثين ثانية، تتم إعادة تشغيل الحاوية.
- يتم تأجيل بدء التشغيل إذا لم يستلم دورات وحدة المعالجة المركزية (CPU) المطلوبة نظرا لارتفاع حمل وحدة المعالجة المركزية (CPU) على RCM.
- إذا إستمرت وحدة المعالجة المركزية ل RCM في حالة الانشغال بسبب التحميل بواسطة نقاط وصول أخرى مثل RCM-checkpointMgr، يستمر إعادة تشغيل الحاوية المربوطة ويسبب حالة CrashLoopBackOff.
يتم معالجة هذا السلوك بواسطة معرف تصحيح الأخطاء من Cisco CSCwe79529.
ملاحظة:
- إذا تأثر RCM الرئيسي، فقم بإجراء تحويل RCM إلى RCM للنسخ الاحتياطي ثم قم باستكشاف الأخطاء وإصلاحها مرة أخرى. وإذا لم تتوفر أي RCM للنسخ الاحتياطي، استمر في أستكشاف أخطاء RCM الرئيسية وإصلاحها.
- يوصى بالتشاور مع Cisco TAC قبل تنفيذ أي حلول بديلة إذا تم ملاحظة نقطة وصول لمركز التشغيل في حالة CrashLoopBackOff.