🥇Назад да мікрасэрвісаў разам з Istio. Частка 1

Заўв. перав.: Service mesh'і вызначана сталі актуальным рашэннем у сучаснай інфраструктуры для прыкладанняў, наступных мікрасэрвіснай архітэктуры. Хоць Istio можа быць на слыху ў шматлікіх DevOps-інжынераў, гэта даволі новы прадукт, які, будучы комплексным у сэнсе якія прадстаўляюцца магчымасцяў, можа запатрабаваць значнага часу для знаёмства. Нямецкі інжынер Rinor Maloku, які адказвае за хмарныя вылічэнні для буйных кліентаў у тэлекамунікацыйнай кампаніі Orange Networks, напісаў выдатны цыкл матэрыялаў, што дазваляюць досыць хутка і глыбока пагрузіцца ў Istio. Пачынае ж ён сваё апавяданне з таго, што наогул умее Istio і як на гэта можна хутка паглядзець на ўласныя вочы.

Ісціё - Open Source-праект, распрацаваны пры супрацоўніцтве каманд з Google, IBM і Lyft. Ён вырашае складанасці, якія ўзнікаюць у прыкладаннях, заснаваных на мікрасэрвісах, напрыклад, такія як:

Упраўленне трафікам: таймаўты, паўторныя спробы, балансіроўка нагрузкі;
бяспеку: аўтэнтыфікацыя і аўтарызацыя канчатковага карыстальніка;
Назіральнасць: трасіроўка, маніторынг, лагіраванне.

Усе яны могуць быць вырашаны на ўзроўні прыкладання, аднак пасля гэтага вашыя сэрвісы перастануць быць "мікра". Усе дадатковыя намаганні па рашэнні гэтых праблем – лішні выдатак рэсурсаў кампаніі, якія маглі б выкарыстоўвацца непасрэдна для бізнес-каштоўнасцяў. Разгледзім прыклад:

Мэнэджар праектаў: Як доўга дадаваць магчымасць зваротнай сувязі?
Распрацоўшчык: Два спрынты.

МП: Што?.. Гэта ж усяго толькі CRUD!
Р: Зрабіць CRUD - простая частка задачы, але нам яшчэ спатрэбіцца аўтэнтыфікаваць і аўтарызоўваць карыстальнікаў і сэрвісы. Паколькі сетка ненадзейная, спатрэбіцца рэалізаваць паўторныя запыты, а таксама патэрн circuit breaker у кліентах. Яшчэ, каб пераканацца, што ўся сістэма не ўпала, спатрэбяцца таймаўты і пераборкі (Больш падрабязна аб абодвух згаданых патэрна гл. далей у артыкуле - заўв. перакл.), а для таго, каб выяўляць праблемы, спатрэбіцца маніторынг, трасіроўка, […]
МП: Ох, давайце тады проста ўставім гэтую фічу ў сэрвіс Product.

Думаю, ідэя зразумелая: аб'ём крокаў і намаганняў, якія патрабуюцца для дадання аднаго сэрвісу, велізарны. У гэтым артыкуле мы разгледзім, як Istio ліквідуе ўсе згаданыя вышэй складанасці (якія не з'яўляюцца мэтавымі для бізнес-логікі) з сэрвісаў.

Заўвага: Артыкул мяркуе, што ў вас ёсць практычныя веды па Kubernetes. У іншым выпадку рэкамендую прачытаць маё ўвядзенне ў Kubernetes і толькі пасля гэтага працягнуць чытанне дадзенага матэрыялу.

Ідэя Istio

У свеце без Istio адзін сэрвіс робіць прамыя запыты да іншага, а ў выпадку збою сэрвіс павінен сам апрацаваць яго: распачаць новую спробу, прадугледзець таймаўт, адкрыць circuit breaker і да т.п.

Сеткавы трафік у Kubernetes

Istio жа прапануе спецыялізаванае рашэнне, цалкам адлучанае ад сэрвісаў і якое функцыянуе шляхам умяшання ў сеткавае ўзаемадзеянне. І такім чынам яно рэалізуе:

адмоваўстойлівасць: абапіраючыся на код статусу ў адказе, яно разумее, ці адбыўся збой у запыце, і выконвае яго паўторна.
Канарэечныя выкаты: перанакіроўвае на новую версію сэрвісу толькі фіксаваную працэнтам колькасць запытаў.
Маніторынг і метрыкі: за які час сэрвіс адказаў?
Трасіроўка і назіральнасць: дадае спецыяльныя загалоўкі ў кожны запыт і выконвае іх трасіроўку ў кластары.
бяспеку: здабывае JWT-токен, аўтэнтыфікуе і аўтарызуе карыстальнікаў.

Гэта толькі некаторыя з магчымасцяў (сапраўды толькі некаторыя!), каб заінтрыгаваць вас. А зараз давайце пагрузімся ў тэхнічныя падрабязнасці!

Архітэктура Istio

Istio перахапляе ўвесь сеткавы трафік і прымяняе да яго набор правілаў, устаўляючы ў кожны pod разумны проксі ў выглядзе sidecar-кантэйнера. Проксі, якія актывуюць усе магчымасці, утвараюць сабой Плоскасць дадзеных, і яны могуць дынамічна наладжвацца з дапамогай Плоскасць кіравання.

Плоскасць дадзеных

Устаўляемыя ў pod'ы проксі дазваляюць Istio з лёгкасцю дамагчыся адпаведнасці патрэбным нам патрабаванням. Напрыклад, праверым функцыі паўторных спроб і circuit breaker.

Як retries і circuit breaking рэалізаваны ў Envoy

падагульнім:

пасланнік (гаворка пра проксі, які знаходзіцца ў sidecar-кантэйнеры, які распаўсюджваецца і як асобны прадукт - заўв. перав.) адпраўляе запыт першаму асобніку сэрвісу B і адбываецца збой.
Envoy Sidecar прадпрымае паўторную спробу (retry). (1)
Запыт са збоем вяртаецца таму, хто выклікаў яго проксі.
Так адчыняецца Circuit Breaker і адбываецца выклік наступнага сэрвісу для наступных запытаў. (2)

Гэта азначае, што вам не давядзецца выкарыстоўваць чарговую бібліятэку Retry, не давядзецца рабіць сваю рэалізацыю Circuit Breaking і Service Discovery на мове праграмавання X, Y або Z. Усё гэта і многае іншае даступна са скрынкі ў Istio і не патрабуе ніякіх змен у кодзе.

Выдатна! Цяпер вы можаце захацець адправіцца ў ваяж з Istio, але ўсё яшчэ ёсць нейкія сумневы, адкрытыя пытанні. Калі гэтае ўніверсальнае рашэнне на ўсе выпадкі ў жыцці, то ў вас узнікае заканамернае падазрэнне: бо ўсе такія рашэнні ў рэчаіснасці апыняюцца не падыходнымі ні для якога выпадку.

І вось нарэшце вы спытаеце: "Яно наладжваецца?"

Цяпер вы гатовыя да марскога падарожжа - і давайце ж пазнаёмімся з Control Plane.

Плоскасць кіравання

Ён складаецца з трох кампанентаў: Пілот, Змяшальнік и Citadel, - якія сумеснымі намаганнямі наладжваюць Envoy'і для маршрутызацыі трафіку, ужываюць палітыкі і збіраюць тэлеметрычныя дадзеныя. Схематычна ўсё гэта выглядае так:

Узаемадзеянне Control Plane з Data Plane

Envoy'і (г.зн. data plane) сканфігураваны з дапамогай Kubernetes CRD (Custom Resource Definitions), вызначанымі Istio і спецыяльна прызначанымі для гэтай мэты. Для вас гэта азначае, што яны прадстаўляюцца чарговым рэсурсам у Kubernetes са знаёмым сінтаксісам. Пасля стварэння гэты рэсурс будзе падабраны control plane'ам і ўжыты да Envoy'ям.

Стаўленне сэрвісаў да Istio

Мы апісалі стаўленне Istio да сэрвісаў, але не зваротнае: як жа сэрвісы ставяцца да Istio?

Шчыра кажучы, аб прысутнасці Istio сэрвісам вядома гэтак жа добра, як рыбам – аб вадзе, калі яны пытаюцца ў сябе: «Што наогул такое вада?».

ілюстрацыя Victoria Dimitrakopoulos: - Як вам вада? - Што наогул такое вада?

Такім чынам, вы можаце ўзяць працоўны кластар і пасля дэплою кампанентаў Istio сэрвісы, змешчаныя ў ім, працягнуць працаваць, а пасля ўхілення гэтых кампанентаў – зноў усё будзе добра. Зразумелая справа, што пры гэтым вы страціце магчымасці, якія прадстаўляюцца Istio.

Дастаткова тэорыі – давайце перанясём гэтыя веды ў практыку!

Istio на практыцы

Istio патрабуе кластара Kubernetes, у якім прынамсі даступныя 4 vCPU і 8 Гб RAM. Каб хутка падняць кластар і прытрымлівацца інструкцый з артыкула, рэкамендую скарыстацца Google Cloud Platform, якая прапануе новым карыстальнікам бясплатныя $300.

Пасля стварэння кластара і налады доступу да Kubernetes праз кансольную ўтыліту можна ўсталяваць Istio праз пакетны мэнэджар Helm.

Ўстаноўка Helm

Усталюйце кліент Helm на сваім кампутары, як расказваюць у афіцыйнай дакументацыі. Яго мы будзем выкарыстоўваць для генерацыі шаблонаў для ўстаноўкі Istio у наступным раздзеле.

Ўстаноўка Istio

Запампуйце рэсурсы Istio з апошняга рэлізу (арыгінальная аўтарская спасылка на версію 1.0.5 зменена на актуальную, г.зн. 1.0.6 — заўв. перакл.), дастаньце змесціва ў адну дырэкторыю, якую я буду ў далейшым называць [istio-resources].

Для прастаты ідэнтыфікацыі рэсурсаў Istio стварыце ў кластары 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 у файл istio.yaml. Мы змянілі стандартны шаблон пад сябе, паказаўшы наступныя параметры:

global.mtls.enabled ўстаноўлена ў false (г.зн. mTLS-аўтэнтыфікацыя адключаная - заўв перакл.), каб спрасціць наш працэс знаёмства;
tracing.enabled уключае трасіроўку запытаў з дапамогай Jaeger;
kiali.enabled устанаўлівае Kiali у кластар для візуалізацыі сэрвісаў і трафіку;
grafana.enabled устанаўлівае Grafana для візуалізацыі сабраных метрык.

Ужыем згенераваныя рэсурсы камандай:

$ kubectl apply -f istio.yaml

Ўстаноўка Istio ў кластар завершана! Дачакайцеся, пакуль усе pod'ы ў прасторы імён istio-system апынуцца ў стане Running або Completed, выканаўшы каманду ніжэй:

$ kubectl get pods -n istio-system

Цяпер мы гатовыя працягнуць у наступным раздзеле, дзе падымем і запусцім прыкладанне.

Архітэктура прыкладання Sentiment Analysis

Скарыстаемся прыкладам мікрасэрвіснага дадатку Sentiment Analysis, выкарыстанага ва ўжо згаданай артыкуле-ўвядзенні ў Kubernetes. Яно дастаткова складанае, каб паказаць магчымасці Istio на практыцы.

Прыкладанне складаецца з чатырох мікрасэрвісаў:

Сэрвіс SA-Frontend, Які абслугоўвае фронтэнд прыкладання на Reactjs;
Сэрвіс SA-WebApp, які абслугоўвае запыты Sentiment Analysis;
Сэрвіс SA-Logic, які выконвае сам сентымент-аналіз;
Сэрвіс SA-Feedback, які атрымлівае ад карыстальнікаў зваротную сувязь аб дакладнасці праведзенага аналізу.

На гэтай схеме апроч сэрвісаў мы бачым таксама Ingress Controller, які ў Kubernetes маршрутызуе ўваходныя запыты на якія адпавядаюць сэрвісы. У Istio выкарыстоўваецца падобная канцэпцыя ў рамках Ingress Gateway, падрабязнасці аб якім рушаць услед.

Запуск прыкладання з проксі ад Istio

Для далейшых аперацый, якія згадваюцца ў артыкуле, склануйце сабе рэпазітар istio-mastery. У ім змяшчаюцца дадатак і маніфесты для Kubernetes і Istio.

Устаўка sidecar'аў

Устаўка можа быць зроблена аўтаматычна або ўручную. Для аўтаматычнай устаўкі sidecar-кантэйнераў спатрэбіцца выставіць прасторы імёнаў лэйбл istio-injection=enabled, што робіцца наступнай камандай:

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

Цяпер кожны pod, які будзе разгортвацца ў прасторы імёнаў па змаўчанні (default) атрымае свой sidecar-кантэйнер. Каб пераканацца ў гэтым, давайце задэплоім тэставы дадатак, перайшоўшы ў каранёвы каталог рэпазітара. [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

Разгарнуўшы сэрвісы, праверым, што ў pod'ов па двух кантэйнера (з самім сэрвісам і яго sidecar'ом), выканаўшы каманду 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

Візуальна гэта ўяўляецца так:

Проксі Envoy у адным з pod'аў

Цяпер, калі прыкладанне паднята і функцыянуе, нам спатрэбіцца дазволіць ўваходзіць трафіку прыходзіць у дадатак.

Ingress Gateway

Лепшая практыка дамагчыся гэтага (дазволіць трафік у кластары) - праз Ingress Gateway у Istio, што размяшчаецца ў «мяжы» кластара і дазваляе ўключаць для ўваходнага трафіку такія функцыі Istio, як маршрутызацыя, балансаванне нагрузкі, бяспека і маніторынг.

Кампанент Ingress Gateway і сэрвіс, які пракідвае яго па-за, былі ўсталяваныя ў кластар падчас усталёўкі Istio. Каб даведацца пра знешні 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 праз браўзэр, то атрымаеце памылку Service Unavailable, т.я. па змаўчанні Istio блакуе ўвесь уваходны трафік, пакуль не вызначаны Gateway.

Рэсурс Gateway

Gateway - гэта CRD (Custom Resource Definition) у Kubernetes, які вызначаецца пасля ўсталёўкі Istio у кластары і які актывуе магчымасць паказваць парты, пратакол і хасты, для якіх мы жадаем дазволіць уваходны трафік.

У нашым выпадку мы жадаем дазволіць HTTP-трафік на 80-й порт для ўсіх хастоў. Задача рэалізуецца наступным азначэннем (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 ужыць канфігурацыю. У нашым выпадку такім з'яўляецца кантролер Ingress Gateway, які быў па змаўчанні ўсталяваны ў Istio.

Канфігурацыя прымяняецца выклікам наступнай каманды:

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

Цяпер шлюз дазваляе доступ да порта 80, але не мае ўяўленні аб тым, куды маршрутызаваць запыты. Для гэтага спатрэбяцца Віртуальныя паслугі.

Рэсурс VirtualService

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)$'
    route:
    - destination:
        host: sa-frontend             # 2
        port:
number: 80

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

Гэты 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

Клікнуўшы на меню Галоўная злева зверху і выбраўшы 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. (пралёт - лагічная адзінка працы ў 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, пераклады якіх рушаць услед у нашым блогу хуткім часам. АБНАЎЛЕННЕ (14 сакавіка): другая частка ужо апублікавана.

PS ад перакладчыка

Чытайце таксама ў нашым блогу:

Крыніца: habr.com

Назад да мікрасэрвісаў разам з Istio. Частка 1