نظرة عامة ومقارنة بين وحدات التحكم في الدخول لـ Kubernetes

نظرة عامة ومقارنة بين وحدات التحكم في الدخول لـ Kubernetes

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

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

معايير

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

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

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

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

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

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

البرمجيات في جوهرها

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

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

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

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

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

عينات المنبع

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

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

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

المصادقة

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

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

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

اشتراك مدفوع

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

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

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

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

وجود التحقق المدمج من رموز الويب JSON للمصادقة والتحقق من صحة المستخدم في التطبيق النهائي.

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

قابلية توسيع القالب بمعنى وجود آليات تسمح لك بإضافة التوجيهات والأعلام الخاصة بك وما إلى ذلك إلى قوالب التكوين القياسية.

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

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

طلب التتبع

القدرة على مراقبة الطلبات وتتبعها وتصحيحها من الدخول إلى خدمات / حواجز محددة ، ومن الناحية المثالية بين الخدمات / البودات أيضًا.

WAF

Поддержка تطبيق جدار الحماية.

تحكم

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

الدخول من Kubernetes

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

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

تدخل بواسطة NGINX Inc.

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

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

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

كونغ انغرس

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

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

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

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

ترافيك

الموقع الإلكتروني: github.com/containous/traefik
الترخيص: MIT

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

HAProxy

الموقع الإلكتروني: github.com/jcmoraisjr/haproxy-ingress
الترخيص: Apache 2.0

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

رحالة

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

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

كونتور

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

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

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

دخول إستيو

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

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

سفير

الموقع الإلكتروني: github.com/datawire/ambassador
الترخيص: Apache 2.0

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

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

إذن ، تتويج المقال هذا الجدول الضخم:

نظرة عامة ومقارنة بين وحدات التحكم في الدخول لـ Kubernetes

يمكن النقر عليه للحصول على عرض أقرب ، وهو متوفر أيضًا بالتنسيق صفائح جوجل.

تلخيص

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

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

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

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

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

PS

اقرأ أيضًا على مدونتنا:

المصدر: www.habr.com

إضافة تعليق