محاكي جاهزية الحاوية وفحوص Kubernetes: مشاريع تخرج هندسة الحاسوب

تحتاج خدمة بدأت للتو وقتاً لقراءة إعداداتها، وقد تتوقف خدمة جاهزة مؤقتاً عن قبول الحركة، بينما قد تتعطل عملية طويلة وتحتاج إعادة تشغيل. هذه حالات مختلفة رغم أنها تظهر أحياناً كلها تحت كلمة «health». مشروع تخرج هندسة الحاسوب يبني محاكياً يوضح الفرق بين startup وreadiness وliveness probes في Kubernetes، ويعرض متى يمرر النظام الحركة ومتى يعيد تشغيل container.

ثلاثة فحوص لأسئلة مختلفة

يتحقق startup probe من انتهاء بدء التطبيق، وreadiness probe من قدرته الحالية على استقبال الطلبات، وliveness probe من حالة تستدعي محاولة إعادة التشغيل. يشرح مرجع Kubernetes الرسمي للـprobes أن كل نوع له غرض مختلف، وأن نجاح startup يسمح ببدء فحوص liveness وreadiness عندما تكون مهيأة. المحاكي يترجم هذه القواعد إلى خط زمني مرئي، لا ينفذ kubelet.

ابدأ بتعريف حالات container: starting، ready، temporarily not ready، unhealthy، restarting. لكل probe نوع وطريقة تحقق وفترة وتوقيت وحد الفشل. اعرض الإعدادات كما هي، ثم سجل نتيجة كل عينة. لا تستخدم كلمة «صحة» بلا وصف؛ أشر هل السؤال عن بدء العملية أو استقبال المرور أو إمكانية التعافي بإعادة تشغيلها.

لا تعاقب بدءاً بطيئاً على أنه فشل دائم

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

أنشئ سيناريوهين: الأول يملك startup probe تكفي نافذته لبدء التطبيق، والثاني يفتقدها ويعيد التشغيل مبكراً. احسب نافذة المحاولات من period وfailureThreshold وinitialDelay وفق نموذج المحاكي، مع الانتباه إلى أن تفاصيل توقيت التنفيذ تعتمد على Kubernetes وإصدارها. الأفضل مقارنة الأحداث التي يولدها cluster تجريبي إن توفر، وتوثيق النسخة بدلاً من وصف الحساب البسيط بأنه توقيت مطابق تماماً في كل ظرف.

الجاهزية ليست سبباً لإعادة التشغيل

قد يكون التطبيق يعمل لكنه غير مستعد مؤقتاً لخدمة المستخدمين، مثلاً أثناء تحميل cache داخلي أو إتمام تهيئة dependency. تذكر وثائق Kubernetes أن Pod غير الجاهز لا يتلقى حركة عبر Service. في نموذج المشروع، تعني فشل readiness تحويل الحالة إلى خارج التوجيه، لا استدعاء restart تلقائياً. أظهر عدد النسخ الجاهزة إن كان السيناريو يحتوي أكثر من pod؛ إخراج نسخة واحدة لا يعني أن الخدمة كلها متوقفة.

أضف اختبار recovery: يفشل probe مرتين، ثم ينجح، فتعود الحاوية إلى ready دون إعادة تشغيل. قارن ذلك بسيناريو liveness الذي يصل إلى حد الفشل ويعيد container. لا تجعل probe تعتمد مباشرة على كل خدمة خارجية إذا كان ذلك يؤدي إلى إخراج كل النسخ عند عطل dependency مشترك؛ هذه سياسة تستحق مراجعة، ولا يقدم المشروع قاعدة واحدة تصلح لكل نظام.

خط زمني لبدء بطيء

مثال اختباري: يستغرق بدء التطبيق 40 ثانية. تعمل startup كل 5 ثوان مع failure threshold يساوي 10، وتبدأ أول نتيجة بعد initial delay يحدده السيناريو. بعد نجاحها يبدأ فحص readiness، ثم يرسل المحاكي حركة افتراضية عند أول جاهزية. هذه الأرقام لشرح التسلسل ولا تحسب مهلة cluster فعلية بدقة. اعرض متى توقف المحاكاة أو أعادت التشغيل، وميّز زمن الانتظار عن زمن تنفيذ الاختبار.

في سيناريو آخر، تبدأ الخدمة خلال 10 ثوان لكنها تفقد القدرة على الاستجابة بعد 3 دقائق. يفشل readiness لبعض الوقت ثم ينجح، بينما liveness لا يفشل. ينبغي أن تبقى العملية دون restart وأن يتوقف إرسال الطلبات إليها مؤقتاً. سيناريو ثالث يعلق فيه التطبيق، فتصل liveness إلى عتبتها ويعاد تشغيله. المقارنة تبين أن probe واحدة لا تجيب وحدها عن كل الحالات.

اختبارات نموذج السلوك

اختبر نجاحاً فورياً، تأخراً، فشلاً متتالياً أقل من threshold، فشلاً عند الحد، نجاحاً بعد إخراج readiness، واستعادة بعد restart. افحص أن startup يوقف الفحصين الآخرين حتى النجاح وفق نموذج الإصدار الذي اخترته. إذا تغير ترتيب حدثين لهما timestamp واحد، ضع قاعدة tie-break معلنة كي تكون إعادة التشغيل قابلة للتكرار.

يتيح Kubernetes فحوصاً عبر HTTP وTCP وexec وغيرها؛ لا تدخل أوامر أو عناوين خارجية يقدمها مستخدم غير موثوق. اجعل المدخلات قائمة اختيار آمنة أو fixtures ثابتة. لا تشغل probe command على الجهاز المضيف. إن بنيت نسخة cluster حقيقية، استخدم namespace مختبراً وصورة بسيطة ومحددة الإصدار، وامسح الموارد بعد الاختبار، وسجل أن المحاكاة والـcluster قد يختلفان.

اعرض المقايضة بدل الشارة الخضراء

المخرجات المفيدة تشمل وقت بداية الخدمة، عدد مرات الفشل، الفترة خارج التوجيه، عدد restart، ووقت عودة الحالة. لا تختزلها إلى «healthy». يمكن مقارنة إعدادين على أثر الحدث نفسه وقياس وقت الوصول إلى ready وعدد إعادة التشغيل. خفف حمل الفحوص؛ كل اختبار متكرر له تكلفة، وإن كان المثال صغيراً. في نظام حقيقي يجب ألا يجعل endpoint الصحي نفسه سبب ضغط جديد.

لا تقارن خدمة ذات بيانات محلية بواحدة تعتمد شبكة ثم تعلن تفوق إعداد probe. اختلاف workload يغير القياس. استخدم baseline ثابتاً وكرر التجربة، واذكر حدود المحاكي: لا يمثل ضغط CPU الفعلي أو انقطاع node أو جميع تفاصيل controller وservice routing.

مخرجات مشروع التخرج

يسلم الفريق آلة حالات، إعدادات YAML آمنة للقراءة، أثر أحداث قابل للإعادة، واختبارات تقارن سياسة probe. تلائم الفكرة مشاريع تخرج هندسة الحاسوب ويمكن ضبطها مع خدمة مشاريع التخرج وتطوير تطبيقات الويب إذا كانت الواجهة تعرض السيناريو. لا تتصل بالـcluster الإنتاجي ولا تغير إعداداته.

يقدم دليل الإعداد الرسمي ملفات أمثلة وأوامر يمكن مراجعتها في بيئة تدريبية، ويشرح مرجع دورة حياة Pod حالات الحاوية والـPod. استخدمهما لتثبيت نطاق النسخة، ولا تعتبر نتائج simulator إثباتاً لسلوك cluster لم تختبره.