تحرير

مشاركة عبر

توزيع أزرق أخضر لمجموعات AKS

Azure Kubernetes Service (AKS)
Azure Application Gateway
Azure Container Registry
Azure Front Door
Azure DNS

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

بناء الأنظمة

يصف هذا القسم بنيات النشر الأزرق والأخضر لمجموعات AKS. هناك حالتان:

  • التطبيقات وواجهات برمجة التطبيقات عامة.
  • التطبيقات وواجهات برمجة التطبيقات الخاصة.

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

يوضح الرسم التخطيطي التالي بنية الحالة العامة:

رسم تخطيطي للبنية العامة.

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

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

توفر بوابة تطبيق Azure الواجهات الأمامية المخصصة لنقاط النهاية العامة.

هذا الرسم التخطيطي مخصص للحالة الخاصة:

رسم تخطيطي للبنية الخاصة.

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

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

توفر بوابة التطبيق الأطراف الأمامية المخصصة لنقاط النهاية الخاصة.

‏‏سير العمل‬

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

المراحل هي:

  1. T0: المجموعة الزرقاء قيد التشغيل.
  2. T1: نشر المجموعة الخضراء.
  3. T2: مزامنة حالة Kubernetes بين المجموعات الزرقاء والأخضر.
  4. T3: قم بتبديل نسبة استخدام الشبكة إلى المجموعة الخضراء.
  5. T4: تدمير المجموعة الزرقاء.

بمجرد أن يكون الإصدار الجديد مباشرا، يصبح نظام المجموعة الأزرق لأي تغيير أو تحديث يأتي بعد ذلك.

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

مشغلات الانتقال

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

  • مقاييس حمل العمل المحددة وأهداف مستوى الخدمة (SLOs) واتفاقيات مستوى الخدمة (SLAs): يتم استخدامها بشكل رئيسي في مرحلة T3 للتحقق من الحالة الإجمالية لمجموعة AKS قبل تبديل حركة المرور.
  • مقاييس النظام الأساسي ل Azure: تستخدم لتقييم حالة وصحة أحمال العمل والمجموعة AKS. يتم استخدامها في جميع الانتقالات.

إمكانية اكتشاف الشبكة للمجموعات

يمكنك توفير إمكانية اكتشاف الشبكة للمجموعات بالطرق التالية:

  • لديك سجلات DNS تشير إلى المجموعات. على سبيل المثال:

    • aks-blue.contoso.com يشير إلى IP الخاص أو العام للمجموعة الزرقاء.
    • aks-green.contoso.com يشير إلى IP الخاص أو العام للمجموعة الخضراء.

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

  • لديك سجلات DNS تشير إلى بوابات التطبيق. على سبيل المثال:

    • aks-blue.contoso.com يشير إلى IP الخاص أو العام لبوابة التطبيق، والتي تحتوي على عنوان IP الخاص أو العام للمجموعة الزرقاء كتجمع خلفي.
    • aks-green.contoso.com يشير إلى IP الخاص أو العام لبوابة التطبيق، والتي تحتوي كتجمع خلفية على IP الخاص أو العام للمجموعة الخضراء.

T0: المجموعة الزرقاء قيد التشغيل

المرحلة الأولية، T0، هي أن المجموعة الزرقاء حية. تعد هذه المرحلة الإصدار الجديد من نظام المجموعة للنشر.

رسم تخطيطي لمرحلة T0: المجموعة الزرقاء قيد التشغيل.

شرط المشغل لمرحلة T1 هو إصدار إصدار جديد من نظام المجموعة، نظام المجموعة الأخضر.

T1: نشر نظام المجموعة الخضراء

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

رسم تخطيطي لمرحلة T1: توزيع نظام المجموعة الأخضر.

المشغل للانتقال إلى مرحلة T2 هو التحقق من صحة مجموعة AKS الخضراء على مستوى النظام الأساسي. يستخدم التحقق من الصحة مقاييس Azure Monitor والأوامر CLI للتحقق من صحة النشر. لمزيد من المعلومات، راجع مراقبة خدمة Azure Kubernetes (AKS) مع مرجع بيانات مراقبة ومراقبة AKS.

يمكن تقسيم مراقبة AKS إلى مستويات مختلفة، كما هو موضح في الرسم التخطيطي التالي:

رسم تخطيطي لمستويات مراقبة AKS.

يتم تقييم صحة نظام المجموعة في المستويين 1 و2، وفي بعض المستوى 3. بالنسبة للمستوى 1، يمكنك استخدام طريقة العرض الأصلية متعددة المجموعات من Monitor للتحقق من صحة، كما هو موضح هنا:

لقطة شاشة لمراقبة مجموعات المراقبة.

في المستوى 2، تأكد من أن خادم Kubernetes API وKubelet يعملان بشكل صحيح. يمكنك استخدام مصنف Kubelet في Monitor، على وجه التحديد، الشبكتين للمصنف التي تعرض إحصائيات التشغيل الرئيسية للعقد:

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

المستوى 3 مخصص لكائنات Kubernetes والتطبيقات التي يتم نشرها بشكل افتراضي في AKS، مثل omsagent وkube-proxy وما إلى ذلك. لهذا الفحص، يمكنك استخدام طريقة عرض Insights الخاصة ب Monitor للتحقق من حالة عمليات نشر AKS:

لقطة شاشة لعرض Monitor Insights.

كبديل، يمكنك استخدام المصنف المخصص الموثق في مقاييس النشر وHPA مع نتائج تحليلات الحاوية. إليك مثال:

لقطة شاشة لمصنف مخصص.

بعد نجاح التحقق من الصحة، يمكنك الانتقال إلى مرحلة T2.

T2: مزامنة حالة Kubernetes بين المجموعات الزرقاء والأخضر

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

هناك طرق مختلفة لمزامنة حالة Kubernetes بين المجموعات:

  • إعادة التوزيع عبر التكامل المستمر والتسليم المستمر (CI/CD). عادة ما يكون كافيا لاستخدام نفس مسارات CI/CD المستخدمة للتوزيع العادي للتطبيقات. الأدوات الشائعة للقيام بذلك هي: GitHub Actions وAzure DevOps و Jenkins.
  • GitOps، مع حلول تتم ترقيتها على موقع الويب Cloud Native Computing Foundation (CNCF)، مثل Flux و ArgoCD.
  • حل مخصص يخزن تكوينات وموارد Kubernetes في مخزن البيانات. عادة ما تستند هذه الحلول إلى مولدات بيان Kubernetes التي تبدأ من تعريفات بيانات التعريف ثم تخزن بيانات Kubernetes التي تم إنشاؤها في مخزن بيانات مثل Azure Cosmos DB. عادة ما تكون هذه هي الحلول المخصصة التي تستند إلى إطار عمل وصف التطبيق قيد الاستخدام.

يوضح الرسم التخطيطي التالي عملية مزامنة حالة Kubernetes:

رسم تخطيطي لمرحلة T2: مزامنة حالة Kubernetes بين المجموعات الزرقاء والأخضر.

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

  • تعطيل البنية الأساسية لبرنامج ربط العمليات التجارية للتوزيع.

  • تعطيل حساب خدمة Kubernetes الذي ينفذ عمليات التوزيع.

    من الممكن أتمتة تعطيل حساب الخدمة باستخدام Open Policy Agent (OPA). لا يمكن بعد استخدام ميزات AKS الأصلية لهذا لأنها لا تزال قيد المعاينة.

يمكن تجنب فترة المزامنة باستخدام آليات متقدمة تدير حالة Kubernetes في مجموعات متعددة.

عند اكتمال المزامنة، يلزم التحقق من صحة نظام المجموعة والتطبيقات. يتضمن هذا:

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

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

عادة ما يتم عرض المجموعة الخضراء على بوابة التطبيق أو موازن التحميل الخارجي مع عنوان URL داخلي غير مرئي للمستخدمين الخارجيين.

عند التحقق من صحة نظام المجموعة الجديد، يمكنك المتابعة إلى المرحلة التالية لتبديل حركة المرور إلى نظام المجموعة الجديد.

T3: تبديل نسبة استخدام الشبكة إلى المجموعة الخضراء

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

فيما يلي رسم تخطيطي يوضح الحالة الهدف بعد تطبيق مفتاح التبديل:

رسم تخطيطي لمرحلة T3: مفتاح حركة مرور نظام المجموعة الأخضر.

تنفذ التقنيات الموضحة في هذه المقالة التبديلات الكاملة: يتم توجيه 100٪ من نسبة استخدام الشبكة إلى نظام المجموعة الجديد. وذلك لأن التوجيه يتم تطبيقه على مستوى DNS مع A تعيين سجل أو CNAME تم تحديثه للإشارة إلى المجموعة الخضراء، وهناك بوابة تطبيق لكل نظام مجموعة.

فيما يلي مثال على التكوين لتبديل نقاط النهاية الخاصة. يستخدم A الحل المقترح السجلات لإجراء التبديل. من منظور تعيين DNS وIP، يكون الموقف كما يلي قبل التبديل:

  • A تسجيل aks.priv.contoso.com نقاط إلى IP الخاص لبوابة التطبيق الزرقاء.
  • A تسجيل aks-blue.priv.contoso.com نقاط إلى IP الخاص لبوابة التطبيق الزرقاء.
  • A تسجيل aks-green.priv.contoso.com نقاط إلى IP الخاص لبوابة التطبيق الخضراء.

يتم إعادة تكوين المفتاح إلى ما يلي:

  • A تسجيل aks.priv.contoso.com نقاط إلى IP الخاص لبوابة التطبيق الخضراء.
  • A تسجيل aks-blue.priv.contoso.com نقاط إلى IP الخاص لبوابة التطبيق الزرقاء.
  • A تسجيل aks-green.priv.contoso.com نقاط إلى IP الخاص لبوابة التطبيق الخضراء.

سيرى مستخدمو المجموعات التبديل بعد وقت البقاء (TTL) ونشر DNS للسجلات.

بالنسبة لنقاط النهاية العامة، يستخدم النهج الموصى به Azure Front Door وAzure DNS. إليك التكوين قبل التبديل:

  • CNAME يشير السجل official-aks.contoso.com إلى سجل لمجال Azure Front Door الذي تم إنشاؤه تلقائيا. لمزيد من المعلومات، راجع البرنامج التعليمي: إضافة مجال مخصص إلى Front Door.
  • A تسجيل aks.contoso.com نقاط إلى IP العام لبوابة التطبيق الزرقاء.
  • يشير تكوين أصل Azure Front Door إلى aks.contoso.com اسم المضيف. لمزيد من المعلومات حول تكوين تجمعات الواجهة الخلفية، راجع الأصول ومجموعات الأصل في Azure Front Door.
    • A تسجيل aks-blue.contoso.com نقاط إلى IP العام لبوابة التطبيق الزرقاء.
    • A تسجيل aks-green.contoso.com نقاط إلى IP العام لبوابة التطبيق الخضراء.

يتم إعادة تكوين المفتاح إلى ما يلي:

  • CNAME يشير السجل official-aks.contoso.com إلى سجل لمجال Azure Front Door الذي تم إنشاؤه تلقائيا.
  • A تسجيل aks.contoso.com نقاط إلى IP العام لبوابة التطبيق الخضراء.
  • يشير تكوين أصل Azure Front Door إلى aks.contoso.com اسم المضيف.
    • A تسجيل aks-blue.contoso.com نقاط إلى IP العام لبوابة التطبيق الزرقاء.
    • A تسجيل aks-green.contoso.com نقاط إلى IP العام لبوابة التطبيق الخضراء.

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

كما هو موضح في المثال، من منظور الشبكات، تستند هذه التقنية إلى تعريف أربعة أسماء مضيفين:

  • اسم المضيف العام الرسمي: اسم المضيف العام الرسمي المستخدم من قبل المستخدمين والمستهلكين.
  • اسم مضيف نظام المجموعة: اسم المضيف الرسمي الذي يستخدمه مستهلكو أحمال العمل المستضافة في المجموعات.
  • اسم مضيف نظام المجموعة الأزرق: اسم المضيف المخصص للمجموعة الزرقاء.
  • اسم مضيف نظام المجموعة الأخضر: اسم المضيف المخصص للمجموعة الخضراء.

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

إذا كان Azure Front Door أيضا جزءا من النشر، فلن يتأثر بالتبديل، لأنه يدير اسم مضيف نظام المجموعة الرسمي فقط. يوفر التجريد المناسب لمستخدمي التطبيق. لا يتأثرون بالتبديل، لأن سجل DNS CNAME يشير دائما إلى Azure Front Door.

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

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

T4: تدمير المجموعة الزرقاء

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

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

إليك الموقف بعد تدمير المجموعة الزرقاء:

رسم تخطيطي لمرحلة T4: يتم تدمير المجموعة الزرقاء.

المكونات

  • Application Gateway هو موازن تحميل لحركة مرور الويب (طبقة OSI 7) التي تمكنك من إدارة نسبة استخدام الشبكة إلى تطبيقات الويب الخاصة بك. في هذا الحل يتم استخدامه كبوابة لحركة مرور HTTP للوصول إلى مجموعات AKS.
  • خدمة Azure Kubernetes (AKS) هي خدمة Kubernetes مدارة يمكنك استخدامها لنشر التطبيقات المعبأة في حاويات وإدارتها. النظام الأساسي للتطبيق هذا هو المكون الرئيسي لهذا النمط.
  • Azure Container Registry هي خدمة مدارة تستخدم لتخزين صور الحاوية والبيانات الاصطناعية ذات الصلة وإدارتها. في هذا الحل يتم استخدام لتخزين وتوزيع صور الحاوية والبيانات الاصطناعية، مثل مخططات Helm، في مجموعات AKS.
  • Azure Monitor هو حل مراقبة لجمع بيانات المراقبة وتحليلها والاستجابة لها من البيئات السحابية والبيئات المحلية. يوفر ميزات المراقبة الأساسية المطلوبة لتنفيذ النشر الأزرق الأخضر. يتم استخدامه في هذه البنية بسبب تكامله مع AKS وقدرته على توفير إمكانات التسجيل والمراقبة والتنبيه التي يمكن استخدامها لإدارة انتقالات المرحلة.
  • يساعد Azure Key Vault في حل المشكلات التالية: إدارة الأسرار وإدارة المفاتيح وإدارة الشهادات؛ ويتم استخدامه لتخزين وإدارة الأسرار والشهادات المطلوبة على مستوى platfomr والتطبيق لهذا الحل.
  • Azure Front Door هو موازن تحميل عمومي ونظام إدارة نقطة نهاية التطبيق. يتم استخدامه في هذا الحل كنقطة نهاية عامة لتطبيقات HTTP التي تتم استضافتها على AKS. في هذا الحل، تقع على عاتقه مسؤولية حاسمة لإدارة تبديل نسبة استخدام الشبكة بين بوابات التطبيق الزرقاء والأخضر.
  • يُعد Azure DNS خدمة استضافة لمجالات DNS التي تقدم تحليلات الأسماء باستخدام البنية التحتية لـ Microsoft Azure. يدير أسماء المضيفين المستخدمة في الحل للمجموعات الزرقاء والأخضر، ويلعب دورا مهما في مفاتيح تبديل نسبة استخدام الشبكة، خاصة لنقاط النهاية الخاصة.

البدائل

  • هناك تقنيات بديلة لتنفيذ مفاتيح حركة المرور التي يمكن أن توفر المزيد من التحكم. على سبيل المثال، من الممكن إجراء تبديل جزئي باستخدام قواعد حركة المرور التي تستند إلى واحد أو أكثر مما يلي:
    • النسبة المئوية لنسبة استخدام الشبكة الواردة
    • رؤوس عناوين HTTP
    • ملفات تعريف الارتباط
  • بديل آخر يوفر حماية أكبر من المشكلات التي تسببها التغييرات هو أن يكون لديك عمليات نشر تستند إلى حلقة. بدلا من المجموعات الزرقاء والأخضر فقط، من الممكن أن يكون لديك المزيد من المجموعات، تسمى الحلقات. كل حلقة كبيرة بما يكفي لعدد المستخدمين الذين لديهم حق الوصول إلى الإصدار الجديد من AKS. أما بالنسبة للنشر الأزرق والأخضر الموضح هنا، يمكن إزالة الحلقات للحصول على تحسين التكلفة والتحكم المناسبين.
  • البدائل المحتملة ل Application Gateway هي NGINX وHAProxy.
  • البديل المحتمل ل Container Registry هو Harbor.
  • في بعض الحالات، من الممكن استخدام موازنة التحميل المختلفة وخدمات DNS للقيام بمفاتيح تبديل نسبة استخدام الشبكة، بدلا من Azure Front Door وAzure DNS.
  • يستند هذا الحل إلى واجهات برمجة تطبيقات Kubernetes لوحدة تحكم الدخول القياسية. إذا كان الحل الخاص بك سيستفيد بدلا من واجهة برمجة تطبيقات البوابة، فاستخدم بوابة التطبيق للحاويات. يمكن أن يساعد في إدارة موازنة التحميل ومعالجة إدارة حركة مرور الدخول بين بوابة التطبيق والقرون. تتحكم بوابة التطبيق للحاويات في إعدادات بوابات التطبيق.

تفاصيل السيناريو

الفوائد الرئيسية للحل هي:

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

تناقش المبادئ الرئيسية والجوانب الأساسية للتوزيع الأزرق والأخضر في هذه المقالات:

من منظور الأتمتة وCI/CD، يمكن تنفيذ الحل بطرق متعددة. نقترح:

حالات الاستخدام المحتملة

النشر الأزرق والأخضر يجعل من الممكن إجراء تغييرات على المجموعات دون التأثير على التطبيقات وأحمال العمل قيد التشغيل. ومن أمثلة التغييرات ما يلي:

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

الاعتبارات

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

  • يمكن أن يكون النشر الأزرق والأخضر تلقائيا بالكامل، مثل التوزيع بدون لمس. عادة ما يكون للتنفيذ الأولي مشغلات يدوية لتنشيط المراحل. على طول الطريق ومع ميزات النضج والمراقبة المناسبة، من الممكن أتمتة المشغلات. وهذا يعني أن هناك اختبارا تلقائيا ومقاييس محددة وSLA وSLO لأتمتة المشغلات.
  • من المهم أن يكون لديك أسماء مضيف مخصصة للمجموعات الزرقاء والأخضر وأيضا أن يكون لديك تكوينات نقطة نهاية مخصصة على البوابات وموازنات التحميل الموجودة أمام المجموعات. وهذا أمر بالغ الأهمية لتحسين موثوقية وصلاحية نشر نظام المجموعة الجديد. بهذه الطريقة، يحدث التحقق من صحة التوزيع بنفس البنية والتكوينات لمجموعة إنتاج قياسية.
  • ضع في اعتبارك الموقف الذي تكون فيه مجموعات AKS موارد مشتركة لتطبيقات متعددة تتم إدارتها بواسطة وحدات عمل مختلفة. في مثل هذه الحالات، من الشائع أن تتم إدارة نظام AKS الأساسي نفسه من قبل فريق مخصص مسؤول عن التشغيل العام ودورة حياة المجموعات، وأن هناك نقاط نهاية في المجموعات لأغراض المسؤول والعمل. نقترح أن نقاط النهاية هذه لديها وحدة تحكم دخول مخصصة في مجموعات AKS للفصل الصحيح بين المخاوف والموثوقية.
  • يعد النشر الأزرق والأخضر مفيدا لتنفيذ واختبار حلول استمرارية الأعمال والتعافي من الكوارث (BC/DR) ل AKS وأحمال العمل ذات الصلة. ويوفر على وجه الخصوص الهياكل الأساسية لإدارة مجموعات متعددة، بما في ذلك الحالات التي تنتشر فيها المجموعات بين مناطق متعددة.
  • يعتمد النجاح مع النشر الأزرق والأخضر على تطبيق جميع جوانب التنفيذ، مثل الأتمتة والمراقبة والتحقق من الصحة، ليس فقط على النظام الأساسي ل AKS، ولكن أيضا على أحمال العمل والتطبيقات التي يتم نشرها على النظام الأساسي. يساعدك القيام بذلك على الحصول على أقصى استفادة من النشر الأزرق والأخضر.
  • في الحل المقترح هناك بوابتان للتطبيق لكل سيناريو عام وخاصة، لذلك في المجموع أربعة. هذا القرار هو تطبيق النشر الأخضر الأزرق على مستوى بوابة تطبيق Azure لتجنب وقت التعطل الناجم عن التكوين الخاطئ للبوابات. العيب الرئيسي لهذا القرار هو التكلفة، نظرا لوجود أربعة مثيلات ل Application Gateway. يتم تشغيلها بالتوازي فقط في الفترة الزمنية التي توجد فيها تغييرات ذات صلة بتكوينات بوابة التطبيق، مثل نهج WAF أو تكوين التحجيم. لمزيد من تحسين التكلفة، يمكنك اختيار بوابة تطبيق واحدة لكل سيناريو، وهذا يعني اثنين من بوابة التطبيق في المجموع. سيتطلب ذلك نقل المنطق الأزرق/الأخضر إلى بوابة التطبيق، بدلا من Azure Front Door. لذلك بدلا من التحكم في Azure Front Door بشكل حتمي، تكون بوابة التطبيق.

الموثوقيه

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

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

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

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

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

التميز التشغيلي

يغطي التميز التشغيلي عمليات التشغيل التي تحافظ على تشغيل التطبيق في الإنتاج. لمزيد من المعلومات، يرجى مراجعةنظرة عامة على ركيزة التميز التشغيلي.

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

نشر هذا السيناريو

للحصول على مثال مطبق للتوزيع الأزرق والأخضر الموضح في هذا الدليل، راجع AKS Landing Zone Accelerator.

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

هام

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

اعتبارات المنطقة

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

  • شبكة ظاهرية مخصصة وشبكة فرعية ل AKS وبوابة التطبيق.
  • الاتصال بخدمات الدعم مثل Monitor و Container Registry و Key Vault.
  • رؤية Azure Front Door لبوابة التطبيق.

هناك متطلبات أساسية للنشر في نفس المنطقة:

  • يجب تغيير حجم الشبكات الظاهرية والشبكات الفرعية لاستضافة نظامي مجموعة.
  • يجب أن يوفر اشتراك Azure سعة كافية للمجموعتين.

نشر وحدة تحكم الدخول وموازنات التحميل الخارجية

هناك أساليب مختلفة لتوزيع وحدة تحكم الدخول وموازنات التحميل الخارجية:

  • يمكن أن يكون لديك وحدة تحكم دخول واحدة مع موازن تحميل خارجي مخصص، مثل التنفيذ المرجعي للبنية الموضحة في هذا الدليل. AGIC هو تطبيق Kubernetes الذي يجعل من الممكن استخدام موازن تحميل Application Gateway L7 لعرض برامج السحابة على الإنترنت. في سيناريوهات معينة، هناك نقاط نهاية المسؤول في مجموعات AKS بالإضافة إلى نقاط نهاية التطبيق. نقاط نهاية المسؤول هي للقيام بمهام تشغيلية على التطبيقات أو لمهام التكوين مثل تحديث خرائط التكوين والأسرار ونهج الشبكة والبيانات.
  • يمكن أن يكون لديك موازن تحميل خارجي واحد يخدم وحدات تحكم دخول متعددة يتم نشرها على نفس المجموعة أو على مجموعات متعددة. هذا النهج غير مشمول في التنفيذ المرجعي. في هذا السيناريو، نوصي بأن يكون لديك بوابات تطبيق منفصلة لنقاط النهاية العامة ونقاط النهاية الخاصة.
  • تستند البنية الناتجة التي تم اقتراحها وتصورها في هذا الدليل إلى وحدة تحكم دخول قياسية تم نشرها كجزء من مجموعة AKS، مثل تلك المستندة إلى NGINX و Envoy. في التنفيذ المرجعي نستخدم AGIC، ما يعني أن هناك اتصالا مباشرا بين بوابة التطبيق ووحدات جراب AKS، ولكن هذا لا يؤثر على البنية الزرقاء والأخضر الشاملة.

المساهمون

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

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

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

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

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