په اخر کې موږ د خدمت میش اسټیو اساسی برخو ته کتنه وکړه ، د سیسټم سره آشنا شو او اصلي پوښتنو ته مو ځواب ورکړ چې معمولا راپورته کیږي کله چې د اسټیو سره کار پیل کوي. پدې برخه کې به موږ وګورو چې څنګه په شبکه کې د تعقیب معلوماتو راټولول تنظیم کړو.
لومړی شی چې د ډیری پراختیا کونکو او سیسټم مدیرانو لپاره ذهن ته راځي کله چې دوی د خدماتو میش ټکي واوري. په حقیقت کې، موږ د هرې شبکې نوډ ته یو ځانګړی پراکسي سرور اضافه کوو چې د TCP ټول ټرافیک تیریږي. داسې ښکاري چې اوس دا ممکنه ده چې په اسانۍ سره د شبکې د ټولو اړیکو په اړه معلومات واستول شي. له بده مرغه، په واقعیت کې ډیری لنډیزونه شتون لري چې باید په پام کې ونیول شي. راځئ چې دوی وګورو.
غلط فهم نمبر XNUMX: موږ کولی شو د آنلاین پیدل سفر ډیټا وړیا ترلاسه کړو.
په حقیقت کې، په نسبتا وړیا توګه، موږ کولی شو یوازې د خپل سیسټم نوډونه ترلاسه کړو چې د تیر او د معلوماتو کچه چې د خدماتو ترمنځ تیریږي (په حقیقت کې، یوازې د وخت په هر واحد کې د بایټ شمیره). په هرصورت، په ډیری قضیو کې، زموږ خدمتونه د یو ډول غوښتنلیک پرت پروتوکول، لکه HTTP، gRPC، Redis، او داسې نور سره اړیکه نیسي. او البته، موږ غواړو د دې پروتوکولونو لپاره په ځانګړې توګه د تعقیب معلومات وګورو؛ موږ غواړو د غوښتنې کچه وګورو، نه د معلوماتو کچه. موږ غواړو زموږ د پروتوکول په کارولو سره د غوښتنو په ځنډ پوه شو. په نهایت کې ، موږ غواړو هغه بشپړ لاره وګورو چې غوښتنه زموږ سیسټم ته د ننوتلو څخه د کارونکي څخه ځواب ترلاسه کولو پورې اخلي. دا ستونزه اوس دومره اسانه نه ده چې حل شي.
لومړی ، راځئ وګورو چې د ټریسینګ سپانس لیږل په اسټیو کې د معماري لید څخه څه ښکاري. لکه څنګه چې موږ د لومړۍ برخې څخه یادونه کوو، اسټیو د ټیل میټري راټولولو لپاره د مکسر په نوم جلا برخه لري. په هرصورت، په اوسني نسخه 1.0.* کې، لیږل په مستقیم ډول د پراکسي سرورونو څخه ترسره کیږي، د بیلګې په توګه، د سفیر پراکسي څخه. Envoy پراکسي د بکس څخه بهر د زپکین پروتوکول په کارولو سره د ټریسینګ سپانونو لیږلو ملاتړ کوي. دا ممکنه ده چې نور پروتوکولونه وصل کړئ، مګر یوازې د پلگ ان له لارې. د اسټیو سره موږ سمدلاسه یو راټول شوی او ترتیب شوی سفیر پراکسي ترلاسه کوو ، کوم چې یوازې د زپکین پروتوکول ملاتړ کوي. که موږ غواړو د مثال په توګه د جیجر پروتوکول وکاروو او د UDP له لارې ټریسینګ سپانونه واستوو، نو موږ به د خپل اسټیو پراکسي عکس جوړولو ته اړتیا ولرو. د istio-proxy لپاره د دودیز پلگ انونو ملاتړ شتون لري، مګر دا لاهم په الفا نسخه کې دی. له همدې امله، که موږ غواړو د لوی شمیر دودیز ترتیباتو پرته ترسره کړو، د ټیکنالوژیو سلسله چې د ټریسینګ اسپینونو ذخیره کولو او ترلاسه کولو لپاره کارول کیږي کم شوي. د اصلي سیسټمونو څخه، په حقیقت کې، تاسو اوس کولی شئ پخپله Zipkin، یا Jaeger وکاروئ، مګر د زپکین مناسب پروتوکول (کوم چې خورا لږ اغیزمن دی) په کارولو سره هرڅه هلته ولیږئ. د زپکین پروتوکول پخپله د HTTP پروتوکول له لارې راټولونکو ته د ټولو تعقیب معلوماتو لیږل شامل دي ، کوم چې خورا ګران دی.
لکه څنګه چې ما مخکې وویل، موږ غواړو د غوښتنلیک کچې پروتوکولونه تعقیب کړو. دا پدې مانا ده چې پراکسي سرورونه چې د هر خدمت تر څنګ ولاړ دي باید پوه شي چې اوس څه ډول تعامل کیږي. په ډیفالټ ، اسټیو ټول بندرونه د ساده TCP لپاره تنظیموي ، پدې معنی چې هیڅ نښې به ونه لیږل شي. د دې لپاره چې د نښو لیږلو لپاره ، تاسو باید لومړی دا اختیار په اصلي میش ترتیب کې فعال کړئ او هغه څه چې خورا مهم دي د پروتوکول سره سم د کوبرنیټس خدماتو ادارو ټول بندرونه نوم کړئ چې په خدمت کې کارول کیږي. دا د مثال په توګه، دا دی:
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 د دې لپاره چې د ورته خدمت پریښودو سره د خدماتو ته د راتلونکو غوښتنو لیک په اړه پوه شي، دا کافي ندي چې په ساده ډول د ټولو ټرافیک مخه ونیسي. تاسو اړتیا لرئ یو ډول ارتباط پیژندونکی ولرئ. د HTTP استازي پراکسي ځانګړي سرلیکونه کاروي، د کوم په واسطه استازي پوهیږي چې کوم خدمت ته ځانګړې غوښتنه نورو خدماتو ته ځانګړي غوښتنې رامینځته کوي. د داسې سرلیکونو لیست:
- x-request-id,
- x-b3-traceid,
- x-b3-spanid,
- x-b3- parentspanid,
- x-b3 نمونه،
- x-b3-بیرغونه
- x-ot-span-context.
که تاسو یو واحد ټکی لرئ، د بیلګې په توګه، یو بنسټیز پیرودونکی، په کوم کې چې تاسو کولی شئ دا ډول منطق اضافه کړئ، نو بیا هرڅه سم دي، تاسو یوازې د دې کتابتون انتظار ته اړتیا لرئ ترڅو د ټولو مراجعینو لپاره تازه شي. مګر که تاسو خورا متضاد سیسټم ولرئ او په شبکه کې له خدمت څخه خدمت ته حرکت کولو کې یووالی شتون نلري ، نو دا به خورا احتمال یوه لویه ستونزه وي. د داسې منطق اضافه کولو پرته، ټول د تعقیب معلومات به یوازې "واحد کچه" وي. دا دی، موږ به ټول د خدمت بین الافغاني تعاملات ترلاسه کړو، مګر دوی به د شبکې له لارې د تیریدو یو واحد زنځیرونو کې نه وتړل شي.
پایلې
اسټیو په شبکه کې د تعقیب معلوماتو راټولولو لپاره اسانه وسیله چمتو کوي ، مګر تاسو باید پوه شئ چې د پلي کولو لپاره تاسو اړتیا لرئ خپل سیسټم تطبیق کړئ او د اسټیو پلي کولو ځانګړتیاوې په پام کې ونیسئ. د پایلې په توګه، دوه اصلي ټکي باید حل شي: د غوښتنلیک کچې پروتوکول تعریف کول (کوم چې باید د استازي پراکسي لخوا مالتړ شي) او د خدماتو څخه د غوښتنو څخه خدمت ته د غوښتنو د ارتباط په اړه د معلوماتو لیږلو ترتیب کول (د سرلیکونو په کارولو سره. د HTTP پروتوکول په صورت کې). کله چې دا مسلې حل شي، موږ یو پیاوړی وسیله لرو چې موږ ته اجازه راکوي په شفافه توګه د شبکې څخه معلومات راټول کړو، حتی په ډیرو مختلف ژبو او چوکاټونو کې لیکل شوي خورا متفاوت سیسټمونو کې.
د خدماتو میش په اړه په راتلونکي مقاله کې ، موږ به د اسټیو سره یوه له لویو ستونزو څخه وګورو - د هر سایډ کار پراکسي کانټینر لخوا د رام لوی مصرف او بحث وکړئ چې تاسو څنګه ورسره معامله کولی شئ.
سرچینه: www.habr.com