ملاحظة perev. : تم نشر هذه المقالة على مدونة Kubernetes الرسمية وكتبها موظفان من Intel مشاركين بشكل مباشر في تطوير CPU Manager ، وهي ميزة جديدة في Kubernetes كتبنا عنها في مراجعة الإصدار 1.8 . في الوقت الحالي (على سبيل المثال ، بالنسبة إلى K8s 1.11) ، تتمتع هذه الميزة بالحالة التجريبية وقراءة المزيد عن الغرض منها لاحقًا في الملاحظة.يتحدث المنشور عن
مدير وحدة المعالجة المركزية ، وهي ميزة بيتا في Kubernetes. يسمح لك مدير وحدة المعالجة المركزية بتوزيع أحمال العمل بشكل أفضل في Kubelet ، أي على وكيل المضيف Kubernetes ، عن طريق تعيين وحدات المعالجة المركزية المخصصة لحاويات موقد معين.
تبدو رائعة! ولكن هل سيساعدني مدير وحدة المعالجة المركزية؟
يعتمد على حجم العمل. يمكن للعقدة الحسابية الوحيدة في مجموعة Kubernetes تشغيل العديد من المداخن ، ويمكن لبعضها تشغيل الأحمال النشطة في استهلاك وحدة المعالجة المركزية. في هذا السيناريو ، يمكن أن تتنافس المداخن على موارد العملية المتاحة على هذه العقدة. عندما تتصاعد هذه المنافسة ، قد يتحول عبء العمل إلى وحدات المعالجة المركزية الأخرى اعتمادًا على ما إذا كان قد تم
اختناقها وتحت أي وحدات المعالجة المركزية كانت متاحة في وقت التخطيط. بالإضافة إلى ذلك ، قد تكون هناك حالات يكون فيها عبء العمل حساسًا لمفاتيح السياق. في كل هذه السيناريوهات ، قد يتأثر أداء عبء العمل.
إذا كان عبء العمل الخاص بك حساسًا لمثل هذه السيناريوهات ، فيمكنك تمكين CPU Manager لتوفير عزل أفضل للأداء من خلال تخصيص وحدات معالجة مركزية محددة للحمل.
يمكن أن يساعد مدير وحدة المعالجة المركزية في عمليات التحميل بالميزات التالية:
- حساس لتأثيرات اختناق وحدة المعالجة المركزية
- حساسة لمفاتيح السياق ؛
- يفتقد ذاكرة التخزين المؤقت للمعالج ؛
- الاستفادة من تقسيم موارد المعالج (على سبيل المثال ، ذاكرة التخزين المؤقت للبيانات والتعليمات) ؛
- ذاكرة حساسة للذاكرة بين مآخذ المعالج (يتم تقديم شرح مفصل لما يدور في ذهن المؤلفين في Unix Stack Exchange - ترجمة تقريبًا. ) ؛
- فرط الحساسية الحساسة أو تتطلب نفس النواة المادية لوحدة المعالجة المركزية.
حسنًا! كيفية استخدامه؟
يعد استخدام CPU Manager أمرًا سهلاً. أولاً ، قم
بتمكينه باستخدام السياسة الثابتة في Kubelet التي تعمل على عقد حساب المجموعة. ثم قم بتكوين فئة
جودة الخدمة المضمونة (QoS) للموقد. اطلب عددًا صحيحًا من نوى وحدة المعالجة المركزية (مثل
1000m أو
4000m ) للحاويات التي تحتاج إلى نوى مخصصة. إنشاء وفقًا للطريقة السابقة (على سبيل المثال ،
kubectl create -f pod.yaml ) ... و voila - سيعين مدير وحدة المعالجة المركزية نوى معالج مخصصة لكل حاوية موقد وفقًا لاحتياجات وحدة المعالجة المركزية الخاصة بهم.
apiVersion: v1 kind: Pod metadata: name: exclusive-2 spec: containers: - image: quay.io/connordoyle/cpuset-visualizer name: exclusive-2 resources: # Pod is in the Guaranteed QoS class because requests == limits requests: # CPU request is an integer cpu: 2 memory: "256M" limits: cpu: 2 memory: "256M"
مواصفات الموقد الذي يطلب معالجين مخصصين.كيف يعمل مدير وحدة المعالجة المركزية؟
نعتبر ثلاثة أنواع من التحكم في موارد وحدة المعالجة المركزية متوفرة في معظم توزيعات Linux ، والتي ستكون ذات صلة بـ Kubernetes وأغراض هذا المنشور. الأولين هما CFS (ما هو حصتي "الصادقة" المرجحة من وقت CPU في النظام) وحصة CFS (ما هو الحد الأقصى لوقت CPU المخصص لي خلال هذه الفترة). يستخدم CPU Manager أيضًا ثالثًا ، والذي يسمى تقارب وحدة المعالجة المركزية (التي يُسمح لي باستخدام وحدات المعالجة المركزية المنطقية لإجراء العمليات الحسابية).
بشكل افتراضي ، يمكن تشغيل جميع القرون والحاويات التي تعمل على عقدة مجموعة Kubernetes على أي نواة نظام متوفرة. العدد الإجمالي للأسهم والحصص المعينة محدود بواسطة موارد وحدة المعالجة المركزية المخصصة لـ
Kubernetes و daemons النظام . ومع ذلك ، يمكن تحديد
حدود وقت وحدة المعالجة المركزية باستخدام
حدود وحدة المعالجة المركزية في مواصفات الموقد . تستخدم Kubernetes
حصة CFS لفرض حدود CPU على حاويات الموقد.
عندما تقوم بتمكين مدير وحدة المعالجة المركزية من خلال سياسة
ثابتة ، فإنه يدير مجموعة مخصصة من وحدات المعالجة المركزية. في البداية ، يحتوي هذا التجمع على وحدة المعالجة المركزية بأكملها لعقدة الحوسبة. عندما تقوم Kubelet بإنشاء حاوية في الموقد مع عدد مضمون من نوى المعالج المخصصة ، يتم تخصيص وحدات المعالجة المركزية المخصصة لهذه الحاوية طوال عمرها وإزالتها من التجمع المشترك. يتم نقل الأحمال من الحاويات المتبقية من هذه النوى المخصصة للآخرين.
تعمل جميع الحاويات التي لا تحتوي على وحدات
معالجة مركزية مخصصة (
Burstable ،
BestEffort ،
ومضمونة مع وحدات معالجة مركزية غير صحيحة ) على نواة تركت في التجمع المشترك. عندما تتوقف حاوية تحتوي على وحدات معالجة مركزية مخصصة عن العمل ، تعود حباتها إلى التجمع المشترك.
مزيد من التفاصيل ، من فضلك ...
يوضح الرسم البياني أعلاه تشريح مدير وحدة المعالجة المركزية. ويستخدم أسلوب
UpdateContainerResources من واجهة وقت تشغيل الحاوية (CRI) لتغيير وحدات المعالجة المركزية التي تعمل عليها الحاويات. يطابق
المدير بشكل دوري
cgroupfs مع الحالة الحالية لموارد وحدة المعالجة المركزية لكل حاوية قيد التشغيل.
يستخدم مدير وحدة المعالجة المركزية
السياسات لاتخاذ قرار بشأن تخصيص نوى وحدة المعالجة المركزية. يتم تطبيق
سياستين : بلا و
Static . افتراضيًا ، بدءًا من Kubernetes الإصدار 1.10 ، يتم تمكينه باستخدام سياسة بلا.
يقوم النهج
الثابت بتعيين حاويات pod المخصصة لوحدة المعالجة المركزية لفئة QoS المضمونة ، والتي تطلب عددًا صحيحًا من النوى. تحاول السياسة
الثابتة تعيين وحدة المعالجة المركزية بأفضل طريقة طوبولوجية وبالترتيب التالي:
- قم بتعيين جميع وحدات المعالجة المركزية (CPU) لمقبس معالج واحد ، إذا كان متاحًا وتتطلب الحاوية وحدة معالجة مركزية (CPU) بحجم مقبس وحدة المعالجة المركزية بالكامل على الأقل.
- قم بتعيين جميع وحدات المعالجة المركزية المنطقية (النتائج الفوقية) الأساسية لوحدة معالجة مركزية فعلية ، إذا كانت متوفرة ، وتتطلب الحاوية وحدة معالجة مركزية على الأقل الأساسية بالكامل.
- قم بتعيين أي وحدات المعالجة المركزية المنطقية المتاحة مع تفضيل لوحدات المعالجة المركزية من مأخذ واحد.
كيف يقوم CPU Manager بتحسين عزل الحساب؟
مع تمكين النهج
الثابت في إدارة وحدة المعالجة المركزية ، يمكن أن تعمل أحمال العمل بشكل أفضل لأحد الأسباب التالية:
- يمكن تخصيص وحدات المعالجة المركزية المخصصة لحاوية مع عبء عمل ، ولكن ليس حاويات أخرى. لا تستخدم هذه الحاويات (الأخرى) نفس موارد وحدة المعالجة المركزية. نتيجة لذلك ، نتوقع أداء أفضل بسبب العزلة في حالات ظهور "المعتدي" (عمليات تتطلب وحدة المعالجة المركزية - ترجمة تقريبًا ) أو عبء العمل المجاور.
- هناك منافسة أقل على الموارد التي يستخدمها عبء العمل ، حيث يمكننا تقسيم وحدة المعالجة المركزية عن طريق عبء العمل نفسه. يمكن أن تتضمن هذه الموارد ليس فقط وحدة المعالجة المركزية ، ولكن أيضًا التسلسلات الهرمية لذاكرة التخزين المؤقت وعرض النطاق الترددي للذاكرة. هذا يحسن أداء عبء العمل العام.
- يعين مدير وحدة المعالجة المركزية وحدة المعالجة المركزية بترتيب طوبولوجي بناءً على أفضل الخيارات المتاحة. إذا كان المقبس بأكمله مجانيًا ، فسيخصص جميع وحدات المعالجة المركزية الخاصة به لحمل العمل. هذا يحسن أداء عبء العمل بسبب نقص حركة المرور بين مآخذ.
- تخضع الحاويات في القرون المزودة بجودة ضمان مضمونة لحدود CFS المخصصة. يمكن تخطيط أعباء العمل المعرضة للانفجارات المفاجئة وتتجاوز حصتها قبل نهاية الفترة المخصصة لها ، ونتيجة لذلك يتم خنقها . يمكن أن يكون لوحدات المعالجة المركزية المعنية في هذا الوقت عمل كبير وغير مفيد للغاية. ومع ذلك ، لن تخضع هذه الحاويات إلى اختناق CFS عندما تكون وحدة المعالجة المركزية للحصة النسبية مدعومة بسياسة تخصيص مخصصة لوحدة المعالجة المركزية.
حسنًا! هل لديك اي نتائج؟
لرؤية تحسينات الأداء والعزلة التي يوفرها تضمين مدير وحدة المعالجة المركزية في Kubelet ، أجرينا تجارب على عقدة حاسوبية مزودة بمقبسين (Intel Xeon CPU E5-2680 v3) وتم تمكين المعالجة الزائدة. تتكون العقدة من 48 وحدة معالجة مركزية منطقية (24 نواة فيزيائية ، لكل منها فرط ترابط). يوضح أدناه أداء وحدة إدارة وحدة المعالجة المركزية (CPU) وعزلتها التي تم التقاطها من خلال أعباء العمل القياسية والحقيقية في ثلاثة سيناريوهات مختلفة.
كيف تفسر الرسوم البيانية؟
لكل سيناريو ، يتم عرض الرسوم البيانية (
الرسوم البيانية الممتدة ،
المخططات الصندوقية) التي توضح وقت التنفيذ المعياري وتنوعه عند بدء تشغيل معيار أو تحميل حقيقي مع تشغيل وإيقاف إدارة وحدة المعالجة المركزية. يتم ضبط وقت التشغيل وفقًا لعمليات الإطلاق الأفضل أداءً (يمثل 1.00 على المحور ص أفضل وقت بدء: كلما انخفضت قيمة الرسم البياني ، كان ذلك أفضل). يوضح ارتفاع الرسم البياني على الرسم البياني التباين في الأداء. على سبيل المثال ، إذا كان الموقع عبارة عن خط ، فلا يوجد اختلاف في الأداء لعمليات الإطلاق هذه. في هذه المناطق نفسها ، يكون الخط الأوسط هو المتوسط ، والأعلى هو المئين 75 ، والقاع هو المئين 25. يتم تعريف ارتفاع المؤامرة (أي الفرق بين المئين 75 و 25) على أنه النطاق الربعي (IQR). يعرض "Moustache" البيانات خارج هذا الفاصل الزمني ، وتظهر النقاط القيم المتطرفة. يتم تعريف الانبعاثات على أنها أية بيانات تختلف عن معدل الذكاء بمعدل 1.5 مرة - أقل أو أكثر من الربع المقابل. تم تنفيذ كل تجربة 10 مرات.
الحماية العدوانية
أطلقنا ستة معايير معيارية من
مجموعة PARSEC (أعباء العمل - "الضحايا")
[يمكن قراءة المزيد عن أعباء عمل الضحايا ، على سبيل المثال ، هنا - تقريبًا. perev. ] بجوار الحاوية التي تقوم بتحميل وحدة المعالجة المركزية (حمل العمل "المعتدي") مع تشغيل وإيقاف إدارة وحدة المعالجة المركزية.
يتم إطلاق الحاوية المعتدية كما هو
الحال مع فئة
Burstable QoS التي تطلب علامة CPU 23 -
--cpus 48 . يتم تشغيل
مقاييس الأداء على
شكل لوحات مع فئة
ضمان جودة الخدمة ، والتي تتطلب مجموعة من وحدات المعالجة المركزية من مقبس كامل (أي 24 وحدة معالجة مركزية على هذا النظام). تظهر الرسوم البيانية أدناه وقت بدء pod المعياري مع معيار بجوار المعتدي pod ، مع سياسة CPU Manager
الثابتة وبدونه. في جميع حالات الاختبار ، يمكنك مشاهدة الأداء المحسّن وتقلب الأداء المنخفض مع تمكين السياسة.
عزل الأحمال المجاورة
يوضح هذا مدى فائدة إدارة وحدة المعالجة المركزية للعديد من أعباء العمل في نفس الموقع. توضح الرسوم البيانية الممتدة أدناه أداء معيارين من مجموعة
PARSEC (
Blackscholes and
Canneal ) التي تم إطلاقها لفئات QoS
المضمونة (Gu) و
Burstable (Bu) QoS المتجاورتين ، مع تشغيل وإيقاف السياسة
الثابتة .
بعد اتجاه عقارب الساعة من الرسم البياني الأيسر العلوي ، نرى أداء
Blackscholes لـ Bu QoS (أعلى اليسار) ،
Canneal لـ Bu QoS (أعلى اليمين) ،
Canneal لـ Gu QoS (أسفل اليمين) و
Blackscholes لـ Gu QoS (أسفل اليسار). في كل رسم بياني ، توجد (في اتجاه عقارب الساعة مرة أخرى) جنبًا إلى جنب مع
Canneal لـ Gu QoS (أعلى اليسار) ،
Blackscholes for Gu QoS (أعلى اليمين) ،
Blackscholes for Bu QoS (أسفل اليمين) و
Canneal لـ Bu QoS (أسفل اليسار) وفقًا لذلك. على سبيل المثال ،
يُظهر الرسم البياني Bu-blackscholes-Gu-canneal (أعلى اليسار) أداءً لـ
Blackscholes يعمل مع Bu QoS ويقع بجوار
Canneal مع فئة Gu QoS. في كل حالة ، تحت فئة Gu QoS يتطلب نواة مأخذ كاملة (أي 24 وحدة معالجة مركزية) ، وتحت فئة بو QoS - 23 وحدة معالجة مركزية.
هناك أداء أفضل واختلاف أقل في الأداء لكل من أعباء العمل المجاورة في جميع الاختبارات. على سبيل المثال ، انظر إلى
Bu-blackscholes-Gu-canneal (أعلى اليسار) و
Gu-canneal-Bu-blackscholes (أسفل اليمين). أنها تظهر أداء كل من تشغيل
Blackscholes و
Canneal مع تشغيل
وإيقاف إدارة وحدة المعالجة المركزية. في هذه الحالة ، يتلقى
Canneal مراكز أكثر
تخصيصًا من CPU Manager ، نظرًا لأنه ينتمي إلى فئة Gu QoS ويطلب عددًا صحيحًا من مراكز CPU. ومع ذلك ، يحصل
Blackscholes أيضًا على مجموعة مخصصة من وحدات المعالجة المركزية ، لأن هذا هو عبء العمل الوحيد في التجمع المشترك. نتيجة لذلك ،
يستفيد كل من
Blackscholes و
Canneal من عزل الحمل عند استخدام CPU Manager.
عزل الأحمال المستقلة
يوضح مدى فائدة إدارة وحدة المعالجة المركزية لأحمال العمل المستقلة من الحياة الواقعية. أخذنا حمولتين من
موديلات TensorFlow الرسمية :
واسعة وعميقة و
ResNet . يتم استخدام مجموعات البيانات النموذجية لهم (التعداد و CIFAR10 ، على التوالي). في كلتا الحالتين ، تتطلب
المداخن (
واسعة وعميقة ،
ResNet ) 24 وحدة معالجة مركزية ، والتي تتوافق مع مقبس كامل. كما هو موضح في الرسوم البيانية ، يوفر مدير وحدة المعالجة المركزية في كلتا الحالتين عزلًا أفضل.
القيود
قد يرغب المستخدمون في الحصول على وحدات المعالجة المركزية المخصصة على مقبس قريب من الناقل الذي يتصل بجهاز خارجي مثل المسرِّع أو بطاقة الشبكة عالية الأداء لتجنب حركة المرور بين المقابس. هذا النوع من التكوين غير معتمد حتى الآن في إدارة وحدة المعالجة المركزية. نظرًا لأن مدير وحدة المعالجة المركزية يوفر أفضل تخصيص ممكن لوحدات المعالجة المركزية التي تنتمي إلى مقبس أو قلب مادي ، فإنه حساس للحالات الشديدة ويمكن أن يؤدي إلى التجزئة. لا يأخذ مدير وحدة المعالجة المركزية في الاعتبار معلمة التمهيد في
isolcpus Linux kernel ، على الرغم من استخدامه كممارسة شائعة في بعض الحالات
(لمزيد من التفاصيل حول هذه المعلمة ، انظر ، على سبيل المثال ، هنا - تقريبًا الترجمة. ) .
ملاحظة من المترجم
اقرأ أيضا في مدونتنا: