تقريبا. العابرة. : لاحظ المهندس الرائد من زالاندو ، هينينج جاكوبس ، مرارًا وتكرارًا مشكلات مع مستخدمي Kubernetes في فهم الغرض من تحقيقات الفعالية (والاستعداد) وتطبيقها الصحيح. لذلك ، جمع أفكاره في هذا المقال الواسع ، والذي سيصبح بمرور الوقت جزءًا من وثائق K8s.
الفحوصات الصحية ، المعروفة في Kubernetes باسم
تحقيقات الثبات (أي ، حرفيًا ، "اختبارات الجدوى" - تقريبًا الترجمة) ، يمكن أن تكون خطيرة جدًا. أوصي بتجنبها كلما كان ذلك ممكنًا: الاستثناءات الوحيدة هي الحالات التي تكون فيها ضرورية حقًا وأنت مدرك تمامًا للخصائص والنتائج المترتبة على استخدامها. سوف يركز هذا المنشور على اختبارات الصلاحية والاستعداد ، وسيشرح أيضًا في الحالات
التي يستحقها ولا يستحق استخدامها.
شارك زميلي ساندور مؤخرًا على Twitter الأخطاء الأكثر شيوعًا التي يواجهها ، بما في ذلك تلك المتعلقة باستخدام تحقيقات الجاهزية / الفعالية:
يمكن أن يؤدي
livenessProbe تكوينه بشكل غير صحيح إلى تفاقم المواقف مع الحمل العالي (إيقاف الانهيار + التشغيل الطويل المحتمل للحاوية / التطبيق) ويؤدي إلى عواقب سلبية أخرى مثل انخفاض التبعيات
(انظر أيضًا مقالتي الأخيرة حول الحد من عدد الطلبات في حزمة K3s + ACME) . والأسوأ من ذلك ، عندما يتم الجمع بين مسبار الفعالية مع فحص صحي ، والذي يعمل كقاعدة بيانات خارجية:
فشل قاعدة البيانات الوحيدة في إعادة تشغيل جميع الحاويات الخاصة بك !
الرسالة العامة
"لا تستخدم تحقيقات liveness" في هذه الحالة تساعد قليلا ، وبالتالي ، فإننا سوف تنظر في ما هي الجاهزية والشيكات liveness - هي.
ملاحظة: تم تضمين معظم الاختبار أدناه في الأصل في الوثائق الداخلية لمطوري Zalando.الشيكات الاستعداد والقدرة
يوفر Kubernetes آليتين مهمتين تسمى
تحقيقات الثبات وتحقيقات الاستعداد . يقومون بشكل دوري ببعض الإجراءات - على سبيل المثال ، إرسال طلب HTTP أو فتح اتصال TCP أو تنفيذ أمر في حاوية - لتأكيد أن التطبيق يعمل بشكل صحيح.
يستخدم Kubernetes
تحقيقات الاستعداد لفهم عندما تكون الحاوية جاهزة لاستقبال حركة المرور. تعتبر الحافظة جاهزة للعمل إذا كانت جميع حاوياتها جاهزة. تطبيق واحد من هذه الآلية هو السيطرة على القرون التي تستخدم كخلفية لخدمات Kubernetes (وخاصة الدخول).
تحقيقات Liveness تساعد Kubernetes فهم عندما حان الوقت لإعادة تشغيل الحاوية. على سبيل المثال ، يسمح لك هذا التحقق باعتراض حالة توقف تام عند "توقف" التطبيق في مكان واحد. تساعد إعادة تشغيل الحاوية في هذه الحالة على نقل التطبيق بعيدًا عن الأرض ، على الرغم من الأخطاء ، ولكنه قد يؤدي أيضًا إلى إخفاقات متتالية (انظر أدناه).
إذا حاولت نشر تحديث إلى أحد التطبيقات التي فشلت في اختبارات الصلاحية / الاستعداد ، فسيتم إيقاف تشغيلها لأن Kubernetes سينتظر حالة
Ready من جميع البرامج.
مثال
فيما يلي مثال على اختبار الاستعداد للتحقق من المسار
/health خلال HTTP بالإعدادات الافتراضية (
الفاصل الزمني : 10 ثوانٍ ،
المهلة : ثانية واحدة ،
عتبة النجاح : 1 ،
عتبة الفشل : 3):
# deployment'/ podTemplate: spec: containers: - name: my-container # ... readinessProbe: httpGet: path: /health port: 8080
توصيات
- بالنسبة إلى الخدمات المصغرة التي تحتوي على نقطة نهاية HTTP (REST ، وما إلى ذلك) ، حدد دائمًا مسبار الاستعداد الذي يتحقق مما إذا كان التطبيق (pod) جاهزًا لاستقبال حركة المرور.
- تأكد من أن اختبار الاستعداد يغطي مدى توفر منفذ خادم الويب الفعلي :
- باستخدام منافذ للاحتياجات الإدارية تسمى "المسؤول" أو "الإدارة" (على سبيل المثال ، 9090) من أجل
readinessProbe ، تأكد من إرجاع نقطة النهاية "موافق" فقط إذا كان منفذ HTTP الرئيسي (مثل 8080) جاهزًا لقبول حركة المرور * ؛
* أعرف حالة واحدة على الأقل في زالاندو عندما لم يحدث هذا ، أي أن ReadinessProbe فحص منفذ "الإدارة" ، لكن الخادم نفسه لم يبدأ بسبب مشاكل في تحميل ذاكرة التخزين المؤقت. - قد يؤدي اختبار الجاهزية المعلقة على منفذ منفصل إلى حقيقة أن الازدحام على المنفذ الرئيسي لن ينعكس في الفحص الصحي (بمعنى أن مجموعة مؤشرات الترابط على الخادم ممتلئة ، لكن الفحص الصحي لا يزال يوضح أن كل شيء على ما يرام).
- تأكد من أن اختبار الاستعداد يتيح تهيئة / ترحيل قاعدة البيانات ؛
- أسهل طريقة لتحقيق ذلك هي الوصول إلى خادم HTTP فقط بعد اكتمال التهيئة (على سبيل المثال ، ترحيل قاعدة البيانات من Flyway ، وما إلى ذلك) ؛ أي بدلاً من تغيير حالة الفحص الصحي ، لا تقم ببساطة بتشغيل خادم الويب حتى يتم الانتهاء من ترحيل قاعدة البيانات *.
* يمكنك أيضًا تشغيل عمليات ترحيل قاعدة البيانات من حاويات الحرف الأولي خارج الحافظة. ما زلت من محبي التطبيقات القائمة بذاتها ، أي تلك التطبيقات التي تعرف فيها حاوية التطبيق ، دون تنسيق خارجي ، على كيفية إحضار قاعدة البيانات إلى الحالة المطلوبة.
- استخدم
httpGet لإجراء httpGet الاستعداد من خلال نقاط النهاية النموذجية للفحوصات الصحية (على سبيل المثال /health ). successThreshold: 1 إعدادات successThreshold: 1 ( interval: 10s ، timeout: 1s successThreshold: 1 ، successThreshold: 1 ، failureThreshold: 3 ):- المعلمات الافتراضية تعني أن القرنة ستصبح غير جاهزة بعد حوالي 30 ثانية (3 فحوصات طبية فاشلة).
- استخدم منفذًا منفصلاً لـ "المسؤول" أو "الإدارة" إذا كانت حزمة التقنية (على سبيل المثال ، Java / Spring) تسمح بذلك بفصل إدارة الصحة والمقاييس عن الحركة العادية:
- إذا لزم الأمر ، يمكن استخدام مسبار الاستعداد لتسخين / تحميل ذاكرة التخزين المؤقت وإعادة رمز الحالة 503 حتى يتم "تسخين الحاوية":
التحذيرات
- لا تعتمد على التبعيات الخارجية (مثل تخزين البيانات) عند إجراء اختبارات الجاهزية / الكفاءة - وهذا يمكن أن يؤدي إلى إخفاقات متتالية:
- على سبيل المثال ، دعنا نأخذ خدمة REST ذات ولاية مع 10 قرون اعتمادًا على قاعدة بيانات Postgres: عندما يعتمد الفحص على اتصال عمل بقاعدة البيانات ، يمكن أن تقع جميع القرون العشرة إذا كان هناك تأخير في الشبكة / على جانب قاعدة البيانات - عادة ما ينتهي كل شيء بأسوأ مما يمكن ؛
- لاحظ أن Spring Data بشكل افتراضي يتحقق من الاتصال بقاعدة البيانات *؛
* هذا هو السلوك الافتراضي لـ Spring Data Redis (على الأقل ، كان الأمر كما لو كنت راجعت آخر مرة) ، مما أدى إلى فشل "كارثي": عندما لم يكن Redis متاحًا لفترة قصيرة ، سقطت جميع القرون. - يمكن أن تعني كلمة "خارجي" في هذا المعنى أيضًا قرونًا أخرى من نفس التطبيق ، أي من الناحية المثالية ، يجب ألا يعتمد التحقق على حالة القرون الأخرى من نفس المجموعة لمنع حدوث أعطال متتالية:
- قد تختلف النتائج لتطبيقات الحالة الموزعة (على سبيل المثال ، التخزين المؤقت في الذاكرة في القرون).
- لا تستخدم المسبار ليفي لالقرون (الاستثناءات هي الحالات عندما تكون ضرورية حقا وأنت على علم تام بخصائص وعواقب استخدامها):
- يمكن أن يساعد مسبار liveness في استعادة الحاويات "المعلقة" ، ولكن نظرًا لأن لديك السيطرة الكاملة على التطبيق الخاص بك ، يجب ألا تحدث أشياء مثل عمليات "التوقف" والمأزق: الأفضل هو إسقاط التطبيق عن قصد وإعادته إلى حالة مستقرة السابقة.
- سيعمل مسبار الثبات الفاشل على إعادة تشغيل الحاوية ، مما يؤدي إلى تفاقم عواقب أخطاء التحميل: تؤدي إعادة تشغيل الحاوية إلى تعطل (على الأقل لوقت تشغيل التطبيق ، على سبيل المثال ، لأكثر من 30 ثانية) ، مما يتسبب في حدوث أخطاء جديدة ، وزيادة الحمل على الحاويات الأخرى وزيادة احتمال فشلها ، وما إلى ذلك ؛
- تعد عمليات التحقق من الفاعلية جنبًا إلى جنب مع التبعية الخارجية هي أسوأ المجموعات الممكنة ، والتي يمكن أن تؤدي إلى إخفاقات متتالية: تأخير بسيط على جانب قاعدة البيانات سيؤدي إلى إعادة تشغيل جميع الحاويات الخاصة بك!
- يجب أن تكون المعلمات الخاصة بالتحقق من الصلاحية والاستعداد مختلفة :
- يمكنك استخدام مسبار الفاعلية مع نفس الفحص الصحي ، ولكن عتبة أعلى (
failureThreshold ) ، على سبيل المثال ، قم بتعيين الحالة غير جاهزة بعد 3 محاولات وافترض أن مسبار الفاعل فشل بعد 10 محاولات ؛
- لا تستخدم اختبارات exec ، لأنها ترتبط بمشكلات معروفة تؤدي إلى ظهور عمليات الزومبي:
ملخص
- استخدم مجسات الاستعداد لتحديد وقت استعداد جراب لتلقي حركة المرور.
- لا تستخدم تحقيقات الكفاءة إلا عند الحاجة إليها حقًا.
- قد يؤدي الاستخدام غير الصحيح لتحقيقات الاستعداد / الثبات إلى تقليل التوافر وفشل المتتالية.
مواد إضافية حول هذا الموضوع
تحديث NO1 من 2019-09-29
حول حاويات init لترحيل قاعدة البيانات : إضافة حاشية سفلية.
ذكرني EJ PDB: واحدة من مشاكل الشيكات حيوية هو عدم وجود تنسيق بين القرون. لدى Kubernetes
ميزانيات تعطيل قرنة (PDBs) للحد من عدد حالات الفشل المتزامنة التي قد يواجهها أحد التطبيقات ، لكن عمليات التدقيق لا تأخذ في الاعتبار PDBs. من الناحية المثالية ، يمكننا طلب K8s: "أعد تشغيل جراب واحد في حالة فشل عملية التحقق ، ولكن لا تقم بإعادة تشغيلها جميعًا حتى لا تزيد الأمر سوءًا."
تم إعداد Bryan بشكل مثالي : "استخدم السبر القوي عندما تعرف على وجه اليقين أن
أفضل شيء يمكنك القيام به هو" قتل "التطبيق " (مرة أخرى ، لا يتم ترحيلك).
التحديث رقم 2 من 2019-09-29
فيما يتعلق بقراءة الوثائق قبل الاستخدام : لقد قمتُ بإنشاء
طلب ميزة لاستكمال الوثائق المتعلقة بتحقيقات الفاعلية.
PS من المترجم
اقرأ أيضًا في مدونتنا: