مجسات Kubernetes: متى تنتظر أو توجّه حركة المرور أو تعيد التشغيل

تعمل عملية افتراضية لواجهة برمجة تطبيقات، لكن التهيئة لم تكتمل بعد. لاحقًا، تصبح قاعدة بياناتها غير متاحة. وفي يوم آخر، يمنع تعطل متبادل محلي اكتمال الطلبات. قد تؤدي كل حالة إلى فشل فحص السلامة. لكن ينبغي ألا تؤدي تلقائيًا إلى الاستجابة نفسها.

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

يبدأ التصميم الجيد للمجسات بتبرير يوضح كيف سيحدث التعافي. يتناول هذا الدليل تطبيق HTTP تقليديًا ضمن Deployment خلف Service عادية. يحتاج الوصول المباشر إلى Pod، والعمليات العاملة، وإعدادات Service المتخصصة، والتوجيه المخصص إلى تحليل منفصل. الإعداد المعروض توضيحي ولم يُنفَّذ.

الجاهزية والحيوية وبدء التشغيل في Kubernetes: ثلاثة قرارات مختلفة

يحدد المجس ما يفعله Kubernetes بإشارة نقطة النهاية. راجع سلوك مجسات Kubernetes قبل اختيار الفحص.

يحمي مجس بدء التشغيل مرحلة التهيئة

يؤخر مجس بدء التشغيل فحوص الحيوية والجاهزية حتى ينجح. يمنح ذلك التهيئة مهلة خاصة بها دون إضعاف الفحوص المستمرة. وتظل هذه المهلة محدودة: يؤدي تكرار فشل بدء التشغيل إلى إنهاء الحاوية. تشرح إرشادات إعداد بدء التشغيل هذا الانتظار المحدود.

تتحكم الجاهزية في أهلية استقبال حركة المرور

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

يسأل مجس الحيوية عما إذا كانت إعادة التشغيل ستفيد

عند بلوغ عتبة الفشل، يؤدي مجس الحيوية إلى إنهاء الحاوية المحددة، لا إلى استبدال Pod بأكملها. تحكم سياسة إعادة التشغيل ما يلي ذلك، بما فيه التراجع التدريجي لإعادة المحاولة الموضح في وثائق دورة حياة Pod. قد تكون العملية قيد التشغيل عالقة. وقد لا تعاني العملية التي تنتظر خدمة خارجية غير متاحة من أي خلل محلي.

إطار الانتظار والتوجيه وإعادة التشغيل لاتخاذ قرارات المجسات

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

اربط العطل بإجراء

كل السيناريوهات التالية افتراضية. اختبر شروط القبول على عبء العمل الفعلي.

تعقّد التبعيات المشتركة قرار التوجيه. إذا كانت كل نسخة تفحص الخدمة الخلفية غير المتاحة نفسها، فقد يتحول سحب نسخة واحدة إلى سحب جميع النسخ. يناقش التحليل العملي لكولين بريك مشكلة نطاق العطل هذه. لا تستطيع إعادة تشغيل النسخ، بمفردها، إصلاح التبعية المشتركة بينها.

سجّل الأدلة والمسؤولية عن التعافي

سجّل ما يظل مفيدًا، وما الذي ستغيّره إعادة التشغيل، ومن المسؤول عن التعافي، إلى جانب الإعداد. هذا المثال بصيغة JSON سجل للتخطيط، وليس سياسة قابلة للتنفيذ.

{
  "framework": "wait-route-restart",
  "wait": "bounded-initialization-allowance",
  "route": "scoped-request-usefulness",
  "restart": "tested-local-recovery-mechanism",
  "acceptance": "observed-state-and-real-requests"
}

قد يكون الاستغناء عن مجس الحيوية معقولًا عندما لا توجد إشارة تبرر إعادة التشغيل. يوثّق Kubernetes هذا الخيار. ويستحق الاعتراض عليه قدرًا مماثلًا من الاهتمام: قد يترك سحب الجاهزية وحده نسخة عالقة غير متاحة إلى أجل غير مسمى. يوضح تحليل بريك لماذا يظل هذا التصميم بحاجة إلى شخص أو آلية مسؤولة عن استعادة التقدم.

فحوص تبعيات الجاهزية دون سحب القدرة المفيدة على الخدمة

افصل التبعيات الأساسية عن الميزات الاختيارية

تسمح الإرشادات الرسمية بفحوص الجاهزية للتبعيات الخلفية التي لا غنى عنها. يحذر هينينغ جاكوبس من فحوص التبعيات المشتركة، بينما يناقش بريك اختلاف تبعيات الطلبات. اسأل عمّا يحققه السحب.

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

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

ضع حدودًا للفحوص وحافظ على السلوك عند تراجع القدرة

حدّد ميزانيات زمنية لفحوص التبعيات وبيّن ما يحدث عند انتهاء المهلة. تحتاج حالة السلامة المخزنة مؤقتًا إلى حد أقصى لعمرها وقاعدة للتعامل مع النتائج المجهولة أو القديمة. نجاح فحص الأمس ليس دليلًا على أن الخدمة تستطيع قبول الطلبات الآن.

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

أبقِ أعطال التبعيات خارج فحوص الحيوية ما لم تفسر الاختبارات كيف تصلحها إعادة التشغيل المحلية. تتضمن مقالات الممارسين أمثلة تاريخية لوحدات التحكم؛ تحقّق من مسار الدخول المثبّت بدلًا من افتراض أن تلك الأمثلة تصف سلوكه الحالي.

إعداد توضيحي لمجسات HTTP وعقد نقاط النهاية

امنح بدء التشغيل والجاهزية والحيوية معاني منفصلة

يوضع هذا المقتطف داخل مواصفات حاوية. وهو ليس Deployment كاملة قابلة للتشغيل. يفترض وجود تطبيق يستمع على المنفذ 8080 ويتيح نقاط النهاية الموضحة. قيم التوقيت أمثلة لم تخضع لاختبارات قياس الأداء، وليست توصيات للضبط.

ports:
  - name: http
    containerPort: 8080
startupProbe:
  httpGet:
    path: /startupz
    port: http
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 24
  successThreshold: 1
readinessProbe:
  httpGet:
    path: /readyz
    port: http
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 3
  successThreshold: 2
livenessProbe:
  httpGet:
    path: /livez
    port: http
  periodSeconds: 10
  timeoutSeconds: 2
  failureThreshold: 3
  successThreshold: 1

بموجب هذا العقد المقترح، تشير /startupz إلى اكتمال التهيئة. وتشير /readyz إلى ما إذا كان ينبغي أن تستقبل النسخة حركة المرور ضمن نطاقها المحدد. وتكشف /livez حالة محلية يمكن أن تعالجها إعادة التشغيل. تجعل المسارات المنفصلة هذا المثال أسهل للمراجعة؛ ولا يشترط Kubernetes عناوين URL منفصلة.

تفحص مجسات HTTP حالة الاستجابة، لا نجاح عمليات العمل. تحدد إرشادات الإعداد الرسمية رموز الحالة الناجحة من 200 إلى 399. تتضمن معالجة إعادة التوجيه استثناءات تستحق الفحص: يتبع kubelet عمليات إعادة التوجيه إلى المضيف نفسه، لكن إعادة التوجيه إلى مضيف مختلف أو وقوع 11 عملية إعادة توجيه أو أكثر يُعامَل على أنه نجاح مع حدث ProbeWarning. فضّل استجابة صريحة للسلامة على إعادة التوجيه إلى تسجيل الدخول. أبقِ حمولات البيانات صغيرة واستبعد الأسرار أو التفاصيل الحساسة للتبعيات.

اختر التوقيت بناءً على أدلة عبء العمل

يحدد periodSeconds وتيرة المجس. ويحدّ timeoutSeconds زمن المجس الواحد. ويحسب failureThreshold حالات الفشل المتتالية، بينما يحسب successThreshold حالات النجاح المتتالية بعد الفشل. يجب أن تكون قيمة الأخير 1 لبدء التشغيل والحيوية. قد تُجرى فحوص الجاهزية بوتيرة أعلى عندما تكون الحاوية غير جاهزة. هذه دلالات الحقول الموثقة، وليست وصفة للضبط.

قِس التهيئة في ظروف بدء التشغيل التي تنوي دعمها، بما فيها حالات البدء البارد ذات الصلة. راجع مهلة السماح بالإنهاء أيضًا. يراعي kubelet مهلة السماح المنطبقة أثناء الإنهاء الناتج عن المجسات؛ وتتوفر مهلة السماح على مستوى المجس لبدء التشغيل والحيوية، لا للجاهزية. راجع وثائق المجسات.

لا ينتج عن ضرب العتبات موعد نهائي دقيق للتعافي. تؤثر الجدولة والمهلات والإيقاف والتراجع التدريجي لإعادة التشغيل والتهيئة أيضًا في الوقت المنقضي. يحتاج الدليل القابل للتشغيل إلى بيئة اختبار كاملة بإصدارات مثبتة ومخرجات تنفيذ محفوظة. لم يُنفَّذ هذا المقتطف على عنقود.

دليل عمل لبيئة الاختبار المرحلية: اختبر العطل وافحص الأدلة ثم انشر

سجّل خط الأساس واختبر عطلًا واحدًا في كل مرة

هذه اختبارات مقترحة، وليست نتائج تجارب. قبل الاختبار الأول:

1. احصر سلوك نقاط النهاية، والقيم الافتراضية لفحوص السلامة في إطار العمل، وافتراضات التوجيه.
2. احفظ إعداد المجسات الحالي وأدلة خط الأساس للطلبات والجاهزية وإعادة التشغيل.
3. عيّن إجراءً متوقعًا ومسؤولًا عن التعافي لكل عطل.
4. اختبر عطلًا واحدًا في كل مرة في عبء عمل معزول ضمن بيئة الاختبار المرحلية.
5. قارن الملاحظات بالعقد قبل الموافقة على نشر محدود النطاق.
6. احتفظ بإعداد التطبيق الذي خضع للمراجعة ومسار التراجع عن النشر.

استخدم تطبيقًا يمكن التخلص منه لإحداث التوقفات المتعمدة. لا تُدخل حالات تعطل متبادل في خدمات الإنتاج المشتركة.

افحص حالة Kubernetes والطلبات الفعلية معًا

اقرأ حالات Pod وأعداد إعادات تشغيل الحاويات. افحص الأحداث وسجلات الحاوية السابقة حيثما توفرت، ثم اربط جاهزية EndpointSlice التابعة لخدمة Service المطابقة بالطلبات المارة عبر Service المقصودة أو مسار الدخول. تشرح وثائق المجسات ودورة الحياة انتقالات الحالة. لا يثبت قبول الإعداد وحده الكثير عن التعافي.

تصل تغييرات EndpointSlice إلى آليات المراقبة وذاكرات التخزين المؤقت لدى العملاء في أوقات مختلفة، كما توضح وثائق EndpointSlice الرسمية. وتوثّق أيضًا استثناءً: يجعل publishNotReadyAddresses قيمة ready لنقطة النهاية صحيحة بغض النظر عن جاهزية Pod. يفترض هذا الدليل أن ذلك الخيار معطّل. اختبر مسار التوجيه المثبّت والطلبات طويلة المدة؛ ولا تفترض أن كل وحدة تحكم توقف توجيه الطلبات الجديدة فورًا أو أن فشل الجاهزية يغلق الاتصالات القائمة.

بالنسبة إلى خدمات الاستدلال، قارن أدلة المجسات مع قابلية رصد استدلال الذكاء الاصطناعي. لا تثبت سلامة العملية زمن الاستجابة أو نجاح الطلبات أو جودة المخرجات. يضيف دليل عمل التتبع باستخدام OpenTelemetry GenAI سياقًا لاستدعاءات النماذج والأدوات. وهو مكمّل لاختبار المجسات.

قِس التعافي، لا المؤشرات الخضراء وحدها.

حدّد التعافي والتراجع قبل الإنتاج

ارفض التغيير إذا انسحبت نسخ غير معنية، أو زادت إعادات التشغيل دون تعافٍ، أو تعطلت مسارات مفيدة، أو بقي التعافي غير مفسر. ضع معايير قبول لعبء العمل بدلًا من استعارة عتبات عامة لزمن الاستجابة أو التوافر.

يجب أن يعيد التراجع عقد نقاط النهاية وإعداد المجسات اللذين خضعا للمراجعة عبر عملية النشر المعتادة. افحص الجاهزية وسلوك إعادة التشغيل والطلبات الفعلية بعد ذلك. نجاح أمر النشر لا يثبت التعافي.

الأخطاء التي تقع فيها الفرق وما لا تستطيع المجسات ضمانه

تجنّب إشارات العطل المشتركة وإعادات التشغيل غير المبررة

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

والإصرار على عناوين URL مختلفة ليس أفضل بوصفه قاعدة مطلقة. يصف Kubernetes تصميمات تشترك في نقطة نهاية بعتبات مختلفة. راجع الإشارة ونتيجتها. لا يمكن لتسمية نقطة النهاية أن تحسم ما إذا كانت إعادة التشغيل ستفيد.

افصل التعطيل والإيقاف والعمل ذي الحالة الدائمة

يقيّد PodDisruptionBudget عمليات الإخلاء الطوعي المدعومة. وهو لا ينسق إعادات تشغيل الحاويات الناتجة عن الحيوية ولا يضمن حدًا أدنى للتوافر. تحدد الوثائق الرسمية للتعطيلات نطاقه. تساعد مناقشة المجتمع التاريخية على تفسير الالتباس؛ لكنها ليست مواصفة حالية.

لا يوفر سحب الجاهزية إنهاءً سلسًا أو تصريفًا للاتصالات أو إيقافًا للعمليات العاملة. تتناول وثائق دورة حياة Pod الإنهاء بصورة منفصلة. تحتاج هذه المسؤوليات إلى تصميمات واختبارات صريحة.

ولا تثبت إعادة تشغيل الحاوية الحالة المعتمدة للمهام ولا تمنع تكرار عمليات الكتابة الخارجية. بالنسبة إلى أعباء عمل الوكلاء، راجع حالة سير العمل الدائمة والتعافي إلى جانب سلامة الحاوية.

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