🧞 🐧 🕜 تصميم مجموعات Kubernetes: كم يجب أن يكون هناك؟ 👨🏾‍🎤 👩🏾‍💻 🔖

ملحوظة perev. : هذه المادة من المشروع التعليمي learnk8s هي إجابة لسؤال شائع عند تصميم البنية التحتية على أساس Kubernetes. نأمل أن تساعد الأوصاف التفصيلية بما فيه الكفاية لإيجابيات وسلبيات كل خيار على اتخاذ أفضل خيار لمشروعك.

TL ؛ DR : يمكن تشغيل نفس مجموعة أحمال العمل على عدة مجموعات كبيرة (سيكون لكل مجموعة عدد كبير من أحمال العمل) أو على العديد من الأحجام الصغيرة (مع عدد صغير من الأحمال في كل مجموعة).

يلخص الجدول أدناه إيجابيات وسلبيات كل نهج:

عند استخدام Kubernetes كمنصة لتشغيل التطبيقات ، غالبًا ما تنشأ العديد من الأسئلة الأساسية حول تعقيدات تكوين الكتلة:

كم عدد الكتل لاستخدام؟
ما حجمها؟
ماذا يجب أن يشمل كل عنقود؟

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

بيان سؤال

بصفتك منشئ برامج ، من المحتمل أن تقوم بتطوير وتشغيل العديد من التطبيقات بالتوازي.

وبالإضافة إلى ذلك، هي حالات كثيرة من هذه التطبيقات عرضة للتشغيل في بيئات مختلفة - على سبيل المثال، يمكن أن يكون ديف ، اختبار و همز .

والنتيجة هي مصفوفة كاملة من التطبيقات والبيئات:

التطبيقات والبيئات

في المثال أعلاه ، تم تقديم 3 تطبيقات و 3 بيئات ، مما يعطي في النهاية 9 خيارات ممكنة.

كل مثيل تطبيق هو وحدة نشر مستقلة يمكن تشغيلها بشكل مستقل عن الآخرين.

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

نتيجة لذلك ، لدى مستخدمي Kubernetes عدة أسئلة:

هل يجب علي وضع جميع مثيلات التطبيق في كتلة واحدة؟
هل يجب إنشاء مجموعة منفصلة لكل مثيل من التطبيق؟
أو ربما يجب عليك استخدام مزيج من الأساليب المذكورة أعلاه؟

كل هذه الخيارات قابلة للتطبيق تمامًا ، لأن Kubernetes هو نظام مرن لا يقيد المستخدم في الاحتمالات.

إليك بعض الطرق الممكنة:

كتلة مشتركة واحدة كبيرة ؛
العديد من المجموعات الصغيرة المتخصصة للغاية ؛
كتلة واحدة لكل تطبيق.
عنقود واحد لكل بيئة.

كما هو موضح أدناه ، فإن النهجين الأولين يقعان في طرفي نقيض من مقياس الخيارات:

من عدة مجموعات كبيرة (على اليسار) إلى العديد من المجموعات الصغيرة (على اليمين)

بشكل عام ، تعتبر مجموعة واحدة "أكبر" من الأخرى إذا كانت تحتوي على مجموع أكبر من العقد والقرون. على سبيل المثال ، الكتلة مع 10 عقد و 100 قرون أكبر من كتلة مع عقدة واحدة و 10 قرون.

حسنًا ، لنبدأ!

1. عنقود مشترك واحد كبير

الخيار الأول هو وضع جميع أعباء العمل في مجموعة واحدة: كتلة

واحدة كبيرة

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

Namespace'y Kubernetes بجزء منفصل منطقيًا من المجموعة عن بعضها البعض ، بحيث يمكن استخدام مساحة الاسم الخاصة بها لكل مثيل من التطبيق.

دعونا نلقي نظرة على إيجابيات وسلبيات هذا النهج.

+ الاستخدام الفعال للموارد

في حالة كتلة واحدة ، يلزم نسخة واحدة فقط من جميع الموارد اللازمة لبدء وإدارة مجموعة Kubernetes.

على سبيل المثال ، هذا صحيح بالنسبة للعقد الرئيسية. عادة ما يكون هناك 3 عقد رئيسية لكل عنقود Kubernetes ، لذلك سيظل عددهم لكل عنقود واحد (للمقارنة ، ستحتاج 10 مجموعات إلى 30 عقدة رئيسية).

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

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

+ رخيصة

نتيجة لما سبق ، عادة ما يكون عدد أقل من المجموعات أرخص لأنه لا توجد تكاليف للموارد الزائدة.

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

توفر بعض خدمات Kubernetes المُدارة ، مثل Google Kubernetes Engine (GKE) أو Azure Kubernetes Service (AKS) ، طبقة تحكم مجانًا. في هذه الحالة ، تكون مشكلة التكلفة أقل حدة.

هناك أيضًا خدمات مُدارة تفرض رسومًا ثابتة على كل مجموعة Kubernetes (على سبيل المثال ، Amazon Elastic Kubernetes Service ، EKS ).

+ الإدارة الفعالة

إدارة مجموعة واحدة أسهل من عدة.

قد تتضمن الإدارة المهام التالية:

نسخة محدثة من Kubernetes ؛
تكوين خط أنابيب CI / CD
تركيب البرنامج المساعد CNI ؛
إنشاء نظام مصادقة المستخدم ؛
ضبط تحكم الوصول ؛

وغيرها الكثير ...

في حالة كتلة واحدة ، كل هذا يجب القيام به مرة واحدة فقط.

بالنسبة للعديد من المجموعات ، سيتعين تكرار العمليات عدة مرات ، الأمر الذي سيتطلب على الأرجح بعض أتمتة العمليات والأدوات لضمان عملية منهجية وموحدة.

والآن بضع كلمات عن السلبيات.

- نقطة واحدة من الفشل

في حالة فشل مجموعة واحدة ، ستتوقف جميع أحمال العمل عن العمل على الفور !

هناك الكثير من الخيارات عندما يحدث خطأ ما:

تحديث Kubernetes يؤدي إلى آثار جانبية غير متوقعة ؛
المكون على مستوى المجموعة (على سبيل المثال ، البرنامج المساعد CNI) لا يعمل كما هو متوقع ؛
لم يتم تكوين أحد مكونات نظام المجموعة بشكل صحيح.
فشل في البنية التحتية الأساسية.

يمكن أن تتسبب إحدى هذه الحوادث في أضرار جسيمة لجميع أعباء العمل الموجودة في مجموعة مشتركة.

- عدم وجود عازل صلب

يعني العمل في مجموعة مشتركة أن التطبيقات تشارك الأجهزة وإمكانات الشبكة ونظام التشغيل على عقد الكتلة.

بمعنى ما ، حاويتان مع تطبيقين مختلفين يعملان على نفس المضيف يشبهان عمليتين تعملان على نفس الجهاز الذي يعمل بنفس نواة نظام التشغيل.

توفر حاويات Linux شكلاً من أشكال العزل ، لكنها أبعد ما تكون عن القوة التي توفرها الأجهزة الافتراضية ، على سبيل المثال. في جوهرها ، العملية في الحاوية هي نفس العملية التي تعمل على نظام التشغيل المضيف.

يمكن أن يكون هذا مشكلة أمنية: مثل هذه المنظمة تسمح نظريًا للتطبيقات غير ذات الصلة بالتفاعل مع بعضها البعض (عن قصد أو عن طريق الخطأ).

بالإضافة إلى ذلك ، تشترك جميع أحمال العمل في مجموعة Kubernetes في بعض الخدمات على مستوى المجموعة ، مثل DNS - وهذا يسمح للتطبيقات بالعثور على خدمات التطبيقات الأخرى في المجموعة.

قد يكون لجميع العناصر المذكورة أعلاه معان مختلفة اعتمادًا على متطلبات أمان التطبيق.

توفر Kubernetes أدوات متنوعة لمنع مشاكل الأمان ، مثل PodSecurityPolicies و NetworkPolicies . ومع ذلك ، لتكوينها الصحيح يتطلب بعض الخبرة بالإضافة إلى ذلك ، فهي غير قادرة على إغلاق جميع ثقوب الأمان على الإطلاق.

من المهم أن تتذكر دائمًا أن Kubernetes تم تصميمه في الأصل للمشاركة.وليس للعزلة والأمن .

- عدم وجود تعدد ضيق في الإيجار

نظرًا لوفرة الموارد المشتركة في مجموعة Kubernetes ، هناك العديد من الطرق التي يمكن من خلالها للتطبيقات المختلفة أن "تضرب بعضها البعض".

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

توفر Kubernetes آليات مختلفة للتحكم في مثل هذا السلوك ، مثل طلبات الموارد وحدودها (انظر أيضًا مقالة " حدود وحدة المعالجة المركزية والاختناق الشديد في Kubernetes " - الترجمة تقريبًا) ، ResourceQuotas و LimitRanges . ومع ذلك ، كما هو الحال في الأمن ، فإن تكوينها غير تافه تمامًا ولا يمكنهم منع جميع الآثار الجانبية غير المتوقعة على الإطلاق.

- عدد كبير من المستخدمين

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

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

- لا يمكن أن تنمو العناقيد إلى أجل غير مسمى

من المحتمل أن تكون الكتلة المستخدمة لجميع أعباء العمل كبيرة جدًا (من حيث عدد العقد والقرون).

ولكن هنا تنشأ مشكلة أخرى: لا يمكن أن تنمو التجمعات في Kubernetes إلى أجل غير مسمى.

هناك حد نظري لحجم الكتلة. في Kubernetes ، يبلغ عدد العقد حوالي 5000 عقد و 150 ألف حبة و 300 ألف حاوية .

ومع ذلك ، في الحياة الواقعية ، يمكن أن تبدأ المشاكل في وقت أبكر بكثير - على سبيل المثال ، في 500 عقدة فقط .

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

يتم استكشاف هذه المشكلة في مقالة ذات صلة في المدونة الأصلية بعنوان " مجموعات العنقود المعمارية - اختيار حجم عقدة العامل ".

ولكن دعونا ننظر إلى النهج المعاكس: العديد من العناقيد الصغيرة.

2. العديد من التجمعات الصغيرة المتخصصة

باستخدام هذا الأسلوب ، تستخدم مجموعة منفصلة لكل عنصر تم نشره:

العديد من الكتل الصغيرة

لأغراض هذه المقالة ، يشير العنصر المنشور إلى مثيل تطبيق - على سبيل المثال ، إصدار مطور تطبيق منفصل.

تستخدم هذه الإستراتيجية Kubernetes كوقت تشغيل متخصص لمثيلات التطبيق الفردية.

دعونا نلقي نظرة على إيجابيات وسلبيات هذا النهج.

+ "نصف قطر الانفجار" المحدود

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

+ عزل

لا تشارك أحمال العمل المستضافة على مجموعات فردية الموارد مثل المعالج أو الذاكرة أو نظام التشغيل أو الشبكة أو الخدمات الأخرى.

ونتيجة لذلك ، نحصل على عزلة شديدة بين التطبيقات غير ذات الصلة ، والتي قد تؤثر بشكل إيجابي على أمنها.

+ عدد قليل من المستخدمين

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

وكلما قل عدد الأشخاص الذين يمكنهم الوصول إلى المجموعة ، انخفض خطر "كسر" شيء ما.

دعونا نلقي نظرة على السلبيات.

- الاستخدام غير الفعال للموارد

كما ذكرنا سابقًا ، تتطلب كل مجموعة Kubernetes مجموعة معينة من موارد التحكم: العقد الرئيسية ، ومكونات طبقة التحكم ، وحلول المراقبة والتسجيل.

في حالة وجود عدد كبير من المجموعات الصغيرة ، من الضروري تخصيص حصة أكبر من الموارد للإدارة.

- التكلفة العالية

يؤدي الاستخدام غير الفعال للموارد تلقائيًا إلى ارتفاع التكاليف.

على سبيل المثال ، صيانة 30 عقدة رئيسية بدلاً من ثلاث نقاط لها نفس القدرة الحاسوبية ستؤثر بالضرورة على التكاليف.

- صعوبات إدارية

تعد إدارة مجموعات Kubernetes المتعددة أكثر صعوبة من إدارة واحدة.

على سبيل المثال ، سيتعين عليك تكوين المصادقة والتفويض لكل مجموعة. يجب أيضًا ترقية Kubernetes عدة مرات.

على الأرجح ، سيكون عليك تطبيق الأتمتة لزيادة فعالية كل هذه المهام.

الآن فكر في سيناريوهات أقل تطرفًا.

3. عنقود واحد لكل تطبيق

كجزء من هذا النهج ، يمكنك إنشاء مجموعة منفصلة لجميع مثيلات تطبيق معين:

الكتلة لكل تطبيق

يمكن اعتبار هذه الطريقة بمثابة تعميم لمبدأ " مجموعة منفصلة لكل فريق " ، حيث عادة ما يشارك فريق من المهندسين في تطوير تطبيق واحد أو أكثر.

دعونا نلقي نظرة على إيجابيات وسلبيات هذا النهج.

+ الكتلة يمكن تخصيصها للتطبيق

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

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

يمكن تخصيص كل عنقود للتطبيق الذي يعمل فيه بحيث يحتوي فقط على ما هو مطلوب.

- بيئات مختلفة في عنقود واحد

عيب هذا النهج هو أن مثيلات التطبيق من بيئات مختلفة تتعايش في نفس الكتلة.

على سبيل المثال ، يتم تشغيل إصدار المنتج من التطبيق في نفس المجموعة مثل إصدار dev. وهذا يعني أيضًا أن المطورين يقومون بأنشطتهم في نفس المجموعة التي يتم فيها تشغيل إصدار الإنتاج من التطبيق.

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

وأخيرًا ، آخر نص على قائمتنا.

4. عنقود واحد لكل بيئة

يوفر هذا السيناريو لتخصيص مجموعة منفصلة لكل بيئة:

واحدة العنقودية للبيئة

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

فيما يلي إيجابيات وسلبيات هذا النهج.

+ عزل البيئة همز

في هذا النهج ، يتم عزل جميع البيئات عن بعضها البعض. ومع ذلك ، من الناحية العملية ، هذا مهم بشكل خاص لبيئة الإنتاج.

إصدارات الإنتاج من التطبيق مستقلة الآن عما يحدث في مجموعات وبيئات أخرى.

وبالتالي ، إذا ظهرت مشكلة فجأة في مجموعة dev ، فستستمر إصدارات prod للتطبيقات في العمل كما لو لم يحدث شيء.

+ الكتلة يمكن تعديلها حسب البيئة

يمكن تخصيص كل عنقود لبيئته. على سبيل المثال ، يمكنك:

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

هذا يسمح لك بزيادة كفاءة تطوير التطبيقات وتشغيلها.

+ تقييد الوصول إلى مجموعة الإنتاج

تنشأ الحاجة إلى العمل مع مجموعة إنتاج مباشرة بشكل غير منتظم ، بحيث يمكنك تحديد دائرة الأشخاص الذين يمكنهم الوصول إليها بشكل كبير.

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

والآن بضع كلمات عن السلبيات.

- عدم وجود عزل بين التطبيقات

العيب الرئيسي لهذا النهج هو عدم وجود عزل الأجهزة والموارد بين التطبيقات.

تشترك التطبيقات غير ذات الصلة في موارد المجموعة: قلب النظام والمعالج والذاكرة وبعض الخدمات الأخرى.

كما سبق ذكره ، يمكن أن يكون هذا خطيرًا.

- عدم القدرة على توطين تبعيات التطبيق

إذا كان التطبيق يحتوي على متطلبات خاصة ، فيجب تلبيته في جميع المجموعات.

على سبيل المثال ، إذا كان التطبيق يحتاج إلى GPU ، فيجب أن تحتوي كل مجموعة على عامل واحد على الأقل مع GPU (حتى إذا تم استخدامه من قبل هذا التطبيق فقط).

ونتيجة لذلك ، نواجه خطر ارتفاع التكاليف والاستخدام غير الفعال للموارد.

استنتاج

إذا كان لديك مجموعة محددة من التطبيقات ، يمكنك وضعها في مجموعات كبيرة أو في العديد من المجموعات الصغيرة.

تناقش المقالة إيجابيات وسلبيات المناهج المختلفة ، بدءًا من مجموعة عالمية واحدة وتنتهي بالعديد من المجموعات الصغيرة والمتخصصة للغاية:

كتلة مشتركة واحدة كبيرة ؛
العديد من المجموعات الصغيرة المتخصصة للغاية ؛
كتلة واحدة لكل تطبيق.
عنقود واحد لكل بيئة.

لذا ، أي نهج للاختيار؟

كالعادة ، تعتمد الإجابة على حالة الاستخدام: تحتاج إلى الموازنة بين إيجابيات وسلبيات الطرق المختلفة واختيار الخيار الأمثل.

ومع ذلك ، لا يقتصر الاختيار على الأمثلة المذكورة أعلاه - يمكنك استخدام أي مجموعة منها!

على سبيل المثال، يمكنك تنظيم عدة مجموعات لكل فريق: مجموعة من أجل التنمية (والتي سيكون لها ديف و اختبار بيئات ) ومجموعة ل إنتاج (حيث سوف يكون موجودا في بيئة الإنتاج).

استنادًا إلى المعلومات الواردة في هذه المقالة ، يمكنك تحسين الإيجابيات والسلبيات وفقًا لسيناريو محدد. حظا طيبا وفقك الله

تصميم مجموعات Kubernetes: كم يجب أن يكون هناك؟