Share via

اعتبارات إدارة العمليات لخدمة Azure Kubernetes

  • مقالة

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

أساس العمليات ل AKS

يمكنك العمل نحو التميز التشغيلي ونجاح العملاء من خلال تصميم حل Azure Kubernetes Service (AKS) بشكل صحيح مع وضع الإدارة والمراقبة في الاعتبار.

اعتبارات التصميم

ضع في اعتبارك العوامل التالية:

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

التوصيات

  • فهم حدود AKS:

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

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

  • أضف تحقيقات السلامة إلى القرون الخاصة بك. تأكد من أن الحجيرات تحتوي على livenessProbeو readinessProbeو و startupProbeتحقيقات صحة AKS.

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

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

  • استخدم تنبيهات قياس نتائج تحليلات حاوية Azure Monitor لتوفير إعلامات عندما تحتاج الأشياء إلى إجراء مباشر.

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

  • استخدم Azure Advisor للحصول على توصيات أفضل الممارسات حول التكلفة والأمان والموثوقية والتميز التشغيلي والأداء. أيضا، استخدم Microsoft Defender للسحابة لمنع التهديدات واكتشافها مثل الثغرات الأمنية للصور.

  • استخدم Kubernetes التي تدعم Azure Arc لإدارة مجموعات Kubernetes غير AKS في Azure باستخدام نهج Azure و Defender for Cloud و GitOps وما إلى ذلك.

  • استخدم طلبات وحدود الجراب لإدارة موارد الحوسبة داخل نظام مجموعة AKS. تبلغ طلبات وحدود الجراب مجدول Kubernetes عن موارد الحوسبة التي يجب تعيينها إلى جراب.

استمرارية الأعمال/التعافي من الكوارث لحماية AKS واستردادها

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

اعتبارات التصميم

ضع في اعتبارك العوامل التالية:

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

  • تعيين طلبات وحدود الجراب. يتيح تعيين هذه الحدود ل Kubernetes:

    • امنح وحدة المعالجة المركزية وموارد الذاكرة بكفاءة إلى القرون.
    • لديك كثافة حاوية أعلى على عقدة.

    يمكن أن تزيد الحدود أيضا من الموثوقية مع انخفاض التكاليف بسبب الاستخدام الأفضل للأجهزة.

  • ملاءمة AKS لمناطق التوفر أو مجموعات التوفر.

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

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

  • إنشاء نسخ احتياطية للتطبيقات والبيانات باستمرار.

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

  • تحديث نظام المجموعة وصيانته.

    • حافظ دائما على تحديث نظام المجموعة الخاص بك.
    • كن على دراية بعملية الإصدار والإهمال.
    • خطط للتحديثات والصيانة.

  • اتصال الشبكة في حالة حدوث تجاوز الفشل.

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

  • عمليات تجاوز الفشل المخطط لها وغير المخطط لها.

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

  • الحفاظ على قدرات DevOps الهندسية للوصول إلى أهداف مستوى الخدمة.

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

توصيات التصميم

فيما يلي أفضل الممارسات لتصميمك:

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

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

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

  • كلما أمكن، قم بإزالة حالة الخدمة من داخل الحاويات. بدلا من ذلك، استخدم النظام الأساسي Azure كخدمة (PaaS) التي تدعم النسخ المتماثل متعدد المناطق.

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

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

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

    • النسخ المتماثل غير المتزامن القائم على البنية التحتية
    • النسخ المتماثل غير المتزامن المستند إلى التطبيق

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

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

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

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

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

  • قم بتخزين صور الحاوية في Azure Container Registry ونسخ السجل جغرافيا إلى كل منطقة AKS.

  • استخدم اتفاقية مستوى الخدمة ل Uptime لتمكين اتفاقية مستوى الخدمة مدعومة ماليا وأعلى لجميع المجموعات التي تستضيف أحمال عمل الإنتاج. تضمن اتفاقية مستوى الخدمة لوقت التشغيل توفرا بنسبة 99.95٪ لنقطة نهاية خادم Kubernetes API للمجموعات التي تستخدم مناطق التوفر و99.9٪ من التوفر للمجموعات التي لا تستخدم مناطق التوفر. تتم تغطية العقد وتجمعات العقد والموارد الأخرى ضمن اتفاقية مستوى الخدمة الخاصة بها. تقدم AKS مستوى مجانيا مع هدف مستوى الخدمة (SLO) بنسبة 99.5٪ لمكونات وحدة التحكم الخاصة بها. لا يجب استخدام المجموعات التي لم يتم تمكين اتفاقية مستوى الخدمة لوقت التشغيل لأحمال عمل الإنتاج.

  • استخدم مناطق متعددة ومواقع نظيرة لاتصال Azure ExpressRoute .

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

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

  • باستخدام بروتوكول anycast المقسم المستند إلى TCP، يضمن Azure Front Door اتصال المستخدمين النهائيين على الفور بأقرب نقطة حضور ل Front Door. تتضمن الميزات الأخرى ل Azure Front Door ما يلي:

    • إنهاء TLS
    • مجال مخصص
    • جدار حماية تطبيق الويب
    • إعادة كتابة عنوان URL
    • تقارب الجلسة

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