لماذا يعتبر APISIX Ingress Controller أفضل من NGINX Ingress Controller؟

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

في هذه المقالة، سنقارن بين وحدتي تحكم Ingress شائعتين لإعطاء القراء رؤى حول اختيار وحدات تحكم Ingress.

• Ingress-NGINX هي وحدة تحكم Ingress تم تنفيذها من قبل مجتمع Kubernetes وتستخدم على نطاق واسع في المجتمع.
• وحدة تحكم APISIX Ingress تأخذ Apache APISIX، وهو مشروع مفتوح المصدر تحت ASF (مؤسسة Apache للبرمجيات)، كطائرة بيانات لها.

مقارنة بين Ingress NGINX و APISIX Ingress

مقارنة الميزات

يُقارن الجدول أدناه الميزات الأساسية لـ Ingress NGINX و APISIX Ingress، بما في ذلك البروتوكولات، التحقيق/المرونة في المصادر العليا، استراتيجيات موازنة الحمل، المصادقة، التكامل مع Kubernetes، إلخ. تم استخراج الجدول من learnk8s.io.

الاختلافات

يمكننا أن نرى من الشكل أدناه أن هناك وظائف وميزات مدمجة أكثر في APISIX Ingress مقارنة بـ Ingress NGINX، بما في ذلك دعم البروتوكولات، فحوصات الصحة وقواطع الدائرة، المصادقة، التكامل مع Kubernetes، وما إلى ذلك.

اكتشاف الخدمة

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

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

بينما يدعم كل من Ingress بروتوكول HTTP/HTTPS، فإن APISIX يدعم المزيد من البروتوكولات. فهو يدعم TLS لتشفير حركة TCP. كما يدعم أيضًا MQTT، Dubbo، و kafka للوكالة.

التحقيق/المرونة في المصادر العليا

فحوصات الصحة

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

لا يتم دعم وظيفة فحص الصحة بعد في Ingress NGINX، ولكن APISIX Ingress يوفر هذه الوظيفة:

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

مثال على تكوين APISIX Ingress لفحوصات الصحة لخدمة httpbin:

apiVersion: apisix.apache.org/v2
kind: ApisixUpstream
metadata:
  name: httpbin
spec:
  healthCheck:
    passive:
      unhealthy:
        httpCodes:
          - 500
        httpFailures: 3
    active:
      type: http
      httpPath: /healthz
      healthy:
        successes: 3
        interval: 2s
        httpCodes:
          - 200

قاطع الدائرة

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

على غرار ميزة فحص الصحة، لا يتم دعم ميزة قطع الخدمة في Ingress NGINX. في APISIX Ingress، يساعد api-breaker على تنفيذ ذلك.

مثال على تكوين قاطع الدائرة في APISIX Ingress:

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
 name: httpbin-route
spec:
 http:
 - name: rule1
   match:
     hosts:
     - httpbin.org
     paths:
       - /status/*
   backends:
   - serviceName: httpbin
     servicePort: 80
   plugins:
   - name: api-breaker
     enable: true
     config:
       break_response_code: 502
       unhealthy:
         http_statuses:
         - 505
         failures: 2
       healthy:
         http_statuses:
         - 200
         successes: 2

دعم المزيد من الإضافات وطرق المصادقة

يستخدم Ingress NGINX بشكل رئيسي التعليقات التوضيحية و ConfigMap للتكوين، والإضافات المدعومة محدودة نسبيًا. إذا كنت ترغب في استخدام JWT، HAMC، أو طرق مصادقة أخرى، يجب عليك دمجها بنفسك.

يدعم APISIX Ingress 80+ إضافة في APISIX بشكل أصلي، والتي تدعم طرق مصادقة متعددة مثل JWT، HAMC، wolf-rbac، إلخ. توفر هذه الإضافات مجموعة واسعة من الوظائف التي تغطي معظم سيناريوهات الاستخدام.

مثال على مصادقة HMAC في مسار APISIX:

apiVersion: apisix.apache.org/v2
kind: ApisixConsumer
metadata:
  name: hmac-value
spec:
  authParameter:
    hmacAuth:
      value:
        access_key: papa
        secret_key: fatpa
        algorithm: "hmac-sha256"
        clock_skew: 0
---

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
 name: httpbin-route
spec:
 http:
 - name: rule1
   match:
     hosts:
     - httpbin.org
     paths:
       - /ip
   backends:
   - serviceName: httpbin
     servicePort: 80
   authentication:
     enable: true
     type: hmacAuth

قابلية التوسع لـ Ingress NGINX و APISIX Ingress

عندما لا تستطيع الميزات الأساسية لوحدة تحكم Ingress تلبية احتياجات مستخدمي المؤسسات، يمكن فقط تخصيصها من خلال التوسع. سنشرح الآن كيفية توسيع Ingress NGINX و APISIX Ingress لميزاتهما.

كيفية توسيع Ingress NGINX لميزاته

يمكن فقط توسيع Ingress NGINX من خلال تضمين برامج Lua.

مثال على تطوير إضافة Ingress NGINX:

1. كتابة برنامج Lua مثال-plugin
2. تثبيت الإضافة في /etc/nginx/lua/plugins/<اسم الإضافة الخاصة بك> $\rightarrow$ /etc/nginx/lua/plugins/example-plugin في pod ingress-nginx
3. تمكين example-plugin في ConfigMap، والرجوع إلى هذا الكائن ConfigMap عند تثبيت Ingress NGINX

apiVersion: v1
kind: ConfigMap
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
data:
  plugins: "example-plugin"

كيفية توسيع APISIX Ingress لميزاته

يوفر APISIX Ingress طرقًا متنوعة لتوسيع الميزات، ويمكن لمستخدمي المؤسسات اختيار الطريقة بحسب احتياجاتهم. يدعم APISIX:

• تطوير الإضافات عبر Lua: بسيط وبدون خسارة تقريبًا في الأداء
• التطوير عبر plugin-runner: يدعم لغات برمجة مثل JAVA/Python/Go للتطوير، مما يسمح للمستخدمين بتخصيص إضافاتهم دون تعلم لغات جديدة
• الإضافات عبر WASM: أي لغة تدعم بناء WASM يمكن استخدامها لتطوير الإضافات

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

لماذا يدعم APISIX Ingress CustomResourceDefinition (CRD)؟

حاليًا، يدعم APISIX Ingress ثلاثة تكوينات تصريحية: Ingress، CRD، و Gateway API. سنقارن هنا بشكل رئيسي بين Ingress و CRD. وسنشرح Gateway API لاحقًا.

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

• أسهل في الاستخدام لأنها أكثر توافقًا مع تصميم طائرة البيانات
• إعادة استخدام التكوينات لتقليل التكرار
• تحسين الوظائف والقابلية للتوسع
• طائرة البيانات لـ APISIX لديها مجتمع نشط، مع تحديثات وإصدارات سريعة، ويمكن لـ CRD دعم المزيد من قدرات طائرة البيانات بسهولة

نقطة ألم Ingress NGINX: عدم دعم إعادة التحميل الساخنة

المشاكل الناجمة عن التكوين الثابت

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

الحالات التي تسبب إعادة تحميل NGINX

• إنشاء مورد Ingress جديد
• إضافة قسم TLS إلى Ingress موجود
• تغيير التعليقات التوضيحية لـ Ingress قد يؤثر أيضًا على تكوين المصدر العلوي (على سبيل المثال، التعليقات التوضيحية لموازنة الحمل لا تحتاج إلى إعادة تحميل)
• إضافة أو حذف مسار في Ingress
• حذف Ingress، Service، أو موارد Secret
• تحديث Secret

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

يحدد هيكل Ingress NGINX أنه يجب أولاً إنشاء تكوين NGINX وإعادة التحميل لإكمال تحديث التكوين. لا يمكن حل مشكلة إعادة التحميل دون تعديل الهيكل. لحل هذه المشكلة، لم يعد APISIX Ingress يعتمد على تكوين NGINX في تنفيذ التوجيه وتم تغييره إلى هيكل ذاكرة خالص. يتم تحقيق التوجيه الديناميكي من خلال إعادة التحميل الساخنة، ولم يعد هناك حاجة لإعادة تشغيل NGINX.

واجهة برمجة التطبيقات Gateway

مزايا واجهة برمجة التطبيقات Gateway في Kubernetes

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

• موجهة نحو الأدوار: تتكون Gateway من موارد API. تمثل موارد API المختلفة أدوارًا مختلفة لاستخدام وتكوين موارد شبكة Kubernetes

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

• قابلة للتوسع: تسمح واجهة برمجة التطبيقات Gateway بربط موارد مختلفة في طبقات API مختلفة. هذا يتيح التخصيص الدقيق داخل هيكل API

حالة دعم واجهة برمجة التطبيقات Gateway

واجهة برمجة التطبيقات Gateway في Kubernetes هي معيار لتوسيع شبكة خدمات Kubernetes. يمكن استخدام مورد Gateway كواجهة برمجة تطبيقات Kubernetes لإدارة دورة حياة البوابة، وهو قوي جدًا. العديد من وحدات تحكم Ingress تدعمها بنشاط، بما في ذلك Istio، Kong، Traefik، إلخ. لسوء الحظ، لا تخطط Ingress NGXIN لدعم واجهة برمجة التطبيقات Gateway بعد (حالة تنفيذ واجهة برمجة التطبيقات Gateway)، بينما يدعم APISIX Ingress بالفعل معظم ميزات واجهة برمجة التطبيقات Gateway: بما في ذلك HTTPRoute، TCPRoute، TLSRoute، UDPRoute، إلخ.

الخلاصة

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

يتميز Ingress NGINX ببساطته وسهولة استخدامه، مع بعض العيوب الواضحة، مثل صعوبة توسيع الميزات. APISIX Ingress، الذي انضم لاحقًا، حل مشكلة إعادة التحميل الساخنة لـ NGINX ووفر قابلية توسع ووظائف أفضل. على سبيل المثال، دعم واجهة برمجة التطبيقات Gateway و CRD يثري قدرات وحدة تحكم Ingress من حيث تطوير المشروع.

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