لإتقان Kubernetes بشكل كامل، تحتاج إلى معرفة الطرق المختلفة لتوسيع نطاق موارد المجموعة: ، وهذا هو أحد الأهداف الرئيسية لـKubernetes. لقد قدمنا نظرة عامة عالية المستوى على آليات التوسع التلقائي الأفقي والرأسي وتغيير حجم المجموعة، بالإضافة إلى التوصيات حول كيفية استخدامها بشكل فعال.
شرط تمت ترجمتها بواسطة الفريق الذي نفذ التوسع التلقائي في .
لماذا من المهم التفكير في التوسع
- أداة لإدارة الموارد وتنظيمها. بالطبع، من الجيد العبث بالميزات الرائعة مثل النشر والمراقبة وإدارة الجراب (الجراب هو مجموعة من الحاويات التي يتم إطلاقها استجابة لطلب).
ومع ذلك، يجب عليك أيضًا التفكير في الأسئلة التالية:
- كيفية توسيع نطاق الوحدات والتطبيقات؟
- كيفية الحفاظ على الحاويات في حالة صالحة للعمل وفعالة؟
- كيفية الاستجابة للتغييرات المستمرة في الكود وأحمال عمل المستخدم؟
قد يكون إعداد مجموعات Kubernetes لموازنة الموارد والأداء مهمة معقدة وتتطلب معرفة متخصصة بالعمل الداخلي لـ Kubernetes. قد يتقلب حجم العمل على تطبيقك أو خدماتك طوال اليوم أو حتى الساعة، لذا من الأفضل أن تفكر في الموازنة باعتبارها عملية مستمرة.
طبقات التوسع التلقائي في Kubernetes
يتطلب التوسع التلقائي الفعال التنسيق بين مستويين:
- مستوى الجراب، بما في ذلك أجهزة القياس التلقائي الأفقية (Horizontal Pod Autoscaler) والرأسية (Vertical Pod Autoscaler). يعد هذا بمثابة قياس للموارد المتاحة للحاويات الخاصة بك.
- يتم إدارة مستوى المجموعة بواسطة Cluster Autoscaler (CA)، والذي يعمل على زيادة أو تقليل عدد العقد داخل المجموعة.
وحدة التوسع التلقائي للطاقة الأفقية (HPA)
كما يوحي الاسم، تقوم HPA بقياس عدد النسخ المتماثلة. تستخدم معظم عمليات DevOps وحدة المعالجة المركزية وتحميل الذاكرة كمحفزات لتغيير عدد النسخ المتماثلة. ومع ذلك، فمن الممكن توسيع نطاق النظام بناءً على ، هم أو حتى .
رسم تخطيطي عالي المستوى لكيفية عمل HPA:
- تقوم HPA بالتحقق بشكل مستمر من القيم المترية المحددة أثناء التثبيت بفاصل زمني افتراضي يبلغ 30 ثانية.
- تحاول HPA زيادة عدد الوحدات إذا تم الوصول إلى حد معين.
- يقوم HPA بتحديث عدد النسخ المتماثلة داخل وحدة التحكم في النشر/النسخ المتماثل.
- بعد ذلك يقوم وحدة التحكم في النشر/التكرار بنشر أي وحدات إضافية مطلوبة.
يقوم HPA بتشغيل عملية نشر الوحدة النمطية عند الوصول إلى الحد الأقصى للمقياس
عند استخدام HPA، ضع ما يلي في الاعتبار:
- الفترة الزمنية الافتراضية لفحص HPA هي 30 ثانية. يتم تعيينه بواسطة العلم. فترة مزامنة وحدة التوسع التلقائي الأفقية في مدير التحكم.
- الخطأ النسبي الافتراضي هو 10%.
- بعد الزيادة الأخيرة في عدد الوحدات، تنتظر HPA حتى تستقر المقاييس لمدة ثلاث دقائق. يتم تعيين هذا الفاصل الزمني بواسطة العلم وحدة توسيع تلقائية أفقية مع تأخير التوسيع.
- بعد التخفيض الأخير في عدد الوحدات، ينتظر HPA الاستقرار لمدة خمس دقائق. يتم تعيين هذا الفاصل الزمني بواسطة العلم وحدة توسيع تلقائية أفقية مع تأخير التخفيض.
- يعمل HPA بشكل أفضل مع كائنات النشر وليس وحدات التحكم في التكرار. التوسع التلقائي الأفقي غير متوافق مع التحديث المستمر، والذي يتلاعب بشكل مباشر بوحدات التحكم في التكرار. عند النشر، يعتمد عدد النسخ المتماثلة بشكل مباشر على كائنات النشر.
التوسع التلقائي الرأسي للقرون
يقوم التوسع التلقائي الرأسي (VPA) بتخصيص قدر أكبر (أو أقل) من وحدة المعالجة المركزية أو الذاكرة للوحدات الموجودة. مناسب للكبسولات ذات الحالة أو عديمة الحالة، ولكنه مخصص بشكل أساسي للخدمات ذات الحالة. ومع ذلك، يمكنك أيضًا تطبيق VPA على وحدات بدون جنسية إذا كنت بحاجة إلى تعديل كمية الموارد المخصصة مبدئيًا تلقائيًا.
يستجيب VPA أيضًا لأحداث OOM (نفاد الذاكرة). يتطلب تغيير وقت وحدة المعالجة المركزية وحجم الذاكرة إعادة تشغيل الأجهزة. عند إعادة التشغيل، يحترم VPA ميزانية التخصيص () لضمان الحد الأدنى المطلوب من عدد الوحدات.
يمكنك تعيين الحد الأدنى والحد الأقصى لمقدار الموارد لكل وحدة. وبذلك، يمكنك تحديد الحد الأقصى لحجم الذاكرة المخصصة إلى 8 جيجابايت. يعد هذا مفيدًا إذا كانت العقد الحالية غير قادرة بشكل واضح على تخصيص أكثر من 8 جيجابايت من الذاكرة لكل حاوية. يتم وصف المواصفات التفصيلية وآلية التشغيل في .
بالإضافة إلى ذلك، يتمتع VPA بميزة توصية مثيرة للاهتمام (VPA Recommender). يقوم بمراقبة استخدام الموارد وأحداث OOM لجميع الوحدات النمطية لاقتراح قيم جديدة للذاكرة ووقت وحدة المعالجة المركزية استنادًا إلى خوارزمية ذكية تأخذ في الاعتبار المقاييس التاريخية. هناك أيضًا واجهة برمجة تطبيقات تأخذ موصوفًا للجراب وتعيد قيم الموارد المقترحة.
من الجدير بالذكر أن VPA Recommender لا يتتبع "حدود" الموارد. قد يؤدي هذا إلى احتكار الوحدة للموارد داخل العقد. من الأفضل تعيين الحد على مستوى مساحة الأسماء لتجنب استخدام كمية كبيرة من الذاكرة أو وحدة المعالجة المركزية.
مخطط رفيع المستوى لكيفية عمل VPA:
- يتحقق VPA بشكل مستمر من القيم المترية المحددة أثناء التثبيت بفاصل زمني افتراضي يبلغ 10 ثوانٍ.
- إذا تم الوصول إلى الحد الأقصى المحدد، تحاول VPA تغيير الكمية المخصصة من الموارد.
- يقوم VPA بتحديث عدد الموارد داخل وحدة التحكم في النشر/التكرار.
- عند إعادة تشغيل الوحدات النمطية، يتم تطبيق كافة الموارد الجديدة على المثيلات التي تم إنشاؤها.
يضيف VPA الكمية المطلوبة من الموارد
يرجى مراعاة النقاط التالية عند استخدام VPA:
- يتطلب التوسع إعادة تشغيل إلزامية للجهاز. يعد هذا ضروريًا لتجنب التشغيل غير المستقر بعد إجراء التغييرات. من أجل ضمان الموثوقية، تتم إعادة تشغيل الوحدات وتوزيعها عبر العقد استنادًا إلى الموارد المخصصة حديثًا.
- VPA وHPA غير متوافقين مع بعضهما البعض حتى الآن ولا يمكن تشغيلهما على نفس الأجهزة. إذا كنت تستخدم آليتي التوسع في نفس المجموعة، فتأكد من أن الإعدادات لا تسمح بتنشيطهما على نفس الكائنات.
- يقوم VPA بضبط طلبات الحاويات للموارد بناءً على الاستخدام الماضي والحالي فقط. لا يضع حدودًا لاستخدام الموارد. قد تكون هناك مشكلات تتعلق بالتطبيقات التي لا تعمل بشكل صحيح وتبدأ في استهلاك المزيد والمزيد من الموارد، مما سيؤدي إلى قيام Kubernetes بإيقاف تشغيل الجراب.
- لا يزال VPA في المراحل الأولى من التطوير. يرجى الاستعداد لأن النظام قد يخضع لبعض التغييرات في المستقبل القريب. يمكنك القراءة عن и . وبالتالي، تتضمن الخطط تنفيذ التشغيل المشترك لـ VPA وHPA، بالإضافة إلى نشر الوحدات مع سياسة التوسع التلقائي الرأسي لها (على سبيل المثال، تسمية خاصة "يتطلب VPA").
التوسع التلقائي لمجموعة Kubernetes
يقوم Cluster Autoscaler (CA) بتغيير عدد العقد استنادًا إلى عدد الأوعية المنتظرة. يقوم النظام بشكل دوري بالتحقق من الوحدات النمطية المعلقة ويزيد حجم المجموعة إذا كانت هناك حاجة إلى المزيد من الموارد وإذا لم تتجاوز المجموعة الحدود المحددة. تتفاعل سلطة التصديق مع مزود خدمة السحابة، وتطلب منه عقدًا إضافية أو تطلق العقد الخاملة. تم تقديم أول إصدار متاح للجمهور من CA في Kubernetes 1.8.
رسم تخطيطي رفيع المستوى لكيفية عمل CA:
- تتحقق CA من الوحدات النمطية الموجودة في حالة الانتظار بفاصل زمني افتراضي يبلغ 10 ثوانٍ.
- إذا كانت إحدى أو أكثر من الحاويات في حالة انتظار لأن المجموعة لا تحتوي على موارد متاحة كافية لتخصيصها، فإنها تحاول توفير عقدة إضافية واحدة أو أكثر.
- بمجرد أن يقوم موفر الخدمة السحابية بتخصيص العقدة المطلوبة، فإنه ينضم إلى المجموعة ويكون جاهزًا لخدمة الحاويات.
- يقوم مجدول Kubernetes بتوزيع الأوعية المنتظرة على العقدة الجديدة. إذا بقيت بعض الوحدات بعد ذلك في حالة الانتظار، فسيتم تكرار العملية وإضافة عقد جديدة إلى المجموعة.
التخصيص التلقائي لعقد المجموعة في السحابة
يرجى أخذ ما يلي في الاعتبار عند استخدام CA:
- تضمن CA أن جميع الحاويات في المجموعة لديها مساحة للتشغيل، بغض النظر عن مستوى تحميل وحدة المعالجة المركزية. بالإضافة إلى ذلك، فإنه يحاول التأكد من عدم وجود عقد غير ضرورية في المجموعة.
- يسجل CA الحاجة إلى التوسع بعد مرور 30 ثانية تقريبًا.
- بعد أن تصبح العقدة غير ضرورية، تنتظر CA 10 دقائق بشكل افتراضي قبل توسيع نطاق النظام.
- يوجد في نظام التوسع التلقائي مفهوم الموسعات. هناك استراتيجيات مختلفة لاختيار مجموعة من العقد التي سيتم إضافة عقد جديدة إليها.
- استخدم الخيار بمسؤولية cluster-autoscaler.kubernetes.io/safe-to-evict (صحيح). إذا قمت بتثبيت عدد كبير من الحاويات، أو إذا كان العديد منها متناثرًا عبر جميع العقد، فسوف تفقد قدرًا كبيرًا من القدرة على توسيع نطاق المجموعة.
- استخدم لمنع إزالة القرون، مما قد يتسبب في كسر جزء من تطبيقك بالكامل.
كيف تتفاعل أنظمة التوسع التلقائي في Kubernetes مع بعضها البعض
للحصول على تناغم مثالي، يجب تطبيق التوسع التلقائي على مستوى الجراب (HPA/VPA) وعلى مستوى المجموعة. يتفاعلون مع بعضهم البعض بشكل بسيط نسبيًا:
- يقوم HPA أو VPA بتحديث نسخ الكبسولات أو الموارد المخصصة للكبسولات الموجودة.
- إذا لم يكن هناك عدد كافٍ من العقد لأداء التوسع المخطط له، تلاحظ CA وجود وحدات في حالة انتظار.
- تقوم CA بتخصيص عقد جديدة.
- تتم توزيع الوحدات عبر العقد الجديدة.
نظام التوسع التعاوني Kubernetes
الأخطاء الشائعة في التوسع التلقائي في Kubernetes
هناك بعض المشكلات الشائعة التي يواجهها العاملون في DevOps عند محاولة تنفيذ التوسع التلقائي.
تعتمد HPA وVPA على المقاييس وبعض البيانات التاريخية. إذا لم يتم تخصيص موارد كافية، فسيتم انهيار الوحدات ولن تتمكن من إنشاء المقاييس. في هذه الحالة، لن يحدث التوسع التلقائي أبدًا.
إن عملية التوسع في حد ذاتها حساسة للوقت. نريد أن يتم توسيع نطاق الوحدات النمطية والمجموعة بسرعة - قبل أن يلاحظ المستخدمون أي مشاكل أو أعطال. لذلك، ينبغي أن يؤخذ متوسط وقت التوسع للمجموعات والمجموعات في الاعتبار.
السيناريو المثالي - 4 دقائق:
- 30 ثانية. تحديث المقاييس المستهدفة: 30-60 ثانية.
- 30 ثانية. تتحقق HPA من القيم المترية: 30 ثانية.
- أقل من ثانيتين. يتم إنشاء القرون وتدخل في حالة الانتظار: 2 ثانية.
- أقل من ثانيتين. ترى CA وحدات الانتظار وترسل مكالمات لإعداد العقد: 2 ثانية.
- 3 دقائق. يقوم مزود الخدمة السحابية بتخصيص العقد. تنتظر الكلاب من نوع K8 حتى تصبح جاهزة: ما يصل إلى 10 دقائق (يعتمد على عدة عوامل).
السيناريو الأسوأ (الأكثر واقعية) - 12 دقيقة:
- 30 ثانية. تحديث مقاييس الهدف.
- 30 ثانية. تقوم HPA بالتحقق من القيم المترية.
- أقل من ثانيتين. تم إنشاء القرون وهي تدخل في حالة الانتظار.
- أقل من ثانيتين. ترى سلطة التصديق (CA) وحدات الانتظار وتصدر مكالمات لإعداد العقد.
- 10 دقائق. يقوم مزود الخدمة السحابية بتخصيص العقد. K8s ينتظر حتى يصبح جاهزًا. يعتمد وقت الانتظار على عدة عوامل مثل زمن انتظار البائع، وزمن انتظار نظام التشغيل، وأدوات الدعم.
يرجى عدم الخلط بين آليات التوسع الخاصة بموفري الخدمات السحابية وهيئة التصديق الخاصة بنا. يعمل الأخير داخل مجموعة Kubernetes، في حين تعمل آلية موفر السحابة على أساس توزيع العقد. إنه لا يعرف ما يحدث مع قرونك أو تطبيقك. تعمل هذه الأنظمة بالتوازي.
كيفية إدارة التوسع في Kubernetes
- Kubernetes هي أداة لإدارة الموارد وتنظيمها. تشكل عمليات إدارة موارد المجموعة والعقدة معلمًا رئيسيًا في إتقان Kubernetes.
- فهم المنطق وراء قابلية التوسعة القائمة على HPA وVPA.
- يجب استخدام CA فقط إذا كان لديك فهم جيد لاحتياجات القرون والحاويات الخاصة بك.
- لتكوين مجموعة بشكل مثالي، تحتاج إلى فهم كيفية عمل أنظمة التوسع المختلفة معًا.
- عند تقدير أوقات التوسع، ضع في الاعتبار أسوأ السيناريوهات وأفضلها.
المصدر: www.habr.com
