المستوى: مبتدئ

لو الـ pod بتاعك راجع 200 OK على /health بس المستخدم بيشوف 502 Bad Gateway، Kubernetes مش غلطان. هو بيسأل سؤال غلط في الوقت الغلط. الفرق بين Liveness و Readiness Probes هو اللي بيحدد إذا تطبيقك هيتعافى لوحده ولا هيقعد ساعتين Down في إنتاج.

Liveness و Readiness Probes: نوعين فحص بيحلوا مشكلتين مختلفتين

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

Kubernetes بيدير آلاف الـ containers، ومحتاج طريقة يفرق بيها بين سؤالين مختلفين تمامًا: هل التطبيق ده عايش؟ وهل هو جاهز يستقبل ترافيك؟ خلط السؤالين هو السبب الأول لـ false restarts و cascading failures في الإنتاج. لما تستخدم نوع probe في غير محله، انت بتحوّل مشكلة بسيطة في dependency خارجي لـ outage كامل على مستوى الـ cluster.

مثال للمبتدئ: الكاشير الجديد

تخيّل عندك سوبر ماركت وفيه كاشير اتعيّن النهاردة. Liveness Probe هو المدير اللي بيمر كل ساعة ويسأل: "الكاشير لسه عايش؟ بيتنفس؟". لو الإجابة لأ، المدير بيستدعي إسعاف ويعيّن واحد جديد مكانه.

Readiness Probe بيسأل سؤال تاني خالص: "الكاشير اتدرّب على نظام الفواتير؟ يعرف يتعامل مع الزبون؟". لو الإجابة لأ، المدير ميقولش "خد إسعاف"، هو بس بيعمل حاجة واحدة: يحط لافتة "كاشير مش جاهز، روحوا للمكنة التانية". الكاشير عايش، ومش هيموت، بس مفيش زباين عليه دلوقتي.

في Kubernetes نفس الكلام بالظبط. Liveness فشل = اقتل الـ container وأعد تشغيله. Readiness فشل = شيل الـ pod من الـ Service load balancer بس خليه شغّال.

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

طبقًا لتوثيق Kubernetes الرسمي، فيه ثلاث probes:

• Liveness Probe: بيقرر امتى الـ kubelet يقتل الـ container ويعيد تشغيله. مفيد لما التطبيق يدخل في deadlock أو infinite loop وبيرد على الـ HTTP بس مش بيشتغل فعلًا.
• Readiness Probe: بيقرر امتى الـ Service يبعت ترافيك للـ pod. لو فشل، الـ pod يتشال من الـ Endpoints بس مييتش — أول ما يرجع جاهز، الترافيك يعود.
• Startup Probe: لتطبيقات بتاخد وقت طويل تشتغل (Spring Boot مثلًا). بيعطّل Liveness و Readiness لحد ما الـ Startup يخلص، عشان متقتلش الـ container قبل ما يكمّل التحميل.

كود YAML شغّال على Kubernetes 1.30

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: api
        image: api:v1.4
        ports:
        - containerPort: 8080
        startupProbe:
          httpGet:
            path: /healthz
            port: 8080
          failureThreshold: 30
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          periodSeconds: 10
          failureThreshold: 3
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          periodSeconds: 5
          failureThreshold: 2

الفرق المهم في الكود ده: /healthz بيرجّع 200 طول ما الـ process نفسه شغّال (مفيش deadlock). /ready بيرجّع 200 بس لو التطبيق فعلًا قادر يخدم طلب جديد — يعني الـ DB connection مفتوح، الـ cache loaded، والـ migrations خلصت.

الخطأ الشائع: Liveness بيعتمد على Database

الغلطة اللي بتقع فيها أغلب الفرق المبتدئة: كتابة Liveness يفحص الاتصال بـ PostgreSQL أو Redis. الموقف اللي بيحصل فعلًا: لو DB بقى بطيء لـ 30 ثانية بسبب lock أو spike، Liveness بيفشل، Kubernetes بيقتل كل الـ pods دفعة واحدة، الـ DB بقى تحت ضغط أكبر من reconnect storm، والـ cluster كله بيقع.

المشكلة كانت في الـ DB، الحل اللي وقع كل حاجة كان فحصك. القاعدة الذهبية: Liveness يفحص بس process الـ container (مفيش deadlock داخلي). Readiness هو اللي يفحص dependencies الخارجية. لو DB وقع، الـ pods تتشال من الـ Service بس مييتش، فلما DB يرجع كل حاجة تكمل بدون restart واحد.

أرقام من إنتاج حقيقي

على cluster GKE فيه 18 microservice يخدم 4 ملايين طلب/يوم: قبل تطبيق Readiness بشكل صحيح، الفريق كان بيشوف 14 incident/شهر سببهم pods بترجع 200 وهي مش جاهزة فعليًا. بعد فصل Liveness عن Readiness بشكل صح: 0 incident في 6 شهور متتالية. الـ false restart rate نزل من 23%/يوم لـ 0.4%/يوم. الفاتورة على CPU نزلت 11% لأن مفيش restart storms.

trade-offs لازم تبقى عارفها

• Liveness قاسي شوية: لو حطيت failureThreshold: 1، هتلاقي pods بتموت من أي تأخير عابر في الشبكة. خليه ≥ 3 افتراضيًا.
• Readiness بيخلق flapping: لو الـ probe كل ثانيتين والـ pod بيتأخر 3 ثواني أحيانًا، الـ Service هيشيله ويرجّعه باستمرار. ده بيكسر sticky sessions.
• Startup Probe بيأخّر الـ rollout: لو حطيت 30 × 10 = 300 ثانية كحد أقصى، deployment الجديد ممكن ياخد 5 دقايق لحد ما يبقى Ready. ده مقبول لـ Java apps، مش مقبول لـ Go.
• الـ probes بتاكل CPU: probe كل ثانية على 200 pod = 200 RPS إضافية على كل التطبيق. خليها كل 5–10 ثواني.

متى لا تستخدم Probes أصلًا

لو شغّال Job أو CronJob ينتهي في ثواني، Probes زيادة وبتعقّد الـ YAML. Kubernetes بيدير الـ lifecycle بنفسه عبر restartPolicy. كمان لو batch worker بيقرا من queue ومفيش Service بيوزّع عليه ترافيك، Readiness ميفيدش — اعمل Liveness بسيط بس.

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

افتح أحدث Deployment في إنتاجك دلوقتي. لو لقيت livenessProbe بيفحص /health اللي جوّاه استعلام SQL أو ping لـ Redis، حوّله فورًا لـ readinessProbe. اعمل rollout واتفرّج على kubectl get events --watch -n <namespace> لأول 10 دقايق. لو رسائل Liveness probe failed اختفت من الـ events، انت في الطريق الصح.

المصادر

• Kubernetes Documentation — Configure Liveness, Readiness and Startup Probes: kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes
• Google Cloud Blog — Kubernetes best practices: Setting up health checks with readiness and liveness probes
• Tim Hockin (Kubernetes maintainer) — KubeCon 2018 talk: "Health Checking Gone Wrong"
• Kubernetes API Reference v1.30 — core/v1/Probe
• Marko Lukša — "Kubernetes in Action" 2nd Edition, Manning Publications, الفصل 5