Istio Circuit Breaker: تعطيل الحاويات المعيبة

انتهت العطلات وها نحن نعود بمشاركتنا الثانية في سلسلة Istio Service Mesh.

موضوع اليوم هو قاطع الدائرة، والتي تُترجم إلى الهندسة الكهربائية الروسية وتعني "قاطع الدائرة"، في اللغة الشائعة - "قاطع الدائرة". فقط في Istio، لا تقوم هذه الآلة بفصل الدائرة القصيرة أو المحملة بشكل زائد، ولكن الحاويات المعيبة.

كيف ينبغي أن يعمل هذا بشكل مثالي

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

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

كيف يعمل حقا

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

ما هو طرد البركة في Istio

وهنا تأتي Istio للإنقاذ من خلال أجهزة حماية قواطع الدائرة، والتي تقوم بإزالة الحاويات المعيبة مؤقتًا من مجموعة موارد التوجيه وموازنة التحميل، وتنفيذ إجراء إخراج المجمع.

باستخدام استراتيجية اكتشاف خارجية، يكتشف Istio الحاضنات المنحنية الخارجة عن الخط ويزيلها من تجمع الموارد لفترة زمنية محددة، تسمى نافذة السكون.

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

الاستعداد لحادث تحطم الطائرة

قبل القيام بإخراج التجمع، تحتاج إلى إنشاء قاعدة توجيه Istio. لنفترض أننا نريد توزيع الطلبات بين الكبسولات بنسبة 50/50. بالإضافة إلى ذلك، سنقوم بزيادة عدد حاويات v2 من حاوية واحدة إلى اثنتين، كما يلي:

oc scale deployment recommendation-v2 --replicas=2 -n tutorial

قمنا الآن بتعيين قاعدة توجيه بحيث يتم توزيع حركة المرور بين الكبسولات بنسبة 50/50.

إليك ما تبدو عليه نتيجة هذه القاعدة:

يمكنك العثور على خطأ في حقيقة أن هذه الشاشة ليست 50/50، ولكن 14:9، ولكن مع مرور الوقت سوف يتحسن الوضع.

صنع خلل

لنقم الآن بتعطيل إحدى حاويتي v2 بحيث يكون لدينا حاوية v1 سليمة، وحاوية v2 سليمة، وحاوية v2 معيبة:

إصلاح الخلل

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

كما ترون، لم تعد حاوية v2 الفاشلة تُستخدم لطلبات التوجيه لأنه تمت إزالتها من التجمع. ولكن بعد 15 ثانية سيعود تلقائيا إلى حوض السباحة. في الواقع، لقد أظهرنا للتو كيفية عمل Pool Ejection.

لنبدأ في بناء الهندسة المعمارية

يسمح لك Pool Ejection، جنبًا إلى جنب مع إمكانات المراقبة الخاصة بـ Istio، بالبدء في إنشاء إطار عمل لاستبدال الحاويات المعيبة تلقائيًا لتقليل وقت التوقف عن العمل والفشل، إن لم يكن القضاء عليه.
 
ناسا لديها شعار واحد بصوت عال - الفشل ليس خيارا، الذي يعتبر مؤلفه مدير الرحلة جين كرانز. يمكن ترجمتها إلى اللغة الروسية على أنها "الفشل ليس خيارًا"، والمعنى هنا هو أنه يمكن جعل كل شيء يعمل إذا كان لديك ما يكفي من الإرادة. ومع ذلك، في الحياة الواقعية، لا تحدث حالات الفشل من تلقاء نفسها، بل إنها حتمية في كل مكان وفي كل شيء. وكيفية التعامل معها في حالة الخدمات المصغرة؟ في رأينا أنه من الأفضل الاعتماد ليس على قوة الإرادة، بل على قدرات الحاويات، Kubernetes, ريد هات OpenShiftو Istio.

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

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

قواطع دوائر من الناحية النظرية

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

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

قواطع دوائر في الممارسة العملية

على سبيل المثال، سنقوم بتشغيل نسختين من خدمة التوصيات الصغيرة الخاصة بنا على OpenShift. سيعمل الإصدار 1 بشكل جيد، ولكن في الإصدار الثاني، سنبني نظام تأخير لمحاكاة حالات التباطؤ على الخادم. لعرض النتائج، استخدم الأداة حصار:

siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io

يبدو أن كل شيء يعمل، ولكن بأي ثمن؟ للوهلة الأولى، لدينا توفر بنسبة 100%، ولكن ألق نظرة فاحصة - الحد الأقصى لمدة المعاملة يصل إلى 12 ثانية. ومن الواضح أن هذا يشكل عنق الزجاجة ويحتاج إلى التوسع.

للقيام بذلك، سوف نستخدم Istio لإزالة الاستدعاءات للحاويات البطيئة. هذا ما يبدو عليه التكوين المقابل باستخدام قاطع الدائرة:

يشير السطر الأخير مع المعلمة httpMaxRequestsPerConnection إلى أنه يجب قطع الاتصال به عند محاولة إنشاء اتصال آخر - اتصال ثانٍ - بالإضافة إلى الاتصال الموجود. نظرًا لأن حاويتنا تحاكي خدمة بطيئة، فستظهر مثل هذه المواقف بشكل دوري، وبعد ذلك سيرجع Istio خطأ 503، ولكن هذا ما سيظهره الحصار:

حسنًا، لدينا قاطع الدائرة الكهربائية، ما هي الخطوة التالية؟

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

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

في المشاركة التالية: سنتحدث عن التتبع والمراقبة المضمنة بالفعل أو التي يمكن إضافتها بسهولة إلى Istio، بالإضافة إلى كيفية إدخال الأخطاء عمدًا في النظام.

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