Kubernetes Liveness و Readiness و Startup Probes: لماذا ليست كلها Health Check واحدة؟

جاهز لا تعني حيًا فقط

قد يكون التطبيق يعمل لكنه ينتظر قاعدة البيانات أو تحميل cache ولا ينبغي أن يستقبل طلبات. Readiness تعبر عن القدرة على خدمة الترافيك الآن.

كيف تسبب probes مشكلة؟

فحص ثقيل أو timeout قصير قد يصنع restarts أثناء ضغط طبيعي. يجب أن يكون endpoint بسيطًا ويعكس الحالة التي يهم ال ـorchestrator اتخاذ قرار بشأنها.

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

Liveness probe تسأل إن كانت الحاوية بحاجة إلى إعادة تشغيل عند توقفها عن العمل بصورة لا تتعافى ذاتيًا. Readiness probe تحدد إن كانت جاهزة لاستقبال طلبات عبر Service في اللحظة الحالية. Startup probe تمنح التطبيق البطيء وقتًا مناسبًا للإقلاع قبل تفعيل فحوص أخرى. الخلط بينها يؤدي إلى إزالة الخدمة من الترافيك بلا داع أو إلى إعادة تشغيلات متكررة قد تضخم عطلًا مؤقتًا في قاعدة البيانات.

سيناريو قاعدة بيانات بطيئة

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

كيف تحدد توقيت الفحص دون أرقام منسوخة؟

اضبط periodSeconds و timeoutSeconds و failureThreshold بالاعتماد على زمن الاستجابة المعتاد وأسوأ ظروف الإقلاع والحمل. لا تستخدم مهلة قصيرة جدًا لفحص يشمل طلبًا شبكيًا تحت ضغط، ولا تجعل المهلة طويلة بحيث يبقى Pod معطوبًا يقبل الترافيك. عند وجود startup probe يجب أن تغطي نافذتها إقلاعًا بطيئًا مشروعًا، ثم يبدأ سلوك الفحوص الأخرى على النحو الموثق. قِس حالات الفشل الحقيقية بدل اختيار أرقام عشوائية.

اختبار endpoint صحي خفيف

ينبغي أن يرد endpoint الخاص بالفحص بسرعة ويعكس السؤال المقصود دون تنفيذ استعلامات مكلفة أو تغيير البيانات. قد تعتمد readiness على توفر مجموعة محددة من الاعتماديات الأساسية وفق تصميم التطبيق، بينما تكتفي liveness بتحديد أن الحلقة الرئيسية ما زالت تعمل. إذا كان البرنامج يدعم أمر exec محليًا أو فحص TCP وفق حالته، فاختر الطريقة الأنسب مع الانتباه إلى أن فتح المنفذ لا يثبت سلامة الوظائف التطبيقية.

مراقبة أثر الفحوص في الإنتاج

سجّل عدد مرات فشل probes وإعادة تشغيل الحاويات والوقت الذي تقضيه النسخ خارج Service endpoints، واربطها بمعدلات الخطأ الفعلية للمستخدمين. راقب استخدام CPU والذاكرة وتغير السلوك بعد النشر؛ فال ـProbe نفسها قد تستهلك موارد وتصبح جزءًا من المشكلة. إذا ارتفعت restarts عقب تغيير الإعداد، راجع سجل الأحداث وتوقيت الخطأ بدل افتراض أن المشكلة في التطبيق وحده.

خطوات مراجعة قبل اعتماد الإعداد

اختبر الإقلاع البارد، ثم توقفًا مؤقتًا في الاعتماد الخارجي، ثم تعليقًا فعليًا في العملية ضمن بيئة معزولة. تأكد أن readiness تزيل النسخة غير الجاهزة، وأن liveness تتدخل فقط حين تكون إعادة التشغيل علاجًا صحيحًا، وأن startup لا تعاقب الإقلاع المشروع. وثّق إعداد كل Probe وأثره وسبب حدوده، ولا تترك قيمًا منسوخة لا تتوافق مع حمل الخدمة.