في الماضي لقد ألقينا نظرة على المكونات الأساسية لخدمة Service Mesh Istio، وتعرفنا على النظام وأجبنا على الأسئلة الرئيسية التي تطرح عادةً عند بدء العمل مع Istio. سننظر في هذا الجزء في كيفية تنظيم عملية جمع معلومات التتبع عبر الشبكة.
أول ما يتبادر إلى ذهن العديد من المطورين ومسؤولي النظام عندما يسمعون عبارة Service Mesh هو التتبع. في الواقع، نقوم بإضافة خادم وكيل خاص لكل عقدة شبكة تمر من خلالها جميع حركة مرور TCP. يبدو أنه أصبح من الممكن الآن إرسال معلومات بسهولة حول جميع تفاعلات الشبكة على الشبكة. لسوء الحظ، في الواقع هناك العديد من الفروق الدقيقة التي يجب أن تؤخذ بعين الاعتبار. دعونا ننظر إليهم.
المفهوم الخاطئ رقم واحد: يمكننا الحصول على بيانات المشي لمسافات طويلة عبر الإنترنت مجانًا.
في الواقع، مجانًا نسبيًا، يمكننا فقط توصيل عقد نظامنا عن طريق الأسهم ومعدل البيانات الذي يمر بين الخدمات (في الواقع، فقط عدد البايتات لكل وحدة زمنية). ومع ذلك، في معظم الحالات، تتواصل خدماتنا عبر نوع ما من بروتوكول طبقة التطبيق، مثل HTTP وgRPC وRedis وما إلى ذلك. وبالطبع، نريد أن نرى معلومات التتبع خصيصًا لهذه البروتوكولات؛ نريد أن نرى معدل الطلب، وليس معدل البيانات. نريد أن نفهم زمن استجابة الطلبات باستخدام البروتوكول الخاص بنا. وأخيرًا، نريد أن نرى المسار الكامل الذي يأخذه الطلب بدءًا من تسجيل الدخول إلى نظامنا وحتى تلقي الرد من المستخدم. هذه المشكلة لم تعد سهلة الحل.
أولاً، دعونا نلقي نظرة على الشكل الذي تبدو عليه امتدادات التتبع من وجهة نظر معمارية في Istio. كما نتذكر من الجزء الأول، لدى Istio مكون منفصل يسمى Mixer لجمع القياس عن بعد. ومع ذلك، في الإصدار الحالي 1.0.*، يتم الإرسال مباشرةً من الخوادم الوكيلة، أي من وكيل المبعوث. يدعم وكيل Envoy إرسال امتدادات التتبع باستخدام بروتوكول zipkin خارج الصندوق. من الممكن توصيل البروتوكولات الأخرى، ولكن فقط من خلال البرنامج المساعد. مع Istio نحصل على الفور على وكيل مبعوث مُجمَّع ومُهيأ، والذي يدعم فقط بروتوكول zipkin. إذا أردنا، على سبيل المثال، استخدام بروتوكول Jaeger وإرسال امتدادات التتبع عبر UDP، فسنحتاج إلى إنشاء صورة الوكيل الخاصة بنا. هناك دعم للمكونات الإضافية المخصصة لـ istio-proxy، لكنه لا يزال في إصدار ألفا. لذلك، إذا أردنا الاستغناء عن عدد كبير من الإعدادات المخصصة، فسيتم تقليل نطاق التقنيات المستخدمة لتخزين واستقبال فترات التتبع. من بين الأنظمة الرئيسية، في الواقع، يمكنك الآن استخدام Zipkin نفسها، أو Jaeger، ولكن أرسل كل شيء هناك باستخدام بروتوكول متوافق مع zipkin (وهو أقل كفاءة بكثير). يتضمن بروتوكول zipkin نفسه إرسال جميع معلومات التتبع إلى هواة الجمع عبر بروتوكول HTTP، وهو أمر مكلف للغاية.
كما قلت من قبل، نريد تتبع البروتوكولات على مستوى التطبيق. وهذا يعني أن الخوادم الوكيلة الموجودة بجانب كل خدمة يجب أن تفهم نوع التفاعل الذي يحدث الآن. افتراضيًا، يقوم Istio بتكوين كافة المنافذ لتكون TCP عادي، مما يعني أنه لن يتم إرسال أي آثار. من أجل إرسال التتبعات، يجب عليك أولاً تمكين هذا الخيار في تكوين الشبكة الرئيسية، والأهم من ذلك، تسمية جميع منافذ كيانات خدمة kubernetes وفقًا للبروتوكول المستخدم في الخدمة. أي على سبيل المثال كالتالي:
apiVersion: v1
kind: Service
metadata:
name: nginx
spec:
ports:
- port: 80
targetPort: 80
name: http
selector:
app: nginxيمكنك أيضًا استخدام أسماء مركبة مثل http-magic (سيرى Istio http ويتعرف على هذا المنفذ كنقطة نهاية http). التنسيق هو: بروتو-إضافي.
لكي لا يتم تصحيح عدد كبير من التكوينات لتحديد البروتوكول، يمكنك استخدام حل بديل قذر: قم بتصحيح المكون التجريبي في الوقت الذي يكون فيه فقط . في النهاية، بالطبع، سيكون من الضروري تغيير هذا المنطق إلى المعيار والتحول إلى اصطلاح التسمية لجميع المنافذ.
لفهم ما إذا كان البروتوكول قد تم تعريفه بشكل صحيح أم لا، يتعين عليك الدخول إلى أي من الحاويات الجانبية باستخدام وكيل المبعوث وتقديم طلب إلى منفذ الإدارة لواجهة المبعوث باستخدام الموقع /config_dump. في التكوين الناتج، تحتاج إلى إلقاء نظرة على مجال تشغيل الخدمة المطلوبة. يتم استخدامه في Istio كمعرف لمكان تقديم الطلب. من أجل تخصيص قيمة هذه المعلمة في Istio (سنراها بعد ذلك في نظام التتبع الخاص بنا)، من الضروري تحديد علامة ServiceCluster في مرحلة إطلاق الحاوية الجانبية. على سبيل المثال، يمكن حسابه على النحو التالي من المتغيرات التي تم الحصول عليها من واجهة برمجة تطبيقات kubernetes الهابطة:
--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')
مثال جيد لفهم كيفية عمل التتبع في المبعوث .
يجب أيضًا تحديد نقطة النهاية نفسها لإرسال امتدادات التتبع في إشارات إطلاق الوكيل المبعوث، على سبيل المثال: --zipkinAddress tracing-collector.tracing:9411
المفهوم الخاطئ الثاني: يمكننا الحصول على آثار كاملة للطلبات من خلال النظام بطريقة غير مكلفة
لسوء الحظ، ليس كذلك. يعتمد تعقيد التنفيذ على كيفية تنفيذ تفاعل الخدمات بالفعل. لماذا هذا؟
الحقيقة هي أنه لكي يتمكن istio-proxy من فهم مراسلات الطلبات الواردة إلى الخدمة مع أولئك الذين يغادرون نفس الخدمة، لا يكفي مجرد اعتراض كل حركة المرور. يجب أن يكون لديك نوع من معرف الاتصال. يستخدم وكيل HTTP Envoy رؤوسًا خاصة، والتي من خلالها يفهم المبعوث الطلب المحدد للخدمة الذي يولد طلبات محددة لخدمات أخرى. قائمة هذه الرؤوس:
- معرف طلب x,
- x-b3-تتبع,
- x-b3-سباند,
- x-b3-parentspanid,
- عينة x-b3,
- أعلام x-b3,
- x-ot-span-context.
إذا كان لديك نقطة واحدة، على سبيل المثال، عميل أساسي، حيث يمكنك إضافة مثل هذا المنطق، فكل شيء على ما يرام، ما عليك سوى الانتظار حتى يتم تحديث هذه المكتبة لجميع العملاء. ولكن إذا كان لديك نظام غير متجانس للغاية ولا يوجد توحيد في الانتقال من خدمة إلى أخرى عبر الشبكة، فمن المرجح أن تكون هذه مشكلة كبيرة. بدون إضافة مثل هذا المنطق، ستكون جميع معلومات التتبع "على مستوى واحد" فقط. وهذا يعني أننا سنتلقى جميع التفاعلات بين الخدمات، لكن لن يتم لصقها في سلاسل مرور واحدة عبر الشبكة.
اختتام
يوفر Istio أداة مناسبة لجمع معلومات التتبع عبر الشبكة، ولكن يجب أن تفهم أنه من أجل التنفيذ، ستحتاج إلى تكييف نظامك ومراعاة ميزات تطبيق Istio. ونتيجة لذلك، يجب حل نقطتين رئيسيتين: تحديد بروتوكول مستوى التطبيق (الذي يجب أن يدعمه وكيل المبعوث) وإعداد إعادة توجيه المعلومات حول اتصال الطلبات بالخدمة من الطلبات الواردة من الخدمة (باستخدام الرؤوس ، في حالة بروتوكول HTTP). عندما يتم حل هذه المشكلات، لدينا أداة قوية تسمح لنا بجمع المعلومات من الشبكة بشفافية، حتى في الأنظمة غير المتجانسة للغاية المكتوبة بالعديد من اللغات والأطر المختلفة.
في المقالة التالية حول Service Mesh، سنلقي نظرة على واحدة من أكبر مشكلات Istio – الاستهلاك الكبير لذاكرة الوصول العشوائي (RAM) بواسطة كل حاوية وكيل جانبية ونناقش كيفية التعامل معها.
المصدر: www.habr.com