نظرة عامة على قابلية الوصول العالية والتعافي من الكوارث لخدمة Azure Kubernetes (AKS)

عند إنشاء التطبيقات وإدارتها في السحابة، هناك دائما خطر التعطيل من الانقطاعات والكوارث. لضمان استمرارية الأعمال (BC)، تحتاج إلى التخطيط لقابلية الوصول العالية (HA) والتعافي من الكوارث (DR).

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

تتناول هذه المقالة بعض الممارسات الموصى بها للتطبيقات المنشورة في AKS، ولكنها ليست بأي حال من الأحوال قائمة شاملة بالحلول الممكنة.

نظرة عامة على التقنية

ينقسم نظام مجموعة Kubernetes إلى مكونين أساسيين:

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

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

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

لتشغيل التطبيقات والخدمات الداعمة، تحتاج إلى عقدة Kubernetes. نظام مجموعة AKS على عقدة واحدة على الأقل، جهاز ظاهري Azure الذي يقوم بتشغيل مكونات عقدة Kubernetes ووقت تشغيل الحاوية. يحدد حجم Azure VM للعقد وحدات المعالجة المركزية والذاكرة والحجم ونوع التخزين المتوفر (مثل SSD عالي الأداء أو HDD العادي). خطط للجهاز الظاهري وحجم التخزين حول ما إذا كانت تطبيقاتك قد تتطلب كميات كبيرة من وحدة المعالجة المركزية والذاكرة أو تخزين عالي الأداء. في AKS، تستند صورة الجهاز الظاهري لعقد نظام المجموعة إلى Ubuntu Linux أو Azure Linux أو Windows Server 2022. عند إنشاء نظام مجموعة AKS أو توسيع عدد العقد، يعمل النظام الأساسي Azure تلقائيًا على إنشاء وتكوين عدد الأجهزة الظاهرية المطلوبة.

لمزيد من المعلومات حول مكونات نظام المجموعة وأحمال العمل في AKS، راجع مفاهيم Kubernetes الأساسية ل AKS.

اعتبارات هامة

الموارد الإقليمية والعالمية

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

تشترك الموارد العالمية في عمر النظام، ويمكن أن تكون متاحة عالميا في سياق نشر متعدد المناطق. لمزيد من المعلومات، راجع الموارد العمومية.

أهداف الاسترداد

يجب أن تحدد خطة التعافي من الكوارث الكاملة متطلبات العمل لكل عملية ينفذها التطبيق:

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

مجموعات التوافر

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

المرونة المناطقية

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

موازنة الأحمال

موازنة التحميل العالمية

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

• Azure Front Door
• مدير حركة بيانات Azure
• موازن تحميل Azure عبر المناطق
• Azure Kubernetes Fleet Manager

موازنة التحميل الإقليمية

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

• موازن تحميل Azure
• Azure Application Gateway
• بوابة تطبيق Azure للحاويات

الملاحظة

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

تعريف النطاق

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

• التخطيط لمجموعات AKS في مناطق متعددة.
• توجيه نسبة استخدام الشبكة عبر مجموعات متعددة باستخدام Azure Traffic Manager.
• استخدم النسخ المتماثل الجغرافي لسجلات صور الحاوية الخاصة بك.
• التخطيط لحالة التطبيق عبر مجموعات متعددة.
• نسخ التخزين عبر مناطق متعددة.

تطبيقات نموذج التوزيع

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

نموذج نشر قابلية وصول عالية نشطة-نشطة

في نموذج توزيع قابلية الوصول العالية النشطة-النشطة (HA)، لديك مجموعتان مستقلتان من AKS تم توزيعهما في منطقتين مختلفتين من مناطق Azure (عادة ما تكون مناطق مقترنة، مثل Canada Central و Canada East أو US East 2 و US Central) التي تخدم حركة المرور بشكل نشط.

باستخدام هذا المثال للبنية:

• يمكنك نشر نظامي مجموعات AKS في مناطق Azure منفصلة.
• أثناء العمليات العادية، يتم توجيه نسبة استخدام الشبكة بين المنطقتين. إذا أصبحت إحدى المناطق غير متوفرة، يتم توجيه حركة المرور تلقائيا إلى منطقة أقرب إلى المستخدم الذي أصدر الطلب.
• هناك زوج موزع محوري لكل مثيل AKS إقليمي. تدير نهج Azure Firewall Manager قواعد جدار الحماية عبر المناطق.
• يتم توفير Azure Key Vault في كل منطقة لتخزين الأسرار والمفاتيح.
• يوازن Azure Front Door تحميل نسبة استخدام الشبكة ويوجهها إلى مثيل Azure Application Gateway إقليمي، والذي يقع أمام كل مجموعة AKS.
• تخزن مثيلات Log Analytics الإقليمية مقاييس الشبكات الإقليمية وسجلات التشخيص.
• يتم تخزين صور الحاوية لحمل العمل في سجل حاوية مدار. يتم استخدام Azure Container Registry واحد لجميع مثيلات Kubernetes في نظام المجموعة. يتيح النسخ المتماثل الجغرافي ل Azure Container Registry نسخ الصور نسخا متماثلا إلى مناطق Azure المحددة ويوفر وصولا مستمرا إلى الصور، حتى إذا واجهت المنطقة انقطاعا.

لإنشاء نموذج توزيع نشط-نشط في AKS، يمكنك تنفيذ الخطوات التالية:

1. إنشاء توزيعين متطابقين في منطقتين مختلفتين من Azure.

2. إنشاء مثيلين لتطبيق الويب الخاص بك.

3. إنشاء ملف تعريف Azure Front Door بالموارد التالية:

   • نقطة نهاية.
   • مجموعتان أصل، كل منهما ذات أولوية واحدة.
   • مسار.

4. تقييد نسبة استخدام الشبكة لتطبيقات الويب فقط من مثيل Azure Front Door. 5. تكوين جميع خدمات Azure الخلفية الأخرى، مثل قواعد البيانات وحسابات التخزين وموفري المصادقة.

5. نشر التعليمات البرمجية لكلا تطبيقي الويب مع النشر المستمر.

لمزيد من المعلومات، راجع نظرة عامة على حل التوفر العالي النشط النشط الموصى به ل AKS.

نموذج نشر التعافي من الكوارث النشط السلبي

في نموذج نشر التعافي من الكوارث (DR) النشط السلبي، لديك مجموعتان مستقلتان من AKS تم توزيعهما في منطقتين مختلفتين من مناطق Azure (عادة ما تكون مناطق مقترنة، مثل Canada Central و Canada East أو US East 2 و US Central) التي تخدم حركة المرور بنشاط. واحد فقط من المجموعات يخدم حركة المرور بنشاط في أي وقت. تحتوي المجموعة الأخرى على نفس بيانات التكوين والتطبيق مثل المجموعة النشطة، ولكنها لا تقبل نسبة استخدام الشبكة ما لم يوجهها مدير حركة المرور.

باستخدام هذا المثال للبنية:

• يمكنك نشر نظامي مجموعات AKS في مناطق Azure منفصلة.
• أثناء العمليات العادية، توجه حركة مرور الشبكة إلى مجموعة AKS الأساسية، والتي قمت بتعيينها في تكوين Azure Front Door.
  • يجب تعيين الأولوية بين 1-5 مع أن يكون 1 هو الأعلى و5 أقل.
  • يمكنك تعيين مجموعات متعددة إلى نفس مستوى الأولوية ويمكنك تحديد وزن كل منها.
• إذا أصبحت المجموعة الأساسية غير متوفرة (تحدث كارثة)، توجه حركة المرور تلقائيا إلى المنطقة التالية المحددة في Azure Front Door.
  • يجب أن تمر جميع نسبة استخدام الشبكة من خلال مدير حركة مرور Azure Front Door لكي يعمل هذا النظام.
• يوجه Azure Front Door نسبة استخدام الشبكة إلى Azure App Gateway في المنطقة الأساسية (يجب وضع علامة على نظام المجموعة بالأولوية 1). إذا فشلت هذه المنطقة، تعيد الخدمة توجيه نسبة استخدام الشبكة إلى نظام المجموعة التالي في قائمة الأولوية.
  • تأتي القواعد من Azure Front Door.
• يتم نشر زوج النظام المحوري لكل مثيل AKS إقليمي. تدير نهج Azure Firewall Manager قواعد جدار الحماية عبر المناطق.
• يتم توفير Azure Key Vault في كل منطقة لتخزين الأسرار والمفاتيح.
• تخزن مثيلات Log Analytics الإقليمية مقاييس الشبكات الإقليمية وسجلات التشخيص.
• يتم تخزين صور الحاوية لحمل العمل في سجل حاوية مدار. يتم استخدام Azure Container Registry واحد لجميع مثيلات Kubernetes في نظام المجموعة. يتيح النسخ المتماثل الجغرافي ل Azure Container Registry نسخ الصور نسخا متماثلا إلى مناطق Azure المحددة ويوفر وصولا مستمرا إلى الصور، حتى إذا واجهت المنطقة انقطاعا.

لإنشاء نموذج نشر نشط-سلبي في AKS، يمكنك تنفيذ الخطوات التالية:

1. إنشاء توزيعين متطابقين في منطقتين مختلفتين من Azure.

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

3. إنشاء مثيلين لتطبيق الويب الخاص بك، مع مثيل واحد على كل نظام مجموعة.

4. إنشاء ملف تعريف Azure Front Door بالموارد التالية:

   • نقطة نهاية.
   • مجموعة أصل ذات أولوية واحدة للمنطقة الأساسية.
   • مجموعة أصل ثانية ذات أولوية اثنين للمنطقة الثانوية.
   • مسار.

5. تقييد نسبة استخدام الشبكة لتطبيقات الويب من مثيل Azure Front Door فقط.

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

7. نشر التعليمات البرمجية لكل من تطبيقات الويب مع النشر المستمر.

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

نموذج توزيع تجاوز الفشل السلبي البارد

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

باستخدام هذا المثال للبنية:

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

لإنشاء نموذج توزيع تجاوز الفشل الخامل البارد في AKS، يمكنك تنفيذ الخطوات التالية:

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

لمزيد من المعلومات، راجع نظرة عامة على حل تجاوز الفشل السلبي البارد الموصى به ل AKS.

حصص الخدمة وحدودها

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

Resource	الحد
المجموعات القصوى لكل اشتراك	5,000 ملاحظة: توزيع المجموعات عبر مناطق مختلفة لحساب حدود تقييد واجهة برمجة تطبيقات Azure
الحد الأقصى للعقد لكل مجموعة مع مجموعات مقياس الجهاز الظاهري ووحدة حفظ المخزون لموازن التحميل القياسي	5000 عبر جميع تجمعات العقد ملاحظة: إذا لم تتمكن من توسيع نطاق ما يصل إلى 5000 عقدة لكل مجموعة، فشاهد أفضل الممارسات للمجموعات الكبيرة.
الحد الأقصى للعقد لكل تجمع عقدة (تجمعات عقد مجموعات مقياس الجهاز الظاهري)	1000
الحد الأقصى لتجمعات العقد لكل مجموعة	100
الحد الأقصى للقرون لكل عقدة: مع المكون الإضافيلشبكة Kubenet 1	الحد الأقصى: 250 Azure CLI الافتراضي: 110 قالب Azure Resource Manager الافتراضي: 110 الإعداد الافتراضي لتوزيع مدخل Azure: 30
الحد الأقصى للقرون لكل عقدة: مع واجهة شبكة حاوية Azure (Azure CNI)1	الحد الأقصى: 250 الحد الأقصى الموصى به لحاويات Windows Server: 110 الافتراضي: 30
فتح ملحق شبكة الخدمة (OSM) AKS	إصدار نظام مجموعة Kubernetes: إصدارات AKS المدعومة وحدات تحكم OSM لكل مجموعة: 1 عدد القرون لكل وحدة تحكم OSM: 1600 حسابات خدمة Kubernetes المُدارة من قِبل OSM: 160
الحد الأقصى لخدمات kubernetes متوازنة التحميل لكل مجموعة مع وحدة SKU لموازن التحميل القياسي	300
الحد الأقصى للعقد لكل مجموعة مع مجموعات توافر الأجهزة الظاهرية ووحدة حفظ المخزون لموازن التحميل الأساسي	100

¹ يجب أن تستخدم حاويات Windows Server المكون الإضافي لشبكة Azure CNI. Kubenet غير مدعوم لحاويات Windows Server.

طبقة وحدة التحكم Kubernetes	الحد
المستوى القياسي	يقوم تلقائيا بتغيير حجم خادم واجهة برمجة تطبيقات Kubernetes استنادا إلى التحميل. حدود مكونات وحدة التحكم الأكبر وخادم API/ مثيلات etcd.
المستوى المجاني	موارد محدودة مع حد طلبات الطيران من 50 استدعاء للتغيير و100 استدعاء للقراءة فقط. حد العقدة الموصى به وهو 10 عقد لكل نظام مجموعة. الأفضل للتجربة والتعلم والاختبار البسيط. لا ينصح للإنتاج/ أحمال العمل الحرجة.

لمزيد من المعلومات، راجع حصص خدمة AKS وحدودها.

نسخة احتياطية

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

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

• حول النسخ الاحتياطي ل AKS باستخدام Azure Backup (معاينة)
• النسخ الاحتياطي ل AKS باستخدام Azure Backup (معاينة)