🥇Назад към микросервизите заедно с Istio. Част 1

Прим. прев.: Service mesh определено стана актуално решение в съвременната инфраструктура за приложения, следващи микросервисната архитектура. Въпреки че Istio може да е познат на много DevOps инженери, това е сравнително нов продукт, който, будейки сложен по отношение на предоставяните възможности, може да изисква значително време за запознаване. Немският инженер Ринор Малуку, отговорен за облачните изчисления за големи клиенти в телекомуникационната компания Orange Networks, написа забележителен цикъл от материали, които позволяват бързо и дълбочинно потапяне в Istio. Той започва своя разказ с това, какво точно може да направи Istio и как можем да го разгледаме бързо с нашите собствени очи.

Istio — Open Source проект, разработен в сътрудничество между екипи от Google, IBM и Lyft. Той решава проблемите, които възникват в приложенията, базирани на микросервиси, например, следните:

Управление на трафика: таймаути, повторни опити, балансировка на натоварването;
Сигурност: аутентификация и авторизация на крайните потребители;
Наблюдаемост: трасировка, мониторинг, логване.

Всички те могат да бъдат решени на ниво приложение, но след това вашите услуги ще престанат да бъдат „микро“. Всички допълнителни усилия за решаване на тези проблеми са излишно разходване на ресурси на компанията, които биха могли да се използват директно за бизнес стойности. Нека разгледаме пример:

Мениджър на проекти: Колко време ще е нужно, за да добавим функция за обратна връзка?
Разработчик: Два спринта.
МП: Какво?.. Това е само CRUD!
Р: Да направим CRUD е лесната част от задачата, но още ще трябва да аутентифицираме и авторизираме потребители и услуги. Тъй като мрежата е ненадеждна, ще е нужно да реализираме повторни запитвания, както и период на circuit breaker в клиентите. Освен това, за да сме уверени, че цялата система не е паднала, ще са нужни таймаути и bulkheads (подробности за двата споменати патерна в статията — бел. ред.), а за да открием проблеми, ще е необходим мониторинг, трасировка, […]
МП: О, тогава просто да включим тази функция в услугата Product.

Мисля, че идеята е ясна: обемът стъпки и усилия, които са необходими за добавяне на една услуга, е огромен. В тази статия ще разгледаме как Istio премахва всички споменати по-горе усложнения (които не са целеви за бизнес логиката) от услугите.

Забележка: Статията предполага, че имате практически знания по Kubernetes. В противен случай, препоръчвам да прочетете моето въведение в Kubernetes и едва след това да продължите с четенето на този материал.

Идеята на Istio

В свят без Istio, една услуга прави директни заявки към друга, а в случай на срив, услугата трябва сама да го обработи: да направи нов опит, да предвиди таймаут, да отвори circuit breaker и т.н.

Мрежовият трафик в Kubernetes

Istio предлага специализирано решение, напълно отделено от услугите и функциониращо чрез намеса в мрежовото взаимодействие. По този начин реализира:

Отказоустойчивост: разчитайки на кода на статуса в отговора, разбира дали е възникнал срив в заявката и я изпълнява отново.
Канарски разширения: пренасочва към новата версия на услугата само фиксиран процент от заявките.
Мониторинг и метрики: за колко време отговори услугата?
Трасировка и наблюдаемост: добавя специални заглавия в всяка заявка и извършва тяхната трасировка в кластера.
Сигурност: извлича JWT-токен, удостоверява и упълномощава потребителите.

Това са само някои от възможностите (наистина само някои!), за да ви заинтригувам. Сега нека се потопим в техническите детайли!

Архитектура на Istio

Istio улавя целия мрежов трафик и прилага набор от правила, вмъквайки в всеки pod умно прокси под формата на sidecar-контейнер. Прокси, които активират всички възможности, образуват Data Plane, и те могат да бъдат динамично конфигурирани с помощта на Control Plane.

Data Plane

Вмъкнатите в pod-ове прокси позволяват на Istio лесно да отговори на нашите изисквания. Например, нека проверим функциите за повторни опити и circuit breaker.

Как retries и circuit breaking са реализирани в Envoy

Да обобщим:

Envoy (става въпрос за прокси, намиращо се в sidecar-контейнера, което се разпространява и като отделен продукт — забележка на преводача) изпраща заявка до първия екземпляр на услуга B и настъпва срив.
Envoy Sidecar прави нов опит (retry). (1)
Заявката със срива се връща на проксито, което я е извикало.
Така се отваря Circuit Breaker и се извиква следващата услуга за последващи заявки. (2)

Това означава, че не е необходимо да използвате друга библиотека за Retry, не е необходимо да правите своя собствена реализация на Circuit Breaking и Service Discovery на езика за програмиране X, Y или Z. Всичко това и много повече е налично от кутията в Istio и не изисква никаки промени в кода.

Страхотно! Сега може да искате да отпразнувате с Istio, но все още имате някакви съмнения, отворени въпроси. Ако това е универсално решение за всички случаи, то естествено възниква съмнение: наистина ли всички такива решения не са подходящи за нито един случай.

И накрая, сега ще попитате: "Настройва ли се?"

Сега сте готови за море — и нека да се запознаем с Control Plane.

Control Plane

Той се състои от три компонента: Pilot, Mixer и 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 GB 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 е зададен на неверно (т.е. mTLS удостоверяване е деактивирано — бел. прев.), за да опростим нашия процес на запознаване;
tracing.enabled включва трасировка на заявките с помощта на Jaeger;
kiali.enabled инсталира Kiali в клъстера за визуализация на услугите и трафика;
grafana.enabled инсталира Grafana за визуализация на събраните метрики.

Ще приложим генерираните ресурси с командата:

$ kubectl apply -f istio.yaml

Инсталацията на Istio в клъстера е завършена! Изчакайте, докато всички pod'ове в пространството от имена istio-system попаднат в състояние В процес на изпълнение или Завършено, изпълнявайки командата по-долу:

$ 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, който ще се разгръща в пространството по подразбиране (по подразбиране) ще получи своя sidecar контейнер. За да се уверим в това, нека разположим тестово приложение, като се преместим в коренната директория на репозитория . В този клон кодът на фронтенда е променен, за да пренасочва потребителите към Auth0 за аутентификация и да използва JWT токен в заявките към останалите услуги. Последното е реализирано по следния начин ( и изпълним следната команда:

$ 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

Най-добрата практика за постигане на това (разрешаване на трафика в клъстера) е чрез

в Istio, което се разполага на „границата“ на клъстера и позволява да активирате за входящия трафик функции на Istio, като маршрутизиране, балансиране на натоварването, сигурност и мониторинг. Най-добрата практика за постигане на това (разрешаване на трафика в клъстера) е чрез Компонентът Ingress Gateway и услугата, която го пробутва навън, бяха инсталирани в клъстера по време на инсталацията на Istio. За да научите външния IP адрес на услугата, изпълнете:

Компонент 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, но не знае накъде да маршрутизира заявките. За това са нужни Virtual Services.

Ресурс 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):

вид: VirtualService метаданни: име: sa-external-services спецификация: хостове: - "*" шлюзове: - http-gateway # 1 http: - мач: - uri: точно: \/ - uri: точно: \/callback - uri: префикс: \/static - uri: регекс: '^.*.(ico|png|jpg) Важно: Този VirtualService се отнася за заявките, постъпващи чрез http-gateway; В дестинация определява се услугата, към която се изпращат заявките. Забележка: Конфигурацията по-горе се съхранява в файла 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 създаден Забележка: Когато приложим ресурсите на Istio, Kubernetes API сървърът създава събитие, което получава 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": "Обичам йогобела"}'; 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'ове във всеки sidecar и ги предава. Въпреки това, без работа с заглавките в услугите, пълният път на трасировката на запитването ще бъде загубен. Необходимо е да се вземат предвид (предават) следните заглавки: 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
Важни моменти:

Този VirtualService се отнася за заявките, постъпващи чрез http-gateway;
В дестинация определява се услугата, към която се изпращат заявките.

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

Прилагане на VirtualService чрез извикване:

Забележка: Когато прилагаме ресурсите на 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, изпълнете следната команда:

… и отворете http://localhost:20001/, логвайки се с admin/admin. Тук ще намерите множество полезни функции, например, за проверка на конфигурацията на компонентите Istio, визуализация на услугите на базата на информация, събрана при прихващане на мрежовите заявки, получаване на отговори на въпросите "Кой с кого се свързва?", "При коя версия на услугата се получават грешки?" и т.н. В общи линии, разгледайте възможностите на Kiali, преди да продължите — към визуализацията на метриките с Grafana.

Grafana: визуализация на метриките

Събраните в Istio метрики попада в Prometheus и се визуализират с Grafana. За да получите достъп до административния интерфейс на Grafana, изпълнете командата по-долу, след което отворете http://localhost:3000/:

Щракнете върху менюто Home вляво горе и изберете Istio Service Dashboard в левия горен ъгъл, започнете със услугата sa-web-app, за да разгледате събраните метрики:

Тук ни очаква празно и напълно скучно представяне — ръководството никога няма да одобри такова. Нека създадем известен товар с командата:

Сега имаме значително по-привлекателни графики, а в допълнение на тях — страхотни инструменти Prometheus за мониторинг и Grafana за визуализация на метриките, които ще ни позволят да разберем производителността, състоянието на здравето и подобренията/влошенията в работата на услугите през времето.

Накрая, нека разгледаме трасировките на заявките в услугите.

Jaeger: трасировка

Трасировката е необходима, защото колкото повече услуги имаме, толкова по-трудно става да стигнем до причината за повредата. Нека разгледаме прост случай от изображението по-долу:

Типичен пример за случайно неуспешна заявка

Заявката идва, пада — в какво е причината? Първата услуга? Или втората? И в двете има изключения — нека разгледаме логовете на всяка. Колко често сте се улавяли в такова занятие? Нашата работа наподобява работа на софтуерни детективи, а не на разработчици…

Това е широко разпространен проблем в микросервисите и се решава чрез разпределени системи за трасировка, в които услугите предават уникален заглавие помежду си, след което тази информация се пренасочва към системата за трасировка, където тя се съпоставя с данните на заявката. Ето илюстрация:

За идентификация на заявката се използва TraceId

В Istio се използва Jaeger Tracer, който реализира независим от доставчика фреймворк OpenTracing API. За достъп до потребителския интерфейс на Jaeger може да използвате следната команда:

Сега влезте в 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-ове в всеки sidecar и ги трансферира. Въпреки това, без работа с заглавията вътре в услугите, пълният път на трасировката на запитването ще бъде загубен.

Необходимо е да се вземат предвид (предават) следните заглавки:

Тази задача не е сложна, обаче за улеснение на нейното изпълнение вече съществуват много библиотеки — например, в услугата sa-web-app клиентът RestTemplate предава тези заглавки, ако просто добавите библиотеките Jaeger и OpenTracing в неговите зависимости.

Обърнете внимание, че приложението Sentiment Analysis демонстрира реализации на Flask, Spring и ASP.NET Core.

Сега, когато стана ясно какво получаваме от кутията (или почти «от кутията»), нека разгледаме въпросите с фино настроена маршрутизация, управление на мрежовия трафик, сигурност и т.н.!

Прим. прев.: прочетете за това в следващата част от материалите по Istio от Rinor Maloku, преводите на които ще последват в нашия блог в близко бъдеще. UPDATE (14 март): Втората част вече е публикувана.