🥇Nazad na mikrousluge uz Istio. Dio 1

Bilješka. transl.: Servisne mreže su definitivno postale vruća tema u današnjoj infrastrukturi za aplikacije koje slijede mikroservisnu arhitekturu. Iako je Istio možda na radaru mnogih DevOps inženjera, to je prilično nov proizvod koji, iako složen u smislu karakteristika koje pruža, može potrajati značajno vrijeme da se upozna. Njemački inženjer Rinor Maloku, koji je zadužen za računalstvo u oblaku za velike klijente u telekomunikacijskoj kompaniji Orange Networks, napisao je prekrasan niz materijala koji vam omogućavaju da brzo i duboko zaronite u Istio. Svoju priču započinje onim što Istio može učiniti i kako to brzo možete vidjeti vlastitim očima.

Istio — Open Source-projekat, razvijen u saradnji sa timovima iz Google-a, IBM-a i Lyfta. Rješava složenost koja se javlja u aplikacijama zasnovanim na mikroservisima, na primjer, kao što su:

upravljanje saobraćajem: vremenska ograničenja, ponovni pokušaji, balansiranje opterećenja;
Sigurnost: autentifikacija i autorizacija krajnjeg korisnika;
opservabilnost: praćenje, praćenje, evidentiranje.

Svi oni se mogu riješiti na nivou aplikacije, međutim nakon toga vaši servisi više neće biti "mikro". Sav dodatni napor u rješavanju ovih problema je gubljenje resursa kompanije koji bi se mogli koristiti direktno za poslovnu vrijednost. Razmotrimo primjer:

Menadžer projekta: Koliko vremena je potrebno za dodavanje funkcije povratnih informacija?
Programer: Dva sprinta.

MP: Šta?.. To je samo GROBRO!
R: Izvođenje CRUD-a je lak dio zadatka, ali još uvijek moramo autentifikovati i ovlastiti korisnike i usluge. Budući da je mreža nepouzdana, morat ćete implementirati ponovljene zahtjeve, kao i uzorak prekidača kod klijenata. Također, kako bi bili sigurni da se cijeli sistem nije srušio, istek vremena i pregrade (Pogledajte kasnije u članku za više detalja o oba navedena obrasca.), a u cilju otkrivanja problema, praćenje, praćenje, […]
MP: Oh, hajde da stavimo ovu funkciju u servis proizvoda.

Mislim da je ideja jasna: količina koraka i napora potrebnih za dodavanje jedne usluge je ogromna. U ovom članku ćemo pogledati kako Istio uklanja svu gore spomenutu složenost (koja nije ciljana poslovnom logikom) iz usluga.

primjedba: Članak pretpostavlja da imate radno znanje o Kubernetesu. Inače, preporučujem čitanje moj uvod u Kubernetes i tek onda nastavite čitati ovaj materijal.

Istio idea

U svijetu bez Istio-a, jedna usluga upućuje direktne zahtjeve drugoj, a u slučaju neuspjeha, usluga mora sama riješiti to: napraviti novi pokušaj, osigurati tajm-aut, otvoriti prekidač itd.

Mrežni saobraćaj u Kubernetesu

Istio, s druge strane, nudi specijalizirano rješenje koje je potpuno odvojeno od usluga i funkcija ometajući mrežnu interakciju. I tako implementira:

tolerancije grešaka: na osnovu statusnog koda u odgovoru, razumije ako zahtjev nije uspio i ponovo ga šalje.
Canary Rollouts: preusmjerava samo fiksni postotak zahtjeva na novu verziju usluge.
Monitoring i metrika: koliko je vremena trebalo da servis odgovori?
Praćenje i uočljivost: Dodaje posebna zaglavlja svakom zahtjevu i prati ih kroz klaster.
Sigurnost: preuzima JWT token, provjerava autentičnost i autorizira korisnike.

Ovo su samo neke od mogućnosti (zaista samo nekoliko!) da vas zaintrigiraju. Sada zaronimo u tehničke detalje!

Arhitektura

Istio presreće sav mrežni promet i na njega primjenjuje skup pravila, ubacujući pametni proxy u obliku bočnog kontejnera u svaki pod. Proksiji koji aktiviraju sve mogućnosti formiraju a data plane, a mogu se dinamički prilagođavati pomoću Kontrolni plan.

data plane

Proksiji koji su umetnuti u podove omogućavaju Istiu da lako postigne zahtjeve koji su nam potrebni. Na primjer, provjerimo ponovne pokušaje i funkcije prekidača.

Kako se ponovni pokušaji i prekidi implementiraju u Envoyu

Da sumiram:

izaslanik (govorimo o proxyju koji se nalazi u bočnom kontejneru, koji se distribuira i kako poseban proizvod - cca. prevod) šalje zahtjev prvoj instanci servisa B i ne uspijeva.
Izaslanik Sidecar pokušava ponovo (pokušaj ponovo). (1)
Neuspjeli zahtjev se vraća proxyju koji ga je pozvao.
Ovo otvara prekidač i poziva sljedeću uslugu za sljedeće zahtjeve. (2)

To znači da ne morate koristiti sljedeću biblioteku Retry, ne morate napraviti vlastitu implementaciju Circuit Breaking i Service Discovery u programskom jeziku X, Y ili Z. Sve ovo i više je dostupno iz kutija u Istio i ne zahtijeva ne promjene koda.

Odlično! Sada ćete možda poželjeti ići na putovanje s Istiom, ali još uvijek postoje nedoumice, otvorena pitanja. Ako je ovo univerzalno rješenje za sve prilike u životu, onda opravdano sumnjate: na kraju krajeva, sva takva rješenja zapravo nisu prikladna ni za jedan slučaj.

I na kraju pitate: "Da li je prilagodljiv?"

Sada ste spremni za putovanje morem - i hajde da se upoznamo sa Kontrolnim avionom.

Kontrolni plan

Sastoji se od tri komponente: pilot, Mikser и citadela, koji zajedno konfigurišu izaslanike da usmjeravaju promet, primjenjuju politike i prikupljaju podatke telemetrije. Šematski, sve to izgleda ovako:

Interakcija kontrolne ravni i ravni podataka

Izaslanici (tj. ravan podataka) su konfigurirani sa Kubernetes CRD (Prilagođene definicije resursa) koje je definirao Istio i posebno dizajniran za ovu svrhu. Ovo za vas znači da su oni samo još jedan resurs u Kubernetesu sa poznatom sintaksom. Jednom kreiran, ovaj resurs će pokupiti kontrolna ravnina i primijeniti na Izaslanike.

Odnos usluga prema Istio

Opisali smo Istiov odnos prema uslugama, ali ne i obrnuto: kako se usluge odnose na Istio?

Iskreno govoreći, službe znaju za prisustvo Istia kao i ribe znaju za vodu kada se zapitaju: „Šta je to uopće voda?“.

Ilustracija Victoria Dimitrakopoulos: Kako vam se sviđa voda? - Šta je uopšte voda?

Dakle, možete uzeti radni klaster i nakon postavljanja Istio komponenti, usluge u njemu će nastaviti raditi, a nakon uklanjanja ovih komponenti, sve će opet biti u redu. Jasno je da ćete u ovom slučaju izgubiti mogućnosti koje pruža Istio.

Dosta teorije - hajde da ovo znanje primenimo u praksi!

Istio u praksi

Istio zahtijeva Kubernetes klaster s najmanje 4 vCPU-a i 8 GB RAM-a na raspolaganju. Kako biste brzo podigli klaster i slijedili upute iz članka, preporučujem korištenje Google Cloud Platforme, koja nudi novim korisnicima besplatno $300.

Nakon kreiranja klastera i podešavanja pristupa Kubernetesu preko uslužnog programa za konzolu, Istio možete instalirati preko Helm menadžera paketa.

Instalacija kormila

Instalirajte Helm klijenta na svoj računar kao što je opisano u službena dokumentacija. Koristit ćemo ga za generiranje šablona za instalaciju Istio-a u sljedećem odjeljku.

Instalacija

Preuzmite Istio resurse sa najnovije izdanje (originalni autorov link na verziju 1.0.5 je promijenjen u trenutnu, tj. 1.0.6 - pribl. prev.), izdvojite sadržaj u jedan direktorij, koji ću nazivati [istio-resources].

Za jednostavnu identifikaciju Istio resursa, kreirajte imenski prostor u klasteru K8s istio-system:

$ kubectl create namespace istio-system

Dovršite instalaciju navigacijom do direktorija [istio-resources] i pokretanje naredbe:

$ 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

Ova komanda će izvesti ključne komponente Istio-a u datoteku istio.yaml. Za sebe smo izmijenili standardni predložak specificirajući sljedeće parametre:

global.mtls.enabled ugrađen u false (tj. mTLS autentifikacija je onemogućena - pribl. prev.)da pojednostavimo naš proces upoznavanja;
tracing.enabled omogućava praćenje zahtjeva sa Jaegerom;
kiali.enabled instalira Kiali u klaster za vizualizaciju usluga i prometa;
grafana.enabled instalira Grafanu da vizualizira prikupljene metrike.

Primijenite generirane resurse naredbom:

$ kubectl apply -f istio.yaml

Instalacija Istio-a u klaster je završena! Pričekajte dok svi podovi u imenskom prostoru istio-system će biti u mogućnosti Running ili Completedpokretanjem naredbe ispod:

$ kubectl get pods -n istio-system

Sada smo spremni da nastavimo do sljedećeg odjeljka, gdje ćemo podići i pokrenuti aplikaciju.

Arhitektura aplikacije za analizu raspoloženja

Upotrijebimo primjer mikroservisne aplikacije Sentiment Analysis korištene u već spomenutom Uvodni članak u Kubernetes. Dovoljno je složen da pokaže mogućnosti Istia u praksi.

Aplikacija se sastoji od četiri mikroservisa:

usluga SA-Frontend, koji služi front-end aplikaciji na Reactjs;
usluga SA Web App, koji služi upitima analize sentimenta;
usluga SA Logickoji se sam izvodi analiza sentimenta;
usluga SA Feedback, koji prima povratne informacije od korisnika o tačnosti izvršene analize.

Na ovom dijagramu, pored servisa, vidimo i Ingress Controller, koji u Kubernetesu usmjerava dolazne zahtjeve odgovarajućim servisima. Istio koristi sličan koncept kao dio Ingress Gatewaya, čiji će detalji slijediti.

Pokretanje aplikacije sa proxy-om iz Istio-a

Za dalje operacije navedene u članku, klonirajte svoje spremište istio-majstorstvo. Sadrži aplikaciju i manifeste za Kubernetes i Istio.

Umetanje prikolica

Može se izvršiti umetanje automatski ili rukom. Da biste automatski umetnuli bočne kontejnere, morate postaviti oznaku na prostor imena istio-injection=enabled, što se radi sljedećom naredbom:

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

Sada svaki pod koji će biti raspoređen u zadanom imenskom prostoru (default) će dobiti svoj kontejner za prikolicu. Da to potvrdimo, postavimo testnu aplikaciju tako što ćemo otići u korijenski direktorij spremišta [istio-mastery] i pokrenuti sljedeću naredbu:

$ 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

Nakon što ste postavili usluge, provjerite da li podovi imaju dva kontejnera (sa samom uslugom i njenom prikolicom) tako što ćete pokrenuti naredbu kubectl get pods i pazeći da ispod kolone READY specificirana vrijednost 2/2, simbolizirajući da oba kontejnera rade:

$ 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

Vizuelno to izgleda ovako:

Proxy izaslanik u jednom od podova

Sada kada je aplikacija pokrenuta i radi, moramo dozvoliti dolaznom prometu da uđe u aplikaciju.

Ingress Gateway

Najbolja praksa da se to postigne (dozvoli promet u klasteru) je kroz Ingress Gateway u Istio-u, koji se nalazi na “ivici” klastera i omogućava vam da omogućite Istio funkcije kao što su rutiranje, balansiranje opterećenja, sigurnost i praćenje dolaznog saobraćaja.

Ingress Gateway komponenta i usluga koja je prosljeđuje prema van instalirani su na klaster tokom Istio instalacije. Da biste saznali eksternu IP adresu usluge, pokrenite:

$ 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

Nastavit ćemo pristupati aplikaciji koristeći ovu IP adresu (nazvat ću je kao EXTERNAL-IP), pa ćemo zbog praktičnosti zapisati vrijednost u varijablu:

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

Ako sada pokušate pristupiti ovoj IP adresi preko pretraživača, dobićete grešku Service Unavailable, jer po defaultu Istio blokira sav dolazni prometdok se ne definira Gateway.

Gateway resurs

Gateway je CRD (prilagođena definicija resursa) u Kubernetesu, definiran nakon instalacije Istio-a u klaster i omogućavajući mogućnost specificiranja portova, protokola i hostova za koje želimo dozvoliti dolazni promet.

U našem slučaju želimo da dozvolimo HTTP saobraćaj na portu 80 za sve hostove. Problem se realizira sljedećom definicijom (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:
- "*"

Ova konfiguracija ne treba objašnjenje osim selektora istio: ingressgateway. Pomoću ovog selektora možemo odrediti na koji ulazni prolaz primijeniti konfiguraciju. U našem slučaju, ovo je Ingress Gateway kontroler, koji je standardno instaliran u Istio.

Konfiguracija se primjenjuje pozivanjem sljedeće naredbe:

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

Gateway sada dozvoljava pristup portu 80, ali nema pojma kamo usmjeriti zahtjeve. Za ovo će vam trebati Virtuelne usluge.

Virtuelni servisni resurs

VirtualService govori Ingress Gatewayu kako da usmjeri zahtjeve koji su dozvoljeni unutar klastera.

Zahtjevi našoj aplikaciji koji dolaze preko http-gatewaya moraju se poslati na sa-frontend, sa-web-app i sa-feedback usluge:

Rute koje treba konfigurirati s VirtualServices

Razmotrite zahtjeve koje treba poslati SA-Frontend-u:

Tačno podudaranje usput / treba poslati na SA-Frontend da dobije index.html;
Putanja sa prefiksom /static/* treba poslati na SA-Frontend da dobije statičke fajlove koji se koriste u frontendu, kao što su CSS i JavaScript;
Putanja koja odgovaraju regularnom izrazu '^.*.(ico|png|jpg)$', mora se poslati u SA-Frontend, jer Ovo su slike prikazane na stranici.

Implementacija se postiže sljedećom konfiguracijom (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
Važne tačke:

Ova virtualna usluga se odnosi na zahtjeve koji dolaze http-gateway;
В destination definiše servis na koji se šalju zahtjevi.

primjedba: Gornja konfiguracija je pohranjena u datoteci sa-virtualservice-external.yaml, koji također sadrži postavke za rutiranje na SA-WebApp i SA-Feedback, ali je skraćeno ovdje u članku radi kratkoće.

Primijenite VirtualService pozivom:

primjedba: Kada primenimo Istio resurse, Kubernetes API server pokreće događaj koji prima Istio Control Plane, a nakon toga, nova konfiguracija se primenjuje na proksije Envoy svakog modula. I čini se da je Ingress Gateway kontroler još jedan izaslanik konfigurisan u kontrolnoj ravni. Sve ovo izgleda ovako na dijagramu:

Istio-IngressGateway konfiguracija za usmjeravanje zahtjeva

Analiza osjećaja je sada dostupna na http://{EXTERNAL-IP}/. Ne brinite ako dobijete status Not Found: ponekad je potrebno malo duže da konfiguracija stupi na snagu i da se Envoy kešovi ažuriraju.

Prije nego što nastavite, poigrajte se malo s aplikacijom kako biste generirali promet. (njegovo prisustvo je neophodno radi jasnoće u narednim radnjama - pribl. prev.).

Kiali: uočljivost

Da biste došli do Kiali administratorskog interfejsa, pokrenite sljedeću naredbu:

…i otvoren http://localhost:20001/prijavljivanjem kao admin/admin. Ovdje ćete pronaći mnoge korisne funkcije, na primjer, za provjeru konfiguracije Istio komponenti, vizualizaciju usluga iz informacija prikupljenih presretanjem mrežnih zahtjeva, dobivanje odgovora na pitanja „Ko koga kontaktira?“, „Koja verzija usluge se javlja neuspjesi?" i tako dalje. Općenito, istražite mogućnosti Kiali prije nego što pređete na vizualizaciju metrike s Grafanom.

Grafana: vizualizacija metrike

metrike prikupljene u Istio-u završavaju u Prometheusu i vizualiziraju se pomoću Grafane. Da biste došli do Grafana administratorskog interfejsa, pokrenite naredbu ispod, a zatim otvorite http://localhost:3000/:

Klikom na meni Početna gore lijevo i odaberite Istio Service Dashboard u gornjem lijevom uglu, počnite sa servisom sa-web-appda pogledate prikupljene metrike:

Ovdje nas čeka prazan i potpuno dosadan nastup - uprava to nikada neće odobriti. Kreirajmo malo opterećenje sa sljedećom naredbom:

Sada imamo mnogo ljepše grafove, a pored njih, divne alate Prometheus za praćenje i Grafana za vizualizaciju metrike, koji će nam omogućiti da naučimo o performansama, zdravstvenom stanju, poboljšanjima/degradaciji usluga tokom vremena.

Na kraju, pogledajmo praćenje zahtjeva u uslugama.

Jaeger: praćenje

Trebat će nam praćenje, jer što više usluga imamo, to je teže doći do uzroka kvara. Pogledajmo jednostavan slučaj sa slike ispod:

Tipičan primjer slučajnog neuspjelog zahtjeva

Zahtjev dolazi, pada - šta je razlog Prvi servis? Ili drugo? U oba postoje izuzeci - pogledajmo dnevnike svakog od njih. Koliko često ste sebe uhvatili kako ovo radite? Naš posao je više poput softverskih detektiva nego programera…

Ovo je široko rasprostranjen problem u mikroservisima i rješava se distribuiranim sistemima praćenja, u kojima servisi međusobno prosljeđuju jedinstveno zaglavlje, nakon čega se ove informacije preusmjeravaju u sistem praćenja, gdje se upoređuju sa podacima zahtjeva. Evo ilustracije:

TraceId se koristi za identifikaciju zahtjeva

Istio koristi Jaeger Tracer, koji implementira OpenTracing API okvir nezavisan od dobavljača. Možete pristupiti korisničkom interfejsu Jaeger sa sljedećom naredbom:

Sada idite na http://localhost:16686/ i izaberite uslugu sa-web-app. Ako usluga nije prikazana u padajućem meniju, prikažite/generirajte aktivnost na stranici i ažurirajte sučelje. Nakon toga kliknite na dugme Pronađite tragove, koji će prikazati najnovije tragove - odaberite bilo koji - pojavit će se detaljne informacije o svim tragovima:

Ovaj trag pokazuje:

Zahtjev stiže istio-ingressgateway (ovo je prva interakcija s jednim od servisa, a za zahtjev se generira Trace ID), nakon čega gateway šalje zahtjev servisu sa-web-app.
U službi sa-web-app zahtjev se preuzima od strane Envoy sidecar-a, kreira se "dijete" u rasponu (zato ga vidimo u tragovima) i preusmjerava se na kontejner sa-web-app. (raspon - logična jedinica rada u Jaegeru, koja ima naziv, vrijeme početka operacije i njeno trajanje. Rasponi se mogu ugniježditi i naručiti. Usmjereni aciklički graf raspona formira trag. - cca. prevod)
Ovdje se zahtjev obrađuje metodom sentimentAnalysis. Ovi tragovi su već generisani od strane aplikacije, tj. zahtijevali su promjene koda.
Od ovog trenutka se pokreće POST zahtjev sa-logic. ID praćenja mora biti proslijeđen iz sa-web-app.
...

primjedba: U koraku 4, aplikacija bi trebala vidjeti zaglavlja koje je generirao Istio i proslijediti ih na sljedeće zahtjeve, kao što je prikazano na slici ispod:

(A) Prosljeđivanje zaglavlja je odgovornost Istio-a; (B) Usluge su odgovorne za zaglavlja

Istio obavlja najveći dio posla jer generira zaglavlja za dolazne zahtjeve, kreira nove raspone u svakom sidecare-u i prosljeđuje ih. Međutim, bez rada sa zaglavljima unutar usluga, potpuna staza praćenja zahtjeva će biti izgubljena.

Sljedeća zaglavlja se moraju uzeti u obzir (proslijediti):

Ovo je jednostavan zadatak, ali da bi se pojednostavila njegova implementacija, već postoji mnoge biblioteke - na primjer, u sa-web-app servisu, RestTemplate klijent prosljeđuje ova zaglavlja ako jednostavno dodate biblioteke Jaeger i OpenTracing u njegove zavisnosti.

Imajte na umu da aplikacija Sentiment Analysis pokazuje implementacije u Flask, Spring i ASP.NET Core.

Sada kada je jasno šta dobijamo iz kutije (ili skoro iz kutije), pogledajmo fino podešavanje rutiranja, upravljanje mrežnim saobraćajem, sigurnost i još mnogo toga!

Bilješka. transl.: o tome pročitajte u sljedećem dijelu materijala o Istiu autora Rinora Malokua, čiji će prijevodi uslijediti na našem blogu u bliskoj budućnosti. UPDATE (14. mart): Drugi deo već objavljeno.

PS od prevodioca

Pročitajte i na našem blogu:

"Povratak na mikroservise sa Istiom": dio 2 (usmjeravanje, kontrola saobraćaja), dio 3 (autentifikacija i autorizacija);
«Conduit - lagana servisna mreža za Kubernetes»;
«Šta je servisna mreža i zašto mi je potrebna [za aplikaciju u oblaku sa mikroservisima]?»;
«Ilustrovani vodič za umrežavanje u Kubernetesu. Dijelovi 1 i 2»;
«Kako je ovaj kontejner s prikolicom završio ovdje [u Kubernetesu]?".

izvor: www.habr.com

Povratak na mikroservise sa Istiom. Dio 1