How-To Guides

إتقان استكشاف أخطاء وحدات Kubernetes: دليل شامل للمطورين

تشغيل الحاويات في بيئة الإنتاج أمر واحد؛ والحفاظ على عملها بشكل موثوق هو أمر آخر. بالنسبة للمطورين من المستوى المتوسط إلى المتقدم، فإن مواجهة وحدة متوقفة عن العمل أو غير مستجيبة في مجموعة عمل Kubernetes ليست مجرد إزعاج، بل هي حرجة تتطلب حلاً سريعاً ومنهجياً. سواء كنت تتعامل مع أخطاء CrashLoopBackOff، أو فشل سحب الصور، أو انقطاع الاتصال بالشبكة، فإن امتلاك نهج منهجي لتصحيح الأخطاء أمر ضروري.

يتجاوز هذا الدليل بناء الجملة الأساسي وينطلق في سير العمل العملي لتشخيص وإصلاح المشكلات الشائعة لوحدات Kubernetes. في النهاية، ستحصل على نموذج عقلي قوي لعزل الأعطال داخل دورة حياة الحاوية.

الخطوة 1: التحقق من حالة الوحدة والأحداث

الخطوة الأولى في أي جلسة استكشاف للأخطاء هي فهم الحالة الحالية للعملية. لا تبدأ أبداً بالغوص في السجلات دون معرفة سبب دخول الوحدة إلى حالتها الحالية. يعطيك الأمر kubectl get pods نظرة عامة على الحالة، لكنه غالباً ما يكون غير كافٍ للتشخيص العميق.

بدلاً من ذلك، قم دائماً برفق هذا الأمر بـ kubectl describe pod. يوفر هذا الأمر إخراجاً مفصلاً يتضمن أحداث الوحدة، وهي ضرورية لفهم إجراءات المجدف وأسباب الفشل.

# التحقق من الحالة العامة للوحدات في مساحة الاسم 'default'
kubectl get pods -n default

# الحصول على معلومات مفصلة حول وحدة محددة، بما في ذلك الأحداث
kubectl describe pod my-app-pod-xyz123 -n default

انظر عن كثب إلى قسم الأحداث في أسفل الإخراج. هل ترى FailedScheduling؟ هذا يشير عادةً إلى قيود الموارد (طلبات وحدة المعالجة المركزية/الذاكرة) أو مشكلات ارتباط العقدة. هل ترى ImagePullBackOff؟ هذا يشير إلى مشكلة في مصادقة سجل الصور أو خطأ مطبعي في وسم الصورة. معالجة هذه المشكلات من المستوى الأول غالباً ما تكون أسرع من الغوص في سجلات التطبيق.

الخطوة 2: فحص سجلات الحاوية

بمجرد التأكد من أن الوحدة في حالة تشغيل (أو أنها تعطلت للتو)، تكون الخطوة المنطقية التالية هي فحص مخرجات التطبيق. تجمع Kubernetes مخرجات stdout و stderr من نقطة الدخول للحاوية في سجلات يمكن الوصول إليها.

استخدم kubectl logs لبث السجلات أو تصديرها. إذا كانت الوحدة في حالة CrashLoopBackOff، فهذا يعني أن الحاوية بدأت، واجهت خطأً، ثم خرجت. يجب عليك فحص السجلات من المثال السابق للحاوية.

# عرض السجلات للنسخة الحالية قيد التشغيل
kubectl logs my-app-pod -n default

# عرض السجلات من نسخة الحاوية السابقة إذا تعطلت
kubectl logs my-app-pod --previous -n default

عند تحليل هذه السجلات، ابحث عن آثار المكدس، والأخطاء القاتلة، أو استثناءات التكوين. إذا كانت السجلات فارغة، فقد تكون الحاوية عالقة في حلقة لا نهائية أو في انتظار إشارة، مما يتطلب مزيداً من التحقيق عبر الأمر exec.

الخطوة 3: التصحيح التفاعلي باستخدام Exec

في بعض الأحيان، لا تكفي السجلات. قد تحتاج إلى فحص نظام الملفات، أو التحقق من متغيرات البيئة، أو اختبار الاتصال بالشبكة من داخل سياق الحاوية. هنا يصبح kubectl exec أقوى أدواتك.

# فتح قشرة bash في الحاوية قيد التشغيل
kubectl exec -it my-app-pod -- /bin/bash

# التحقق من متغيرات البيئة
printenv

# اختبار الاتصال بخدمة خارجية أو قاعدة بيانات
curl -v http://internal-service:8080/health

# سرد الملفات للتحقق مما إذا تم تحميل خرائط التكوين بشكل صحيح
ls -la /etc/config

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

الخطوة 4: التحقق من قيود الموارد

أحد الأسباب الشائعة لوفاة الوحدات الصامتة هو الوصول إلى حدود الموارد. إذا تجاوزت الحاوية حدود وحدة المعالجة المركزية أو الذاكرة، فقد يقوم قاتل الذاكرة (OOM Killer) في نواة Linux بإنهائها دون توفير الكثير من السياق في سجلات التطبيق.

تحقق من استخدام الموارد باستخدام:

kubectl top pod my-app-pod

قارن الاستخدام المبلغ عنه مع resources.limits المحددة في ملف تعريف YAML الخاص بك. إذا كان الاستخدام قريباً باستمرار من الحد، فقد تحتاج إلى التوسع أفقياً أو تعديل الحدود. بالإضافة إلى ذلك، تحقق من سجلات النظام على العقدة الأساسية (عبر journalctl على عقد Linux) للبحث عن رسائل قاتل الذاكرة إذا كانت الوحدة تعاد تشغيلها بشكل متكرر.

الخاتمة

استكشاف أخطاء وحدات Kubernetes يتعلق أقل بحفظ الأوامر في الذاكرة وأكثر باتباع مسار تشخيصي منطقي: الحالة → الأحداث → السجلات → الفحص الداخلي → الموارد. من خلال إتقان هذه الخطوات الأربع، يمكنك عزل الأعطال بكفاءة، وتقليل متوسط وقت الإصلاح (MTTR)، والحفاظ على استقرار تطبيقاتك الحاوية. تذكر أن Kubernetes يوفر جميع الأدوات التي تحتاجها؛ عليك فقط معرفة كيفية استخدامها بالترتيب الصحيح.

Share: