إستيو و Kubernetes في الإنتاج. الجزء 2. تتبع

في المقالة الأخيرة ، درسنا المكونات الأساسية لـ Service Mesh Istio ، وتعرفنا على النظام وأجبنا على الأسئلة الأساسية التي تنشأ عادةً في بداية العمل مع Istio. في هذا الجزء ، سننظر في كيفية تنظيم جمع معلومات التتبع عبر الشبكة.



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

الاعتقاد الخاطئ رقم واحد: يمكننا الحصول على بيانات عن الرحلات عبر الشبكة مجانًا

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

للبدء ، دعنا ننظر إلى كيفية ظهور امتدادات التتبع من وجهة نظر الهندسة المعمارية في Istio. كما نتذكر من الجزء الأول ، لدى Istio مكون منفصل لجمع القياس عن بعد ، والذي يسمى Mixer. ومع ذلك ، في الإصدار الحالي 1.0. * يتم الإرسال مباشرة من خوادم بروكسي ، أي باستخدام مبعوث الوكيل. يدعم مبعوث الوكيل إرسال نطاقات التتبع عبر بروتوكول zipkin خارج الصندوق. يمكن أن تكون متصلا البروتوكولات الأخرى ، ولكن فقط من خلال البرنامج المساعد. مع Istio ، نحصل على الفور على وكيل المبعوث الذي تم تجميعه وتكوينه ، والذي يدعم بروتوكول zipkin فقط. إذا أردنا استخدام بروتوكول Jaeger على سبيل المثال وإرسال مسافات التتبع عبر UDP ، فسنحتاج إلى تجميع صورة istio-proxy لدينا. يوجد دعم للإضافات المخصصة لـ 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). التنسيق هو: proto-extra.

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

لفهم ما إذا كان البروتوكول محددًا بالفعل بشكل صحيح ، ستحتاج إلى الدخول في أي من الحاويات الجانبية مع وكيل المبعوث وتقديم طلب إلى منفذ المسؤول لواجهة المبعوث مع الموقع / config_dump. في التكوين الناتج ، تحتاج إلى إلقاء نظرة على عملية مجال الخدمة المطلوبة. يتم استخدامه في Istio كمعرف إلى أين يذهب الطلب. لتخصيص قيمة هذه المعلمة في Istio (سنرىها بعد ذلك في نظام التتبع الخاص بنا) ، يجب عليك تحديد إشارة serviceCluster في مرحلة بدء تشغيل الحاوية الجانبية. على سبيل المثال ، يمكن حسابها على هذا النحو من المتغيرات التي تم الحصول عليها من kubernetes API لأسفل:

--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')

مثال جيد لفهم كيف يعمل تتبع في المبعوث هنا .

يجب أيضًا تحديد نقطة النهاية نفسها لإرسال --zipkinAddress tracing-collector.tracing:9411 في علامات بدء وكيل المبعوث ، على سبيل المثال: - --zipkinAddress tracing-collector.tracing:9411

الاعتقاد الخاطئ رقم 2: يمكننا الحصول على مسارات كاملة غير مكلفة مرور طلبات النظام من خارج منطقة الجزاء

لسوء الحظ ، هذا ليس كذلك. يعتمد تعقيد التنفيذ على كيفية قيامك بالفعل بتنفيذ تفاعل الخدمات. لماذا هذا

والحقيقة هي أنه لكي يفهم istio-proxy مراسلات الطلبات الواردة إلى الخدمة مع القادمين من نفس الخدمة ، لا يكفي مجرد اعتراض كل حركة المرور. يجب أن يكون لديك نوع من معرف الارتباط. يستخدم وكيل HTTP المبعوث رؤوسًا خاصة ، يفهم بواسطتها المبعوث طلب الخدمة المعين الذي يولد طلبات محددة للخدمات الأخرى. قائمة هذه الرؤوس:

• معرّف س طلب ،
• x-b3-traceid ،
• x-b3-spanid ،
• س-ب 3-الوالدين ،
• عينات x-b3 ،
• أعلام x-b3 ،
• س ot-span- السياق.

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

الخاتمة

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

في المقالة التالية حول Service Mesh ، سننظر في واحدة من أكبر مشكلات Istio - استهلاك الذاكرة الكبيرة لكل حاوية وكيل جانبي ومناقشة كيفية التعامل معها.