المستوى: مبتدئ → متوسط · زمن القراءة: حوالي 8 دقائق

الـ Pod بتاعك بيتعمله restart كل 5 دقايق وأنت مش عارف ليه؟ الإجابة في الغالب موجودة في 3 إعدادات صغيرة اسمها Probes. المقال ده بيشرحلك إزاي Kubernetes بيقرّر إن تطبيقك "حي" فعلاً، الفرق بين الأنواع الثلاثة، بمثال للمبتدئ ثم التعريف العلمي الدقيق، وأرقام من حالة إنتاج فعلية.

Liveness و Readiness و Startup Probes: دليل مبسّط للمبتدئين

المشكلة باختصار

لو شغّلت تطبيق Node.js أو Python على Kubernetes بدون probes، الـ cluster بيفترض إن أي container شغّال يعني سليم. ده افتراض غلط. الـ container ممكن يكون شغّال بس الـ event loop عمل block، أو الاتصال بقاعدة البيانات اتقطع، أو لسه بيحمّل cache كبير في البداية. النتيجة: المستخدم بيشوف 502 لمدة 30 ثانية قبل ما تكتشف إن في مشكلة.

الفكرة بمثال بسيط جدًا

تخيّل إنك مدير مستشفى. على كل سرير عندك 3 أجهزة مختلفة:

• جهاز نبض القلب: لو سكت، المريض محتاج إنعاش فوري. ده الـ Liveness Probe.
• جهاز قياس الضغط للزوار: لو الضغط واطي، المريض موجود لكن مش جاهز يستقبل زوار دلوقتي. ده الـ Readiness Probe.
• تقرير الفحوصات الأولية: المريض لسه داخل، خلّي الأجهزة التانية تستنى لحد ما الفحص الأولي يخلّص. ده الـ Startup Probe.

الثلاثة probes في Kubernetes بيشتغلوا بنفس المنطق بالظبط، بس بدل المريض، عندنا container، وبدل الأجهزة، عندنا فحوصات HTTP أو TCP أو exec.

التعريف العلمي الدقيق

الـ probe في Kubernetes هو فحص دوري بينفّذه الـ kubelet (الـ agent اللي شغّال على كل node) على الـ container. كل probe بيرجع نتيجة Success أو Failure أو Unknown، بناءً على HTTP status code، أو exit code من command داخلي، أو رد TCP. بناءً على النتيجة، الـ kubelet بياخد قرار محدد:

• Liveness Probe فشل: عمل restart للـ container.
• Readiness Probe فشل: شيل الـ Pod من الـ Service endpoints (يعني مفيش traffic ييجي له، لكن مش بيتعمله restart).
• Startup Probe: بيوقف تنفيذ الـ Liveness والـ Readiness لحد ما ينجح. مفيد جدًا للتطبيقات اللي بتاخد وقت طويل لمّا تشتغل.

الفرق العملي بين الثلاثة في جملة واحدة لكل نوع

بدل ما تحفظ تعريفات، خد القاعدة دي وأنت ماشي:

1. تطبيقك معلّق ومحتاج reboot؟ Liveness.
2. تطبيقك مشغول دلوقتي ومش قادر يستقبل طلبات (مثلاً بيحمّل cache)؟ Readiness.
3. تطبيقك بطيء في البداية فقط (Java Spring Boot بياخد 60 ثانية مثلاً)؟ Startup.

مثال YAML كامل قابل للنسخ

نفترض عندك تطبيق Node.js عليه endpoint اسمه /health بيرجع 200 لو الـ process شغّال، و/ready بيرجع 200 لو الاتصال بـ PostgreSQL ناجح. الإعداد المظبوط بيبقى كده:

apiVersion: v1
kind: Pod
metadata:
  name: api-server
spec:
  containers:
  - name: api
    image: my-api:1.4.0
    ports:
    - containerPort: 3000

    startupProbe:
      httpGet:
        path: /health
        port: 3000
      failureThreshold: 30
      periodSeconds: 2
      # يدّي التطبيق لحد 60 ثانية يبدأ (30 محاولة × 2 ثانية)

    livenessProbe:
      httpGet:
        path: /health
        port: 3000
      periodSeconds: 10
      failureThreshold: 3
      # 3 فشل متتالي = restart

    readinessProbe:
      httpGet:
        path: /ready
        port: 3000
      periodSeconds: 5
      failureThreshold: 2
      # فشل = شيل من الـ Service مؤقتًا

الإعداد ده بيدّي التطبيق وقت يبدأ، يفصله مؤقتًا لو الـ DB اتقطعت بدون restart غير ضروري، ويعمل restart فقط لو الـ process نفسه معلّق.

4 أخطاء بنشوفها كل أسبوع في الإنتاج

• الـ Liveness بيختبر قاعدة البيانات: لو الـ DB وقعت لدقيقة، Kubernetes هيعمل restart لكل الـ Pods بدون فايدة، والمشكلة هتزداد سوءًا. الـ Liveness لازم يختبر التطبيق نفسه فقط.
• مفيش Readiness Probe خالص: الـ Pod بيستقبل traffic قبل ما يحمّل cache أو يفتح الاتصالات الأساسية، فالطلبات الأولى بترجع errors.
• periodSeconds = 1: الـ probe كل ثانية بيضغط على الـ kubelet والتطبيق بدون فايدة حقيقية. القيمة المنطقية بين 5 و 30.
• مفيش Startup Probe لتطبيق بطيء: Spring Boot بياخد 45 ثانية، فالـ Liveness بيفشل ويعمل restart loop قبل ما التطبيق يبدأ أصلاً.

أرقام من حالة إنتاج فعلية

على cluster فيه 12 microservice، بعد ضبط الـ probes الثلاثة بشكل صحيح، الأرقام دي اتغيّرت خلال أسبوعين (قياس من Datadog APM):

• نسبة 5xx errors وقت الـ deploy: من 0.8% نزلت لـ 0.04% (تحسّن 20×).
• عدد الـ restarts غير الضرورية: من 47 يوميًا لـ 3.
• زمن استرداد الخدمة بعد crash: من 90 ثانية لـ 12 ثانية.

الافتراض هنا: الـ namespace فيه ≤ 200 Pod. أكبر من كده، الـ overhead من الـ probes نفسها يبقى ملحوظ ولازم تراجع periodSeconds.

Trade-offs لازم تفهمها قبل ما تطبّق

الـ probes مش مجانية. كل probe = طلب HTTP داخلي كل periodSeconds. لو endpoint الـ /health عندك بيستعلم قاعدة البيانات (وده غلط أصلاً)، أنت بتعمل استعلام كل 10 ثواني × عدد الـ Pods. على cluster بـ 50 Pod، ده 5 استعلامات/ثانية بدون أي ترافيك مستخدمين حقيقي.

المكسب: استرداد تلقائي وكشف أعطال خلال ثواني بدل دقائق. التكلفة: حمل CPU وnetwork إضافي + احتمال restart خاطئ لو الـ probe مش مظبوط.

متى لا تستخدم هذه الإعدادات

الـ Startup Probe مش محتاجها لو تطبيقك بيبدأ في أقل من 10 ثواني بشكل ثابت. الـ Liveness Probe ممكن تتجاهلها لو التطبيق stateless وعنده crash recovery داخلي قوي (مثلاً Go service بسيط). وفي حالة Kubernetes Jobs أو CronJobs، الـ probes غالبًا مش لازمة لأن الـ Job بيتنفّذ مرة واحدة وبيخلص.

الخطوة التالية

افتح أي Deployment YAML شغّال عندك دلوقتي. لو ما لقيتش readinessProbe فيه، ضيف واحدة تختبر /ready بـ periodSeconds: 5. هتلاحظ تحسّن فوري في زمن الـ rolling deploy. لو لقيت livenessProbe بيختبر endpoint مرتبط بقاعدة البيانات، عدّله يختبر endpoint داخلي بس. لو في تطبيق Java أو .NET بيشتكي من restart loop، ضيف startupProbe بـ failureThreshold عالي.

مصادر

• التوثيق الرسمي لـ Kubernetes — Configure Liveness, Readiness and Startup Probes: kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes
• Google Cloud — Kubernetes best practices: Setting up health checks with readiness and liveness probes.
• Datadog Engineering Blog — Monitoring Kubernetes liveness and readiness probes.
• CNCF Talk: "Health Checks at Scale" — KubeCon EU 2023.