قابلية وصول عالية لتطبيقات AKS متعددة المستويات

Azure Cosmos DB

Azure Disk Storage

ملفات Azure

خدمة Azure Kubernetes ‏(AKS)

موازن تحميل Azure

يناقش هذا الدليل قابلية الوصول العالية (HA) لنشر التطبيقات متعددة المستويات في مجموعات Azure Kubernetes Service (AKS). توضح المقالة آليات وبنى Kubernetes HA، وتوفر قائمة اختيار وإرشادات لتحديد نقاط فشل قابلية الوصول العالية الفردية والقضاء عليها.

هناك مهمتان أساسيتان لتنفيذ قابلية الوصول العالية لتطبيقات AKS.

• تحديد جميع نقاط الفشل الفردية في التطبيق.
• القضاء على نقاط الفشل الفردية.

يتطلب القضاء على نقاط الفشل الفردية حل قابلية وصول عالية.

ركائز قابلية الوصول العالية الأربعة

تظهر أربعة أعمدة قابلية وصول عالية في كل نظام متوفر بشكل كبير:

• التكرار
• رصد
• الاسترداد
• نقاط التفتيش

ضع في اعتبارك تطبيق AKS متعدد التلميحات، حيث تصل نسبة استخدام الشبكة إلى طبقة منطق العمل، ويحافظ مستوى البيانات على الحالة، ويرجع التطبيق الاستجابات للمستخدمين.

تحديد نقاط الفشل الفردية

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

القضاء على نقاط الفشل الفردية

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

قم بتنزيل ملف Visio لهذا الرسم التخطيطي.

في تطبيق منسوخ نسخا متماثلا:

• يمكنك نسخ مكونات طبقة الأعمال مع أعداد مختلفة من النسخ المتماثلة لكل مكون، اعتمادا على أدائها وعبء العمل.
• يمكنك أيضا نسخ طبقة البيانات خلف موازن تحميل.

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

قائمة اختيار Kubernetes HA

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

ركيزة قابلية الوصول العالية	حل
التكرار	☐ نوع وحدة تحكم Kubernetes ☐ عدد النسخ المتماثلة ☐ جدولة عدم الترابط
مراقبة‬	☐ فحوصات الحياة ☐ فحوصات الجاهزية ☐ فحوصات بدء التشغيل
الاسترداد	☐ نوع الخدمة ☐ انتخاب القائد ☐ إعادة تشغيل النهج ☐ خطافات ما قبل الإيقاف
التحقق	☐ مطالبات الحجم المستمرة ☐ وحدات التخزين الثابتة

التكرار

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

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

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

  من خلال تحديد حدود طلب المورد، spec.containers[].resources، يمكنك إضافة التحجيم التلقائي للجراب الأفقي (HPA)، مما يؤدي إلى قيام Kubernetes تلقائيا بزيادة أو تقليل عدد النسخ المتماثلة استنادا إلى حدود استخدام الموارد التي تحددها. يساعد HPA على تجنب الحالات التي تمنع فيها زيادة الحمل تطبيقك من تقديم الطلبات بسبب التحميل الزائد.

• جدولة عدم الترابط، التكوين spec.affinity.podAntiAffinity. تحتوي مجموعة Kubernetes النموذجية على مستوى الإنتاج على عقد منتشرة عبر مناطق توفر متعددة، يتم التعبير عنها باستخدام topologyKey. يجب أن تكون وحدات الجراب من نفس التوزيع مفضلة أو ناعمة مضادة للترابط مع بعضها البعض. يضمن هذا التكوين جدولة pods على العقد في مناطق توفر مختلفة.

  يمكن أن تحتوي مجموعة AKS على تجمعات عقد متعددة، لكل منها أحجام ومواصفات مجموعة مقياس أجهزة ظاهرية مختلفة. على سبيل المثال، يمكنك استضافة pods قاعدة البيانات الخاصة بك على العقد مع محركات الأقراص ذات الحالة الصلبة السريعة (SSD)، واستضافة pods التعلم الآلي على العقد مع وحدات معالجة الرسومات (GPUs).

مراقبة‬

وبدون المراقبة، يمكن أن يصبح التكرار غير فعال. تحتاج إلى آلية مراقبة مستمرة للتأكد من أن حمل العمل يصل إلى نسخة متماثلة سليمة.

• فحوصات الحياة والتكوينspec.containers.livenessProbe ومراقبة صحة الحجيرات الخاصة بك. إذا تعطل حاوية أو خرجت، يمكن ل Kubernetes اكتشافها. عند فشل الحياة، يعيد Kubernetes تشغيل الحاوية.

• فحوصات الجاهزية، التكوين spec.containers.readinessProbe، تحديد ما إذا كنت تريد إرسال نسبة استخدام الشبكة إلى الجراب. إذا لم تكن أي pods للنشر جاهزة، فلن تكون جزءا من نقاط النهاية لخدمة Kubernetes التي تجريد التوزيع، وبالتالي لن تكون مفيدة. من المهم تعيين فحوصات الجاهزية بعناية، لأنها لا تؤدي إلى إعادة التشغيل، ولكنها تستخدم لعزل الكبسولات عن تلقي نسبة استخدام الشبكة حتى تصبح جاهزة.

• فحوصات بدء التشغيل والتكوينspec.containers.startupProbe ، تمنع بشكل رئيسي الإيجابيات الزائفة للجهوزية والحيوية في تطبيقات البدء البطيء. بمجرد نجاح مسبار بدء التشغيل، يبدأ مسبار الحياة.

يقدم Azure رؤى أعمق تسمح لك بتعيين التنبيهات استنادا إلى صحة نظام المجموعة.

الاسترداد

الغرض الرئيسي من المراقبة هو تشغيل الاسترداد عندما يكتشف فشلا. تتضمن عملية الاسترداد ثلاث مراحل:

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

• نوع الخدمة، التكوين spec.type. يمكن تصنيف الكشف عن القرون الخاصة بك من خلال خدمة ضمن التكرار وكذلك الاسترداد. ومع ذلك، في بعض الحالات، قد يكون لديك نشر نسخة متماثلة واحدة. لا تزال هناك فوائد لكشف الحجيرات من خلال الخدمة، على الرغم من عدم وجود موازنة تحميل.

  الميزة الرئيسية للخدمة هي أن إدخالات خدمة اسم المجال (DNS) يتم تحديثها تلقائيا باستخدام نقاط نهاية خدمة Kubernetes. لن تتلقى الحاوية التي تحتوي على حاويات مع تحقيقات الاستعداد الفاشلة نسبة استخدام الشبكة من خلال AKS. على الرغم من أن قدرة موازنة التحميل لخدمات IP لمجموعة Kubernetes بدائية، يمكنك اقتران خدمة بدون رأس مع حلول شبكة الدخول أو الخدمة الأخرى لموازنة توزيع التحميل بشكل أفضل.

  إن كيفية وصول حركة المرور الخارجية إلى مجموعة AKS خارج نطاق Kubernetes. يمكنك التعامل مع حركة المرور الخارجية باستخدام خدمات مثل Azure Application Gateway.

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

• إعادة تشغيل النهج، التكوين spec.restartPolicy. ينطبق نهج إعادة التشغيل على جميع الحاويات في الحاوية. يجب أن يكون هناك مبرر صالح لتعيين هذه السمة إلى Never. تتصل بعض الحاويات بخادم ترخيص في كل مرة تبدأ فيها، وقد ترغب في تجنب التكاليف الإضافية لإعادة التشغيل المفرطة.

• خطافات ما قبل الإيقاف، التكوين spec.containers.lifecycle.preStop. يتم تشغيل خطافات الإيقاف المسبق قبل SIGTERM إرسال إشارة إلى الحاوية. يمكن أن يكون البرنامج النصي قبل الإيقاف بسيطا مثل أمر السكون 30 ثانية.

  على سبيل المثال، عندما يقوم تطبيق يديره HPA بالتحجيم، قد يتم إنهاء الطلبات قيد التقدم بشكل مفاجئ ما لم يكن لدى التطبيق SIGTERM معالج يكمل تقديم الطلبات قبل الخروج. يقوم خطاف الإيقاف المسبق بإزالة نقطة نهاية الجراب، وبالتالي إدخال DNS، من نقطة نهاية الخدمة. أثناء تشغيل خطاف الإيقاف المسبق، لا يمكن إرسال أي طلبات جديدة إلى pod. يسمح خطاف الإيقاف المسبق للجراب بإنهاء معالجة طلباته قيد التقدم دون تلقي طلبات جديدة. خطافات ما قبل الإيقاف هي طريقة بسيطة لتقليل الطلبات التي تم إسقاطها دون تعديل التعليمات البرمجية للتطبيق.

التحقق

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

يمكنك الاستمرار في حالة التطبيق في ثلاثة مستويات:

• يخزن مستوى سجلات البيانات البيانات في قاعدة بيانات. يمكن نسخ كل سجل قاعدة بيانات عبر مثيلات قاعدة بيانات متعددة. سجلات قاعدة البيانات هي الشكل المهيمن لاستمرار الحالة، خاصة في قواعد البيانات السحابية المدارة مثل Azure Cosmos DB.

• عادة ما يقوم مستوى نظام الملفات بنسخ ملفات البيانات نسخا متماثلا، مثل ملفات تسجيل الكتابة المسبقة (WAL). يقدم معظم موفري السحابة المكونات الإضافية لحلولهم، مثل Azure Files.

• يستمر مستوى القرص في البيانات على مستوى الكتلة، والذي يوفر مرونة لتعريف نظام الملفات المراد استخدامه، كما هو الحال في Azure Disk Storage.

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

قابلية الوصول العالية والإصلاح بعد كارثة

في كل من قابلية الوصول العالية والتعافي من الكوارث (DR)، تعد خيارات طبولوجيا الشبكة وحلول موازنة التحميل مهمة.

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

بدلا من استخدام مناطق متعددة، تستفيد قابلية الوصول العالية من عمليات التوزيع متعددة المناطق داخل مناطق Azure. يوضح الرسم التخطيطي التالي الفرق بين مناطق التوفر ومناطق قابلية الوصول العالية والتعافي من الكوارث.

قم بتنزيل ملف Visio لهذه البنية.

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

اعتبارات أخرى

• للحفاظ على قابلية الوصول العالية للتطبيق، تأكد من توفر مستوى التحكم Kubernetes الخاص بك، بما في ذلك خادم API ومدير وحدة التحكم، بشكل كبير. ضع في اعتبارك استخدام اتفاقية مستوى الخدمة لوقت تشغيل AKS لضمان قابلية الوصول العالية.

• تتعارض استراتيجية دمج الموارد بشكل مباشر مع ركيزة التكرار HA. لذلك، يجب تحليل تكلفة التكرار بعناية. يمكن أن تساعد حاسبة تسعير Azure.

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكاتب الرئيسي:

• علي كانسو | مهندس البرامج الرئيسي

مساهمون آخرون:

• كارثيك سانكارا سوبرامانيان | مهندس برمجيات II
• Kinshuman Patra | مدير هندسة المجموعة الشريكة
• Ayobami Ayodeji | كبير مديري البرنامج
• أوسكار لو بلا ألفاريز | مهندس حلول المجال

لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.

الخطوات التالية

• نمط مجموعة Kubernetes عالي التوفر
• المناطق ومناطق التوفر
• الحصص النسبية وقيود حجم الجهاز الظاهري وتوافر المنطقة في خدمة Azure Kubernetes (AKS)
• تنسيق الخدمات المصغرة والتطبيقات متعددة الحاويات لقابلية التوسع العالية والتوافر
• بنية نظام مجموعة Azure Kubernetes Service (AKS) وعملياته

الموارد ذات الصلة

• خط AKS أساسي لأنظمة مجموعة متعددة المناطق
• بنية الخدمات المصغرة في خدمة Azure Kubernetes
• مراجعة Azure Well-Architected Framework - خدمة Azure Kubernetes (AKS)

يناقش هذا الدليل قابلية الوصول العالية (HA) لنشر التطبيقات متعددة المستويات في مجموعات Azure Kubernetes Service (AKS). توضح المقالة آليات وبنى Kubernetes HA، وتوفر قائمة اختيار وإرشادات لتحديد نقاط فشل قابلية الوصول العالية الفردية والقضاء عليها.

هناك مهمتان أساسيتان لتنفيذ قابلية الوصول العالية لتطبيقات AKS.

• تحديد جميع نقاط الفشل الفردية في التطبيق.
• القضاء على نقاط الفشل الفردية.

يتطلب القضاء على نقاط الفشل الفردية حل قابلية وصول عالية.

ركائز قابلية الوصول العالية الأربعة

تظهر أربعة أعمدة قابلية وصول عالية في كل نظام متوفر بشكل كبير:

• التكرار
• رصد
• الاسترداد
• نقاط التفتيش

ضع في اعتبارك تطبيق AKS متعدد التلميحات، حيث تصل نسبة استخدام الشبكة إلى طبقة منطق العمل، ويحافظ مستوى البيانات على الحالة، ويرجع التطبيق الاستجابات للمستخدمين.

تحديد نقاط الفشل الفردية

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

القضاء على نقاط الفشل الفردية

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

قم بتنزيل ملف Visio لهذا الرسم التخطيطي.

في تطبيق منسوخ نسخا متماثلا:

• يمكنك نسخ مكونات طبقة الأعمال مع أعداد مختلفة من النسخ المتماثلة لكل مكون، اعتمادا على أدائها وعبء العمل.
• يمكنك أيضا نسخ طبقة البيانات خلف موازن تحميل.

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

قائمة اختيار Kubernetes HA

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

ركيزة قابلية الوصول العالية	حل
التكرار	☐ نوع وحدة تحكم Kubernetes ☐ عدد النسخ المتماثلة ☐ جدولة عدم الترابط
مراقبة‬	☐ فحوصات الحياة ☐ فحوصات الجاهزية ☐ فحوصات بدء التشغيل
الاسترداد	☐ نوع الخدمة ☐ انتخاب القائد ☐ إعادة تشغيل النهج ☐ خطافات ما قبل الإيقاف
التحقق	☐ مطالبات الحجم المستمرة ☐ وحدات التخزين الثابتة

التكرار

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

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

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

  من خلال تحديد حدود طلب المورد، spec.containers[].resources، يمكنك إضافة التحجيم التلقائي للجراب الأفقي (HPA)، مما يؤدي إلى قيام Kubernetes تلقائيا بزيادة أو تقليل عدد النسخ المتماثلة استنادا إلى حدود استخدام الموارد التي تحددها. يساعد HPA على تجنب الحالات التي تمنع فيها زيادة الحمل تطبيقك من تقديم الطلبات بسبب التحميل الزائد.

• جدولة عدم الترابط، التكوين spec.affinity.podAntiAffinity. تحتوي مجموعة Kubernetes النموذجية على مستوى الإنتاج على عقد منتشرة عبر مناطق توفر متعددة، يتم التعبير عنها باستخدام topologyKey. يجب أن تكون وحدات الجراب من نفس التوزيع مفضلة أو ناعمة مضادة للترابط مع بعضها البعض. يضمن هذا التكوين جدولة pods على العقد في مناطق توفر مختلفة.

  يمكن أن تحتوي مجموعة AKS على تجمعات عقد متعددة، لكل منها أحجام ومواصفات مجموعة مقياس أجهزة ظاهرية مختلفة. على سبيل المثال، يمكنك استضافة pods قاعدة البيانات الخاصة بك على العقد مع محركات الأقراص ذات الحالة الصلبة السريعة (SSD)، واستضافة pods التعلم الآلي على العقد مع وحدات معالجة الرسومات (GPUs).

مراقبة‬

وبدون المراقبة، يمكن أن يصبح التكرار غير فعال. تحتاج إلى آلية مراقبة مستمرة للتأكد من أن حمل العمل يصل إلى نسخة متماثلة سليمة.

• فحوصات الحياة والتكوينspec.containers.livenessProbe ومراقبة صحة الحجيرات الخاصة بك. إذا تعطل حاوية أو خرجت، يمكن ل Kubernetes اكتشافها. عند فشل الحياة، يعيد Kubernetes تشغيل الحاوية.

• فحوصات الجاهزية، التكوين spec.containers.readinessProbe، تحديد ما إذا كنت تريد إرسال نسبة استخدام الشبكة إلى الجراب. إذا لم تكن أي pods للنشر جاهزة، فلن تكون جزءا من نقاط النهاية لخدمة Kubernetes التي تجريد التوزيع، وبالتالي لن تكون مفيدة. من المهم تعيين فحوصات الجاهزية بعناية، لأنها لا تؤدي إلى إعادة التشغيل، ولكنها تستخدم لعزل الكبسولات عن تلقي نسبة استخدام الشبكة حتى تصبح جاهزة.

• فحوصات بدء التشغيل والتكوينspec.containers.startupProbe ، تمنع بشكل رئيسي الإيجابيات الزائفة للجهوزية والحيوية في تطبيقات البدء البطيء. بمجرد نجاح مسبار بدء التشغيل، يبدأ مسبار الحياة.

يقدم Azure رؤى أعمق تسمح لك بتعيين التنبيهات استنادا إلى صحة نظام المجموعة.

الاسترداد

الغرض الرئيسي من المراقبة هو تشغيل الاسترداد عندما يكتشف فشلا. تتضمن عملية الاسترداد ثلاث مراحل:

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

• نوع الخدمة، التكوين spec.type. يمكن تصنيف الكشف عن القرون الخاصة بك من خلال خدمة ضمن التكرار وكذلك الاسترداد. ومع ذلك، في بعض الحالات، قد يكون لديك نشر نسخة متماثلة واحدة. لا تزال هناك فوائد لكشف الحجيرات من خلال الخدمة، على الرغم من عدم وجود موازنة تحميل.

  الميزة الرئيسية للخدمة هي أن إدخالات خدمة اسم المجال (DNS) يتم تحديثها تلقائيا باستخدام نقاط نهاية خدمة Kubernetes. لن تتلقى الحاوية التي تحتوي على حاويات مع تحقيقات الاستعداد الفاشلة نسبة استخدام الشبكة من خلال AKS. على الرغم من أن قدرة موازنة التحميل لخدمات IP لمجموعة Kubernetes بدائية، يمكنك اقتران خدمة بدون رأس مع حلول شبكة الدخول أو الخدمة الأخرى لموازنة توزيع التحميل بشكل أفضل.

  إن كيفية وصول حركة المرور الخارجية إلى مجموعة AKS خارج نطاق Kubernetes. يمكنك التعامل مع حركة المرور الخارجية باستخدام خدمات مثل Azure Application Gateway.

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

• إعادة تشغيل النهج، التكوين spec.restartPolicy. ينطبق نهج إعادة التشغيل على جميع الحاويات في الحاوية. يجب أن يكون هناك مبرر صالح لتعيين هذه السمة إلى Never. تتصل بعض الحاويات بخادم ترخيص في كل مرة تبدأ فيها، وقد ترغب في تجنب التكاليف الإضافية لإعادة التشغيل المفرطة.

• خطافات ما قبل الإيقاف، التكوين spec.containers.lifecycle.preStop. يتم تشغيل خطافات الإيقاف المسبق قبل SIGTERM إرسال إشارة إلى الحاوية. يمكن أن يكون البرنامج النصي قبل الإيقاف بسيطا مثل أمر السكون 30 ثانية.

  على سبيل المثال، عندما يقوم تطبيق يديره HPA بالتحجيم، قد يتم إنهاء الطلبات قيد التقدم بشكل مفاجئ ما لم يكن لدى التطبيق SIGTERM معالج يكمل تقديم الطلبات قبل الخروج. يقوم خطاف الإيقاف المسبق بإزالة نقطة نهاية الجراب، وبالتالي إدخال DNS، من نقطة نهاية الخدمة. أثناء تشغيل خطاف الإيقاف المسبق، لا يمكن إرسال أي طلبات جديدة إلى pod. يسمح خطاف الإيقاف المسبق للجراب بإنهاء معالجة طلباته قيد التقدم دون تلقي طلبات جديدة. خطافات ما قبل الإيقاف هي طريقة بسيطة لتقليل الطلبات التي تم إسقاطها دون تعديل التعليمات البرمجية للتطبيق.

التحقق

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

يمكنك الاستمرار في حالة التطبيق في ثلاثة مستويات:

• يخزن مستوى سجلات البيانات البيانات في قاعدة بيانات. يمكن نسخ كل سجل قاعدة بيانات عبر مثيلات قاعدة بيانات متعددة. سجلات قاعدة البيانات هي الشكل المهيمن لاستمرار الحالة، خاصة في قواعد البيانات السحابية المدارة مثل Azure Cosmos DB.

• عادة ما يقوم مستوى نظام الملفات بنسخ ملفات البيانات نسخا متماثلا، مثل ملفات تسجيل الكتابة المسبقة (WAL). يقدم معظم موفري السحابة المكونات الإضافية لحلولهم، مثل Azure Files.

• يستمر مستوى القرص في البيانات على مستوى الكتلة، والذي يوفر مرونة لتعريف نظام الملفات المراد استخدامه، كما هو الحال في Azure Disk Storage.

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

قابلية الوصول العالية والإصلاح بعد كارثة

في كل من قابلية الوصول العالية والتعافي من الكوارث (DR)، تعد خيارات طبولوجيا الشبكة وحلول موازنة التحميل مهمة.

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

بدلا من استخدام مناطق متعددة، تستفيد قابلية الوصول العالية من عمليات التوزيع متعددة المناطق داخل مناطق Azure. يوضح الرسم التخطيطي التالي الفرق بين مناطق التوفر ومناطق قابلية الوصول العالية والتعافي من الكوارث.

قم بتنزيل ملف Visio لهذه البنية.

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

اعتبارات أخرى

• للحفاظ على قابلية الوصول العالية للتطبيق، تأكد من توفر مستوى التحكم Kubernetes الخاص بك، بما في ذلك خادم API ومدير وحدة التحكم، بشكل كبير. ضع في اعتبارك استخدام اتفاقية مستوى الخدمة لوقت تشغيل AKS لضمان قابلية الوصول العالية.

• تتعارض استراتيجية دمج الموارد بشكل مباشر مع ركيزة التكرار HA. لذلك، يجب تحليل تكلفة التكرار بعناية. يمكن أن تساعد حاسبة تسعير Azure.

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكاتب الرئيسي:

• علي كانسو | مهندس البرامج الرئيسي

مساهمون آخرون:

• كارثيك سانكارا سوبرامانيان | مهندس برمجيات II
• Kinshuman Patra | مدير هندسة المجموعة الشريكة
• Ayobami Ayodeji | كبير مديري البرنامج
• أوسكار لو بلا ألفاريز | مهندس حلول المجال

لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.

الخطوات التالية

• نمط مجموعة Kubernetes عالي التوفر
• المناطق ومناطق التوفر
• الحصص النسبية وقيود حجم الجهاز الظاهري وتوافر المنطقة في خدمة Azure Kubernetes (AKS)
• تنسيق الخدمات المصغرة والتطبيقات متعددة الحاويات لقابلية التوسع العالية والتوافر
• بنية نظام مجموعة Azure Kubernetes Service (AKS) وعملياته

الموارد ذات الصلة

• خط AKS أساسي لأنظمة مجموعة متعددة المناطق
• بنية الخدمات المصغرة في خدمة Azure Kubernetes
• مراجعة Azure Well-Architected Framework - خدمة Azure Kubernetes (AKS)