Povratak mikroservisima s Istio. Dio 1

Napomena za prijevod.: Service meshovi postali su relevantno rješenje u modernoj infrastrukturi za aplikacije koje slijede mikroservisnu arhitekturu. Iako je Istio poznat mnogim DevOps inženjerima, to je prilično nov proizvod koji, budući da nudi opsežne mogućnosti, može zahtijevati značajno vrijeme za upoznavanje. Njemački inženjer Rinor Maloku, koji je zadužen za Cloud computing za velike klijente u telekomunikacijskoj kompaniji Orange Networks, napisao je izvanredan niz materijala koji omogućuju brzo i duboko uranjanje u Istio. On započinje svoj pregled s objašnjenjem što Istio uopće može i kako to možete brzo vidjeti vlastitim očima.

Istio — Open Source projekt razvijen u suradnji timova iz Googlea, IBM-a i Lyfta. Rješava kompleksnosti koje se javljaju u aplikacijama temeljenim na mikroservisima, kao što su:

• Upravljanje prometom: timeout-i, ponovni pokušaji, balansiranje opterećenja;
• Sigurnost: autentifikacija i autorizacija krajnjeg korisnika;
• Promatranje: praćenje, nadziranje, logiranje.

Sve to može biti riješeno na razini aplikacije, međutim, nakon toga vaša se usluga više neće smatrati "mikro". Svi dodatni napori za rješavanje ovih problema predstavljaju dodatni trošak resursa kompanije, koji bi se mogli iskoristiti za direktne poslovne vrednosti. Uzmimo primjer:

Voditelj projekta: Koliko dugo trebamo dodati mogućnost povratnih informacija?
Programer: Dva sprinuta.

VP: Što?.. To je samo CRUD!
P: Izraditi CRUD je jednostavan dio zadatka, ali ćemo također morati autentificirati i autorizirati korisnike i usluge. Budući da je mreža nepouzdana, bit će potrebno implementirati ponovne zahtjeve, kao i circuit breaker uzorak u klijentima. Također, kako bismo osigurali da cijeli sustav ne padne, bit će potrebni timeout-i i bulkheads (više o oba spomenuta uzorka pročitajte u nastavku članka — napomena prev.), a kako bismo otkrili probleme, biti će potrebno nadziranje, praćenje, […]

VP: Oh, hajdemo onda jednostavno dodati ovu funkciju u uslugu proizvoda.

Mislim da je ideja jasna: količina koraka i truda potrebnog za dodavanje jedne usluge je ogromna. U ovom članku ćemo razmotriti kako Istio uklanja sve gore spomenute kompleksnosti (koje nisu fokusirane na poslovnu logiku) iz usluga.

Napomena: Članak pretpostavlja da imate praktično znanje o Kubernetesu. U suprotnom, preporučujem da pročitate moj uvod u Kubernetes i tek nakon toga nastavite s čitanjem ovog materijala.

Ideja Istio

U svijetu bez Istia, jedna usluga upućuje direktne zahtjeve drugoj, a u slučaju neuspjeha, usluga mora sama obraditi to: pokušati ponovno, predvidjeti vremensko ograničenje, otvoriti circuit breaker itd.

Mrežni promet u Kubernetessu

Istio nudi specijalizirano rješenje, potpuno odvojeno od usluga i funkcioniše putem intervencije u mrežnoj interakciji. Na taj način implementira:

• Otpornost na greške: oslanjajući se na statusni kod u odgovoru, razumije je li došlo do greške u zahtjevu i ponavlja ga.
• Kanarinci ili canary ispuštanja: preusmjerava na novu verziju usluge samo fiksni postotak zahtjeva.
• Praćenje i metrike: za koliko vremena je usluga odgovorila?
• Praćenje i vidljivost: dodaje posebne zaglavlja u svaki zahtjev i prati ih u klasteru.
• Sigurnost: izvlači JWT-token, autentificira i autorizira korisnike.

Ovo su samo neke od mogućnosti (zapravo samo neke!), da vas zainteresiraju. A sada, zaronimo u tehničke detalje!

Arhitektura Istio

Istio presreće sav mrežni promet i primjenjuje na njega skup pravila, umetnuvši pametni proxy u svaki pod u obliku sidecar kontejnera. Proxy, koji aktiviraju sve mogućnosti, čine Data Plane, i mogu se dinamički konfigurirati pomoću Control Plane.

Data Plane

Umetnuti proksi u podove omogućava Istio-u da lako ispuni naše potrebne zahtjeve. Na primjer, provjerimo funkcionalnosti ponovnih pokušaja i circuit breaker.

Kako su retries i circuit breaking implementirani u Envoy

Zaključno:

1. Envoy (riječ je o proksiju koji se nalazi u sidecar kontejneru, koji se širi i kao odvojeni proizvod — napomena prev.) šalje zahtjev prvom primjerku usluge B i nastaje greška.
2. Envoy Sidecar pokušava ponovno (retry). (1)
3. Zahtev sa greškom se vraća proxy-ju koji ga je pozvao.
4. Tako se otvara Circuit Breaker i poziva se sljedeća usluga za naredne zahtjeve. (2)

To znači da nećete morati koristiti još jednu biblioteku za Retry, nećete morati razvijati vlastitu implementaciju Circuit Breaking i Service Discovery na programskom jeziku X, Y ili Z. Sve to i još mnogo toga dostupno je odmah u Istio-u i ne zahtijeva. ništa promjena u kodu.

Odlično! Sada biste mogli poželjeti krenuti na put s Istio, ali još uvijek imate neka pitanja i nejasnoće. Ako je to univerzalno rješenje za sve situacije, prirodno je da se zapitate: svi takvi pristupi se u stvarnosti često pokazuje neodgovarajućima za nijednu situaciju.

I konačno ćete pitati: "Može li se konfigurirati?"

Sada ste spremni za morsko putovanje — upoznajmo se s Control Plane.

Control Plane

Sastoji se od tri komponente: Pilot, Mixer i Citadel, — koji zajedničkim snagama konfiguriraju Envoye za usmjeravanje prometa, primjenjuju politike i prikupljaju telemetrijske podatke. Schematika svega toga izgleda ovako:

Interakcija Control Plane s Data Plane

Envoye (tj. data plane) konfigurirani su pomoću Kubernetes CRD (Custom Resource Definitions) koje definira Istio i posebno su namijenjene za ovu svrhu. Za vas to znači da se predstavljaju kao još jedan resurs u Kubernetesu s poznatom sintaksom. Nakon kreiranja, ovaj resurs će biti prepoznat od strane control plane-a i primijenjen na Envoye.

Odnos usluga prema Istio

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

Iskreno govoreći, o prisutnosti Istio-a usluge znaju koliko ribe znaju o vodi kada se pitaju: "Što uopće voda jest?".

Ilustracija Victoria Dimitrakopoulos: — Kako ti se sviđa voda? — Što uopće voda jest?

Tako možete uzeti radni klaster i nakon implementacije Istio komponenti, usluge unutar njega će nastaviti raditi, a nakon uklanjanja tih komponenti — sve će ponovo biti u redu. Naravno, prilikom toga ćete izgubiti mogućnosti koje nudi Istio.

Dosta teorije — prebacimo to znanje u praksu!

Istio u praksi

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

Nakon kreiranja klastera i postavljanja pristupa Kubernetesu putem konzolnog alata, možete instalirati Istio putem paketa menadžera Helm.

Instalacija Helma

Instalirajte Helm klijent na vašem računalu, kao što se opisuje u službene dokumentacije. Koristit ćemo ga za generiranje predložaka za instalaciju Istio u sljedećem poglavlju.

Instalacija Istio

Preuzmite resurse Istio iz najnovijeg izdanja (originalna autorska poveznica na verziju 1.0.5 promijenjena je na aktualnu, tj. 1.0.6 — napomena prev.), izvadite sadržaj u jedan direktorij, koji ću kasnije nazvati [istio-resources].

Za jednostavno prepoznavanje Istio resursa, stvorite u K8s klasteru prostor imena istio-system:

$ kubectl create namespace istio-system

Završite instalaciju prelaskom u direktorij [istio-resources] i izvršavanjem 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 Istio u datoteku istio.yaml. Prilagodili smo standardni predložak sebi, navodeći sljedeće postavke:

• global.mtls.enabled postavljeno na false (tj. mTLS autentifikacija je onemogućena — napomena prev.), kako bismo pojednostavili naš proces upoznavanja;
• tracing.enabled omogućuje praćenje zahtjeva pomoću Jaeger-a;
• kiali.enabled postavlja Kiali u klaster za vizualizaciju usluga i prometa;
• grafana.enabled postavlja Grafanu za vizualizaciju prikupljenih metrike.

Primijenit ćemo generirane resurse naredbom:

$ kubectl apply -f istio.yaml

Instalacija Istio u klaster je završena! Pričekajte da svi 'pod'-ovi u prostoru imena istio-system budu u stanju Ispunjeno ili Završeno, izvršavanjem donje naredbe:

$ kubectl get pods -n istio-system

Sada smo spremni nastaviti u sljedećem odjeljku, gdje ćemo pokrenuti i unijeti aplikaciju.

Arhitektura aplikacije Sentiment Analysis

Iskoristit ćemo primjer mikroservisne aplikacije Sentiment Analysis, korištene u već spomenutoj artiklu o uvodu u Kubernetes. Ona je dovoljno složena da pokaže mogućnosti Istio u praksi.

Aplikacija se sastoji od četiri mikroservisa:

1. Servis SA-Frontend, koji poslužuje frontend aplikacije na Reactjs;
2. Servis SA-WebApp, koji poslužuje zahtjeve za Sentiment Analysis;
3. Servis SA-Logic, koji izvršava sam sentiment-analyzu;
4. Servis SA-Feedback, koji od korisnika prikuplja povratne informacije o točnosti provedenog analiziranja.

Na ovoj shemi, osim usluga, također vidimo Ingress Controller koji u Kubernetesu usmjerava dolazne zahtjeve na odgovarajuće usluge. U Istio-u se koristi slična koncepcija unutar Ingress Gateway-a, detalji slijede.

Pokretanje aplikacije s Istio proxy-jem

Za daljnje operacije spomenute u članku, klonirajte vlastiti repozitorij istio-mastery. U njemu se nalaze aplikacija i manifesti za Kubernetes i Istio.

Umetanje sidecar-a

Umetanje se može izvršiti automatski ili ručno. Da bi se automatski dodali sidecar kontejneri, potrebno je postaviti label za prostor imena istio-injection=enabled, što se radi sljedećom naredbom:

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

Sada će svaki pod koji se pokrene u prostoru imena po defaultu (default) dobiti svoj sidecar kontejner. Da bismo se uvjerili u to, hajde da deployamo testnu aplikaciju tako da pređemo u korijenski direktorij repozitorija [istio-mastery] i izvršimo 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 pokretanja servisa, provjerit ćemo imaju li podovi dva kontejnera (sami servis i njegov sidecar), izvršavajući naredbu kubectl get pods i uvjeravajući se da je pod u stupcu READY ima vrijednost 2/2, što simbolizira da su oba kontejnera pokrenuta:

$ 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:

Envoy proxy u jednom od podova

Sada kada je aplikacija pokrenuta i radi, trebamo omogućiti ulaznom prometu da dolazi do aplikacije.

Ingress Gateway

Najbolja praksa za postizanje ovoga (omogućavanje prometa u klasteru) je kroz Ingress Gateway u Istio, koja se nalazi na „granici“ klastera i omogućava aktiviranje funkcija Istio za ulazni promet kao što su usmjeravanje, balansiranje opterećenja, sigurnost i praćenje.

Komponenta Ingress Gateway i servis koji je promašio van, instalirani su u klaster tijekom instalacije Istio. Da biste saznali vanjsku IP adresu servisa, izvršite:

$ 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

Pristupat ćemo aplikaciji preko ove IP adrese i dalje (nazvat ću je EXTERNAL-IP), stoga ćemo za praktičnost 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 pokušate sada pristupiti ovoj IP adresi putem preglednika, dobit ćete grešku Service Unavailable, jer po defaultu Istio blokira sav ulazni promet, dok ne bude definiran Gateway.

Resurs Gateway

Gateway je CRD (Custom Resource Definition) u Kubernetesu, definiran nakon instalacije Istio u klasteru, koji aktivira mogućnost definiranja portova, protokola i hostova za koje želimo dozvoliti dolazni promet.

U našem slučaju želimo dozvoliti HTTP promet na 80. portu za sve hostove. Zadatak 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 zahtijeva objašnjenja osim selektora istio: ingressgateway. Pomoću ovog selektora možemo odrediti kojem Ingress Gateway-u se primjenjuje konfiguracija. U našem slučaju to je kontroler Ingress Gateway, koji je po defaultu instaliran u Istio.

Konfiguracija se primjenjuje pozivanjem sljedeće komande:

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

Sada gateway dozvoljava pristup portu 80, ali nema ideju kamo usmjeriti zahtjeve. Za to su potrebni Virtual Services.

Resurs VirtualService

VirtualService ukazuje Ingress Gateway-u kako usmjeriti zahtjeve koji su dopušteni unutar klastera.

Zahtjevi za našu aplikaciju, koji dolaze kroz http-gateway, trebaju biti poslani na usluge sa-frontend, sa-web-app i sa-feedback:

Rute koje treba konfigurirati s VirtualServices

Razmotrite zahtjeve koji trebaju ići na SA-Frontend:

• Tačno podudaranje putanje / mora se slati na SA-Frontend za preuzimanje index.html;
• Putanje s prefiksom /static/* mora se slati na SA-Frontend za preuzimanje statičkih datoteka korištenih u frontendu, kao što su CSS i JavaScript;
• Putanje koje odgovaraju redovitom izrazu '^.*\.(ico|png|jpg)$', moraju se slati na SA-Frontend, jer su to slike koje se prikazuju na stranici.

Implementacija se postiže sljedećom konfiguracijom (sa-virtualservice-external.yaml):

vrsta: VirtualService
metapodaci:
  naziv: sa-vanjske-usluge
spec:
  domaćini:
  - "*"
  prolazi:
  - http-prolaz                      # 1
  http:
  - podudaranje:
    - uri:
        točno: \/
    - uri:
        točno: \/callback
    - uri:
        prefiks: \/static
    - uri:
        regex: '^.*.(ico|png|jpg)

Važne točke:



 	
 Ovaj VirtualService se odnosi na zahtjeve koji dolaze putem http-prolaz;


 	
 U destination određuje uslugu na koju se šalju zahtjevi.




Napomena: Gornja konfiguracija se čuva u datoteci sa-virtualservice-external.yaml, koja također sadrži postavke za usmjeravanje prema SA-WebApp i SA-Feedback, ali je ovdje skraćena radi sažetosti.

Primjenjujemo VirtualService pozivom:

$ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml
virtualservice.networking.istio.io/sa-external-services created
Napomena: Kada koristimo resurse Istio, Kubernetes API Server stvara događaj koji preuzima Istio Control Plane, i tek nakon toga nova konfiguracija se primjenjuje na proxy servere Envoy svakog pod-a. A kontroler Ingress Gateway predstavlja još jedan Envoy, konfiguriran u Control Plane. Sve to na dijagramu izgleda ovako:

 Konfiguracija Istio-IngressGateway za usmjeravanje zahtjeva
Aplikacija Sentiment Analysis postala je dostupna na http://{EXTERNAL-IP}/. Ne brinite ako dobijete status Not Found: ponekad je potrebno malo više vremena da se konfiguracija aktivira i keširanje Envoy ažurira.
Prije nego nastavite, malo se igrajte s aplikacijom kako biste generirali promet (njegova prisutnost je potrebna za preglednost u sljedećim radnjama — nap. prev.).
Kiali: nadzor
Da biste ušli u administrativno sučelje Kiali, izvršite sljedeću naredbu:
$ kubectl port-forward 
    $(kubectl get pod -n istio-system -l app=kiali 
    -o jsonpath='{.items[0].metadata.name}') 
    -n istio-system 20001
… i otvorite http://localhost:20001/, prijavivši se kao admin/admin. Ovdje ćete pronaći mnogo korisnih mogućnosti, kao što su provjera konfiguracije Istio komponenti, vizualizacija servisa na temelju informacija prikupljenih prilikom presretanja mrežnih zahtjeva, dobivanje odgovora na pitanja „Tko se kome obraća?”, „Kod koje verzije servisa dolazi do grešaka?” itd. Uglavnom, istražite mogućnosti Kiali prije nego što krenete dalje — prema vizualizaciji metrika s Grafana.
Grafana: vizualizacija metrika
Metrike prikupljene u Istio idu u Prometheus i vizualiziraju se s Grafana. Da biste ušli u administrativno sučelje Grafana, izvršite dolje navedenu naredbu, a zatim otvorite 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
Kliknite na izbornik Home u gornjem lijevom kutu i odaberite Istio Service Dashboard u gornjem lijevom kutu, počnite s uslugom sa-web-app, kako biste pregledali prikupljene metrike:
Ovdje nas očekuje prazna i potpuno dosadna prezentacija — vodstvo nikada ne bi odobrio tako nešto. Stoga, hajde da stvorimo malu opterećenost sljedećom naredbom:
$ while true; do 
    curl -i http://$EXTERNAL_IP/sentiment 
    -H "Content-type: application/json" 
    -d '{"sentence": "I love yogobella"}'; 
    sleep .8; done
Evo, sada imamo mnogo ljepše grafikone, a uz to i izvrsne alate Prometheus za praćenje i Grafana za vizualizaciju metrika koji će nam omogućiti da saznamo o performansama, stanju, poboljšanjima/degradaciji rada servisa tijekom vremena.
Na kraju, pogledajmo praćenje zahtjeva u servisima.
Jaeger: praćenje
Praćenje nam je potrebno jer što više servisa imamo, teže je doći do uzroka kvara. Pogledajmo jednostavan slučaj sa slike ispod:

 Tipični primjer slučajnog neuspješnog zahtjeva
Zahtjev dolazi, pada — u čemu je uzrok? Prvi servis? Ili drugi? Ima iznimaka u oba — pogledajmo logove svakog. Koliko često ste se uhvatili za ovim zadatkom? Naš posao više sliči na detektive za softver, a ne na programere...
Ovo je široko rasprostranjen problem u mikroslužbama i rješava se raspodijeljenim sustavima praćenja, u kojem servisi međusobno šalju jedinstvenu oznaku zaglavlja, a zatim se te informacije preusmjeravaju u sustav praćenja gdje se usklađuju s podacima zahtjeva. Evo ilustracije:

 Za identifikaciju zahtjeva koristi se TraceId
U Istio se koristi Jaeger Tracer, koji implementira neovisni od ponuđača okvir OpenTracing API. Pristup korisničkom sučelju Jaeger može se dobiti sljedećom naredbom:
$ kubectl port-forward -n istio-system 
    $(kubectl get pod -n istio-system -l app=jaeger 
    -o jsonpath='{.items[0].metadata.name}') 16686
Sada idite na http://localhost:16686/ i odaberite servis sa-web-app. Ako servis nije prikazan u padajućem izborniku — generirajte aktivnost na stranici i osvježite sučelje. Nakon toga pritisnite gumb Find Traces, koji će pokazati najnovije tragove — odaberite bilo koji — prikazat će se detaljne informacije o svim tragovima:
Ovaj trag pokazuje:
 
 Zahtjev dolazi u istio-ingressgateway (to je prvo interakcija s jednim od servisa, a za zahtjev se generira Trace ID), nakon čega prolaz usmjerava zahtjev u servis sa-web-app.
 
 U servisu sa-web-app zahtjev hvata Envoy sidecar, stvara se 'dijete' u span-u (zato ga vidimo u tragovima) i preusmjerava se u kontejner sa-web-app. (Span — logička jedinica rada u Jaegeru, koja ima naziv, vrijeme početka operacije i njezinu trajanje. Spanovi mogu biti ugnježdeni i poredani. Usmjereni aciklični graf od spanova čini trace. — napomena prev.)
 
 Ovdje se zahtjev obrađuje metodom sentimentAnalysis. Ovi tracovi su već generirani od strane aplikacije, tj. za njih su bile potrebne izmjene u kodu.
 
 Od ovog trenutka inicira se POST zahtjev na sa-logic. Trace ID mora biti proslijeđen iz sa-web-app.
 
 …
Napomena: U 4. koraku aplikacija bi trebala vidjeti zaglavlja generirana od strane Istioa i proslijediti ih u sljedeće zahtjeve, kao što je prikazano na slici ispod:

 (A) Za prosljeđivanje zaglavlja odgovara Istio; (B) Za zaglavlja odgovaraju usluge
Istio obavlja većinu posla, jer generira zaglavlja za dolazne zahtjeve, stvara nove spanove u svakom sidecaru i proslijeđuje ih. Međutim, bez rada s zaglavljima unutar usluga, potpuni put tracea zahtjeva će biti izgubljen.
Potrebno je uzeti u obzir (proslijediti) sljedeća zaglavlja:
x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
x-ot-span-context
Ovo nije kompliciran zadatak, no za olakšavanje njegove implementacije već postoje mnoge biblioteke — na primjer, u usluzi sa-web-app klijent RestTemplate proslijedi ova zaglavlja, ako jednostavno dodate biblioteke Jaeger i OpenTracing u njegove ovisnosti.
Primijetite da aplikacija Sentiment Analysis demonstrira implementacije na Flasku, Springu i ASP.NET Core.
Sada, kada je jasno što dobivamo iz kutije (ili gotovo ‘iz kutije’), razmotrimo pitanja fino podešene usmjerenosti, upravljanja mrežnim prometom, sigurnosti itd.!
Napomena za prijevod.: o tome čitajte u sljedećem dijelu materijala o Istio od Rinora Malokua, čiji će prijevodi uslijediti na našem blogu uskoro. AZURIRAJ (14. ožujka): Drugi dio već je objavljen.
P.S. od prevodioca
Pročitajte i na našem blogu:
 
 «Povratak mikroservisima uz Istio»: dio 2 (usmjerenje, upravljanje prometom), dio 3 (autentifikacija i autorizacija);
 
 «Kako sam dospio u ThoughtWorks ili uzorno intervjuiranje»;
 
 «Što je service mesh i zašto mi treba [za cloud aplikaciju s mikroservisima]?»;
 
 «Ilustrirani vodič za uređivanje mreže u Kubernetesu. Dijelovi 1 i 2»;
 
 «Kako je ovaj sidecar kontejner dospio ovdje [u Kubernetes]?».
Izvor: habr.com
route:
 - destination:
 host: sa-frontend             # 2
 port:
 number: 80
 Važne točke:
 
 Ovaj VirtualService se odnosi na zahtjeve koji dolaze putem http-prolaz;
 
 U destination određuje uslugu na koju se šalju zahtjevi.
Napomena: Gornja konfiguracija se čuva u datoteci sa-virtualservice-external.yaml, koji također sadrži postavke za usmjerenje u SA-WebApp i SA-Feedback, ali je skraćen ovdje u članku radi sažetosti.
Primijenimo VirtualService pozivom:
Napomena: Kada koristimo Istio resurse, Kubernetes API Server stvara događaj koji prima Istio Control Plane, i nakon toga nova konfiguracija se primjenjuje na proxy poslužitelje Envoy svakog pod-a. A kontroler Ingress Gateway se predstavlja kao još jedan Envoy, konfiguriran u Control Plane. Sve to na dijagramu izgleda ovako:

 Konfiguracija Istio-IngressGateway za usmjeravanje zahtjeva
Aplikacija Sentiment Analysis postala je dostupna na http://{EXTERNAL-IP}/. Ne brinite ako dobijete status Not Found: ponekad je potrebno malo više vremena da se konfiguracija aktivira i keširanje Envoy ažurira.
Prije nego nastavite, malo se igrajte s aplikacijom kako biste generirali promet (njegova prisutnost je potrebna za preglednost u sljedećim radnjama — nap. prev.).
Kiali: nadzor
Da biste ušli u administrativno sučelje Kiali, izvršite sljedeću naredbu:
… i otvorite http://localhost:20001/, prijavivši se kao admin/admin. Ovdje ćete pronaći mnogo korisnih mogućnosti, kao što su provjera konfiguracije Istio komponenti, vizualizacija servisa na temelju informacija prikupljenih prilikom presretanja mrežnih zahtjeva, dobivanje odgovora na pitanja „Tko se kome obraća?”, „Kod koje verzije servisa dolazi do grešaka?” itd. Uglavnom, istražite mogućnosti Kiali prije nego što krenete dalje — prema vizualizaciji metrika s Grafana.
Grafana: vizualizacija metrika
Metrike prikupljene u Istio idu u Prometheus i vizualiziraju se s Grafana. Da biste ušli u administrativno sučelje Grafana, izvršite dolje navedenu naredbu, a zatim otvorite http://localhost:3000/:
Kliknite na izbornik Home u gornjem lijevom kutu i odaberite Istio Service Dashboard u gornjem lijevom kutu, počnite s uslugom sa-web-app, kako biste pregledali prikupljene metrike:
Ovdje nas očekuje prazna i potpuno dosadna prezentacija — vodstvo nikada ne bi odobrio tako nešto. Stoga, hajde da stvorimo malu opterećenost sljedećom naredbom:
Evo, sada imamo mnogo ljepše grafikone, a uz to i izvrsne alate Prometheus za praćenje i Grafana za vizualizaciju metrika koji će nam omogućiti da saznamo o performansama, stanju, poboljšanjima/degradaciji rada servisa tijekom vremena.
Na kraju, pogledajmo praćenje zahtjeva u servisima.
Jaeger: praćenje
Praćenje nam je potrebno jer što više servisa imamo, teže je doći do uzroka kvara. Pogledajmo jednostavan slučaj sa slike ispod:

 Tipični primjer slučajnog neuspješnog zahtjeva
Zahtjev dolazi, pada — u čemu je uzrok? Prvi servis? Ili drugi? Ima iznimaka u oba — pogledajmo logove svakog. Koliko često ste se uhvatili za ovim zadatkom? Naš posao više sliči na detektive za softver, a ne na programere...
Ovo je široko rasprostranjen problem u mikroslužbama i rješava se raspodijeljenim sustavima praćenja, u kojem servisi međusobno šalju jedinstvenu oznaku zaglavlja, a zatim se te informacije preusmjeravaju u sustav praćenja gdje se usklađuju s podacima zahtjeva. Evo ilustracije:

 Za identifikaciju zahtjeva koristi se TraceId
U Istio se koristi Jaeger Tracer, koji implementira neovisni od ponuđača okvir OpenTracing API. Pristup korisničkom sučelju Jaeger može se dobiti sljedećom naredbom:
Sada idite na http://localhost:16686/ i odaberite servis sa-web-app. Ako servis nije prikazan u padajućem izborniku — generirajte aktivnost na stranici i osvježite sučelje. Nakon toga pritisnite gumb Find Traces, koji će pokazati najnovije tragove — odaberite bilo koji — prikazat će se detaljne informacije o svim tragovima:
Ovaj trag pokazuje:
 
 Zahtjev dolazi u istio-ingressgateway (to je prvo interakcija s jednim od servisa, a za zahtjev se generira Trace ID), nakon čega prolaz usmjerava zahtjev u servis sa-web-app.
 
 U servisu sa-web-app zahtjev preuzima Envoy sidecar, stvara se 'dijete' u span-u (zato ga vidimo u tragovima) i preusmjerava se u kontejner sa-web-app. (Span — logička jedinica rada u Jaeger-u, koja ima naziv, vrijeme početka operacije i njezinu trajanje. Span-ovi mogu biti ugniježdeni i strukturirani. Usmjereni aciklični graf span-ova čini trag. — nap. prev.)
 
 Ovdje se zahtjev obrađuje metodom sentimentAnalysis. Ovi tracovi su već generirani od strane aplikacije, tj. za njih su bile potrebne izmjene u kodu.
 
 Od ovog trenutka inicira se POST zahtjev na sa-logic. Trace ID mora biti proslijeđen iz sa-web-app.
 
 …
Napomena: U 4. koraku aplikacija bi trebala vidjeti zaglavlja generirana od strane Istioa i proslijediti ih u sljedeće zahtjeve, kao što je prikazano na slici ispod:

 (A) Za prosljeđivanje zaglavlja odgovara Istio; (B) Za zaglavlja odgovaraju usluge
Istio obavlja glavni posao, jer generira zaglavlja za dolazne zahtjeve, stvara nove span-ove u svakom sidecar-u i prosljeđuje ih. Međutim, bez rada sa zaglavljima unutar servisa, potpuni put traganja zahtjeva bit će izgubljen.
Potrebno je uzeti u obzir (proslijediti) sljedeća zaglavlja:
Ovo nije kompliciran zadatak, no za olakšavanje njegove implementacije već postoje mnoge biblioteke — na primjer, u usluzi sa-web-app klijent RestTemplate proslijedi ova zaglavlja, ako jednostavno dodate biblioteke Jaeger i OpenTracing u njegove ovisnosti.
Primijetite da aplikacija Sentiment Analysis demonstrira implementacije na Flasku, Springu i ASP.NET Core.
Sada, kada je jasno što dobivamo iz kutije (ili gotovo ‘iz kutije’), razmotrimo pitanja fino podešene usmjerenosti, upravljanja mrežnim prometom, sigurnosti itd.!
Napomena za prijevod.: o tome čitajte u sljedećem dijelu materijala o Istio od Rinora Malokua, čiji će prijevodi uslijediti na našem blogu uskoro. AZURIRAJ (14. ožujka): Drugi dio već je objavljen.
P.S. od prevodioca
Pročitajte i na našem blogu:
 

• «Povratak mikroservisima uz Istio»: dio 2 (usmjerenje, upravljanje prometom), dio 3 (autentifikacija i autorizacija);
• «Kako sam dospio u ThoughtWorks ili uzorno intervjuiranje»;
• «Što je service mesh i zašto mi treba [za cloud aplikaciju s mikroservisima]?»;
• «Ilustrirani vodič za uređivanje mreže u Kubernetesu. Dijelovi 1 i 2»;
• «Kako je ovaj sidecar kontejner dospio ovdje [u Kubernetes]?».

Izvor: habr.com