تحتاج أنظمة السحابة الحديثة مثل Kubernetes إلى طرق أذكى لإدارة موارد الحوسبة. يشرح هذا المنشور لماذا يؤدي تخمين مقدار قوة الحوسبة التي تحتاجها غالبًا إلى إهدار المال وكيف تعمل الأدوات الجديدة على إصلاح ذلك.
تخيل أنك تدير متجرًا إلكترونيًا مزدهرًا. أنت بحاجة إلى أجهزة كمبيوتر (خوادم) للتعامل مع جميع عملائك. في عالم الحوسبة السحابية، خاصة مع أنظمة مثل Kubernetes، تُسمى هذه الأجهزة «عُقدًا» (nodes) وتعمل تطبيقاتك في وحدات صغيرة تُسمى «بودات» (pods).
يتحدث الخبر اليوم عن مشكلة شائعة تواجه الشركات التي تستخدم خدمة EKS من أمازون (Elastic Kubernetes Service). لفترة طويلة، كانت الطريقة المعتادة لإدارة هذه العُقد هي التخمين. كنت تقوم بإعداد مجموعات من الخوادم، وتقرر مسبقًا عدد الخوادم الصغيرة والمتوسطة والكبيرة التي ستحتاجها خلال فترات الذروة. وبما أن لا أحد يريد أن يتعطل متجره، فكنت تضيف دائمًا القليل من الموارد الزائدة «فقط في حالة الطوارئ». هذا يشبه مدير مطعم يقوم ببناء عدد ثابت من غرف الطعام الصغيرة والمتوسطة والكبيرة، ثم يأمل أن يتطابق العملاء تمامًا مع أحجام هذه الغرف. إذا احتاج العديد من العملاء إلى غرفة متوسطة بينما الغرف الصغيرة فقط هي المتاحة، فإنهم ينتظرون. وإذا ظلت غرفة كبيرة فارغة طوال اليوم، فهذا إهدار للإيجار.
هذه «لعبة التخمين» هي ما يسميه المقال «مشكلة التنبؤ». نظام Kubernetes ممتاز في تنظيم تطبيقاتك، لكنه لم يُصمم للتنبؤ بالضبط بعدد الخوادم التي ستحتاجها في أي لحظة معينة، أو ما هو *نوع* الخادم. لذلك، غالبًا ما ينتهي نصف خوادمك السحابية باهظة الثمن بالجلوس خاملة، مما يهدر المال.
هنا يأتي دور أداة جديدة مثل Karpenter. بدلاً من تحديد مجموعات من الخوادم مسبقًا، يعمل Karpenter بشكل مختلف. فكر في مدير مطعمنا الآن لديه أرضية فارغة ومهندس معماري تحت الطلب. عندما يصل عميل (وهو «بود») ويحتاج إلى طاولة (وهي «عقدة») بمتطلبات محددة – لنقل، طاولة لخمسة أشخاص مع إطلالة – يقوم المهندس المعماري على الفور بتصميم وبناء «تلك الغرفة بالضبط» لهم. لا يوجد مساحة مهدرة، ولا غرف فارغة مبنية مسبقًا.
يقوم Karpenter بإنشاء وإطلاق الخوادم في السحابة ديناميكيًا «فقط عندما تحتاجها تطبيقاتك فعليًا» و«بالمواصفات الدقيقة المطلوبة». هذا يعني عدم المبالغة في توفير الموارد، وعدم وجود خوادم خاملة، وتقليل كبير في إهدار المال. إنه يتعلق بالحصول على موارد الحوسبة الصحيحة، في الوقت المناسب، في كل مرة.
يتحدث الخبر اليوم عن مشكلة شائعة تواجه الشركات التي تستخدم خدمة EKS من أمازون (Elastic Kubernetes Service). لفترة طويلة، كانت الطريقة المعتادة لإدارة هذه العُقد هي التخمين. كنت تقوم بإعداد مجموعات من الخوادم، وتقرر مسبقًا عدد الخوادم الصغيرة والمتوسطة والكبيرة التي ستحتاجها خلال فترات الذروة. وبما أن لا أحد يريد أن يتعطل متجره، فكنت تضيف دائمًا القليل من الموارد الزائدة «فقط في حالة الطوارئ». هذا يشبه مدير مطعم يقوم ببناء عدد ثابت من غرف الطعام الصغيرة والمتوسطة والكبيرة، ثم يأمل أن يتطابق العملاء تمامًا مع أحجام هذه الغرف. إذا احتاج العديد من العملاء إلى غرفة متوسطة بينما الغرف الصغيرة فقط هي المتاحة، فإنهم ينتظرون. وإذا ظلت غرفة كبيرة فارغة طوال اليوم، فهذا إهدار للإيجار.
هذه «لعبة التخمين» هي ما يسميه المقال «مشكلة التنبؤ». نظام Kubernetes ممتاز في تنظيم تطبيقاتك، لكنه لم يُصمم للتنبؤ بالضبط بعدد الخوادم التي ستحتاجها في أي لحظة معينة، أو ما هو *نوع* الخادم. لذلك، غالبًا ما ينتهي نصف خوادمك السحابية باهظة الثمن بالجلوس خاملة، مما يهدر المال.
هنا يأتي دور أداة جديدة مثل Karpenter. بدلاً من تحديد مجموعات من الخوادم مسبقًا، يعمل Karpenter بشكل مختلف. فكر في مدير مطعمنا الآن لديه أرضية فارغة ومهندس معماري تحت الطلب. عندما يصل عميل (وهو «بود») ويحتاج إلى طاولة (وهي «عقدة») بمتطلبات محددة – لنقل، طاولة لخمسة أشخاص مع إطلالة – يقوم المهندس المعماري على الفور بتصميم وبناء «تلك الغرفة بالضبط» لهم. لا يوجد مساحة مهدرة، ولا غرف فارغة مبنية مسبقًا.
يقوم Karpenter بإنشاء وإطلاق الخوادم في السحابة ديناميكيًا «فقط عندما تحتاجها تطبيقاتك فعليًا» و«بالمواصفات الدقيقة المطلوبة». هذا يعني عدم المبالغة في توفير الموارد، وعدم وجود خوادم خاملة، وتقليل كبير في إهدار المال. إنه يتعلق بالحصول على موارد الحوسبة الصحيحة، في الوقت المناسب، في كل مرة.
