أفضل ممارسات Kubernetes. اختبار الجدوى Kubernetes مع اختبارات الجاهزية والحيوية

أفضل ممارسات Kubernetes. إنشاء
أفضل الممارسات Kubernetes حاويات صغيرة .



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

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

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



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

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

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

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

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



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



فكر في كيفية اختبار الاستعداد والحيوية. هناك ثلاث طرق اختبار - HTTP و ommand و TCP. يمكنك استخدام أي منها للتحقق. أكثر طرق اختبار المستخدم شيوعًا هي مسبار HTTP.

حتى إذا لم يكن تطبيقك خادم HTTP ، فلا يزال بإمكانك إنشاء خادم HTTP خفيف الوزن داخل تطبيقك للتفاعل مع اختبار Lively. بعد ذلك ، سيبدأ Kubernetes في اختبار ping ، وإذا كانت استجابة HTTP في حدود 200 أو 300 مللي ثانية ، فهذا يعني أن البود "سليم". خلاف ذلك ، سيتم وضع علامة على الوحدة بأنها "غير صحية".



للاختبارات باستخدام Command ، ينفذ Kubernetes الأمر داخل الحاوية. إذا عاد الأمر برمز خروج صفر ، فسيتم وضع علامة على الحاوية على أنها سليمة ، وإلا ، عندما يكون رقم حالة الخروج من 1 إلى 255 ، سيتم وضع علامة على الحاوية على أنها "مريضة". طريقة الاختبار هذه مفيدة إذا كنت لا تستطيع أو لا تريد بدء تشغيل خادم HTTP ، ولكنك قادر على تشغيل أمر يتحقق من صحة تطبيقك.



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



يمكن تكوين الاختبارات بعدة طرق مع معلمات مختلفة. يمكنك تحديد عدد المرات التي يجب تنفيذها فيها ، وما هي عتبات النجاح والفشل ، ومدة انتظار الإجابات. راجع وثائق اختبار الجاهزية والفعالية لمزيد من المعلومات. ومع ذلك ، هناك نقطة واحدة مهمة جدًا في إعداد اختبار مدى الحياة - الإعداد الأولي لتأخير اختبار DelaySeconds الأولي. كما ذكرت ، سيؤدي فشل هذا الاختبار إلى إعادة تشغيل الوحدة النمطية. لذلك ، تحتاج إلى التأكد من أن الاختبار لا يبدأ حتى يصبح التطبيق جاهزًا للاستخدام ، وإلا فسيبدأ في التنقل خلاله. أوصي باستخدام وقت بدء تشغيل P99 أو متوسط ​​وقت بدء تشغيل التطبيق من المخزن المؤقت. لا تنس تعديل هذه القيمة كـنظرًا لأن وقت إطلاق تطبيقك أصبح أسرع أو أبطأ.

سيؤكد معظم الخبراء أن Health Check هو فحص إلزامي لأي نظام موزع ، و Kubernetes ليست استثناء. ويضمن استخدام التحقق "الصحي" من الخدمات Kubernetes الموثوقة ووقت التشغيل ولا يؤدي أي عمل للمستخدمين.

يتبع قريبا جدا ...

القليل من الدعاية :)

أشكركم على البقاء معنا. هل تحب مقالاتنا؟ هل تريد رؤية مواد أكثر إثارة للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية لأصدقائك VPS القائم على السحابة للمطورين من $ 4.99 ، وهو نظير فريد من نوعه لخوادم مستوى الدخول التي اخترعناها لك: الحقيقة الكاملة عن VPS (KVM) E5-2697 v3 (6 نوى) 10GB DDR4 480GB SSD 1Gbps من $ 19 أو كيفية تقسيم الخادم؟ (تتوفر الخيارات مع RAID1 و RAID10 ، حتى 24 مركزًا و 40 جيجابايت DDR4).

Dell R730xd أرخص مرتين في مركز بيانات Equinix Tier IV في أمستردام؟ فقط لدينا 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV من 199 دولارًا في هولندا!Dell R420 - 2x E5-2430 2.2 جيجا هرتز 6C 128 جيجا بايت DDR3 2x960GB SSD 1Gbps 100TB - من 99 دولار! اقرأ عن كيفية بناء مبنى البنية التحتية الفئة c باستخدام خوادم Dell R730xd E5-2650 v4 بتكلفة 9000 يورو مقابل سنت واحد؟