الإصلاح التلقائي لعقد خدمة خدمة Azure Kubernetes ‏(AKS)

ينطبق على: ✔️ AKS ✔️ Automatic Standard

تراقب خدمة Azure Kubernetes (AKS) الحالة الصحية للعقد العاملة باستمرار وتنفذ إصلاحا تلقائيا للعقد إذا أصبحت غير صحية. يُجري النظام الأساسي للجهاز الظاهري Azure (VM) الصيانة للأجهزة الظاهرية التي تواجه مشكلات. تعمل AKS وأجهزة Azure الظاهرية معًا لتقليل انقطاعات الخدمة للمجموعات.

بالنسبة لمعظم أعباء العمل الإنتاجية، تعتبر AKS Automatic تجربة الإعداد الجاهزة للإنتاج الموصى بها ل AKS. تأتي عناقيد AKS Automatic وAKS Standard مجهزة مسبقا مع إصلاح تلقائي للعقد.

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

سلوك الإصلاح التلقائي للعقدة حسب وضع العنقود

كلا وضعي عنقود AKS يأتون مجهزين مسبقا مع إصلاح تلقائي للعقدة:

  • AKS Automatic: تم تعيينه مسبقا كجزء من الإعدادات الافتراضية الجاهزة للإنتاج من AKS Auto.
  • AKS ستاندرد: تم إعدادها مسبقا على عناقيد AKS Standard دون إعداد إضافي.

كلا الوضعين يستخدمان نفس فحوصات صحة العقدة ونفس تسلسل الإصلاح الموضح في هذا المقال.

لمزيد من المعلومات حول إعدادات الإعداد التلقائي لمنصة AKS، انظر ما هو خدمة Azure Kubernetes ‏(AKS) Automatic?

كيف تتحقق AKS من عقد NotReady

تستخدم AKS القواعد التالية لتحديد ما إذا كانت العقدة غير صحية وتحتاج إلى إصلاح:

  • تبلغ العقدة عن حالة NotReady عند عمليات التحقق المتتالية ضمن إطار زمني مدته 10 دقائق.
  • العقدة لا تبلغ عن أي حالة في غضون 10 دقائق.

يمكنك التحقق يدويا من الحالة الصحية للعقد باستخدام kubectl get nodes الأمر .

كيف يعمل الإصلاح التلقائي

إشعار

تبدأ AKS عمليات الإصلاح باستخدام حساب المستخدم aks-remediator.

إذا حدد AKS عقدة غير صحية تبقى غير صحية لمدة لا تقل عن خمس دقائق، يقوم AKS بتنفيذ الإجراءات التالية:

  1. تقوم AKS بإعادة تشغيل العقدة.
  2. إذا بقيت العقدة غير صحية بعد إعادة التشغيل، يقوم AKS بإعادة رسم العقدة.
  3. إذا بقيت العقدة غير سليمة بعد إعادة التصوير وكانت عقدة لينكس، يقوم AKS بإعادة نشر العقدة.

يعيد AKS محاولة إعادة التشغيل، وإعادة الصور، وإعادة النشر حتى ثلاث مرات إذا بقيت العقدة غير صحية. قد تستغرق عملية إصلاح السيارات بشكل عام حتى ساعة واحدة لإكمالها.

اعتبارات الإنتاج

الإصلاح التلقائي للعقد هو آلية أساسية للمرونة، ولكن ادمجها مع ممارسات المرونة على مستوى عبء العمل:

  • شغل أحمال العمل الحرجة مع عدة نسخ مقلدة.
  • استخدم البود: التغييراتالميزانيات ومجسات الجاهزية لتقليل التأثير المرئي للمستخدم.
  • مراقبة نشاط الإصلاح وأحداث الخطأ لاكتشاف المشاكل المتكررة في العقد.
  • دمج توقيت إصلاح السيارات في تخطيط SLO/SLA والاستجابة للحوادث.

القيود

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

قد لا تقوم AKS بالإصلاح التلقائي في السيناريوهات التالية:

  • يمنع خطأ في تكوين الشبكة الإبلاغ عن حالة العقدة.
  • تفشل العقدة في التسجيل كعقدة سليمة.
  • العقدة تحتوي على أحد اللوثات التالية:
    • node.cloudprovider.kubernetes.io/shutdown
    • ToBeDeletedByClusterAutoscaler
  • يتم ترقية العقدة وتحتوي على التعليقات التالية:
    • "cluster-autoscaler.kubernetes.io/scale-down-disabled": "true"
    • "kubernetes.azure.com/azure-cluster-autoscaler-scale-down-disabled-reason": "upgrade"

مراقبة الإصلاح التلقائي للعقدة باستخدام أحداث Kubernetes

عندما يقوم AKS بإصلاح تلقائي للعقدة، فإنه يصدر أحداث Kubernetes من المصدر aks-auto-repair . تظهر الأحداث التالية على كائن العقدة عند حدوث الإصلاح التلقائي.

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

السبب رسالة الحدث ‏‏الوصف
NodeRebootStart الإصلاح التلقائي للعقدة يبدأ إجراء إعادة التشغيل بسبب استمرار حالة عدم الاستعداد لأكثر من خمس دقائق. هذا الحدث ينبهك عندما يكون إعادة التشغيل على عقدتك. هذا الإجراء هو الأول في تسلسل الإصلاح التلقائي للعقدة بشكل عام.
NodeRebootEnd اكتمل إجراء إعادة التشغيل من الإصلاح التلقائي للعقدة. يتم إصدارها بمجرد اكتمال إعادة التشغيل على العقدة. لا يشير هذا الحدث إلى الحالة الصحية (صحية أو غير صحية) للعقدة بعد تنفيذ إعادة التشغيل.
NodeReimageStart الإصلاح التلقائي للعقدة يبدأ إجراء إعادة التصوير بسبب استمرار حالة عدم الاستعداد لأكثر من خمس دقائق. هذا الحدث ينبهك عندما يكون إعادة التصوير على عقدتك على وشك الإعادة.
NodeReimageEnd اكتمل إجراء إعادة تعيين من الإصلاح التلقائي للعقدة. يتم إرسالها بمجرد اكتمال إعادة الصورة على العقدة. لا يشير هذا الحدث إلى الحالة الصحية (صحية أو غير صحية) للعقدة بعد تنفيذ إعادة الصورة.
NodeRedeployStart الإصلاح التلقائي للعقدة يبدأ عملية إعادة نشر بسبب استمرار حالة عدم الاستعداد لأكثر من خمس دقائق. هذا الحدث يخبرك عندما يكون إعادة النشر على عقدتك على وشك التنفيذ. إعادة النشر هي الإجراء الأخير في تسلسل الإصلاح التلقائي للعقدة.
NodeRedeployEnd اكتمل إجراء إعادة التوزيع من الإصلاح التلقائي للعقدة. يتم إرسالها بمجرد اكتمال إعادة النشر على العقدة. لا يشير هذا الحدث إلى الحالة الصحية (صحية أو غير صحية) للعقدة بعد تنفيذ إعادة التوزيع.

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

إشعار

تختلف رموز الخطأ في رسائل الأحداث التالية بناء على الخطأ المبلغ عنه.

السبب رسالة الحدث ‏‏الوصف
NodeRebootError فشل إجراء إعادة تشغيل الإصلاح التلقائي للعقدة بسبب فشل العملية. راجع تفاصيل الخطأ هنا: رمز الخطأ يتم إصداره عند وجود خطأ في إجراء إعادة التشغيل.
NodeReimageError فشل إجراء إعادة تعيين الإصلاح التلقائي للعقدة بسبب فشل العملية. راجع تفاصيل الخطأ هنا: رمز الخطأ يتم إصداره عندما يكون هناك خطأ في إجراء إعادة الصورة.
NodeRedeployError فشل إجراء إعادة نشر الإصلاح التلقائي للعقدة بسبب فشل العملية. راجع تفاصيل الخطأ هنا: رمز الخطأ يتم إصداره عندما يكون هناك خطأ في إجراء إعادة النشر.

المحتوى ذو الصلة

  • Last updated on