ثلاثة مستويات من autoscaling في Kubernetes: كيفية استخدامها بشكل فعال

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

تم ترجمة مقال بقلم Kubernetes Autoscaling 101: Cluster Autoscaler، Horizontal Autoscaler، and Vertical Pod Autoscaler من قبل فريق قام بتطبيق autoscaling في Kubernetes aaS من Mail.ru.

لماذا من المهم التفكير في القياس

Kubernetes هي أداة لإدارة الموارد وتنسيقها . بطبيعة الحال ، من الجيد أن يتم العبث بوظائف النشر والمراقبة وإدارة السهولة (وحدة pod هي مجموعة من الحاويات التي يتم إطلاقها استجابةً لطلب).

ومع ذلك ، يجب أن تفكر في مثل هذه القضايا:

1. كيفية توسيع نطاق الوحدات والتطبيقات؟
   
2. كيفية الحفاظ على حاويات التشغيل والكفاءة؟
   
3. كيف تستجيب للتغيرات المستمرة في الكود وعبء العمل من المستخدمين؟
   

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

مستويات Kubernetes autoscale

يتطلب الفحص الذاتي الفعال التنسيق بين مستويين:

1. مستوى Pod ، بما في ذلك أفقي (Autodal Pod Autoscaler ، HPA) والتحجيم التلقائي الرأسي (الرأسي Pod Autoscaler ، VPA). هذا هو توسيع نطاق الموارد المتاحة للحاويات الخاصة بك.
   
2. مستوى الكتلة ، الذي يتم التحكم فيه بواسطة نظام Cluster Autoscaler (CA) ، يزيد أو يقلل من عدد العقد داخل الكتلة.
   

وحدة القياس التلقائي الأفقية (HPA)

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

سير عمل HPA عالي المستوى:

1. يتحقق HPA بشكل مستمر من القيم المترية المحددة أثناء التثبيت بفاصل زمني افتراضي قدره 30 ثانية.
   
2. يحاول HPA زيادة عدد الوحدات النمطية إذا تم الوصول إلى العتبة المحددة.
   
3. HPA بتحديث عدد النسخ المتماثلة داخل وحدة تحكم النشر / النسخ المتماثل.
   
4. ثم تقوم وحدة التحكم في النشر / النسخ المتماثل بنشر جميع الوحدات الإضافية المطلوبة.
   

HPA تطلق عملية نشر الوحدة النمطية عند الوصول إلى عتبة المقاييس

عند استخدام HPA ، ضع في اعتبارك ما يلي:

• الفاصل الزمني الافتراضي للتحقق من صحة HPA هو 30 ثانية. يتم تعيينها مع إشارة فترة قرنة autoscaler- المزامنة في إدارة وحدة التحكم.
  
• الخطأ النسبي الافتراضي هو 10 ٪.
  
• بعد الزيادة الأخيرة في عدد الوحدات ، تتوقع HPA أن تستقر المقاييس في غضون ثلاث دقائق. يتم تعيين هذا الفاصل الزمني بواسطة علامة التأخير الأفقي pod-autoscaler-upscale .
  
• بعد التخفيض الأخير في عدد الوحدات ، تتوقع HPA أن تستقر لمدة خمس دقائق. يتم تعيين هذا الفاصل الزمني بواسطة علامة التأخير الأفقي pod-autoscaler-downscale .
  
• HPA يعمل بشكل أفضل مع كائنات النشر ، وليس وحدات تحكم النسخ المتماثل. autoscaling الأفقي غير متوافق مع التحديثات المتداول ، والتي تتعامل مباشرة مع وحدات تحكم النسخ المتماثل. عند النشر ، يعتمد عدد النسخ المتماثلة مباشرةً على كائنات النشر.
  

autoscaling العمودي من القرون

يخصص المقياس العمودي التلقائي (VPA) مزيدًا من (أو أقل) وقت المعالج أو الذاكرة للقرون الموجودة. انها مناسبة للقرون مع أو بدون دولة عديمي الجنسية ، ولكن الغرض منه هو أساسا للخدمات الحكومية. ومع ذلك ، يمكنك تطبيق VPA للوحدات النمطية عديمي الجنسية إذا كنت بحاجة إلى ضبط كمية الموارد المخصصة أصلاً تلقائيًا.

يستجيب VPA أيضًا إلى أحداث OOM (نفاد الذاكرة ، نفاد الذاكرة). لتغيير وقت المعالج وحجم الذاكرة ، تتم إعادة تشغيل برنامج pod. عند إعادة التشغيل ، يحترم VPA ميزانية توزيع السنفات (PDB ) لضمان الحد الأدنى لعدد الوحدات.

يمكنك تعيين الحد الأدنى والحد الأقصى لموارد كل وحدة. لذلك ، يمكنك تحديد الحد الأقصى لمقدار الذاكرة المخصصة بحد أقصى 8 جيجابايت. هذا مفيد إذا كانت العقد الحالية لا يمكنها تخصيص أكثر من 8 جيجابايت من الذاكرة لكل حاوية. يتم وصف المواصفات التفصيلية وآليات التشغيل في ويكي VPA الرسمية .

بالإضافة إلى ذلك ، VPA لديه وظيفة توصية مثيرة للاهتمام (VPA recommender). يتتبع استخدام الموارد وأحداث OOM لجميع الوحدات لتقديم قيم جديدة من الذاكرة ووقت المعالج بناءً على خوارزمية ذكية مع مراعاة المقاييس التاريخية. هناك أيضًا واجهة برمجة التطبيقات (API) التي تأخذ واصف pod وتقوم بإرجاع قيم الموارد المقترحة.

تجدر الإشارة إلى أن VPA recommender لا تراقب "حد" الموارد. يمكن أن يسبب هذا الوحدة النمطية احتكار الموارد داخل العقد. من الأفضل تعيين قيمة حدية على مستوى مساحة الاسم لتجنب حدوث هدر كبير للذاكرة أو وقت المعالج.

مخطط رفيع المستوى لـ VPA:

1. يقوم VPA بالتحقق المستمر من القيم المترية المحددة أثناء التثبيت بفاصل افتراضي يبلغ 10 ثوانٍ.
   
2. إذا تم الوصول إلى العتبة المحددة ، فسيحاول VPA تغيير كمية الموارد المخصصة.
   
3. يقوم VPA بتحديث مقدار الموارد داخل وحدة التحكم في النشر / النسخ المتماثل.
   
4. عند إعادة تشغيل الوحدات النمطية ، يتم تطبيق جميع الموارد الجديدة على الحالات التي تم إنشاؤها.
   

يضيف VPA الكمية المطلوبة من الموارد

ضع في اعتبارك النقاط التالية عند استخدام VPA:

• التحجيم يتطلب إعادة تشغيل إلزامية للجراب. يعد ذلك ضروريًا لتجنب التشغيل غير المستقر بعد إجراء التغييرات. من أجل الموثوقية ، يتم إعادة تشغيل الوحدات النمطية وتوزيعها بين العقد بناءً على الموارد المخصصة حديثًا.
  
• لا يتوافق VPA و HPA مع بعضهما البعض ولا يمكنهما العمل على نفس الأجهزة. إذا كنت تستخدم آليتي القياس في نفس المجموعة ، فتأكد من أن الإعدادات لن تسمح بتنشيطها على نفس الكائنات.
  
• يقوم VPA بتكوين طلبات الحاوية للموارد استنادًا إلى الاستخدام السابق والحالي فقط. لا تضع قيودًا على استخدام الموارد. قد تكون هناك مشاكل في التشغيل غير الصحيح للتطبيقات التي ستبدأ في الاستيلاء على المزيد والمزيد من الموارد ، وهذا سوف يؤدي إلى إيقاف تشغيل Kubernetes.
  
• VPA لا يزال في مرحلة مبكرة من التطوير. كن مستعدًا في المستقبل القريب للنظام قد يخضع لبعض التغييرات. يمكنك أن تقرأ عن القيود المعروفة وخطط التنمية . لذلك ، في خطط تنفيذ العمل المشترك بين VPA و HPA ، وكذلك نشر الوحدات جنبًا إلى جنب مع سياسة التوسع التلقائي الرأسية بالنسبة لهم (على سبيل المثال ، هناك تسمية خاصة "تتطلب VPA").
  

Kubernetes Cluster Auto-Scaling

يغير Cluster Autoscaler (CA) عدد العقد بناءً على عدد القرون المنتظرة. يبحث النظام بشكل دوري عن الوحدات النمطية المعلقة - ويزيد من حجم الكتلة إذا كانت هناك حاجة إلى مزيد من الموارد وإذا كانت الكتلة لا تتجاوز الحدود المحددة. يتفاعل المرجع المصدق (CA) مع موفر الخدمة السحابية أو يطلب عقدًا إضافية منه أو يحرر الخمول. تم تقديم أول إصدار متاح للجمهور من CA في Kubernetes 1.8.

مخطط تشغيل رفيع المستوى CA:

1. يتحقق المرجع المصدق (CA) من الوحدات النمطية في حالة الاستعداد بفاصل افتراضي يبلغ 10 ثوانٍ.
   
2. إذا كانت وحدة أو عدة وحدات في وضع الاستعداد بسبب عدم كفاية الموارد المتاحة في الكتلة لتوزيعها ، فإنه يحاول إعداد عقد إضافي واحد أو عدة.
   
3. عندما يخصص موفر الخدمة السحابية العقدة المطلوبة ، فإنه يربط الكتلة ويكون جاهزًا لخدمة وحدات pod.
   
4. تقوم Kubernetes Scheduler بتوزيع الوحدات المعلقة على مضيف جديد. إذا استمرت بعد ذلك بعض الوحدات في حالة الاستعداد ، فستتكرر العملية وتتم إضافة عقد جديدة إلى الكتلة.
   

التخصيص التلقائي للعقد العنقودية في السحابة

ضع في اعتبارك ما يلي عند استخدام المرجع المصدق (CA):

• يضمن المرجع المصدق (CA) أن يكون لكل الوحدات في الكتلة مكان للعمل ، بغض النظر عن تحميل المعالج. بالإضافة إلى ذلك ، يحاول التأكد من عدم وجود العقد غير الضرورية في الكتلة.
  
• يسجل المرجع المصدق (CA) الحاجة إلى القياس بعد حوالي 30 ثانية.
  
• بعد أن تصبح العقدة غير ضرورية ، ينتظر CA افتراضيًا 10 دقائق قبل تغيير حجم النظام.
  
• في نظام autoscale هناك مفهوم المتوسع. هذه استراتيجيات مختلفة لاختيار مجموعة من العقد التي ستضاف إليها نقاط جديدة.
  
• استخدام مسؤول الكتلة الخيار- autoscaler.kubernetes.io/safe-to-evict (صحيح) . إذا قمت بتثبيت العديد من البرامج ، أو إذا كانت العديد منها منتشرة في جميع العقد ، فستفقد قدرتك على تقليص حجم المجموعة.
  
• استخدم PodDisruptionBudgets لمنع إزالة البرامج ، بسبب أي جزء من التطبيق قد يفشل تمامًا.
  

كيف تتفاعل أنظمة Kubernetes autoscale

لتحقيق الانسجام التام ، يجب تطبيق القياس التلقائي على مستوى الجراب (HPA / VPA) وعلى مستوى المجموعة. يتفاعلون ببساطة مع بعضهم البعض:

1. HPA أو VPA بتحديث النسخ المتماثلة pod أو الموارد المخصصة للقرون الموجودة.
   
2. إذا لم يكن هناك ما يكفي من العقد للقياس المخطط ، فإن CA تلاحظ وجود القرون في حالة الخمول.
   
3. يخصص CA العقد الجديدة.
   
4. يتم توزيع الوحدات النمطية على العقد الجديدة.
   

Kubernetes نظام التحجيم التعاوني

أخطاء Kubernetes الشائعة autoscaling

هناك العديد من المشكلات النموذجية التي تواجه devs عند محاولة تطبيق autoscaling.

تعتمد HPA و VPA على المقاييس وبعض البيانات التاريخية. إذا تم تخصيص موارد غير كافية ، سيتم طي الوحدات ولن تتمكن من إنشاء مقاييس. في هذه الحالة ، لن يتم إجراء الفحص التلقائي.

عملية التحجيم نفسها حساسة للوقت. نريد توسيع نطاق الوحدات النمطية والكتلة بسرعة - قبل أن يلاحظ المستخدمون أي مشاكل أو فشل. لذلك ، ينبغي أن يؤخذ في الاعتبار متوسط ​​وقت التوسع في القرون والمجموعة.

سيناريو مثالي - 4 دقائق:

1. 30 ثانية تحديث المقاييس المستهدفة: 30-60 ثانية.
   
2. 30 ثانية يتحقق HPA من القيم المترية: 30 ثانية.
   
3. أقل من 2 ثانية. يتم إنشاء وحدات جراب والدخول في حالة الاستعداد: 1 ثانية.
   
4. أقل من 2 ثانية. يرى CA وحدات معلقة ويرسل مكالمات لإعداد العقد: ثانية واحدة.
   
5. 3 دقائق مزود سحابة يخصص العقد. ينتظر K8s حتى يكون جاهزًا: حتى 10 دقائق (يعتمد على عدة عوامل).
   

سيناريو أسوأ (أكثر واقعية) - 12 دقيقة:

1. 30 ثانية تحديث المقاييس المستهدفة.
   
2. 30 ثانية HPA بالتحقق من صحة القيم المترية.
   
3. أقل من 2 ثانية. يتم إنشاء وحدات جراب والذهاب إلى حالة الاستعداد.
   
4. أقل من 2 ثانية. ترى CA وحدات معلقة وترسل مكالمات لإعداد العقد.
   
5. 10 دقائق مزود سحابة يخصص العقد. ينتظر K8s حتى تكون جاهزة. يعتمد وقت الانتظار على عدة عوامل ، مثل تأخير المورد ، وتأخير نظام التشغيل ، وعمل الأدوات المساعدة.
   

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

كيفية إدارة التحجيم في Kubernetes

1. Kubernetes هي أداة لإدارة الموارد وتنسيقها. تعد عمليات جراب الكتلة وإدارة الموارد علامة بارزة في تطوير Kubernetes.
   
2. تعلم منطق قابلية قرنة ل HPA و VPA.
   
3. يجب استخدام CA فقط إذا فهمت احتياجات القرون والحاويات جيدًا.
   
4. من أجل تكوين الكتلة الأمثل ، تحتاج إلى فهم كيفية عمل أنظمة القياس المختلفة معًا.
   
5. عند تقييم أوقات القياس ، ضع في اعتبارك أسوأ السيناريوهات وأفضلها.