خطوات الاستخدام
الخطوة الأولى: أدخل عدد الحاويات (containers) التي ترغب في نشرها. هذا الرقم يمثل عدد نسخ التطبيق أو الخدمة التي سيتم تشغيلها. في بيئات مثل Kubernetes، يتم تحديد هذا العدد لتحقيق التوازن في التحميل وتوفير التكرار (redundancy) وتجنب نقاط الفشل الفردية. كلما زاد العدد، زادت القدرة على معالجة الطلبات ولكن أيضًا زاد استهلاك الموارد. تأكد من أن العدد يتماشى مع متطلبات التطبيق من حيث التوفرية (availability) والحمل المتوقع.
الخطوة الثانية: أدخل كمية وحدة المعالجة المركزية (CPU) المطلوبة لكل حاوية. عادةً ما تُعطى بوحدة الـ millicores (مللي كور) أو بعدد صحيح من الأنوية (vCPUs). على سبيل المثال، 1000 millicores = 1 CPU core. فهم هذه الوحدة ضروري لأن الحاويات غالبًا ما تشارك نوى المعالج مع بعضها البعض. تحديد قيمة منخفضة جدًا قد يؤدي إلى ضعف الأداء، بينما قيمة مرتفعة جدًا قد تهدر الموارد. يُنصح بالرجوع إلى معايير التطبيق الأساسية مثل متطلبات اللغة أو قاعدة البيانات.
الخطوة الثالثة: أدخل كمية الذاكرة (memory) المطلوبة لكل حاوية. الوحدة الشائعة هي الميغابايت (MB) أو الجيغابايت (GB). يجب أن تشمل هذه القيمة الذاكرة المستخدمة من قبل التطبيق نفسه بالإضافة إلى أي اعتماديات (dependencies). على سبيل المثال، إذا كان التطبيق يعتمد على قاعدة بيانات داخل الحاوية، يجب تضمين ذاكرة قاعدة البيانات أيضًا. احذر من تأثير تراكم الذاكرة (memory leak) وتأكد من تعيين حد أقصى (limit) أعلى من الطلب (request) لمنع الحاوية من استخدام ذاكرة غير محدودة.
الخطوة الرابعة: احسب إجمالي الموارد المطلوبة: إجمالي CPU = عدد الحاويات × CPU لكل حاوية. إجمالي الذاكرة = عدد الحاويات × الذاكرة لكل حاوية. هذه الأرقام تمثل الحد الأدنى من الموارد التي يجب أن تكون متاحة في الكتلة (cluster) لتشغيل جميع الحاويات. في بيئات السحابة، قد تحتاج إلى إضافة هامش أمان (buffer) بنسبة 10-20% لاستيعاب أي تقلبات في الأداء أو احتياجات إضافية مثل sidecar containers أو أنظمة التشغيل.
الخطوة الخامسة: تحقق من التأكد من أن الموارد الإجمالية لا تتجاوز سعة البنية التحتية. إذا كنت تستخدم Kubernetes، تأكد من أن لديك عقد (nodes) كافية تفي بمجموع الموارد المطلوبة. يُوصى أيضًا بفهم الفرق بين requests و limits: requests هي الموارد المضمونة للحاوية، بينما limits هي الحد الأقصى المسموح به. إذا تجاوزت requests إجمالي سعة العقدة، قد لا تتم جدولة الحاويات.
أمثلة محلولة
تطبيقات عملية على حاسبة موارد الحاويات بخطوات الحل كاملة.
الحل
لحساب إجمالي الموارد: إجمالي CPU = 10 × 0.5 = 5 vCPUs. إجمالي الذاكرة = 10 × 512 ميجابايت = 5120 ميجابايت = 5 جيجابايت. لكن يجب مراعاة أن كل حاوية قد تحتاج أيضاً إلى موارد OS overhead (نحو 5-10% إضافية). إذا أضفنا هامش 10%، يصبح إجمالي CPU المطلوب 5.5 vCPUs والذاكرة 5.6 جيجابايت. بالإضافة إلى ذلك، إذا كنت تستخدم Kubernetes مع sidecar (مثل Istio proxy)، أضف 100-200 ميجابايت لكل حاوية. لذلك قد تحتاج إلى حوالي 6 حاويات فعلياً لتحقيق التكرار؟ لا، العدد هو 10 حاويات، لكن الموارد الإضافية تجعل الإجمالي 6.5 جيجابايت ذاكرة و 6 vCPUs. تأكد من أن العقد الفعلية تدعم هذه القيم. على سبيل المثال، إذا كان لديك عقدة واحدة بسعة 8 vCPUs و 16 جيجابايت، يمكنك تشغيل 10 حاويات بسهولة مع هامش أمان.
الحل
إجمالي CPU = 50 × 2 = 100 vCPUs. إجمالي الذاكرة = 50 × 4 = 200 جيجابايت. هذا كبير جداً! في السحابة، قد تحتاج إلى 5 عقدة كل منها 20 vCPU و 40 جيجابايت ذاكرة (إجمالي 100 vCPU و 200 جيجابايت). لكن يجب مراعاة أن تطبيقات مثل Spark تحتاج إلى ذاكرة إضافية لـ shuffle و overhead. غالباً ما يوصى بتخصيص 10-20% إضافية. لذا يمكنك حساب 240 جيجابايت ذاكرة و 120 vCPU. أيضاً، يجب أن تأخذ في الاعتبار سياسات الجدولة (scheduling) في Kubernetes: قد لا تتمكن العقد من تشغيل حاويات كثيرة إذا كانت كل حاوية تستهلك 2 vCPU و 4 جيجابايت لأن عدد الحاويات لكل عقدة محدود. قد تحتاج إلى تقسيم الحاويات على عقد متعددة مع مراعاة التوزيع الجغرافي أو المتطلبات الشبكية. استخدم حاسبة الموارد لتقدير التكلفة في السحابة العامة مثل AWS ECS أو Google Cloud Run.
أمثلة محسوبة
قيم مُدخَلة ونتيجة محسوبة فعليًا بواسطة حاسبة موارد الحاويات.
مرجع — تطبيق ويب صغير
- عدد الحاويات
- 10
- وحدة المعالجة المركزية لكل حاوية (نواة)
- 0.5
- الذاكرة لكل حاوية (ميجابايت)
- 512
مرجع — حِمل بيانات ضخم
- عدد الحاويات
- 50
- وحدة المعالجة المركزية لكل حاوية (نواة)
- 2
- الذاكرة لكل حاوية (ميجابايت)
- 4,096
مرجع — نوى كسرية لكل حاوية
- عدد الحاويات
- 8
- وحدة المعالجة المركزية لكل حاوية (نواة)
- 1.5
- الذاكرة لكل حاوية (ميجابايت)
- 1,024