Get best of the week

أفضل ممارسات Kubernetes. تحديد الاستعلامات وحدود الموارد

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

لكل مورد من موارد Kubernetes ، يمكنك تكوين نوعين من المتطلبات - الطلبات والحدود. يصف الأول الحد الأدنى من المتطلبات لتوافر موارد العقدة المجانية اللازمة لتشغيل الحاوية أو الموقد ، والثاني يحد بشكل صارم من الموارد المتاحة للحاوية.

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

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



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



يمكن لكل حاوية في جراب ضبط الاستعلامات والقيود الخاصة بها ، وكلها مضافة. يتم تحديد موارد المعالج بالملليمتر. إذا كانت حاوية الإطلاق تحتاج إلى مركزين كاملين ، فيمكنك تعيين القيمة على 2000 م. إذا كانت الحاوية بحاجة إلى الطاقة فقط 1/4 من القلب ، فإن القيمة هي 250m. ضع في اعتبارك أنه إذا قمت بتعيين قيمة مورد معالج أكبر من عدد النوى للعقدة الأكبر ، فلن يتم التخطيط لإطلاق الموقد على الإطلاق. سيحدث موقف مماثل إذا كان لديك وحدة فرعية تحتاج إلى أربعة نوى ، وتتكون مجموعة Kubernetes من جهازين افتراضيين رئيسيين فقط.

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

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

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



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

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

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

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



دعونا نلقي نظرة على كل منهم. Request.cpu هو الحد الأقصى لعدد طلبات طاقة المعالج المدمجة التي يمكن أن تأتي من جميع حاويات مساحة الاسم. في هذا المثال ، يمكنك الحصول على 50 حاوية بطلبات 10 م لكل منها ، وخمس حاويات بطلبات 100 م أو حاوية واحدة فقط مع طلب 500 م. طالما أن إجمالي عدد الطلبات. cpu لمساحة الاسم هذه أقل من 500 متر ، فسيكون كل شيء على ما يرام.

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

Limits.cpu هي قيمة طاقة المعالج المدمجة القصوى التي يمكن لجميع حاويات مساحة الاسم استخدامها. يمكننا أن نفترض أن هذا هو الحد الأقصى لطلبات طاقة المعالج.

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

يوفر نطاق الحد قيودًا قد:

  • ;
  • Starage Request PersistentVolumeClaim ;
  • Request Limit ;
  • Requests/Limits .

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



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

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

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

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

مرة أخرى ، من المهم ملاحظة أنه إذا تم تعيين هذه القيمة ، فإن القيمة الافتراضية ليست كذلك ، فإن القيمة الدنيا تصبح الاستعلام الافتراضي.

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



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

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



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

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

دعونا نتخيل سيناريو لديك فيه آلة نفدت الذاكرة - كيف ستفعل Kubernetes ذلك؟

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

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

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

أفضل ممارسات Kubernetes. تعطيل الإنهاء الصحيح


القليل من الدعاية :)


أشكركم على البقاء معنا. هل تحب مقالاتنا؟ هل تريد رؤية مواد أكثر إثارة للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية لأصدقائك VPS القائم على السحابة للمطورين من $ 4.99 ، وهو نظير فريد من نوعه لخوادم مستوى الدخول التي اخترعناها لك: الحقيقة الكاملة عن VPS (KVM) E5-2697 v3 (6 نوى) 10GB DDR4 480GB SSD 1Gbps من $ 19 أو كيفية تقسيم الخادم؟ (تتوفر الخيارات مع RAID1 و RAID10 ، حتى 24 مركزًا و 40 جيجابايت DDR4).

Dell R730xd أرخص مرتين في مركز بيانات Equinix Tier IV في أمستردام؟ فقط لدينا 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV من 199 دولارًا في هولندا!Dell R420 - 2x E5-2430 2.2 جيجا هرتز 6C 128 جيجا بايت DDR3 2x960GB SSD 1Gbps 100TB - من 99 دولار! اقرأ عن كيفية بناء مبنى البنية التحتية الفئة c باستخدام خوادم Dell R730xd E5-2650 v4 بتكلفة 9000 يورو مقابل سنت واحد؟

More articles:


All Articles