آخري ۾ اسان سروس ميش اسٽيو جي بنيادي حصن کي ڏٺو، سسٽم سان واقف ٿي ويا ۽ بنيادي سوالن جو جواب ڏنو جيڪي عام طور تي پيدا ٿين ٿا جڏهن Istio سان ڪم ڪرڻ شروع ڪيو وڃي. هن حصي ۾ اسين ڏسنداسين ته نيٽ ورڪ تي ٽريڪنگ معلومات جي گڏ ڪرڻ کي ڪيئن منظم ڪجي.
پهرين شيء جيڪا ذهن ۾ اچي ٿي ڪيترن ئي ڊولپرز ۽ سسٽم ايڊمنسٽريٽرن لاءِ جڏهن اهي لفظ ٻڌندا آهن سروس ميش ٽريڪنگ. درحقيقت، اسان هر نيٽ ورڪ نوڊ تي هڪ خاص پراکسي سرور شامل ڪيو جنهن جي ذريعي تمام TCP ٽرئفڪ گذري ٿو. اهو لڳي ٿو ته اهو هاڻي آساني سان نيٽ ورڪ تي سڀني نيٽ ورڪ رابطي جي باري ۾ معلومات موڪلڻ ممڪن آهي. بدقسمتي سان، حقيقت ۾ اهڙا ڪيترائي nuances آهن جن کي حساب ۾ وٺڻ جي ضرورت آهي. اچو ته انهن کي ڏسو.
غلط فهمي نمبر هڪ: اسان مفت ۾ آن لائن جابلو ڊيٽا حاصل ڪري سگهون ٿا.
حقيقت ۾، نسبتاً مفت ۾، اسان صرف اسان جي سسٽم جا نوڊس حاصل ڪري سگھون ٿا جيڪي تير سان ڳنڍيل آهن ۽ ڊيٽا جي شرح جيڪا خدمتن جي وچ ۾ گذري ٿي (حقيقت ۾، صرف وقت جي في يونٽ بائيٽ جو تعداد). جڏهن ته، اڪثر ڪيسن ۾، اسان جون خدمتون ڪنهن قسم جي ايپليڪيشن ليئر پروٽوڪول تي رابطو ڪن ٿيون، جهڙوڪ HTTP، gRPC، Redis، وغيره. ۽، يقينا، اسان انهن پروٽوڪولن لاء خاص طور تي ڄاڻ جي ڄاڻ ڏسڻ چاهيون ٿا؛ اسان چاهيون ٿا درخواست جي شرح، نه ڊيٽا جي شرح. اسان اسان جي پروٽوڪول کي استعمال ڪندي درخواستن جي ويڪرائي کي سمجهڻ چاهيون ٿا. آخرڪار، اسان مڪمل رستو ڏسڻ چاهيون ٿا جيڪو درخواست اسان جي سسٽم ۾ لاگ ان ٿيڻ کان وٺي صارف کان جواب حاصل ڪرڻ لاء وٺندو آهي. اهو مسئلو هاڻي حل ڪرڻ ايترو آسان ناهي.
پهرين، اچو ته ڏسو ته ڇا موڪلڻ واري ٽريڪنگ اسپن وانگر نظر ايندي آهي Istio ۾ هڪ تعميراتي نقطي نظر کان. جيئن ته اسان کي پهرين حصي کان ياد آهي، Istio هڪ الڳ جزو آهي جنهن کي Mixer سڏيو ويندو آهي ٽيلي ميٽري کي گڏ ڪرڻ لاء. جڏهن ته، موجوده ورزن 1.0.* ۾، موڪلڻ سڌو سنئون پراکسي سرورز کان، يعني، اينووي پراکسي کان. Envoy proxy zipkin پروٽوڪول استعمال ڪندي ٽريڪنگ اسپن موڪلڻ جي سپورٽ ڪري ٿو. اهو ممڪن آهي ته ٻين پروٽوڪول سان ڳنڍڻ، پر صرف هڪ پلگ ان ذريعي. Istio سان اسان کي فوري طور تي هڪ گڏ ڪيل ۽ ترتيب ڏنل ايلچي پراکسي ملي ٿي، جيڪا صرف زپڪن پروٽوڪول کي سپورٽ ڪري ٿي. جيڪڏهن اسان استعمال ڪرڻ چاهيون ٿا، مثال طور، جيجر پروٽوڪول ۽ يو ڊي پي ذريعي ٽريڪنگ اسپن موڪلڻ، پوءِ اسان کي پنهنجي اسٽيو-پراڪسي تصوير ٺاهڻ جي ضرورت پوندي. istio-proxy لاءِ ڪسٽم پلگ ان لاءِ سپورٽ موجود آهي، پر اهو اڃا تائين الفا ورزن ۾ آهي. تنهن ڪري، جيڪڏهن اسان وڏي تعداد ۾ ڪسٽم سيٽنگون ڪرڻ چاهيون ٿا، ٽريڪنگ اسپن کي محفوظ ڪرڻ ۽ وصول ڪرڻ لاءِ استعمال ٿيندڙ ٽيڪنالاجيز جي حد گهٽجي وئي آهي. مکيه سسٽم مان، حقيقت ۾، هاڻي توهان استعمال ڪري سگهو ٿا Zipkin پاڻ، يا Jaeger، پر zipkin مطابقت پروٽوڪول (جيڪو تمام گهٽ موثر آهي) استعمال ڪندي اتي هر شي کي موڪليو. زپڪن پروٽوڪول پاڻ ۾ شامل آهي سڀني ٽريڪنگ معلومات گڏ ڪرڻ وارن کي HTTP پروٽوڪول ذريعي، جيڪو ڪافي مهانگو آهي.
جيئن ته مون اڳ ۾ ئي چيو آهي، اسان کي ٽريڪ ڪرڻ چاهيون ٿا ايپليڪيشن-سطح پروٽوڪول. هن جو مطلب آهي ته پراکسي سرورز جيڪي هر خدمت جي اڳيان بيٺا آهن انهن کي سمجهڻ گهرجي ته هاڻي ڪهڙي قسم جو رابطو ٿي رهيو آهي. ڊفالٽ طور، Istio سڀني بندرگاهن کي ترتيب ڏئي ٿو سادو TCP، جنهن جو مطلب آهي ڪوبه نشان نه موڪليو ويندو. نشانيون موڪلڻ لاءِ، توھان کي لازمي طور تي، پھريائين، ھن اختيار کي مکيه ميش ترتيب ۾ فعال ڪرڻ گھرجي ۽، جيڪو تمام ضروري آھي، سڀني بندرگاھن کي نالو ڏيو ڪبرنيٽس سروس ادارن جي پروٽوڪول جي مطابق جيڪو خدمت ۾ استعمال ٿئي ٿو. اهو آهي، مثال طور، هن طرح:
apiVersion: v1
kind: Service
metadata:
name: nginx
spec:
ports:
- port: 80
targetPort: 80
name: http
selector:
app: nginxتوھان پڻ استعمال ڪري سگھوٿا مرڪب جا نالا جهڙوڪ http-magic (Istio ڏسندو http ۽ ان بندرگاهه کي http endpoint طور سڃاڻيندو). فارميٽ آهي: پروٽو-اضافي.
پروٽوڪول کي طئي ڪرڻ لاءِ وڏي تعداد ۾ ترتيبن کي پيچ نه ڪرڻ لاءِ ، توهان هڪ گندي ڪم ڪار استعمال ڪري سگهو ٿا: پائلٽ جزو کي هن وقت پيچ ڪريو جڏهن اهو صرف . آخر ۾، يقينا، اهو ضروري آهي ته هن منطق کي معياري طور تي تبديل ڪرڻ ۽ سڀني بندرگاهن جي نالي جي ڪنوينشن کي تبديل ڪرڻ لاء.
سمجھڻ لاءِ ته ڇا پروٽوڪول واقعي صحيح طور تي بيان ڪيو ويو آھي، توھان کي ڪنھن به سائڊ ڪار ڪنٽينر ۾ داخل ٿيڻ جي ضرورت آھي envoy proxy سان ۽ انٽرفيس جي منتظم بندرگاھ کي گذارش ڪرڻ لاءِ envoy proxy /config_dump. نتيجي جي ترتيب ۾، توهان کي گهربل خدمت جي آپريشن فيلڊ کي ڏسڻ جي ضرورت آهي. اهو Istio ۾ استعمال ڪيو ويندو آهي هڪ سڃاڻپ ڪندڙ جي طور تي جتي درخواست ڪئي وئي آهي. Istio ۾ هن پيٽرولر جي قيمت کي ترتيب ڏيڻ لاء (اسان ان کي اسان جي ٽريڪنگ سسٽم ۾ ڏسندا سين)، اهو ضروري آهي ته سروس ڪلستر پرچم کي بيان ڪرڻ لاء سائڊ ڪار ڪنٽينر کي لانچ ڪرڻ جي مرحلي ۾. مثال طور، اهو حساب ڪري سگهجي ٿو هن طرح هيٺ ڏنل ڪبرنيٽس API مان حاصل ڪيل متغيرن مان:
--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')
ھڪڙو سٺو مثال سمجھڻ لاءِ ته ڪيئن ٽريسنگ ڪم ڪندو آھي ايلچي ۾ .
ٽريسنگ اسپن موڪلڻ لاءِ آخري پوائنٽ پاڻ کي پڻ ايلچي پراکسي لانچ پرچمن ۾ بيان ڪيو وڃي، مثال طور: --zipkinAddress tracing-collector.tracing:9411
غلط فهمي نمبر ٻه: اسان سستي سان درخواستن جا مڪمل نشان حاصل ڪري سگھون ٿا سسٽم کان ٻاهر
بدقسمتي سان، اهو ناهي. عملدرآمد جي پيچيدگي تي منحصر آهي ته توهان اڳ ۾ ئي خدمتن جي رابطي کي ڪيئن لاڳو ڪيو آهي. ائين ڇو آهي؟
حقيقت اها آهي ته istio-proxy لاءِ هڪ ئي خدمت ڇڏڻ وارن سان گڏ هڪ خدمت ڏانهن ايندڙ درخواستن جي خط و ڪتابت کي سمجهڻ جي قابل ٿي وڃڻ لاءِ، اهو ڪافي ناهي ته صرف سڀني ٽرئفڪ کي روڪيو وڃي. توھان کي ضرورت آھي ڪنھن قسم جي رابطي جي سڃاڻپ ڪندڙ. HTTP نمائندو پراکسي خاص هيڊر استعمال ڪري ٿو، جنهن جي ذريعي سفير سمجهي ٿو ته ڪهڙي مخصوص درخواست خدمت جي ٻين خدمتن لاءِ مخصوص درخواستون پيدا ڪري ٿي. اهڙن عنوانن جي فهرست:
- x-درخواست-id،
- x-b3-traceid,
- x-b3-spanid,
- x-b3-parentspanid,
- x-b3-نموني،
- x-b3-جھنڊو،
- x-ot-span-context.
جيڪڏهن توهان وٽ هڪ نقطو آهي، مثال طور، هڪ بنيادي ڪلائنٽ، جنهن ۾ توهان اهڙي منطق شامل ڪري سگهو ٿا، پوء سڀ ڪجهه ٺيڪ آهي، توهان کي صرف انتظار ڪرڻو پوندو ته هن لائبريري کي سڀني مراجعين لاء اپڊيٽ ڪيو وڃي. پر جيڪڏهن توهان وٽ هڪ تمام متضاد نظام آهي ۽ نيٽ ورڪ تي خدمت کان خدمت ڏانهن منتقل ڪرڻ ۾ ڪو به اتحاد نه آهي، ته اهو گهڻو ڪري هڪ وڏو مسئلو ٿيندو. اهڙي منطق کي شامل ڪرڻ کان سواءِ، سڀني ٽريڪنگ معلومات صرف ”سنگل-سطح“ هوندي. اهو آهي، اسان سڀني بين الاقوامي خدمت جي وچ ۾ رابطي کي حاصل ڪنداسين، پر انهن کي نيٽ ورڪ ذريعي گذرڻ جي واحد زنجيرن ۾ جڙيل نه هوندو.
ٿڪل
Istio هڪ نيٽ ورڪ تي ٽريڪنگ معلومات گڏ ڪرڻ لاء هڪ آسان اوزار مهيا ڪري ٿو، پر توهان کي اهو سمجهڻ گهرجي ته عمل درآمد لاء توهان کي پنهنجي سسٽم کي ترتيب ڏيڻ ۽ Istio عمل درآمد جي خاصيتن کي حساب ۾ رکڻ جي ضرورت پوندي. نتيجي طور، ٻن مکيه نقطن کي حل ڪرڻ جي ضرورت آهي: ايپليڪيشن ليول پروٽوڪول جي وضاحت ڪرڻ (جنهن کي ايلچي پراکسي جي مدد ڪرڻ گهرجي) ۽ خدمت جي درخواستن کان خدمت جي درخواستن جي ڪنيڪشن بابت معلومات جي فارورڊنگ کي ترتيب ڏيڻ (هيڊر استعمال ڪندي. ، HTTP پروٽوڪول جي صورت ۾). جڏهن اهي مسئلا حل ڪيا ويندا آهن، اسان وٽ هڪ طاقتور اوزار آهي جيڪو اسان کي نيٽ ورڪ کان شفاف معلومات گڏ ڪرڻ جي اجازت ڏئي ٿو، جيتوڻيڪ ڪيترن ئي مختلف ٻولين ۽ فريم ورڪ ۾ لکيل تمام مختلف سسٽم ۾.
سروس ميش جي باري ۾ ايندڙ مضمون ۾، اسان ڏسنداسين Istio سان گڏ سڀ کان وڏو مسئلو - هر سائڊ ڪار پراکسي ڪنٽينر طرفان رام جو وڏو استعمال ۽ بحث ڪنداسين ته توهان ان سان ڪيئن معاملو ڪري سگهو ٿا.
جو ذريعو: www.habr.com