بیرته د اسټیو سره مایکرو خدماتو ته. دریمه برخه

نوټ. ژباړه: د خدماتو میشونه یقینا په عصري زیربنا کې د مایکرو سرویس جوړښت تعقیب غوښتنلیکونو لپاره اړونده حل ګرځیدلی. پداسې حال کې چې اسټیو ممکن د ډیری DevOps انجینرانو په شونډو کې وي ، دا یو کافي نوی محصول دی چې پداسې حال کې چې د وړتیاو له مخې چې دا چمتو کوي جامع وي ، ممکن د پیژندلو لپاره د پام وړ وخت ته اړتیا ولري. آلماني انجینر رینور مالوکو، چې د مخابراتي شرکت اورنج شبکې کې د لوی پیرودونکو لپاره د کلاوډ کمپیوټري مسؤلیت لري، د موادو یوه په زړه پورې لړۍ لیکلې چې تاسو ته اجازه درکوي په چټکۍ او ژوره توګه په اسټیو کې ډوب کړئ. هغه خپله کیسه د هغه څه سره پیل کوي چې اسټیو په عموم کې کولی شي او تاسو څنګه ژر تر ژره په خپلو سترګو وګورئ.

اسټیټو - د خلاصې سرچینې پروژه د ګوګل، IBM او Lyft ټیمونو په همکارۍ رامینځته شوې. دا پیچلتیاوې حل کوي چې د مایکرو خدماتو پراساس غوښتنلیکونو کې رامینځته کیږي ، لکه:

• د ترافیکو مدیریت: مهال ویش، بیا هڅه، د بار توازن؛
• امنیت: د پای کارونکي تصدیق او اجازه؛
• مشاهده: تعقیب، څارنه، ننوتنه.

دا ټول د غوښتنلیک په کچه حل کیدی شي، مګر له هغې وروسته به ستاسو خدمتونه نور "مائیکرو" نه وي. د دې ستونزو د حل لپاره ټولې اضافي هڅې د شرکت سرچینو ضایع کول دي چې په مستقیم ډول د سوداګرۍ ارزښت لپاره کارول کیدی شي. راځئ چې یو مثال وګورو:

د پروژې مدیر: د فیډبیک فیچر اضافه کولو لپاره څومره وخت نیسي؟
پرمخ وړونکی: دوه سپرینټونه.

استازی: څه؟... دا یوازې CRUD دی!
R: د CRUD ترسره کول اسانه برخه ده، مګر موږ لاهم اړتیا لرو چې د کاروونکو او خدماتو تصدیق او تصدیق وکړو. څرنګه چې شبکه د اعتبار وړ نه ده، تاسو اړتیا لرئ چې تکراري غوښتنې پلي کړئ، او همدارنګه د سرکټ ماتونکي نمونه په مراجعینو کې. همچنان ، د دې لپاره چې ډاډ ترلاسه کړئ چې ټول سیسټم خراب نشي ، تاسو به د وخت پای ته اړتیا ولرئ او ګولۍ (د دواړو ذکر شویو نمونو په اړه د نورو جزیاتو لپاره، وروسته په مقاله کې وګورئ - نږدې ژباړه.)، او د ستونزو موندلو لپاره ، څارنه ، تعقیب ، […]

MP: اوه، نو راځئ چې دا فیچر د محصول خدمت کې دننه کړو.

زه فکر کوم چې نظر روښانه دی: د یو خدمت اضافه کولو لپاره اړین ګامونه او هڅې خورا لوی دي. پدې مقاله کې، موږ به وګورو چې څنګه Istio پورته ذکر شوي ټول پیچلتیاوې لرې کوي (چې موخه یې د سوداګرۍ منطق نه وي) له خدماتو څخه.

تبصره: دا مقاله داسې انګیرل کیږي چې تاسو د کوبرنیټس په اړه کاري پوهه لرئ. که نه نو زه د لوستلو وړاندیز کوم Kubernetes ته زما پیژندنه او یوازې له هغې وروسته د دې موادو لوستلو ته دوام ورکړئ.

Istio مفکوره

د اسټیو پرته نړۍ کې، یو خدمت بل ته مستقیمې غوښتنې کوي، او د ناکامۍ په صورت کې، خدمت باید پخپله اداره کړي: نوې هڅه وکړئ، د وخت وخت چمتو کړئ، د سرکټ بریکر خلاص کړئ، او داسې نور.

په Kubernetes کې د شبکې ترافیک

Istio یو ځانګړی حل وړاندې کوي، په بشپړه توګه د خدماتو څخه جلا شوی او د شبکې اړیکو سره د مداخلې له لارې فعالیت کوي. او پدې توګه دا پلي کوي:

• د خطا زغم: په ځواب کې د حالت کوډ پراساس، دا پوهیږي چې ایا غوښتنه ناکامه شوې او بیا یې اجرا کوي.
• کانري رول آؤټ: د خدماتو نوې نسخې ته د غوښتنو یوازې یوه ثابته فیصده لیږل کیږي.
• څارنه او میټریکونه: د خدمت ځواب ورکولو لپاره څومره وخت نیولی؟
• تعقیب او مشاهده کول: هرې غوښتنې ته ځانګړي سرلیکونه اضافه کوي او په ټول کلستر کې یې لټوي.
• امنیت: د JWT نښه بیرته ترلاسه کوي، تصدیق کوي او کاروونکو ته اجازه ورکوي.

دا یوازې یو څو امکانات دي (واقعیا یوازې یو څو!) چې تاسو یې په زړه پوري کړي. اوس راځئ چې تخنیکي توضیحاتو ته لاړ شو!

د اسټیو معمارۍ

Istio د شبکې ټول ترافیک مداخله کوي او په دې باندې یو لړ مقررات پلي کوي، په هر پوډ کې د سایډ کار کانټینر په بڼه یو سمارټ پراکسي داخلوي. پراکسي چې ټولې وړتیاوې فعالوي د الف د معلوماتو الوتکه، او دوی په متحرک ډول په کارولو سره تنظیم کیدی شي د کنټرول الوتکه.

د معلوماتو الوتکه

په پوډونو کې داخل شوي پراکسي اسټیو ته اجازه ورکوي چې په اسانۍ سره هغه اړتیاوې پوره کړي چې موږ ورته اړتیا لرو. د مثال په توګه، راځئ چې بیا هڅه وکړو او د سرکټ بریکر افعال وګورو.

څنګه بیا هڅه او سرکټ ماتول په انوی کې پلي کیږي

د لنډیز لپاره:

1. استازي (موږ د یو پراکسي په اړه خبرې کوو چې د سایډ کار کانټینر کې موقعیت لري ، کوم چې په توګه توزیع شوی جلا محصول - نږدې ژباړه.) د B خدمت لومړۍ مثال ته غوښتنه لیږي او ناکامیږي.
2. سفیر سایډکار بیا هڅه کوي (بیا هڅه). (1)
3. غوښتنه ناکامه شوه او پراکسي ته بیرته راستانه شوه چې ورته ویل کیږي.
4. دا سرکټ بریکر خلاصوي او د راتلونکو غوښتنو لپاره راتلونکي خدمت ته زنګ وهي. (2)

د دې معنی دا ده چې تاسو اړتیا نلرئ د بیاکتنې بل کتابتون وکاروئ ، تاسو اړتیا نلرئ د برنامې په ژبه X ، Y یا Z کې د سرکټ ماتولو او خدماتو کشف پخپله پلي کړئ. دا ټول او نور ډیر څه د بکس څخه بهر شتون لري. په اسټیو کې او اړتیا نلري никаких په کوډ کې بدلونونه.

غوره! اوس تاسو ممکن غواړئ د اسټیو سره سفر ته لاړشئ ، مګر تاسو لاهم ځینې شکونه لرئ ، خلاصې پوښتنې. که دا د ژوند د ټولو مواردو لپاره یو نړیوال حل وي، نو تاسو طبیعي شک لرئ: په حقیقت کې دا ډول ټول حلونه د هرې قضیې لپاره مناسب نه دي.

او په نهایت کې تاسو وپوښتئ: "ایا دا دودیز دی؟"

اوس تاسو د سمندري سفر لپاره چمتو یاست، راځئ چې د کنټرول الوتکې سره اشنا شو.

د کنټرول الوتکه

دا د دریو برخو څخه جوړه ده: پیلوټ, مخلوط и د فراه تاريخي کلا، کوم چې په ګډه کار کوي ترڅو سفیران تنظیم کړي ترڅو ټرافيکي لارې تنظیم کړي ، پالیسۍ پلي کړي ، او د ټیلی میټري ډیټا راټول کړي. په سکیمیک ډول دا ټول داسې ښکاري:

د ډیټا الوتکې سره د کنټرول الوتکې تعامل

سفیران (د بیلګې په توګه د معلوماتو الوتکه) په کارولو سره ترتیب شوي Kubernetes CRD (د ګمرک سرچینې تعریفونه) د اسټیو لخوا تعریف شوي او په ځانګړي ډول د دې هدف لپاره ټاکل شوي. دا ستاسو لپاره څه معنی لري دا دي چې دوی په کوبرنیټس کې د پیژندل شوي ترکیب سره یوازې یوه بله سرچینه ښکاري. یوځل چې رامینځته شي ، دا سرچینه به د کنټرول الوتکې لخوا پورته شي او سفیرانو ته به پلي شي.

د اسټیو سره د خدماتو اړیکه

موږ د خدماتو سره د اسټیو اړیکه تشریح کړې، مګر برعکس نه: خدمات څنګه د اسټیو سره تړاو لري؟

د ریښتیني کیدو لپاره ، خدمتونه د اسټیو له شتون څخه دومره خبر دي لکه کب د اوبو څخه دي کله چې دوی له ځانه وپوښتي ، "اوبه څه شی دی؟"

بیلګه ویکتوریا دیمیتراکوپولوس:- اوبه څنګه خوښوې؟ - په هر حال اوبه څه شی دی؟

پدې توګه ، تاسو کولی شئ کاري کلستر واخلئ او د اسټیو اجزاو له مینځه وړلو وروسته ، پدې کې موقعیت لرونکي خدمات به کار ته دوام ورکړي ، او د دې اجزاو لرې کولو وروسته به هرڅه سم وي. دا روښانه ده چې پدې حالت کې تاسو به د اسټیو لخوا چمتو شوي وړتیاوې له لاسه ورکړئ.

کافي تیوري - راځئ چې دا پوهه په عمل کې واچوو!

Istio په عمل کې

Istio د Kubernetes کلستر ته اړتیا لري چې لږترلږه 4 vCPUs او 8 GB رام شتون ولري. د ګړندي کلستر تنظیم کولو او د مقالې لارښوونې تعقیبولو لپاره ، زه د ګوګل کلاوډ پلیټ فارم کارولو وړاندیز کوم ، کوم چې نوي کاروونکو وړاندیز کوي وړیا $300.

د کلستر رامینځته کولو او د کنسول افادیت له لارې کوبرنیټس ته د لاسرسي تنظیم کولو وروسته ، تاسو کولی شئ د هیلم بسته مدیر له لارې اسټیو نصب کړئ.

د هیلم نصب کول

په خپل کمپیوټر کې د هیلم مراجع نصب کړئ، لکه څنګه چې تشریح شوي رسمي اسناد. موږ به دا په راتلونکې برخه کې د اسټیو نصبولو لپاره ټیمپلیټونو رامینځته کولو لپاره وکاروو.

د اسټیو نصب کول

د اسټیو سرچینې ډاونلوډ کړئ وروستۍ خپرونه (د 1.0.5 نسخې سره د اصلي لیکوال لینک اوسنۍ نسخې ته بدل شوی، د بیلګې په توګه 1.0.6 - نږدې ژباړل.)، محتويات په یوه ډایرکټر کې استخراج کړئ، کوم چې زه به له دې وروسته غږ وکړم [istio-resources].

د اسټیو سرچینې په اسانۍ سره پیژندلو لپاره، د K8s کلستر کې د نوم ځای جوړ کړئ istio-system:

$ kubectl create namespace istio-system

ډایرکټر ته په تګ سره نصب کول بشپړ کړئ [istio-resources] او کمانډ چلول:

$ helm template install/kubernetes/helm/istio 
  --set global.mtls.enabled=false 
  --set tracing.enabled=true 
  --set kiali.enabled=true 
  --set grafana.enabled=true 
  --namespace istio-system > istio.yaml

دا کمانډ به د اسټیو کلیدي برخې فایل ته راوړي istio.yaml. موږ معیاري ټیمپلیټ د ځان سره سم بدل کړ، د لاندې پیرامیټونو مشخص کول:

• global.mtls.enabled نصب false (د مثال په توګه د mTLS تصدیق غیر فعال دی - نږدې.)زموږ د نیټې پروسې ساده کولو لپاره؛
• tracing.enabled د جیجر په کارولو سره د غوښتنې تعقیب شامل دي؛
• kiali.enabled کیالي په یوه کلستر کې نصبوي ترڅو خدمات او ترافیک لید کړي؛
• grafana.enabled ګرافانا نصبوي ترڅو راټول شوي میټریکونه وګوري.

راځئ چې د کمانډ سره تولید شوي سرچینې وکاروو:

$ kubectl apply -f istio.yaml

په کلستر کې د اسټیو نصب کول بشپړ شوي! انتظار وکړئ تر هغه چې ټول پوډونه د نوم ځای کې وي istio-system کولی شي Running او یا Completedد لاندې کمانډ په چلولو سره:

$ kubectl get pods -n istio-system

اوس موږ چمتو یو چې راتلونکې برخې ته دوام ورکړو، چیرې چې موږ به غوښتنلیک پورته او روان کړو.

د احساس تحلیل غوښتنلیک جوړښت

راځئ چې د احساساتي تحلیل مایکرو سرویس غوښتنلیک مثال وکاروو چې دمخه یې یادونه شوې Kubernetes ته د پیژندنې مقاله. دا دومره پیچلې ده چې په عمل کې د اسټیو وړتیاوې وښیې.

غوښتنلیک د څلورو مایکرو خدماتو څخه جوړ دی:

1. خدمت SA-Frontend، کوم چې د Reactjs غوښتنلیک مخکنی پای ته خدمت کوي؛
2. خدمت SA-WebApp، کوم چې د احساساتو تحلیل پوښتنو ته خدمت کوي؛
3. خدمت SA- منطق، کوم چې پخپله ترسره کوي د احساساتو تحلیل;
4. خدمت SA-فیډبیک، کوم چې د تحلیل دقت په اړه د کاروونکو څخه فیډبیک ترلاسه کوي.

پدې ډیاګرام کې، د خدماتو سربیره، موږ د انګریس کنټرولر هم ګورو، کوم چې په کوبرنیټس کې مناسبو خدماتو ته راتلونکو غوښتنو ته الرښوونه کوي. اسټیو په خپل انګریس ګیټ وے کې ورته مفهوم کاروي ، چې نور توضیحات به یې تعقیب کړي.

د اسټیو څخه د پراکسي سره د غوښتنلیک چلول

په مقاله کې ذکر شوي د نورو عملیاتو لپاره ، خپل ذخیره کلون کړئ istio-mastery. دا د کبرنیټس او اسټیو لپاره غوښتنلیک او څرګندونه لري.

د sidecars داخلول

داخل کیدی شي پخپله او یا په لاسي ډول. د دې لپاره چې په اتوماتيک ډول د سایډ کار کانټینرونه دننه کړئ، تاسو اړتیا لرئ د نوم ځای ته لیبل تنظیم کړئ istio-injection=enabled، کوم چې د لاندې کمانډ سره ترسره کیږي:

$ kubectl label namespace default istio-injection=enabled
namespace/default labeled

اوس هر پوډ چې به په ډیفالټ نوم ځای کې ځای په ځای شي (default) به خپل د سایډ کار کانټینر ترلاسه کړي. د دې تصدیق کولو لپاره ، راځئ چې د ذخیره کولو روټ لارښود ته په تګ سره د ازموینې غوښتنلیک ځای په ځای کړو [istio-mastery] او لاندې کمانډ چلول:

$ kubectl apply -f resource-manifests/kube
persistentvolumeclaim/sqlite-pvc created
deployment.extensions/sa-feedback created
service/sa-feedback created
deployment.extensions/sa-frontend created
service/sa-frontend created
deployment.extensions/sa-logic created
service/sa-logic created
deployment.extensions/sa-web-app created
service/sa-web-app created

د خدماتو ځای په ځای کولو سره ، راځئ چې وګورو چې پوډونه دوه کانټینرونه لري (د خدمت پخپله او د هغې سایډ کار سره) د قوماندې په چلولو سره kubectl get pods او ډاډ ترلاسه کړئ چې د کالم لاندې READY ارزښت مشخص شوی 2/2، سمبول چې دواړه کانټینرونه روان دي:

$ kubectl get pods
NAME                           READY     STATUS    RESTARTS   AGE
sa-feedback-55f5dc4d9c-c9wfv   2/2       Running   0          12m
sa-frontend-558f8986-hhkj9     2/2       Running   0          12m
sa-logic-568498cb4d-2sjwj      2/2       Running   0          12m
sa-logic-568498cb4d-p4f8c      2/2       Running   0          12m
sa-web-app-599cf47c7c-s7cvd    2/2       Running   0          12m

په لید کې دا داسې ښکاري:

په یوه پوډ کې د اینوای پراکسي

اوس چې غوښتنلیک پورته او روان دی، موږ به اړتیا ولرو چې راتلونکو ټرافیک ته اجازه ورکړو چې غوښتنلیک ته راشي.

د ننوتلو دروازې

د دې ترلاسه کولو لپاره غوره تمرین (په کلستر کې ترافیک ته اجازه ورکړئ) له لارې ده د ننوتلو دروازې په اسټیو کې، کوم چې د کلستر په "څنډه" کې موقعیت لري او تاسو ته اجازه درکوي د اسټیو ځانګړتیاوې فعال کړئ لکه روټینګ، د بار توازن، امنیت او د راتلونکو ټرافيکو څارنه.

د Ingress Gateway برخه او هغه خدمت چې دا په بهر کې وړاندې کوي د اسټیو نصبولو پرمهال په کلستر کې نصب شوي. د خدمت بهرنۍ IP پته موندلو لپاره، چلول:

$ kubectl get svc -n istio-system -l istio=ingressgateway
NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP
istio-ingressgateway   LoadBalancer   10.0.132.127   13.93.30.120

موږ به د دې IP په کارولو سره غوښتنلیک ته لاسرسي ته دوام ورکړو (زه به دې ته د EXTERNAL-IP په توګه اشاره وکړم) ، نو د اسانتیا لپاره به موږ ارزښت په متغیر کې ولیکو:

$ EXTERNAL_IP=$(kubectl get svc -n istio-system 
  -l app=istio-ingressgateway 
  -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')

که تاسو اوس د براوزر له لارې دې IP ته د لاسرسي هڅه وکړئ ، نو تاسو به د خدماتو نه شتون تېروتنه ترلاسه کړئ ، ځکه چې د ډیفالټ Istio ټول راتلونکی ترافیک بندوي، ګیټ وے تراوسه نه دی تعریف شوی.

د دروازې سرچینې

ګیټ وے په کوبرنیټس کې د CRD (د ګمرک سرچینې تعریف) دی چې په کلستر کې د اسټیو نصبولو وروسته تعریف شوی او د بندرونو ، پروتوکول او کوربه توب مشخص کولو وړتیا وړوي چې موږ غواړو د راتلونکي ترافیک ته اجازه ورکړو.

زموږ په قضیه کې، موږ غواړو د ټولو کوربه توب لپاره په پورټ 80 کې HTTP ټرافیک ته اجازه ورکړو. دنده د لاندې تعریف لخوا پلي کیږي (http-gateway.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: http-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
- "*"

دا ترتیب د انتخاب کونکي پرته هیڅ توضیح ته اړتیا نلري istio: ingressgateway. د دې انتخاب کونکي سره موږ کولی شو مشخص کړو چې کوم انګریس ګیټ وے ته تنظیم کول پلي کړو. زموږ په قضیه کې، دا د Ingress Gateway کنټرولر دی، کوم چې په ایستیو کې د ډیفالټ لخوا نصب شوی.

تشکیلات د لاندې کمانډ په زنګ وهلو سره پلي کیږي:

$ kubectl apply -f resource-manifests/istio/http-gateway.yaml gateway.networking.istio.io/http-gateway created

ګیټی اوس 80 پورټ ته د لاسرسي اجازه ورکوي، مګر هیڅ نه پوهیږي چې چیرته د غوښتنې الرښوونه وکړي. د دې لپاره تاسو اړتیا لرئ مجازی خدمتونه.

د مجازی خدماتو سرچینه

VirtualService د Ingress Gateway ته وايي چې څنګه هغه غوښتنې راټیټ کړي چې په کلستر کې اجازه لري.

زموږ غوښتنلیک ته چې د http-gateway له لارې راځي باید sa-frontend، sa-web-app او sa-feedback خدماتو ته واستول شي:

هغه لارې چې د VirtualServices سره تنظیم کولو ته اړتیا لري

راځئ هغه غوښتنې وګورو چې باید SA-Frontend ته واستول شي:

• د لارې په اوږدو کې دقیق میچ / باید SA-Frontend ته واستول شي ترڅو ترلاسه کړي index.html؛
• مخکینۍ لارې /static/* باید SA-Frontend ته واستول شي ترڅو په فرنټ اینډ کې کارول شوي جامد فایلونه ترلاسه کړي، لکه CSS او JavaScript؛
• لارې د منظم بیان سره سمون لري '^.*.(ico|png|jpg)$'، باید SA-Frontend ته ولیږل شي، ځکه دا هغه انځورونه دي چې په پاڼه کې ښودل شوي.

پلي کول د لاندې ترتیب لخوا ترلاسه کیږي (sa-virtualservice-external.yaml):

kind: VirtualService
metadata:
  name: sa-external-services
spec:
  hosts:
  - "*"
  gateways:
  - http-gateway                      # 1
  http:
  - match:
    - uri:
        exact: /
    - uri:
        exact: /callback
    - uri:
        prefix: /static
    - uri:
        regex: '^.*.(ico|png|jpg)

Важные моменты:



 	
 Этот VirtualService относится к запросам, приходящим через http-gateway;


 	
 В destination определяется сервис, куда отправляются запросы.




Примечание: Конфигурация выше хранится в файле sa-virtualservice-external.yaml, который также содержит настройки для маршрутизации в SA-WebApp и SA-Feedback, но был сокращён здесь в статье для лаконичности.

Применим VirtualService вызовом:

$ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml
virtualservice.networking.istio.io/sa-external-services created
Примечание: Когда мы применяем ресурсы Istio, Kubernetes API Server создаёт событие, которое получает Istio Control Plane, и уже после этого новая конфигурация применяется к прокси-серверам Envoy каждого pod'а. А контроллер Ingress Gateway представляется очередным Envoy, сконфигурированным в Control Plane. Всё это на схеме выглядит так:


Конфигурация Istio-IngressGateway для маршрутизации запросов
Приложение Sentiment Analysis стало доступным по http://{EXTERNAL-IP}/. Не переживайте, если вы получаете статус Not Found: иногда требуется чуть больше времени для того, чтобы конфигурация вступила в силу и кэши Envoy обновились.
Перед тем, как продолжить, поработайте немного с приложением, чтобы сгенерировать трафик (его наличие необходимо для наглядности в последующих действиях — прим. перев.).
Kiali : наблюдаемость
Чтобы попасть в административный интерфейс Kiali, выполните следующую команду:
$ kubectl port-forward 
    $(kubectl get pod -n istio-system -l app=kiali 
    -o jsonpath='{.items[0].metadata.name}') 
    -n istio-system 20001
… и откройте http://localhost:20001/, залогинившись под admin/admin. Здесь вы найдете множество полезных возможностей, например, для проверки конфигурации компонентов Istio, визуализации сервисов по информации, собранной при перехвате сетевых запросов, получения ответов на вопросы «Кто к кому обращается?», «У какой версии сервиса возникают сбои?» и т.п. В общем, изучите возможности Kiali перед тем, как двигаться дальше — к визуализации метрик с Grafana.

Grafana: визуализация метрик
Собранные в Istio метрики попадают в Prometheus и визуализируются с Grafana. Чтобы попасть в административный интерфейс Grafana, выполните команду ниже, после чего откройте http://localhost:3000/:
$ kubectl -n istio-system port-forward 
    $(kubectl -n istio-system get pod -l app=grafana 
    -o jsonpath={.items[0].metadata.name}) 3000
Кликнув на меню Home слева сверху и выбрав Istio Service Dashboard в левом верхнем углу, начните с сервиса sa-web-app, чтобы посмотреть на собранные метрики:

Здесь нас ждёт пустое и совершенно скучное представление — руководство никогда такое не одобрит. Давайте же создадим небольшую нагрузку следующей командой:
$ while true; do 
    curl -i http://$EXTERNAL_IP/sentiment 
    -H "Content-type: application/json" 
    -d '{"sentence": "I love yogobella"}'; 
    sleep .8; done
Вот теперь у нас гораздо более симпатичные графики, а в дополнение к ним — замечательные инструменты Prometheus для мониторинга и Grafana для визуализации метрик, что позволят нам узнать о производительности, состоянии здоровья, улучшениях/деградации в работе сервисов на протяжении времени.
Наконец, посмотрим на трассировку запросов в сервисах.
Jaeger : трассировка
Трассировка нам потребуется, потому что чем больше у нас сервисов, тем сложнее добраться до причины сбоя. Посмотрим на простой случай из картинки ниже:


Типовой пример случайного неудачного запроса
Запрос приходит, падает — в чём же причина? Первый сервис? Или второй? Исключения есть в обоих — давайте посмотрим на логи каждого. Как часто вы ловили себя за таким занятием? Наша работа больше похожа на детективов программного обеспечения, а не разработчиков…
Это широко распространённая проблема в микросервисах и решается она распределёнными системами трассировки, в которых сервисы передают друг другу уникальный заголовок, после чего эта информация перенаправляется в систему трассировки, где она сопоставляется с данными запроса. Вот иллюстрация:


Для идентификации запроса используется TraceId
В Istio используется Jaeger Tracer, который реализует независимый от вендоров фреймворк OpenTracing API. Получить доступ к пользовательского интерфейсу Jaeger можно следующей командой:
$ kubectl port-forward -n istio-system 
    $(kubectl get pod -n istio-system -l app=jaeger 
    -o jsonpath='{.items[0].metadata.name}') 16686
Теперь зайдите на http://localhost:16686/ и выберите сервис sa-web-app. Если сервис не показан в выпадающем меню — проявите/сгенерируйте активность на странице и обновите интерфейс. После этого нажмите на кнопку Find Traces, которая покажет самые последние трейсы — выберите любой — покажется детализированная информация по всем трейсам:

Этот трейс показывает:

 Запрос приходит в istio-ingressgateway (это первое взаимодействие с одним из сервисов, и для запроса генерируется Trace ID), после чего шлюз направляет запрос в сервис sa-web-app.
 В сервисе sa-web-app запрос подхватывается Envoy sidecar'ом, создаётся «ребёнок» в span'е (поэтому мы видим его в трейсах) и перенаправляется в контейнер sa-web-app. (Span — логическая единица работы в Jaeger, имеющая название, время начало операции и её продолжительность. Span'ы могут быть вложенными и упорядоченными. Ориентированный ациклический граф из span'ов образует trace. — прим. перев.)
 Здесь запрос обрабатывается методом sentimentAnalysis. Эти трейсы уже сгенерированы приложением, т.е. для них потребовались изменения в коде.
 С этого момента инициируется POST-запрос в sa-logic. Trace ID должен быть проброшен из sa-web-app.
 …

Примечание: На 4 шаге приложение должно увидеть заголовки, сгенерированные Istio, и передать их в последующие запросы, как показано на изображении ниже:


(A) За проброс заголовков отвечает Istio; (B) За заголовки отвечают сервисы
Istio делает основную работу, т.к. генерирует заголовки для входящих запросов, создаёт новые span'ы в каждом sidecare'е и пробрасывает их. Однако без работы с заголовками внутри сервисов полный путь трассировки запроса будет утерян.
Необходимо учитывать (пробрасывать) следующие заголовки:
x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
x-ot-span-context
Это несложная задача, однако для упрощения её реализации уже существует множество библиотек — например, в сервисе sa-web-app клиент RestTemplate пробрасывает эти заголовки, если просто добавить библиотеки Jaeger и OpenTracing в его зависимости.
Заметьте, что приложение Sentiment Analysis демонстрирует реализации на Flask, Spring и ASP.NET Core.
Теперь, когда стало ясно, что мы получаем из коробки (или почти «из коробки»), рассмотрим вопросы тонко настраиваемой маршрутизации, управления сетевым трафиком, безопасности и т.п.!
Прим. перев.: об этом читайте в следующей части материалов по Istio от Rinor Maloku, переводы которых последуют в нашем блоге в ближайшее время. UPDATE (14 марта): Вторая часть уже опубликована.
P.S. от переводчика
Читайте также в нашем блоге:

 «Назад к микросервисам вместе с Istio»: часть 2 (маршрутизация, управление трафиком), часть 3 (аутентификация и авторизация);
 «Conduit — легковесный service mesh для Kubernetes»;
 «Что такое service mesh и почему он мне нужен [для облачного приложения с микросервисами]?»;
 «Иллюстрированное руководство по устройству сети в Kubernetes. Части 1 и 2»;
 «Как этот sidecar-контейнер оказался здесь [в Kubernetes]?».

Источник: habr.com
route:

- destination:

host: sa-frontend             # 2

port:

number: 80

مهم ټکي:

 دا مجازی خدمت هغه غوښتنو ته اشاره کوي چې له لارې راځي http-دروازه;
 В destination هغه خدمت چې غوښتنې لیږل کیږي ټاکل کیږي.

تبصره: پورته ترتیب په یوه فایل کې زیرمه شوی دی sa-virtualservice-external.yaml, کوم چې په SA-WebApp او SA-Feedback کې د روټینګ لپاره ترتیبات هم لري، مګر دلته د لنډیز لپاره په مقاله کې لنډ شوي.
راځئ چې په زنګ وهلو سره VirtualService پلي کړو:

تبصره: کله چې موږ د اسټیو سرچینې مصرف کوو، د کوبرنیټس API سرور یوه پیښه رامینځته کوي چې د اسټیو کنټرول پلان لخوا ترلاسه کیږي، او له هغې وروسته نوی ترتیب د هر پوډ انوی پراکسي باندې پلي کیږي. او د Ingress Gateway کنټرولر داسې ښکاري چې د کنټرول په الوتکه کې ترتیب شوی بل سفیر وي. دا ټول په انځور کې داسې ښکاري:


د غوښتنې روټینګ لپاره Istio-IngressGateway ترتیب
د احساس تحلیل غوښتنلیک اوس شتون لري http://{EXTERNAL-IP}/. اندیښنه مه کوئ که تاسو د نه موندلو حالت ترلاسه کړئ: ځینې ​​​​وختونه دا د ترتیب لپاره یو څه وخت نیسي چې اغیز وکړي او د نوي کیچ تازه کول.
مخکې لدې چې پرمخ لاړشئ ، د ترافیک رامینځته کولو لپاره یو څه د ایپ سره لوبې وکړئ. (د دې شتون په راتلونکو کړنو کې د وضاحت لپاره اړین دی - نږدې ژباړه.).
کیالي: مشاهده کول
د کیالي اداري انٹرفیس ته د رسیدو لپاره ، لاندې کمانډ چل کړئ:

... او خلاص http://localhost:20001/، د مدیر/اډمین په توګه ننوتل. دلته به تاسو ډیری ګټورې ب featuresې ومومئ ، د مثال په توګه ، د اسټیو اجزاو ترتیب چیک کول ، د شبکې غوښتنې مداخلې څخه راټول شوي معلوماتو په کارولو سره خدمتونه لیدل ، د پوښتنو ځوابونه ترلاسه کړئ "څوک له چا سره اړیکه لري؟" ، "د خدماتو کومه نسخه تجربه کوي. ناکامۍ؟" او همداسی پسی. په عموم کې، د کیالي وړتیاوې وپلټئ مخکې له دې چې د ګرافانا سره میټریکونو لیدلو ته لاړ شئ.

ګرافانا: د میټریک لید
په اسټیو کې راټول شوي میټریکونه پرومیټیوس ته ځي او د ګرافانا سره لیدل کیږي. د ګرافانا اداري انٹرفیس ته د رسیدو لپاره ، لاندې کمانډ چل کړئ او بیا خلاص کړئ http://localhost:3000/:

په مینو کې کلیک کول کور پورته کیڼ او غوره کول د اسټیو خدمت ډشبورډ په پورتنۍ ښي کونج کې، د خدمت سره پیل کړئ sa-web-appراټول شوي میټریکونو ته د کتلو لپاره:

هغه څه چې موږ ته دلته انتظار کوي یو خالي او په بشپړ ډول ستړي کوونکی فعالیت دی - مدیریت به هیڅکله دا تصویب نکړي. راځئ چې د لاندې کمانډ سره یو کوچنی بار جوړ کړو:

اوس موږ ډیر ښه ګرافونه لرو، او د دوی سربیره، د څارنې لپاره په زړه پورې پرومیټیوس وسیلې او د میټریکونو لیدلو لپاره ګرافانا چې موږ ته اجازه راکوي د وخت په تیریدو سره په خدماتو کې د فعالیت، روغتیا، پرمختګونو / تخریب په اړه زده کړه وکړو.
په نهایت کې ، راځئ چې په خدماتو کې د تعقیب غوښتنې وګورو.
Jaeger: تعقیب
موږ به تعقیب ته اړتیا ولرو ځکه چې څومره خدمتونه لرو ، د ناکامۍ لامل ته رسیدل خورا ستونزمن دي. راځئ چې د لاندې انځور څخه یو ساده قضیه وګورو:


د تصادفي ناکامې غوښتنې عادي مثال
غوښتنه راځي، راځي - لامل څه دی؟ لومړی خدمت؟ یا دوهم؟ په دواړو کې استثناوې شتون لري - راځئ چې د هر یو لاګ وګورو. تاسو څو ځله خپل ځان د دې کار کولو لپاره نیولی دی؟ زموږ کار د پراختیا کونکو په پرتله د سافټویر کشف کونکو په څیر دی ...
دا په مایکرو خدماتو کې یوه عامه ستونزه ده او د توزیع شوي تعقیب سیسټمونو لخوا حل کیږي ، په کوم کې چې خدمات یو بل ته ځانګړی سرلیک لیږدوي ، وروسته له دې چې دا معلومات د تعقیب سیسټم ته لیږل کیږي ، چیرې چې دا د غوښتنې ډیټا سره پرتله کیږي. دلته یو مثال دی:


TraceId د غوښتنې پیژندلو لپاره کارول کیږي
اسټیو د جیجر ټریسر کاروي، کوم چې د پلورونکي خپلواک OpenTracing API چوکاټ پلي کوي. تاسو کولی شئ د لاندې کمانډ سره د جیجر کارونکي انٹرفیس ته لاسرسی ومومئ:

اوس لاړ شه http://localhost:16686/ او یو خدمت وټاکئ sa-web-app. که خدمت په ډراپ-ډاون مینو کې نه وي ښودل شوی، په پاڼه کې فعالیت وښایاست / تولید کړئ او انٹرفیس تازه کړئ. له هغې وروسته، په تڼۍ کلیک وکړئ نښې ومومئ، کوم چې به وروستي نښې وښیې - کوم غوره کړئ - د ټولو نښو په اړه تفصيلي معلومات به څرګند شي:

دا نښه ښیي:

 غوښتنه راځي istio-ingressgateway (دا د یو خدماتو سره لومړی تعامل دی، او د غوښتنې لپاره ټریس ID رامینځته کیږي)، وروسته له دې چې دروازه خدمت ته غوښتنه لیږي sa-web-app.
 په خدمت کې sa-web-app غوښتنه د سفیر سایډ کار لخوا اخیستل کیږي ، یو "ماشوم" په موده کې رامینځته کیږي (له همدې امله موږ دا په نښو کې ګورو) او کانټینر ته لیږل کیږي sa-web-app. (Span - په جیجر کې د کار منطقي واحد چې نوم لري، د عملیاتو پیل وخت او موده. سپینونه ځړول کیدی شي او امر کیدی شي. د سپانونو یو لارښود ایسکلیک ګراف یو ټریس جوړوي. - نږدې ژباړه.)
 دلته غوښتنه د میتود لخوا پروسس کیږي د احساساتو تحلیل. دا نښې لا دمخه د غوښتنلیک لخوا رامینځته شوي ، i.e. دوی د کوډ بدلونونو ته اړتیا درلوده.
 له دې شیبې څخه ، د POST غوښتنه په کې پیل کیږي منطق. د ټریس ID باید له دې ځایه لیږل کیږي sa-web-app.
 ...

تبصره: په 4 ګام کې، غوښتنلیک باید د Istio لخوا رامینځته شوي سرلیکونه وګوري او راتلونکو غوښتنو ته یې وسپاري لکه څنګه چې په لاندې عکس کې ښودل شوي:


(A) Istio د سرلیکونو لیږلو مسولیت لري؛ (ب) خدمتونه د سرلیکونو لپاره مسؤل دي
Istio ډیری کار کوي ځکه چې ... د راتلونکو غوښتنو لپاره سرلیکونه رامینځته کوي ، په هر اړخ پاملرنې کې نوي سپانونه رامینځته کوي او دوی ته یې لیږدوي. په هرصورت، د خدماتو دننه د سرلیکونو سره کار کولو پرته، د بشپړ غوښتنې ټریس لاره به له لاسه ورکړي.
لاندې سرلیکونه باید په پام کې ونیول شي:

دا ستونزمن کار نه دی، مګر د پلي کولو ساده کول لا دمخه شتون لري ډیری کتابتونونه - د مثال په توګه، په sa-web-app خدمت کې، د RestTemplate مراجع دا سرلیکونه وړاندې کوي که تاسو په ساده ډول د جیجر او اوپن ټریسنګ کتابتونونه اضافه کړئ د هغه روږديتوب.
په یاد ولرئ چې د احساس تحلیل غوښتنلیک په فلاسک، پسرلي، او ASP.NET کور کې پلي کول ښیې.
اوس چې دا روښانه ده چې موږ له بکس څخه څه ترلاسه کوو (یا نږدې د بکس څخه بهر) ، راځئ چې د ښه تنظیم شوي لارې ، د شبکې ترافیک مدیریت ، امنیت او داسې نور وګورو!
نوټ. ژباړه: د دې په اړه د رینور مالوکو څخه په اسټیو کې د موادو په راتلونکې برخه کې ولولئ، چې ژباړې به یې په نږدې راتلونکي کې زموږ په بلاګ کې تعقیب شي. تازه (د مارچ ۱۴مه): دوهمه برخه لا دمخه خپور شوی.
PS د ژباړونکي څخه
زموږ په بلاګ کې هم ولولئ:

 "د اسټیو سره مایکرو خدماتو ته بیرته": دویمه برخه (روټینګ، د ترافیک کنټرول), دریمه برخه (تصدیق او جواز);
 «کنډیټ - د Kubernetes لپاره د لږ وزن خدمت میش»
 «د خدمت میش څه شی دی او زه ولې اړتیا لرم [د مایکرو خدماتو سره د کلاوډ غوښتنلیک لپاره]؟»
 «په Kubernetes کې د شبکې کولو لپاره یو روښانه لارښود. ۱ او ۲ برخه»
 «دا سایډ کار کانټینر څنګه دلته [په کوبرنیټس کې] پای ته ورسید؟".

سرچینه: www.habr.com