يمكن أن تكون تحقيقات الحياة في Kubernetes خطيرة

ملحوظة. ترجمة.: لاحظ المهندس الرئيسي من زالاندو، هينينج جاكوبس، بشكل متكرر مشاكل بين مستخدمي Kubernetes في فهم الغرض من تحقيقات الحيوية (والاستعداد) واستخدامها الصحيح. لذلك، قام بجمع أفكاره في هذه المذكرة الواسعة، والتي ستصبح في النهاية جزءًا من وثائق K8.

الفحوصات الصحية، المعروفة في Kubernetes باسم تحقيقات الحيوية (أي، حرفيًا، "اختبارات الجدوى" - تقريبًا. ترجمة.)، يمكن أن يكون خطيرًا جدًا. أوصي بتجنبها إن أمكن: الاستثناءات الوحيدة هي عندما تكون ضرورية حقًا وتكون على دراية تامة بتفاصيل استخدامها وعواقبها. سيتحدث هذا المنشور عن فحوصات الحيوية والجاهزية، وسيخبرك أيضًا في أي الحالات هو ويجب أن لا تستخدمها.

شارك زميلي ساندور مؤخرًا على تويتر الأخطاء الأكثر شيوعًا التي يواجهها، بما في ذلك تلك المتعلقة باستخدام مجسات الاستعداد/الحيوية:

تم تكوينه بشكل غير صحيح livenessProbe يمكن أن يؤدي إلى تفاقم حالات التحميل العالي (إيقاف تشغيل كرة الثلج + وقت بدء تشغيل الحاوية/التطبيق المحتمل الطويل) ويؤدي إلى عواقب سلبية أخرى مثل انخفاض التبعية (أنظر أيضا مقالتي الأخيرة حول الحد من عدد الطلبات في مجموعة K3s+ACME). والأمر أسوأ من ذلك عندما يتم دمج مسبار الحيوية مع فحص الصحة، وهو قاعدة بيانات خارجية: سيؤدي فشل قاعدة بيانات واحدة إلى إعادة تشغيل جميع الحاويات الخاصة بك!

رسالة عامة "لا تستخدم مجسات الحيوية" في هذه الحالة، لا يساعد ذلك كثيرًا، لذا دعونا نلقي نظرة على الغرض من فحوصات الاستعداد والحيوية.

ملاحظة: تم تضمين معظم الاختبارات أدناه في الأصل في وثائق المطورين الداخليين لـ Zalando.

فحوصات الجاهزية والحيوية

يوفر Kubernetes آليتين مهمتين تسمى تحقيقات الحيوية وتحقيقات الاستعداد. ويقومون بشكل دوري بتنفيذ بعض الإجراءات — مثل إرسال طلب HTTP، أو فتح اتصال TCP، أو تنفيذ أمر في الحاوية — للتأكد من أن التطبيق يعمل كما هو متوقع.

يستخدم كوبيرنيتيس تحقيقات الاستعدادلفهم متى تكون الحاوية جاهزة لقبول حركة المرور. تعتبر الكبسولة جاهزة للاستخدام إذا كانت جميع حاوياتها جاهزة. أحد استخدامات هذه الآلية هو التحكم في القرون التي سيتم استخدامها كواجهات خلفية لخدمات Kubernetes (وخاصة Ingress).

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

إذا حاولت نشر تحديث تطبيق فشل في عمليات التحقق من الحيوية/الجاهزية، فسيتم إيقاف طرحه بينما ينتظر Kubernetes الحالة Ready من جميع القرون.

مثال

فيما يلي مثال على مسبار الاستعداد الذي يفحص المسار /health عبر HTTP مع الإعدادات الافتراضية (الفاصلة: 10 ثواني، مهلة: 1 ثانية، عتبة النجاح: 1، عتبة الفشل: 3):

# часть общего описания deployment'а/стека
podTemplate:
  spec:
    containers:
    - name: my-container
      # ...
      readinessProbe:
        httpGet:
          path: /health
          port: 8080

توصيات

1. بالنسبة للخدمات الصغيرة ذات نقطة نهاية HTTP (REST، وما إلى ذلك) حدد دائمًا مسبار الاستعداد، والذي يتحقق مما إذا كان التطبيق (pod) جاهزًا لقبول حركة المرور.
2. تأكد من مسبار الجاهزية يغطي مدى توفر منفذ خادم الويب الفعلي:
   • استخدام المنافذ لأغراض إدارية، تسمى "admin" أو "management" (على سبيل المثال، 9090)، من أجل readinessProbeتأكد من أن نقطة النهاية تُرجع موافق فقط إذا كان منفذ HTTP الأساسي (مثل 8080) جاهزًا لقبول حركة المرور*؛

     *أنا على علم بحالة واحدة على الأقل في زالاندو حيث لم يحدث هذا، أي. readinessProbe لقد قمت بفحص منفذ "الإدارة"، لكن الخادم نفسه لم يبدأ العمل بسبب مشاكل في تحميل ذاكرة التخزين المؤقت.

   • يمكن أن يؤدي إرفاق مسبار الاستعداد بمنفذ منفصل إلى حقيقة أن التحميل الزائد على المنفذ الرئيسي لن ينعكس في فحص السلامة (أي أن تجمع مؤشرات الترابط على الخادم ممتلئ، لكن فحص السلامة لا يزال يظهر أن كل شيء على ما يرام ).
3. تأكد من أن يتيح مسبار الاستعداد تهيئة/ترحيل قاعدة البيانات;
   • أسهل طريقة لتحقيق ذلك هي الاتصال بخادم HTTP فقط بعد اكتمال التهيئة (على سبيل المثال، ترحيل قاعدة بيانات من تسلكه وما إلى ذلك وهلم جرا.)؛ أي أنه بدلاً من تغيير حالة التحقق من الصحة، لا تقم ببساطة بتشغيل خادم الويب حتى يتم اكتمال ترحيل قاعدة البيانات*.

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

4. استخدم httpGet لفحوصات الاستعداد من خلال نقاط نهاية الفحص الصحي النموذجية (على سبيل المثال، /health).
5. فهم معلمات الفحص الافتراضية (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • تعني الخيارات الافتراضية أن الكبسولة ستصبح غير جاهز بعد حوالي 30 ثانية (3 عمليات فحص سلامة عقلية فاشلة).
6. استخدم منفذًا منفصلاً لـ "admin" أو "management" إذا كانت مجموعة التكنولوجيا (مثل Java/Spring) تسمح بذلك، لفصل إدارة الصحة والمقاييس عن حركة المرور العادية:
   • لكن لا تنسى النقطة 2.
7. إذا لزم الأمر، يمكن استخدام مسبار الاستعداد لتسخين/تحميل ذاكرة التخزين المؤقت وإرجاع رمز الحالة 503 حتى يتم تسخين الحاوية:
   • أوصي أيضًا بقراءة الشيك الجديد startupProbe, ظهرت في الإصدار 1.16 (كتبنا عن ذلك باللغة الروسية هنا - تقريبا. ترجمة.).

التحذيرات

1. لا تعتمد على التبعيات الخارجية (مثل مستودعات البيانات) عند تشغيل اختبارات الاستعداد/الحيوية - قد يؤدي ذلك إلى حالات فشل متتالية:
   • كمثال، لنأخذ خدمة REST ذات الحالة مع 10 كبسولات اعتمادًا على قاعدة بيانات Postgres واحدة: عندما يعتمد الفحص على اتصال عامل بقاعدة البيانات، قد تفشل جميع البودات العشرة إذا كان هناك تأخير على جانب الشبكة/قاعدة البيانات - عادةً ما يكون ذلك كل شيء ينتهي أسوأ مما يمكن؛
   • يرجى ملاحظة أن بيانات الربيع تتحقق من اتصال قاعدة البيانات بشكل افتراضي*؛

     * هذا هو السلوك الافتراضي لـ Spring Data Redis (على الأقل كانت هذه هي المرة الأخيرة التي قمت فيها بالتحقق)، مما أدى إلى فشل "كارثي": عندما لم يكن Redis متاحًا لفترة قصيرة، "تعطلت جميع القرون".

   • "خارجي" بهذا المعنى يمكن أن يعني أيضًا كبسولات أخرى من نفس التطبيق، أي أنه من الناحية المثالية، يجب ألا يعتمد الفحص على حالة البودات الأخرى من نفس المجموعة لمنع الأعطال المتتالية:
     • قد تختلف النتائج بالنسبة للتطبيقات ذات الحالة الموزعة (على سبيل المثال، التخزين المؤقت في الذاكرة في القرون).
2. لا تستخدم مسبار الحيوية للقرون (الاستثناءات هي الحالات التي تكون فيها ضرورية حقًا وتكون على دراية تامة بتفاصيل استخدامها وعواقبها):
   • يمكن أن يساعد مسبار الحيوية في استعادة الحاويات المعلقة، ولكن بما أنك تتمتع بالتحكم الكامل في تطبيقك، فمن الأفضل ألا تحدث أشياء مثل العمليات المعلقة والتوقف التام: البديل الأفضل هو تعطل التطبيق عمدًا وإعادته إلى الحالة المستقرة السابقة؛
   • سيؤدي فشل مسبار الحيوية إلى إعادة تشغيل الحاوية، مما قد يؤدي إلى تفاقم تأثيرات الأخطاء المتعلقة بالتمهيد: ستؤدي إعادة تشغيل الحاوية إلى وقت التوقف (على الأقل طوال مدة بدء تشغيل التطبيق، على سبيل المثال أكثر من 30 ثانية)، مما يتسبب في حدوث أخطاء جديدة، زيادة الحمل على الحاويات الأخرى وزيادة احتمالية فشلها، وما إلى ذلك؛
   • تعد عمليات التحقق من الحيوية جنبًا إلى جنب مع التبعية الخارجية أسوأ مزيج ممكن، مما يهدد بالفشل المتتالي: سيؤدي التأخير الطفيف في جانب قاعدة البيانات إلى إعادة تشغيل جميع حاوياتك!
3. معلمات التحقق من الحيوية والاستعداد يجب أن تكون مختلف:
   • يمكنك استخدام مسبار الحيوية مع نفس فحص الصحة، ولكن مع حد استجابة أعلى (failureThreshold)، على سبيل المثال، تعيين الحالة غير جاهز بعد 3 محاولات واعتبر أن مسبار الحيوية قد فشل بعد 10 محاولات؛
4. لا تستخدم الشيكات execنظرًا لارتباطها بالمشاكل المعروفة التي تؤدي إلى ظهور عمليات الزومبي:
   • التفاصيل: انظر عرض تقديمي من قبل المتخصصين في Datadog.

ملخص

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

مواد إضافية حول الموضوع

• مستندات Kubernetes: تكوين تحقيقات الحيوية والاستعداد;
• إعادة النظر في تحقيقات حيوية وجاهزية Kubernetes: كيفية تجنب إطلاق النار على نفسك في القدم الأخرى;
• مختبرات NRE انقطاع بعد الوفاة (يتحدث أيضًا عن lifenessProbe).

تحديث رقم 1 من 2019-09-29

حول حاويات init لترحيل قاعدة البيانات: تمت إضافة الحاشية السفلية.

ذكرني EJ حول PDB: إحدى مشكلات اختبارات الحيوية هي عدم التنسيق بين القرون. لدى كوبيرنيتيس ميزانيات تعطيل الكبسولة (PDB) للحد من عدد حالات الفشل المتزامنة التي يمكن أن يواجهها التطبيق، إلا أن عمليات التحقق لا تأخذ في الاعتبار PDB. من الناحية المثالية، يمكننا أن نطلب من K8s "إعادة تشغيل حجرة واحدة إذا فشل اختبارها، ولكن لا تعيد تشغيلها جميعًا لتجنب تفاقم الأمور."

لقد صاغها برايان بشكل مثالي: "استخدم اختبار الحيوية عندما تعرف بالضبط ما هو أفضل ما عليك فعله هو قتل التطبيق"(مرة أخرى، لا تنجرف).

تحديث رقم 2 من 2019-09-29

فيما يتعلق بقراءة الوثائق قبل الاستخدام: لقد قمت بإنشاء الطلب المقابل (طلب المواصفات) لإضافة وثائق حول تحقيقات الحيوية.

PS من المترجم

اقرأ أيضًا على مدونتنا:

• «كوبيرنيتيس: قرنة الحياة"؛
• «أفضل ممارسات حاوية Google السبع"؛
• «7 مبادئ لتصميم التطبيقات القائمة على الحاويات".

المصدر: www.habr.com