Povratak na mikroservise s Istiom. 1. dio

Bilješka. prev.: Servisne mreže definitivno su 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 značajki koje pruža, može trebati dosta vremena da se upozna. Njemački inženjer Rinor Maloku, koji je zadužen za računalstvo u oblaku za velike klijente u telekomunikacijskoj tvrtki Orange Networks, napisao je prekrasnu seriju materijala koji vam omogućuju da brzo i duboko uronite u Istio. Svoju priču počinje time što Istio može i kako se to brzo može vidjeti vlastitim očima.

Istio — Open Source projekt, razvijen u suradnji s timovima iz Googlea, IBM-a i Lyfta. Rješava složenosti koje nastaju u aplikacijama temeljenim na mikroservisima, na primjer, kao što su:

• upravljanje prometom: isteci vremena, ponovni pokušaji, uravnoteženje opterećenja;
• sigurnosti: autentifikacija i autorizacija krajnjeg korisnika;
• uočljivost: praćenje, praćenje, evidentiranje.

Sve ih je moguće riješiti na aplikativnoj razini, no nakon toga vaše usluge više neće biti "mikro". Sav dodatni napor za rješavanje ovih problema je gubitak resursa tvrtke koji bi se mogli izravno koristiti za poslovnu vrijednost. Razmotrite primjer:

Voditelj projekta: Koliko je vremena potrebno za dodavanje značajke povratne informacije?
Programer: Dva sprinta.

MP: Što?.. To je samo CRUD!
R: Izvođenje CRUD-a lakši je dio zadatka, ali još uvijek moramo autentificirati i autorizirati korisnike i usluge. Budući da je mreža nepouzdana, morat ćete implementirati ponovljene zahtjeve, kao i uzorak prekidača u klijentima. Također, kako bismo bili sigurni da se cijeli sustav nije srušio, timeouts i pregrade (Pogledajte kasnije u članku za više detalja o oba spomenuta uzorka.), a u svrhu otkrivanja problema, praćenja, praćenja, […]

MP: Oh, stavimo onda ovu značajku u uslugu proizvoda.

Mislim da je ideja jasna: količina koraka i truda 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.

Primijetiti: Članak pretpostavlja da imate radno znanje o Kubernetesu. Inače, preporučam čitanje moj uvod u Kubernetes a tek onda nastaviti čitati ovaj materijal.

Istina ideja

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

Mrežni promet u Kubernetesu

Istio, s druge strane, nudi specijalizirano rješenje koje je potpuno odvojeno od usluga i funkcija ometanjem mrežne interakcije. I tako provodi:

• tolerancija kvarova: na temelju statusne šifre u odgovoru, razumije ako zahtjev nije uspio i ponovno ga šalje.
• Canary Rollouts: preusmjerava samo fiksni postotak zahtjeva na novu verziju usluge.
• Praćenje i metrika: koliko je trebalo servisu da odgovori?
• Tragiranje i opažanje: dodaje posebna zaglavlja svakom zahtjevu i prati ih kroz klaster.
• sigurnosti: Dohvaća JWT token, autentificira i autorizira korisnike.

Ovo su samo neke od mogućnosti (zapravo samo neke!) koje će vas zaintrigirati. Sada zaronimo u tehničke detalje!

Arhitektura

Istio presreće sav mrežni promet i na njega primjenjuje skup pravila, umetajući pametni proxy u obliku kontejnera s prikolicom u svaku jedinicu. Proxiji koji aktiviraju sve mogućnosti čine a podatkovna ravnina, a mogu se dinamički podešavati s Upravljačka ravnina.

podatkovna ravnina

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

Kako su ponovni pokušaji i prekidanje strujnog kruga implementirani u Envoyu

Ukratko:

1. Izaslanik (govorimo o proxyju koji se nalazi u kontejneru prikolice, koji se distribuira i kako zasebni proizvod - cca. prev.) šalje zahtjev prvoj instanci usluge B i ne uspijeva.
2. Envoy Sidecar pokušava ponovno (pokušaj ponovo). (1)
3. Neuspjeli zahtjev se vraća proxyju koji ga je pozvao.
4. Ovo otvara prekidač strujnog kruga i poziva sljedeći servis za sljedeće zahtjeve. (2)

To znači da ne morate koristiti sljedeću biblioteku Ponovni pokušaj, ne morate izraditi vlastitu implementaciju prekida strujnog kruga i otkrivanja usluge u programskom jeziku X, Y ili Z. Sve ovo i više dostupno je izvan kutija u Istio i ne zahtijeva ne promjene koda.

Sjajno! Sada možda želite ići na putovanje s Istiom, ali još uvijek postoje neke nedoumice, otvorena pitanja. Ako je ovo univerzalno rješenje za sve prilike u životu, onda imate opravdanu sumnju: na kraju krajeva, sva takva rješenja zapravo nisu prikladna ni za jedan slučaj.

I na kraju pitate: "Je li to prilagodljivo?"

Sada ste spremni za putovanje morem - i upoznajmo se s Control Planeom.

Upravljačka ravnina

Sastoji se od tri komponente: Pilot, Mikser и Citadela, koji zajedno konfiguriraju Envoys za usmjeravanje prometa, primjenu pravila i prikupljanje telemetrijskih podataka. Shematski, sve to izgleda ovako:

Interakcija kontrolne ravnine s podatkovnom ravninom

Izaslanici (tj. podatkovna ravnina) su konfigurirani sa Kubernetes CRD (Custom Resource Definitions) definirao Istio i posebno dizajniran za ovu svrhu. Za vas to znači da su oni samo još jedan resurs u Kubernetesu s poznatom sintaksom. Nakon što se stvori, ovaj će resurs preuzeti upravljačka razina i primijeniti na izaslanike.

Odnos usluga prema Istio

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

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

ilustracija Victoria Dimitrakopoulos: Kako ti se sviđa voda? - Što je uopće 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 - idemo ovo znanje primijeniti u praksi!

Istio u praksi

Istio zahtijeva Kubernetes klaster s najmanje 4 vCPU-a i 8 GB dostupnog RAM-a. Za brzo podizanje klastera i praćenje uputa iz članka preporučujem korištenje Google Cloud Platforme koja nudi nove korisnike besplatnih 300 dolara.

Nakon stvaranja klastera i postavljanja pristupa Kubernetesu putem uslužnog programa konzole, Istio možete instalirati putem Helm paketnog upravitelja.

Instalacija kormila

Instalirajte Helm klijent na svoje računalo kako je opisano u službena dokumentacija. Koristit ćemo ga za generiranje predložaka za instaliranje Istia u sljedećem odjeljku.

Montaža

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

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

$ kubectl create namespace istio-system

Dovršite instalaciju navigacijom do imenika [istio-resources] i izvođenje 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 naredba će ispisati ključne komponente Istioa u datoteku istio.yaml. Modificirali smo standardni predložak za sebe navodeći sljedeće parametre:

• global.mtls.enabled instaliran u false (tj. mTLS provjera autentičnosti je onemogućena - pribl. prijevod.)da pojednostavimo naš proces upoznavanja;
• tracing.enabled omogućuje praćenje zahtjeva s Jaegerom;
• kiali.enabled instalira Kiali u klaster za vizualizaciju usluga i prometa;
• grafana.enabled instalira Grafanu za vizualizaciju prikupljenih metrika.

Primijenite generirane resurse naredbom:

$ kubectl apply -f istio.yaml

Instalacija Istio u klasteru je završena! Pričekajte dok sve mahune u prostoru imena istio-system moći Running ili Completedpokretanjem naredbe ispod:

$ kubectl get pods -n istio-system

Sada smo spremni za nastavak na sljedeći odjeljak, gdje ćemo podići i pokrenuti aplikaciju.

Arhitektura aplikacije za analizu osjećaja

Poslužimo se primjerom 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:

1. Usluga SA-frontend, koji služi front-end aplikaciji na Reactjs;
2. Usluga SA WebApp, koji služi upitima analize osjećaja;
3. Usluga SA Logikakoja sama sebe izvodi analiza sentimenta;
4. Usluga SA povratne informacije, koji od korisnika prima povratnu informaciju o točnosti izvršene analize.

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

Pokretanje aplikacije s proxyjem iz Istio

Za daljnje radnje spomenute u članku, klonirajte svoje spremište istio-majstorstvo. Sadrži aplikaciju i manifeste za Kubernetes i Istio.

Umetanje bočnih prikolica

Može se izvršiti umetanje automatsko ili ručno. Za automatsko umetanje kontejnera s prikolicom morate postaviti oznaku u imenski prostor istio-injection=enabled, što se radi sljedećom naredbom:

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

Sada svaka grupa koja će biti implementirana u zadanom prostoru naziva (default) će dobiti svoj bočni kontejner. Da to provjerimo, implementirajmo testnu aplikaciju odlaskom u korijenski direktorij repozitorija [istio-mastery] i pokretanje sljedeće naredbe:

$ 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 postavljanja usluga, provjerite imaju li kapsule po dva spremnika (sa samom uslugom i njezinom prikolicom) pokretanjem naredbe kubectl get pods i pazeći da ispod stupca READY navedena vrijednost 2/2, simbolizirajući da oba spremnika 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

Vizualno to izgleda ovako:

Izaslanik opunomoćenika u jednoj od pods

Sada kada je aplikacija pokrenuta, moramo dopustiti dolaznom prometu da uđe u aplikaciju.

Ulazni prolaz

Najbolja praksa da se to postigne (dopusti promet u klasteru) je putem Ulazni prolaz u Istio, koji se nalazi na "rubu" klastera i omogućuje vam da omogućite Istio značajke kao što su usmjeravanje, uravnoteženje opterećenja, sigurnost i praćenje dolaznog prometa.

Komponenta Ingress Gateway i servis koji je prosljeđuje prema van instalirani su na klaster tijekom instalacije Istio. Da biste saznali vanjsku 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 pomoću ovog IP-a (nazivat ću ga EXTERNAL-IP), pa ćemo radi 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 ovom IP-u putem preglednika, dobit ćete grešku Service Unavailable, jer prema zadanim postavkama Istio blokira sav dolazni prometdok se pristupnik ne definira.

Resurs pristupnika

Gateway je CRD (Custom Resource Definition) u Kubernetesu, definiran nakon instaliranja Istia u klaster i omogućavanja mogućnosti specificiranja portova, protokola i hostova za koje želimo dopustiti dolazni promet.

U našem slučaju, želimo dopustiti HTTP promet na portu 80 za sve hostove. Problem je realiziran 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:
- "*"

Ovu konfiguraciju nije potrebno objašnjavati osim selektora istio: ingressgateway. Pomoću ovog birača možemo odrediti na koji Ingress Gateway primijeniti konfiguraciju. U našem slučaju, to je Ingress Gateway kontroler, koji je standardno instaliran u Istio.

Konfiguracija se primjenjuje pozivom sljedeće naredbe:

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

Gateway sada dopušta pristup portu 80, ali nema pojma kamo usmjeriti zahtjeve. Za ovo će vam trebati Virtualne usluge.

Resurs virtualne usluge

VirtualService govori Ingress Gatewayu kako usmjeriti zahtjeve koji su dopušteni unutar klastera.

Zahtjevi za našu aplikaciju koji dolaze putem http-gatewaya moraju se poslati na usluge sa-frontend, sa-web-app i sa-feedback:

Rute koje se konfiguriraju s VirtualServices

Razmotrite zahtjeve koje treba poslati SA-Frontendu:

• Točno podudaranje usput / treba poslati na SA-Frontend da dobije index.html;
• Staze s prefiksom /static/* treba poslati u SA-Frontend kako bi se dobile statičke datoteke koje se koriste u sučelju, kao što su CSS i JavaScript;
• Staze koje odgovaraju regularnom izrazu '^.*.(ico|png|jpg)$', mora se poslati na SA-Frontend, jer Ovo su slike prikazane na stranici.

Implementacija se postiže sljedećom konfiguracijom (sa-virtualna usluga-vanjska.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žni bodovi:

 Ovaj VirtualService odnosi se na zahtjeve koji dolaze http-pristupnik;
 В destination definira servis kojem se šalju zahtjevi.

Primijetiti: Gornja konfiguracija pohranjena je u datoteci sa-virtualservice-external.yaml, koji također sadrži postavke za usmjeravanje na SA-WebApp i SA-Feedback, ali je skraćen ovdje u članku radi sažetosti.
Primijenite VirtualService pozivom:

Primijetiti: Kada primijenimo Istio resurse, Kubernetes API Server pokreće događaj koji Istio Control Plane prima, a nakon toga se nova konfiguracija primjenjuje na Envoy proxyje svake jedinice. Čini se da je kontroler ulaznog prolaza još jedan izaslanik konfiguriran u kontrolnoj ravnini. Sve ovo izgleda ovako na dijagramu:


Istio-IngressGateway konfiguracija za usmjeravanje zahtjeva
Analiza raspoloženja sada je dostupna na http://{EXTERNAL-IP}/. Ne brinite ako dobijete status Not Found: ponekad je potrebno malo više vremena da konfiguracija stupi na snagu i da se Envoy predmemorije ažuriraju.
Prije nego nastavite, malo se poigrajte s aplikacijom kako biste generirali promet. (njegova prisutnost je neophodna za jasnoću u kasnijim radnjama - pribl. prev.).
Kiali: uočljivost
Da biste došli do Kiali administratorskog sučelja, pokrenite sljedeću naredbu:

...i otvoriti http://localhost:20001/prijavom kao admin/admin. Ovdje ćete pronaći mnoge korisne značajke, na primjer, provjeriti konfiguraciju Istio komponenti, vizualizirati usluge iz informacija prikupljenih presretanjem mrežnih zahtjeva, dobiti odgovore na pitanja "Tko koga kontaktira?", "Koja verzija usluge ima problema neuspjesi?" i tako dalje. Općenito, istražite mogućnosti Kialija prije nego prijeđete na vizualizaciju metrike s Grafanom.

Grafana: vizualizacija metrike
Mjerni podaci prikupljeni u Istiu završavaju u Prometheusu i vizualiziraju se pomoću Grafane. Da biste došli do Grafana administratorskog sučelja, pokrenite naredbu ispod, a zatim otvorite http://localhost:3000/:

Klikom na meni Naslovna gore lijevo i odaberite Istio Service Dashboard u gornjem lijevom kutu počnite s uslugom sa-web-aplikacijaza pregled prikupljenih metrika:

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

Sada imamo puno ljepše grafove, a osim njih i prekrasne alate Prometheus za praćenje i Grafana za vizualizaciju metrike, koji će nam omogućiti da učimo o performansama, zdravstvenom stanju, poboljšanjima/degradacijama usluga tijekom vremena.
Na kraju, pogledajmo praćenje zahtjeva u uslugama.
Jaeger: trasiranje
Trebat će nam traženje, jer što više servisa 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 - koji je razlog? Prvi servis? Ili drugo? U obje postoje iznimke - pogledajmo zapisnike svake. Koliko često ste se uhvatili u ovome? Naš je posao više poput softverskih detektiva nego programera...
Ovo je široko rasprostranjen problem u mikroservisima i rješava se distribuiranim sustavima praćenja, u kojima servisi međusobno prosljeđuju jedinstveno zaglavlje, nakon čega se te informacije preusmjeravaju u sustav praćenja, gdje se uspoređuju s podacima zahtjeva. Evo ilustracije:


TraceId se koristi za identifikaciju zahtjeva
Istio koristi Jaeger Tracer, koji implementira OpenTracing API okvir neovisan o dobavljaču. Jaeger korisničkom sučelju možete pristupiti sljedećom naredbom:

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

Ovaj trag pokazuje:

 Zahtjev dolazi istio-ingressgateway (ovo je prva interakcija s jednom od usluga, a za zahtjev se generira Trace ID), nakon čega gateway šalje zahtjev usluzi sa-web-aplikacija.
 U službi sa-web-aplikacija zahtjev preuzima Envoy sidecar, "dijete" se stvara u rasponu (zato ga vidimo u tragovima) i preusmjerava se u spremnik sa-web-aplikacija. (Raspon - logična jedinica rada u Jaegeru, koja ima naziv, vrijeme početka operacije i njezino trajanje. Rasponi se mogu ugniježditi i naručiti. Usmjereni aciklički graf raspona tvori trag. - cca. prev.)
 Ovdje se zahtjev obrađuje metodom analiza osjećaja. Ove tragove već je generirala aplikacija, tj. zahtijevali su izmjene koda.
 Od tog trenutka pokreće se POST zahtjev sa-logika. Trace ID mora biti proslijeđen s sa-web-aplikacija.
 ...

Primijetiti: U koraku 4, aplikacija bi trebala vidjeti zaglavlja koja je generirao Istio i proslijediti ih sljedećim zahtjevima, kao što je prikazano na slici ispod:


(A) Prosljeđivanje zaglavlja odgovornost je Istia; (B) Usluge su odgovorne za zaglavlja
Istio obavlja glavninu posla jer generira zaglavlja za dolazne zahtjeve, stvara nove raspone u svakom sidecareu i prosljeđuje ih. Međutim, bez rada sa zaglavljima unutar usluga izgubit će se puna staza praćenja zahtjeva.
Sljedeća zaglavlja moraju se uzeti u obzir (proslijediti):

Ovo je jednostavan zadatak, ali za pojednostavljenje njegove provedbe već postoji mnoge knjižnice - na primjer, u usluzi sa-web-app, RestTemplate klijent prosljeđuje ta zaglavlja ako jednostavno dodate biblioteke Jaeger i OpenTracing u njegove ovisnosti.
Imajte na umu da aplikacija Sentiment Analysis demonstrira implementacije u Flasku, Springu i ASP.NET Coreu.
Sada kada je jasno što dobivamo odmah (ili gotovo izvan okvira), pogledajmo fino podešavanje usmjeravanja, upravljanje mrežnim prometom, sigurnost i još mnogo toga!
Bilješka. prev.: pročitajte o tome u sljedećem dijelu materijala o Istio od Rinora Malokua, čiji će prijevodi uslijediti na našem blogu u bliskoj budućnosti. UPDATE (14. ožujka): Drugi dio već objavljeno.
PS od prevoditelja
Pročitajte i na našem blogu:

 "Povratak na mikrousluge s Istiom": dio 2 (usmjeravanje, kontrola prometa), dio 3 (provjera autentičnosti i autorizacija);
 «Conduit - lagana servisna mreža za Kubernetes»;
 «Što je servisna mreža i zašto mi je potrebna [za aplikaciju u oblaku s mikroservisima]?»;
 «Ilustrirani vodič za umrežavanje u Kubernetesu. 1. i 2. dio»;
 «Kako je ovaj kontejner s prikolicom završio ovdje [u Kubernetesu]?".

Izvor: www.habr.com