Istio اور Kubernetes پیداوار میں۔ حصہ 2۔ سراغ لگانا

ماضی میں آرٹیکل ہم نے سروس میش اسٹیو کے بنیادی اجزاء کو دیکھا، سسٹم سے واقفیت حاصل کی اور ان اہم سوالات کے جوابات دیے جو عام طور پر اسٹیو کے ساتھ کام شروع کرتے وقت پیدا ہوتے ہیں۔ اس حصے میں ہم دیکھیں گے کہ نیٹ ورک پر ٹریسنگ کی معلومات کے مجموعہ کو کیسے منظم کیا جائے۔

پہلی چیز جو بہت سے ڈویلپرز اور سسٹم ایڈمنسٹریٹرز کے ذہن میں آتی ہے جب وہ سروس میش ٹریسنگ کے الفاظ سنتے ہیں۔ درحقیقت، ہم ہر نیٹ ورک نوڈ میں ایک خصوصی پراکسی سرور شامل کرتے ہیں جس کے ذریعے تمام TCP ٹریفک گزرتی ہے۔ ایسا لگتا ہے کہ اب نیٹ ورک پر تمام نیٹ ورک کے تعاملات کے بارے میں معلومات آسانی سے بھیجنا ممکن ہے۔ بدقسمتی سے، حقیقت میں بہت سی باریکیاں ہیں جن پر غور کرنے کی ضرورت ہے۔ آئیے ان کو دیکھتے ہیں۔

غلط فہمی نمبر ایک: ہم آن لائن ہائیکنگ ڈیٹا مفت حاصل کر سکتے ہیں۔

درحقیقت، نسبتاً مفت میں، ہم صرف اپنے سسٹم کے نوڈس حاصل کر سکتے ہیں جو تیروں کے ذریعے منسلک ہوتے ہیں اور ڈیٹا کی شرح جو سروسز کے درمیان گزرتی ہے (حقیقت میں، وقت کی فی یونٹ صرف بائٹس کی تعداد)۔ تاہم، زیادہ تر معاملات میں، ہماری خدمات کسی قسم کے ایپلیکیشن لیئر پروٹوکول پر بات چیت کرتی ہیں، جیسے HTTP، gRPC، Redis، وغیرہ۔ اور، یقیناً، ہم ان پروٹوکولز کے لیے خاص طور پر ٹریسنگ کی معلومات دیکھنا چاہتے ہیں؛ ہم درخواست کی شرح دیکھنا چاہتے ہیں، ڈیٹا کی شرح نہیں۔ ہم اپنے پروٹوکول کا استعمال کرتے ہوئے درخواستوں کی تاخیر کو سمجھنا چاہتے ہیں۔ آخر میں، ہم وہ مکمل راستہ دیکھنا چاہتے ہیں جو ایک درخواست ہمارے سسٹم میں لاگ ان ہونے سے لے کر صارف سے جواب حاصل کرنے تک لیتی ہے۔ یہ مسئلہ اب حل کرنا اتنا آسان نہیں رہا۔

سب سے پہلے، آئیے دیکھتے ہیں کہ اسٹیو میں آرکیٹیکچرل نقطہ نظر سے ٹریسنگ اسپین بھیجنا کیسا لگتا ہے۔ جیسا کہ ہمیں پہلے حصے سے یاد ہے، اسٹیو میں ٹیلی میٹری جمع کرنے کے لیے مکسر نامی ایک الگ جزو ہے۔ تاہم، موجودہ ورژن 1.0.* میں، بھیجنا براہ راست پراکسی سرورز سے، یعنی ایلچی پراکسی سے کیا جاتا ہے۔ ایلچی پراکسی باکس کے باہر زپکن پروٹوکول کا استعمال کرتے ہوئے ٹریسنگ اسپین بھیجنے کی حمایت کرتی ہے۔ دوسرے پروٹوکول کو جوڑنا ممکن ہے، لیکن صرف ایک پلگ ان کے ذریعے۔ Istio کے ساتھ ہمیں فوری طور پر ایک اسمبل شدہ اور کنفیگرڈ ایلچی پراکسی ملتی ہے، جو صرف زپکن پروٹوکول کو سپورٹ کرتی ہے۔ اگر ہم استعمال کرنا چاہتے ہیں، مثال کے طور پر، Jaeger پروٹوکول اور UDP کے ذریعے ٹریسنگ اسپین بھیجنا چاہتے ہیں، تو ہمیں اپنی istio-proxy امیج بنانے کی ضرورت ہوگی۔ istio-proxy کے لیے حسب ضرورت پلگ ان کے لیے سپورٹ موجود ہے، لیکن یہ اب بھی الفا ورژن میں ہے۔ لہذا، اگر ہم اپنی مرضی کے مطابق ترتیبات کی ایک بڑی تعداد کے بغیر کرنا چاہتے ہیں تو، ٹریسنگ اسپین کو ذخیرہ کرنے اور وصول کرنے کے لیے استعمال ہونے والی ٹیکنالوجیز کی حد کم ہو جاتی ہے۔ اہم سسٹمز میں سے، حقیقت میں، اب آپ خود Zipkin، یا Jaeger استعمال کر سکتے ہیں، لیکن 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 میں ایک شناخت کنندہ کے طور پر استعمال ہوتا ہے جہاں درخواست کی جاتی ہے۔ اسٹیو میں اس پیرامیٹر کی قدر کو حسب ضرورت بنانے کے لیے (پھر ہم اسے اپنے ٹریسنگ سسٹم میں دیکھیں گے)، سائڈ کار کنٹینر کو لانچ کرنے کے مرحلے پر سروس کلسٹر پرچم کی وضاحت کرنا ضروری ہے۔ مثال کے طور پر، یہ نیچے کی طرف kubernetes API سے حاصل کردہ متغیرات سے اس طرح شمار کیا جا سکتا ہے:

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

یہ سمجھنے کے لیے ایک اچھی مثال ہے کہ ایلچی میں ٹریسنگ کیسے کام کرتی ہے۔ یہاں.

ٹریسنگ اسپین بھیجنے کے لیے اختتامی نقطہ خود بھی ایلچی پراکسی لانچ فلیگ میں بیان کیا جانا چاہیے، مثال کے طور پر: --zipkinAddress tracing-collector.tracing:9411

غلط فہمی نمبر دو: ہم سستے طریقے سے سسٹم کے ذریعے درخواستوں کے مکمل نشانات حاصل کر سکتے ہیں

بدقسمتی سے، ایسا نہیں ہے۔ نفاذ کی پیچیدگی کا انحصار اس بات پر ہے کہ آپ نے پہلے سے ہی خدمات کے تعامل کو کیسے نافذ کیا ہے۔ ایسا کیوں ہے؟

حقیقت یہ ہے کہ istio-proxy ایک ہی سروس کو چھوڑنے والوں کے ساتھ کسی سروس میں آنے والی درخواستوں کے خط و کتابت کو سمجھنے کے قابل ہونے کے لیے، صرف تمام ٹریفک کو روکنا کافی نہیں ہے۔ آپ کے پاس کسی قسم کا مواصلاتی شناخت کنندہ ہونا ضروری ہے۔ ایچ ٹی ٹی پی ایلچی پراکسی خاص ہیڈر استعمال کرتی ہے، جس کے ذریعے ایلچی سمجھتا ہے کہ سروس کے لیے کون سی مخصوص درخواست دوسری سروسز کے لیے مخصوص درخواستیں پیدا کرتی ہے۔ ایسے ہیڈرز کی فہرست:

• x-request-id،
• x-b3-traceid،
• x-b3-spanid،
• x-b3-parentspanid،
• x-b3 نمونہ،
• x-b3-جھنڈے،
• x-ot-span-context.

اگر آپ کے پاس ایک نقطہ ہے، مثال کے طور پر، ایک بنیادی کلائنٹ، جس میں آپ اس طرح کی منطق شامل کر سکتے ہیں، تو سب کچھ ٹھیک ہے، آپ کو صرف اس لائبریری کے تمام کلائنٹس کے لیے اپ ڈیٹ ہونے کا انتظار کرنا ہوگا۔ لیکن اگر آپ کے پاس ایک بہت ہی متفاوت نظام ہے اور نیٹ ورک پر سروس سے سروس میں منتقل ہونے میں کوئی اتحاد نہیں ہے، تو یہ ممکنہ طور پر ایک بڑا مسئلہ ہوگا۔ اس طرح کی منطق کو شامل کیے بغیر، تمام ٹریسنگ معلومات صرف "سنگل لیول" ہوں گی۔ یعنی، ہم تمام انٹر-سروس تعاملات حاصل کریں گے، لیکن وہ نیٹ ورک کے ذریعے گزرنے کی واحد زنجیروں میں چپکے نہیں ہوں گے۔

حاصل يہ ہوا

Istio نیٹ ورک پر ٹریسنگ کی معلومات جمع کرنے کے لیے ایک آسان ٹول فراہم کرتا ہے، لیکن آپ کو یہ سمجھنا چاہیے کہ نفاذ کے لیے آپ کو اپنے سسٹم کو ڈھالنے اور Istio کے نفاذ کی خصوصیات کو مدنظر رکھنا ہوگا۔ نتیجے کے طور پر، دو اہم نکات کو حل کرنے کی ضرورت ہے: ایپلیکیشن لیول پروٹوکول کی وضاحت کرنا (جسے ایلچی پراکسی کے ذریعے سپورٹ کیا جانا چاہیے) اور سروس سے درخواستوں سے سروس سے کنکشن کے بارے میں معلومات کو آگے بھیجنا (ہیڈر کا استعمال کرتے ہوئے) ، HTTP پروٹوکول کی صورت میں)۔ جب یہ مسائل حل ہو جاتے ہیں، تو ہمارے پاس ایک طاقتور ٹول ہوتا ہے جو ہمیں نیٹ ورک سے شفاف طریقے سے معلومات اکٹھا کرنے کی اجازت دیتا ہے، یہاں تک کہ بہت سی مختلف زبانوں اور فریم ورک میں لکھے گئے انتہائی متفاوت نظاموں میں بھی۔

سروس میش کے بارے میں اگلے مضمون میں، ہم Istio کے ساتھ سب سے بڑے مسائل میں سے ایک کو دیکھیں گے - ہر سائڈ کار پراکسی کنٹینر کے ذریعے RAM کی بڑی کھپت اور اس پر بات کریں گے کہ آپ اس سے کیسے نمٹ سکتے ہیں۔

ماخذ: www.habr.com