تقييد CPU في Kubernetes: القاتل الصامت لزمن الاستجابة

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

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

في الشكل أعلاه، يبلغ استخدام CPU للحاوية 25% فقط، ما يجعلها مرشحًا طبيعيًا لتقليل حجمها.

لكن بعد تغيير حجم الحاوية (أصبح استخدام CPU للحاوية الآن 50%، وما زال منخفضًا)، تضاعف زمن الاستجابة أربع مرات.

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

لتوضيح الأمر أكثر، تخيَّل أنك تحدِّد قيد CPU بقيمة 200 مللي ثانية، وتتم ترجمة هذا الحد إلى حصة مجموعة في نظام Linux الأساسي. يمكن للحاوية استخدام 20 مللي ثانية فقط من وحدة المعالجة المركزية في كل مرة (ويُطلق على هذا شريحة زمنية للمعالج)، لأن فترة التطبيق الافتراضية تبلغ 100 مللي ثانية فقط. إذا كانت مهمتك أطول من 20 مللي ثانية، فسيتم تقييدك، وسيستغرق إكمال المهمة أربعة أضعاف الوقت.

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

إذا كنت تُجري عملية نشر صغيرة، فقد تتمكن من استكشاف التقييد يدويًا.

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

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

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

يُعَد تقييد وحدة المعالجة المركزية مقياسًا أساسيًا لأداء التطبيقات نظرًا للعلاقة المباشرة بين زمن الاستجابة وتقييد المعالج. هذه أخبار رائعة بالنسبة لك، إذ يمكنك الحصول على هذا المقياس مباشرةً من Kubernetes وOpenShift.

لضمان بقاء أوقات استجابة تطبيقك منخفضة وعدم تقييد وحدة المعالجة المركزية واستمرار تحقيق أداء عالٍ للتطبيق، يجب أولًا أن تفهم أنه عند حدوث تقييد CPU لا يمكن الاعتماد فقط على استخدام نوى المعالج. يجب أن تأخذ في الاعتبار جميع التحليلات واعتماديات الموارد التي تؤثِّر في أداء التطبيق. أدرجت IBM Turbonomic هذه الاعتبارات ضمن منصة التحليلات الخاصة بها.

عند تحديد إجراءات التحجيم المناسب للحاويات، تعمل Turbonomic على تحليل أربعة أبعاد بشكل مستمر:

1. قيود وحدة المعالجة المركزية
2. طلبات وحدة المعالجة المركزية
3. حدود الذاكرة
4. طلبات الذاكرة

تستطيع Turbonomic تحديد قيود وحدة المعالجة المركزية التي تقلل من خطر التقييد وتمكِّن تطبيقاتك من العمل بأداء كامل دون قيود. كل ذلك يتم بفضل إضافة تقييد وحدة المعالجة المركزية كبُعد يمكن للمنصة تحليله وإدارة المقايضات الناتجة عنه. إضافة بُعد تقييد وحدة المعالجة المركزية يضمن انخفاض أوقات استجابة التطبيق.

بالإضافة إلى ذلك، تعمل Turbonomic على توليد إجراءات لنقل الحجيرات الخاصة بك وتوسيع المجموعات، وكما نعلم جميعًا، هذه تحديات على مستوى البنية التقنية بأكملها. لدى العملاء القدرة على الاطِّلاع على مؤشرات الأداء الرئيسية وطرح السؤال: أيٌّ من خدماتي يتم تقييدها؟ كما يُتيح لهم فهم تاريخ تقييد وحدة المعالجة المركزية لكل خدمة، مع مراعاة أن كل خدمة مرتبطة مباشرةً بزمن استجابة التطبيق، ما يوفر للمستخدمين رؤية قيّمة لأداء نظامهم.

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

يمكن لمنصة IBM Turbonomic المساعدة على تحسين كلٍّ من الإنفاق على السحابة والأداء في الوقت نفسه. يمكنك أتمتة إجراءات التحسين بشكل مستمر وفي الوقت الفعلي -دون تدخل بشري- لتوفير الاستخدام الأكثر كفاءة لوحدات المعالجة والذاكرة والتخزين وشبكة الاتصال لتطبيقاتك في كل طبقة من المجموعة.