مراقبة موارد مجموعة Kubernetes

مراقبة موارد مجموعة Kubernetes

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

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

لقد تمكنت من إدارة عدة مجموعات من 4 إلى 50 عقدة. تحتوي كل مجموعة على ما يصل إلى 200 خدمة وتطبيقات صغيرة. للاستفادة بشكل أفضل من الأجهزة الموجودة، تم تكوين معظم عمليات النشر باستخدام موارد ذاكرة الوصول العشوائي (RAM) ووحدة المعالجة المركزية (CPU) القابلة للاندفاع. بهذه الطريقة، يمكن للبودات أن تأخذ الموارد المتاحة إذا لزم الأمر، وفي الوقت نفسه لا تتداخل مع التطبيقات الأخرى على هذه العقدة. حسنًا، أليس هذا رائعًا؟

وعلى الرغم من أن المجموعة تستهلك القليل نسبيًا من وحدة المعالجة المركزية (8%) وذاكرة الوصول العشوائي (40%)، إلا أننا واجهنا مشكلات مستمرة مع استباق الكبسولات عندما حاولت تخصيص ذاكرة أكبر مما كان متاحًا على العقدة. في ذلك الوقت لم يكن لدينا سوى لوحة تحكم واحدة لمراقبة موارد Kubernetes. مثله:

مراقبة موارد مجموعة Kubernetes
لوحة معلومات Grafana مع مقاييس cAdvisor فقط

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

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

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

لقد قمت تقريبًا بمراقبة جميع مجموعات Kubernetes فقط باستخدام مصدر العقدة и مقاييس ولاية كوبي. يوفر Node Exporter إحصائيات حول استخدام الإدخال/الإخراج والقرص ووحدة المعالجة المركزية وذاكرة الوصول العشوائي، بينما تعرض مقاييس حالة Kube مقاييس كائن Kubernetes مثل الطلبات وحدود موارد وحدة المعالجة المركزية والذاكرة.

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

مراقبة موارد مجموعة Kubernetes

مراقبة موارد مجموعة Kubernetes
لوحة تحكم كوبي إيجل

تمكنا من حل العديد من المشاكل المتعلقة بالموارد وتوفير المعدات:

  1. لم يكن بعض المطورين يعرفون عدد الموارد التي تحتاجها الخدمات الصغيرة (أو ببساطة لم يزعجوا أنفسهم). لم تكن هناك طريقة للعثور على طلبات غير صحيحة للموارد - ولهذا نحتاج إلى معرفة الاستهلاك بالإضافة إلى الطلبات والحدود. والآن يمكنهم رؤية مقاييس Prometheus ومراقبة الاستخدام الفعلي وضبط الطلبات والحدود.
  2. تستهلك تطبيقات JVM أكبر قدر ممكن من ذاكرة الوصول العشوائي (RAM) التي يمكنها التعامل معها. يقوم جامع البيانات المهملة بتحرير الذاكرة فقط عند استخدام أكثر من 75%. وبما أن معظم الخدمات تحتوي على ذاكرة قابلة للانفجار، فقد كانت مشغولة دائمًا بواسطة JVM. لذلك، كانت جميع خدمات Java هذه تستهلك ذاكرة وصول عشوائي (RAM) أكبر بكثير مما كان متوقعًا.
  3. طلبت بعض التطبيقات قدرًا كبيرًا من الذاكرة، ولم يمنح برنامج جدولة Kubernetes هذه العقد لتطبيقات أخرى، على الرغم من أنها كانت في الواقع أكثر حرية من العقد الأخرى. أضاف أحد المطورين عن طريق الخطأ رقمًا إضافيًا في الطلب وحصل على قطعة كبيرة من ذاكرة الوصول العشوائي: 20 جيجابايت بدلاً من 2. ولم يلاحظ أحد ذلك. يحتوي التطبيق على 3 نسخ متماثلة، مما يعني تأثر ما يصل إلى 3 عقد.
  4. لقد قدمنا ​​حدودًا للموارد، وأعدنا جدولة الكبسولات بالطلبات الصحيحة، وحصلنا على توازن مثالي لاستخدام الأجهزة عبر جميع العقد. كان من الممكن إغلاق بعض العقد تمامًا. وبعد ذلك رأينا أن لدينا الأجهزة الخاطئة (موجهة بوحدة المعالجة المركزية، وليست موجهة نحو الذاكرة). قمنا بتغيير النوع وحذفنا عدة عقد أخرى.

نتائج

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

المصدر: www.habr.com

إضافة تعليق