لماذا يعتبر APISIX Ingress Controller خيارًا أفضل من Emissary-ingress؟
Xin Rong
March 17, 2023
معلومات أساسية
Kubernetes Ingress هو كائن API يُستخدم لتحديد قواعد توجيه حركة المرور الخارجية إلى الخدمات الداخلية في الكتلة. عادةً ما يتم استخدام Ingress Controller لتنفيذ منطق مورد Ingress وإدارة قواعد حركة المرور هذه بشكل مركزي.
في الممارسة العملية، يحتاج مستخدمو المؤسسات عادةً إلى وظائف إدارة حركة المرور مثل mTLS، إعادة المحاولة، تحديد معدل الحركة، والمصادقة، والتي لا يمكن لمفاهيم مورد Ingress تحقيقها. لذلك، تقوم تطبيقات Ingress Controller عادةً بتوسيع الوظائف عن طريق إضافة CRDs إضافية. فيما يلي مقارنة مفصلة للاختلافات بين تطبيقات APISIX Ingress Controller وEmissary-Ingress.
ما هو Apache APISIX Ingress Controller
Apache APISIX Ingress Controller هو مشروع مفتوح المصدر تحت ASF (Apache Software Foundation). يقوم مستوى التحكم بتكوين وتسليم الموارد في Kubernetes، بينما يتعامل APISIX مع حركة المرور الفعلية. لتحسين الأمان، تستخدم عملية النشر بأكملها بنية مستوى بيانات ومستوى تحكم منفصلين تمامًا، مما يتجنب بشكل فعال خطر تسريب أذونات كتلة Kubernetes بسبب الهجمات على مستوى البيانات.
ما هو Emissary-Ingress
Emissary-Ingress هو مشروع تحت التطوير في CNCF (Cloud Native Computing Foundation). كمستوى تحكم لوكيل Envoy، فهو مسؤول عن تحليل موارد Kubernetes، ويتم معالجة جميع حركة المرور مباشرة بواسطة Envoy على مستوى البيانات. عن طريق تجميع مستوى التحكم ومستوى البيانات في حاوية واحدة، يصبح الوصول والنشر أسهل.
الفرق بين APISIX Ingress Controller وEmissary-Ingress
بالإضافة إلى دعم موارد Ingress، يمكن لكل من APISIX Ingress Controller وEmissary-Ingress دعم التكوين من خلال CRDs وGateway API لتكملة قيود مفاهيم Ingress.
ستقوم الأقسام التالية بتحليل الاختلافات والمزايا بين الاثنين من حيث الوظائف الأساسية، اكتشاف الخدمة، والقابلية للتوسع.
الوظائف الأساسية
الميزة | APISIX Ingress | Emissary-ingress | |
البروتوكولات | HTTP/HTTPS | ✓ | ✓ |
gRPC | ✓ | ✓ | |
TCP | ✓ | ✓ | |
UDP | ✓ | ✕ | |
Websockets | ✓ | ✓ | |
موازنة الحمل | Round Robin | ✓ | ✓ |
Ring Hash | ✓ | ✓ | |
Least Connections | ✓ | ✓ | |
Maglev | ✕ | ✓ | |
المصادقة | External Auth | ✓ | ✓ |
Basic | ✓ | ✓ | |
JWT | ✓ | ✕ | |
OAuth | ✓ | ✕ | |
OpenID | ✓ | ✕ | |
إدارة حركة المرور | Circuit Breaker | ✓ | ✓ |
Rate Limiting | ✓ | ✓ | |
Canary | ✓ | ✓ | |
Fault Injection | ✓ | ✕ | |
Health Checks | ✓ | ✓ |
تشمل وظائف البوابة الشائعة إدارة حركة المرور، موازنة الحمل، والمصادقة. ومع ذلك، يجب ملاحظة أن دعم Emissary-Ingress للمصادقة محدود نسبيًا، حيث يحتوي فقط على قدرات Basic Auth
وExternal Auth
.
اكتشاف الخدمة
في بنية الخدمات الصغيرة، يتم عادةً تقسيم التطبيقات إلى عدة خدمات صغيرة تعمل معًا لإنجاز منطق الأعمال المحدد. نظرًا لأن عدد حالات الخدمات الصغيرة يتغير باستمرار، هناك حاجة إلى آلية لمساعدة الخدمات على اكتشاف وتحديد موقع بعضها البعض.
يشير اكتشاف الخدمة إلى الطريقة التي يتم بها تحديد موقع الخدمات الصغيرة على الشبكة عن طريق الحصول على معلومات اكتشاف الخدمة من خلال اسم الخدمة لتحديد الحالة التي يتم توجيه الطلب إليها.
بالنسبة لأطر الخدمات الصغيرة التقليدية، غالبًا ما يتم اختيار السجل بناءً على متطلبات الأعمال المحددة. ومع ذلك، فإن نقل مكون اكتشاف وتسجيل الخدمة الحالي إلى آلية اكتشاف خدمة DNS القائمة على Kubernetes يمكن أن يتطلب تكاليف معينة من حيث التعديلات.
من ناحية أخرى، إذا كانت البوابة تدعم مكونات اكتشاف وتسجيل الخدمة الحالية، فلا حاجة لمثل هذه التعديلات، مما يمكن أن يؤدي إلى دعم أفضل لأطر الخدمات الصغيرة.
فيما يلي حالات الدعم للاثنين لمكونات اكتشاف الخدمة:
اكتشاف الخدمة | Apache APISIX Ingress Controller | Emissary-Ingress |
---|---|---|
Kubernetes | ✓ | ✓ |
DNS | ✓ | ✓ |
Nacos | ✓ | ✕ |
Eureka | ✓ | ✕ |
Consul | ✓ | ✓ |
بالنسبة لنظام اكتشاف الخدمة، يتمتع APISIX Ingress Controller بدعم أقوى، ويمكن للمستخدمين بسهولة دمجه في إطار الخدمات الصغيرة الحالي من خلال Ingress controller.
القابلية للتوسع
عندما لا تلبي وظائف Kubernetes Ingress controller متطلبات محددة، يمكن للمستخدمين توسيع وظائفها من خلال التطوير المخصص. يمكن تلبية احتياجات أكثر تخصيصًا عن طريق تطوير إضافات مخصصة أو تعديل الكود الحالي. يمكن لوحدات تحكم Ingress ذات القابلية للتوسع القوية أن تجعل تطوير وتخصيص الميزات أسهل، مما يوفر دعمًا وحلولًا أفضل للسيناريوهات المحددة.
Emissary-Ingress
قابلية توسع Emissary-Ingress محدودة نسبيًا، حيث لا يدعم التوسع من خلال Envoy Filter
المخصص. نظرًا لأن مستوى البيانات ومستوى التحكم متكاملان، فإنه يتطلب تطويرًا مخصصًا للنظام بأكمله. تعقيد التطوير المخصص لمستوى البيانات Envoy
مرتفع ويشكل عبئًا كبيرًا على المطورين.
بالإضافة إلى ذلك، إذا كان المستخدمون بحاجة إلى Emissary-Ingress أكثر قوة، فإنهم بحاجة إلى ترقيته إلى المنتج التجاري لـ Ambassador Edge Stack. تتطلب بعض الميزات الخاصة الدفع للحصول على الدعم.
APISIX Ingress Controller
يقوم مستوى بيانات APISIX بشكل أساسي بتوسيع وظائفه من خلال الإضافات، والتي توفر أكثر من 80 إضافة جاهزة للاستخدام. يدعم APISIX Ingress Controller جميع الإضافات التي يوفرها APISIX، والتي يمكن أن تلبي معظم حالات الاستخدام اليومية.
إذا كانت هناك حاجة للتخصيص بناءً على سيناريوهات الأعمال المحددة، فإن APISIX يقدم خيارات توسع متعددة للمستخدمين للاختيار والجمع بحرية وفقًا لظروفهم. طرق التوسع المدعومة حاليًا هي كما يلي:
- تطوير الإضافات باستخدام لغة Lua بسيط نسبيًا وبدون أي فقدان للأداء تقريبًا. بالإضافة إلى ذلك، يمكنك استخدام إضافة serverless لكتابة كود Lua مباشرة، مما يمكن أن يلبي متطلبات الأعمال بسرعة.
- بالإضافة إلى لغة Lua الأصلية، يمكنك أيضًا استخدام
Plugin Runner
أو إضافاتWASM
للتوسع، والتي تدعم تطوير إضافات مخصصة بلغات برمجة مثل Java، Python، وGo. هذا يمكّن المستخدمين من استخدام منطق الأعمال الحالي والاختيار بناءً على مكدس التكنولوجيا أو تفضيلات التطوير في الشركة دون الحاجة إلى لغة جديدة.
يدعم APISIX Ingress Controller طرق التوسع المذكورة أعلاه بالكامل دون أي تطويرات إضافية.
الأداء
كمكون وكيل لحركة المرور الداخلة لـ Kubernetes، فإنه يدير جميع حركة المرور الواردة إلى المنصة ويدير بشكل موحد قواعد حركة المرور المختلفة، مما يضع متطلبات أعلى على أداء الوكيل.
في هذه المقالة، سنقوم بإجراء اختبارات أداء على APISIX Ingress Controller (APISIX: 3.1.0) وEmissary-Ingress 3.4.0 في نفس الحالة (4C 8G).
QPS
QPS (الاستعلامات في الثانية) يمثل عدد الاستعلامات التي يمكن للخدمة معالجتها في الثانية. كلما كان الرقم أعلى، كان الأداء أفضل.
- 5000 مورد Ingress QPS
زمن الاستجابة
زمن الاستجابة: الوقت الذي يستغرقه الخادم للرد. كلما كان التأخير أصغر، كان الأداء أفضل.
يظهر الرسم البياني أن APISIX Ingress Controller يحافظ على أداء متسق عبر مقاييس الموارد المختلفة، مما يظهر أداءً متوازنًا جيدًا.
من ناحية أخرى، يؤثر Emissary-Ingress بشكل كبير على QPS وزمن الاستجابة عند التعامل مع مقاييس الموارد الكبيرة ومطابقات التوجيه المختلفة، مع انخفاض الأداء مع زيادة عدد الموارد. لذلك، مع نمو حجم الأعمال في بيئات الإنتاج الفعلية، يصبح الأداء العالي لـ APISIX أكثر بروزًا.
الخلاصة
يتميز Emissary-Ingress بالبساطة وسهولة التكامل، ولكنه أكثر صعوبة للتطوير المخصص. علاوة على ذلك، تعتمد متطلبات الميزات الإضافية على المكونات ذات الصلة بالمنصة للحصول على الدعم.
في المقابل، يتمتع APISIX Ingress Controller بمزايا في قابلية التوسع وتكامل اكتشاف الخدمة، مع قابلية توسع قوية وتطوير بسيط. بالإضافة إلى ذلك، يؤدي APISIX Ingress Controller أداءً استثنائيًا، خاصة في السيناريوهات التي يستمر فيها حجم الأعمال في النمو، مما يظهر مزايا كبيرة.