هيكل بنية الأساس لنظام مجموعة Azure Kubernetes Service (AKS)

توفر هذه البنية المرجعية بنية أساسية موصى بها لنشر نظام مجموعة Azure Kubernetes Service (AKS) على Azure. ويستخدم مبادئ التصميم الخاصة بنا ويستند إلى أفضل ممارساتنا المعمارية من Azure Well-Architected Framework لتوجيه فرق متميزة متعددة التخصصات أو متعددة مثل الشبكات والأمان والهوية من خلال نشر هذه البنية الأساسية للأغراض العامة.

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

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

يتوفر تنفيذ هذه البنية أيضا على GitHub: التنفيذ المرجعي الأساسي لخدمة Azure Kubernetes (AKS). يمكنك استخدامه كنقطة بداية بديلة وتكوينه بناء على احتياجاتك.

تكوين شبكة الاتصال

طبولوجيا الشبكة
البحث عن عناوين IP
توزيع موارد الدخول

حساب نظام المجموعة

حساب نظام المجموعة الأساسي
مرجع صورة الحاوية
إدارة النهج

إدارة الهوية

دمج معرف Microsoft Entra لنظام المجموعة
دمج معرف Microsoft Entra لحمل العمل

تدفق البيانات الآمن

تأمين تدفق الشبكة
إضافة سرية المفاتيح

استمرارية الأعمال

قابلية التوسع
توفر نظام المجموعة والعقدة
التوفر والدعم متعدد المناطق

العمليات

البنية الأساسية لبرنامج ربط العمليات التجارية ل CI/CD للمجموعة وأحمال العمل
سلامة الشبكة وقياساتها
إدارة التكاليف وإعداد التقارير

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

تستخدم هذه البنية مخطط شبكة محوري. يتم نشر المركز والتحدث (المحاور) في شبكات ظاهرية منفصلة متصلة من خلال التناظر. بعض مزايا هذا المخطط هي:

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

• يقلل من التعرض المباشر لموارد Azure للإنترنت العام.

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

• يجب أن تتطلب جميع تطبيقات الويب خدمة جدار حماية تطبيق الويب (WAF) للمساعدة في التحكم في تدفق حركة مرور HTTP.

• خيار طبيعي لأحمال العمل التي تمتد عبر اشتراكات متعددة.

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

• يمكن مشاركة بعض الموارد، مثل جدار الحماية وDNS عبر الشبكات.

• يتوافق مع مناطق الهبوط على نطاق المؤسسة Azure.

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

لمزيد من المعلومات، راجع تخطيط شبكة النظام المحوري في Azure.

لمراجعة تغييرات تصميم الشبكة المضمنة في حاويات Windows على البنية المرجعية الأساسية ل AKS، راجع المقالة المصاحبة.

مركز

الشبكة الظاهرية المركزية هي النقطة المركزية للاتصال وإمكانية المراقبة. يحتوي المركز دائما على جدار حماية Azure مع نهج جدار الحماية العمومية التي تحددها فرق تكنولوجيا المعلومات المركزية لفرض نهج جدار الحماية على مستوى المؤسسة، وAzure Bastion، وشبكة فرعية للبوابة لاتصال VPN، وAzure Monitor لمراقبة الشبكة.

داخل الشبكة، يتم نشر ثلاث شبكات فرعية.

شبكة فرعية لاستضافة جدار حماية Azure

Azure Firewall هو جدار حماية مُدار كخدمة. يؤمّن مثيل جدار الحماية نسبة استخدام الشبكة الصادرة. بدون هذه الطبقة من الأمان، قد تتواصل نسبة استخدام الشبكة هذه مع خدمة ضارة تابعة لجهة خارجية يمكن أن تصادر بيانات الشركة الحساسة. يمكنك Azure Firewall Manager من نشر وتكوين مثيلات Azure Firewall المتعددة مركزيا وإدارة نهج Azure Firewall لنوع بنية شبكة الشبكة الظاهرية للمركز هذا.

شبكة فرعية لاستضافة بوابة

هذه الشبكة الفرعية هي عنصر نائب لبوابة VPN أو ExpressRoute. توفر البوابة الاتصال بين أجهزة التوجيه في الشبكة المحلية والشبكة الظاهرية.

شبكة فرعية لاستضافة Azure Bastion

هذه الشبكة الفرعية هي عنصر نائب ل Azure Bastion. يمكنك استخدام Bastion للوصول بأمان إلى موارد Azure دون تعريض الموارد إلى الإنترنت. يتم استخدام هذه الشبكة الفرعية للإدارة والعمليات فقط.

تكلم

تحتوي الشبكة الظاهرية المحورية على نظام مجموعة AKS والموارد الأخرى ذات الصلة. يحتوي المتحدث على أربع شبكات فرعية:

الشبكة الفرعية لاستضافة بوابة تطبيق Azure

Azure Application Gateway عبارة عن موازن تحميل حركة مرور الويب يعمل في الطبقة 7. يستخدم التنفيذ المرجعي Application Gateway v2 SKU الذي يمكن Web Application Firewall (WAF). يؤمن WAF حركة المرور الواردة من هجمات حركة مرور الويب الشائعة، بما في ذلك الروبوتات. يحتوي المثيل على تكوين IP عام للواجهة الأمامية التي تتلقى طلبات المستخدم. حسب التصميم، تتطلب بوابة التطبيق شبكة فرعية مخصصة.

الشبكة الفرعية لاستضافة موارد الدخول

لتوجيه حركة المرور وتوزيعها، Traefik هي وحدة تحكم الدخول التي ستفي بموارد دخول Kubernetes. توجد موازنات التحميل الداخلية Azure في هذه الشبكة الفرعية. لمزيدٍ من المعلومات، راجع استخدام موازن تحميل داخلي مع Azure Kubernetes Service (AKS).

الشبكة الفرعية لاستضافة عقد نظام المجموعة

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

الشبكة الفرعية لاستضافة نقاط نهاية Private Link

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

لمزيد من المعلومات، راجع خيارات نشر الارتباط الخاص.

البحث عن عناوين IP

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

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

• إصلاح

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

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

• قابلية التوسع

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

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

• عناوين Azure Private Link

  عامل في العناوين المطلوبة للاتصال بخدمات Azure الأخرى عبر Private Link. في هذه البنية، لدينا عنوانان مخصصان للارتباطات إلى Azure Container Registry Key Vault.

• عناوين معينة محجوزة للاستخدام بواسطة Azure. لا يمكن تعيينها.

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

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

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

للحصول على معلومات تتعلق بتخطيط IP لمجموعة AKS، راجع تخطيط عنوان IP لنظام المجموعة الخاص بك.

لمراجعة اعتبارات تخطيط عنوان IP المضمنة في حاويات Windows على البنية المرجعية الأساسية ل AKS، راجع المقالة المصاحبة.

الوظائف الإضافية وميزات المعاينة

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

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

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

مرجع صورة الحاوية

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

• تتم مصادقة نظام المجموعة لسحب الصورة.

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

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

  أحد الخيارات هو Azure Container Registry (ACR).

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

تكوين الحوسبة للمجموعة الأساسية

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

بالنسبة إلى تجمع عقدة المستخدم، فيما يلي بعض الاعتبارات:

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

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

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

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

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

دمج معرف Microsoft Entra لنظام المجموعة

يعد تأمين الوصول من وإلى نظام المجموعة أمرا بالغ الأهمية. فكر من منظور نظام المجموعة عند اتخاذ خيارات الأمان:

• الوصول من الداخل إلى الخارج. وصول AKS إلى مكونات Azure مثل البنية الأساسية للشبكات وسجل حاويات Azure وAzure Key Vault. تخويل الموارد التي يسمح لنظام المجموعة بالوصول إليها فقط.
• الوصول الخارجي. توفير الوصول إلى الهويات إلى مجموعة Kubernetes. تخويل فقط الكيانات الخارجية المسموح لها بالوصول إلى خادم Kubernetes API وAzure Resource Manager.

وصول AKS إلى Azure

هناك طريقتان لإدارة AKS للوصول إلى Azure من خلال معرف Microsoft Entra: أساسيات الخدمة أو الهويات المدارة لموارد Azure.

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

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

بشكل افتراضي، هناك هويتان أساسيتان يستخدمهما نظام المجموعة، وهوية نظام المجموعة وهوية kubelet. يتم استخدام هوية نظام المجموعة بواسطة مكونات وحدة التحكم AKS لإدارة موارد نظام المجموعة بما في ذلك موازنات تحميل الدخول و IPs العامة المدارة من AKS وما إلى ذلك. يتم استخدام هوية kubelet للمصادقة مع Azure Container Registry (ACR). تدعم بعض الوظائف الإضافية أيضا المصادقة باستخدام هوية مدارة.

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

في هذه البنية، يصل نظام المجموعة إلى موارد Azure التي يتم تأمينها بواسطة معرف Microsoft Entra وتنفيذ العمليات التي تدعم الهويات المدارة. تعيين التحكم في الوصول المستند إلى الدور Azure (Azure RBAC) والأذونات للهويات المدارة للمجموعة، اعتمادا على العمليات التي تنوي المجموعة القيام بها. يصادق نظام المجموعة نفسه على معرف Microsoft Entra ثم يتم السماح به أو رفض الوصول استنادا إلى الأدوار التي تم تعيينها له. فيما يلي بعض الأمثلة من هذا التنفيذ المرجعي حيث تم تعيين أدوار Azure المضمنة إلى نظام المجموعة:

• مساهم الشبكة. قدرة نظام المجموعة على التحكم في الشبكة الظاهرية المحورية. يسمح تعيين الدور هذا للهوية المعينة لنظام مجموعة AKS بالعمل مع الشبكة الفرعية المخصصة لخدمات وحدة تحكم الدخول الداخلية.
• مقاييس قاعدة بيانات الناشر المتعلقة بالمراقبة. قدرة نظام المجموعة على إرسال المقاييس إلى Azure Monitor.
• AcrPull. قدرة نظام المجموعة على سحب الصور من سجلات حاوية Azure المحددة.

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

يعمل تكامل Microsoft Entra أيضا على تبسيط الأمان للوصول الخارجي. لنفترض أن المستخدم يريد استخدام kubectl. كخطوة أولية az aks get-credentials ، يقومون بتشغيل الأمر للحصول على بيانات اعتماد نظام المجموعة. سيقوم معرف Microsoft Entra بمصادقة هوية المستخدم مقابل أدوار Azure المسموح لها بالحصول على بيانات اعتماد نظام المجموعة. لمزيد من المعلومات، راجع أذونات أدوار نظام المجموعة المتوفرة.

تسمح AKS بالوصول إلى Kubernetes باستخدام معرف Microsoft Entra بطريقتين. الأول هو استخدام معرف Microsoft Entra كموفر هوية متكامل مع نظام Kubernetes RBAC الأصلي. والآخر يستخدم Azure RBAC الأصلي للتحكم في الوصول إلى نظام المجموعة. كلاهما مفصل أدناه.

إقران Kubernetes RBAC إلى معرف Microsoft Entra

التحكم في الوصول استنادًا إلى الدور (RBAC) الخاص بـ Kubernetes:

• مجموعة من الأذونات. تم تعريفه بواسطة عنصر Role أو ClusterRole للأذونات على مستوى نظام المجموعة.

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

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

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

استخدام التحكم في الوصول استناداً إلى الدور لـ Azure للحصول على مصادقة Kubernetes

بدلا من استخدام Kubernetes native RBAC (ClusterRoleBindings و RoleBindings) للتخويل مع مصادقة Microsoft Entra المتكاملة، هناك خيار آخر نوصي به، وهو استخدام Azure RBAC وتعيينات دور Azure لفرض عمليات التحقق من التخويل على نظام المجموعة. يمكن إضافة تعيينات الدور هذه في نطاقات الاشتراك أو مجموعة الموارد بحيث ترث جميع المجموعات ضمن النطاق مجموعة متسقة من تعيينات الأدوار فيما يتعلق بمن لديه أذونات للوصول إلى الكائنات على مجموعة Kubernetes.

لمزيد من المعلومات، راجع Azure RBAC لتخويل Kubernetes.

الحسابات المحلية

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

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

دمج معرف Microsoft Entra لحمل العمل

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

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

توزيع موارد الدخول

توجه موارد دخول Kubernetes نسبة استخدام الشبكة الواردة إلى نظام المجموعة وتوزعها. هناك جزءان من موارد الدخول:

• موازن التحميل الداخلي. يديرها AKS. يعرض موازن التحميل هذا وحدة تحكم الدخول من خلال عنوان IP ثابت خاص. وهو بمثابة نقطة اتصال واحدة تتلقى التدفقات الواردة.

  في هذه البنية، يتم استخدام Azure Load Balancer. يتم وضعه خارج نظام المجموعة في شبكة فرعية مخصصة لموارد الدخول. يتلقى نسبة استخدام الشبكة من Azure Application Gateway وأن الاتصال عبر TLS. للحصول على معلومات حول تشفير TLS لنسبة استخدام الشبكة الواردة، راجع تدفق حركة مرور الدخول.

• وحدة التحكم في الدخول. لقد اخترنا Traefik. يتم تشغيله في تجمع عقدة المستخدم في نظام المجموعة. يتلقى نسبة استخدام الشبكة من موازن التحميل الداخلي، وينهي TLS، ويعيد توجيهه إلى قرون حمل العمل عبر HTTP.

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

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

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

• تقييد القرون ليتم جدولتها فقط على تجمع عقدة المستخدم باستخدام nodeSelectors. سيؤدي هذا الإعداد إلى عزل حمل العمل ووحدات النظام.

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

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

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

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

إعدادات جهاز التوجيه

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

فيما يلي مثال من هذه البنية:

يستخدم Traefik موفر Kubernetes لتكوين المسارات. يشير annotations,tlsو entrypoints إلى أنه سيتم تقديم المسارات عبر HTTPS. middlewares يحدد أن نسبة استخدام الشبكة فقط من الشبكة الفرعية لبوابة تطبيق Azure مسموح بها. ستستخدم الاستجابات ترميز gzip إذا قبل العميل. نظرا لأن Traefik يقوم بإنهاء TLS، فإن الاتصال بخدمات الواجهة الخلفية عبر HTTP.

apiVersion:networking.k8s.io/v1
kind: Ingress
metadata:
  name: aspnetapp-ingress
  namespace: a0008
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.class: traefik-internal
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    traefik.ingress.kubernetes.io/router.tls.options: default
    traefik.ingress.kubernetes.io/router.middlewares: app-gateway-snet@file, gzip-compress@file
spec:
  tls:
  - hosts:
      - bu0001a0008-00.aks-ingress.contoso.com
  rules:
  - host: bu0001a0008-00.aks-ingress.contoso.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: aspnetapp-service
            port: 
              number: 80

تأمين تدفق الشبكة

يمكن تصنيف تدفق الشبكة، في هذا السياق، على النحو التالي:

• نسبة استخدام الشبكة الداخلة. من العميل إلى حمل العمل الذي يعمل في نظام المجموعة.

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

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

• إدارة نسبة استخدام الشبكة. نسبة استخدام الشبكة التي تنتقل بين العميل وخادم واجهة برمجة تطبيقات Kubernetes.

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

تحتوي هذه البنية على عدة طبقات من الأمان لتأمين جميع أنواع نسبة استخدام الشبكة.

تدفق نسبة استخدام الشبكة للدخول

تقبل البنية طلبات TLS المشفرة فقط من العميل. TLS v1.2 هو الحد الأدنى المسموح به للإصدار مع مجموعة مقيدة من cyphers. تم تمكين إشارة اسم الخادم (SNI) الصارمة. يتم إعداد TLS من طرف إلى طرف من خلال بوابة التطبيق باستخدام شهادتي TLS مختلفتين، كما هو موضح في هذه الصورة.

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

1. يرسل العميل طلب HTTPS إلى اسم المجال: bicycle.contoso.com. يرتبط هذا الاسم من خلال سجل DNS A بعنوان IP العام لبوابة تطبيق Azure. يتم تشفير حركة المرور هذه للتأكد من أنه لا يمكن فحص حركة المرور بين متصفح العميل والبوابة أو تغييرها.

2. يحتوي Application Gateway على جدار حماية تطبيق ويب متكامل (WAF) ويتفاوض على تأكيد اتصال TLS bicycle.contoso.com، ما يسمح بالشفرات الآمنة فقط. بوابة التطبيق هي نقطة إنهاء TLS، كما هو مطلوب لمعالجة قواعد فحص WAF، وتنفيذ قواعد التحويل التي تعيد توجيه نسبة استخدام الشبكة إلى الخلفية المكونة. يتم تخزين شهادة TLS في Azure Key Vault. يتم الوصول إليها باستخدام هوية مدارة يعينها المستخدم مدمجة مع بوابة التطبيق. لمزيد من المعلومات، راجع إنهاء TLS مع شهادات Key Vault.

3. مع انتقال نسبة استخدام الشبكة من بوابة التطبيق إلى الخلفية، يتم تشفيرها مرة أخرى باستخدام شهادة TLS أخرى (حرف بدل ل *.aks-ingress.contoso.com) أثناء إعادة توجيهها إلى موازن التحميل الداخلي. تعمل إعادة التشفير هذه على التأكد من أن نسبة استخدام الشبكة غير الآمنة لا تتدفق إلى الشبكة الفرعية لنظام المجموعة.

4. تتلقى وحدة تحكم الدخول نسبة استخدام الشبكة المشفرة من خلال موازن التحميل. وحدة التحكم هي نقطة إنهاء TLS أخرى ل *.aks-ingress.contoso.com وتعيد توجيه نسبة استخدام الشبكة إلى pods حمل العمل عبر HTTP. يتم تخزين الشهادات في Azure Key Vault وتثبيتها في نظام المجموعة باستخدام برنامج تشغيل واجهة تخزين الحاوية (CSI). لمزيد من المعلومات، راجع إضافة إدارة سرية.

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

Egress تدفق نسبة استخدام الشبكة

في هذه البنية، نوصي بجميع حركة الخروج من المجموعة التي تتواصل من خلال جدار حماية Azure أو الجهاز الظاهري للشبكة المماثلة، عبر خيارات أخرى مثل بوابة NAT أو وكيل HTTP. للتحكم في عدم الثقة والقدرة على فحص نسبة استخدام الشبكة، تنتقل جميع نسبة استخدام الشبكة الخارجة من نظام المجموعة عبر جدار حماية Azure. يمكنك تنفيذ هذا الاختيار باستخدام المسارات المعرفة من قبل المستخدم (UDRs). الوثبة التالية للمسار هي عنوان IP الخاص لجدار حماية Azure. هنا، يقرر جدار حماية Azure ما إذا كان يجب حظر حركة مرور الخروج أو السماح بها. يستند هذا القرار إلى القواعد المحددة في Azure Firewall أو قواعد التحليل الذكي للمخاطر المضمنة.

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

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

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

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

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

حركة مرور Pod-to-pod

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

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

لمزيد من المعلومات، راجع الاختلافات بين نهج شبكة Azure ونهج Calico وقدراتها.

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

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

لمزيد من المعلومات، راجع تعريف نطاقات IP المعتمدة لخادم API.

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

إضافة سرية المفاتيح

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

تكامل Azure Key Vault بشكل جيد مع خدمات Azure الأخرى. استخدم الميزة المضمنة لتلك الخدمات للوصول إلى الأسرار. للحصول على مثال حول كيفية وصول Azure Application Gateway إلى شهادات TLS لتدفق الدخول، راجع قسم تدفق حركة مرور الدخول.

يسمح لك نموذج إذن Azure RBAC ل Key Vault بتعيين هويات حمل العمل إما إلى تعيين دور Key Vault Secrets User أو Key Vault Reader والوصول إلى الأسرار. لمزيد من المعلومات، راجع الوصول إلى Azure Key Vault باستخدام RBAC.

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

ستحتاج إلى استخدام هويات حمل العمل للسماح ل pod بالوصول إلى الأسرار من متجر معين. لتسهيل عملية الاسترداد، استخدم برنامج تشغيل Secrets Store CSI. عندما يحتاج الكبسولة إلى سر، يتصل برنامج التشغيل بالمخزن المحدد، ويسترد البيانات السرية على وحدة تخزين، ويحمل وحدة التخزين هذه في نظام المجموعة. يمكن للجراب بعد ذلك الحصول على السر من نظام ملفات وحدة التخزين.

يحتوي برنامج تشغيل CSI على العديد من الموفرين لدعم مختلف المتاجر المدارة. في هذا التنفيذ، اخترنا Azure Key Vault مع Secrets Store CSI Driver باستخدام الوظيفة الإضافية لاسترداد شهادة TLS من Azure Key Vault وتحميلها في الجراب الذي يقوم بتشغيل وحدة تحكم الدخول. يتم ذلك أثناء إنشاء الجراب وتخزن وحدة التخزين المفاتيح العامة والخاصة على حد سواء.

تخزين حمل العمل

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

لمعرفة المزيد حول خيارات التخزين، راجع خيارات التخزين للتطبيقات في خدمة Azure Kubernetes (AKS).

إدارة السياسات

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

هناك سيناريوهان مختلفان يقدمهما نهج Azure لإدارة مجموعات AKS الخاصة بك:

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

عند تعيين النهج، قم بتطبيقها بناء على متطلبات حمل العمل. خذ بعين الاعتبار هذه العوامل:

• هل تريد تعيين مجموعة من السياسات (تسمى المبادرات) أو اختيار السياسات الفردية؟ يوفر نهج Azure مبادرتين مضمنتين: أساسي ومقيد. كل مبادرة هي مجموعة من النهج المضمنة القابلة للتطبيق على نظام مجموعة AKS. يوصى بتحديد مبادرة واختيار نهج إضافية للمجموعة والموارد (ACR وبوابة التطبيق Key Vault وغيرها) التي تتفاعل مع نظام المجموعة، وفقا لمتطلبات مؤسستك.

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

• هل لديك مناطق في حمل العمل لا ينبغي أن تكون متوافقة حسب التصميم؟ لدى Azure Policy القدرة على تحديد مساحات أسماء Kubernetes المعفاة من فرض النهج. من المستحسن الاستمرار في تطبيق النهج في وضع التدقيق بحيث تكون على دراية بهذه المثيلات.

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

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

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

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

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

لمراقبة كيفية عمل Azure Policy من داخل نظام المجموعة الخاص بك، يمكنك الوصول إلى سجلات pod لجميع pods في gatekeeper-system مساحة الاسم بالإضافة إلى سجلات azure-policy و azure-policy-webhook pods في kube-system مساحة الاسم.

لمراجعة اعتبارات نهج Azure الخاصة ب Windows المضمنة في حاويات Windows على البنية المرجعية الأساسية ل AKS، راجع المقالة المصاحبة.

قابلية توسعة العقدة والجراب

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

هناك طريقتان: التحجيم التلقائي أو التحجيم اليدوي.

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

التحجيم التلقائي هو النهج الموصى به لأن بعض هذه الآليات اليدوية مضمنة في مقياس تلقائي.

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

التحجيم التلقائي للقرن الأفقي

التحجيم التلقائي للجراب الأفقي (HPA) هو مورد Kubernetes الذي يقاس عدد القرون.

في مورد HPA، يوصى بتعيين الحد الأدنى والحد الأقصى لعدد النسخ المتماثلة. تقيد هذه القيم حدود التحجيم التلقائي.

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

قد تكون هناك حالة تعارض حيث يتحقق (HPA) قبل اكتمال عملية التحجيم. قد تكون النتيجة حساب نسبة غير صحيح. للحصول على التفاصيل، راجع تهدئة أحداث التحجيم.

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

أداة التحجيم التلقائي لنظام المجموعة

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

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

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

بالنسبة لتجمع عقدة النظام، القيمة الدنيا الموصى بها هي 3.

لمراجعة اعتبارات التحجيم المضمنة في حاويات Windows على البنية المرجعية الأساسية ل AKS، راجع المقالة المصاحبة.

قرارات استمرارية الأعمال

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

عقد المجموعة

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

اعزل التطبيق (التطبيقات) عن خدمات النظام عن طريق وضعه في تجمع عقدة منفصل، يشار إليه باسم تجمع عقدة المستخدم. بهذه الطريقة، تعمل خدمات Kubernetes على عقد مخصصة ولا تتنافس مع حمل العمل الخاص بك. يوصى باستخدام العلامات والتسميات والملامح لتحديد تجمع العقدة لجدولة حمل العمل الخاص بك، والتأكد من أن تجمع عقدة النظام الخاص بك ملطخ ب CriticalAddonsOnly [taint] (/azure/aks/use-system-pools#system-and-user-node-pools).

يعد الصيانة المنتظمة لنظام المجموعة مثل التحديثات في الوقت المناسب أمرا بالغ الأهمية للموثوقية. كما يوصى بمراقبة صحة الجرابات من خلال الفحوصات.

توفر الجراب

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

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

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

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

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

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

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

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

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

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

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

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

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

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

للتبسيط، في هذه البنية يتم نشر AKS في منطقة واحدة مع تجمعات العقد التي تغطي مناطق التوفر 1 و2 و3. يتم نشر الموارد الأخرى للبنية الأساسية، مثل Azure Firewall وApplication Gateway إلى نفس المنطقة أيضا بدعم متعدد المناطق. يتم تمكين النسخ المتماثل الجغرافي لسجل حاوية Azure.

مناطق متعددة

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

• استخدم المناطق المزدوجة. ضع في اعتبارك استخدام البنية الأساسية لبرنامج ربط العمليات التجارية CI/CD التي تم تكوينها لاستخدام منطقة مقترنة للتعافي من حالات فشل المنطقة. تتمثل إحدى فوائد استخدام المناطق المقترنة في الموثوقية أثناء التحديثات. يتأكد Azure من تحديث منطقة واحدة فقط في الزوج في كل مرة. يمكن لبعض أدوات DevOps مثل Flux تسهيل عمليات النشر متعددة المناطق.

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

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

التعافي من الكوارث

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

• استخدم المناطق المزدوجة.

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

• دمج استراتيجية الاسترداد، مثل النسخ المتماثل إلى منطقة أخرى، كجزء من مسار DevOps لتحقيق أهداف مستوى الخدمة (SLO).

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

النسخ الاحتياطي لنظام المجموعة

بالنسبة للعديد من البنيات، يمكن توفير مجموعة جديدة وإعادتها إلى حالة التشغيل من خلال [نظام المجموعة bootstrapping} المستند إلى GitOps(#cluster-bootstrapping) متبوعا بنشر التطبيق. ومع ذلك، إذا كانت هناك حالة موارد حرجة مثل خرائط التكوين والوظائف والأسرار المحتملة التي لا يمكن التقاطها لسبب ما ضمن عملية تمهيد التشغيل، ففكر في استراتيجية الاسترداد الخاصة بك. يوصى عموما بتشغيل أحمال العمل عديمة الحالة في Kubernetes، ولكن إذا كانت البنية الخاصة بك تتضمن حالة مستندة إلى القرص، فستحتاج أيضا إلى النظر في استراتيجية الاسترداد الخاصة بك لهذا المحتوى.

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

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

لا ينفذ التنفيذ المرجعي النسخ الاحتياطي، مما قد يتضمن موارد Azure إضافية في البنية لإدارة ومراقبة ودفع ثمن وتأمين؛ مثل حساب Azure Storage، وAzure Backup vault والتكوين، والوصول الموثوق به. GitOps جنبا إلى جنب مع الهدف من تشغيل حمل العمل عديم الحالة هو حل الاسترداد الذي تم تنفيذه.

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

اتفاقية مستوى الخدمة لخادم واجهة برمجة تطبيقات Kubernetes

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

المقايضة

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

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

اختبار مع المحاكاة وتجاوز الفشل القسري

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

لمزيد من المعلومات، راجع Azure Chaos Studio.

مراقبة المقاييس وجمعها

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

تصدر معظم أحمال العمل المستضافة في pods مقاييس Prometheus. رؤى الحاوية قادرة على التكامل مع Prometheus لعرض مقاييس التطبيق وأحمال العمل التي تجمعها من العقد وKubernetes.

هناك بعض حلول الجهات الخارجية التي تتكامل مع Kubernetes التي يمكنك الاستفادة منها، مثل Datadog أو Grafana أو New Relic، إذا كانت مؤسستك تستخدمها بالفعل.

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

• تسجيل الدخول إلى ClusterAutoscaler للحصول على إمكانية الملاحظة في عمليات التحجيم. لمزيد من المعلومات، راجع استرداد سجلات التحجيم التلقائي للمجموعة وحالتها.
• KubeControllerManager أن يكون لديه إمكانية الملاحظة في التفاعل بين Kubernetes ومستوى التحكم Azure.
• KubeAuditAdmin للحصول على إمكانية الملاحظة في الأنشطة التي تعدل نظام المجموعة الخاص بك. لا يوجد سبب لتمكين كل من KubeAuditو KubeAuditAdmin، حيث إن KubeAudit عبارة عن مجموعة فائقة من KubeAuditAdmin تتضمن عمليات غير تعديل (قراءة) أيضاً.
• يلتقط Guard عمليات تدقيق Microsoft Entra ID وAzure RBAC.

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

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

لمزيد من المعلومات حول أفضل ممارسات المراقبة الخاصة بنا ل AKS، راجع مراقبة خدمة Azure Kubernetes (AKS) باستخدام Azure Monitor.

لمراجعة اعتبارات المراقبة الخاصة ب Windows المضمنة في حاويات Windows على البنية المرجعية الأساسية ل AKS، راجع المقالة المصاحبة.

تمكين الشفاء الذاتي

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

تحديثات نظام مجموعة AKS

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

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

• عقد AKS:

  1. بلا/تحديثات يدوية: هذا للبنية الأساسية غير القابلة للتغيير أو عندما تكون التحديثات اليدوية هي الأفضل. وهذا يحقق مستوى أكبر من قابلية التنبؤ والتحكم في تحديثات عقد AKS.
  2. التحديثات التلقائية غير المراقب: تنفذ AKS تحديثات نظام التشغيل الأصلية. وهذا يعطي إمكانية التنبؤ عن طريق تكوين نوافذ الصيانة تتماشى مع ما هو جيد للأعمال. قد يستند إلى ساعات الذروة وأفضل العمليات. مستوى التحكم منخفض لأنه لا يمكن معرفة مسبقا ما سيتم تثبيته على وجه التحديد داخل عقدة AKS.
  3. تحديثات صورة العقدة التلقائية: يوصى بتحديث صور عقدة AKS تلقائيا عند توفر الأقراص الثابتة الظاهرية الجديدة (VHDs). تصميم نوافذ الصيانة لتكون متوافقة قدر الإمكان مع احتياجات الأعمال. بالنسبة لتحديثات VHD المسماة بالأمان، يوصى بتكوين نوافذ صيانة يومية تعطي أقل قابلية للتنبؤ. يمكن تكوين تحديثات VHD العادية مع نافذة صيانة أسبوعية، كل أسبوعين أو حتى شهريا. اعتمادا على ما إذا كانت الحاجة إلى أقراص VHD مخصصة للأمان مقابل أقراص VHD العادية جنبا إلى جنب مع نافذة الصيانة المجدولة، تتقلب إمكانية التنبؤ مما يوفر مرونة أكثر أو أقل ليتم محاذاتها مع متطلبات العمل. في حين أن ترك هذا دائما إلى متطلبات العمل سيكون مثاليا، فإن الواقع يفرض على المنظمات العثور على نقطة التحول. مستوى التحكم منخفض لأنه لا يمكن معرفة الثنائيات المحددة التي تم تضمينها مسبقا في VHD جديد ولا يزال هذا النوع من التحديثات التلقائية هو الخيار الموصى به نظرا لأنه يتم فحص الصور قبل أن تصبح متاحة.

  إشعار

  لمزيد من المعلومات حول كيفية تكوين تحديثات عقد AKS التلقائية، يرجى إلقاء نظرة على صور نظام تشغيل عقدة الترقية التلقائية.

• إصدار نظام مجموعة AKS:

  1. بلا/تحديثات يدوية: هذا للبنية الأساسية غير القابلة للتغيير أو عندما تكون التحديثات اليدوية هي الأفضل. وهذا يحقق مستوى أكبر من قابلية التنبؤ والتحكم في تحديثات إصدار نظام مجموعة AKS. يوصى بالاشتراك في ذلك، نظرا لأن هذا يترك في تحكم كامل مما يتيح الفرصة لاختبار إصدار نظام مجموعة AKS جديد (أي 1.14.x إلى 1.15.x) في بيئات أقل قبل الوصول إلى الإنتاج.
  2. التحديثات التلقائية: لا ينصح بتصحيح نظام مجموعة الإنتاج أو تحديثها تلقائيا بأي شكل (أي 1.16.x إلى 1.16.y) إلى إصدار نظام مجموعة AKS الجديد المتوفر دون اختباره بشكل صحيح في بيئات أقل. بينما يتم تنسيق إصدارات Kubernetes المصدر وتحديثات إصدار نظام مجموعة AKS مع إيقاع منتظم، فإن التوصية لا تزال لتكون دفاعية مع مجموعات AKS في الإنتاج مما يزيد من إمكانية التنبؤ والتحكم في عملية التحديث. مقابل النظر في هذا التكوين للبيئات الأقل كجزء من التميز التشغيلي، مما يتيح تنفيذ الاختبارات الروتينية الاستباقية للكشف عن المشكلات المحتملة في أقرب وقت ممكن.

حافظ على تحديث إصدار Kubernetes مع إصدارات N-2 المدعومة. تعد الترقية إلى أحدث إصدار من Kubernetes أمرا بالغ الأهمية لأنه يتم إصدار إصدارات جديدة بشكل متكرر.

لمزيد من المعلومات، راجع التحديث بانتظام إلى أحدث إصدار من Kubernetesوترقية نظام مجموعة Azure Kubernetes Service (AKS).

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

التحديثات الأسبوعية

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

التحديثات اليومية

بين ترقيات الصور، تقوم عقد AKS بتنزيل وتثبيت نظام التشغيل وتصحيحات وقت التشغيل، بشكل فردي. قد يتطلب التثبيت إعادة تشغيل العقدة VMs. لن تقوم AKS بإعادة تشغيل العقد بسبب التحديثات المعلقة. لديك عملية تراقب العقد للتحديثات المطبقة التي تتطلب إعادة التشغيل وتنفذ إعادة تشغيل تلك العقد بطريقة خاضعة للتحكم. خيار مفتوح المصدر هو Kured (البرنامج الخفي لإعادة تشغيل Kubernetes).

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

مراقبه الأمان

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

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

عمليات نظام المجموعة وأحمال العمل (DevOps)

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

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

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

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

يمكن تكوين عملية تمهيد التشغيل باستخدام إحدى الطرق التالية:

• التكوين الذاتي باستخدام شيء مثل Flux أو Argo CD
• التدفقات
• ملحق مجموعة GitOps Flux v2

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

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

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

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

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

يمكن أن يكون جزء آخر لدمج حمل العمل الأساسي مع معرف Microsoft Entra.

البنية الأساسية كتعليمة برمجية (IaC)

اختر أسلوبا تعريفيا غير فعال على نهج إلزامي، حيثما أمكن ذلك. بدلا من كتابة تسلسل من الأوامر التي تحدد خيارات التكوين، استخدم بناء الجملة التعريفي الذي يصف الموارد وخصائصها. أحد الخيارات هو قوالب Azure Resource Manager (ARM ). آخر هو Terraform.

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

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

تخزين البرامج النصية وملفات القوالب وإصدارها في نظام التحكم بالمصادر.

حمل العمل CI/CD

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

يجب أن تتضمن استراتيجية التوزيع الخاصة بك مسار تسليم مستمر (CD) موثوقا به و مُنفذ تلقائياً. يجب نشر التغييرات على صور حاوية حمل العمل تلقائيا إلى نظام المجموعة.

في هذه البنية، اخترنا GitHub Actions لإدارة سير العمل والتوزيع. تتضمن الخيارات الشائعة الأخرى خدمات Azure DevOps و Jenkins.

نظام المجموعة CI/CD

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

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

جزء أساسي من تدفق CI/CD هو تمهيد نظام مجموعة تم توفيره حديثاً. يعد نهج GitOps مفيدا لتحقيق هذه الغاية، مما يسمح للمشغلين بتعريف عملية تمهيد التشغيل بشكل تعريفي كجزء من استراتيجية IaC ورؤية التكوين ينعكس في المجموعة تلقائيا.

عند استخدام GitOps، يتم نشر عامل في نظام المجموعة للتأكد من تنسيق حالة نظام المجموعة مع التكوين المخزن في مستودع Git الخاص بك. أحد هذه العوامل هو flux، والذي يستخدم عامل تشغيل واحد أو أكثر في نظام المجموعة لتشغيل عمليات النشر داخل Kubernetes. يقوم Flux بهذه المهام:

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

يمكنك أيضا تعيين النهج التي تحكم كيفية نشر هذه التغييرات.

فيما يلي مثال يوضح كيفية أتمتة تكوين نظام المجموعة باستخدام GitOps و flux:

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

1. يلتزم المطور بإجراء تغييرات على التعليمات البرمجية المصدر، مثل تكوين ملفات YAML، المخزنة في مستودع git. ثم يتم دفع التغييرات إلى خادم git.

2. يتم تشغيل Flux في pod جنبا إلى جنب مع حمل العمل. يتمتع Flux بإمكانية الوصول للقراءة فقط إلى مستودع git للتأكد من أن Flux يطبق التغييرات فقط كما طلب المطورون.

3. يتعرف Flux على التغييرات في التكوين ويطبق هذه التغييرات باستخدام أوامر kubectl.

4. لا يملك المطورون وصولا مباشرا إلى واجهة برمجة تطبيقات Kubernetes من خلال kubectl.

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

بينما يمكن تكوين GitOps و Flux يدويا، يوصى بملحق مجموعة GitOps مع Flux v2 ل AKS.

استراتيجيات توزيع حمل العمل والمجموعة

توزيع أي تغيير (مكونات البنية، حمل العمل، تكوين نظام المجموعة)، إلى مجموعة AKS واحدة على الأقل قبل الإنتاج. سيؤدي القيام بذلك إلى محاكاة التغيير قد يؤدي إلى كشف المشكلات قبل التوزيع إلى الإنتاج.

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

تتطلب تقنيات النشر المتقدمة مثل النشر الأزرق والأخضر واختبار A/B وإصدارات الكناري عملية إضافية والأدوات المحتملة. Flagger هو حل مفتوح المصدر شائع للمساعدة في حل سيناريوهات التوزيع المتقدمة.

إدارة التكلفة

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

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

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

تزويد

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

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

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

  بالنسبة لأحمال العمل غير الإنتاجية التي تتضمن Azure SQL Database أو Azure App Service كجزء من بنية حمل عمل AKS، قم بتقييم ما إذا كنت مؤهلا لاستخدام اشتراكات Azure Dev/Test لتلقي خصومات الخدمة.

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

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

• يمكن أن يؤدي تمكين التشخيصات على نظام المجموعة إلى زيادة التكلفة.

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

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

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

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

Monitor

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

• Azure Advisor

• Azure Cost Management

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

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

تحسين

التصرف بناء على التوصيات المقدمة من Azure استشاري. هناك طرق أخرى للقيام بذلك:

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

• اختر SKU أقل لتجمعات العقد، إذا كان حمل العمل يدعمه.

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

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

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

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

متابعة التعرف على بنية أساس AKS:

• للتعرف على استضافة الخدمات المصغرة على أساس AKS، راجع بنية الخدمات المصغرة المتقدمة لخدمة Azure Kubernetes (AKS).
• لنشر أساس AKS عبر مناطق متعددة، راجع أساس AKS للمجموعات متعددة المناطق.
• لنشر أساس AKS في بيئة PCI-DSS 3.2.1، راجع نظام مجموعة AKS المنظم ل PCI-DSS 3.2.1.
• للتعرف على اعتبارات إضافة حاويات Windows إلى البنية المرجعية، راجع المقالة المصاحبة: حاويات Windows على البنية المرجعية الأساسية ل AKS

تعرف على المزيد حول AKS

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

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

راجع الأدلة التالية ذات الصلة:

• مراجعة Azure Well-Architected Framework لخدمة Azure Kubernetes (AKS)
• مسرع منطقة هبوط AKS، وهو تنفيذ على نطاق المؤسسة يستند إلى هذه البنية. يساعدك المسرع على إعداد بيئة Azure بطريقة متسقة ومتكررة باستخدام البنية الأساسية كتعليمية (IaC) لنشر خدمة Azure Kubernetes (AKS).
• دليل عمليات اليوم الثاني لخدمات Azure Kubernetes (AKS)

راجع البنى ذات الصلة التالية:

• بنية الخدمات المصغرة في خدمة Azure Kubernetes
• استخدام Azure Firewall للمساعدة في حماية نظام مجموعة Azure Kubernetes Service (AKS)
• GitOps لخدمة Azure Kubernetes
• دفق البيانات باستخدام AKS