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

إشعار

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

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

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

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

التحجيم التلقائي للتطبيق مقابل التوسع التلقائي للبنية الأساسية

التحجيم التلقائي للتطبيق

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

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

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

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

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

إشعار

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

التحجيم التلقائي للجراب العمودي

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

تحذير

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

إشعار

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

التحجيم التلقائي للبنية الأساسية

التحجيم التلقائي للكتلة

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

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

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

التوفير الزائد

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

لتحديد المقدار الأمثل من الإفراط في التوفير، يمكنك استخدام الصيغة التالية:

1-buffer/1+traffic

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

1-30%/1+40%=50%

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

يعرض YAML التالي مثالا على بيان الإيقاف المؤقت ل pod:

apiVersion: scheduling.k8s.io/v1 
kind: PriorityClass 
metadata: 
  name: overprovisioning 
value: -1 
globalDefault: false 
description: "Priority class used by overprovisioning." 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: overprovisioning 
  namespace: kube-system 
spec: 
  replicas: 1 
  selector: 
    matchLabels: 
      run: overprovisioning 
  template: 
    metadata: 
      labels: 
        run: overprovisioning 
    spec: 
      priorityClassName: overprovisioning 
      containers: 
      - name: reserve-resources 
        image: your-custome-pause-image 
        resources: 
          requests: 
            cpu: 1 
            memory: 4Gi 

تحجيم العقدة وكفاءتها

إرشادات أفضل الممارسات:

مراقبة استخدام الموارد وجدولتها بعناية لضمان استخدام العقد بكفاءة.

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

صور العقدة

إرشادات أفضل الممارسات:

استخدم أحدث إصدار من صورة العقدة للتأكد من أن لديك أحدث تصحيحات الأمان وإصلاحات الأخطاء.

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

Azure Linux

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

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

Ubuntu 2204

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

يتم دعم صورة Ubuntu 2204 بالكامل من قبل Microsoft وCononical ومجتمع Ubuntu ويمكن أن تساعدك على تحقيق أداء وأمان أفضل لأحمال العمل المعبأة في حاويات.

الأجهزة الظاهرية

إرشادات أفضل الممارسات:

عند تحديد جهاز ظاهري، تأكد من أن حجم وأداء قرص نظام التشغيل وVM SKU ليس لديهم تعارض كبير. يمكن أن يتسبب التناقض في الحجم أو الأداء في حدوث مشكلات في الأداء والتنازع على الموارد.

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

استخدام تجمعات عقد النظام المخصصة

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

عمليات الإنشاء

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

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

خادم واجهة برمجة تطبيقات Kubernetes

عمليات LIST و WATCH

يستخدم Kubernetes عمليات LIST و WATCH للتفاعل مع خادم Kubernetes API ومراقبة المعلومات حول موارد نظام المجموعة. هذه العمليات أساسية لكيفية أداء Kubernetes لإدارة الموارد.

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

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

تقوم عملية WATCH بمراقبة الموارد في الوقت الحقيقي. عند إعداد WATCH على مورد، يرسل لك خادم API التحديثات كلما كانت هناك تغييرات على هذا المورد. هذا مهم لوحدات التحكم، مثل وحدة تحكم ReplicaSet، والتي تعتمد على WATCH للحفاظ على الحالة المطلوبة للموارد.

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

لتجنب المشكلات المحتملة وضمان استقرار وحدة تحكم Kubernetes، يمكنك استخدام الاستراتيجيات التالية:

حصص الموارد النسبية

تنفيذ حصص الموارد النسبية للحد من عدد الموارد التي يمكن سردها أو مراقبتها من قبل مستخدم معين أو مساحة اسم معينة لمنع الاستدعاءات الزائدة.

أولوية واجهة برمجة التطبيقات والإنصاف

قدم Kubernetes مفهوم أولوية API والإنصاف (APF) لتحديد أولويات طلبات واجهة برمجة التطبيقات وإدارتها. يمكنك استخدام APF في Kubernetes لحماية خادم واجهة برمجة تطبيقات نظام المجموعة وتقليل عدد HTTP 429 Too Many Requests الاستجابات التي تراها تطبيقات العميل.

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

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

تحسين التسمية والمحددات

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

في عمليات إنشاء وتحديث Kubernetes، تشير إلى الإجراءات التي تدير موارد نظام المجموعة وتعدلها.

إنشاء وتحديث العمليات

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

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

يمكن أن تؤثر عمليات الإنشاء والتحديث على أداء خادم Kubernetes API في ظل الشروط التالية:

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

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

أداء مستوى البيانات

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

أنواع التخزين

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

إذا كان حمل العمل الخاص بك غير قادر على استخدام أقراص نظام التشغيل سريعة الزوال، فإن AKS افتراضيا لاستخدام أقراص Premium SSD OS. إذا كانت أقراص نظام التشغيل Premium SSD غير متوافقة مع حمل العمل الخاص بك، فإن AKS يتم تعيينها افتراضيا على أقراص SSD القياسية. حاليا، نوع قرص نظام التشغيل الوحيد المتوفر هو Standard HDD. لمزيد من المعلومات، راجع خيارات التخزين في خدمة Azure Kubernetes (AKS).

يوفر الجدول التالي تصنيفا تفصيليا لحالات الاستخدام المقترحة لأقراص نظام التشغيل المدعومة في AKS:

نوع قرص نظام التشغيل	الميزات الرئيسية	حالات الاستخدام المقترحة
أقراص نظام التشغيل الزائل	• إعادة تصوير أسرع وأوقات التمهيد. • زمن انتقال أقل للقراءة/الكتابة على قرص نظام التشغيل لعقد عامل AKS. • الأداء العالي والتوافر.	• تتطلب أحمال عمل المؤسسة، مثل SQL Server وOracle وDynamics وExchange Server وMySQL وCassandra وMongoDB وSAP Business Suite وما إلى ذلك. • أحمال عمل إنتاج عديمة الحالة تتطلب توفرا عاليا وزمن انتقال منخفضا.
أقراص Premium SSD OS	• أداء متناسق وزمن انتقال منخفض. • قابلية وصول عالية.	• تتطلب أحمال عمل المؤسسة، مثل SQL Server وOracle وDynamics وExchange Server وMySQL وCassandra وMongoDB وSAP Business Suite وما إلى ذلك. • أحمال عمل المؤسسات المكثفة للإدخل/الإخراج (IO).
أقراص نظام التشغيل SSD القياسية	• أداء متناسق. • توفر وزمن انتقال أفضل مقارنة بأقراص محركات الأقراص الثابتة القياسية.	• خوادم الويب. • عمليات إدخال/إخراج منخفضة في الثانية (IOPS) خوادم التطبيقات. • تطبيقات المؤسسة المستخدمة بشكل خفيف. • أحمال عمل التطوير/الاختبار.
أقراص محركات الأقراص الثابتة القياسية	• تكلفة منخفضة. • يعرض التغير في الأداء وزمن الانتقال.	• تخزين النسخ الاحتياطي. • مساحة تخزين كبيرة مع وصول غير متكرر.

IOPS ومعدل النقل

تشير عمليات الإدخال/الإخراج في الثانية (IOPS) إلى عدد عمليات القراءة والكتابة التي يمكن للقرص تنفيذها في ثانية. يشير معدل النقل إلى كمية البيانات التي يمكن نقلها في فترة زمنية معينة.

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

يمكنك استخدام الخطوات التالية لمراقبة IOPS وعدادات النطاق الترددي على أقراص نظام التشغيل في مدخل Microsoft Azure:

1. انتقل إلى مدخل Azure.
2. ابحث عن مجموعات مقياس الجهاز الظاهري وحدد مجموعة مقياس الجهاز الظاهري.
3. ضمن Monitoring، حدد Metrics.

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

تم تصميم Azure Premium SSD v2 لأحمال عمل المؤسسة المكثفة من IO التي تتطلب زمن انتقال قرص أقل من مللي ثانية و IOPS عالية ومعدل النقل بتكلفة منخفضة. وهي مناسبة لمجموعة واسعة من أحمال العمل، مثل SQL server وOracle وMariaDB وSAP وCassandra وMongoDB والبيانات الضخمة/التحليلات والألعاب والمزيد. نوع القرص هذا هو الخيار الأعلى أداء المتوفر حاليا لوحدات التخزين الثابتة.

جدولة الجراب

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