ملحوظة. ترجمة.: هذه المادة من مشروع تعليمي - إجابة سؤال شائع عند تصميم البنية التحتية على أساس Kubernetes. نأمل أن تساعدك الأوصاف التفصيلية الكافية لإيجابيات وسلبيات كل خيار على اتخاذ أفضل خيار لمشروعك.
TL؛ DR: يمكن تشغيل نفس مجموعة أحمال العمل على عدة مجموعات كبيرة (سيكون لكل مجموعة عدد كبير من أحمال العمل) أو على العديد من الأحمال الصغيرة (مع عدد صغير من أحمال العمل في كل مجموعة).
يوجد أدناه جدول يقيم إيجابيات وسلبيات كل نهج:
عند استخدام Kubernetes كنظام أساسي لتشغيل التطبيقات ، غالبًا ما يكون هناك العديد من الأسئلة الأساسية حول تعقيدات تكوين المجموعات:
- كم عدد المجموعات لاستخدامها؟
- ما هو الحجم الذي يجب أن تصنعه؟
- ما الذي يجب أن تتضمنه كل مجموعة؟
في هذه المقالة ، سأحاول الإجابة على كل هذه الأسئلة من خلال تحليل إيجابيات وسلبيات كل نهج.
بيان سؤال
بصفتك مطور برامج ، من المحتمل أن تقوم بتطوير وتشغيل العديد من التطبيقات بالتوازي.
بالإضافة إلى ذلك ، من المحتمل أن يتم تشغيل العديد من مثيلات هذه التطبيقات في بيئات مختلفة - على سبيل المثال ، يمكن أن تكون ديف, تجربه بالعربي и همز.
والنتيجة هي مصفوفة كاملة من التطبيقات والبيئات:
التطبيقات والبيئات
في المثال أعلاه ، هناك 3 تطبيقات و 3 بيئات ، مما ينتج عنه إجمالي 9 خيارات ممكنة.
كل طبعة تطبيق هي وحدة نشر قائمة بذاتها يمكنك العمل معها بشكل مستقل عن الآخرين.
يرجى ملاحظة أن مثيل التطبيق قد تتكون من العديد مكوناتمثل الواجهة الأمامية والخلفية وقاعدة البيانات وما إلى ذلك. في حالة تطبيق الخدمات المصغرة ، سيتضمن المثيل جميع الخدمات المصغرة.
نتيجة لذلك ، لدى مستخدمي Kubernetes عدة أسئلة:
- هل يجب استضافة جميع طبعات التطبيق على نفس المجموعة؟
- هل يستحق الأمر بدء مجموعة منفصلة لكل مثيل تطبيق؟
- أو ربما ينبغي استخدام مزيج من الأساليب المذكورة أعلاه؟
كل هذه الخيارات قابلة للتطبيق ، لأن Kubernetes هو نظام مرن لا يحد من خيارات المستخدم.
فيما يلي بعض الطرق الممكنة:
- مجموعة مشتركة كبيرة واحدة ؛
- العديد من التجمعات الصغيرة المتخصصة للغاية ؛
- مجموعة واحدة لكل تطبيق ؛
- مجموعة واحدة لكل بيئة.
كما هو موضح أدناه ، فإن النهجين الأولين يقعان على طرفي نقيض من مقياس الخيارات:
من عدد قليل من التجمعات الكبيرة (على اليسار) إلى العديد من المجموعات الصغيرة (على اليمين)
بشكل عام ، يعتبر أن إحدى المجموعات "أكبر" من الأخرى إذا كانت تحتوي على أكثر من مجموع العقد والقرون. على سبيل المثال ، الكتلة التي تحتوي على 10 عقد و 100 قرنة أكبر من الكتلة التي تحتوي على عقدة واحدة و 1 قرون.
حسنًا ، لنبدأ!
1. مجموعة مشتركة كبيرة واحدة
الخيار الأول هو وضع جميع أحمال العمل في مجموعة واحدة:
كتلة واحدة كبيرة
ضمن هذا النهج ، يتم استخدام الكتلة كعنصر عالمي منصة البنية التحتية - يمكنك ببساطة نشر كل ما تحتاجه في مجموعة Kubernetes الحالية.
يسمح لك Kubernetes بالفصل المنطقي لأجزاء من نظام المجموعة عن بعضها البعض ، بحيث يمكن لكل طبعة تطبيق استخدام مساحة الاسم الخاصة بها.
دعونا نلقي نظرة على إيجابيات وسلبيات هذا النهج.
+ الاستخدام الفعال للموارد
في حالة وجود مجموعة واحدة ، ستكون هناك حاجة إلى نسخة واحدة فقط من جميع الموارد اللازمة لتشغيل وإدارة مجموعة Kubernetes.
على سبيل المثال ، هذا صحيح بالنسبة للعقد الرئيسية. عادة ، هناك 3 عقد رئيسية لكل مجموعة Kubernetes ، لذلك بالنسبة لمجموعة واحدة ، سيظل عددها على هذا النحو (للمقارنة ، ستحتاج 10 مجموعات إلى 30 عقدة رئيسية).
تنطبق الدقة المذكورة أعلاه أيضًا على الخدمات الأخرى التي تعمل عبر المجموعة بأكملها ، مثل موازنات التحميل ووحدات التحكم في الدخول والمصادقة وأنظمة التسجيل والمراقبة.
في مجموعة واحدة ، يمكن استخدام جميع هذه الخدمات لجميع أعباء العمل في وقت واحد (لا داعي لإنشاء نسخ منها ، كما هو الحال في مجموعات متعددة).
+ رخيصة
كنتيجة لما سبق ، فعادة ما يكون عدد أقل من المجموعات أرخص لأنه لا توجد تكلفة للموارد الزائدة.
هذا ينطبق بشكل خاص على Masternodes ، والتي يمكن أن تكلف مبلغًا كبيرًا من المال سواء تمت استضافتها في أماكن العمل أو في السحابة.
تمكنت بعض خدمات Kubernetes مثل أو ، توفير طبقة التحكم مجانًا. في هذه الحالة ، تكون مسألة التكاليف أقل حدة.
هناك أيضًا خدمات مُدارة تفرض رسومًا ثابتة لتشغيل كل مجموعة Kubernetes (على سبيل المثال ، ).
+ إدارة فعالة
من الأسهل إدارة مجموعة واحدة من عدة مجموعات.
قد تشمل الإدارة المهام التالية:
- تحديث إصدار Kubernetes ؛
- تكوين خط أنابيب CI / CD ؛
- تثبيت البرنامج المساعد CNI ؛
- إنشاء نظام مصادقة المستخدم ؛
- تركيب وحدة تحكم الدخول ؛
واشياء أخرى عديدة…
في حالة وجود مجموعة واحدة ، سيتعين عليك القيام بكل هذا مرة واحدة فقط.
بالنسبة للعديد من المجموعات ، سيتعين تكرار العمليات عدة مرات ، الأمر الذي سيتطلب على الأرجح بعض أتمتة العمليات والأدوات لضمان عملية منتظمة وموحدة.
والآن بضع كلمات عن السلبيات.
- نقطة واحدة للفشل
في حالة الرفض الوحيد ستتوقف المجموعات عن العمل على الفور جميع أعباء العمل!
هناك العديد من الخيارات عندما يحدث خطأ ما:
- تؤدي ترقية Kubernetes إلى آثار جانبية غير متوقعة
- لا يبدأ مكون على مستوى الكتلة (على سبيل المثال ، مكون إضافي لـ CNI) في العمل كما هو متوقع ؛
- تم تكوين أحد مكونات الكتلة بشكل غير صحيح ؛
- فشل في البنية التحتية الأساسية.
يمكن أن يتسبب أحد هذه الحوادث في أضرار جسيمة لجميع أعباء العمل المستضافة في مجموعة مشتركة.
- عدم وجود مواد عازلة صلبة
يعني التشغيل في مجموعة مشتركة أن التطبيقات تشترك في الأجهزة وإمكانيات الشبكات ونظام التشغيل على العقد العنقودية.
بمعنى ما ، هناك حاويتان بهما تطبيقان مختلفان يعملان على نفس المضيف يشبهان عمليتين تعملان على نفس الجهاز يعملان على نفس نواة نظام التشغيل.
توفر حاويات Linux شكلاً من أشكال العزلة ، لكنها ليست في مكان قريب من القوة التي توفرها ، على سبيل المثال ، الأجهزة الافتراضية. في جوهرها ، العملية في الحاوية هي نفس العملية التي تعمل على نظام التشغيل المضيف.
يمكن أن تكون هذه مشكلة أمنية: تسمح هذه المنظمة نظريًا للتطبيقات غير ذات الصلة بالتواصل مع بعضها البعض (عن قصد أو عن طريق الخطأ).
بالإضافة إلى ذلك ، تشترك جميع أحمال العمل في مجموعة Kubernetes في بعض الخدمات على مستوى المجموعة مثل - يسمح هذا للتطبيقات بالعثور على خدمات التطبيقات الأخرى في المجموعة.
يمكن أن يكون لكل النقاط المذكورة أعلاه معاني مختلفة اعتمادًا على متطلبات أمان التطبيق.
يوفر Kubernetes أدوات متنوعة لمنع مشكلات الأمان مثل и . ومع ذلك ، فهي تتطلب بعض الخبرة لتكوينها بشكل صحيح ، ولا يمكنها إغلاق جميع الثغرات الأمنية تمامًا.
من المهم أن تتذكر دائمًا أن Kubernetes تم تصميمه في الأصل لـ مشاركة، ليس ل العزلة والأمن.
- عدم وجود صعوبة في تعدد الإيجارات
نظرًا لوفرة الموارد المشتركة في مجموعة Kubernetes ، هناك العديد من الطرق التي يمكن من خلالها للتطبيقات المختلفة أن تخطو على أصابع قدم بعضها البعض.
على سبيل المثال ، يمكن لأحد التطبيقات أن يحتكر موردًا مشتركًا (مثل المعالج أو الذاكرة) ويرفض وصول التطبيقات الأخرى التي تعمل على نفس المضيف إلى الوصول إليه.
يوفر Kubernetes آليات مختلفة للتحكم في هذا السلوك ، مثل (انظر أيضا المقال ""- تقريبًا. ترجمة.), и . ومع ذلك ، كما هو الحال في حالة الأمان ، فإن تكوينها غير بسيط إلى حد ما ولا يمكنها منع جميع الآثار الجانبية غير المتوقعة على الإطلاق.
- عدد كبير من المستخدمين
في حالة وجود مجموعة واحدة ، يجب عليك فتح الوصول إليها للعديد من الأشخاص. وكلما زاد عددهم ، زادت مخاطر "كسر" شيء ما.
داخل المجموعة ، يمكنك التحكم في من يمكنه فعل ماذا (انظر المقال ""- تقريبًا. ترجمة.). ومع ذلك ، فإنه لن يمنع المستخدمين من "كسر" شيء ما في منطقة مسؤوليتهم.
- لا يمكن أن تنمو المجموعات إلى ما لا نهاية
من المحتمل أن تكون المجموعة المستخدمة لجميع أحمال العمل كبيرة جدًا (من حيث عدد العقد والقرون).
ولكن هنا تنشأ مشكلة أخرى: لا يمكن أن تنمو التجمعات في Kubernetes إلى ما لا نهاية.
هناك حد نظري لحجم الكتلة. في Kubernetes ، إنه تقريبًا .
ومع ذلك ، في الحياة الواقعية ، يمكن أن تبدأ المشاكل في وقت أبكر بكثير - على سبيل المثال ، متى .
الحقيقة هي أن المجموعات الكبيرة تضع عبئًا كبيرًا على طبقة التحكم Kubernetes. بمعنى آخر ، يلزم ضبط دقيق للحفاظ على الكتلة وتعمل بكفاءة.
تم استكشاف هذه المشكلة في مقالة ذات صلة على المدونة الأصلية بعنوان "".
لكن لنفكر في النهج المعاكس: العديد من المجموعات الصغيرة.
2. العديد من التجمعات الصغيرة المتخصصة
باستخدام هذا الأسلوب ، يمكنك استخدام مجموعة منفصلة لكل عنصر تقوم بنشره:
العديد من التجمعات الصغيرة
لأغراض هذه المادة تحت عنصر قابل للنشر يُفهم على أنه مثيل للتطبيق - على سبيل المثال ، إصدار مطور من تطبيق منفصل.
في هذه الإستراتيجية ، يتم استخدام Kubernetes كمتخصص مدة العرض لمثيلات التطبيق الفردية.
دعونا نلقي نظرة على إيجابيات وسلبيات هذا النهج.
+ "نصف قطر انفجار" محدود
عندما "تنكسر" مجموعة ، فإن النتائج السلبية تقتصر فقط على أعباء العمل التي تم نشرها في هذه المجموعة. تظل جميع أعباء العمل الأخرى كما هي.
+ العزل
لا تشترك أحمال العمل المستضافة في مجموعات فردية في الموارد المشتركة مثل المعالج أو الذاكرة أو نظام التشغيل أو الشبكة أو الخدمات الأخرى.
نتيجة لذلك ، نحصل على عزلة قوية بين التطبيقات غير ذات الصلة ، والتي يمكن أن تكون مفيدة لأمنها.
+ عدد قليل من المستخدمين
نظرًا لأن كل مجموعة تحتوي فقط على مجموعة محدودة من أحمال العمل ، يتم تقليل عدد المستخدمين الذين يمكنهم الوصول إليها.
كلما قل عدد الأشخاص الذين يمكنهم الوصول إلى الكتلة ، قل خطر "كسر" شيء ما.
دعونا نلقي نظرة على السلبيات.
- الاستخدام غير الفعال للموارد
كما ذكرنا سابقًا ، تتطلب كل مجموعة Kubernetes مجموعة معينة من موارد الإدارة: العقد الرئيسية ومكونات طبقة التحكم وحلول المراقبة والتسجيل.
في حالة وجود عدد كبير من المجموعات الصغيرة ، يجب تخصيص حصة أكبر من الموارد للإدارة.
- غالي الثمن
يؤدي الاستخدام غير الفعال للموارد تلقائيًا إلى ارتفاع التكاليف.
على سبيل المثال ، الحفاظ على 30 رمزًا رئيسيًا بدلاً من ثلاثة بنفس قوة الحوسبة سيؤثر بالتأكيد على التكاليف.
- صعوبات الإدارة
تعد إدارة مجموعات Kubernetes المتعددة أكثر صعوبة من إدارة مجموعة واحدة.
على سبيل المثال ، سيتعين عليك تكوين المصادقة والترخيص لكل مجموعة. يجب أيضًا إجراء ترقية إصدار Kubernetes عدة مرات.
على الأرجح ، ستحتاج إلى تطبيق الأتمتة لزيادة كفاءة كل هذه المهام.
الآن ضع في اعتبارك السيناريوهات الأقل تطرفًا.
3. مجموعة واحدة لكل تطبيق
باستخدام هذا الأسلوب ، يمكنك إنشاء مجموعة منفصلة لجميع مثيلات تطبيق معين:
الكتلة لكل تطبيق
يمكن اعتبار هذه الطريقة بمثابة تعميم للمبدأ "مجموعة منفصلة لكل فريق"لأنه عادةً ما يشارك فريق من المهندسين في تطوير تطبيق واحد أو أكثر.
دعونا نلقي نظرة على إيجابيات وسلبيات هذا النهج.
+ يمكن تخصيص الكتلة للتطبيق
إذا كان لتطبيق ما احتياجات خاصة ، فيمكن تنفيذها في كتلة دون التأثير على الكتل الأخرى.
قد تشمل هذه الاحتياجات عمال GPU ، أو بعض المكونات الإضافية لـ CNI ، أو شبكة خدمة ، أو بعض الخدمات الأخرى.
يمكن تخصيص كل مجموعة للتطبيق الذي يتم تشغيله عليها لتحتوي فقط على ما هو مطلوب.
- بيئات مختلفة في مجموعة واحدة
عيب هذا الأسلوب هو أن مثيلات التطبيق من بيئات مختلفة تتعايش في نفس المجموعة.
على سبيل المثال ، يعمل إصدار prod للتطبيق على نفس المجموعة مثل إصدار dev. هذا يعني أيضًا أن المطورين يعملون في نفس المجموعة مثل إصدار الإنتاج من التطبيق.
إذا فشلت المجموعة بسبب تصرفات المطورين أو مواطن الخلل في إصدار المطورين ، فمن المحتمل أن تعاني نسخة prod أيضًا - وهو عيب كبير في هذا النهج.
وأخيرًا ، السيناريو الأخير في قائمتنا.
4. مجموعة واحدة لكل بيئة
يوفر هذا السيناريو تخصيص مجموعة منفصلة لكل بيئة:
مجموعة واحدة لكل بيئة
على سبيل المثال ، قد يكون لديك مجموعات ديف, تجربه بالعربي и همز، حيث ستقوم بتشغيل جميع مثيلات التطبيق المخصصة لبيئة معينة.
فيما يلي إيجابيات وسلبيات هذا النهج.
+ عزل البيئة المنتجة
ضمن هذا النهج ، يتم عزل جميع البيئات عن بعضها البعض. ومع ذلك ، في الممارسة العملية ، هذا مهم بشكل خاص لبيئة prod.
أصبحت إصدارات الإنتاج من التطبيق الآن مستقلة عما يحدث في البيئات والمجموعات الأخرى.
وبالتالي ، إذا ظهرت مشكلة فجأة في مجموعة dev ، فستستمر إصدارات prod من التطبيقات في العمل كما لو لم يحدث شيء.
+ يمكن تعديل الكتلة مع البيئة
يمكن تصميم كل مجموعة مع بيئتها. على سبيل المثال ، يمكنك:
- تثبيت أدوات التطوير والتصحيح في مجموعة dev ؛
- تثبيت أطر وأدوات الاختبار على الكتلة تجربه بالعربي;
- استخدام روابط أجهزة وشبكات أكثر قوة في المجموعة همز.
هذا يحسن كفاءة تطوير التطبيقات وتشغيلها.
+ تقييد الوصول إلى كتلة الإنتاج
غالبًا ما لا تظهر الحاجة إلى العمل بشكل مباشر مع مجموعة prod ، لذلك يمكنك بشكل كبير تقييد دائرة الأشخاص الذين يمكنهم الوصول إليها.
يمكنك الذهاب إلى أبعد من ذلك وحرمان الأشخاص تمامًا من الوصول إلى هذه المجموعة ، والقيام بجميع عمليات النشر باستخدام أداة CI / CD آلية. مثل هذا النهج سيقلل من مخاطر الأخطاء البشرية حيث يكون ذلك مناسبًا تمامًا.
والآن بضع كلمات عن السلبيات.
- عدم العزل بين التطبيقات
العيب الرئيسي لهذا النهج هو عدم عزل الأجهزة والموارد بين التطبيقات.
تشترك التطبيقات غير ذات الصلة في موارد المجموعة: مركز النظام والمعالج والذاكرة وبعض الخدمات الأخرى.
كما ذكرنا سابقًا ، يمكن أن يكون هذا خطيرًا.
- عدم القدرة على توطين تبعيات التطبيق
إذا كان للتطبيق متطلبات خاصة ، فيجب أن تكون مستوفاة في جميع المجموعات.
على سبيل المثال ، إذا كان التطبيق يحتاج إلى GPU ، فيجب أن تحتوي كل مجموعة على عامل واحد على الأقل مع GPU (حتى لو تم استخدامه بواسطة هذا التطبيق فقط).
نتيجة لذلك ، فإننا نخاطر بتكاليف أعلى واستخدام غير فعال للموارد.
اختتام
إذا كان لديك مجموعة معينة من التطبيقات ، فيمكن وضعها في عدة مجموعات كبيرة أو في العديد من المجموعات الصغيرة.
يناقش المقال إيجابيات وسلبيات الأساليب المختلفة ، بدءًا من مجموعة عالمية واحدة إلى عدة مجموعات صغيرة ومتخصصة للغاية:
- مجموعة مشتركة كبيرة واحدة ؛
- العديد من التجمعات الصغيرة المتخصصة للغاية ؛
- مجموعة واحدة لكل تطبيق ؛
- مجموعة واحدة لكل بيئة.
إذن ما هو النهج الذي يجب أن تختاره؟
كالعادة ، تعتمد الإجابة على حالة الاستخدام: تحتاج إلى الموازنة بين إيجابيات وسلبيات الأساليب المختلفة واختيار الخيار الأفضل.
ومع ذلك ، لا يقتصر الاختيار على الأمثلة المذكورة أعلاه - يمكنك استخدام أي مزيج منها!
على سبيل المثال ، يمكنك تنظيم زوج من المجموعات لكل فريق: مجموعة للتطوير (والتي سيكون لها بيئات ديف и تجربه بالعربي) ومجموعة ل إنتاج (حيث ستكون بيئة الإنتاج).
بناءً على المعلومات الواردة في هذه المقالة ، ستتمكن من تحسين الإيجابيات والسلبيات وفقًا لسيناريو محدد. حظ سعيد!
PS
اقرأ أيضًا على مدونتنا:
- «"؛
- «"؛
- «"؛
- «".
المصدر: www.habr.com