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

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

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

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

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

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

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

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

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

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

إدارة الهوية

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

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

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

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

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

العمليات

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

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

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

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

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

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

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

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

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

• دعم مشاركة الموارد، مثل جدار الحماية ومناطق نظام أسماء المجالات (DNS)، عبر الشبكات.

• محاذاة مع منطقة الهبوط على نطاق المؤسسة Azure.

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

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

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

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

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

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

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

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

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

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

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

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

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

الشبكة الظاهرية المركزية

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

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

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

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

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

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

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

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

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

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

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

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

تستخدم هذه البنية المرجعية نهج شبكة متعددة، والتي تتطلب كل منها مساحة عنوان IP:

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

مساحة عنوان IP للشبكة الظاهرية

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

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

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

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

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

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

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

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

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

مساحة عنوان IP لوحدة الجراب

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

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

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

لمزيد من المعلومات، راجع الإرشادات حول تخطيط عنوان IP لتراكب Azure CNI

اعتبارات مساحة عنوان IP الأخرى

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تحديد نظام تشغيل

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

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

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

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

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

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

وصول AKS إلى Azure

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

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

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

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

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

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

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

• مراقبة دور ناشر المقاييس. إدارة قدرة نظام المجموعة على إرسال المقاييس إلى Azure Monitor.

• دور AcrPull. يدير قدرة نظام المجموعة على سحب الصور من مثيلات Azure Container Registry المحددة.

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

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

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

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

يدعم Kubernetes التحكم في الوصول استنادا إلى الدور من خلال:

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

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

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

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

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

بدلا من استخدام Kubernetes 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، راجع اتحاد هوية حمل العمل.

تحديد نموذج شبكة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

يستخدم Traefik موفر Kubernetes لتكوين المسارات. annotationstlsتشير الخيارات و و entrypoints إلى أن المسارات يتم تقديمها عبر HTTPS. middlewares يحدد الخيار السماح فقط بنسبة استخدام الشبكة من الشبكة الفرعية لبوابة التطبيق. تستخدم الاستجابات ترميز 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

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

في هذه البنية، يتضمن تدفق الشبكة ما يلي:

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

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

• حركة مرور Pod-to-pod بين pods. تتضمن حركة المرور هذه الاتصال بين وحدة تحكم الدخول وعبء العمل. إذا كان حمل العمل الخاص بك يتكون من تطبيقات متعددة تم نشرها في نظام المجموعة، فإن الاتصال بين هذه التطبيقات يندرج أيضا في هذه الفئة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

لمزيد من المعلومات حول اعتبارات نهج Azure الخاصة ب Windows، راجع مقالة إدارة نهج حاويات Windows على AKS.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

عقد المجموعة

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

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

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

توفر الجراب

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

مناطق متعددة

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

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

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

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

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

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

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

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

• دمج استراتيجية الاسترداد، مثل النسخ المتماثل إلى منطقة أخرى، كجزء من مسار DevOps لتلبية SLO الخاص بك.

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

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

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

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

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

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

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

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

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

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

المقايضة

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

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

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

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

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

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

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

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

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

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

• ClusterAutoscaler: اكتساب إمكانية الملاحظة في عمليات التحجيم مع التسجيل. لمزيد من المعلومات، راجع استرداد سجلات التحجيم التلقائي للمجموعة وحالتها.
• KubeControllerManager: اكتساب إمكانية الملاحظة في التفاعل بين Kubernetes وAzure control plane.
• kube-audit-admin: اكتساب إمكانية الملاحظة في الأنشطة التي تعدل نظام المجموعة الخاص بك. لا يوجد سبب لتمكين كل منهما kube-audit kube-audit-admin . kube-audit هي مجموعة فائقة تتضمن kube-audit-admin عمليات غير معدلة (قراءة) أيضا.
• guard: تسجيل Microsoft Entra ID وAzure RBAC audits.

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

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

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

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

مقاييس الشبكة

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

بالنسبة لأحمال العمل الحساسة للغاية لبروتوكول التحكم في الإرسال (TCP) أو فقدان حزمة بروتوكول مخطط بيانات المستخدم (UDP) أو زمن الانتقال أو ضغط DNS، تعد مقاييس الشبكة على مستوى الجراب مهمة. في AKS، يمكنك العثور على هذا المستوى من التفاصيل باستخدام ميزة مراقبة الشبكة المتقدمة. لا تتطلب معظم أحمال العمل هذا العمق من إمكانية مراقبة الشبكة. يجب عدم تثبيت الوظيفة الإضافية Advanced Network Observability ما لم تطلب pods شبكة محسنة للغاية، مع حساسية وصولا إلى مستوى الحزمة.

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

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

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

جزء من عمليات اليوم-2 لمجموعات Kubernetes هو إجراء تحديثات النظام الأساسي ونظام التشغيل الروتينية. هناك ثلاث طبقات من التحديثات التي يجب معالجتها على كل مجموعة AKS:

• إصدار Kubernetes (على سبيل المثال، Kubernetes 1.30.3 إلى 1.30.7 أو Kubernetes 1.30.7 إلى 1.31.1)، والذي قد يأتي مع تغييرات Kubernetes API وإيقافها. تؤثر تغييرات الإصدار في هذه الطبقة على المجموعة بأكملها.
• صورة القرص الثابت الظاهري (VHD) على كل عقدة، والتي تجمع بين تحديثات نظام التشغيل وتحديثات مكونات AKS. يتم اختبار هذه التحديثات مقابل إصدار Kubernetes لنظام المجموعة. يتم تطبيق تغييرات الإصدار في هذه الطبقة على مستوى تجمع العقدة ولا تؤثر على إصدار Kubernetes.
• عملية التحديث الأصلية لنظام التشغيل، مثل Windows Update أو apt. يوفر مورد نظام التشغيل هذه التحديثات مباشرة ولا يتم اختبارها مقابل إصدار Kubernetes لنظام المجموعة. تؤثر تغييرات الإصدار في هذه الطبقة على عقدة واحدة ولا تؤثر على إصدار Kubernetes.

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

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

بنية أساسية ثابتة

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

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

الترقيات الموضعية

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

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

الترقيات الموضعية للعقد

استخدم قناة الترقية NodeImage التلقائية لترقيات صورة نظام التشغيل للعقدة. تقوم هذه القناة بتكوين نظام المجموعة لتحديث VHD على كل عقدة مع تحديثات على مستوى العقدة. تختبر Microsoft التحديثات مقابل إصدار AKS الخاص بك. بالنسبة لعقد Windows، تحدث التحديثات مرة واحدة في الشهر تقريبا. بالنسبة لعقد Linux، تحدث هذه التحديثات مرة واحدة في الأسبوع تقريبا.

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

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

يجب أن تتجنب معظم المجموعات التي تقوم بالترقيات الموضعية خيارات قناة ترقية None صورة العقدة و Unmanaged .

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

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

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

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

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

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

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

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

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

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

لاعتبارات عمليات نظام المجموعة وأحمال العمل (DevOps)، راجع ركيزة مبادئ تصميم التميز التشغيلي.

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

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

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

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

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

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

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

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

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

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

مهمة أخرى هي دمج حمل العمل الأساسي مع معرف Microsoft Entra.

استخدام IaC

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

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

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

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

حمل العمل CI/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 في جراب جنبا إلى جنب مع حمل العمل. يتمتع Flux بإمكانية الوصول للقراءة فقط إلى مستودع Git للتأكد من أن Flux يطبق التغييرات فقط كما طلب المطورون.

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

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

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

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

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

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

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

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

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

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

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

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

تزويد

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

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

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

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

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

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

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

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

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

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

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

Monitor

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

• Azure Advisor

• Microsoft Cost Management

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

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

تحسين

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

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

  هام

  قد يكون لتغيير إعدادات التحجيم التلقائي لنظام المجموعة بقوة، مثل الحد الأدنى والحد الأقصى لإعدادات العقدة لتجمع عقدة، للتأثير على التكاليف نتائج عكسية. على سبيل المثال، إذا scale-down-unneeded-time تم تعيين إلى 10 دقائق، ويتم تعديل إعدادات العقدة الدنيا والحد الأقصى كل خمس دقائق استنادا إلى خصائص حمل العمل، فلن يقلل عدد العقد أبدا. وذلك لأن حساب الوقت غير الضروري لكل عقدة يتم إعادة تعيينه بسبب تحديث إعدادات التحجيم التلقائي لنظام المجموعة.

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

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

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

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

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

• بنية متقدمة للخدمات المصغرة من AKS
• خط AKS أساسي لأنظمة مجموعة متعددة المناطق
• نظام مجموعة AKS المنظم ل PCI-DSS 3.2.1
• حاويات Windows على البنية المرجعية الأساسية ل AKS

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

• خارطة طريق AKS على GitHub
• مقدمة إلى Kubernetes
• تطوير التطبيقات ونشرها على Kubernetes
• مراجعة إطار عمل مصممة جيدا ل AKS
• مسرع منطقة هبوط AKS
• دليل عمليات اليوم الثاني لـ AKS
• بنية الخدمات المصغرة على AKS
• استخدام Azure Firewall للمساعدة في حماية نظام مجموعة AKS
• عمليات Git ل AKS
• دفق البيانات باستخدام AKS