🖖🏾 🏕️ ◾️ "دعونا نستخدم Kubernetes!" لديك الآن 8 مشاكل 🤳🏾 🦐 ⚗️

إذا كنت تستخدم Docker ، يبدو أن الخطوة المنطقية التالية هي التحول إلى Kubernetes ، إنها K8s ، أليس كذلك؟ حسنًا ، افترض. ومع ذلك ، فإن الحلول المصممة لـ 500 مهندس برمجيات في وقت واحد يقومون بتطوير تطبيق واحد تختلف تمامًا عن الحلول لـ 50 شخصًا. وحل فريق من 5 مبرمجين هو قصة أخرى تمامًا.

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

الجميع يحب "الأجزاء المتحركة"

Kubernetes تتحرك وتتغير كثيرًا: المفاهيم والأنظمة الفرعية والعمليات والآلات والتعليمات البرمجية ... وكل هذا يعني الكثير من الصعوبات.

عدة سيارات

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

كود جدا جدا جدا

تتضمن قاعدة كود Kubernetes في بداية مارس 2020 أكثر من 580.000 سطر من التعليمات البرمجية على Go. وهذا مجرد رمز نظيف ، باستثناء التعليقات والأسطر الفارغة وحزم البائعين. تصف المراجعة الأمنية لعام 2019 قاعدة التعليمات البرمجية على النحو التالي:
"إن قاعدة كود Kubernetes لديها مساحة كبيرة للتحسين. إنه كبير ومعقد ، ويحتوي على أقسام كبيرة من التعليمات البرمجية بأقل قدر من التوثيق وعدد كبير من التبعيات ، بما في ذلك الأنظمة التي ليست جزءًا من Kubernetes. أيضا في قاعدة الكود يوجد العديد من حالات إعادة تنفيذ المنطق التي يمكن أن تكون مركزية في دعم المكتبات ، الأمر الذي من شأنه تقليل التعقيد وتبسيط التصحيحات وتقليل تحميل المستندات في مناطق مختلفة من قاعدة الكود ".
لنكون صادقين ، يمكن قول الشيء نفسه عن العديد من المشاريع الكبيرة الأخرى ، ولكن يجب أن يعمل كل هذا الرمز بشكل صحيح إذا كنت لا تريد فشل تطبيقك.

التعقيد المعماري والتشغيلي والتشكيلي والمفاهيمي

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

تتضمن وثائق مفهوم K8s العديد من الأشياء "التعليمية" البحتة ، مثل المقتطف التالي:

In Kubernetes, an EndpointSlice contains references to a set of network endpoints. The EndpointSlice controller automatically creates EndpointSlices for a Kubernetes Service when a selector is specified. These EndpointSlices will include references to any Pods that match the Service selector. EndpointSlices group network endpoints together by unique Service and Port combinations.
By default, EndpointSlices managed by the EndpointSlice controller will have no more than 100 endpoints each. Below this scale, EndpointSlices should map 1:1 with Endpoints and Services and have similar performance.

في الواقع ، أنا أفهم ما يدور حوله هذا ، ولكن انتبه إلى عدد المفاهيم التي تحتاج إلى تعلمها: EndpointSlice ، Service ، selector ، Pod ، Endpoint.

و - نعم ، في معظم الأحيان لن تستخدم كل هذه الميزات. لذلك ، في معظم الأحيان لن تحتاج إلى Kubernetes على الإطلاق.

هنا مقتطف عشوائي آخر:

بشكل افتراضي ، قد يتم توجيه حركة المرور المرسلة إلى ClusterIP أو خدمة NodePort إلى أي عنوان خلفية للخدمة. منذ Kubernetes 1.7 ، كان من الممكن توجيه حركة المرور "الخارجية" إلى Pods التي تعمل على العقدة التي تلقت حركة المرور ، ولكن هذا غير مدعوم لخدمات ClusterIP ، ولم تكن الطوبولوجيا الأكثر تعقيدًا - مثل التوجيه المنطقي - ممكنة. تحل ميزة طوبولوجيا الخدمة ذلك من خلال السماح لمنشئ الخدمة بتحديد سياسة لتوجيه حركة المرور استنادًا إلى تسميات العقدة للعقد الأصلية والوجهة.

إليك ما تقوله مراجعة الأمان حول هذا:

Kubernetes — , . , Kubernetes — , , , .

كلما حصلت على Kubernetes ، كلما أصبحت عملية التطوير العادية أكثر صعوبة: أنت بحاجة إلى كل هذه المفاهيم (Pod ، Deployment ، Service ، إلخ) فقط لجعل التعليمات البرمجية تعمل. وبالتالي ، تحتاج إلى الترويج لنظام K8s كامل ، حتى فقط للاختبار من خلال آلة افتراضية أو حاويات Docker متداخلة.

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

يمكنك حدد أي خيار ، ولكن لن يكون أيًا منهم مثاليًا. أسهل طريقة لعدم استخدام Kubernetes على الإطلاق.

الخدمات الصغيرة (هذه فكرة سيئة)

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

من الصعب تصحيح التطبيقات الموزعة. ستحتاج إلى نوع جديد تمامًا من أدوات التصحيح والتسجيل ، والتي ستظل تمنحك أقل من سجلات تطبيق متجانسة.

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

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

أليست Kubernetes مفيدة على الإطلاق؟

تحجيم

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

يمكنك شراء VMs في السحابة ، وسيكون لديهم ما يصل إلى 416 وحدة معالجة مركزية افتراضية و 8 تيرابايت من ذاكرة الوصول العشوائي ، أي قوة غير جذابة تمامًا. سيكلفك قرشًا جميلًا ، ولكن سيكون من السهل جدًا القيام به.
يمكن تحجيم العديد من تطبيقات الويب البسيطة بطريقة سهلة إلى حد ما مع خدمات مثل Heroku.

من المفترض ، بالطبع ، أن زيادة عدد الأجهزة الافتراضية العاملة ستلعب أيضًا بين يديك:

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

الموثوقية

كلما زادت الأجزاء المتحركة ، زادت احتمالية حدوث خطأ.
يمكن في كثير من الحالات أن تكون قدرات Kubernetes ، التي تم تعزيزها من خلال الموثوقية المتزايدة (الفحوصات الصحية ، النشر المتدرج) ، مضمنة بالفعل أو تنفيذها أسهل بكثير. على سبيل المثال ، يمكن لـ nginx إجراء فحوصات صحية على عمليات العمال ، ويمكنك أيضًا استخدام docker-autoheal أو شيء مشابه لإعادة تشغيل هذه العمليات تلقائيًا.

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

أفضل الممارسات؟

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

ما لم تشعر بالحاجة الملحة لكل هذه التعقيدات ، لديك مجموعة واسعة من الأدوات التي ستحل مشاكلك: Docker Compose لجهاز واحد ، Hashicorp's Nomad for orchestration ، Heroku وأنظمة مماثلة للتحجيم ، وشيء مثل Shakemake لحسابات خطوط الأنابيب.

خاتمة من المحرر

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

"دعونا نستخدم Kubernetes!" لديك الآن 8 مشاكل