من النقاط المهمة في تشغيل الأنظمة الموزعة معالجة الفشل. يساعد Kubernetes في ذلك عن طريق استخدام وحدات التحكم التي تراقب صحة نظامك وتعيد تشغيل الخدمات التي توقفت عن العمل. ومع ذلك، يمكن لـ Kubernetes إيقاف تطبيقاتك بالقوة لضمان سلامة النظام بشكل عام. في هذه السلسلة، سنلقي نظرة على كيفية مساعدة Kubernetes على القيام بعمله بكفاءة أكبر وتقليل وقت توقف التطبيق.
قبل الحاويات، كانت معظم التطبيقات تعمل على الأجهزة الافتراضية أو المادية. إذا تعطل التطبيق أو تجمد، فقد يستغرق الأمر وقتًا طويلاً لإلغاء المهمة قيد التقدم وإعادة تحميل البرنامج. في أسوأ السيناريوهات، كان على شخص ما أن يحل هذه المشكلة يدويًا في الليل، في أكثر الساعات غير المناسبة. إذا كانت هناك آلة أو اثنتين فقط تؤديان مهمة مهمة، فإن مثل هذا التعطيل يكون غير مقبول على الإطلاق.
لذلك، بدلاً من عمليات إعادة التشغيل اليدوية، بدأوا في استخدام المراقبة على مستوى العملية لإعادة تشغيل التطبيق تلقائيًا في حالة الإنهاء غير الطبيعي. إذا فشل البرنامج، فإن عملية المراقبة تلتقط رمز الخروج وتعيد تشغيل الخادم. مع ظهور أنظمة مثل Kubernetes، تم دمج هذا النوع من الاستجابة لفشل النظام ببساطة في البنية التحتية.
يستخدم Kubernetes حلقة حدث مراقبة الاختلاف واتخاذ الإجراء لضمان بقاء الموارد سليمة في طريقها من الحاويات إلى العقد نفسها.
وهذا يعني أنك لم تعد بحاجة إلى تشغيل مراقبة العملية يدويًا. إذا فشل أحد الموارد في اجتياز فحص السلامة، فسيقوم Kubernetes ببساطة بتزويده تلقائيًا ببديل. ومع ذلك، يقوم Kubernetes بأكثر من مجرد مراقبة تطبيقك بحثًا عن حالات الفشل. يمكنه إنشاء المزيد من نسخ التطبيق لتشغيلها على أجهزة متعددة، أو تحديث التطبيق، أو تشغيل إصدارات متعددة من التطبيق الخاص بك في وقت واحد.
لذلك، هناك العديد من الأسباب التي تجعل Kubernetes قادرًا على إنهاء حاوية صحية تمامًا. على سبيل المثال، إذا قمت بترقية النشر الخاص بك، فسوف يقوم Kubernetes بإيقاف البودات القديمة ببطء أثناء بدء تشغيل البودات الجديدة. إذا قمت بإيقاف تشغيل عقدة، فسيتوقف Kubernetes عن تشغيل جميع البودات على تلك العقدة. أخيرًا، إذا نفدت موارد العقدة، فسيقوم Kubernetes بإغلاق جميع البودات لتحرير تلك الموارد.
لذلك، من المهم أن يتم إنهاء تطبيقك بأقل قدر من التأثير على المستخدم النهائي وبأقل وقت للاسترداد. وهذا يعني أنه قبل إيقاف التشغيل، يجب حفظ جميع البيانات التي يجب حفظها، وإغلاق جميع اتصالات الشبكة، وإكمال العمل المتبقي، وإدارة المهام العاجلة الأخرى.
من الناحية العملية، هذا يعني أن التطبيق الخاص بك يجب أن يكون قادرًا على التعامل مع رسالة SIGTERM، وهي إشارة إنهاء العملية التي تعد الإشارة الافتراضية لأداة الإيقاف المساعدة على أنظمة تشغيل Unix. عند تلقي هذه الرسالة، يجب إيقاف تشغيل التطبيق.
بمجرد أن يقرر Kubernetes إنهاء الكبسولة، يحدث عدد من الأحداث. دعونا نلقي نظرة على كل خطوة يتخذها Kubernetes عند إغلاق حاوية أو حجرة.
لنفترض أننا نريد إنهاء إحدى القرون. عند هذه النقطة، سيتوقف عن استقبال حركة المرور الجديدة - لن تتأثر الحاويات التي تعمل في الكبسولة، ولكن سيتم حظر كل حركة المرور الجديدة.
دعونا نلقي نظرة على خطاف preStop، وهو أمر خاص أو طلب HTTP يتم إرساله إلى الحاويات الموجودة في حجرة. إذا لم يتم إيقاف تشغيل تطبيقك بشكل صحيح عند تلقي SIGTERM، فيمكنك استخدام preStop لإيقاف التشغيل بشكل صحيح.
ستخرج معظم البرامج بأمان عندما تتلقى إشارة SIGTERM، ولكن إذا كنت تستخدم تعليمات برمجية لجهة خارجية أو نظامًا لا تتحكم فيه بشكل كامل، فإن خطاف preStop يعد طريقة رائعة لفرض إيقاف التشغيل بسلاسة دون تغيير التطبيق.
بعد تنفيذ هذا الخطاف، سيرسل Kubernetes إشارة SIGTERM إلى الحاويات الموجودة في الكبسولة، لإعلامهم بأنه سيتم قطع اتصالهم قريبًا. عند تلقي هذه الإشارة، سينتقل الرمز الخاص بك إلى عملية إيقاف التشغيل. قد تتضمن هذه العملية إيقاف أي اتصالات طويلة الأمد مثل اتصال قاعدة البيانات أو دفق WebSocket، وحفظ الحالة الحالية، وما شابه.
حتى إذا كنت تستخدم خطاف preStop، فمن المهم جدًا التحقق مما يحدث بالضبط لتطبيقك عندما ترسل إليه إشارة SIGTERM، وكيف يتصرف، بحيث لا تأتي الأحداث أو التغييرات في تشغيل النظام الناتجة عن إيقاف تشغيل الكبسولة كما هي. مفاجأة لك.
في هذه المرحلة، سينتظر Kubernetes فترة زمنية محددة، تسمى ternationGracePeriodSecond، أو فترة إيقاف التشغيل بأمان عندما يتلقى إشارة SIGTERM، قبل اتخاذ المزيد من الإجراءات.
بشكل افتراضي، هذه الفترة هي 30 ثانية. من المهم ملاحظة أنه يعمل بالتوازي مع خطاف preStop وإشارة SIGTERM. لن ينتظر Kubernetes حتى انتهاء خطاف preStop وSIGTERM - إذا خرج تطبيقك قبل انتهاء TerminatingGracePeriod، فسينتقل Kubernetes على الفور إلى الخطوة التالية. لذلك، تأكد من أن قيمة هذه الفترة بالثواني لا تقل عن الوقت اللازم لإغلاق الكبسولة بشكل صحيح، وإذا تجاوزت 30 ثانية، قم بزيادة الفترة إلى القيمة المطلوبة في YAML. في المثال المعطى، هو 60S.
وأخيرًا، الخطوة الأخيرة هي أنه إذا كانت الحاويات لا تزال قيد التشغيل بعد إنهاءGracePeriod، فسوف ترسل إشارة SIGKILL وسيتم حذفها قسرًا. في هذه المرحلة، سيقوم 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