مشاركة عبر

أفضل الممارسات للأداء والتحجيم لأحمال العمل الكبيرة في خدمة Azure Kubernetes (AKS)

  • مقالة

إشعار

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

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

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

في هذه المقالة، ستتعرف على:

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

قابلية توسع مستوى التحكم AKS وKubernetes

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

يحتوي Kubernetes على مغلف مقياس متعدد الأبعاد مع كل نوع مورد يمثل بعدا. ليست كل الموارد متشابهة. على سبيل المثال، عادة ما يتم تعيين الساعات على الأسرار، ما يؤدي إلى استدعاءات القائمة إلى kube-apiserver التي تضيف تكلفة وتحميلا أعلى بشكل غير متناسب على مستوى التحكم مقارنة بالموارد دون ساعات.

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

يتناسب حجم المغلف مع حجم وحدة التحكم Kubernetes. تدعم AKS ثلاثة مستويات لمستوى التحكم كجزء من وحدة SKU الأساسية: المستوى المجاني والقياسي والمتميزة. لمزيد من المعلومات، راجع مستويات التسعير المجانية والقياسية والمتميزة لإدارة نظام مجموعة AKS.

هام

نوصي بشدة باستخدام المستوى القياسي أو المتميز للإنتاج أو أحمال العمل على نطاق واسع. تقوم AKS تلقائيا بتحجيم مستوى التحكم Kubernetes لدعم حدود المقياس التالية:

  • ما يصل إلى 5000 عقدة لكل مجموعة AKS
  • 200000 حاوية لكل مجموعة AKS (مع تراكب Azure CNI)

في معظم الحالات، يؤدي تجاوز حد الحد الأقصى للمقياس إلى انخفاض الأداء، ولكنه لا يتسبب في تجاوز فشل نظام المجموعة على الفور. لإدارة التحميل على مستوى التحكم Kubernetes، ضع في اعتبارك التحجيم على دفعات تصل إلى 10-20٪ من المقياس الحالي. على سبيل المثال، بالنسبة إلى مجموعة عقدة 5000، قم بتحجيم بزيادات من 500 إلى 1000 عقدة. بينما تقوم AKS بالتحجيم التلقائي لمستوى التحكم الخاص بك، فإنه لا يحدث على الفور.

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

عملاء Kubernetes

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

يمكنك تحليل حركة مرور خادم API وسلوك العميل من خلال سجلات تدقيق Kube. لمزيد من المعلومات، راجع استكشاف أخطاء وحدة تحكم Kubernetes وإصلاحها.

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

  • ضع في اعتبارك عدد الكائنات (CRs) التي تتوقع وجودها في النهاية عند تعريف نوع مورد جديد (CRD).
  • يعتمد التحميل على etcd وخادم API بشكل أساسي على عدد الكائنات الموجودة، وليس عدد العناصر التي يتم إرجاعها. حتى إذا كنت تستخدم محدد حقل لتصفية القائمة واسترداد عدد قليل فقط من النتائج، فلا تزال هذه الإرشادات سارية. الاستثناء الوحيد هو استرداد كائن واحد بواسطة metadata.name.
  • تجنب استدعاءات LIST المتكررة إذا كان ذلك ممكنا إذا كانت التعليمات البرمجية الخاصة بك تحتاج إلى الاحتفاظ بقائمة محدثة من الكائنات في الذاكرة. بدلا من ذلك، ضع في اعتبارك استخدام فئات Informer المتوفرة في معظم مكتبات Kubernetes. يجمع المخبرون تلقائيا بين وظائف LIST و WATCH للحفاظ على مجموعة في الذاكرة بكفاءة.
  • ضع في اعتبارك ما إذا كنت بحاجة إلى تناسق قوي إذا لم يفي المخبرون باحتياجاتك. هل تحتاج إلى رؤية أحدث البيانات، حتى اللحظة الدقيقة التي أصدرت فيها الاستعلام؟ إذا لم يكن الأمر كما هو، فقم بتعيين ResourceVersion=0. يؤدي هذا إلى خدمة ذاكرة التخزين المؤقت لخادم API لطلبك بدلا من etcd.
  • إذا لم تتمكن من استخدام Informers أو ذاكرة التخزين المؤقت لخادم API، فاقرأ القوائم الكبيرة في مجموعات.
  • تجنب الإدراج في كثير من الأحيان أكثر من اللازم. إذا لم تتمكن من استخدام Informers، ففكر في عدد المرات التي يسرد فيها تطبيقك الموارد. بعد قراءة العنصر الأخير في قائمة كبيرة، لا تقم على الفور بإعادة الاستعلام عن نفس القائمة. يجب عليك الانتظار قليلا بدلا من ذلك.
  • ضع في اعتبارك عدد مثيلات التشغيل لتطبيق العميل الخاص بك. هناك فرق كبير بين وجود وحدة تحكم واحدة تسرد الكائنات مقابل وجود pods على كل عقدة تفعل الشيء نفسه. إذا كنت تخطط للحصول على مثيلات متعددة من تطبيق العميل الخاص بك تسرد بشكل دوري أعدادا كبيرة من الكائنات، فلن يتم توسيع الحل الخاص بك إلى مجموعات كبيرة.

تقييد واجهة برمجة تطبيقات Azure والنظام الأساسي

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

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

إدارة التقييد في AKS

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

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

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

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

قيود الميزات

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

إشعار

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

  • يدعم Azure Network Policy Manager (Azure npm) ما يصل إلى 250 عقدة فقط.
  • لن يمكن الوصول إلى بعض مقاييس عقدة AKS، بما في ذلك استخدام قرص العقدة، واستخدام وحدة المعالجة المركزية/الذاكرة للعقدة، و/إخراج/دخول الشبكة، في مقاييس النظام الأساسي لمراقبة Azure بعد زيادة مستوى التحكم. لتأكيد ما إذا كان قد تم توسيع مستوى التحكم الخاص بك، ابحث عن configmap "حالة تحجيم مستوى التحكم"
kubectl describe configmap control-plane-scaling-status -n kube-system
  • لا يمكنك استخدام ميزة الإيقاف والبدء مع المجموعات التي تحتوي على أكثر من 100 عقدة. لمزيد من المعلومات، راجع إيقاف نظام مجموعة AKS وبدء تشغيله.

الشبكات

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

  • استخدم NAT المدارة للخروج من نظام المجموعة مع اثنين على الأقل من عناوين IP العامة على بوابة NAT. لمزيد من المعلومات، راجع إنشاء بوابة NAT مدارة لمجموعة AKS الخاصة بك.
  • استخدم تراكب Azure CNI لتوسيع نطاق ما يصل إلى 200000 حاوية و5000 عقدة لكل مجموعة. لمزيد من المعلومات، راجع تكوين شبكات تراكب Azure CNI في AKS.
  • إذا كان التطبيق الخاص بك يحتاج إلى اتصال مباشر من جراب إلى جراب عبر المجموعات، فاستخدم Azure CNI مع تخصيص IP ديناميكي وتوسيع نطاق يصل إلى 50000 حاوية تطبيق لكل مجموعة مع عنوان IP واحد قابل للتوجيه لكل جراب. لمزيد من المعلومات، راجع تكوين شبكة Azure CNI لتخصيص IP الديناميكي في AKS.
  • عند استخدام خدمات Kubernetes الداخلية خلف موازن تحميل داخلي، نوصي بإنشاء موازن تحميل داخلي أو خدمة أقل من مقياس عقدة 750 لأداء التحجيم الأمثل ومرونة موازن التحميل.
  • يدعم Azure npm ما يصل إلى 250 عقدة فقط. إذا كنت ترغب في فرض نهج الشبكة لمجموعات أكبر، ففكر في استخدام Azure CNI الذي يتم تشغيلها بواسطة Cilium، والذي يجمع بين مستوى التحكم القوي ل Azure CNI مع مستوى بيانات Cilium لتوفير شبكة وأمان عاليي الأداء.

تحجيم تجمع العقدة

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

  • بالنسبة لتجمعات عقد النظام، استخدم Standard_D16ds_v5 SKU أو وحدة SKU مكافئة للجهاز الظاهري للذاكرة/الذاكرة مع أقراص نظام التشغيل المؤقتة لتوفير موارد حساب كافية لوحدات kube-system.
  • نظرا لأن AKS لديها حد 1000 عقدة لكل تجمع عقدة، نوصي بإنشاء خمس تجمعات عقد مستخدم على الأقل لتوسيع نطاق يصل إلى 5000 عقدة.
  • عند تشغيل مجموعات AKS على نطاق واسع، استخدم التحجيم التلقائي لنظام المجموعة كلما أمكن ذلك لضمان التحجيم الديناميكي لتجمعات العقد استنادا إلى الطلب على موارد الحوسبة. لمزيد من المعلومات، راجع تغيير حجم نظام مجموعة AKS تلقائيا لتلبية متطلبات التطبيق.
  • إذا كنت تقوم بتحجيم أكثر من 1000 عقدة ولا تستخدم مقياس المجموعة التلقائي، نوصي بالتحجيم على دفعات من 500-700 عقدة في كل مرة. يجب أن يكون لعمليات التحجيم وقت انتظار من دقيقتين إلى خمس دقائق بين عمليات توسيع النطاق لمنع تقييد واجهة برمجة تطبيقات Azure. لمزيد من المعلومات، راجع إدارة واجهة برمجة التطبيقات: نهج التخزين المؤقت والتقييد.

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

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