نظرة عامة ومقارنة بين أجهزة التحكم في الدخول ل Kubernetes



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

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

معايير


من أجل إجراء مقارنة من حيث المبدأ والحصول على أي نتيجة مفيدة ، تحتاج إلى فهم ليس فقط موضوع الموضوع ، ولكن لديك أيضًا قائمة محددة من المعايير التي ستحدد متجه البحث. دون التظاهر بتحليل جميع الحالات المحتملة لاستخدام Ingress / Kubernetes ، حاولنا تسليط الضوء على أكثر المتطلبات العامة لوحدات التحكم - كن مستعدًا لدراسة جميع تفاصيلك وتفاصيلك في أي حال على حدة.

لكنني سأبدأ بالخصائص التي أصبحت مألوفة جدًا بحيث يتم تنفيذها في جميع القرارات ولا يتم اعتبارها:

  • الاكتشاف الديناميكي للخدمات (اكتشاف الخدمة) ؛
  • إنهاء SSL ؛
  • العمل مع websockets.

الآن عن نقاط المقارنة:

البروتوكولات المدعومة


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

البرمجيات القائمة


هناك العديد من خيارات التطبيق التي تستند إليها وحدة التحكم. شعبية منها هي nginx ، traefik ، haproxy ، مبعوث. في الحالة العامة ، قد لا يؤثر ذلك على طريقة استقبال حركة المرور ونقلها ، ولكن من المفيد دائمًا معرفة الفروق الدقيقة والميزات المحتملة لما هو "تحت الغطاء".

توجيه حركة المرور


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

مساحة الاسم الكتلة


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

عينات لمنبع


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

الخوارزميات المتوازنة


هناك العديد من الخيارات: من الجولة التقليدية إلى تلك الغريبة مثل ملفات تعريف الارتباط rdp ، وكذلك بعض الميزات مثل الجلسات اللزجة .

المصادقة


ما خطط التخويل التي يدعمها جهاز التحكم؟ أساسي ، هضم ، oauth ، المصادقة الخارجية - أعتقد أن هذه الخيارات يجب أن تكون مألوفة. يعد هذا معيارًا مهمًا إذا كنت تستخدم الكثير من الدوائر للمطورين (و / أو فقط الدوائر المغلقة) التي يتم الوصول إليها من خلال Ingress.

توزيع حركة المرور


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

الاشتراك المدفوع


هل هناك خيار مدفوع لوحدة التحكم ، مع وظائف متقدمة و / أو دعم فني؟

واجهة المستخدم الرسومية (Web UI)


هل هناك أي واجهة رسومية للتحكم في تكوين وحدة التحكم؟ بشكل أساسي ، من أجل "سهولة" و / أو بالنسبة لأولئك الذين يحتاجون إلى إجراء بعض التغييرات على تكوين Ingress ، ولكن العمل باستخدام قوالب "غير طبيعية" غير مريح. قد يكون مفيدًا إذا أراد المطورون إجراء أي تجارب على حركة المرور أثناء التنقل.

التحقق من صحة JWT


وجود التحقق JSON المدمج من الرموز على شبكة الإنترنت للحصول على إذن والتحقق من المستخدم من التطبيق النهائي.

ميزات لتخصيص التكوين


امتداد القوالب ، بمعنى وجود آليات لإضافة توجيهاتها أو علاماتها أو ما إلى قوالب التكوين القياسية

آليات حماية DDOS الأساسية


خوارزميات حد معدل بسيطة أو خيارات أكثر تطوراً لتصفية حركة المرور بناءً على العناوين والقوائم البيضاء والبلدان وما إلى ذلك.

طلب تتبع


إمكانيات مراقبة وتتبع وتصحيح طلبات من Ingresss إلى خدمات / قرون محددة ، وبشكل مثالي ، بين خدمات / pods أيضًا.

WAF


دعم لجدار الحماية التطبيق .

دخول المراقبين


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

دخول Kubernetes


الموقع الإلكتروني: github.com/kubernetes/ingress-nginx
الترخيص: أباتشي 2.0

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

دخول من قبل NGINX Inc


الموقع الإلكتروني: github.com/nginxinc/kubernetes-ingress
الترخيص: أباتشي 2.0

المنتج الرسمي لمطوري nginx. لديها نسخة مدفوعة على أساس NGINX Plus . الفكرة الرئيسية هي مستوى عال من الاستقرار والتوافق الخلفي الثابت وعدم وجود أي وحدات غريبة والسرعة المتزايدة المعلنة (مقارنة بوحدة التحكم الرسمية) التي تحققت بسبب رفض لوا.

تم تخفيض النسخة المجانية بشكل كبير ، بما في ذلك حتى عند مقارنتها بوحدة التحكم الرسمية (بسبب نقص وحدات Lua-modules نفسها). مدفوعة في الوقت نفسه لديها وظائف إضافية واسعة إلى حد ما: المقاييس في الوقت الحقيقي ، والتحقق من صحة JWT ، والفحوصات الصحية النشطة ، وأكثر من ذلك. من الميزات المهمة عبر NGINX Ingress الدعم الكامل لحركة مرور TCP / UDP (وفي إصدار المجتمع أيضًا!). الجانب السلبي هو عدم وجود ميزات لتوزيع حركة المرور ، والتي ، مع ذلك ، "لها الأولوية القصوى للمطورين" ، ولكن الأمر يتطلب بعض الوقت للتنفيذ.

كونغ دخول


الموقع الإلكتروني: github.com/Kong/kubernetes-ingress-controller
الترخيص: أباتشي 2.0

تم تطوير المنتج بواسطة شركة كونغ إنك. في نسختين: التجارية والحرة. يعتمد على nginx ، حيث يتم توسيع قدراته بواسطة عدد كبير من الوحدات النمطية في Lua.

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

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

Traefik


الموقع الإلكتروني: github.com/containous/traefik
الترخيص: معهد ماساتشوستس للتكنولوجيا

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

HAProxy


موقع الويب: github.com/jcmoraisjr/haproxy-ingress
الترخيص: أباتشي 2.0

اشتهر HAProxy منذ فترة طويلة بأنه موازن البروكسي والمرور. كجزء من نظام Kubernetes ، يقدم تحديثًا "بسيطًا" للتكوين (بدون فقد حركة المرور) ، واكتشاف خدمة قائمة على DNS ، وتهيئة ديناميكية باستخدام واجهة برمجة التطبيقات. التخصيص الكامل لقالب التكوين عن طريق استبدال CM'a ، وكذلك إمكانية استخدام وظائف مكتبة Sprig فيه ، قد يصبح جذابًا. بشكل عام ، ينصب التركيز الرئيسي للحل على السرعة العالية والتفاؤل والكفاءة في الموارد المستهلكة. ميزة وحدة التحكم هي دعم عدد قياسي من أساليب الموازنة المختلفة.

رحالة


الموقع الإلكتروني: github.com/appscode/voyager
الترخيص: أباتشي 2.0

وحدة التحكم المستندة إلى HAproxy ، والتي يتم وضعها كحل عالمي يدعم قدرات واسعة على عدد كبير من مقدمي الخدمات. تم اقتراح الفرصة لموازنة حركة المرور على L7 و L4 ، ويمكن اعتبار موازنة حركة مرور TCP L4 ككل واحدة من الميزات الرئيسية للحل.

كفاف


الموقع الإلكتروني: github.com/heptio/contour
الترخيص: أباتشي 2.0

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

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

Isstio دخول


الموقع الإلكتروني: istio.io/docs/tasks/traffic-management/ingress
الترخيص: أباتشي 2.0

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

سفير


الموقع الإلكتروني: github.com/datawire/amb Ambassador
الترخيص: أباتشي 2.0

حل آخر يعتمد على المبعوث. لديه نسخة مجانية والتجارية. يتم وضعه على أنه "أصلي تمامًا لـ Kubernetes" ، والذي يجلب ميزات مقابلة (تكامل دقيق مع أساليب وكيانات مجموعة K8s).

جدول المقارنة


لذلك ، ذروة المقال هو هذا الجدول الضخم:



إنه قابل للنقر لعرضه بشكل أكثر تفصيلًا ، وهو متاح أيضًا بتنسيق أوراق Google .

لتلخيص


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

يعد Kubernetes Ingress الكلاسيكي جيدًا لإمكانية الوصول إليه وإثباته ، وهو غني جدًا بالقدرات - بشكل عام ، يجب أن يكون "كافيًا للعيون". ومع ذلك ، إذا كانت هناك متطلبات متزايدة للاستقرار ومستوى من الميزات والتطوير ، فإن الأمر يستحق الانتباه إلى Ingress with NGINX Plus والاشتراك المدفوع. لدى كونغ مجموعة غنية من المكونات الإضافية (وبالتالي ، القدرات التي توفرها لهم) ، وفي النسخة المدفوعة ، يوجد المزيد منها. لديها فرص كافية للعمل كبوابة API ، تكوين حيوي على أساس موارد CRD ، وكذلك خدمات Kubernetes الأساسية.

مع المتطلبات المتزايدة لطرق الموازنة والترخيص ، ألق نظرة على Traefik و HAProxy. هذه هي مشاريع مفتوحة المصدر ، ثبت على مر السنين ، مستقرة جدا وتتطور بنشاط. كانت "كونتور" موجودة منذ عامين ، لكنها لا تزال تبدو صغيرة جدًا ولديها ميزات أساسية فقط تمت إضافتها على رأس "المبعوث". إذا كانت هناك متطلبات لوجود / تضمين WAF قبل التطبيق ، فيجب عليك الانتباه إلى Ingress نفسه من Kubernetes أو HAProxy.

والأغنى في الميزات هي منتجات مبنية على أساس Envoy ، وخاصة Istio. يبدو أنه حل معقد "يمكن أن يفعل أي شيء" ، ومع ذلك ، يعني أيضًا عتبة أعلى بكثير لإدخال التكوين / التشغيل / الإدارة من الحلول الأخرى.

لقد اخترنا ومازلنا نستخدم Kubernetes Ingress ، والذي يغطي 80-90 ٪ من الاحتياجات ، كوحدة تحكم قياسية. انها موثوقة جدا ، وسهلة التكوين ، والتوسع. في الحالة العامة ، في حالة عدم وجود متطلبات محددة ، ينبغي أن يناسب معظم المجموعات / التطبيقات. من نفس المنتجات متعددة الاستخدامات والبسيطة نسبيًا ، يمكن التوصية بشركة Traefik و HAProxy.

PS


اقرأ أيضًا في مدونتنا:

Source: https://habr.com/ru/post/ar447180/


All Articles