قد يكون من الصعب إدارة الأنظمة الموزعة لأنها تحتوي على العديد من العناصر المتحركة والمتغيرة التي تحتاج جميعها إلى العمل بشكل صحيح حتى يعمل النظام. في حالة فشل أحد العناصر، يجب على النظام اكتشافه وتجاوزه وإصلاحه، ويجب أن يتم كل ذلك تلقائيًا. في سلسلة أفضل ممارسات Kubernetes، سنتعلم كيفية إعداد اختبارات الاستعداد والحيوية لاختبار صحة مجموعة Kubernetes.
يعد التحقق من الصحة طريقة بسيطة للسماح للنظام بمعرفة ما إذا كان مثيل التطبيق الخاص بك قيد التشغيل أم لا. إذا كان مثيل التطبيق الخاص بك معطلاً، فلا ينبغي للخدمات الأخرى الوصول إليه أو إرسال طلبات إليه. بدلاً من ذلك، يجب إرسال الطلب إلى مثيل آخر للتطبيق قيد التشغيل بالفعل أو سيتم تشغيله لاحقًا. بالإضافة إلى ذلك، يجب على النظام استعادة الوظائف المفقودة لتطبيقك.
افتراضيًا، سيبدأ Kubernetes في إرسال حركة المرور إلى الكبسولة عندما تكون جميع الحاويات الموجودة في الكبسولة قيد التشغيل، وسيعيد تشغيل الحاويات عند تعطلها. قد يكون سلوك النظام الافتراضي هذا جيدًا بما يكفي للبدء به، ولكن يمكنك تحسين موثوقية نشر المنتج الخاص بك عن طريق استخدام فحوصات السلامة المخصصة.
لحسن الحظ، يجعل Kubernetes هذا الأمر سهلاً للغاية، لذلك ليس هناك عذر لتجاهل هذه الفحوصات. يوفر Kubernetes نوعين من عمليات التحقق من الصحة، ومن المهم فهم الاختلافات في كيفية استخدام كل منهما.
تم تصميم اختبار الجاهزية لإخبار Kubernetes أن تطبيقك جاهز للتعامل مع حركة المرور. قبل السماح للخدمة بإرسال حركة المرور إلى حجرة، يجب على Kubernetes التحقق من نجاح التحقق من الجاهزية. إذا فشل اختبار الاستعداد، فسيتوقف Kubernetes عن إرسال حركة المرور إلى الحجرة حتى يتم اجتياز الاختبار.
يخبر اختبار Liveness Kubernetes ما إذا كان تطبيقك حيًا أم ميتًا. في الحالة الأولى، سيتركها Kubernetes بمفردها، وفي الحالة الثانية، ستحذف الكبسولة الميتة وتستبدلها بأخرى جديدة.
لنتخيل سيناريو يستغرق فيه تطبيقك دقيقة واحدة للإحماء والتشغيل. لن تبدأ خدمتك في العمل حتى يتم تحميل التطبيق وتشغيله بالكامل، على الرغم من أن سير العمل قد بدأ بالفعل. ستواجه أيضًا مشكلات إذا كنت تريد توسيع نطاق هذا النشر ليشمل نسخًا متعددة، لأن هذه النسخ لا ينبغي أن تتلقى حركة مرور حتى تصبح جاهزة تمامًا. ومع ذلك، سيبدأ Kubernetes افتراضيًا في إرسال حركة المرور بمجرد بدء العمليات داخل الحاوية.
عند استخدام اختبار الجاهزية، سينتظر Kubernetes حتى يتم تشغيل التطبيق بالكامل قبل السماح للخدمة بإرسال حركة المرور إلى النسخة الجديدة.
لنتخيل سيناريو آخر، حيث يتوقف التطبيق لفترة طويلة، مما يؤدي إلى إيقاف طلبات الخدمة. مع استمرار تشغيل العملية، سيفترض Kubernetes افتراضيًا أن كل شيء على ما يرام ويستمر في إرسال الطلبات إلى الكبسولة التي لا تعمل. ولكن عند استخدام Liveness، سيكتشف Kubernetes أن التطبيق لم يعد يخدم الطلبات وسيقوم بإعادة تشغيل الكبسولة الميتة افتراضيًا.
دعونا نلقي نظرة على كيفية اختبار الاستعداد والقدرة على الاستمرار. هناك ثلاث طرق للاختبار - HTTP، وCommand، وTCP. يمكنك استخدام أي منهم للتحقق. الطريقة الأكثر شيوعًا لاختبار المستخدم هي مسبار HTTP.
حتى إذا لم يكن تطبيقك خادم HTTP، فلا يزال بإمكانك إنشاء خادم HTTP خفيف الوزن داخل تطبيقك للتفاعل مع اختبار Liveness. بعد ذلك، سيبدأ Kubernetes في اختبار اتصال الكبسولة، وإذا كانت استجابة HTTP في نطاق 200 أو 300 مللي ثانية، فسوف يشير ذلك إلى أن الكبسولة سليمة. وإلا، سيتم وضع علامة على الوحدة بأنها "غير صحية".
بالنسبة لاختبارات الأوامر، يقوم Kubernetes بتشغيل الأمر داخل الحاوية الخاصة بك. إذا عاد الأمر برمز خروج صفر، فسيتم وضع علامة على الحاوية على أنها صحية، وإلا، عند استلام رقم حالة الخروج من 1 إلى 255، سيتم وضع علامة على الحاوية على أنها "مريضة". تعتبر طريقة الاختبار هذه مفيدة إذا كنت لا تستطيع أو لا تريد تشغيل خادم HTTP، ولكنك قادر على تشغيل أمر للتحقق من صحة التطبيق الخاص بك.
آلية التحقق النهائية هي اختبار TCP. سيحاول Kubernetes إنشاء اتصال TCP على المنفذ المحدد. إذا كان من الممكن القيام بذلك، تعتبر الحاوية صحية، وإذا لم يكن الأمر كذلك، فهي تعتبر غير قابلة للحياة. يمكن أن تكون هذه الطريقة مفيدة إذا كنت تستخدم سيناريو حيث لا يعمل الاختبار باستخدام طلب HTTP أو تنفيذ الأمر بشكل جيد. على سبيل المثال، الخدمات الرئيسية للتحقق باستخدام TCP ستكون gRPC أو FTP.
يمكن تكوين الاختبارات بعدة طرق باستخدام معلمات مختلفة. يمكنك تحديد عدد المرات التي يجب تنفيذها، وما هي حدود النجاح والفشل، ومدة انتظار الاستجابات. لمزيد من المعلومات، راجع الوثائق الخاصة باختبارات الجاهزية والحيوية. ومع ذلك، هناك نقطة واحدة مهمة جدًا في إعداد اختبار الحياة - الإعداد الأولي لتأخير الاختبار الأولي DelaySeconds. وكما ذكرت، سيؤدي فشل هذا الاختبار إلى إعادة تشغيل الوحدة. لذلك تحتاج إلى التأكد من أن الاختبار لا يبدأ حتى يصبح التطبيق جاهزًا للعمل، وإلا فإنه سيبدأ في الدوران خلال عمليات إعادة التشغيل. أوصي باستخدام وقت بدء التشغيل P99 أو متوسط وقت بدء تشغيل التطبيق من المخزن المؤقت. تذكر ضبط هذه القيمة عندما يصبح وقت بدء تشغيل التطبيق الخاص بك أسرع أو أبطأ.
سيؤكد معظم الخبراء أن عمليات التحقق من السلامة هي فحص إلزامي لأي نظام موزع، وKubernetes ليس استثناءً. يضمن استخدام فحوصات سلامة الخدمة تشغيلًا موثوقًا وخاليًا من المشاكل لـ Kubernetes وهو سهل بالنسبة للمستخدمين.
على أن تستمر قريبا جدا ...
بعض الاعلانات 🙂
أشكركم على البقاء معنا. هل تحب مقالاتنا؟ تريد أن ترى المزيد من المحتوى المثير للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية للأصدقاء ، , تناظرية فريدة من خوادم المستوى المبتدئ ، اخترعناها من أجلك: (متوفر مع RAID1 و RAID10 ، حتى 24 مركزًا وحتى 40 جيجا بايت DDR4).
Dell R730xd أرخص مرتين في مركز بيانات Equinix Tier IV في أمستردام؟ هنا فقط في هولندا! Dell R420 - 2x E5-2430 2.2 جيجا هرتز 6C 128 جيجا بايت DDR3 2x960 جيجا بايت SSD 1 جيجا بايت في الثانية 100 تيرا بايت - من 99 دولارًا! أقرأ عن
المصدر: www.habr.com