🥇Atgal į mikropaslaugas su Istio. 1 dalis

Pastaba. vert.: Paslaugų tinkleliai neabejotinai tapo aktualiu sprendimu šiuolaikinėje infrastruktūroje, skirtoje programoms, kurios atitinka mikro paslaugų architektūrą. Nors „Istio“ gali būti daugelio „DevOps“ inžinierių lūpose, tai gana naujas produktas, su kuriuo, nors ir visapusiškai, atsižvelgiant į jo teikiamas galimybes, gali prireikti nemažai laiko susipažinti. Vokiečių inžinierius Rinoras Maloku, atsakingas už debesų kompiuteriją stambiems klientams telekomunikacijų bendrovėje Orange Networks, parašė nuostabią seriją medžiagos, leidžiančios greitai ir giliai pasinerti į Istio. Savo istoriją jis pradeda nuo to, ką apskritai Istio gali padaryti ir kaip tai greitai pamatysite savo akimis.

Tas pats — Atvirojo kodo projektas, sukurtas bendradarbiaujant su Google, IBM ir Lyft komandomis. Jis išsprendžia sudėtingas problemas, kylančias naudojant mikropaslaugomis pagrįstas programas, pavyzdžiui:

Eismo valdymas: skirtukai, pakartotiniai bandymai, apkrovos balansavimas;
saugumas: galutinio vartotojo autentifikavimas ir autorizavimas;
Stebimumas: sekimas, stebėjimas, medienos ruoša.

Visa tai gali būti išspręsta programos lygiu, tačiau po to jūsų paslaugos nebebus „mikro“. Visos papildomos pastangos sprendžiant šias problemas yra įmonės resursų švaistymas, kuris gali būti tiesiogiai panaudotas verslo vertei gauti. Pažiūrėkime į pavyzdį:

Projekto vadovas: kiek laiko užtrunka pridėti atsiliepimų funkciją?
Kūrėjas: du sprintai.

MP: Ką?.. Tai tiesiog GRUD!
R: Atlikti CRUD yra lengva dalis, tačiau vis tiek turime autentifikuoti ir įgalioti vartotojus ir paslaugas. Kadangi tinklas yra nepatikimas, turėsite įgyvendinti pakartotines užklausas, taip pat grandinės pertraukiklio modelis klientuose. Be to, norint užtikrinti, kad visa sistema nesustrigtų, jums reikės skirtojo laiko ir pertvaros (daugiau informacijos apie abu minėtus modelius žr. vėliau straipsnyje – apytikslis vertimas)ir siekiant aptikti problemas, stebėti, sekti, […]

MP: O, tada tiesiog įterpkime šią funkciją į produkto paslaugą.

Manau, kad idėja aiški: norint pridėti vieną paslaugą, reikia atlikti daugybę žingsnių ir pastangų. Šiame straipsnyje apžvelgsime, kaip Istio iš paslaugų pašalina visą aukščiau paminėtą sudėtingumą (kuris nėra skirtas verslo logikai).

Atkreipti dėmesį: Šiame straipsnyje daroma prielaida, kad turite praktinių žinių apie Kubernetes. Kitu atveju rekomenduoju perskaityti mano įžanga į Kubernetes ir tik po to tęskite šios medžiagos skaitymą.

Istio idėja

Pasaulyje, kuriame nėra Istio, viena paslauga pateikia tiesioginius užklausas kitai, o gedimo atveju paslauga turi tai tvarkyti pati: bandyti iš naujo, suteikti timeout, atidaryti grandinės pertraukiklį ir pan.

Tinklo srautas Kubernetes

Istio siūlo specializuotą sprendimą, visiškai atskirtą nuo paslaugų ir veikiantį trikdant tinklo ryšį. Ir taip įgyvendinama:

atsparumas gedimams: pagal būsenos kodą atsakyme, jis supranta, ar užklausa nepavyko, ir ją vykdo iš naujo.
Kanarų riestainiai: nukreipia tik fiksuotą procentą užklausų į naują paslaugos versiją.
Stebėjimas ir metrika: Kiek laiko užtruko, kol tarnyba atsakė?
Sekimas ir stebėjimas: prie kiekvienos užklausos prideda specialias antraštes ir seka jas visame klasteryje.
saugumas: nuskaito JWT prieigos raktą, autentifikuoja ir įgalioja vartotojus.

Tai tik keletas galimybių (tikrai tik kelios!) jus suintriguoti. Dabar pasinerkime į technines detales!

Istio architektūra

„Istio“ perima visą tinklo srautą ir taiko jam taisyklių rinkinį, į kiekvieną bloką įterpdamas išmanųjį tarpinį serverį šoninio priekabos konteinerio pavidalu. Tarpiniai serveriai, suaktyvinantys visas galimybes, sudaro a Duomenų plokštuma, ir juos galima dinamiškai konfigūruoti naudojant Valdymo plokštuma.

Duomenų plokštuma

Į lizdus įterpti tarpiniai serveriai leidžia „Istio“ lengvai patenkinti mums reikalingus reikalavimus. Pavyzdžiui, patikrinkime pakartotinio bandymo ir grandinės pertraukiklio funkcijas.

Kaip „Envoy“ įgyvendinami pakartotiniai bandymai ir grandinės pertraukimas

Apibendrinimas:

pasiuntinys (kalbame apie tarpinį serverį, esantį šoninio priekabos konteineryje, kuris platinamas kaip atskiras produktas - apytiksliai vertimas.) siunčia užklausą pirmajam paslaugos B egzemplioriui ir nepavyksta.
Pasiuntinys priekabos bando dar kartą (bandyti dar kartą). (1)
Užklausa nepavyksta ir grąžinama ją iškvietusiam įgaliotajam serveriui.
Tai atidaro „Circuit Breaker“ ir iškviečia kitą tarnybą dėl vėlesnių užklausų. (2)

Tai reiškia, kad jums nereikia naudoti kitos „Retry“ bibliotekos, jums nereikia pačiam įdiegti grandinės pertraukimo ir paslaugų aptikimo programavimo kalbomis X, Y arba Z. Visa tai ir dar daugiau yra prieinama iš karto. Istio mieste ir nereikalauja ne kodo pakeitimai.

Puiku! Dabar galbūt norėsite leistis į kelionę su Istio, bet vis dar turite abejonių, atvirų klausimų. Jei tai yra universalus sprendimas visoms gyvenimo progoms, tuomet kyla natūralus įtarimas: juk visi tokie sprendimai realybėje pasirodo netinkami bet kokiam atvejui.

Ir galiausiai jūs klausiate: „Ar tai galima pritaikyti?

Dabar jūs pasiruošę kelionei jūra, susipažinkime su valdymo lėktuvu.

Valdymo plokštuma

Jį sudaro trys komponentai: Pilotas, Maišytuvas и Citadelė, kurios kartu sukonfigūruoja pasiuntinius nukreipti srautą, vykdyti politiką ir rinkti telemetrijos duomenis. Schematiškai viskas atrodo taip:

Valdymo plokštumos sąveika su duomenų plokštuma

Pasiuntiniai (t. y. duomenų plokštuma) konfigūruojami naudojant Kubernetes CRD (Custom Resource Definitions), apibrėžtas Istio ir specialiai skirtas šiam tikslui. Jums tai reiškia, kad jie atrodo tik dar vienas „Kubernetes“ šaltinis su pažįstama sintaksė. Sukūrus šį išteklį, valdymo plokštuma paims ir pritaikys pasiuntiniams.

Paslaugų ryšys su Istio

Aprašėme Istio santykį su paslaugomis, bet ne atvirkščiai: kaip paslaugos yra susijusios su Istio?

Tiesą sakant, tarnybos taip pat žino apie Istio buvimą kaip žuvys, kai klausia savęs: „Kas vis dėlto yra vanduo?

Iliustracija Viktorija Dimitrakopoulos: - Kaip tau patinka vanduo? - Kas vis dėlto yra vanduo?

Taigi, galite paimti veikiantį klasterį ir įdiegus Istio komponentus jame esančios paslaugos veiks toliau, o pašalinus šiuos komponentus vėl viskas bus gerai. Aišku, kad tokiu atveju prarasite Istio teikiamas galimybes.

Užteks teorijos – pritaikykime šias žinias praktiškai!

Istio praktikoje

„Istio“ reikalauja „Kubernetes“ klasterio su mažiausiai 4 vCPU ir 8 GB RAM. Norėdami greitai nustatyti klasterį ir vadovautis straipsnyje pateiktomis instrukcijomis, rekomenduoju naudoti „Google Cloud Platform“, kuri siūlo naujiems vartotojams nemokamai 300 USD.

Sukūrę klasterį ir sukonfigūravę prieigą prie „Kubernetes“ naudodami konsolės įrankį, galite įdiegti „Istio“ naudodami „Helm“ paketų tvarkyklę.

Vairo montavimas

Įdiekite „Helm“ klientą savo kompiuteryje, kaip aprašyta oficialius dokumentus. Tai naudosime kurdami šablonus, skirtus „Istio“ diegimui kitame skyriuje.

„Istio“ diegimas

Atsisiųskite „Istio“ išteklius iš naujausias leidimas (pirminė autoriaus nuoroda į 1.0.5 versiją pakeista į dabartinę, t. y. 1.0.6 – apytikslis vertimas), išskleiskite turinį į vieną katalogą, kurį nuo šiol vadinsiu [istio-resources].

Norėdami lengvai identifikuoti Istio išteklius, sukurkite vardų erdvę K8s klasteryje istio-system:

$ kubectl create namespace istio-system

Užbaikite diegimą eidami į katalogą [istio-resources] ir paleisti komandą:

$ 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

Ši komanda išves pagrindinius Istio komponentus į failą istio.yaml. Pakeitėme standartinį šabloną, kad tiktų sau, nurodydami šiuos parametrus:

global.mtls.enabled įdiegta false (t. y. mTLS autentifikavimas išjungtas – apytiksliai)supaprastinti mūsų pažinčių procesą;
tracing.enabled apima užklausų sekimą naudojant Jaeger;
kiali.enabled įdiegia Kiali į klasterį, kad vizualizuotų paslaugas ir srautą;
grafana.enabled įdiegia „Grafana“, kad vizualizuotų surinktą metriką.

Sugeneruotus išteklius panaudokime su komanda:

$ kubectl apply -f istio.yaml

Istio diegimas klasteryje baigtas! Palaukite, kol visi ankštys bus vardų erdvėje istio-system galės Running arba Completedvykdydami žemiau esančią komandą:

$ kubectl get pods -n istio-system

Dabar esame pasirengę tęsti kitame skyriuje, kuriame parengsime ir paleisime programą.

Sentimentų analizės programos architektūra

Pasinaudokime jau minėtame naudotos Sentiment Analysis mikropaslaugos programos pavyzdžiu „Kubernetes“ įvadinis straipsnis. Tai pakankamai sudėtinga, kad praktiškai parodytų Istio galimybes.

Programą sudaro keturios mikropaslaugos:

Tarnyba SA-Frontend, kuri aptarnauja Reactjs programos priekinę dalį;
Tarnyba SA-WebApp, kuri aptarnauja nuotaikų analizės užklausas;
Tarnyba SA-Logika, kuri atlieka pati sentimentų analizė;
Tarnyba SA-Atsiliepimai, kuri iš vartotojų gauna atsiliepimus apie analizės tikslumą.

Šioje diagramoje, be paslaugų, taip pat matome įėjimo valdiklį, kuris Kubernetes nukreipia gaunamas užklausas į atitinkamas tarnybas. „Istio“ savo „Ingress Gateway“ naudoja panašią koncepciją, apie kurią bus daugiau informacijos.

Programos paleidimas naudojant tarpinį serverį iš „Istio“.

Jei norite atlikti kitas straipsnyje minimas operacijas, klonuokite saugyklą istio-meistriškumas. Jame yra Kubernetes ir Istio programa ir manifestai.

Šoninių priekabų įdėjimas

Įdėjimas gali būti atliktas automatiškai arba rankomis. Norėdami automatiškai įterpti šoninių priekabų konteinerius, turėsite nustatyti vardų srities etiketę istio-injection=enabled, kuri atliekama naudojant šią komandą:

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

Dabar kiekviena grupė, kuri bus įdiegta numatytojoje vardų erdvėje (default) gaus savo priekabos konteinerį. Norėdami tai patikrinti, įdiekite bandomąją programą, eidami į saugyklos šakninį katalogą [istio-mastery] ir paleiskite šią komandą:

$ 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

Įdiegę paslaugas patikrinkime, ar ankštys turi du konteinerius (su pačia paslauga ir jos šonine priekaba), paleisdami komandą kubectl get pods ir įsitikinkite, kad po stulpeliu READY nurodyta vertė 2/2, simbolizuojantis, kad abu konteineriai veikia:

$ 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

Vizualiai tai atrodo taip:

Pasiuntinio įgaliotasis asmuo vienoje iš ankščių

Dabar, kai programa yra sukurta ir veikia, turėsime leisti įeinančiam srautui patekti į programą.

Įėjimo vartai

Geriausia praktika tai pasiekti (leisti srautą klasteryje) yra per Įėjimo vartai Istio, kuris yra klasterio „kraštyje“ ir leidžia įjungti „Istio“ funkcijas, tokias kaip maršruto parinkimas, apkrovos balansavimas, apsauga ir gaunamo srauto stebėjimas.

„Istio“ diegimo metu klasteryje buvo įdiegtas „Ingress Gateway“ komponentas ir jį išoriškai persiunčianti paslauga. Norėdami sužinoti išorinį paslaugos IP adresą, paleiskite:

$ 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

Mes ir toliau prieisime prie programos naudodami šį IP (pavadinsiu jį EXTERNAL-IP), todėl patogumo dėlei reikšmę įrašysime į kintamąjį:

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

Jei bandysite dabar pasiekti šį IP per naršyklę, gausite klaidą Paslauga nepasiekiama, nes pagal numatytuosius nustatymus „Istio“ blokuoja visą įeinantį srautą, Vartai dar nebuvo apibrėžti.

Vartų šaltinis

Vartai yra CRD (Custom Resource Definition) „Kubernetes“, apibrėžiamas įdiegus „Istio“ klasteryje ir suteikiant galimybę nurodyti prievadus, protokolą ir pagrindinius kompiuterius, kuriems norime leisti įeinantį srautą.

Mūsų atveju norime leisti HTTP srautą per 80 prievadą visiems pagrindiniams kompiuteriams. Užduotis įgyvendinama pagal tokį apibrėžimą (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:
- "*"

Šios konfigūracijos nereikia paaiškinti, išskyrus selektorių istio: ingressgateway. Šiuo parinkikliu galime nurodyti, kuriam įėjimo šliuzui taikyti konfigūraciją. Mūsų atveju tai yra Ingress Gateway valdiklis, kuris Istio buvo įdiegtas pagal nutylėjimą.

Konfigūracija taikoma iškviečiant šią komandą:

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

Dabar šliuzas leidžia pasiekti 80 prievadą, bet neįsivaizduoja, kur nukreipti užklausas. Tam jums reikės Virtualios paslaugos.

Virtualios paslaugos šaltinis

„VirtualService“ nurodo „Ingress Gateway“, kaip nukreipti užklausas, kurios yra leidžiamos klasteryje.

Užklausos dėl mūsų programos, gaunamos per http-gateway, turi būti siunčiamos sa-frontend, sa-web-app ir sa-feedback paslaugoms:

Maršrutai, kuriuos reikia sukonfigūruoti naudojant „VirtualServices“.

Pažvelkime į užklausas, kurios turėtų būti siunčiamos SA-Frontend:

Tikslios rungtynės pakeliui / turėtų būti išsiųstas SA-Frontend, kad gautumėte index.html;
Priešdėliniai takai /static/* turi būti siunčiami į SA-Frontend, kad būtų gauti statiniai failai, naudojami sąsajoje, pvz., CSS ir JavaScript;
Keliai, atitinkantys reguliariąją išraišką '^.*.(ico|png|jpg)$', turi būti siunčiami į SA-Frontend, nes Tai yra nuotraukos, rodomos puslapyje.

Diegimas pasiekiamas naudojant šią konfigūraciją (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
Svarbūs taškai:

Ši virtuali paslauga nurodo gaunamas užklausas http-vartai;
В destination Nustatoma tarnyba, kuriai siunčiami prašymai.

Atkreipti dėmesį: aukščiau pateikta konfigūracija saugoma faile sa-virtualservice-external.yaml, kuriame taip pat yra maršruto nustatymai SA-WebApp ir SA-Feedback, bet čia, kad būtų trumpai, jis sutrumpintas.

Pritaikykime „VirtualService“ paskambinę:

Atkreipti dėmesį: Kai naudojame „Istio“ išteklius, „Kubernetes“ API serveris sukuria įvykį, kurį gauna „Istio“ valdymo plokštuma, o po to nauja konfigūracija taikoma kiekvienos grupės „Envoy“ įgaliotiesiems serveriams. Ir Ingress Gateway valdiklis, atrodo, yra kitas pasiuntinys, sukonfigūruotas valdymo plokštumoje. Visa tai diagramoje atrodo taip:

Istio-IngressGateway konfigūracija užklausų nukreipimui

Nuotaikų analizės programa dabar pasiekiama http://{EXTERNAL-IP}/. Nesijaudinkite, jei gausite būseną Nerasta: Kartais užtrunka šiek tiek ilgiau, kol konfigūracija įsigalios ir pasiuntinio talpyklos atnaujinamos.

Prieš tęsdami, šiek tiek pažaiskite su programa, kad generuotumėte srautą. (jo buvimas būtinas siekiant aiškumo tolesniuose veiksmuose - apytiksliai vertimas).

Kiali: pastebimumas

Norėdami patekti į Kiali administracinę sąsają, paleiskite šią komandą:

... ir atidaryta http://localhost:20001/, prisijungiant kaip admin/admin. Čia rasite daug naudingų funkcijų, pavyzdžiui, patikrinti Istio komponentų konfigūraciją, vizualizuoti paslaugas naudojant informaciją, surinktą perimant tinklo užklausas, gauti atsakymus į klausimus „Kas su kuo kreipiasi?“, „Kokia paslaugos versija veikia. nesėkmės?" ir taip toliau. Apskritai, prieš pradėdami vizualizuoti metriką su Grafana, ištirkite Kiali galimybes.

Grafana: metrikos vizualizacija

„Istio“ surinkta metrika patenka į „Prometheus“ ir vizualizuojama naudojant „Grafana“. Norėdami patekti į Grafana administracinę sąsają, paleiskite toliau pateiktą komandą ir atidarykite http://localhost:3000/:

Spustelėkite meniu Pagrindinis viršuje kairėje ir pasirinkite „Istio Service“ prietaisų skydelis viršutiniame kairiajame kampe pradėkite nuo aptarnavimo sa-web-appNorėdami peržiūrėti surinktas metrikas:

Čia mūsų laukia tuščias ir visiškai nuobodus pasirodymas – vadovybė tam niekada nepritars. Sukurkime nedidelę apkrovą naudodami šią komandą:

Dabar turime daug gražesnių grafikų ir, be jų, nuostabius „Prometheus“ įrankius stebėjimui ir „Grafana“ metrikos vizualizavimui, kurie leis mums sužinoti apie našumą, sveikatą, paslaugų patobulinimus / blogėjimą laikui bėgant.

Galiausiai pažvelkime į paslaugų užklausas.

Jėgeris: sekimas

Mums reikės sekimo, nes kuo daugiau paslaugų turime, tuo sunkiau rasti gedimo priežastį. Pažvelkime į paprastą atvejį iš toliau pateiktos nuotraukos:

Tipiškas atsitiktinės nesėkmingos užklausos pavyzdys

Prašymas ateina, krenta - kokia priežastis? Pirma paslauga? Arba antra? Abiejuose yra išimčių – pažiūrėkime į kiekvieno žurnalus. Kaip dažnai pastebėjote save tai darant? Mūsų darbas labiau panašus į programinės įrangos detektyvus, o ne į kūrėjus...

Tai dažna mikropaslaugų problema ir sprendžiama paskirstytomis sekimo sistemomis, kuriose paslaugos viena kitai perduoda unikalią antraštę, po kurios ši informacija persiunčiama į sekimo sistemą, kur ji lyginama su užklausos duomenimis. Štai iliustracija:

TraceId naudojamas užklausai identifikuoti

„Istio“ naudoja „Jaeger Tracer“, kuri įdiegia nuo pardavėjo nepriklausomą „OpenTracing“ API sistemą. „Jaeger“ vartotojo sąsają galite pasiekti naudodami šią komandą:

Dabar eik į http://localhost:16686/ ir pasirinkite paslaugą sa-web-app. Jei paslauga nerodoma išskleidžiamajame meniu, parodykite / generuokite veiklą puslapyje ir atnaujinkite sąsają. Po to spustelėkite mygtuką Rasti pėdsakus, kuriame bus rodomi naujausi pėdsakai – pasirinkite bet kurį – pasirodys išsami informacija apie visus pėdsakus:

Šis pėdsakas rodo:

Prašymas ateina istio-įėjimo vartai (tai pirmoji sąveika su viena iš paslaugų ir užklausai sugeneruojamas sekimo ID), po kurio šliuzas siunčia užklausą tarnybai sa-web-app.
Tarnyboje sa-web-app prašymą paima Envoy šoninė priekaba, tarpoje sukuriamas „vaikas“ (todėl matome jį pėdsakuose) ir nukreipiamas į konteinerį sa-web-app. (trukmė - loginis darbo vienetas Jėgeryje, turintis pavadinimą, operacijos pradžios laiką ir trukmę. Tarpatramius galima sudėti ir rūšiuoti. Nukreiptas aciklinis intervalų grafikas sudaro pėdsaką. — apytiksliai vertimas.)
Čia užklausa apdorojama metodu sentimentų analizė. Šiuos pėdsakus jau sugeneruoja programa, t.y. jiems reikėjo pakeisti kodą.
Nuo šio momento POST užklausa inicijuojama sa-logika. Trace ID turi būti persiųstas iš sa-web-app.
...

Atkreipti dėmesį: 4 veiksme programa turėtų matyti „Istio“ sugeneruotas antraštes ir perduoti jas vėlesnėms užklausoms, kaip parodyta paveikslėlyje žemiau:

(A) „Istio“ yra atsakinga už antraščių persiuntimą; (B) Paslaugos yra atsakingos už antraštes

Istio atlieka didžiąją dalį darbo, nes... generuoja gaunamų užklausų antraštes, sukuria naujus intervalus kiekvienoje papildomoje programoje ir jas persiunčia. Tačiau nedirbant su antraštėmis paslaugose, visas užklausos sekimo kelias bus prarastas.

Reikia atsižvelgti į šias antraštes:

Tai nėra sudėtinga užduotis, tačiau supaprastinti jos įgyvendinimą jau yra daug bibliotekų - pavyzdžiui, sa-web-app paslaugoje RestTemplate klientas persiunčia šias antraštes, jei tiesiog pridedate Jaeger ir OpenTracing bibliotekas jo priklausomybės.

Atminkite, kad nuotaikų analizės programa demonstruoja diegimus „Flask“, „Spring“ ir „ASP.NET Core“.

Dabar, kai aišku, ką mes gauname iš dėžutės (arba beveik iš dėžutės), pažvelkime į tiksliai sureguliuotą maršruto parinkimą, tinklo srauto valdymą, saugumą ir kt.!

Pastaba. vert.: Skaitykite apie tai kitoje Rinor Maloku medžiagos apie Istio dalyje, kurios vertimai bus artimiausiu metu mūsų tinklaraštyje. ATNAUJINIMAS (kovo 14 d.): Antroji dalis jau buvo paskelbta.