لماذا تختار AISpeech Apache APISIX بدلاً من NGINX كـ k8s Ingress Controller

مقدمة

مرحبًا بالجميع، أنا جين وي من شركة AISpeech، وهي شركة تقنية عالية التخصص في مجال التعرف على الكلام وتحليله باستخدام الحاسوب، وأنا هنا لأتحدث عن تكامل Apache APISIX مع K8s بدلاً من استخدام ingress الأصلي.

في وقت كتابة هذا المقال، تم بالفعل تطبيق Apache APISIX في بيئة الإنتاج الخاصة بنا وتولى جزءًا من حركة المرور الداخلة للأعمال. نحن ننقل تدريجيًا حركة المرور من ingress الأصلي، كما هو موضح في الشكل أدناه.

في الواقع، يقوم APISIX-ingress-controller بتسجيل عنوان IP الخاص بالـ pod إلى العقدة upstream، مما يسمح لحركة المرور الأعمال بالوصول إلى الـ pod مباشرة وتجاوز نظام DNS الخاص بـ Kubernetes. يمكنك تنفيذ بعض سياسات موازنة التحميل الخاصة عبر الإضافات بناءً على ذلك. لذلك، من ناحية، نعتمد على قدرة التوجيه الديناميكية لـ Apache APISIX لتوزيع حركة المرور. ومن ناحية أخرى، نضيف بعض الإضافات المخصصة لتلبية احتياجات الأعمال.

من الرسم التخطيطي أعلاه، يبدو أن APISIX-ingress-controller يتكرر مع ingress الأصلي. في هذا المقال، سنشرح بإيجاز سبب تخلينا عن ingress الأصلي وبناء وحدة تحكم ingress خاصة بنا بناءً على Apache APISIX.

ما هو Ingress

باختصار، Ingress هو طريقة لـ Kubernetes للتعامل مع حركة المرور الخارجية.

المشكلة التي يحلها Ingress

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

يحتوي Kubernetes على طرق متنوعة (NodePort، LoadBalancer، Ingress، ...) لفضح الواجهات للوصول إلى الخدمات الداخلية لـ Kubernetes. بالمقارنة، يعتبر Ingress بالتأكيد طريقة أكثر اقتصادية لتحقيق الوكيل العكسي عن طريق فضح عدد محدود من عناوين IP العامة.

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

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

مشاكل وحدة تحكم ingress الأصلية لـ Kubernetes

تساعدنا وحدة تحكم ingress لـ NGINX في الحفاظ على مزامنة الحالة بين مجموعة Kubernetes و NGINX، وتوفر قدرات الوكيل العكسي الأساسية، فلماذا نبني ingress خاص بنا؟ نتوقع المزيد من وحدة تحكم ingress لتلبية المزيد من احتياجات الأعمال.

بعد استخدام وحدة تحكم ingress الأصلية لـ Kubernetes، وجدنا أن المشكلات التالية بارزة:

1. مشكلة إعادة التحميل

   تم تصميم ingress الأصلي لـ Kubernetes لتمرير ملفات تكوين YAML إلى وحدة تحكم ingress، وتحويلها إلى ملفات تكوين NGINX، ثم تشغيل إعادة التحميل لجعل التكوين ساري المفعول.

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

   في المقابل، يدعم Apache APISIX إعادة التحميل الساخن للتكوينات، لذا يمكنك تعريف وتعديل المسارات في أي وقت دون تشغيل إعادة تحميل NGINX.

2. كتابة نصوص وإدخال معلمات في التعليقات التوضيحية

   تدعم وحدة تحكم ingress الأصلية أجزاء النصوص المحددة بواسطة التعليقات التوضيحية في ملف YAML، مما يشعر بأنه حل مؤقت لدعم الميزات المتقدمة وهو، بصراحة، غير قابل للإدارة حقًا. يسبب العدد الكبير من نصوص التعليقات التوضيحية مشاكل لموظفي DevOps.

   في Apache APISIX، يمكننا كتابة المنطق عبر كود الإضافات لفضح واجهة تكوين بسيطة تسهل صيانة التكوين وتجنب تداخل النصوص مع موظفي DevOps.

3. عدم دعم موازنة التحميل ذات الحالة

   لا يتم دعم سياسات موازنة التحميل المتقدمة، مثل "استمرارية الجلسة"، إلخ. Kubernetes هو نظام إدارة تطبيقات حاويات موجه للعمليات، وقد يكون له علاقة بحقيقة أن Kubernetes يعزز نهج نشر بدون حالة، لذا لن يدعم Kubernetes رسميًا سياسات موازنة التحميل هذه المتناقضة في المستقبل القريب. في الواقع، حاولت Google بالفعل معالجة هذه المشكلات مع حل شبكة الخدمات الخاص بها (Istio). إن بنية Istio مثالية، ولكن على حساب الأداء، والذي قد يتم حله مع mixer v2.

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

4. الأوزان الديناميكية

   غالبًا ما تحتاج خدمات الأعمال إلى التحكم في حركة المرور بنسبة مئوية، مما يصبح مشكلة في Kubernetes.

   على الرغم من أن Kubernetes يدعم IPVS (خادم IP الافتراضي) بعد الإصدار 1.8، إلا أن معلمات بدء "kube-proxy" ولا التعليقات التوضيحية لـ "kube-route" ليست سهلة الاستخدام مثل Apache APISIX، الذي يقوم داخليًا بتجريد الكائنات الرئيسية مثل المسار، الخدمة، المستهلك، upstream، الإضافة، وغيرها. تعديل وزن مثل هذه العمليات مدعوم بشكل طبيعي، ببساطة عن طريق تعديل "وزن العقدة" تحت "upstream".

5. قدرات التوسع غير المرنة

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

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

   يوفر Apache APISIX دعمًا للإضافات للتوسع، وبالإضافة إلى الإضافات الرسمية، يمكنك تخصيص الإضافات لتلبية خصائصك الخاصة.

   هناك أيضًا بعض مشكلات التكوين الناتجة عن ConfigMap و Namespaces، والتي ترتبط بطريقة استخدامنا لها وليست عامة، لذا لن أتطرق إليها هنا.

وحدة تحكم ingress لـ Apache APISIX

نظرًا لقدرات التوجيه والتوسع القوية لـ Apache APISIX، يمكن استخدام Apache APISIX كتنفيذ لـ Ingress لحل نقاط الألم المذكورة أعلاه بسهولة وتوفير خيار إضافي لوحدة تحكم ingress للمجتمع. الرسم التخطيطي الزمني هو كما يلي:

لتنفيذ وحدة تحكم ingress لـ Apache APISIX، نحتاج إلى حل نوعين من المشكلات الأساسية: الأول هو حل المزامنة بين حالة مجموعة Kubernetes و Apache APISIX؛ والثاني هو تعريف الكائنات في Apache APISIX في Kubernetes (CRD).

للتكامل السريع مع Apache APISIX والاستفادة منه، قمنا بإنشاء مشروع وحدة تحكم ingress لـ Apache APISIX (نرحب بمشاركة الجميع)، والذي ينفذ حاليًا النوع الأول من المشكلات الأساسية: مزامنة معلومات pod في Kubernetes إلى upstream في Apache APISIX، مع تنفيذ نسخة احتياطية أساسية لحل مشاكل التوفر العالي الخاصة بها.

نظرًا لأن Kubernetes يستخدم YAML لتحديد حالة المجموعة بشكل تصريحي، نحتاج إلى تعريف CRD (تعريفات الموارد المخصصة) للكائنات (المسار/الخدمة/upstream/الإضافة) في Apache APISIX لدمجها في Kubernetes.

أيضًا، لتسهيل هجرة مستخدمي ingress الحاليين في Kubernetes، سنحاول أن نكون متوافقين مع عناصر تكوين ingress الحالية.

ستكون هذه الميزات هدف جهودنا القادمة، ونرحب بمشاركتكم.