APISIX Ingress Controller يتكامل مع Service Discovery

هل اكتشاف الخدمة مطلوب في التطبيقات السحابية الأصلية؟

الخلفية

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

يجب أن تتواصل هذه المكونات بشكل ديناميكي للعمل معًا بشكل جيد. عادةً ما يكون من الضروري إدخال أدوات اكتشاف الخدمة. لقد كتبنا مقالًا سابقًا يقدم اكتشاف الخدمة في الخدمات الصغيرة: ما هو اكتشاف الخدمة في الخدمات الصغيرة - API7.ai.

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

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

في بيئة Kubernetes، تكون الـ pods هي أصغر وحدة قابلة للنشر.

وفي Kubernetes، يكون التواصل بين المكونات أكثر صعوبة لأن عنوان IP الخاص بالـ Pod ليس دائمًا ويتغير غالبًا.

لذلك، من الأهمية بمكان التكيف مع هذه البيئة الديناميكية عند نشر التطبيقات في Kubernetes.

تأخذ Kubernetes هذا المطلب في الاعتبار وتوفر آلية اكتشاف خدمة تعتمد على DNS.

توفر Kubernetes مفهومًا يسمى Service، يشبه الوكيل العكسي. يحتاج العميل فقط إلى استخدام Service، ولا يحتاج إلى معرفة الـ pods المغلقة خلفها.

سيتم تعيين ClusterIP دائم لكل Service. لذا، عندما يتغير عنوان IP الخاص بالـ Pod، يمكن للمكونات الأخرى أن تتعاون من خلال ClusterIP الثابت للـ Service.

في نفس الوقت، ستقوم الخدمة في Kubernetes بتحديث سجل A/AAAA تلقائيًا إلى DNS في الكتلة.

يبدو السجل كالتالي:

my-svc.my-namespace.svc.cluster-domain.example

يمكن للعميل التحليل عبر مساحات الأسماء أو في نفس مساحة الأسماء، مما يسهل بشكل كبير اكتشاف الخدمة بين المكونات.

ومع ذلك، بالنسبة لهندسة الخدمات الصغيرة التقليدية التي ليست في Kubernetes، نستخدم عادةً أدوات اكتشاف الخدمة لتحقيق التعاون بين الخدمات. للتكيف الكامل مع آلية اكتشاف الخدمة المعتمدة على DNS في بيئة Kubernetes، يلزم وجود تكلفة تحويل/هجرة معينة.

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

في ظل هذه المقدمة، ما هي أفضل طريقة لكشف الخدمات التي تم نقلها حديثًا إلى Kubernetes؟

كيف يعمل APISIX Ingress مع اكتشاف الخدمة؟

APISIX Ingress هو تنفيذ لـ Ingress controller في Kubernetes. يستخدم Apache APISIX كـ data plane ويدعم تكوين قواعد الوكيل من خلال Ingress، و CRD المخصصة، و Gateway API. في نفس الوقت، يوفر أيضًا تكاملًا مع أدوات اكتشاف الخدمة، مما يجعل من السهل وكيل الخدمات المسجلة وكشفها للعميل.

سنشرح ذلك بالتفصيل في هذا القسم.

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

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

إحدى القدرات الممتازة هي التكامل مع أدوات اكتشاف الخدمة.

يمكن لـ APISIX التكامل مع أدوات اكتشاف الخدمة التالية:

• Consul
• DNS
• Eureka
• Nacos

فقط أضف التكوين التالي إلى ملف تكوين APISIX (خذ DNS كمثال):

discovery:
   dns:
     servers:
       - "127.0.0.1:8600"          # استخدم العنوان الحقيقي لخادم DNS الخاص بك

بهذه الطريقة، عند تكوين upstream، يمكن لـ APISIX تحليل معلومات عنوان upstream الفعلي بشكل ديناميكي من خلال اكتشاف الخدمة ووكيل الطلب.

كيف يفعل APISIX Ingress ذلك؟

يستخدم APISIX Ingress APISIX كمكون وكيل data plane. عند التكامل الأول لاكتشاف الخدمة، نظرنا في خيارين.

• تكامل control plane: تكوين اكتشاف الخدمة في Ingress controller، وتحليل التكوين، وإرسال النتائج إلى APISIX للوكيل.
• تكامل data plane: تكوين اكتشاف الخدمة على data plane لـ APISIX، ويقوم data plane بتحليل التكوين والوكيل.

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

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

كيفية استخدام APISIX Ingress؟

أولاً، تأكد من تضمين تكوين اكتشاف الخدمة الصحيح في تكوين APISIX. يستخدم DNS كمثال في ما يلي:

discovery:
  dns:
    servers:
      - "10.96.0.10:53"

قم بإنشاء مورد ApisixUpstream، وقم بتعديل التكوين المتعلق بـ discovery وفقًا لسيناريو الاستخدام. على سبيل المثال، يتم تعيين type: dns و serviceName للوكيل هنا:

# httpbin-upstream.yaml
apiVersion: apisix.apache.org/v2
kind: ApisixUpstream
metadata:
  name: httpbin-upstream
spec:
  discovery:
    type: dns
    serviceName: httpbin.default.svc.cluster.local

أخيرًا، قم بإنشاء مورد ApisixRoute الذي يشير upstreams فيه إلى مورد ApisixUpstream الذي تم إنشاؤه للتو:

# httpbin-route.yaml
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: httpbin-route
spec:
  http:
  - name: rule1
    match:
      hosts:
      - local.httpbin.org
      paths:
      - /*
    upstreams:
    - name: httpbin-upstream

بعد إنشاء الموارد المذكورة أعلاه بشكل صحيح، يمكنك الوصول إلى httpbin.default.svc.cluster.local المسجل في DNS من خلال local.httpbin.org.

الفوائد والتوقعات

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

شكرًا للقراءة. ما زلنا في طريقنا لبناء APISIX Ingress لتوفير أفضل تجارب المستخدم!

لمزيد من المعلومات حول بوابة API، يرجى زيارة مدوناتنا أو الاتصال بنا.