مشاركة عبر


الموثوقية في خدمة Azure Kubernetes (AKS)

خدمة Azure Kubernetes Service (AKS) هي خدمة تنسيق حاويات مدارة تبسط نشر وإدارة وعمليات Kubernetes.

عند استخدام Azure، تعد الموثوقية مسؤولية مشتركة. توفر Microsoft مجموعة من الإمكانات لدعم المرونة والاسترداد. أنت مسؤول عن فهم كيفية عمل هذه الإمكانات في جميع الخدمات التي تستخدمها، وتحديد الإمكانات التي تحتاجها لتحقيق أهداف عملك وأهداف وقت التشغيل.

تصف هذه المقالة كيفية جعل Azure Kubernetes Service (AKS) مقاومة لمجموعة متنوعة من الانقطاعات والمشاكل المحتملة، بما في ذلك الأعطال المؤقتة، انقطاعات مناطق التوافر، وانقطاعات المناطق. كما يشرح كيف يمكنك استخدام النسخ الاحتياطية للتعافي من أنواع أخرى من المشاكل، ويبرز بعض المعلومات الأساسية حول اتفاقية مستوى الخدمة (SLA) لخدمة Azure Kubernetes (AKS).

توصيات نشر الإنتاج

للحصول على توصيات حول كيفية نشر أحمال عمل إنتاج موثوق بها في AKS، راجع المقالات التالية:

نظرة عامة على بنية الموثوقية

عند إنشاء نظام مجموعة AKS، يقوم النظام الأساسي Azure تلقائيا بإنشاء وتكوين:

  • وحدة التحكم التي تحتوي على خادم API، وما إلى ذلك، والمجدول، ووحدات الجراب الأخرى المطلوبة لإدارة حمل العمل الخاص بك.

  • تجمع عقدة النظام إلى اشتراكك الذي يستضيف الوظائف الإضافية والقرون الأخرى التي تعمل في مساحة اسم نظام kube.

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

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

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

  • تدير Microsoft وحدة التحكم والمكونات الأخرى المدارة من AKS.

  • تقع على عاتقك مسؤولية:

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

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

المرونة في مواجهة الأعطال العابرة

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

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

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

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

  • قم بتعيين ميزانيات تعطيل الجراب (PDBs) في pod YAML لتحديد عدد pods التي تحتاجها في حالة في Ready وقت معين. عند تعيين PDBs، تضمن AKS الحد الأدنى من توفر النسخ المتماثلة عند تشغيل العمليات لتطويق العقد واستنزافها. إذا تعذر استيفاء PDB أثناء عمليات مثل الترقيات، تستمر الحاوية في العمل وقد تفشل العملية. لمزيد من المعلومات، راجع PDBs.
  • استخدم maxUnavailable لتحديد الحد الأقصى لعدد النسخ المتماثلة التي يمكن أن تصبح غير متوفرة في وقت معين. على سبيل المثال، عند إجراء إعادة تشغيل متداولة، تضمن AKS أنه لا يتم تدحرج أكثر من maxUnavailable عدد pods في وقت معين. لمزيد من المعلومات، راجع maxUnavailable.
  • اتبع أفضل ممارسات النشر. يمكن أن تفشل النسخ المتماثلة للجراب أيضا بسبب مشاكل التطبيق. لمزيد من المعلومات، راجع أفضل الممارسات على مستوى التوزيع لموثوقية نظام مجموعة AKS.

‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫‏‫ملاحظة

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

المرونة في مواجهة حالات فشل منطقة التوفر

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

عند نشر نظام مجموعة AKS في منطقة تدعم مناطق التوفر، تتطلب المكونات المختلفة أنواعا مختلفة من التكوين.

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

Requirements

دعم المنطقة: يمكنك نشر مجموعات AKS مقاومة للمناطق في أي منطقة تدعم مناطق التوفر.

الاعتبارات

لتحسين موثوقية ومرونة أحمال عمل إنتاج AKS في منطقة ما، تحتاج إلى تكوين AKS لتكرار المنطقة عن طريق إجراء التكوينات التالية:

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

  • تمكين التحجيم التلقائي. توفر تجمعات عقد Kubernetes خيارات تحجيم يدوية وتلقائية. باستخدام التحجيم اليدوي، يمكنك إضافة العقد أو حذفها حسب الحاجة، وتنتظر القرون المعلقة حتى تقوم بتوسيع نطاق تجمع عقدة. يستخدم التحجيم المدار بواسطة AKS التحجيم التلقائي لنظام المجموعة أو التوفير التلقائي للعقدة (NAP). تقوم AKS بتحجيم تجمع العقدة لأعلى أو لأسفل استنادا إلى متطلبات الجراب ضمن الحصة النسبية ل SKU الخاصة باشتراكك وسعته. يساعد هذا الأسلوب على التأكد من جدولة pods الخاصة بك على العقد المتوفرة في مناطق التوفر.

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

  • تكوين شبكة مرنة للمنطقة. إذا كانت وحدات الجراب الخاصة بك تخدم نسبة استخدام الشبكة الخارجية، فكون بنية شبكة نظام المجموعة باستخدام خدمات مثل Azure Application Gateway أو Azure Load Balancer أو Azure Front Door.

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

التكلفة

لا توجد رسوم إضافية لتمكين دعم منطقة التوفر في AKS. تدفع مقابل الأجهزة الظاهرية (VMs) والموارد الأخرى التي تقوم بنشرها في مناطق التوفر.

تكوين دعم منطقة التوفر

  • إنشاء نظام مجموعة AKS جديد يحتوي على دعم منطقة التوفر: لتكوين دعم منطقة التوفر، راجع إنشاء مجموعة Azure Kubernetes Service (AKS) التي تستخدم مناطق التوفر.
  • هجرة: لا يمكنك تمكين دعم منطقة التوفر بعد إنشاء نظام مجموعة. بدلا من ذلك، تحتاج إلى إنشاء مجموعة جديدة تم تمكين دعم منطقة التوفر بها وحذف المجموعة الموجودة.
  • تعطيل دعم منطقة التوفر: لا يمكنك تعطيل دعم منطقة التوفر بعد إنشاء نظام مجموعة. بدلا من ذلك، تحتاج إلى إنشاء نظام مجموعة جديد يحتوي على دعم منطقة التوفر معطل وحذف نظام المجموعة الموجود.

السلوك عندما تكون جميع المناطق صحية

يصف هذا القسم ما يمكن توقعه عندما يتم تكوين عناقيد AKS لدعم مناطق التوافر وتكون جميع مناطق التوافر عاملة.

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

  • النسخ المتماثل للبيانات بين المناطق: إذا قمت بتشغيل حمل عمل عديم الحالة، فيجب عليك استخدام خدمات Azure المدارة، مثل قواعد بيانات Azure أو ذاكرة التخزين المؤقت Azure ل Redis أو Azure Storage لتخزين بيانات التطبيق. يمكنك استخدام هذه الخدمات للمساعدة في ضمان إمكانية نقل نسبة استخدام الشبكة عبر العقد والمناطق دون المخاطرة بفقدان البيانات أو التأثير على تجربة المستخدم. يمكنك استخدام عمليات توزيع Kubernetes والخدماتوفحوصات السلامة لإدارة القرون عديمة الحالة وضمان التوزيع حتى عبر المناطق.

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

السلوك أثناء فشل المنطقة

يصف هذا القسم ما يمكن توقعه عند حدوث انقطاع في منطقة التوافر أثناء تكوين عناقيد AKS مع دعم منطقة التوافر.

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

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

  • الإعلام: لا تقوم Microsoft بإعلامك تلقائيا عندما تكون المنطقة معطلة. ومع ذلك، يمكنك استخدام Azure Resource Health لمراقبة صحة كل مورد على حدة، ويمكنك إعداد تنبيهات Resource Health لإبلاغك بالمشاكل. يمكنك أيضا استخدام Azure Service Health لفهم الصحة العامة للخدمة، بما في ذلك أي أعطال في المناطق، ويمكنك إعداد تنبيهات صحة الخدمة لإبلاغك بالمشاكل.

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

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

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

  • وقت التعطل المتوقع: إذا قمت بتكوين مرونة المنطقة لنظام المجموعة والقرون بشكل صحيح، فلا يتوقع أن يتسبب فشل المنطقة في حدوث وقت تعطل لحمل عمل AKS.

  • إعادة توجيه حركة المرور: تعيد موازنات التحميل توجيه الطلبات الواردة الجديدة إلى pods التي تعمل على العقد السليمة.

لمزيد من المعلومات، راجع اعتبارات مرونة المنطقة ل AKS.

استعادة المنطقة

عند استرداد منطقة التوفر، يعتمد سلوك إرجاع الموارد على المكون:

  • وحدة التحكم: تستعيد AKS تلقائيا عمليات وحدة التحكم عبر جميع مناطق التوفر. لا يلزم التدخل اليدوي.

  • تجمعات العقد والعقد: بعد إرجاع الموارد مباشرة، تظل العقد في المناطق السليمة سابقا ولا تتم استعادتها في المنطقة المستردة. ومع ذلك، في المرة التالية التي تقوم فيها بعملية تحجيم العقدة، مثل عند توسيع نطاق تجمع العقدة، يمكن لتجمع العقدة إنشاء عقد في المنطقة المستردة.

  • السنفات: مباشرة بعد إرجاع الموارد، تستمر الحجيرات في العمل على العقد التي تعمل عليها حاليا. عند إنشاء pods جديدة أو إعادة إنشاء وحدات الجراب الموجودة، تكون مؤهلة لاستخدام العقد في المنطقة المستردة.

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

اختبار فشل المنطقة

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

القدرة على الصمود في وجه الإخفاقات على مستوى المنطقة

مجموعات AKS هي موارد منطقة واحدة. إذا كانت المنطقة غير متوفرة، فإن نظام مجموعة AKS الخاص بك غير متوفر أيضا.

حلول مخصصة متعددة المناطق للمرونة

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

  • استخدم Azure Kubernetes Fleet Manager إذا كنت تريد تجربة أبسط مدارة. باستخدام Azure Kubernetes Fleet Manager، يمكنك:

    • إدارة مجموعة من مجموعات AKS كوحدة واحدة، ويمكن توزيع هذه المجموعات عبر مناطق Azure متعددة.

    • أتمتة جوانب معينة من إدارة نظام المجموعة، مثل ترقيات صورة نظام المجموعة والعقدة.

    • استخدم قدرات توزيع نسبة استخدام الشبكة لنشر نسبة استخدام الشبكة عبر المجموعات وتجاوز الفشل تلقائيا إذا كانت المنطقة غير متوفرة.

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

النسخ الاحتياطي والاستعادة

يحتوي Azure Backup على ملحق يمكنك استخدامه لنسخ موارد نظام مجموعة AKS احتياطيا ووحدات التخزين الثابتة التي يتم إرفاقها بالمجموعة. يتصل مخزن النسخ الاحتياطي بمجموعة AKS من خلال الملحق لتنفيذ عمليات النسخ الاحتياطي والاستعادة.

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

لمزيد من المعلومات، راجع المقالات التالية:

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

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

المرونة في صيانة الخدمة

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

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

اتفاقية مستوى الخدمة

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

توفر AKS ثلاثة مستويات تسعير لإدارة نظام المجموعة: FreeوStandardوPremium. تمكنك الطبقة المجانية من استخدام AKS لاختبار أحمال العمل الخاصة بك. تم تصميم المستويين Standard وPremium لأحمال عمل الإنتاج. عند نشر مجموعة AKS التي تم تمكين مناطق التوفر بها، تزداد نسبة وقت التشغيل المحددة في اتفاقية مستوى الخدمة. ومع ذلك، لا تنطبق اتفاقية مستوى الخدمة إلا إذا قمت بنشر نظام مجموعة في مستوى التسعير القياسي أو المتميز.