خط AKS أساسي لأنظمة مجموعة متعددة المناطق

توضح هذه البنية المرجعية تفاصيل كيفية تشغيل مثيلات متعددة من مجموعة Azure Kubernetes Service (AKS) عبر مناطق متعددة في تكوين نشط/نشط ومتاح للغاية.

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

الهندسة

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

يتوفر تنفيذ مرجعي لهذه البنية على GitHub.

المكونات

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

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

أنماط التصميم

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

اعتبارات نمط العقدة الجغرافية

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

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

اعتبارات طابع النشر

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

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

يتم تفصيل كل عنصر من هذه العناصر مع إرشادات محددة في الأقسام التالية من هذا التصميم المرجعي.

⁧⁩إدارة الأسطول⁧⁩

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

الاعتبارات

تنفذ هذه الاعتبارات ركائز Azure Well-Architected Framework، وهو عبارة عن مجموعة من المبادئ التوجيهية التي يمكن استخدامها لتحسين جودة حمل العمل. لمزيد من المعلومات، يرجى مراجعةMicrosoft Azure Well-Architected Framework.

توزيع نظام المجموعة وتمهيد التشغيل

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

تعريف نظام المجموعة

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

عند العمل مع العديد من مثيلات AKS، نوصي بالنظر في البنية الأساسية كحلول للتعليمات البرمجية، مثل قوالب Azure Resource Manager أو قوالب Bicep أو تكوينات Terraform. توفر البنية الأساسية كحلول تعليمة برمجية حلًا تلقائيًا وقابلًا للتطوير وغير فعال. تتضمن هذه البنية المرجعية قالب ARM للخدمات المشتركة للحلول ثم قالب آخر لمجموعات AKS + الخدمات الإقليمية. إذا كنت تستخدم البنية الأساسية كتعليمة برمجية، يمكن تعريف طابع التوزيع بتكوينات معممة مثل الشبكات والتخويل والتشخيص. يمكن توفير ملف معلمة توزيع بقيم إقليمية محددة. باستخدام هذا التكوين، يمكن استخدام قالب واحد لنشر طابع متطابق تقريبًا عبر أي منطقة.

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

توزيع نظام المجموعة

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

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

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

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

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

تمهيد نظام المجموعة

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

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

GitOps

بدلا من تكوين مكونات Kubernetes يدويا، ضع في اعتبارك استخدام أساليب تلقائية لتطبيق التكوينات على مجموعة Kubernetes، حيث يتم إيداع هذه التكوينات في مستودع مصدر. غالبًا ما يشار إلى هذه العملية باسم GitOps، وتشمل حلول GitOps الشائعة لـKubernetes Flux وArgo CD. يستخدم هذا التنفيذ ملحق Flux ل AKS لتمكين تمهيد تشغيل المجموعات تلقائيا وفورا بعد توزيع المجموعات.

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

نهج Azure

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

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

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

عند تصميم نهج لمجموعات AKS متعددة، ضع في اعتبارك العناصر التالية:

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

راجع مؤسسة موارد Cloud Adoption Framework للحصول على المواد التي ستساعدك على إنشاء استراتيجية لإدارة النهج.

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

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

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

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

التوفر وتجاوز الفشل

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

Pods للتطبيق (إقليمي)

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

لمزيد من المعلومات، راجع Kubernetes ReplicaSet.

Application Pods (عمومي)

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

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

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

لمزيد من المعلومات، راجع التحجيم التلقائي للجراب الأفقيوالتحجيم التلقائي لمجموعة AKS.

تجمعات عقدة Kubernetes (إقليمية)

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

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

تجمعات عقدة Kubernetes (عمومية)

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

لمزيد من المعلومات، راجع الواجهة الأمامية لـ Azure.

طبولوجيا الشبكة

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

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

إدارة نسبة استخدام الشبكة

باستخدام بنية مرجع أساس AKS، يتم توجيه حركة مرور حمل العمل مباشرة إلى مثيل Azure Application Gateway، ثم إعادة توجيهها إلى موارد دخول موازن التحميل الخلفية / AKS. عند العمل مع مجموعات متعددة، يتم توجيه طلبات العميل من خلال مثيل Azure Front Door، والذي يوجه إلى مثيل Azure Application Gateway.

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

1. يرسل المستخدم طلبا إلى اسم مجال (مثل https://contoso-web.azurefd.net)، يتم حله إلى مثيل Azure Front Door. يتم تشفير هذا الطلب بشهادة حرف بدل (*.azurefd.net) الصادرة لجميع المجالات الفرعية لـAzure Front Door. يتحقق مثيل Azure Front Door من صحة الطلب مقابل نهج WAF، ويحدد الواجهة الخلفية الأسرع (استنادًا إلى الصحة وزمن الانتقال)، ويستخدم DNS العام لحل عنوان IP للواجهة الخلفية (مثيل Azure Application Gateway).

2. يقوم Front Door بإعادة توجيه الطلب إلى مثيل Application Gateway المناسب المحدد، والذي يعمل كنقطة إدخال للطابع الإقليمي. تتدفق نسبة استخدام الشبكة عبر الإنترنت ويتم تشفيرها بواسطة Azure Front Door. ضع في اعتبارك أسلوبًا للتأكد من أن مثيل بوابة التطبيق يقبل نسبة استخدام الشبكة فقط من مثيل Front Door. أحد الأساليب هو استخدام مجموعة أمان الشبكة على الشبكة الفرعية التي تحتوي على بوابة التطبيق. يمكن للقواعد تصفية نسبة استخدام الشبكة الواردة (أو الصادرة) استنادًا إلى خصائص مثل المصدر والمنفذ والوجهة. تسمح لك الخاصية Source بتعيين علامة خدمة مضمنة تشير إلى عناوين IP لمورد Azure. يسهل هذا التجريد تكوين القاعدة والحفاظ عليها وتتبع عناوين IP. بالإضافة إلى ذلك، ضع في اعتبارك استخدام Front Door لعنوان الواجهة الخلفية X-Azure-FDID للتأكد من أن مثيل بوابة التطبيق يقبل نسبة استخدام الشبكة فقط من مثيل Front Door. لمزيد من المعلومات حول عناوين Front Door، راجع دعم البروتوكول لعناوين HTTP في Azure Front Door.

اعتبارات الموارد المشتركة

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

Container Registry

يستخدم Azure Container Registry في هذا التصميم المرجعي لتوفير خدمات صورة الحاوية (سحب). ضع في اعتبارك العناصر التالية عند العمل مع Azure Container Registry في نشر نظام مجموعة متعدد المناطق.

التوافر الجغرافي

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

أنشأ التنفيذ المرجعي متعدد المناطق AKS مثيل سجل حاوية واحد ونسخ متماثلة من هذا المثيل في كل منطقة نظام مجموعة. لمزيد من المعلومات حول النسخ المتماثل لـAzure Container Registry، راجع النسخ المتماثل الجغرافي في Azure Container Registry.

صورة تعرض نسخًا متماثلة ACR متعددة من داخل مدخل Microsoft Azure.

الوصول إلى نظام المجموعة

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

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

Azure Monitor

ميزة Azure Monitor Container insights هي الأداة الموصى بها لمراقبة وفهم أداء وصحة أحمال عمل نظام المجموعة والحاويات. تستخدم نتائج تحليلات الحاوية كل من مساحة عمل Log Analytics لتخزين بيانات السجل، ومقاييس Azure Monitor لتخزين بيانات السلسلة الزمنية الرقمية. يمكن أيضا جمع مقاييس Prometheus بواسطة Container Insights وإرسال البيانات إلى خدمة Azure Monitor المدارة ل Prometheus أو Azure Monitor Logs.

يمكنك أيضا تكوين إعدادات تشخيص نظام مجموعة AKS لتجميع وتحليل سجلات الموارد من مكونات وحدة التحكم AKS وإعادة توجيهها إلى مساحة عمل Log Analytics.

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

عند النظر في مراقبة تنفيذ عبر المناطق مثل هذا التصميم المرجعي، من المهم مراعاة الاقتران بين كل طابع. في هذه الحالة، ضع في اعتبارك كل طابع مكونًا لوحدة واحدة (نظام مجموعة إقليمية). يستخدم التنفيذ المرجعي AKS متعدد المناطق مساحة عمل Log Analytics واحدة، مشتركة من قبل كل مجموعة Kubernetes. كما هو الحال مع الموارد المشتركة الأخرى، حدد الطابع الإقليمي لاستهلاك معلومات حول مساحة عمل Log Analytics الفردية وتوصيل كل مجموعة بها.

الآن بعد أن انبعثت كل مجموعة إقليمية من سجلات التشخيص إلى مساحة عمل Log Analytics واحدة، يمكن استخدام هذه البيانات، جنبا إلى جنب مع مقاييس الموارد، لإنشاء تقارير ولوحات معلومات تمثل المجموعة العالمية بأكملها بسهولة أكبر.

الواجهة الأمامية لـ Azure

يستخدم Azure Front door لتحميل التوازن وتوجيه نسبة استخدام الشبكة إلى كل نظام مجموعة AKS. يسمح Azure Front Door للتوجيه العمومي للطبقة السابعة، وكلاهما مطلوب لهذه البنية المرجعية.

تكوين نظام المجموعة

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

الشهادات

لا يدعم Front Door الشهادات الموقعة ذاتيا حتى في بيئات التطوير/الاختبار. لتمكين نسبة استخدام الشبكة HTTPS، تحتاج إلى إنشاء شهادة TLS/SSL موقعة من قبل مرجع مصدق (CA). يستخدم التنفيذ المرجعي Certbot لإنشاء شهادة Let's Encrypt Authority X3. عند التخطيط لمجموعة إنتاج، استخدم الطريقة المفضلة لمؤسستك لشراء شهادات TLS.

للحصول على معلومات حول المراجع المصدقة الأخرى التي يدعمها Front Door، راجع المراجع المصدقة المسموح بها لتمكين HTTPS المخصص على Azure Front Door.

الوصول إلى نظام المجموعة والهوية

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

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

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

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

لمزيد من المعلومات حول إدارة الوصول إلى نظام مجموعة AKS باستخدام معرف Microsoft Entra، راجع تكامل AKS Microsoft Entra.

البيانات والحالة وذاكرة التخزين المؤقت

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

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

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

تحسين التكلفة

استخدم حاسبة تسعير Azure لتقدير تكاليف الخدمات المستخدمة في البنية. يتم وصف أفضل الممارسات الأخرى في قسم تحسين التكلفة في Microsoft Azure Well-Architected Framework، وخيارات تكوين تحسين التكلفة المحددة في مقالة تحسين التكاليف .

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

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

• مناطق توفر AKS
• Azure Kubernetes Fleet Manager
• النسخ الجغرافي المتماثل في Azure Container Registry
• المناطق المُقترنة في Azure

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

• مراجعة Azure Well-Architected Framework لخدمة Azure Kubernetes (AKS)
• البنية الأساسية لمجموعة Azure Kubernetes Service (AKS)
• تدفق CI/CD لأحمال العمل المستندة إلى الحاويات
• تكامل AKS Microsoft Entra
• وثائق Azure Front Door
• وثائق Azure Cosmos DB