فحص العنقود واستكشاف أخطائه وإصلاحها

قد لا يعمل نشرُك الأول كما ينبغي أحيانًا. والخبر الجيد هو أن kubectl يوفر كل ما تحتاج إليه لمعرفة ما يحدث وإصلاحه بطريقة منهجية.

ابدأ بنظرة عامة. هل عقد المجموعة سليمة وحالتها Ready؟

افحص مراحل Pods. تُعد Running حالة جيدة؛ بينما تشير Pending وCrashLoopBackOff وImagePullBackOff إلى مشكلات محددة.

يُعد kubectl describe أفضل مساعد لك؛ إذ يعرض المواصفات والحالة الحالية وقائمة Events التي تشرح إخفاقات الجدولة وسحب الصور.

تظهر أخطاء التطبيقات عادةً في السجلات. اعرضها بشكل متتابع باستخدام -f، أو اقرأ السجلات السابقة لحاوية متوقفة باستخدام --previous.

إذا استمر Pod في إعادة التشغيل، فلن تحتوي الحاوية الحالية على سجلات مفيدة بعد. اعرض سجلات النسخة السابقة بدلاً من ذلك.

افتح shell داخل حاوية قيد التشغيل لفحص الملفات ومتغيرات البيئة والاتصال من داخلها.

اعرض الأحداث الأخيرة عبر namespace، مرتبة حسب الوقت، لاكتشاف الأنماط التي قد لا تظهر في العرض الخاص بكل Pod.

يعني هذا أن Kubernetes لا يستطيع سحب الصورة: قد يكون الاسم أو الوسم خاطئاً، أو قد يكون المستودع الخاص بلا بيانات اعتماد، أو قد يوجد خطأ مطبعي. يعرض describe خطأ السحب الدقيق.

تبدأ الحاوية ثم تخرج بشكل متكرر. تحقّق من logs --previous لمعرفة سبب التوقف، والذي يكون غالباً أمراً خاطئاً أو إعداداً مفقوداً أو تبعية فاشلة.

استخدم kubectl top لعرض استخدام CPU والذاكرة مباشرةً (ويتطلب ذلك metrics-server)، واستخدم port-forward لاختبار خدمة مباشرةً من جهازك.

شخّص سبب إعادة تشغيل Pod.

أصبحت لديك الآن مجموعة أدوات لاستكشاف الأخطاء وإصلاحها:

• استخدم get nodes/pods للتحقق من السلامة، وdescribe لعرض الأحداث
• استخدم logs (و--previous) للبحث عن أخطاء التطبيق
• استخدم exec للفحص من الداخل، وport-forward للاختبار
• تعرّف على حالتي ImagePullBackOff وCrashLoopBackOff

وعادةً ما يكشف الفحص الهادئ والمنهجي لهذه العناصر المشكلة بسرعة.