عند إنشاء مجموعة Kubernetes، قد تطرح أسئلة: ما عدد العقد العاملة التي يجب تكوينها وما نوعها؟ ما هو الأفضل بالنسبة للمجموعة المحلية: شراء العديد من الخوادم القوية أو استخدام عشرات الأجهزة القديمة في مركز البيانات الخاص بك؟ هل من الأفضل أخذ ثمانية مثيلات أحادية النواة أو مثيلتين رباعية النواة في السحابة؟
الإجابات على هذه الأسئلة موجودة في المقال. في ترجمة الأمر .
سعة الكتلة
بشكل عام، يمكن اعتبار مجموعة Kubernetes بمثابة "عقدة عظمى" كبيرة. إجمالي قوتها الحاسوبية هو مجموع صلاحيات جميع العقد المكونة لها.
هناك عدة طرق لتحقيق هدف سعة المجموعة المطلوب. على سبيل المثال، نحتاج إلى مجموعة ذات سعة إجمالية تبلغ 8 مراكز للمعالج و32 جيجابايت من ذاكرة الوصول العشوائي لأن مجموعة من التطبيقات تتطلب الكثير من الموارد. بعد ذلك يمكنك تثبيت عقدتين بذاكرة 16 جيجابايت أو أربع عقد بذاكرة 8 جيجابايت أو معالجين رباعي النواة أو أربعة معالجات ثنائية النواة.
فيما يلي طريقتان ممكنتان لإنشاء مجموعة:
ينتج كلا الخيارين مجموعة بنفس السعة، لكن التكوين السفلي يحتوي على أربع عقد أصغر والتكوين العلوي يحتوي على عقدتين أكبر.
أي خيار أفضل؟
للإجابة على هذا السؤال، دعونا نلقي نظرة على مزايا كلا الخيارين. وقد قمنا بتلخيصها في جدول.
عدة عقد كبيرة
العديد من العقد الصغيرة
إدارة أسهل للمجموعات (إذا كانت داخل الشركة)
التحجيم التلقائي السلس
أرخص (إذا كان داخل الشركة)
السعر مختلف قليلاً (في السحابة)
يمكنه تشغيل التطبيقات كثيفة الاستخدام للموارد
النسخ المتماثل الكامل
يتم استخدام الموارد بشكل أكثر كفاءة (أقل الحمل على برامج النظام
ارتفاع التسامح مع خطأ الكتلة
يرجى ملاحظة أننا نتحدث فقط عن العقد العاملة. يعد اختيار عدد وحجم العقد الرئيسية موضوعًا مختلفًا تمامًا.
لذلك، دعونا نناقش كل نقطة من الجدول بمزيد من التفصيل.
الخيار الأول: عدة عقد كبيرة
الخيار الأكثر تطرفًا هو عقدة عاملة واحدة لسعة المجموعة بأكملها. في المثال أعلاه، ستكون هذه عقدة عاملة واحدة تحتوي على 16 مركزًا لوحدة المعالجة المركزية و16 جيجابايت من ذاكرة الوصول العشوائي.
الايجابيات
بالإضافة إلى رقم 1. إدارة أسهل
من الأسهل إدارة عدد قليل من الآلات بدلاً من إدارة أسطول كامل. أصبح نشر التحديثات والإصلاحات أسرع، كما أصبحت مزامنتها أسهل. كما أن عدد حالات الفشل بالأرقام المطلقة أقل أيضًا.
يرجى ملاحظة أن كل ما سبق ينطبق على أجهزتك وخوادمك، وليس على المثيلات السحابية.
الوضع مختلف في السحابة. هناك، يتم التعامل مع الإدارة من قبل مزود الخدمة السحابية. وبالتالي، فإن إدارة عشر عقد في السحابة لا تختلف كثيرًا عن إدارة عقدة واحدة.
توجيه حركة المرور وتوزيع الأحمال بين القرون في السحابة : يتم إرسال حركة المرور القادمة من الإنترنت إلى موازن التحميل الرئيسي، الذي يعيد توجيه حركة المرور إلى منفذ إحدى العقد (تقوم خدمة NodePort بتعيين المنفذ في النطاق 30000-32767 في كل عقدة نظام المجموعة). تقوم القواعد التي يحددها kube-proxy بإعادة توجيه حركة المرور من العقدة إلى الكبسولة. إليك ما يبدو عليه الأمر بالنسبة لعشرة قرون على عقدتين:
Pro #2: تكلفة أقل لكل عقدة
السيارة القوية أغلى ثمناً، لكن الزيادة في الأسعار ليست بالضرورة خطية. بمعنى آخر، عادةً ما يكون خادم واحد ذو عشرة نواة بذاكرة تبلغ 10 جيجابايت أرخص من عشرة خوادم أحادية النواة بنفس مقدار الذاكرة.
لكن لاحظ أن هذه القاعدة لا تعمل عادةً في الخدمات السحابية. في مخططات التسعير الحالية لجميع موفري الخدمات السحابية الرئيسيين، تزيد الأسعار خطيًا مع السعة.
وبالتالي، في السحابة، عادة لا يمكنك حفظها على خوادم أكثر قوة.
Pro #3: يمكنك تشغيل التطبيقات كثيفة الاستخدام للموارد
تتطلب بعض التطبيقات خوادم قوية في المجموعة. على سبيل المثال، إذا كان نظام التعلم الآلي يتطلب 8 جيجابايت من الذاكرة، فلن تتمكن من تشغيله على عقد تبلغ سعتها 1 جيجابايت، ولكن فقط مع عقدة عاملة كبيرة واحدة على الأقل.
سلبيات
العيب رقم 1. العديد من القرون لكل عقدة
إذا تم تنفيذ نفس المهمة على عدد أقل من العقد، فمن الطبيعي أن يكون لكل منها عدد أكبر من القرون.
هذا يمكن أن يكون مشكلة.
والسبب هو أن كل وحدة تقدم بعض النفقات العامة لوقت تشغيل الحاوية (مثل Docker)، بالإضافة إلى kubelet وcAdvisor.
على سبيل المثال، يقوم kubelet بفحص جميع الحاويات الموجودة على العقدة بانتظام من أجل البقاء - كلما زاد عدد الحاويات، زاد العمل الذي يتعين على kubelet القيام به.
يقوم CAdvisor بجمع إحصائيات استخدام الموارد لجميع الحاويات الموجودة على العقدة، ويقوم kubelet بالاستعلام عن هذه المعلومات بانتظام وتوفيرها عبر واجهة برمجة التطبيقات (API). مرة أخرى، المزيد من الحاويات يعني المزيد من العمل لكل من cAdvisor وkubelet.
إذا زاد عدد الوحدات، فقد يؤدي ذلك إلى إبطاء النظام وحتى تقويض موثوقيته.
في مستودع Kubernetes بعض تقفز العقد بين حالات جاهز/غير جاهز لأن عمليات فحص kubelet المنتظمة لجميع الحاويات الموجودة على العقدة تستغرق وقتًا طويلاً.
لهذا السبب Kubernetes . اعتمادًا على أداء العقدة، يمكنك تشغيل عدد أكبر من البودات لكل عقدة، ولكن من الصعب التنبؤ بما إذا كانت ستكون هناك مشكلات أو أن كل شيء سيعمل بشكل جيد. يجدر اختبار العمل مقدمًا.
العيب رقم 2. القيود على النسخ المتماثل
عدد قليل جدًا من العقد يحد من المدى الفعال لنسخ التطبيق. على سبيل المثال، إذا كان لديك تطبيق عالي التوفر يحتوي على خمس نسخ متماثلة ولكن عقدتين فقط، فسيتم تقليل درجة النسخ المتماثل الفعالة للتطبيق إلى اثنتين.
لا يمكن توزيع خمس نسخ متماثلة إلا عبر عقدتين، وإذا فشلت إحداهما، فسيتم إزالة نسخ متماثلة متعددة في وقت واحد.
إذا كان لديك خمس عقد أو أكثر، فسيتم تشغيل كل نسخة متماثلة على عقدة منفصلة، وسيؤدي فشل عقدة واحدة إلى إزالة نسخة متماثلة واحدة على الأكثر.
وبالتالي، قد تتطلب متطلبات التوفر العالية حدًا أدنى معينًا لعدد العقد في المجموعة.
العيب رقم 3. أسوأ عواقب الفشل
مع وجود عدد صغير من العقد، يكون لكل فشل عواقب أكثر خطورة. على سبيل المثال، إذا كان لديك عقدتان فقط وفشلت إحداهما، فإن نصف الوحدات النمطية الخاصة بك تختفي على الفور.
بالطبع، سيقوم Kubernetes بترحيل عبء العمل من العقد الفاشلة إلى العقد الأخرى. ولكن إذا كان هناك عدد قليل منهم، فقد لا يكون هناك ما يكفي من القدرة الحرة. ونتيجة لذلك، لن تكون بعض تطبيقاتك متاحة حتى تقوم بإحضار العقدة الفاشلة.
وبالتالي، كلما زاد عدد العقد، قل تأثير فشل الأجهزة.
العيب رقم 4: المزيد من خطوات القياس التلقائي
يحتوي Kubernetes على نظام للقياس التلقائي للمجموعة للبنية التحتية السحابية، والذي يسمح لك بإضافة العقد أو إزالتها تلقائيًا وفقًا لاحتياجاتك الحالية. مع العقد الأكبر حجمًا، يصبح القياس التلقائي أكثر مفاجأة وصعوبة. على سبيل المثال، في عقدتين، ستؤدي إضافة عقدة إضافية إلى زيادة سعة المجموعة على الفور بنسبة 50%. وسيكون عليك أن تدفع مقابل هذه الموارد، حتى لو لم تكن بحاجة إليها.
وبالتالي، إذا كنت تخطط لاستخدام القياس العنقودي التلقائي، فكلما كانت العقد أصغر، كلما حصلت على توسيع أكثر مرونة وفعالية من حيث التكلفة.
الآن دعونا نلقي نظرة على مزايا وعيوب عدد كبير من العقد الصغيرة.
الخيار الثاني: العديد من العقد الصغيرة
تنبع مزايا هذا النهج بشكل أساسي من عيوب الخيار المعاكس الذي يحتوي على عدة عقد كبيرة.
الايجابيات
Pro #1: تأثير أقل للفشل
كلما زاد عدد العقد، قل عدد القرون في كل عقدة. على سبيل المثال، إذا كان لديك مائة وحدة لكل عشر عقد، فستحتوي كل عقدة على متوسط عشر وحدات.
بهذه الطريقة، إذا فشلت إحدى العقد، فستفقد 10% فقط من عبء العمل. من المحتمل أن يتأثر عدد قليل فقط من النسخ المتماثلة وسيظل التطبيق الشامل قيد التشغيل.
بالإضافة إلى ذلك، من المحتمل أن تحتوي العقد المتبقية على ما يكفي من الموارد المجانية للتعامل مع عبء عمل العقدة الفاشلة، لذلك يمكن لـ Kubernetes إعادة جدولة البودات بحرية وستعود تطبيقاتك إلى الحالة الوظيفية بسرعة نسبيًا.
Pro #2: النسخ المتماثل الجيد
إذا كان هناك ما يكفي من العقد، فيمكن لمجدول Kubernetes تعيين عقد مختلفة لجميع النسخ المتماثلة. بهذه الطريقة، في حالة فشل العقدة، ستتأثر نسخة متماثلة واحدة فقط وسيظل التطبيق متاحًا.
سلبيات
العيب رقم 1. صعوبة السيطرة عليه
من الصعب إدارة أعداد كبيرة من العقد. على سبيل المثال، يجب أن تتواصل كل عقدة في Kubernetes مع جميع العقد الأخرى، أي أن عدد الاتصالات ينمو بشكل تربيعي، ويجب تتبع كل هذه الاتصالات.
تقوم وحدة تحكم العقدة في Kubernetes Controller Manager بانتظام بالتجول عبر جميع العقد الموجودة في المجموعة للتحقق من صحتها - كلما زاد عدد العقد، زاد الحمل على وحدة التحكم.
يتزايد أيضًا الحمل على قاعدة بيانات etcd - كل استدعاءات kubelet وkube-proxy لـ etcd (عبر واجهة برمجة التطبيقات)، والتي يجب على etcd أن تبث تحديثات الكائنات إليها.
بشكل عام، تفرض كل عقدة عاملة حملاً إضافيًا على مكونات النظام الخاصة بالعقد الرئيسية.
يدعم Kubernetes رسميًا المجموعات ذات . ومع ذلك، في الممارسة العملية هناك بالفعل 500 عقدة .
لإدارة عدد كبير من العقد العاملة، يجب عليك اختيار عقد رئيسية أكثر قوة. على سبيل المثال، كوبي اب حجم VM الصحيح للعقدة الرئيسية اعتمادًا على عدد العقد العاملة. وهذا يعني أنه كلما زاد عدد العقد العاملة، زادت إنتاجية العقد الرئيسية.
لحل هذه المشاكل المحددة هناك تطورات خاصة، مثل . يتيح لك هذا النظام تجاوز القيود وبناء مجموعات تحتوي على عدد كبير من العقد العاملة.
العيب رقم 2: المزيد من التكاليف العامة.
في كل عقدة عاملة، يقوم Kubernetes بتشغيل مجموعة من برامج النظام - بما في ذلك وقت تشغيل الحاوية (مثل Docker)، وkube-proxy، وkubelet، بما في ذلك cAdvisor. يستهلكون معًا قدرًا ثابتًا معينًا من الموارد.
إذا كان لديك العديد من العقد الصغيرة، تكون نسبة هذا الحمل على كل عقدة أكبر. على سبيل المثال، تخيل أن جميع برامج النظام الموجودة على عقدة واحدة معًا تستخدم 0,1 مركزًا لوحدة المعالجة المركزية و0,1 جيجابايت من الذاكرة. إذا كان لديك عقدة واحدة ذات عشرة مراكز بسعة 10 جيجابايت من الذاكرة، فإن البرامج الشيطانية تستهلك 1% من سعة المجموعة. من ناحية أخرى، في عشر عقد أحادية النواة بذاكرة تبلغ 1 جيجابايت، ستستحوذ البرامج الشيطانية على 10% من سعة المجموعة.
وبالتالي، كلما قل عدد العقد، زادت كفاءة استخدام البنية التحتية.
العيب رقم 3. الاستخدام غير الفعال للموارد
في العقد الصغيرة، قد تكون أجزاء الموارد المتبقية صغيرة جدًا بحيث لا يمكن تعيين أي حمل عمل لها، لذا تظل غير مستخدمة.
على سبيل المثال، يتطلب كل جراب 0,75 جيجابايت من الذاكرة. إذا كان لديك عشر عقد، كل منها بذاكرة 1 جيجابايت، فيمكنك تشغيل عشر وحدات، مع ترك كل عقدة بذاكرة غير مستخدمة تبلغ 0,25 جيجابايت.
وهذا يعني إهدار 25% من ذاكرة المجموعة بأكملها.
على عقدة كبيرة ذات ذاكرة تبلغ 10 جيجابايت، يمكنك تشغيل 13 وحدة من هذه الوحدات - وسيكون هناك جزء واحد غير مستخدم يبلغ 0,25 جيجابايت.
في هذه الحالة، يتم إهدار 2,5% فقط من الذاكرة.
وبالتالي، يتم استخدام الموارد على النحو الأمثل على العقد الأكبر.
عدة عقد كبيرة أو العديد من العقد الصغيرة؟
إذن، أيهما أفضل: عدد قليل من العقد الكبيرة في كتلة أم عدة عقد صغيرة؟ وكما هو الحال دائما، لا توجد إجابة واضحة. يعتمد الكثير على نوع التطبيق.
على سبيل المثال، إذا كان التطبيق يتطلب 10 غيغابايت من الذاكرة، فإن العقد الأكبر حجمًا تكون خيارًا واضحًا. وإذا كان التطبيق يتطلب النسخ المتماثل بمقدار عشرة أضعاف من أجل التوفر العالي، فلا يستحق المخاطرة بوضع النسخ المتماثلة على عقدتين فقط - يجب أن يكون هناك ما لا يقل عن عشر عقد في المجموعة.
في المواقف المتوسطة، قم بالاختيار بناءً على مزايا وعيوب كل خيار. ربما تكون بعض الحجج أكثر صلة بموقفك من غيرها.
وليس من الضروري على الإطلاق جعل جميع العقد بنفس الحجم. لا شيء يمنعك من تجربة العقد من نفس الحجم أولاً، ثم إضافة عقد ذات حجم مختلف إليها، ودمجها في كتلة. يمكن أن تكون العقد العاملة في مجموعة Kubernetes غير متجانسة تمامًا. لذلك يمكنك محاولة الجمع بين مزايا كلا النهجين.
لا توجد وصفة واحدة، ولكل موقف فروق دقيقة، والإنتاج وحده هو الذي سيظهر الحقيقة.
الترجمة من إعداد فريق المنصة السحابية .
المزيد عن كوبرنيتيس: .
المصدر: www.habr.com