Kubernetes Gateway API v1.0: هل يجب عليك التبديل؟

لقد مر أكثر من شهر منذ إصدار Kubernetes Gateway API الإصدار v1.0، مما يشير إلى وصول بعض واجهات برمجة التطبيقات الرئيسية إلى حالة التوفر العام.

لقد كتبت عن Gateway API عندما تخرج إلى مرحلة بيتا العام الماضي، ولكن بعد عام، لا يزال السؤال قائمًا. هل يجب عليك التبديل من Ingress API إلى Gateway API؟

إجابتي من العام الماضي كانت أنه لا يجب عليك ذلك. وكان لدي أسباب قوية.

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

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

مع إصدار v1.0، قد يتغير هذا. أصبحت Gateway API الآن أكثر قدرة، وتقوم أكثر من 20 تنفيذًا باللحاق بسرعة.

لذلك، إذا كنت تبدأ من جديد وتختار بين Ingress وGateway API، أقترح عليك اختيار Gateway API إذا كانت الواجهة والتنفيذ الذي تختاره يدعمان جميع الميزات التي تريدها.

ما الخطأ في Ingress API؟

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

على سبيل المثال، إذا اخترت Nginx Ingress، ستستخدم بعضًا من عشرات التعليقات التوضيحية التي ليست قابلة للنقل إذا قررت التبديل إلى تنفيذ Ingress آخر مثل Apache APISIX.

هذه التعليقات التوضيحية الخاصة بالتنفيذ تكون أيضًا مرهقة للإدارة وتفقد الغرض من إدارة Ingress بطريقة Kubernetes الأصلية.

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

تهدف Gateway API إلى حل هذه المشكلة مرة واحدة وإلى الأبد من خلال توفير عدم التحيز للبائع لـ Ingress API ومرونة CRDs. وهي موضوعة بشكل جيد لتحقيق هذا الهدف.

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

الفوائد الواضحة

التعبيرية، القابلية للتمديد، والتوجه نحو الأدوار هي الأفكار الرئيسية التي شكلت تطوير Gateway API.

على عكس Ingress API، فإن Gateway API هي مجموعة من واجهات برمجة التطبيقات المتعددة (HTTPRoute، Gateway، GatewayClass، إلخ)، كل منها يلبي أدوارًا تنظيمية مختلفة.

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

يسمح هذا التصميم الموجه نحو الأدوار للواجهة للأشخاص المختلفين باستخدام الكتلة مع الحفاظ على التحكم.

Gateway API أيضًا أكثر قدرة بكثير من Ingress API. الميزات التي تتطلب تعليقات توضيحية في Ingress API مدعومة بشكل افتراضي في Gateway API.

امتداد رسمي

على الرغم من أن Gateway API هي واجهة برمجة تطبيقات Kubernetes رسمية، إلا أنها يتم تنفيذها كمجموعة من CRDs.

هذا لا يختلف عن استخدام موارد Kubernetes الافتراضية. ولكن عليك فقط تثبيت هذه CRDs كامتداد رسمي.

هذا يسمح بالتكرار السريع مقارنة بـ Kubernetes، التي تتحرك ببطء نحو الاستقرار طويل الأجل.

هل ستنتشر؟

كما يذكرنا هذا الكوميكس الشهير XKCD بشكل متكرر، تميل المعايير إلى الانتشار.

تم رؤية نسخة من هذا في Ingress وGateway APIs. عادة ما تسير الأمور كالتالي:

1. يظهر معيار لتوحيد مشاريع/معايير مختلفة (Kubernetes Ingress API).
2. يكون للمعيار الموحد قيود يريد المنفذون التغلب عليها (Ingress API كانت محدودة).
3. تتباعد التنفيذات عن المعيار بسبب هذه القيود (CRDs مخصصة، تعليقات توضيحية).
4. كل تنفيذ لديه الآن معيار خاص به (CRDs غير قابلة للنقل، تعليقات توضيحية).
5. يظهر معيار جديد لتوحيد هذه المعايير المختلفة (Kubernetes Gateway API).

من المعقول التفكير في أن Gateway API قد لا تكون النهاية هنا. ولكنني أعتقد أن لديها كل فرصة لتصبح المعيار لتوجيه حركة المرور في Kubernetes.

مرة أخرى، لدي أسباب قوية.

التبني الواسع أمر بالغ الأهمية لمنع انتشار المعايير حيث تكون هناك حوافز أقل للتنفيذات للعمل على معيار مختلف. لدى Gateway API بالفعل أكثر من 25 تنفيذًا.

يمكن للتنفيذ أن يتوافق مع Gateway API على مستويات مختلفة:

1. الأساسي: من المتوقع أن تتوافق جميع التنفيذات مع هذه.
2. الممتد: قد تكون هذه متاحة فقط في بعض التنفيذات ولكنها واجهات برمجة تطبيقات قياسية.
3. خاص بالتنفيذ: خاص بالتنفيذات ولكن يتم إضافتها من خلال نقاط التمديد القياسية.

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

كان مشروع Service Mesh Interface (SMI) محاولة مماثلة لتوحيد تكوين شبكات الخدمة في Kubernetes. ومع ذلك، تلقى المشروع اهتمامًا قليلاً بعد المشاركة الأولية لمشاريع شبكات الخدمة وتلاشى ببطء.

لم يدعم SMI العديد من الميزات المشتركة التي توقعها المستخدمون في شبكة الخدمة. كما أنه لم يتحرك بسرعة كافية لدعم هذه الميزات. في النهاية، تأخرت تنفيذات شبكات الخدمة في التوافق مع SMI (كنت أعمل عن كثب مع SMI تحت CNCF TAG Network في مشروع يبلغ عن توافق SMI).

هذه أسباب عالمية، ولكن المشروع يتم إحياؤه الآن من خلال Gateway API. تهدف مبادرة Gateway API لإدارة وإدارة الشبكة (GAMMA) إلى توسيع Gateway API للعمل مع شبكات الخدمة.

تم دمج مشروع SMI مؤخرًا مع مبادرة GAMMA، وهو أمر ممتاز لـ Gateway API. كما أعلن Istio، الذي لا شك في أنه شبكة الخدمة الأكثر شعبية، أن Gateway API ستكون الواجهة الافتراضية لإدارة Istio في المستقبل. مثل هذه التبني يمنع الانتشار.

دليل الهجرة

يحتوي توثيق Gateway API على دليل شامل حول كيفية هجرة موارد Ingress إلى موارد Gateway. بدلاً من إعادة ذكر ذلك، دعنا نحاول استخدام أداة ingress2gateway لتحويل موارد Ingress إلى موارد Gateway API المقابلة.

يمكنك تنزيل وتثبيت الثنائي لنظام التشغيل الخاص بك مباشرة من صفحة الإصدارات.

لنأخذ مورد Ingress بسيط:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: httpbin-route
spec:
  ingressClassName: apisix
  rules:
    - host: local.httpbin.org
      http:
        paths:
          - backend:
              service:
                name: httpbin
                port:
                  number: 80
            path: /
            pathType: Prefix

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

لتحويله إلى مورد Gateway API، يمكننا تشغيل:

ingress2gateway print --input_file=ingress.yaml

سيكون مورد Gateway API كما يلي:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: httpbin-route
spec:
  hostnames:
  - local.httpbin.org
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: httpbin
      port: 80

بدائل قابلة للتطبيق

هناك بدائل قابلة للتطبيق أخرى لتكوين البوابات في Kubernetes.

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

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

في أي حال، فإن Gateway API موجودة لتبقى.