مستوى المقال: مبتدئ
لو بتعمل rolling update لخدمتك على Kubernetes ولاحظت إن users بيشوفوا 502 و 500 في أول 20 ثانية بعد كل deploy، المشكلة مش في الكود ولا في الـ load balancer. Kubernetes بيوجّه ترافيك على pod قبل ما الـ app جواه يخلّص استعداد، وفيه طريقتين بيقولوا للـ cluster "أنا جاهز" و "أنا لسه عايش": Readiness Probe و Liveness Probe. المقال ده هيوريك ازاي تستخدمهم بـ 12 سطر YAML وتنزّل الأخطاء دي للصفر تقريباً.
المشكلة باختصار
عندك خدمة Node.js بتاخد 12 ثانية تحمّل الـ config وتفتح connection pool لـ PostgreSQL ولـ Redis. لما الـ pod الجديد يبدأ في deployment جديد، Kubernetes افتراضياً بيعتبره "ready" بمجرد ما الـ container process يبدأ يشتغل. الـ Service بيبدأ يبعت ترافيك عليه فوراً، فأول الطلبات بتدخل على app لسه بيبوت وبيرجّع 500 لأن الـ DB pool لسه ما اتفتحش.
الـ Probes بتحلّ المشكلة دي عن طريق سؤالين مختلفين بتسألهم Kubernetes للـ container. الـ Readiness Probe بيسأل: "هل أنت جاهز تستقبل ترافيك دلوقتي؟". الـ Liveness Probe بيسأل: "هل أنت لسه عايش، وللا محتاج restart؟". الاتنين سؤالين مختلفين، والإجابة بتفرق في القرار اللي بياخده الـ cluster.
مثال للمبتدئ: محل الكشري
تخيّل محل كشري بيفتح الساعة 12 الضهر. لو الباب اتفتح 11:55 (الباب مفتوح = Kubernetes شايف الـ container شغّال)، الزبائن هيدخلوا. بس الطباخ لسه بيسخّن الزيت ويسلق الأرز. الزبون يطلب، يستنّى دقيقتين، وفي الآخر يطلع زعلان لأن الأكل مش جاهز.
الـ Readiness Probe هنا = لافتة "Open" اللي الطباخ بيعلّقها بإيده لما الأكل يستوي فعلاً. لما اللافتة تتشال (الـ probe بيفشل)، الزبون الجديد بيتحوّل لفرع تاني، بس المحل ما اتقفلش. الـ Liveness Probe = موظف الإدارة اللي بيمر كل ساعة يطمئن إن الطباخ مش نايم. لو الطباخ نايم (الـ probe بيفشل)، الإدارة بتجيب طباخ بديل (Kubernetes يعمل restart للـ container).
الفرق بين الاتنين بسيط لكنه حاسم: لافتة Open بتشال مؤقتاً، الطباخ البديل بيتجاب لما الأصلي يقع نهائياً. لو خلطت بين الاتنين، هتعمل restart للمحل كل ما الأكل يخلص، وهي حاجة طبيعية.
الفرق التقني بين Liveness و Readiness و Startup
التلاتة عبارة عن check بيتنفذ على فترات منتظمة، والفرق في رد فعل الـ cluster لما الـ check يفشل:
- Liveness Probe بيفشل → kubelet بيعمل restart للـ container. مفيد للحالات اللي الـ app فيها deadlock أو وقف يستجيب بدون ما يموت رسمياً.
- Readiness Probe بيفشل → kube-proxy بيشيل الـ pod من الـ Service endpoints. الـ container ميتعملوش restart، بس الترافيك بيتحوّل لباقي الـ replicas.
- Startup Probe بيشتغل مرة واحدة بس قبل التانيين، مفيد لو الـ app بتاخد وقت طويل في الـ boot (أكتر من 30 ثانية). طول ما الـ Startup شغّال، Liveness و Readiness بيكونوا موقوفين.
