القياس التلقائي وإدارة الموارد في Kubernetes (نظرة عامة وتقرير فيديو)

27 أبريل في المؤتمر سترايك 2019، ضمن قسم "DevOps" ، تم إعداد تقرير "القياس التلقائي وإدارة الموارد في Kubernetes". يشرح كيفية استخدام K8s لضمان التوافر العالي للتطبيقات وضمان أقصى أداء لها.

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

دعنا نحلل موضوع التقرير بالكلمات ونبدأ من النهاية.

Kubernetes

لنفترض أن لدينا حاويات Docker على المضيف. لماذا؟ لضمان التكرار والعزل ، والذي بدوره يسمح لك بإجراء نشر بسيط وجيد ، CI / CD. لدينا الكثير من هذه الشاحنات ذات الحاويات.

ما الذي يعطي Kubernetes في هذه الحالة؟

1. نتوقف عن التفكير في هذه الأجهزة ونبدأ العمل مع "السحاب" مجموعة من الحاويات أو القرون (مجموعات الحاويات).
2. علاوة على ذلك ، نحن لا نفكر حتى في القرون الفردية ، ولكننا ندير أكثرоمجموعات أكبر. هذه الأوليات عالية المستوى اسمح لنا أن نقول إن هناك نمطًا لتشغيل حمل عمل معين ، ولكن العدد الصحيح من المثيلات لتشغيله. إذا قمنا بتغيير القالب لاحقًا ، فستتغير جميع الحالات أيضًا.
3. استخدام API التعريفي بدلاً من تنفيذ سلسلة من الأوامر المحددة ، نصف "جهاز العالم" (في YAML) الذي تم إنشاؤه بواسطة Kubernetes. ومرة أخرى: عندما يتغير الوصف ، سيتغير عرضه الفعلي أيضًا.

إدارة الموارد

وحدة المعالجة المركزية‏:

لنقم بتشغيل nginx و php-fpm و mysql على الخادم. ستشتمل هذه الخدمات في الواقع على عمليات تشغيل أكثر ، تتطلب كل منها موارد الحوسبة:

(الأرقام الموجودة على الشريحة هي "ببغاوات" ، وهي الحاجة المجردة لكل عملية من أجل قوة الحوسبة)

لكي تكون قادرًا على العمل مع هذا بشكل ملائم ، فمن المنطقي دمج العمليات في مجموعات (على سبيل المثال ، كل عمليات nginx في مجموعة "nginx" واحدة). هناك طريقة بسيطة وواضحة للقيام بذلك وهي وضع كل مجموعة في وعاء:

للمتابعة ، عليك أن تتذكر ماهية الحاوية (في Linux). أصبح مظهرهم ممكنًا بفضل ثلاث ميزات رئيسية في النواة تم تنفيذها لفترة طويلة: قدرات, النطاقات и مجموعات cgroups. وقد ساهمت التقنيات الأخرى في مزيد من التطوير (بما في ذلك "القذائف" الملائمة مثل Docker):

في سياق التقرير ، نحن مهتمون فقط مجموعات cgroups، لأن مجموعات التحكم هي جزء من وظيفة الحاويات (Docker ، إلخ) التي تنفذ إدارة الموارد. العمليات مجتمعة في مجموعات ، كما أردنا ، هي مجموعات التحكم.

دعنا نعود إلى احتياجات وحدة المعالجة المركزية لهذه العمليات ، والآن لمجموعات العمليات:

(أكرر أن جميع الأرقام هي تعبير تجريدي عن الحاجة إلى الموارد)

في الوقت نفسه ، تمتلك وحدة المعالجة المركزية نفسها موردًا محدودًا معينًا (في المثال 1000)والتي قد يفتقر إليها الجميع (مجموع احتياجات كل المجموعات 150 + 850 + 460 = 1460). ماذا سيحدث في هذه الحالة؟

تبدأ النواة في توزيع الموارد وتقوم بذلك "بشكل عادل" ، مع إعطاء نفس القدر من الموارد لكل مجموعة. لكن في الحالة الأولى ، هناك أكثر من المطلوب (333> 150) ، لذلك يبقى الفائض (333-150 = 183) في الاحتياطي ، والذي يتم توزيعه أيضًا بالتساوي بين الحاويات الأخرى:

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

لنلق نظرة على حالة نقص الموارد في الحاوية الثانية (php-fpm). يتم توزيع جميع موارد الحاويات بالتساوي بين العمليات. نتيجة لذلك ، تعمل العملية الرئيسية بشكل جيد ، ويتباطأ جميع العمال ، حيث حصلوا على أقل من نصف ما يحتاجون إليه:

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

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

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

دعنا نعود إلى Linux kernel وتفاعله مع وحدة المعالجة المركزية - الصورة العامة كما يلي:

تحتوي مجموعة cgroup على إعدادين - في الواقع ، هذان نوعان من "التقلبات" البسيطة التي تسمح لك بتحديد:

1. الوزن للحاوية (الطلبات) هو الأسهم;
2. النسبة المئوية لإجمالي الوقت الذي تستغرقه وحدة المعالجة المركزية في العمل على مهام الحاوية (الحدود) هو حصة.

كيف تقيس وحدة المعالجة المركزية؟

هناك طرق مختلفة:

1. ما هو الببغاوات، لا أحد يعلم - تحتاج إلى التفاوض في كل مرة.
2. فائدة أكثر وضوحًا ، لكن نسبيًا: 50٪ من الخادم الذي يحتوي على 4 مراكز و 20 مركزًا هي أشياء مختلفة تمامًا.
3. يمكنك استخدام ما سبق ذكره الوزنالتي يعرفها Linux ، لكنها أيضًا نسبية.
4. الخيار الأنسب هو قياس موارد الحوسبة بتنسيق ثواني. أولئك. في ثوانٍ من وقت المعالج بالنسبة إلى ثوانٍ من الوقت الفعلي: لقد أعطوا ثانية واحدة من وقت المعالج في ثانية واحدة حقيقية - هذا هو نواة واحدة كاملة لوحدة المعالجة المركزية.

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

ضع في اعتبارك مثال خادم بسيط يحتوي على 3 مراكز وحدة معالجة مركزية ، حيث سيتم إعطاء ثلاثة قرون أوزان (500 و 1000 و 1500) يمكن تحويلها بسهولة إلى الأجزاء الخاصة بها من النوى المخصصة (0,5 و 1 و 1,5).

إذا أخذنا الخادم الثاني ، حيث سيكون هناك ضعف عدد النوى (6) ، ووضعنا نفس البودات هناك ، فيمكن بسهولة حساب توزيع النوى عن طريق الضرب ببساطة في 2 (1 ، 2 و 3 ، على التوالي). ولكن تحدث لحظة مهمة عندما يظهر الكبسولة الرابعة على هذا الخادم ، حيث سيكون وزنها ، للراحة ، 3000. إنها تأخذ بعض موارد وحدة المعالجة المركزية (نصف النوى) ، ويتم إعادة حسابها من بقية الكبسولات (نصف):

Kubernetes وموارد وحدة المعالجة المركزية

في Kubernetes ، يتم قياس موارد وحدة المعالجة المركزية عادةً بـ ميلدراخ، أي. 0,001 حبة تؤخذ كوزن أساسي. (يسمى نفس الشيء مشاركة وحدة المعالجة المركزية في مصطلحات Linux / cgroups ، على الرغم من أن أكثر من ذلك ، 1000 ميليكور = 1024 مشاركة وحدة المعالجة المركزية.) تتأكد K8s من عدم وضع المزيد من البودات على الخادم أكثر من موارد وحدة المعالجة المركزية لمجموع أوزان جميع الكبسولات.

كيف يحدث هذا؟ عند إضافة خادم إلى مجموعة Kubernetes ، فإنه يُبلغ عن عدد نوى وحدة المعالجة المركزية المتوفرة لديه. وعندما يتم إنشاء حجرة جديدة ، يعرف برنامج جدولة Kubernetes عدد النوى التي ستحتاجها هذه الكبسولة. وبالتالي ، سيتم تحديد الكبسولة على الخادم ، حيث يوجد عدد كافٍ من النوى.

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

يمكن أن تحتوي الحجرة على كلا من الطلبات (جدولة CFS) والحدود (تذكر إشارة المرور؟):

• إذا كانت متساوية ، يتم تعيين فئة QoS للجراب مضمون. هذا العدد من النوى المتاح دائمًا له مضمون.
• إذا كان الطلب أقل من الحد - فئة QoS قابل للانفجار. أولئك. نتوقع أن يستخدم الكبسولة ، على سبيل المثال ، نواة واحدة دائمًا ، لكن هذه القيمة ليست حدًا لها: أحيانا يمكن استخدام pod أكثر (عندما يكون لدى الخادم موارد مجانية لهذا الغرض).
• هناك أيضًا فئة QoS أفضل جهد - يشمل الكبسولات التي لم يتم تحديد طلب لها. يتم إعطاء الموارد لهم أخيرًا.

ذاكرة

مع الذاكرة ، يكون الوضع مشابهًا ، لكنه مختلف قليلاً - بعد كل شيء ، طبيعة هذه الموارد مختلفة. بشكل عام ، يكون القياس على النحو التالي:

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

هذا لا يناسبنا دائمًا ، لذلك من الممكن تنظيم العمليات المهمة بالنسبة لنا والتي لا ينبغي قتلها. للقيام بذلك ، استخدم المعلمة oom_score_adj.

دعنا نعود إلى فئات CPU QoS ونرسم تشابهًا مع قيم oom_score_adj التي تحدد أولويات استهلاك الذاكرة للقرون:

• أقل قيمة لـ oom_score_adj للحجرة هي -998 ، مما يعني أنه يجب قتل مثل هذا الكبسولة في آخر منعطف ، هذا مضمون.
• أعلى - 1000 - هو أفضل جهد، يتم قتل هذه القرون أولاً.
• لحساب القيم المتبقية (قابل للانفجار) هناك معادلة ، جوهرها أنه كلما زادت الموارد التي يطلبها الكبسولة ، قل احتمال تعرضها للقتل.

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

في المجموع

يتم إعطاء كل كبسولة في Kubernetes requests и limits - كلا المعلمتين لوحدة المعالجة المركزية والذاكرة:

1. بناءً على الطلبات ، يعمل برنامج جدولة Kubernetes ، الذي يوزع الكبسولات بين الخوادم ؛
2. بناءً على جميع المعلمات ، يتم تحديد فئة QoS للجراب ؛
3. يتم حساب الأوزان النسبية بناءً على طلبات وحدة المعالجة المركزية ؛
4. بناءً على طلبات وحدة المعالجة المركزية ، تم تكوين جدولة CFS ؛
5. تم تكوين OOM killer بناءً على طلبات الذاكرة ؛
6. تم تكوين "إشارة المرور" بناءً على حدود وحدة المعالجة المركزية ؛
7. على أساس حدود الذاكرة يتم ضبط الحد على cgroup'u.

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

قياس ذاتي

جهاز قياس الكتلة التلقائي K8s

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

هذا هو القياس التلقائي لمجموعة Kubernetes ، والذي يعمل بشكل رائع (في تجربتنا). ومع ذلك ، كما هو الحال في أي مكان آخر ، هناك بعض الفروق الدقيقة هنا ...

بينما قمنا بزيادة أحجام الكتلة ، كان كل شيء على ما يرام ، ولكن ماذا يحدث عند الكتلة بدأ الإفراج عنه؟ تكمن المشكلة في أن ترحيل البودات (إلى مضيفين مجانيين) أمر صعب للغاية من الناحية الفنية ومكلفًا من حيث الموارد. لدى Kubernetes نهجًا مختلفًا تمامًا.

ضع في اعتبارك مجموعة من 3 خوادم تحتوي على نشر. لديه 6 قرون: الآن 2 لكل خادم. لسبب ما ، أردنا إغلاق أحد الخوادم. للقيام بذلك ، نستخدم الأمر kubectl drain، أيّ:

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

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

ومع ذلك ، هناك فارق بسيط هنا أيضًا. في حالة مماثلة ، بالنسبة لـ StatefulSet (بدلاً من النشر) ، ستكون الإجراءات مختلفة. الآن لدينا بالفعل تطبيق ذو حالة - على سبيل المثال ، ثلاث مجموعات مع MongoDB ، واحدة منها بها مشكلة ما (تلف البيانات أو خطأ آخر منع الكبسولة من البدء بشكل صحيح). وقررنا مرة أخرى إغلاق خادم واحد. ماذا سيحدث؟

MongoDB استطاع يموت لأنه يحتاج إلى نصاب قانوني: بالنسبة لمجموعة من ثلاث منشآت ، يجب تشغيل اثنتين على الأقل. ومع ذلك، هذا لا يحدث - شكرا ل PodDisruptionBudget. تحدد هذه المعلمة الحد الأدنى المطلوب لعدد البودات قيد التشغيل. مع العلم أن إحدى وحدات MongoDB لم تعد تعمل ، ورؤية أن MongoDB بها PodDisruptionBudget مضبوطة على minAvailable: 2، لن يسمح لك Kubernetes بحذف الكبسولة.

خلاصة القول: لكي تعمل حركة (وفي الواقع ، إعادة إنشاء) البودات بشكل صحيح عند تحرير الكتلة ، تحتاج إلى تكوين PodDisruptionBudget.

التحجيم الأفقي

لنفكر في موقف آخر. يوجد تطبيق يعمل كـ Deployment في Kubernetes. تأتي حركة مرور المستخدم إلى أجهزتها (على سبيل المثال ، هناك ثلاثة منها) ، ونقيس مؤشرًا معينًا فيها (على سبيل المثال ، الحمل على وحدة المعالجة المركزية). عندما يزداد الحمل ، نقوم بإصلاحه وفقًا للجدول الزمني ونزيد عدد الكبسولات لتوزيع الطلبات.

اليوم ، في Kubernetes ، لا يلزم القيام بذلك يدويًا: يتم تكوين الزيادة / النقص التلقائي في عدد الكبسولات اعتمادًا على قيم مؤشرات الحمل المقاسة.

الأسئلة الرئيسية هنا ماذا تقيس и كيف تفسر القيم المستلمة (لاتخاذ قرار بشأن تغيير عدد الكبسولات). يمكن قياس الكثير من الأشياء.

كيفية القيام بذلك تقنيًا - جمع المقاييس ، إلخ. - تحدثت بالتفصيل في التقرير عن المراقبة و Kubernetes. والنصيحة الرئيسية لاختيار المعلمات المثلى هي تجربة!

هنالك طريقة الاستخدام (استخدام التشبع والأخطاء) ، ومعنى ذلك على النحو التالي. بناءً على ما هو منطقي للقياس ، على سبيل المثال ، php-fpm؟ بناءً على حقيقة أن العمال ينفدون ، هذا هو استخدام. وإذا انتهى العمال ولم يتم قبول الاتصالات الجديدة ، فهذا بالفعل التشبع. يجب قياس كل من هذه المعلمات ، واعتمادًا على القيم ، يجب إجراء القياس.

بدلا من خاتمة

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

مقاطع الفيديو والشرائح

فيديو من العرض (44 دقيقة):

عرض التقرير:

PS

تقارير أخرى حول Kubernetes في مدونتنا:

• «تمديد واستكمال Kubernetes» (أندري بولوفوف ؛ 8 أبريل 2019 في Saint HighLoad ++);
• «قواعد البيانات و Kubernetes» (ديمتري ستولياروف ؛ 8 نوفمبر 2018 على HighLoad ++);
• «المراقبة و Kubernetes» (ديمتري ستولياروف ؛ 28 مايو 2018 في RootConf);
• «أفضل ممارسات CI / CD مع Kubernetes و GitLab» (ديمتري ستولياروف ؛ 7 نوفمبر 2017 على HighLoad ++);
• «تجربتنا مع Kubernetes في المشاريع الصغيرة» (ديمتري ستولياروف ؛ 6 يونيو 2017 في RootConf).

المصدر: www.habr.com