لكل مورد Kubernetes ، من الممكن تكوين نوعين من المتطلبات - الطلبات والحدود. يصف الأول الحد الأدنى لمتطلبات موارد العقدة المجانية المطلوبة لتشغيل حاوية أو جراب ، والثاني يحد بشدة من الموارد المتاحة للحاوية.
عندما تخطط Kubernetes للقرون ، من المهم جدًا أن تحتوي الحاويات على موارد كافية للتشغيل بشكل طبيعي. إذا كنت تخطط لنشر تطبيق كبير على مضيف محدود الموارد ، فمن المحتمل ألا يتم تشغيله بسبب نفاد ذاكرة المضيف أو نفاد طاقة المعالج. في هذه المقالة ، سننظر في كيفية حل مشاكل نقص قوة الحوسبة باستخدام طلبات الموارد والقيود.
الطلبات والحدود هي آليات تستخدمها Kubernetes لإدارة الموارد مثل وحدة المعالجة المركزية والذاكرة. الطلبات هي ما يضمن حصول الحاوية على المورد المطلوب. إذا طلبت الحاوية موردًا ، فسيقوم Kubernetes بجدولته فقط على عقدة يمكنها توفيره. تتحكم الحدود في أن الموارد المطلوبة بواسطة الحاوية لا تتجاوز أبدًا قيمة معينة.
يمكن للحاوية فقط زيادة قوة الحوسبة إلى حد معين ، وبعد ذلك سيتم تقييدها. دعونا نرى كيف يعمل. لذلك ، هناك نوعان من الموارد - المعالج والذاكرة. يستخدم برنامج جدولة Kubernetes هذه الموارد لمعرفة مكان تشغيل البودات الخاصة بك. تبدو مواصفات المورد النموذجية لحجرة ما هكذا.
يمكن لكل حاوية في الكبسولة تعيين طلباتها وحدودها ، وكلها مواد مضافة. يتم تحديد موارد المعالج بالملليكورات. إذا احتاجت الحاوية الخاصة بك إلى قلبين كاملين للتشغيل ، فقم بتعيين القيمة على 2000 متر. إذا كانت الحاوية تحتاج فقط إلى 1/4 طاقة أساسية ، فستكون القيمة 250 مترًا. اعلم أنه إذا قمت بتعيين قيمة مورد وحدة المعالجة المركزية أكبر من عدد النوى لأكبر عقدة ، فلن تتم جدولة البود الخاص بك للبدء على الإطلاق. سيحدث موقف مماثل إذا كان لديك جراب يحتاج إلى أربعة مراكز ، وتتكون مجموعة Kubernetes من جهازين افتراضيين رئيسيين فقط.
ما لم يكن التطبيق الخاص بك مصممًا خصيصًا للاستفادة من مراكز متعددة (وبالتالي تتبادر إلى الذهن برامج مثل الحسابات العلمية المعقدة وعمليات قواعد البيانات) ، فإن أفضل ممارسة هي تعيين طلبات وحدة المعالجة المركزية إلى 1 أو أقل ثم تشغيل المزيد من النسخ المتماثلة على قابلية التوسع. سيعطي هذا الحل النظام مرونة وموثوقية أكبر.
عندما يتعلق الأمر بحدود وحدة المعالجة المركزية ، تصبح الأمور أكثر إثارة للاهتمام لأنها تعتبر موردًا قابلًا للضغط. إذا بدأ تطبيقك في الاقتراب من حد وحدة المعالجة المركزية (CPU) ، فسيبدأ Kubernetes في تقييد الحاوية الخاصة بك باستخدام Throttling CPU. هذا يعني أن المعالج سيكون محدودًا بشكل مصطنع ، مما يجعل أداء التطبيق أسوأ ، ولكن لن يتم إنهاء العملية أو تقديمها.
يتم تحديد موارد الذاكرة بالبايت. عادةً ما تُقاس القيمة في الإعدادات بـ Mib mebibytes ، ولكن يمكنك ضبطها على أي قيمة ، من بايت إلى بيتابايت. الوضع هنا هو نفسه كما هو الحال مع وحدة المعالجة المركزية - إذا قمت بتقديم طلب لمقدار من الذاكرة يتجاوز حجم الذاكرة على العقد الخاصة بك ، فلن تتم جدولة تنفيذ هذا الكبسولة. ولكن بخلاف موارد وحدة المعالجة المركزية ، لا يتم ضغط الذاكرة لأنه لا توجد طريقة للحد من استخدامها. لذلك ، سيتم إيقاف تشغيل الحاوية بمجرد نفاد الذاكرة المخصصة لها.
من المهم أن تتذكر أنه لا يمكنك تكوين الطلبات التي تتجاوز كمية الموارد التي يمكن أن توفرها العقد الخاصة بك. يمكن العثور على مواصفات المشاركة لأجهزة GKE VM في الروابط الموجودة أسفل هذا الفيديو.
في عالم مثالي ، ستكون إعدادات الحاوية الافتراضية كافية للحفاظ على سير العمل بسلاسة. لكن العالم الحقيقي ليس كذلك ، يمكن للناس بسهولة أن ينسوا تعديل استخدام الموارد ، أو سيضع المتسللون الطلبات والحدود التي تتجاوز القدرات الفعلية للبنية التحتية. لمنع مثل هذه السيناريوهات ، يمكنك تكوين حصص موارد ResourceQuota ونطاقات LimitRange.
بمجرد إنشاء مساحة الاسم ، يمكن قفلها باستخدام الحصص. على سبيل المثال ، إذا كان لديك مساحات اسمي prod و dev ، فإن النمط هو أنه لا توجد حصص إنتاج على الإطلاق ، وحصص التطوير صارمة للغاية. يتيح ذلك لـ prod أخذ كل الموارد المتاحة في حالة حدوث زيادة حادة في حركة المرور ، مما يؤدي إلى حظر التطوير تمامًا.
قد تبدو حصة الموارد مثل هذا. في هذا المثال ، هناك 4 أقسام - هذه هي الأسطر الأربعة النهائية للشفرة.
دعونا نلقي نظرة على كل منهم. Orders.cpu هو الحد الأقصى لعدد الطلبات المجمعة لطاقة وحدة المعالجة المركزية التي يمكن أن تأتي من جميع حاويات مساحة الاسم. في هذا المثال ، يمكن أن يكون لديك 50 حاوية بها 10 ملايين طلب ، أو خمس حاويات بها 100 مليون طلب ، أو حاوية واحدة فقط بها 500 مليون طلب. طالما أن العدد الإجمالي لطلبات وحدة المعالجة المركزية لمساحة اسم معينة أقل من 500 متر ، فسيكون كل شيء على ما يرام.
تعد طلبات الذاكرة المطلوبة للذاكرة هي الحد الأقصى لمقدار طلبات الذاكرة المجمعة التي يمكن أن تحتويها جميع الحاويات في مساحة الاسم. كما في الحالة السابقة ، يمكن أن يكون لديك 50 حاوية 2 mib ، أو 20 حاويات mib 100 ، أو حاوية واحدة بحجم 100 mib طالما أن الحجم الإجمالي للذاكرة المطلوبة في مساحة الاسم أقل من XNUMX ميبي بايت.
Limits.cpu هو أقصى قدر مشترك من طاقة المعالج يمكن أن تستخدمه جميع حاويات مساحة الاسم. يمكننا أن نفترض أن هذا هو الحد الأقصى لطلبات طاقة المعالج.
أخيرًا ، limits.memory هي الحد الأقصى لمقدار الذاكرة المشتركة التي يمكن لجميع الحاويات في مساحة الاسم استخدامها. هذا هو الحد الأقصى لطلبات الذاكرة الإجمالية.
لذلك ، بشكل افتراضي ، تعمل الحاويات في مجموعة Kubernetes بموارد حوسبة غير محدودة. باستخدام حصص الموارد ، يمكن لمسؤولي الكتلة الحد من استهلاك الموارد وإنشاء الموارد بناءً على مساحة الاسم. في مساحة الاسم ، يمكن أن يستهلك البود أو الحاوية قدرًا كبيرًا من وحدة المعالجة المركزية وطاقة الذاكرة كما هو محدد بواسطة الحصة النسبية لمورد مساحة الاسم. ومع ذلك ، هناك قلق من أن جرابًا أو حاوية واحدة يمكن أن تحتكر جميع الموارد المتاحة. لمنع هذا الموقف ، يتم استخدام نطاق الحد - سياسة الحد من تخصيص الموارد (للقرون أو الحاويات) في مساحة الاسم.
يوفر النطاق المحدد حدودًا يمكنها:
- ضمان الحد الأدنى والأقصى من استخدام موارد الحوسبة لكل وحدة أو حاوية في مساحة الاسم ؛
- فرض حد أدنى وحد أقصى من طلب Starage لكل PersistentVolumeClaim في مساحة الاسم ؛
- فرض علاقة بين طلب وحد لمورد في مساحة اسم ؛
- قم بتعيين الطلبات / الحدود الافتراضية لحساب الموارد في مساحة الاسم وحقنها تلقائيًا في الحاويات في وقت التشغيل.
حتى تتمكن من إنشاء نطاق محدد في مساحة الاسم الخاصة بك. بخلاف الحصة النسبية ، التي تنطبق على مساحة الاسم بالكامل ، يتم استخدام نطاق الحد للحاويات الفردية. يمكن أن يمنع هذا المستخدمين من إنشاء حاويات صغيرة أو عملاقة داخل مساحة الاسم. قد يبدو النطاق المحدد بهذا الشكل.
كما في الحالة السابقة ، يمكن تمييز 4 أقسام هنا. دعونا نلقي نظرة على كل منها.
يعيّن القسم الافتراضي القيود الافتراضية للحاوية في الحاوية. إذا قمت بتعيين هذه القيم في النطاق الأقصى ، فإن أي حاويات لم يتم تعيين هذه القيم لها بشكل صريح ستتبع القيم الافتراضية.
في قسم defaultRequest ، يتم تكوين الطلبات الافتراضية للحاوية في الحاوية. مرة أخرى ، إذا قمت بتعيين هذه القيم على النطاق الأقصى ، فإن أي حاويات لم يتم تعيين هذه المعلمات لها بشكل صريح ستستخدم هذه القيم افتراضيًا.
يحدد قسم max الحدود القصوى التي يمكن تعيينها لحاوية في Pod. لا يمكن تعيين القيم في القسم الافتراضي وحدود الحاوية فوق هذا الحد. من المهم ملاحظة أنه في حالة تعيين الحد الأقصى وعدم وجود قسم افتراضي ، تصبح القيمة القصوى هي القيمة الافتراضية.
يحدد قسم min الحد الأدنى من الطلبات التي يمكن تعيينها لحاوية في حجرة. ومع ذلك ، لا يمكن تعيين القيم في القسم الافتراضي وطلبات الحاوية أدنى من هذا الحد.
مرة أخرى ، من المهم ملاحظة أنه إذا تم تعيين هذه القيمة ولم يتم تعيين القيمة الافتراضية ، فسيصبح الحد الأدنى للقيمة هو الاستعلام الافتراضي.
في النهاية ، يتم استخدام طلبات الموارد هذه بواسطة جدولة Kubernetes لتنفيذ أحمال العمل الخاصة بك. لكي تتمكن من إعداد حاوياتك بشكل صحيح ، من المهم جدًا فهم كيفية عملها. لنفترض أنك تريد تشغيل عدة كبسولات على مجموعتك. بافتراض أن مواصفات الكبسولة صالحة ، فإن جدول Kubernetes سيستخدم round robin لتحديد العقدة لتشغيل عبء العمل.
سيتحقق Kubernetes مما إذا كان لدى Node 1 موارد كافية لتلبية طلبات حاويات pod ، وإذا لم يكن الأمر كذلك ، فسوف ينتقل إلى العقدة التالية. إذا لم تكن أي من العقد في النظام قادرة على تلبية الطلبات ، فستدخل البودات في حالة الانتظار. باستخدام ميزات محرك Google Kubernetes مثل القياس التلقائي للعقدة ، يمكن لـ GKE اكتشاف الحالة المعلقة تلقائيًا وإنشاء عدد قليل من العقد الإضافية.
إذا كانت هناك سعة زائدة للعقد في وقت لاحق ، فإن القياس التلقائي سيقلل من عدد العقد لتوفير المال. هذا هو سبب قيام Kubernetes بجدولة Pods بناءً على الطلبات. ومع ذلك ، قد يكون الحد أعلى من الطلبات ، وفي بعض الحالات قد تنفد موارد المضيف بالفعل. نسمي هذه الدولة حالة الالتزام المفرط.
كما قلت ، عندما يتعلق الأمر بوحدة المعالجة المركزية ، سيبدأ Kubernetes في الحد من Pods. ستتلقى كل جراب المقدار الذي طلبته ، ولكن إذا لم يصل إلى الحد الأقصى ، فسيبدأ تطبيق الاختناق.
فيما يتعلق بموارد الذاكرة ، يتعين على Kubernetes هنا اتخاذ قرارات بشأن أي البودات يجب حذفها وأيها يجب الاحتفاظ بها حتى تحرير موارد النظام ، وإلا فسوف ينهار النظام بأكمله.
دعنا نتخيل سيناريو حيث لديك آلة تنفد من الذاكرة - كيف سيتعامل Kubernetes مع هذا؟
سيبحث Kubernetes عن Pods التي تستخدم موارد أكثر مما هو مطلوب. لذا ، إذا لم تكن حاوياتك تحتوي على طلبات على الإطلاق ، فهذا يعني أنها تستخدم بشكل افتراضي أكثر مما طلبوا ، وذلك ببساطة لأنهم لم يطلبوا أي شيء على الإطلاق! تصبح هذه الحاويات مرشحة رئيسية للإغلاق. المرشحون التاليون عبارة عن حاويات استوفت جميع طلباتهم لكنها لا تزال أقل من الحد الأقصى.
لذلك إذا عثرت Kubernetes على عدد قليل من البودات التي تجاوزت معاملات الطلب الخاصة بها ، فسيتم تصنيفها حسب الأولوية ثم إزالة أقل البودات ذات الأولوية. إذا كانت جميع الكبسولات لها نفس الأولوية ، فسيقوم Kubernetes بإغلاق تلك الكبسولات التي تجاوزت طلباتها بأكثر من بقية الكبسولات.
في حالات نادرة جدًا ، قد تقوم Kubernetes بإنهاء Pods التي لا تزال ضمن طلباتها. يمكن أن يحدث هذا عندما تبدأ مكونات النظام الهامة مثل عامل Kubelet أو Docker في استهلاك موارد أكثر مما تم حجزه لها.
لذلك ، في المراحل الأولى لشركة صغيرة ، يمكن أن تعمل مجموعة Kubernetes بشكل جيد دون تعيين طلبات وحدود الموارد ، ولكن عندما تبدأ فرقك ومشاريعك في النمو من حيث الحجم ، فإنك تخاطر بالتعرض لمشاكل في هذا المجال. تتطلب إضافة الاستعلامات والقيود إلى الوحدات النمطية ومساحات الأسماء الخاصة بك القليل جدًا من الجهد الإضافي ويمكن أن توفر لك الكثير من المتاعب.
بعض الاعلانات 🙂
أشكركم على البقاء معنا. هل تحب مقالاتنا؟ تريد أن ترى المزيد من المحتوى المثير للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية للأصدقاء ، , تناظرية فريدة من خوادم المستوى المبتدئ ، اخترعناها من أجلك: (متوفر مع RAID1 و RAID10 ، حتى 24 مركزًا وحتى 40 جيجا بايت DDR4).
Dell R730xd أرخص مرتين في مركز بيانات Equinix Tier IV في أمستردام؟ هنا فقط في هولندا! Dell R420 - 2x E5-2430 2.2 جيجا هرتز 6C 128 جيجا بايت DDR3 2x960 جيجا بايت SSD 1 جيجا بايت في الثانية 100 تيرا بايت - من 99 دولارًا! أقرأ عن
المصدر: www.habr.com