Kthehu te mikroshërbimet me Istio. Pjesa 1

Shënim. përkth.: Rrjetat e shërbimit janë bërë padyshim një zgjidhje e rëndësishme në infrastrukturën moderne për aplikimet që ndjekin arkitekturën e mikroservisit. Ndërsa Istio mund të jetë në buzët e shumë inxhinierëve të DevOps, ai është një produkt mjaft i ri që, megjithëse gjithëpërfshirës për sa i përket aftësive që ofron, mund të kërkojë një kohë të konsiderueshme për t'u njohur me të. Inxhinieri gjerman Rinor Maloku, i cili është përgjegjës për kompjuterin cloud për klientët e mëdhenj në kompaninë e telekomunikacionit Orange Networks, ka shkruar një seri të mrekullueshme materialesh që ju lejojnë të zhyteni shpejt dhe thellë në Istio. Ai e fillon rrëfimin e tij me atë që Istio mund të bëjë në përgjithësi dhe si mund ta shihni shpejt me sytë tuaj.

Istio — Një projekt me burim të hapur i zhvilluar në bashkëpunim me ekipe nga Google, IBM dhe Lyft. Ai zgjidh kompleksitetet që lindin në aplikacionet e bazuara në mikroshërbime, të tilla si:

• Menaxhimi i Trafikut: afatet, riprovimet, balancimi i ngarkesës;
• siguri: vërtetimi dhe autorizimi i përdoruesit fundor;
• Vëzhgueshmëria: gjurmimi, monitorimi, prerjet.

Të gjitha këto mund të zgjidhen në nivelin e aplikacionit, por pas kësaj shërbimet tuaja nuk do të jenë më "mikro". E gjithë përpjekja shtesë për të zgjidhur këto probleme është një humbje e burimeve të kompanisë që mund të përdoren drejtpërdrejt për vlerën e biznesit. Le të shohim një shembull:

Menaxheri i projektit: Sa kohë duhet për të shtuar një veçori reagimi?
Zhvilluesi: Dy sprinte.

Deputeti: Çfarë?.. Është thjesht BRUTO!
R: Bërja e CRUD është pjesa e lehtë, por ne ende duhet të vërtetojmë dhe autorizojmë përdoruesit dhe shërbimet. Meqenëse rrjeti nuk është i besueshëm, do t'ju duhet të zbatoni kërkesa të përsëritura, si dhe modeli i ndërprerësit në klientët. Gjithashtu, për t'u siguruar që i gjithë sistemi të mos rrëzohet, do t'ju duhen ndërprerje dhe balluket (për më shumë detaje rreth të dy modeleve të përmendura, shih më vonë në artikull - përafërsisht përkth.), dhe për të zbuluar problemet, monitorimin, gjurmimin, […]

MP: Oh, atëherë le ta fusim këtë veçori në shërbimin e produktit.

Unë mendoj se ideja është e qartë: sasia e hapave dhe përpjekjeve të nevojshme për të shtuar një shërbim është e madhe. Në këtë artikull, ne do të shohim se si Istio heq të gjithë kompleksitetin e përmendur më lart (që nuk synohet të jetë logjikë biznesi) nga shërbimet.

Shënim: Ky artikull supozon se ju keni njohuri pune për Kubernetes. Përndryshe, ju rekomandoj të lexoni prezantimi im në Kubernetes dhe vetëm pas kësaj vazhdoni ta lexoni këtë material.

Istio ide

Në një botë pa Istio, një shërbim i bën kërkesa të drejtpërdrejta një tjetri dhe në rast të një dështimi, shërbimi duhet ta trajtojë vetë: të bëjë një përpjekje të re, të sigurojë një afat kohor, të hapë një ndërprerës etj.

Trafiku i rrjetit në Kubernetes

Istio ofron një zgjidhje të specializuar, tërësisht të ndarë nga shërbimet dhe funksionon duke ndërhyrë në komunikimin në rrjet. Dhe kështu zbaton:

• toleranca ndaj gabimeve: Bazuar në kodin e statusit në përgjigje, kupton nëse kërkesa dështoi dhe e riekzekuton atë.
• Përhapja e kanarinave: ridrejton vetëm një përqindje fikse të kërkesave në versionin e ri të shërbimit.
• Monitorimi dhe metrika: Sa kohë u desh që shërbimi të përgjigjej?
• Gjurmimi dhe vrojtueshmëria: Shton tituj të veçantë për çdo kërkesë dhe i gjurmon ato nëpër grup.
• siguri: Merr shenjën JWT, vërteton dhe autorizon përdoruesit.

Këto janë vetëm disa nga mundësitë (në të vërtetë vetëm disa!) për t'ju intriguar. Tani le të zhytemi në detajet teknike!

Arkitektura Istio

Istio përgjon të gjithë trafikun e rrjetit dhe zbaton një sërë rregullash për të, duke futur një përfaqësues inteligjent në formën e një kontejneri anësor në çdo pod. Proxies që aktivizojnë të gjitha aftësitë formojnë a Plani i të dhënave, dhe ato mund të konfigurohen në mënyrë dinamike duke përdorur Avioni i kontrollit.

Plani i të dhënave

Proxies të futura në pods lejojnë Istio të përmbushë lehtësisht kërkesat që na duhen. Për shembull, le të kontrollojmë funksionet e riprovës dhe ndërprerësit.

Si zbatohen përsëritjet dhe ndërprerja e qarkut në Envoy

Përmbledhur:

1. i dërguar (po flasim për një përfaqësues të vendosur në një enë anësore, e cila shpërndahet si produkt i veçantë - përafërsisht. përkth.) dërgon një kërkesë në shkallën e parë të shërbimit B dhe dështon.
2. I dërguari Sidecar përpiqet përsëri (provo sërish). (1)
3. Kërkesa dështon dhe i kthehet përfaqësuesit që e ka thirrur.
4. Kjo hap Circuit Breaker dhe thërret shërbimin tjetër për kërkesat e mëvonshme. (2)

Kjo do të thotë që ju nuk keni nevojë të përdorni një bibliotekë tjetër "Riprovoni", nuk keni nevojë të bëni vetë zbatimin tuaj të Circuit Breaking dhe Service Discovery në gjuhën e programimit X, Y ose Z. E gjithë kjo dhe shumë më tepër janë të disponueshme jashtë kutisë në Istio dhe nuk kërkon jo ndryshimet në kod.

E shkëlqyeshme! Tani mund të dëshironi të shkoni në një udhëtim me Istio, por keni ende disa dyshime, pyetje të hapura. Nëse kjo është një zgjidhje universale për të gjitha rastet e jetës, atëherë ju keni një dyshim të natyrshëm: në fund të fundit, të gjitha zgjidhjet e tilla në realitet rezultojnë të papërshtatshme për çdo rast.

Dhe në fund ju pyesni: "A është i personalizueshëm?"

Tani jeni gati për udhëtimin detar, le të njihemi me Planin e Kontrollit.

Avioni i kontrollit

Ai përbëhet nga tre komponentë: Pilot, mikser и Kala, të cilat punojnë së bashku për të konfiguruar të dërguarit për të drejtuar trafikun, për të zbatuar politika dhe për të mbledhur të dhëna telemetrike. Skematikisht gjithçka duket kështu:

Ndërveprimi i planit të kontrollit me planin e të dhënave

Të dërguarit (d.m.th. rrafshi i të dhënave) konfigurohen duke përdorur Kubernetes CRD (Custom Resource Definitions) të përcaktuara nga Istio dhe të destinuara posaçërisht për këtë qëllim. Çfarë do të thotë kjo për ju është se ato duket se janë vetëm një burim tjetër në Kubernetes me një sintaksë të njohur. Pasi të krijohet, ky burim do të merret nga avioni i kontrollit dhe do të aplikohet te të dërguarit.

Marrëdhënia e shërbimeve me Istio

Ne kemi përshkruar marrëdhënien e Istios me shërbimet, por jo të kundërtën: si lidhen shërbimet me Istio?

Për të qenë i sinqertë, shërbimet janë po aq të vetëdijshme për praninë e Istios sa peshqit për ujin kur pyesin veten: "Çfarë është uji gjithsesi?"

ilustrim Victoria Dimitrakopoulos: - Si ju pëlqen uji? - Çfarë është uji gjithsesi?

Kështu, ju mund të merrni një grup pune dhe pas vendosjes së komponentëve Istio, shërbimet e vendosura në të do të vazhdojnë të punojnë dhe pas heqjes së këtyre komponentëve, gjithçka do të jetë përsëri mirë. Është e qartë se në këtë rast do të humbisni aftësitë e ofruara nga Istio.

Mjaft teori - le ta zbatojmë këtë njohuri në praktikë!

Istio në praktikë

Istio kërkon një grup Kubernetes me të paktën 4 vCPU dhe 8 GB RAM në dispozicion. Për të vendosur shpejt një grup dhe për të ndjekur udhëzimet nga artikulli, unë rekomandoj përdorimin e Google Cloud Platform, e cila u ofron përdoruesve të rinj 300 dollarë falas.

Pas krijimit të një grupi dhe konfigurimit të aksesit në Kubernetes përmes programit të konsolës, mund të instaloni Istio përmes menaxherit të paketave Helm.

Instalimi i timonit

Instaloni klientin Helm në kompjuterin tuaj, siç përshkruhet në dokumentacion zyrtar. Ne do ta përdorim këtë për të gjeneruar shabllone për instalimin e Istio në seksionin tjetër.

Instalimi i Istio

Shkarkoni burimet e Istio nga lëshimi i fundit (Lidhja e autorit origjinal me versionin 1.0.5 është ndryshuar në atë aktualin, d.m.th. 1.0.6 - përafërsisht përkth.), ekstraktoni përmbajtjen në një direktori, të cilën do ta thërras tani e tutje [istio-resources].

Për të identifikuar me lehtësi burimet Istio, krijoni një hapësirë ​​emri në grupin K8s istio-system:

$ kubectl create namespace istio-system

Përfundoni instalimin duke shkuar te drejtoria [istio-resources] dhe ekzekutoni komandën:

$ 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

Kjo komandë do të nxjerrë përbërësit kryesorë të Istio në një skedar istio.yaml. Ne modifikuam shabllonin standard për t'iu përshtatur vetes, duke specifikuar parametrat e mëposhtëm:

• global.mtls.enabled instaluar në false (d.m.th. vërtetimi mTLS është i çaktivizuar - përafërsisht)për të thjeshtuar procesin tonë të takimit;
• tracing.enabled përfshin gjurmimin e kërkesave duke përdorur Jaeger;
• kiali.enabled instalon Kiali në një grup për të vizualizuar shërbimet dhe trafikun;
• grafana.enabled instalon Grafana për të vizualizuar metrikat e mbledhura.

Le të përdorim burimet e krijuara me komandën:

$ kubectl apply -f istio.yaml

Instalimi i Istio në grup ka përfunduar! Prisni derisa të gjitha grupet të jenë në hapësirën e emrave istio-system do të jetë në gjendje të Running ose Completedduke ekzekutuar komandën e mëposhtme:

$ kubectl get pods -n istio-system

Tani jemi gati të vazhdojmë në seksionin tjetër, ku do ta vëmë në funksion aplikacionin.

Arkitektura e aplikacionit të Analizës së Sentimentit

Le të përdorim shembullin e aplikacionit të mikroshërbimit të Analizës së Sentimentit të përdorur në sa më sipër Artikulli hyrës në Kubernetes. Është mjaft komplekse për të treguar aftësitë e Istios në praktikë.

Aplikacioni përbëhet nga katër mikroshërbime:

1. Shërbim SA-Frontend, i cili shërben në frontend të një aplikacioni Reactjs;
2. Shërbim SA-WebApp, e cila shërben për pyetjet e analizës së ndjenjave;
3. Shërbim SA-Logjika, e cila kryen vetë analiza e ndjenjave;
4. Shërbim SA-Feedback, e cila merr reagime nga përdoruesit për saktësinë e analizës.

Në këtë diagram, përveç shërbimeve, shohim edhe kontrolluesin e hyrjes, i cili në Kubernetes drejton kërkesat hyrëse në shërbimet e duhura. Istio përdor një koncept të ngjashëm brenda portës së tij Ingress, më shumë detaje për të cilat do të vijojnë.

Ekzekutimi i një aplikacioni me një përfaqësues nga Istio

Për operacione të mëtejshme të përmendura në artikull, klononi depon tuaj istio-mjeshtëri. Ai përmban aplikacionin dhe manifestohet për Kubernetes dhe Istio.

Futja e karrigeve anësore

Futja mund të bëhet automatikisht ose manualisht. Për të futur automatikisht kontejnerët e karrigeve anësore, do t'ju duhet të vendosni një etiketë në hapësirën e emrave istio-injection=enabled, e cila bëhet me komandën e mëposhtme:

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

Tani çdo pod që do të vendoset në hapësirën e emrave të paracaktuar (default) do të marrë kontejnerin e saj anësor. Për ta verifikuar këtë, le të vendosim aplikacionin e testimit duke shkuar te direktoria rrënjësore e depove [istio-mastery] dhe ekzekutoni komandën e mëposhtme:

$ 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

Pasi kemi vendosur shërbimet, le të kontrollojmë që podat kanë dy kontejnerë (me vetë shërbimin dhe karrigen e tij anësore) duke ekzekutuar komandën kubectl get pods dhe duke u siguruar që nën kolonë READY vlera e specifikuar 2/2, duke simbolizuar që të dy kontejnerët po funksionojnë:

$ 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

Vizualisht duket kështu:

Përfaqësuesi i të dërguarit në një nga grupet

Tani që aplikacioni është në funksionim, do të na duhet të lejojmë që trafiku në hyrje të hyjë në aplikacion.

Porta e hyrjes

Praktika më e mirë për ta arritur këtë (lejimi i trafikut në grup) është përmes Porta e hyrjes në Istio, i cili ndodhet në “buzë” të grupit dhe ju lejon të aktivizoni veçoritë e Istio si drejtimi, balancimi i ngarkesës, siguria dhe monitorimi për trafikun në hyrje.

Komponenti Ingress Gateway dhe shërbimi që e përcjell atë nga jashtë u instaluan në grup gjatë instalimit të Istio. Për të zbuluar adresën IP të jashtme të shërbimit, ekzekutoni:

$ 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

Ne do të vazhdojmë të aksesojmë aplikacionin duke përdorur këtë IP (do t'i referohem si EXTERNAL-IP), kështu që për lehtësi do ta shkruajmë vlerën në një ndryshore:

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

Nëse provoni të hyni në këtë IP përmes një shfletuesi tani, do të merrni një gabim Shërbimi i Padisponueshëm, sepse si parazgjedhje Istio bllokon të gjithë trafikun në hyrje, Gateway ende nuk është përcaktuar.

Burimi i portës

Gateway është një CRD (Custom Resource Definition) në Kubernetes, i përcaktuar pas instalimit të Istio në grup dhe mundëson aftësinë për të specifikuar portet, protokollin dhe hostet për të cilët duam të lejojmë trafikun në hyrje.

Në rastin tonë, ne duam të lejojmë trafikun HTTP në portin 80 për të gjithë hostet. Detyra zbatohet nga përkufizimi i mëposhtëm (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:
- "*"

Ky konfigurim nuk ka nevojë për shpjegim përveç selektorit istio: ingressgateway. Me këtë përzgjedhës mund të specifikojmë se në cilën portë hyrëse të aplikohet konfigurimi. Në rastin tonë, ky është kontrolluesi Ingress Gateway, i cili u instalua si parazgjedhje në Istio.

Konfigurimi zbatohet duke thirrur komandën e mëposhtme:

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

Gateway tani lejon hyrjen në portin 80, por nuk e ka idenë se ku t'i drejtojë kërkesat. Për këtë do t'ju duhet Shërbimet Virtuale.

Burimi VirtualService

VirtualService i tregon Portës Ingress se si të drejtojë kërkesat që lejohen brenda grupit.

Kërkesat për aplikacionin tonë që vijnë përmes http-gateway duhet të dërgohen në shërbimet sa-frontend, sa-web-app dhe sa-feedback:

Rrugët që duhet të konfigurohen me VirtualServices

Le të shohim kërkesat që duhet të dërgohen në SA-Frontend:

• Përputhja e saktë gjatë rrugës / duhet të dërgohet në SA-Frontend për të marrë index.html;
• Shtigjet e paracaktuara /static/* duhet të dërgohet në SA-Frontend për të marrë skedarë statikë të përdorur në frontend, si CSS dhe JavaScript;
• Shtigjet përputhen me shprehje të rregullta '^.*.(ico|png|jpg)$', duhet të dërgohet në SA-Frontend, sepse Këto janë fotot e shfaqura në faqe.

Zbatimi arrihet me konfigurimin e mëposhtëm (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

pika të rëndësishme:

 Ky Shërbim Virtual i referohet kërkesave që vijnë http-porta;
 В destination Përcaktohet shërbimi në të cilin dërgohen kërkesat.

Shënim: Konfigurimi i mësipërm ruhet në një skedar sa-virtualservice-external.yaml, i cili gjithashtu përmban cilësime për drejtimin në SA-WebApp dhe SA-Feedback, por është shkurtuar këtu në artikull për shkurtim.
Le të aplikojmë VirtualService duke telefonuar:

Shënim: Kur konsumojmë burimet Istio, serveri Kubernetes API krijon një ngjarje që merret nga Plani i Kontrollit Istio, dhe pas kësaj konfigurimi i ri zbatohet në përfaqësuesit Envoy të secilit pod. Dhe kontrolluesi i Portës Ingress duket të jetë një tjetër i dërguar i konfiguruar në Planin e Kontrollit. E gjithë kjo duket si kjo në diagram:


Konfigurimi Istio-IngressGateway për drejtimin e kërkesës
Aplikacioni "Analiza e ndjenjave" është tani në dispozicion http://{EXTERNAL-IP}/. Mos u shqetësoni nëse merrni statusin Nuk u gjet: Ndonjëherë duhet pak më shumë që konfigurimi të hyjë në fuqi dhe cache e Envoy të përditësohet.
Përpara se të vazhdoni, luani pak me aplikacionin për të gjeneruar trafik. (prania e tij është e nevojshme për qartësi në veprimet e mëvonshme - përafërsisht përkth.).
Kiali: vëzhgueshmëria
Për të arritur në ndërfaqen administrative Kiali, ekzekutoni komandën e mëposhtme:

... dhe të hapur http://localhost:20001/, duke u identifikuar si admin/admin. Këtu do të gjeni shumë veçori të dobishme, për shembull, për të kontrolluar konfigurimin e komponentëve Istio, për të vizualizuar shërbimet duke përdorur informacionin e mbledhur nga përgjimet e kërkesave të rrjetit, për të marrë përgjigje për pyetjet "Kush po kontakton me kë?", "Cili version i shërbimit po përjeton dështimet?” e kështu me radhë. Në përgjithësi, eksploroni aftësitë e Kiali përpara se të kaloni në vizualizimin e metrikës me Grafana.

Grafana: vizualizimi i metrikës
Metrikat e mbledhura në Istio shkojnë në Prometheus dhe vizualizohen me Grafana. Për të arritur në ndërfaqen administrative Grafana, ekzekutoni komandën më poshtë dhe më pas hapeni http://localhost:3000/:

Duke klikuar në meny Fillimi lart majtas dhe duke zgjedhur Paneli i Shërbimit Istio në këndin e sipërm majtas, filloni me shërbimin sa-web-apppër të parë matjet e mbledhura:

Ajo që na pret këtu është një performancë boshe dhe plotësisht e mërzitshme - menaxhmenti nuk do ta miratojë kurrë këtë. Le të krijojmë një ngarkesë të vogël me komandën e mëposhtme:

Tani kemi grafikë shumë më të bukur, dhe përveç tyre, mjete të mrekullueshme Prometheus për monitorim dhe Grafana për vizualizimin e metrikave që do të na lejojnë të mësojmë për performancën, shëndetin, përmirësimet / degradimin e shërbimeve me kalimin e kohës.
Së fundi, le të shohim gjurmimin e kërkesave në shërbime.
Jaeger: gjurmimi
Ne do të kemi nevojë për gjurmim, sepse sa më shumë shërbime të kemi, aq më e vështirë është të arrijmë tek shkaku i dështimit. Le të shohim një rast të thjeshtë nga fotografia më poshtë:


Shembull tipik i një kërkese të dështuar rastësore
Kërkesa vjen, bie - cila eshte arsyeja? Shërbimi i parë? Apo e dyta? Ka përjashtime në të dyja - le të shohim regjistrat e secilit. Sa shpesh e keni kapur veten duke e bërë këtë? Puna jonë është më shumë si detektivë softuerësh sesa zhvillues...
Ky është një problem i zakonshëm në mikroshërbime dhe zgjidhet nga sistemet e gjurmimit të shpërndarë, në të cilat shërbimet i kalojnë njëra-tjetrës një kokë unike, pas së cilës ky informacion përcillet në sistemin e gjurmimit, ku krahasohet me të dhënat e kërkesës. Ja një ilustrim:


TraceId përdoret për të identifikuar kërkesën
Istio përdor Jaeger Tracer, i cili zbaton kornizën OpenTracing API të pavarur nga shitësi. Ju mund të përdorni ndërfaqen e përdoruesit Jaeger me komandën e mëposhtme:

Tani shkoni në http://localhost:16686/ dhe zgjidhni një shërbim sa-web-app. Nëse shërbimi nuk shfaqet në menynë rënëse, shfaqni/gjeneroni aktivitetin në faqe dhe përditësoni ndërfaqen. Pas kësaj, klikoni në butonin Gjeni gjurmë, i cili do të tregojë gjurmët më të fundit - zgjidhni ndonjë - do të shfaqet informacion i detajuar për të gjitha gjurmët:

Kjo gjurmë tregon:

 Kërkesa vjen istio-ingressgateway (ky është ndërveprimi i parë me një nga shërbimet, dhe për kërkesën krijohet një ID gjurmë), pas së cilës porta dërgon kërkesën në shërbim sa-web-app.
 Ne sherbim sa-web-app kërkesa merret nga karriera anësore e të dërguarit, krijohet një "fëmijë" në hapësirë ​​(kjo është arsyeja pse ne e shohim atë në gjurmë) dhe ridrejtohet në kontejner sa-web-app. (Hapësirë - një njësi logjike e punës në Jaeger, e cila ka një emër, kohën e fillimit të operacionit dhe kohëzgjatjen e tij. Hapësirat mund të futen dhe të porositen. Një grafik i drejtuar jociklik i shtrirjeve formon një gjurmë. - përafërsisht. përkth.)
 Këtu kërkesa përpunohet sipas metodës Analiza e ndjenjave. Këto gjurmë janë krijuar tashmë nga aplikacioni, d.m.th. ata kërkonin ndryshime të kodit.
 Nga ky moment, një kërkesë POST inicohet në sa-logjika. ID-ja e gjurmës duhet të përcillet nga sa-web-app.
 ...

Shënim: Në hapin 4, aplikacioni duhet të shohë titujt e krijuar nga Istio dhe t'i kalojë ato në kërkesat e mëvonshme siç tregohet në imazhin më poshtë:


(A) Istio është përgjegjës për përcjelljen e kokave; (B) Shërbimet janë përgjegjëse për titujt
Istio bën pjesën më të madhe të punës sepse... gjeneron tituj për kërkesat hyrëse, krijon hapësira të reja në çdo kujdes anësor dhe i përcjell ato. Megjithatë, pa punuar me titujt brenda shërbimeve, shtegu i plotë i gjurmimit të kërkesës do të humbet.
Titujt e mëposhtëm duhet të merren parasysh:

Kjo nuk është një detyrë e vështirë, por për të thjeshtuar zbatimin e saj tashmë ekziston shumë biblioteka - për shembull, në shërbimin sa-web-app, klienti RestTemplate i përcjell këto tituj nëse thjesht shtoni bibliotekat Jaeger dhe OpenTracing në varësitë e tij.
Vini re se aplikacioni i Analizës së Sentimentit demonstron implementime në Flask, Spring dhe ASP.NET Core.
Tani që është e qartë se çfarë marrim nga kutia (ose pothuajse jashtë kutisë), le të shohim rrugën e rregulluar mirë, menaxhimin e trafikut të rrjetit, sigurinë, etj.!
Shënim. përkth.: Lexoni për këtë në pjesën tjetër të materialeve për Istio nga Rinor Maloku, përkthimet e të cilave do të pasojnë në blogun tonë në të ardhmen e afërt. UPDATE (14 mars): Pjesa e dytë tashmë është publikuar.
PS nga përkthyesi
Lexoni edhe në blogun tonë:

 "Kthehu te mikroshërbimet me Istio": pjesa 2 (drejtimi, kontrolli i trafikut), pjesa 3 (autentifikimi dhe autorizimi);
 «Përçues - rrjetë shërbimi e lehtë për Kubernetes"?
 «Çfarë është një rrjetë shërbimi dhe pse më nevojitet [për një aplikacion cloud me mikroshërbime]?"?
 «Një udhëzues i ilustruar për rrjetëzimin në Kubernetes. Pjesët 1 dhe 2"?
 «Si përfundoi këtu [në Kubernetes] ky kontejner i karrocave anësore?'.

Burimi: www.habr.com