مقارنة بين Kubernetes Gateway و Ingress APIs

قبل بضعة أشهر، تخرج واجهة برمجة تطبيقات Kubernetes Gateway إلى النسخة التجريبية.

لماذا تحتاج إلى واجهة برمجة تطبيقات أخرى للتعامل مع حركة المرور الخارجية عندما لديك واجهة برمجة تطبيقات Kubernetes Ingress API المستقرة وعشرات التنفيذات؟ ما هي المشاكل التي تحلها واجهة برمجة تطبيقات Gateway API الجديدة في واجهة برمجة تطبيقات Ingress؟ هل يعني هذا نهاية واجهة برمجة تطبيقات Ingress؟

سأحاول الإجابة على هذه الأسئلة في هذه المقالة من خلال التعامل العملي مع هذه الواجهات والنظر في كيفية تطورها.

توحيد الوصول الخارجي إلى الخدمات: واجهة برمجة تطبيقات Ingress

تم إنشاء واجهة برمجة تطبيقات Kubernetes Ingress لتوحيد تعريض الخدمات في Kubernetes لحركة المرور الخارجية. تخطت واجهة برمجة تطبيقات Ingress قيود أنواع الخدمات الافتراضية، NodePort وLoadBalancer، من خلال تقديم ميزات مثل التوجيه وإنهاء SSL.

هناك أكثر من 20 تنفيذًا لواجهات تحكم Ingress متاحة. في هذه المقالة، سأستخدم Apache APISIX ووحدة تحكم Ingress الخاصة بها للأمثلة.

يمكنك إنشاء مورد Ingress لتكوين APISIX أو أي تنفيذات أخرى لـ Ingress.

يظهر المثال أدناه كيف يمكنك توجيه حركة المرور بين نسختين من تطبيق باستخدام APISIX Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-routes
spec:
  ingressClassName: apisix
  rules:
    - host: local.navendu.me
      http:
        paths:
          - backend:
              service:
                name: bare-minimum-api-v1
                port:
                  number: 8080
            path: /v1
            pathType: Prefix
          - backend:
              service:
                name: bare-minimum-api-v2
                port:
                  number: 8081
            path: /v2
            pathType: Prefix

نصيحة: يمكنك الاطلاع على هذا البرنامج التعليمي العملي لمعرفة المزيد حول إعداد Ingress على Kubernetes باستخدام وحدة تحكم Apache APISIX Ingress.

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

هذا جيد للتوجيه البسيط. لكن الواجهة محدودة، وإذا كنت ترغب في استخدام جميع الميزات التي توفرها وحدة تحكم Ingress الخاصة بك، فستكون مضطرًا لاستخدام الملاحظات.

على سبيل المثال، لا توفر واجهة برمجة تطبيقات Kubernetes Ingress مخططًا لتكوين إعادة الكتابة. إعادة الكتابة مفيدة عندما يختلف عنوان URL الخاص بالخادم الخلفي عن المسار المكون في قاعدة Ingress.

يدعم APISIX هذه الميزة، وعليك استخدام ملاحظات مخصصة للاستفادة منها:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-routes
  annotations:
    k8s.apisix.apache.org/rewrite-target-regex: "/app/(.*)"
    k8s.apisix.apache.org/rewrite-target-regex-template: "/$1"
spec:
  ingressClassName: apisix
  rules:
    - host: local.navendu.me
      http:
        paths:
          - backend:
              service:
                name: bare-minimum-api
                port:
                  number: 8080
            path: /app
            pathType: Prefix

هذا ينشئ مورد Ingress يقوم بتكوين APISIX لتوجيه أي طلبات تحتوي على البادئة /app إلى الخادم الخلفي مع إزالة البادئة. على سبيل المثال، سيتم توجيه طلب /app/version إلى /version.

الملاحظات خاصة باختيارك لوحدة تحكم Ingress. هذه "الامتدادات الخاصة" قلصت نطاق قابلية النقل التي كانت مقصودة في البداية مع واجهة برمجة تطبيقات Ingress.

موارد CRDs المخصصة > واجهة برمجة تطبيقات Ingress

التقييد بالملاحظات يضحي أيضًا بقابلية استخدام وحدات تحكم Ingress.

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

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: api-routes
spec:
  http:
    - name: route-1
      match:
        hosts:
          - local.navendu.me
        paths:
          - /v1
      backends:
        - serviceName: bare-minimum-api-v1
          servicePort: 8080
    - name: route-2
      match:
        hosts:
          - local.navendu.me
        paths:
          - /v2
      backends:
        - serviceName: bare-minimum-api-v2
          servicePort: 8081

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

توسيع Ingress والتطور إلى واجهة برمجة تطبيقات Gateway

لم تكن واجهة برمجة تطبيقات Ingress معطلة؛ كانت محدودة. تم تصميم واجهة برمجة تطبيقات Gateway للتغلب على هذه القيود.

(واجهة برمجة تطبيقات Gateway) تهدف إلى تطوير شبكة خدمات Kubernetes من خلال واجهات تعبيرية وقابلة للتوسيع وموجهة نحو الأدوار ...

تستلهم من موارد CRDs المخصصة لوحدات تحكم Ingress المختلفة المذكورة سابقًا.

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

تقسيم حركة المرور باستخدام مورد APISIX Ingress (انظر مرجع ApisixRoute/v2):

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: traffic-split
spec:
  http:
    - name: rule-1
      match:
        hosts:
          - local.navendu.me
        paths:
          - /get*
      backends:
        - serviceName: bare-minimum-api-v1
          servicePort: 8080
          weight: 90
        - serviceName: bare-minimum-api-v2
          servicePort: 8081
          weight: 10

تقسيم حركة المرور باستخدام واجهة برمجة تطبيقات Gateway (انظر تدحرج حركة المرور Canary):

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: traffic-split
spec:
  hostnames:
  - local.navendu.me
  rules:
  - backendRefs:
    - name: bare-minimum-api-v1
      port: 8080
      weight: 90
    - name: bare-minimum-api-v2
      port: 8081
      weight: 10

تحسين آخر من واجهة برمجة تطبيقات Ingress هو كيفية فصل الاهتمامات في واجهة برمجة تطبيقات Gateway. مع Ingress، يعمل مطور التطبيق ومدير الكتلة على نفس كائن Ingress، دون إدراك مسؤوليات الآخر، مما يفتح الباب أمام التكوينات الخاطئة.

تفصل واجهة برمجة تطبيقات Gateway التكوينات إلى كائنات Route وGateway، مما يوفر استقلالية لمطور التطبيق ومدير الكتلة. يوضح الرسم البياني أدناه هذا بوضوح:

هل هذه نهاية واجهة برمجة تطبيقات Ingress؟

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

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

مع كون واجهة برمجة تطبيقات Gateway مجموعة شاملة لواجهة برمجة تطبيقات Ingress، قد يكون من المنطقي توحيد الاثنين. بفضل مجتمع SIG Network، لا تزال واجهة برمجة تطبيقات Gateway تنمو وستكون قريبًا جاهزة للإنتاج.

معظم وحدات تحكم Ingress وشبكات الخدمات قد نفذت بالفعل واجهة برمجة تطبيقات Gateway إلى جانب واجهة برمجة تطبيقات Ingress، ومع تطور المشروع، ستظهر المزيد من التنفيذات.

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