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

إشعار

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

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

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

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

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

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

إرشادات وضع AKS لأعباء العمل الكبيرة

يدعم AKS وضعين للعناقود:

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

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

مقياس العقد

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

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

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

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

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

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

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

تدعم AKS ثلاث مستويات لتسعير طائرات التحكم كجزء من وحدة التخزين الأساسية: المجاني، القياسي، والمميز. لمزيد من المعلومات، راجع مستويات التسعير المجانية والقياسية والمتميزة لإدارة نظام مجموعة AKS.

هام

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

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

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

للتأكد مما إذا كان مستوى التحكم قد تم تكبيره، ابحث عن Configmap large-cluster-control-plane-scaling-status.

kubectl describe configmap large-cluster-control-plane-scaling-status -n kube-system

اعتبارات غلاف مقياس Kubernetes ومستوى التحكم

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

لا يلغي AKS Automatic الحاجة إلى سلوك العميل الفعال؛ لا تزال المجموعات الكبيرة تحتاج إلى أنماط قائمة على الساعات، وترقيم الرقم، والتراجع، وحركة مرور محدودة من LIST.

عدد الطلبات التي يعالجها خادم API في أي لحظة يتم تحديده بواسطة --max-requests-inflight وعلامات --max-mutating-requests-inflight معينة. يستخدم AKS القيم الافتراضية 400 و200 طلب لهذه الأعلام، مما يسمح بإرسال ما مجموعه 600 طلب في وقت معين. ومع تكبير حجم خادم واجهة برمجة التطبيقات ليصبح أكبر، نزيد أيضا من طلبات الطيران أثناء الرحلة.

نوعان من كائنات كوبيرنيتس، PriorityLevelConfiguration وFlowSchema (APF)، يحددان كيف يقسم خادم API إجمالي سعة الطلبات عبر أنواع الطلبات. يستخدم AKS التكوين الافتراضي.

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

kubectl get --raw /metrics | grep apiserver_flowcontrol_nominal_limit_seats

يقوم FlowSchema بتعيين طلبات خوادم API إلى تكوين مستوى الأولوية. إذا تطابق عدة كائنات FlowSchema طلبا معين، يختار خادم واجهة برمجة التطبيقات الطلبة ذات الأسبقية الأقل مطابقة.

يمكن عرض تعيين FlowSchemas إلى PriorityLevelConfigurations باستخدام هذا الأمر:

kubectl get flowschemas

للتأكد مما إذا كانت أي طلبات تسقط بسبب APF، قم بتشغيل الأمر التالي:

kubectl get --raw /metrics | grep apiserver_flowcontrol_rejected_requests_total

أفضل الممارسات لعملاء Kubernetes

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

  • ضع في اعتبارك عدد الكائنات (CRs) التي تتوقع وجودها في النهاية عند تعريف نوع مورد جديد (CRD).
  • يعتمد الحمل على etcd وخادم API بشكل أساسي على حجم الاستجابة. تنطبق هذه الإرشادات سواء أصدر العميل عددا قليلا من طلبات LIST لكائنات كبيرة أو عددا كبيرا من طلبات LIST لكائنات أصغر.

استخدم المخبرين

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

استخدم ذاكرة التخزين المؤقت لخادم واجهة برمجة التطبيقات

استخدم resourceVersion=0 لإرجاع النتائج من ذاكرة التخزين المؤقت لخادم API. هذا يمكن أن يمنع جلب الأشياء من etcd وبالتالي يقلل من حمل etcd، لكنه لا يدعم الترقيم إلى صفحات الصفحات.

/api/v1/namespaces/default/pods?resourceVersion=0

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

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

/api/v1/namespaces/default/pods?watch=true

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

/api/v1/namespaces/default/pods?watch=true&resourceVersion=<resourceversion>

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

  • القائمة المحسنة:

    /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running

  • القائمة غير المحسنة:

    /api/v1/pods

استخدم الترقيم لتقليل حجم ردود LIST إذا اضطر العميل لجلب البيانات من etcd. المثال التالي يستخدم وسيط الحد لتقييد الاستجابة على 100 كائن.

/api/v1/namespaces/default/pods?fieldSelector=status.phase=Running&limit=100

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

/api/v1/namespaces/default/pods?fieldSelector=status.phase=Running&limit=100&continue=<continue_token>

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

kubectl get pods -n default --chunk-size=100

إذا كان المتحكمون أو المشغلون يستخدمون تحديثات الإيجار لاختيار القائد، تأكد من أنهم مقاومون لمشاكل الاتصال المؤقتة عن طريق ضبط leaseDuration، renewDeadline، وهذه retryPeriod هي الأمثل لأعباء عملك. بالنسبة لوحدات تحكم Kubernetes التي تستخدم اختيار قائد العميل، استخدم الصيغة التالية:

lease_duration > renew_deadline > retry_period

مجموعات الشياطين

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

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

  • استخدم استراتيجية RollingUpdate لطرح مجموعات DaemonSet جديدة تدريجيا. عند تحديث قالب DaemonSet، تستبدل وحدة التحكم الكبسولات القديمة بأخرى جديدة بطريقة محكمة. عندما لا تكون استراتيجية التحديث المدحرجة محددة بشكل صريح، يقوم Kubernetes افتراضيا بإنشاء تحديث RollingUpdate مع maxUnavailable ك 1، maxSurge ك 0، وminReadySeconds ك 0. راجع المثال التالي.

      minReadySeconds: 30
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 1

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

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

      spec:
    template:
      spec:
        containers:
        - name: my-daemonset-container
          image: <image>
          command: ["/bin/sh", "-c", "sleep $(( (RANDOM % 60) + 1 )); exec /path/to/your/app --args"]

إشعار

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

تحسينات etcd

  • حافظ على حجم ال etcd الإجمالي صغيرا ولا تستخدم etcd كقاعدة بيانات عامة الاستخدام. يوفر AKS 8 جيجابايت من تخزين etcd افتراضيا، لكن قواعد بيانات etcd الأكبر تزيد من وقت إزالة التجزئة، مما قد يؤدي إلى مشاكل في أداء القراءة والكتابة. يمكن لقواعد بيانات etcd الأكبر أيضا أن تزيد من احتمال حدوث مشاكل في موثوقية خوادم API وetcd إذا كان العميل غير المحسن يجلب أعدادا كبيرة من الكائنات من etcd بشكل متكرر. إذا تجاوز حجم قاعدة بيانات ETCD 2 جيجابايت، فكر في استخدام تقنيات تقليل حجم الكائنات المذكورة أدناه.
  • لتقليل حجم مواصفات البودات، نقل متغيرات البيئة من مواصفات البودات إلى ConfigMaps.
  • قسم الأسرار الكبيرة أو خرائط التهيئة إلى أجزاء أصغر وأسهل في الإدارة.
  • تخزين الأسرار في Azure Key Vault بدلا من أسرار Kubernetes عندما يكون ذلك ممكنا لتقليل عدد الأسرار المخزنة في etcd.
  • تنظيف الأشياء غير المستخدمة
    • احذف الوظائف القديمة والبودات المكتملة. استخدم ttlSecondsAfterFinished على الوظائف حتى تتم إزالة الأشياء المنتهية تلقائيا.
    • تأكد من أن وحدات التحكم تضبط ownerReferences. هذا يمكن Kubernetes Garbage Collection من إزالة الكائنات التابعة تلقائيا عند حذف المورد الرئيسي.
    • حدد سجل الوظائف في Cron عن طريق تعيين successJobsHistoryLimit و failedJobsHistoryLimit للاحتفاظ بعدد قليل فقط من سجلات الوظائف المكتملة.
    • تقليل تاريخ نشر النشر. يتم تخزين مجموعات النسخ القديمة أيضا ككائنات واجهة برمجة تطبيقات (API). القيمة الافتراضية هي 10.
  • قلل من تاريخ مراجعة هيلم بالحجة --history-max . في المجموعات الكبيرة، حافظ على أقل من 5.

مراقبة مقاييس وسجلات مستوى التحكم في AKS

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

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

يقدم Azure Monitor مقاييس شاملة وسجلات لصحة مستوى التحكم من خلال Azure وبروميثيوس المدار وDiagnostic Settings.

مقاييس منصة مستوى التحكم الرئيسي

يعرض AKS مقاييس المنصة التالية في Azure Monitor لمراقبة صحة خادم API وetcd. هذه المقاييس متاحة دون تفعيل بروميثيوس المدار، ويمكن عرضها مباشرة في بوابة Azure تحت Metrics لمجموعة AKS الخاصة بك.

مقاييس خادم API:

المقيَاس الوصف
apiserver_cpu_usage_percentage الحد الأقصى لنسبة المعالج (بناء على حد التيار) المستخدم من قبل وحدة خادم API عبر النسخ.
apiserver_memory_usage_percentage الحد الأقصى لنسبة الذاكرة (بناء على الحد الحالي) المستخدم من قبل وحدة خادم API عبر النسخ.
apiserver_current_inflight_requests (معاينة) الحد الأقصى لعدد الطلبات النشطة حاليا أثناء الطيران على خادم API، لكل نوع طلب.

مقاييس ETCD:

المقيَاس الوصف
etcd_cpu_usage_percentage الحد الأقصى لنسبة المعالج (بناء على حد التيار) المستخدم في وحدة ETCD عبر المثلات.
etcd_memory_usage_percentage الحد الأقصى لنسبة الذاكرة (بناء على حد التيار) المستخدم من قبل وحدة ETCD عبر المثلات.
etcd_database_usage_percentage أقصى استخدام لقاعدة بيانات etcd عبر المثلات. راقب هذا عن كثب لتجنب تجاوز حد تخزين etcd.

راقب apiserver_cpu_usage_percentage باستمرار وكشف apiserver_memory_usage_percentage ضغط الموارد على خادم واجهة برمجة التطبيقات (API). إذا etcd_database_usage_percentage كان فوق 50%باستمرار، راجع قسم تحسينات Etcd لتقليل حجم قاعدة البيانات. للاطلاع على القائمة الكاملة للمقاييس المتاحة، راجع مرجع بيانات مراقبة AKS.

قيود الميزات

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

  • يدعم AKS توسيع نطاق ما يصل إلى 5000 عقدة بشكل افتراضي لجميع مجموعات المستوى القياسي / LTS. تقوم AKS بتحجيم مستوى التحكم الخاص بمجموعتك في وقت التشغيل استنادا إلى حجم نظام المجموعة واستخدام موارد خادم API. إذا لم تتمكن من التوسع إلى الحد المدعوم، قم بتفعيل مقاييس مستوى التحكم control plane (معاينة) باستخدام الخدمة المدارة Azure Monitor ل Prometheus لمراقبة مستوى التحكم. للمساعدة في حل مشاكل في أداء التوسع أو الموثوقية، راجع الموارد التالية:

    إشعار

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

  • Azure مدير سياسة الشبكة (Azure npm) يدعم فقط حتى 250 عقدة.

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

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

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

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

يبسط AKS Automatic عمليات العنقود، لكن قيود اشتراك Azure وتقييد المنصة لا تزال سارية على نطاق واسع.

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

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

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

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

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

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

الشبكات

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

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

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

  • إذا كنت تستخدم Azure Standard Load Balancer، استخدم على الأقل <عناوين IP العامة الصادرة c0>2. كما تأخذ في اعتبارك حدود قواعد الخلفية لخدمة LoadBalancer عند التخطيط للعناقيد الكبيرة. تدعم موازنات التحميل القياسية Azure حتى 10,000 تكوين IP خلفي لكل عنوان IP للواجهة الأمامية. كل نوع: خدمة LoadBalancer تنشئ قاعدة توازن تحميل واحدة لكل منفذ مكشوف وتربط جميع عقد العنقود بمجموعة الموازنات الخلفية. على سبيل المثال، كشف 5 منافذ لخدمة واحدة سيصل إلى هذا الحد عند 2000 عقدة.

    1 service * 5 ports * 2000 nodes = 10000 backend IP configurations

  • استخدم Azure CNI Overlay لتوسيع ما يصل إلى 200,000 وحدة و5,000 عقدة لكل مجموعة. لمزيد من المعلومات، راجع تكوين شبكة CNI Overlay Azure في AKS.

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

  • عند استخدام خدمات Kubernetes الداخلية خلف موازن تحميل داخلي، نوصي بإنشاء موازن تحميل داخلي أو خدمة أقل من مقياس عقدة 750 لأداء التحجيم الأمثل ومرونة موازن التحميل.

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

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

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

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

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

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

المحتوى ذو الصلة

  • Last updated on