لا يستطيع Kubernetes رؤية ما بداخل تطبيقك. إن تُرك وشأنه، يعدّ الـ container سليمًا ما دامت عمليته تعمل، حتى لو كانت تلك العملية عالقة في deadlock، أو ما زالت تسخّن، أو عاجزة عن الوصول إلى قاعدة البيانات. الـ probes (الفحوص) هي طريقة التطبيق لقول الحقيقة عن نفسه. لكن يجب صياغة هذه الحقيقة بعناية، لأن Kubernetes يتصرّف بناءً عليها تلقائيًا وعلى نطاق واسع.
\n| الـ Probe | \nالسؤال الذي يجيب عنه | \nحين يفشل | \n
|---|---|---|
| startup | \nهل انتهى التطبيق من البدء؟ | \nواصل الانتظار حتى الحدّ، ثم أعِد التشغيل | \n
| readiness | \nهل يجب أن يستقبل هذا الـ Pod حركة الآن؟ | \nأزِل الـ Pod من endpoints الـ Service؛ دون إعادة تشغيل | \n
| liveness | \nهل العملية عالقة بلا أمل في التعافي؟ | \nأعِد تشغيل الـ container | \n
ما دام startup probe مضبوطًا ولم ينجح بعد، لا يعمل الاثنان الآخران. وحالما ينجح، لا يعمل مرة أخرى أبدًا لذلك الـ container.
\nلدى notes-api أصلًا المساران (endpoints) اللذان يحتاج إليهما هذا. /healthz يُرجع ok إذا كانت حلقة الأحداث (event loop) تستطيع الإجابة عن طلب أصلًا. و/readyz يفحص أيضًا مجمّع اتصالات قاعدة البيانات ويُرجع 503 إذا تعذّر الوصول إلى Postgres.
- name: api\n image: ghcr.io/skylane/notes-api:1.4.0\n ports:\n - name: http\n containerPort: 3000\n startupProbe:\n httpGet:\n path: /healthz\n port: http\n periodSeconds: 2\n failureThreshold: 30 # up to 60 s to start\n readinessProbe:\n httpGet:\n path: /readyz\n port: http\n periodSeconds: 5\n failureThreshold: 2\n livenessProbe:\n httpGet:\n path: /healthz\n port: http\n periodSeconds: 10\n timeoutSeconds: 2\n failureThreshold: 3أي حالة HTTP من 200 إلى 399 تُعدّ نجاحًا. وإلى جانب httpGet توجد probes من نوع tcpSocket وgrpc وexec؛ فضّل HTTP لخدمات الويب، لأنه يختبر المسار الذي تسلكه الحركة الحقيقية. القيم الافتراضية، إن تركت الحقول، هي periodSeconds: 10 وtimeoutSeconds: 1 وfailureThreshold: 3. مهلة الثانية الواحدة تفاجئ التطبيقات البطيئة، فاضبطها عن قصد.
الـ readiness هو الـ probe الأهمّ في العمل اليومي. الـ Pod الذي يبدأ، أو المُثقل، أو المقطوع عن قاعدة بياناته يُبلغ بأنه غير جاهز ويخرج من endpoints الـ Service حتى يتعافى. وهو أيضًا بوّابة للـ rollouts: لا يُحسب الـ Pod الجديد متاحًا إلا حين يصبح جاهزًا، ولا يزيل التحديث المتدرّج الـ Pods القديمة إلا بقدر ما تصبح الجديدة متاحة. الإصدار الذي لا يصل إلى قاعدة البيانات لا يأخذ الحركة أبدًا من إصدار يصل إليها. لهذا فإن الـ Deployment الذي لا readiness probe فيه هو أول ما أنبّه عليه في كل مراجعة.
\n\nقبل وجود الـ startup probes، كانت التطبيقات بطيئة البدء تُحمى بـ initialDelaySeconds على الـ liveness. هذا يؤخّر الفحص الأول في كل بدء بمقدار أسوأ زمن بدء، وينكسر مجددًا حين يصبح البدء أبطأ. أما الـ startup probe فيعطي التطبيق periodSeconds × failureThreshold (هنا 2 × 30 = 60 ثانية) لينهض، مع فحص متكرّر حتى يُكتشف البدء السريع بسرعة، ثم يسلّم الأمر إلى الـ liveness بوتيرته العادية.
حين يُحذف Pod، أثناء rollout أو تقليص للنسخ أو تفريغ لـ node، يبدأ شيئان في الوقت نفسه: يُزال الـ Pod من endpoints الـ Service، ويبدأ الـ kubelet في إنهاء الـ container. إزالة الـ endpoints يجب أن تنتشر إلى قواعد الشبكة في كل node وإلى أي موازن أحمال، وهذا يستغرق لحظة. إذا توقّف تطبيقك عن قبول الاتصالات لحظة وصول SIGTERM، فالطلبات الموجّهة إليه في تلك اللحظة تُرفض.
\nللحل نصفان. في مواصفات الـ Pod، توقّف قبل SIGTERM حتى يلحق التوجيه بالتغيير:
\n spec:\n terminationGracePeriodSeconds: 30\n containers:\n - name: api\n lifecycle:\n preStop:\n sleep:\n seconds: 5الإجراء sleep يعمل داخل الـ kubelet، فيعمل حتى في image من نوع distroless لا تحتوي على ملف sleep التنفيذي. وفي التطبيق، أبقِ معالج SIGTERM من الدرس 1.4: توقّف عن قبول اتصالات جديدة، وأنهِ الطلبات الجارية، وأغلق مجمّع اتصالات قاعدة البيانات، ثم اخرج. يجب أن يتّسع توقّف preStop والتفريغ معًا داخل terminationGracePeriodSeconds، وإلا فسيرسل الـ kubelet إشارة SIGKILL عند انتهاء المهلة.
يعرف Kubernetes الآن متى يكون notes-api سليمًا وكيف يوقفه بأمان. التالي: يحتاج إلى معرفة كم يستهلك notes-api من المعالج والذاكرة، وكيف يضيف Pods حين تنمو الحركة.
\n","toc":[{"id":"sec-1","text":"ثلاثة probes، وثلاث عواقب","level":2},{"id":"sec-2","text":"الـ Readiness مفتاح للحركة","level":2},{"id":"sec-3","text":"البدء دون حلقات إعادة تشغيل","level":2},{"id":"sec-4","text":"الإيقاف دون إسقاط الطلبات","level":2}],"takeaways":["فشل الـ readiness probe يزيل الـ Pod من endpoints الـ Service؛ وفشل الـ liveness probe يعيد تشغيل الـ container؛ والـ startup probe يؤجّل الاثنين حتى يكتمل بدء التطبيق.","الـ liveness يفحص فقط هل العملية نفسها عالقة؛ لا تجعله أبدًا يعتمد على قاعدة بيانات أو خدمة أخرى.","الـ readiness بوّابة للتحديثات المتدرّجة، فالإصدار الجديد العاجز عن الخدمة لا يحلّ أبدًا محلّ إصدار يعمل.","عند الحذف، تحدث إزالة الـ endpoints وإرسال SIGTERM في الوقت نفسه؛ وتوقّفpreStop قصير يتيح للحركة أن تنصرف عن الـ Pod قبل أن يبدأ التطبيق بالإيقاف.","يجب أن ينهي التطبيق العمل الجاري خلال terminationGracePeriodSeconds (30 افتراضيًا)، وإلا فسيُقتل."],"further":[{"title":"Liveness, Readiness, and Startup Probes","url":"https://kubernetes.io/docs/concepts/configuration/liveness-readiness-startup-probes/"},{"title":"Configure Liveness, Readiness and Startup Probes","url":"https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/"},{"title":"Pod Lifecycle (termination of Pods)","url":"https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination"}],"quiz":[{"q":"يبدأ الـ readiness probe لـ notes-api بالفشل على أحد الـ Pods لأنه لا يصل إلى Postgres. ماذا يفعل Kubernetes؟
","options":[{"text":"يعيد تشغيل الـ container حتى ينجح الفحص.","why":"إعادات التشغيل تأتي من إخفاقات الـ liveness. الـ readiness يؤثّر في الحركة فقط."},{"text":"يحذف الـ Pod ويُجدوِل واحدًا جديدًا على node آخر.","why":"الـ probes لا تحذف الـ Pods أبدًا. يبقى الـ Pod في مكانه."},{"text":"لا شيء حتى يفشل الـ liveness probe أيضًا.","why":"الـ readiness يتصرّف وحده، باستقلال عن الـ liveness."},{"text":"يزيل الـ Pod من endpoints الـ Service، فلا يحصل على حركة جديدة حتى ينجح الفحص مجددًا.","why":"صحيح. يستمر الـ Pod في العمل ويعود إلى التناوب حالما يصبح جاهزًا، دون إعادة تشغيل."}],"answer":3},{"q":"الـ liveness probe لديك يستدعي /readyz، الذي يفحص قاعدة البيانات. يُعاد تشغيل Postgres لمدة 20 ثانية. ماذا يحدث؟
يستغرق notes-api حتى 60 ثانية ليبدأ على قاعدة بيانات كبيرة لأنه يسخّن cache. أي إعداد للـ probes يتجنّب حلقة إعادة التشغيل دون إبطاء اكتشاف الأعطال لاحقًا؟
","options":[{"text":"initialDelaySeconds: 60 على الـ liveness probe.","why":"يعمل، لكن كل بدء ينتظر الآن 60 ثانية قبل أن يعمل الـ liveness أصلًا، وينكسر مجددًا حين يستغرق البدء 65 ثانية."},{"text":"احذف الـ liveness probe.","why":"عندها لن يُعاد تشغيل العملية العالقة في deadlock أبدًا."},{"text":"startup probe مع periodSeconds: 5 وfailureThreshold: 15، فيحصل التطبيق على ما يصل إلى 75 ثانية للبدء قبل أن يتولّى الـ liveness.","why":"صحيح. يُؤجَّل الـ liveness والـ readiness حتى ينجح الـ startup probe مرة واحدة؛ وبعدها يعمل الـ liveness بوتيرته العادية."},{"text":"timeoutSeconds: 60 على الـ liveness probe.","why":"هذا يسمح لفحص واحد بالتعليق لمدة دقيقة، فيؤخّر اكتشاف حالات التعليق الحقيقية ولا يحلّ مشكلة البدء."}],"answer":2},{"q":"خلال كل rollout تفشل بضعة طلبات إلى notes-api بـ connection refused، مع أن التطبيق يعالج SIGTERM. ما الحل المعتاد؟
terminationGracePeriodSeconds إلى 300.","why":"التطبيق يتوقّف أصلًا خلال مهلة السماح. الأخطاء تحدث في بداية الإنهاء، لا في نهايته."},{"text":"أضف توقّف preStop لبضع ثوانٍ حتى تنتشر إزالة الـ endpoints قبل أن يتوقّف التطبيق عن قبول الاتصالات.","why":"صحيح. SIGTERM وإزالة الـ endpoints يحدثان بالتوازي؛ والتوقّف القصير يتيح للـ proxies أن تتوقّف عن توجيه الحركة إلى الـ Pod أولًا."},{"text":"اضبط replicas: 1 أثناء الـ rollouts.","why":"نسخ أقل تجعل أي اتصال ساقط أكثر إيلامًا، لا أقل."},{"text":"عطّل الـ readiness probe أثناء الـ rollouts.","why":"الـ readiness هو ما يُبقي الـ Pods غير الجاهزة خارج التناوب؛ وتعطيله يجعل الـ rollouts أسوأ."}],"answer":1}],"exercise":{"kind":"choice","multiple":false,"options":["startup","initial-delay","no-liveness","liveness-readyz"],"correct":["startup"],"title":"حلقة إعادة التشغيل مع قواعد البيانات الكبيرة","prompt":"بعد أن كبرت قاعدة بيانات أحد العملاء، صار تسخين الـ cache عند بدء notes-api يستغرق حتى 90 ثانية. الـ liveness probe على /healthz يستخدم القيم الافتراضية (periodSeconds: 10 وfailureThreshold: 3)، فتُقتل الـ Pods عند نحو 30 ثانية ولا تنتهي من البدء أبدًا. معالج /healthz لا يُسجَّل إلا بعد اكتمال التسخين. أي تغيير هو الحل الأفضل؟
periodSeconds × failureThreshold؟"],"explanation":"الـ startup probe يؤجّل الـ liveness والـ readiness حتى ينجح مرة واحدة. مع periodSeconds: 5 وfailureThreshold: 24 يحصل notes-api على ما يصل إلى 120 ثانية للتسخين، ويُكتشف أنه بدأ خلال 5 ثوانٍ من انتهائه، ومن بعدها يعمل الـ liveness بوتيرته العادية كل 10 ثوانٍ:
startupProbe:\n httpGet:\n path: /healthz\n port: http\n periodSeconds: 5\n failureThreshold: 24أما initialDelaySeconds فسيعمل اليوم، لكنه يؤخّر كل بدء بمقدار أسوأ حالة وينكسر مجددًا حين يصل التسخين إلى 95 ثانية.
startupProbe على /healthz مع periodSeconds: 5 وfailureThreshold: 24.","why":"صحيح. ما يصل إلى 120 ثانية للبدء، مع فحص كل 5 ثوانٍ، ثم يتولّى الـ liveness دون تغيير."},"initial-delay":{"text":"اضبط initialDelaySeconds: 90 على الـ liveness probe.","why":"يؤخّر الـ liveness بـ 90 ثانية في كل بدء، حتى السريع منها، ويفشل مجددًا حالما يتجاوز التسخين 90 ثانية."},"no-liveness":{"text":"احذف الـ liveness probe؛ الـ readiness يكفي.","why":"الـ readiness لا يعيد تشغيل أي شيء أبدًا، فستبقى العملية العالقة في deadlock مكانها إلى الأبد، خارج التناوب لكن دون إصلاح."},"liveness-readyz":{"text":"وجّه الـ liveness probe إلى /readyz بدلًا من ذلك.","why":"هذا لا يضيف وقتًا للبدء، ويربط إعادات التشغيل بصحة قاعدة البيانات، فيحوّل الأعطال العابرة في قاعدة البيانات إلى انقطاعات."}}},"words":683,"readMinutes":4}