كيف يدعم APISIX Ingress الإضافات المخصصة (Custom Plugins)؟

Ingress و Ingress Controller

Ingress هو أحد كائنات API في Kubernetes. يدير الوصول الخارجي إلى الخدمات في الكتلة، عادةً HTTP/HTTPS.

يمكن للعملاء اتباع قواعد Ingress لتوجيه طلبات العملاء إلى خدمات كتلة Kubernetes أو إلى Pod معين.

فيما يلي مثال على مورد Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: apisix-gateway
spec:
  rules:
    - host: apisix.apache.org
      http:
        paths:
          - backend:
              service:
                name: apisix-gateway
                port:
                  number: 80
            path: /
            pathType: Exact

يحتوي المثال أعلاه على المحتويات التالية:

• metadata.name: اسم مورد Ingress
• spec.rules[].host: النطاق المستخدم للوصول الخارجي
• spec.rules[].http.paths[].backend: يصف المعلومات المتعلقة بالخدمات في الكتلة
• spec.rules[].http.paths[].path: يصف المسارات المستخدمة للوصول الخارجي إلى الخدمات في الكتلة
• spec.rules[].http.paths[].pathType: يصف نوع المسار لإدارة الوصول الخارجي إلى الخدمات في الكتلة

بناءً على المثال أعلاه، يمكننا ملاحظة أن مواصفات مورد Ingress بسيطة نسبيًا.

Ingress هو تعريف مورد في Kubernetes ولا يمكنه التعامل مع أي حركة مرور بنفسه. لذلك، إذا أردنا جعل موارد Ingress فعالة، يجب علينا استخدام وحدة تحكم لمعالجة هذه الموارد، والتي تُعرف باسم Ingress controller.

سيقوم Ingress controller بمراقبة أي تغييرات في الموارد في كتلة Kubernetes وتحويل قواعد موارد Ingress إلى قواعد الوكيل في طبقة البيانات حتى تتمكن طبقة البيانات من التعامل مع حركة المرور.

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

كيف يدعم Ingress-NGINX الامتدادات؟

أولاً، سنستخدم مثالًا لوحدة تحكم Ingress-NGINX في نظام Kubernetes لإظهار كيفية استخدام الامتدادات.

يمكننا استخدام Annotation لوصف الامتدادات المطلوبة لموارد Ingress في Ingress-NGINX. على سبيل المثال:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/enable-cors: "true"
    nginx.ingress.kubernetes.io/cors-allow-origin: https://foo.com,https://bar.com
    nginx.ingress.kubernetes.io/cors-allow-headers: x-foo-1,x-foo-2
    nginx.ingress.kubernetes.io/cors-allow-methods: GET,POST,PUT
  name: nginx-ingress
spec:
  rules:
    - host: kubernetes.github.io
      http:
        paths:
          - path: /ingress
            pathType: Exact
            backend:
              service:
                name: nginx
                port:
                  number: 80

يُمكن التكوين أعلاه من تمكين CORS.

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

تصف الأقسام التالية كيفية استخدام وحدة تحكم Apache APISIX Ingress لتلبية هذه المتطلبات.

استخدام الإضافات في APISIX Ingress

Apache APISIX Ingress يستخدم الإضافات لتلبية متطلبات العملاء المختلفة للتعامل مع حركة المرور وأي سيناريوهات محددة. حاليًا، هناك أكثر من 80 إضافة جاهزة للاستخدام، ويمكن للمستخدمين تطوير إضافات مخصصة لدعم ميزات جديدة.

هناك العديد من الطرق المختلفة لتطوير الإضافات المخصصة:

• يمكن للمستخدمين استخدام Lua لتطوير الإضافات، ويمكن تشغيل هذه الإضافات داخليًا في APISIX
• يمكن للمستخدمين أيضًا استخدام لغات برمجة أخرى لتطوير الإضافات؛ تُعرف هذه الآلية باسم "plugin runner"، وتُعرف الإضافات المطورة بهذه الآلية باسم "External Plugin"

يرجى الرجوع إلى الوثائق الرسمية حول تطوير الإضافات:

• تطوير الإضافات: https://apisix.apache.org/docs/apisix/plugin-develop/
• تطوير الإضافات الخارجية: https://apisix.apache.org/docs/apisix/external-plugin/

سنقدم ثلاث طرق لتطوير الإضافات باستخدام Lua في APISIX Ingress.

الوضع النقي CRD

تدعم وحدة تحكم APISIX Ingress مواصفات CRD الخاصة بها، ويمكنك تمكين الإضافات مباشرة في قواعد التوجيه (سواء كانت إضافة داخلية أو إضافة مخصصة). على سبيل المثال:

apiVersion: apisix.apache.org/v2beta3
kind: ApisixRoute
metadata:
  name: httpbin-route
spec:
  http:
    - name: rule1
      match:
        hosts:
          - apisix.apache.org
        paths:
          - /apisix-ingress
      backends:
        - serviceName: apisix-gateway
          servicePort: 80
      plugins:
        - name: cors
          enable: true
          config:
            allow_origins: http://foo.bar.org
            allow_methods: "GET,POST"
            max_age: 3600
            expose_headers: x-foo,x-baz
            allow_headers: x-from-ingress
            allow_credential: true

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

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

وضع CRD + Ingress Annotations

يمكننا أيضًا استخدام CRD + Ingress Annotations لتوسيع الميزات في APISIX Ingress، على سبيل المثال:

apiVersion: apisix.apache.org/v2
kind: ApisixPluginConfig
metadata:
  name: cors-plugin
spec:
  plugins:
    - name: cors
      enable: true
      config:
        allow_origins: http://foo.bar.org
        allow_methods: "GET,POST"
        max_age: 3600
        expose_headers: x-foo,x-baz
        allow_headers: x-from-ingress
        allow_credential: true
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: apisix
    k8s.apisix.apache.org/plugin-config-name: cors-plugin
  name: apisix-ingress
spec:
  rules:
    - host: apisix.apache.org
      http:
        paths:
          - path: /apisix-ingress
            pathType: Exact
            backend:
              service:
                name: apisix-gateway
                port:
                  number: 80

باستخدام التكوين أعلاه، يمكننا إنشاء تكوين إضافة مستقل يسمى cors-plugin واستخدام k8s.apisix.apache.org/plugin-config-name: cors-plugin في مورد Ingress للإشارة إليه. التأثير الفعلي هو نفسه تقريبًا للتكوين الأول؛ كلاهما سيفعل إضافة cors للمسارات المقابلة.

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

وضع Ingress Annotations

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: apisix
    k8s.apisix.apache.org/enable-cors: "true"
    k8s.apisix.apache.org/cors-allow-origin: https://foo.com,https://bar.com
    k8s.apisix.apache.org/cors-allow-headers: x-foo-1,x-foo-2
    k8s.apisix.apache.org/cors-allow-methods: GET,POST,PUT
  name: apisix-ingress
spec:
  rules:
    - host: apisix.apache.org
      http:
        paths:
          - path: /apisix-ingress
            pathType: Exact
            backend:
              service:
                name: apisix-gateway
                port:
                  number: 80

سيضيف التكوين أعلاه بعض المعلومات الإضافية المتعلقة بـ CORS إلى مورد Ingress. يمكن لوحدة تحكم APISIX Ingress بعد ذلك التعرف على هذه المعلومات وتحويلها إلى تكوين طبقة البيانات لتوسيع ميزات مورد Ingress.

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

إذا كنت بحاجة إلى إجراء تطويرات مخصصة، يرجى الرجوع إلى الوثائق التالية:

• كيفية استخدام وحدة تحكم APISIX Ingress للتطوير: https://apisix.apache.org/docs/ingress-controller/contribute/

الخلاصة

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