الدرس 14: تشخيص الأعطال — الدرس الختامي
لقد وصلت إلى الدرس الأخير، وفيه نجمع كل شيء معًا في أداة واحدة ستستخدمها مرارًا وتكرارًا: تدفق تشخيص منظّم — أي runbook. عندما ينكسر شيء ما في العنقود، يكون من المغري أن تصاب بالذعر وتخمّن. بدلًا من ذلك، نعمل كالمحققين: نجمع الأدلة أولًا، وعندها فقط نتّهم مشتبهًا به. الترتيب بسيط وثابت: أولًا kubect
تشخيص الأعطال يشبه أن تكون محققًا: لا تتّهم أحدًا قبل جمع الأدلة. أولًا انظر من يبدو مشبوهًا (get)، اقرأ الشهادات (describe و logs)، وعندها فقط قرّر من المذنب وأصلحه.
- تشخيص الأعطال
- عملية منظّمة لإيجاد سبب العطل: اجمع الأدلة (get, describe, logs)، صُغ فرضية، أصلح، وتحقّق من زوال المشكلة — بدلًا من التخمين.
- Runbook (دليل تشغيل)
- قائمة ثابتة وقابلة للتكرار من الخطوات تتّبعها عند ظهور عطل. تتيح لكل فرد في الفريق أن يشخّص بالترتيب نفسه ولا يتخطّى خطوة حرجة تحت الضغط.
- CrashLoopBackOff
- حالة Pod تبدأ فيها الحاوية بالعمل، تنهار، ويستمر Kubernetes في إعادة المحاولة مع تأخير متزايد بين المحاولات. يكون السبب في معظم الأحيان في شيفرة التطبيق أو إعداداته — اقرأه عبر logs --previous.
- ImagePullBackOff
- حالة يفشل فيها Kubernetes في سحب (pull) الـ image الخاص بالحاوية: اسم أو tag خاطئ، أو الـ image غير موجود في الـ registry، أو نقص في بيانات الاعتماد. يظهر السبب في الـ Events الخاصة بـ describe.
- Pending
- حالة قُبِل فيها الـ Pod لكنه لم يُجدوَل بعد على أي node — عادةً لأنه لا تتوفّر موارد كافية (CPU/الذاكرة)، أو لأن أي node لا يطابق متطلباته.
- Events
- سجلّ قصير لما حاول Kubernetes فعله بالـ Pod (جدول، سحب الـ image، شغّل، فشل). يظهر في أسفل مخرجات kubectl describe pod وهو عادةً الدليل الأول على السبب.
