🥇Nazaj k mikrostoritev skupaj z Istio. Del 1

Op. prev.: Service mesh je gotovo postalo odgovarajuće rešenje u savremenoj infrastrukturi za aplikacije koje se oslanjaju na mikroservisnu arhitekturu. Iako je Istio poznat mnogim DevOps inženjerima, to je prilično nov proizvod koji, iako je složen u smislu ponuđenih mogućnosti, može zahtevati značajno vreme za upoznavanje. Nemački inženjer Rinor Maloku, zadužen za cloud computing za velike klijente u telekomunikacijskoj kompaniji Orange Networks, napisao je sjajan ciklus materijala koji omogućavaju brzo i duboko uranjanje u Istio. On započinje svoju priču o tome šta Istio uopšte može da uradi i kako to možete brzo videti svojim očima.

Istio — Open Source projekat, razvijen uz saradnju timova iz Google-a, IBM-a i Lyft-a. On rešava složenosti koje se javljaju u aplikacijama zasnovanim na mikroservisima, kao što su:

Upravljanje prometa: tajmauti, ponovni pokušaji, balansiranje opterećenja;
Sigurnost: autentifikacija i autorizacija krajnjeg korisnika;
Posmatranje: praćenje, monitoring, logovanje.

Sve to se može rešiti na nivou aplikacije, ali tada vaši servisi više neće biti 'mikro'. Svi dodatni napori za rešavanje ovih problema predstavljaju dodatne troškove kompanije koji bi mogli biti usmereni direktno ka stvaranju poslovne vrednosti. Razmotrimo primer:

Menadžer projekta: Koliko dugo će trajati dodavanje mogućnosti povratnih informacija?
Razvijač: Dva sprinta.
MP: Šta?.. To je samo CRUD!
R: Uraditi CRUD je jednostavan deo zadatka, ali će nam takođe trebati autentifikacija i autorizacija korisnika i servisa. Pošto je mreža nepouzdana, biće potrebno implementirati ponovno slanje zahteva, kao i pattern circuit breaker u klijentima. Takođe, kako bismo osigurali da ceo sistem ne padne, biće potrebni tajmauti i bulkheads (više o oba pomenuta patterna možete pročitati u nastavku članka — napomena prev.), a da bismo otkrili probleme, biće potrebno praćenje, praćenje zahteva, […]
MP: Oh, hajde da jednostavno dodamo ovu funkcionalnost u servis Product.

Mislim da je ideja jasna: obim koraka i napora koji su potrebni za dodavanje jednog servisa je ogroman. U ovom članku ćemo proučiti kako Istio eliminiše sve prethodno pomenute složenosti (koje nisu fokusirane na poslovnu logiku) iz servisa.

Napomena: Članek predvideva, da imate praktično znanje o Kubernetesu. V nasprotnem primeru priporočam, da preberete moj uvod v Kubernetes in šele nato nadaljujete z branjem tega gradiva.

Ideja Istio

V svetu brez Istio en servis pošilja neposredne poizvedbe drugemu, v primeru napake pa mora servis sam obvladovati situacijo: poskusiti znova, določiti časovno omejitev, odpreti circuit breaker itd.

Omrežni promet v Kubernetesu

Istio pa ponuja specializirano rešitev, ki je popolnoma ločena od storitev in deluje tako, da posega v omrežno komunikacijo. Tako implementira:

Odporna zasnova: zanaša se na kodo stanja v odgovoru, da ugotovi, ali je prišlo do napake pri poizvedbi, in jo znova izvede.
Canary uvajanja: preusmeri na novo različico storitve le določen odstotek poizvedb.
Nadzor in metrike: koliko časa je storitev potrebovala za odgovor?
Sledenje in opazovanje: doda posebne glave v vsako poizvedbo in sledi njihovemu toku v klastru.
Sigurnost: pridobi JWT-token, avtentificira in autorizira uporabnike.

To je le nekaj možnosti (resnično le nekaterih!), da vas pritegnem. Zdaj pa se potopimo v tehnične podrobnosti!

Arhitektura Istio

Istio zajame ves omrežni promet in mu uporabi niz pravil, v vsak pod vstavlja pametno proxie v obliki sidecar kontejnerja. Proxiji, ki aktivirajo vse možnosti, tvorijo Data Plane, in jih je mogoče dinamično konfigurirati s pomočjo Control Plane.

Data Plane

Vstavljenih proxijev v pode omogoča Istio zlahka doseči zahteve, ki jih potrebujemo. Na primer, preverimo funkcionalnosti ponovnih poskusov in circuit breaker.

Kako so retries in circuit breaking implementirani v Envoy

Povzemimo:

Envoy (govorimo o proxyju, ki se nahaja v sidecar kontejnerju, ki se distribuira tudi kot poseben izdelek — op. prev.) pošlje poizvedbo prvemu primeru storitve B in pride do napake.
Envoy Sidecar poskuša znova (retry). (1)
Poizvedba z napako se vrača proxyju, ki jo je sprožil.
Tako se odpre Circuit Breaker in pokliče se naslednja storitev za nadaljnje poizvedbe. (2)

To pomeni, da vam ni treba uporabljati še ene knjižnice za ponavljanje, niti ustvarjati svoje implementacije Circuit Breaker in Service Discovery v programskem jeziku X, Y ali Z. Vse to in še več je na voljo kar v Istio, brez potrebe po kakršnih koli spremembah v kodi.

Odlično! Zdaj se morda želite odpraviti na pot z Istio, vendar še vedno imate nekatere dvome in odprta vprašanja. Če je to univerzalna rešitev za vse primere, se vam upravičeno postavlja vprašanje: ali takšne rešitve v resnici niso primerne za noben primer.

In končno se boste vprašali: „Ali se to nastavi?“

Zdaj ste pripravljeni na pomorsko potovanje — spoznamo se s Control Plane.

Control Plane

Sestavljen je iz treh komponent: Pilot, Mixer in Citadel, — ki skupaj konfigurirajo Envoye za usmerjanje prometa, izvajajo politike in zbirajo telemetrične podatke. V diagramu to izgleda takole:

Interakcija Control Plane z Data Plane

Envoye (tj. data plane) so konfigurirani s pomočjo Kubernetes CRD (Definicije lastnih virov), ki jih določa Istio in so posebej namenjene za to nalogo. To pomeni, da se prikažejo kot še en vir v Kubernetesu z znanim sintaktičnim izrazom. Po ustvarjanju bo ta vir izbran s strani control plane in uporabljen za Envoye.

Odnos storitev do Istio

Opisali smo odnos Istio do storitev, vendar ne obratno: kako storitve gledajo na Istio?

Iskreno povedano, storitve so o prisotnosti Istio obveščene tako dobro, kot ribe — o vodi, ko se sprašujejo: „Kaj sploh je voda?“.

Ilustracija Victoria Dimitrakopoulos: — Kakšna je voda? — Kaj sploh je voda?

Tako lahko vzamete delujoči klaster in po namestitvi komponent Istio storitve, ki so v njem, še naprej delujejo, in po odstranitvi teh komponent bo vse znova v redu. Seveda pa boste pri tem izgubili možnosti, ki jih nudi Istio.

Dovolj teorije — prenesimo to znanje v prakso!

Istio v praksi

Istio zahteva klaster Kubernetes, v katerem so na voljo vsaj 4 vCPU in 8 GB RAM. Da bi hitro vzpostavili klaster in sledili navodilom iz članka, priporočam uporabo Google Cloud Platform, ki novim uporabnikom ponuja brezplačnih 300 $.

Po ustvarjanju gruče in nastavitvi dostopa do Kubernetes prek konzolskega orodja lahko Istio namestite prek upravitelja paketov Helm.

Namestitev Helma

Namestite odjemalca Helma na svojem računalniku, kot je opisano v uradni dokumentaciji. To bomo uporabili za generiranje predlog za namestitev Istia v naslednjem razdelku.

Namestitev Istia

Prenesite vire Istio iz zadnje različice (izvirna avtorska povezava na različico 1.0.5 je bila spremenjena na aktualno, tj. 1.0.6 — op. prev.), izvlecite vsebino v eno mapo, ki jo bom kasneje imenoval [istio-resources].

Za enostavno prepoznavo virov Istio ustvarite v gruči K8s prostor imen istio-system:

$ kubectl create namespace istio-system

Dokončajte namestitev tako, da preizkusite katalog [istio-resources] in izvedite ukaz:

$ 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

Ta ukaz bo izpisal ključne komponente Istio v datoteko istio.yaml. Spremenili smo standardno predlogo in določili naslednje parametre:

global.mtls.enabled nastavljeno na false (tj. mTLS-avtentikacija je onemogočena — op. prev.), da olajšamo naš postopek spoznavanja;
tracing.enabled omogoča sledenje zahtevam z uporabo Jaegerja;
kiali.enabled namesti Kiali v gruče za vizualizacijo storitev in prometa;
grafana.enabled namesti Grafano za vizualizacijo zbranih metrik.

Uporabimo generirane vire z ukazom:

$ kubectl apply -f istio.yaml

Namestitev Istia v gruči je končana! Počakajte, da so vsi podi v prostoru imen istio-system v stanju Running ili Completed, tako da izvedete spodnji ukaz:

$ kubectl get pods -n istio-system

Sedaj smo pripravljeni nadaljevati v naslednjem razdelku, kjer bomo vzpostavili in zagnali aplikacijo.

Arhitektura aplikacije Sentiment Analysis

Izkoristili bomo primer mikrostoritvenih aplikacij Sentiment Analysis, uporabljenih v že omenjeni uvodni članku o Kubernetes. Dovolj je zapletena, da pokaže možnosti Istia v praksi.

Aplikacija se sestavlja iz štirih mikrostoritvenih delov:

Storitve SA-Frontend, ki zagotavlja frontend aplikacije v Reactjs;
Storitve SA-WebApp, ki obdeluje zahtevke za analizo razpoloženja;
Storitve SA-Logic, ki izvaja samo analizo razpoloženja;
Storitve SA-Feedback, ki od uporabnikov zbira povratne informacije o natančnosti izvedene analize.

Na tej shemi, poleg storitev, vidimo tudi Ingress Controller, ki v Kubernetesu usmerja prihajajoče zahteve na ustrezne storitve. V Istio se uporablja podobna zasnova znotraj Ingress Gateway, podrobnosti sledijo.

Zagon aplikacije s proxyjem Istio

Za nadaljnje operacije, omenjene v članku, si klonirajte repozitorij istio-mastery. V njem so shranjene aplikacije in manifesti za Kubernetes in Istio.

Vstavljanje sidecar-ov

Vstavljanje se lahko izvede automatski ili ročno. Za samodejno vstavljanje sidecar kontejnerjev je potreben label za prostor imen istio-injection=enabled, kar se izvede s sledečim ukazom:

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

Zdaj bo vsak pod, ki bo nameščen v privzetem prostoru imen (default) prejel svoj sidecar kontejner. Da se prepričamo, torej, namestimo testno aplikacijo, tako da gremo v korenski katalog repozitorija [istio-mastery] in izvedemo sledeči ukaz:

$ 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

Po nameščanju storitev preverimo, da imajo podi dva kontejnerja (samo storitev in njen sidecar), tako da izvedemo ukaz kubectl get pods in se prepričamo, da je v stolpcu READY navedena vrednost 2/2, kar simbolizira, da sta oba kontejnerja zagnana:

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

Proxy Envoy v enem izmed podov

Zdaj, ko je aplikacija vzpostavljena in deluje, bo potrebno omogočiti prihajajočo promet v aplikacijo.

Ingress Gateway

Najboljša praksa za to (omogočiti promet v klastru) je preko Ingress Gateway v Istio, ki se nahaja na 'meji' klustra in omogoča vključitev funkcij, kot so usmerjanje, uravnoteženje obremenitev, varnost in obveščanje za prihajajoči promet.

Komponenta Ingress Gateway in storitev, ki jo usmerja navzven, sta bila nameščena v klaster med namestitvijo Istio. Da bi izvedeli zunanji IP naslov storitve, izvedite:

$ 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

Obraćamo se aplikaciji putem ove IP adrese, koju ću dalje nazivati EXTERNAL-IP, pa ćemo za praktičnost zabeležiti vrednost u promenljivu:

$ 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 da otvorite ovu IP adresu u pretraživaču, dobićete grešku Service Unavailable, jer podrazumevano Istio blokira sav dolazni saobraćaj, dok se ne definiše Gateway.

Resurs Gateway

Gateway je CRD (Custom Resource Definition) u Kubernetes-u, koji se definiše nakon instalacije Istio-a u klasteru i omogućava nam da navedemo portove, protokole i hostove za koje želimo da dozvolimo dolazni saobraćaj.

U našem slučaju želimo da dozvolimo HTTP saobraćaj na portu 80 za sve hostove. Zadatak se ostvaruje sledeć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 zahteva objašnjenja osim selektora istio: ingressgateway. Pomoću ovog selektora možemo odrediti kojem Ingress Gateway-u primenjujemo konfiguraciju. U našem slučaju, to je kontroler Ingress Gateway-a koji je podrazumevano instaliran u Istio-u.

Konfiguracija se primenjuje pozivom sledeć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 predstavu o tome gde da usmeri zahteve. Za to će biti potrebni Virtual Services.

Resurs VirtualService

VirtualService ukazuje Ingress Gateway-u kako da usmeri zahteve koji su dozvoljeni unutar klastera.

Zahtevi za našu aplikaciju, koji dolaze putem http-gateway-a, treba da budu poslati na servise sa-frontend, sa-web-app i sa-feedback:

Rute koje treba konfigurisati sa VirtualServices

Razmotrite zahteve koji treba da se usmere na SA-Frontend:

Tačno podudaranje po putanji / treba da se pošalje na SA-Frontend da dobije index.html;
Putanje sa prefiksom /static/* treba da se pošalju na SA-Frontend da dobiju statične datoteke korišćene na frontendu, poput CSS-a i JavaScript-a;
Putanje koje se uklapaju u regularni izraz '^.*.(ico|png|jpg)$', treba da se pošalju na SA-Frontend, jer su to slike prikazane na stranici.

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

vrsta: VirtualService metapodatki: ime: sa-external-services spec: gostitelji: - "*" prehodi: - http-gateway # 1 http: - ujemanje: - uri: natančno: \/ - uri: natančno: \/callback - uri: predpona: \/static - uri: regex: '^.*.(ico|png|jpg) Pomembne točke: Ta VirtualService se nanaša na zahteve, ki prihajajo preko http-gateway; V cilj opredeljuje se servis, na koji se šalju zahtevi. Napomena: Konfiguracija iznad se čuva u datoteci sa-virtualservice-external.yaml, koja takođe sadrži podešavanja za rutiranje u SA-WebApp i SA-Feedback, ali je ovde skraćena za sažetost. Primenićemo VirtualService pozivom: $ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml virtualservice.networking.istio.io/sa-external-services je kreiran Napomena: Kada primenimo resurse Istio, Kubernetes API Server kreira događaj koji dobija Istio Control Plane, i tek nakon toga nova konfiguracija se primenjuje na proxy servere Envoy svakog poda. A Ingress Gateway kontroler se predstavlja kao još jedan Envoy, konfiguriše se u Control Plane. Sve to na dijagramu izgleda ovako: Konfiguracija Istio-IngressGateway za rutiranje zahteva Aplikacija Sentiment Analysis je dostupna na http://{EXTERNAL-IP}/. Ne brinite ako dobijete status Not Found: ponekad je potrebno malo više vremena da bi konfiguracija stupila na snagu i keširanje Envoy-a se ažuriralo. Pre nego što nastavite, malo se igrajte sa aplikacijom da generišete saobraćaj (njegovo prisustvo je neophodno za jasnoću u narednim koracima — nap. prev.). Kiali: nadgledanje Da biste ušli u administratorski interfejs Kiali, izvršite sledeću komandu: $ 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/, ulogujte se kao admin/admin. Ovde ćete pronaći mnogo korisnih mogućnosti, kao što su provere konfiguracije komponenti Istio, vizualizacija servisa na osnovu informacija prikupljenih tokom presretanja mrežnih zahteva, odgovori na pitanja „Ko se kome obraća?”, „Kod koje verzije servisa dolazi do grešaka?” itd. U suštini, istražite mogućnosti Kiali pre nego što krenete dalje — ka vizualizaciji metrika sa Grafana. Grafana: vizualizacija metrika Metrike prikupljene u Istio idu u Prometheus i vizualizuju se putem Grafana. Da biste ušli u administratorski interfejs Grafana, izvršite donju komandu, 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 meni Home gore levo i odaberite Istio Service Dashboard u gornjem levom uglu, započnite sa servisom sa-web-app, da biste pogledali prikupljene metrike: Ovde nas čeka prazan i potpuno dosadan prikaz — uputstvo nikad ne bi odobrilo nešto takvo. Hajde da stvorimo malo opterećenje sledećom komandom: $ while true; do curl -i http://$EXTERNAL_IP/sentiment -H "Content-type: application/json" -d '{"sentence": "I love yogobella"}'; sleep .8; done Zdaj imamo veliko lepše grafikon, poleg njih pa tudi odlična orodja Prometheus za spremljanje in Grafana za vizualizacijo metrik, ki nam omogočajo, da bolje razumemo zmogljivost, zdravje, izboljšave/degradacijo delovanja storitev skozi čas. Na koncu si poglejmo sledenje zahtevam v storitvah. Jaeger: sledenje Sledenje je potrebno, ker čim več storitev imamo, tem težje je priti do vzroka napake. Poglejmo preprost primer iz spodnje slike: Tipičen primer naključnega neuspeha zahtevka Zahteva pride, pade — kako pa to? Prva storitev? Ali druga? Napake so v obeh — poglejmo dnevniške zapise vsakega. Kolikokrat ste se ujeli pri takšnem delu? Naša dela bolj spominjajo na delo detektivov programske opreme kot razvijalcev... To je široko razširjena težava v mikroservisih in se reši z distribucijskimi sistemi sledenja, pri čemer si storitve izmenjujejo edinstven glavni naslov, nato pa se te informacije preusmerijo v sistem za sledenje, kjer se povežejo s podatki zahtevka. Tukaj je ilustracija: Za identifikacijo zahtevka se uporablja TraceId V Istio uporabljamo Jaeger Tracer, ki implementira neodvisen od dobaviteljev okvir OpenTracing API. Dostop do uporabniškega vmesnika Jaeger lahko pridobite z naslednjim ukazom: $ kubectl port-forward -n istio-system $(kubectl get pod -n istio-system -l app=jaeger -o jsonpath='{.items[0].metadata.name}') 16686 Zdaj pojdite na http://localhost:16686/ in izberite storitev sa-web-app. Če storitev ni prikazana v spustnem meniju — ustvarite/simulirajte aktivnost na strani in posodobite vmesnik. Nato kliknite na gumb Find Traces, ki bo pokazal najnovejše sledi — izberite katerokoli — prikazana bo podrobna informacija o vseh sledeh: Ta sled prikazuje: Zahteva pride v istio-ingressgateway (to je prvo interakcijo z eno od storitev, in za zahtevek se generira Trace ID), nato pa prehod usmeri zahtevo v storitev sa-web-app. V storitvi sa-web-app zahtevo zajame Envoy sidecar, ustvari se 'otrok' v span (zato ga vidimo v sledeh) in se preusmeri v kontejner sa-web-app. (Span — logična jedinica rada u Jaegeru, koja ima naziv, vrijeme početka operacije i njezinu trajanje. Spanovi mogu biti ugniježđeni i poredani. Orijentirani aciklični graf od spanova čini trace. — napomena prev.) Ovdje se zahtjev obrađuje metodom sentimentAnalysis. Ovi tragovi su već generirani aplikacijom, tj. za njih su bila potrebna promjena u kodu. Od ove tačke se inicira 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 Istio, i proslijediti ih u naredne 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 dolazeće zahtjeve, stvara nove spanove u svakom sidecare i proslijeđuje ih. Međutim, bez rada s zaglavljima unutar usluga, cijeli put traganja 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 složen zadatak, međutim, za pojednostavljenje njegove implementacije već postoje brojne biblioteke — na primjer, u usluzi sa-web-app klijent RestTemplate proslijedi ova zaglavlja, ako se jednostavno dodaju biblioteke Jaeger i OpenTracing u njegove zavisnosti. Primijetite da aplikacija Sentiment Analysis demonstrira implementacije na Flask, Spring i ASP.NET Core. Sada, kada je jasno što dobivamo iz kutije (ili skoro 'iz kutije'), razmotrit ćemo pitanja fino podešene rutiranja, upravljanja mrežnim prometom, sigurnosti itd.! Op. prev.: o tome čitajte u sljedećem dijelu materijala o Istio od Rinora Malokua, čiji će prijevodi uslijediti na našem blogu u skoroj budućnosti. UPDATE (14. ožujka): Drugi dio je već objavljen. P.S. od prevajalca Preberite tudi na našem blogu: «Povratak mikroservisima uz Istio»: dio 2 (rutiranje, upravljanje prometom), dio 3 (autentikacija i autorizacija); «Conduit — lagani service mesh za Kubernetes»; «Što je service mesh i zašto mi je potreban [za oblačnu aplikaciju s mikroservisima]?»; «Ilustrirani vodič za konstrukciju mreže u Kubernetesu. Dijelovi 1 i 2»; «Kako se ovaj sidecar kontejner našao ovdje [u Kubernetesu]?». Izvor: habr.com route: - destination: host: sa-frontend # 2 port: number: 80
Važne točke:

Ta VirtualService se nanaša na zahteve, ki prihajajo preko http-gateway;
V cilj opredeljuje se servis, na koji se šalju zahtevi.

Napomena: Konfiguracija iznad se čuva u datoteci sa-virtualservice-external.yaml, koji također sadrži postavke za rutiranje u SA-WebApp i SA-Feedback, ali su ovdje skraćene u članku radi sažetosti.

Uporabite VirtualService z klicem:

Napomena: Ko uporabljamo vire Istio, Kubernetes API strežnik ustvari dogodek, ki ga prejme Istio Control Plane, in šele nato se nova konfiguracija uporabi za proxy strežnike Envoy vsakega pod-a. In Ingress Gateway se predstavi kot še en Envoy, konfiguriran v Control Plane. Vse to izgleda tako na diagramu:

Konfiguracija Istio-IngressGateway za rutiranje zahteva

Aplikacija Sentiment Analysis je dostupna na http://{EXTERNAL-IP}/. Ne brinite ako dobijete status Not Found: ponekad je potrebno malo više vremena da bi konfiguracija stupila na snagu i keširanje Envoy-a se ažuriralo.

Pre nego što nastavite, malo se igrajte sa aplikacijom da generišete saobraćaj (njegovo prisustvo je neophodno za jasnoću u narednim koracima — nap. prev.).

Kiali: nadgledanje

Da biste ušli u administratorski interfejs Kiali, izvršite sledeću komandu:

… i otvorite http://localhost:20001/, ulogujte se kao admin/admin. Ovde ćete pronaći mnogo korisnih mogućnosti, kao što su provere konfiguracije komponenti Istio, vizualizacija servisa na osnovu informacija prikupljenih tokom presretanja mrežnih zahteva, odgovori na pitanja „Ko se kome obraća?”, „Kod koje verzije servisa dolazi do grešaka?” itd. U suštini, istražite mogućnosti Kiali pre nego što krenete dalje — ka vizualizaciji metrika sa Grafana.

Grafana: vizualizacija metrika

Metrike prikupljene u Istio idu u Prometheus i vizualizuju se putem Grafana. Da biste ušli u administratorski interfejs Grafana, izvršite donju komandu, a zatim otvorite http://localhost:3000/:

Kliknite na meni Home gore levo i odaberite Istio Service Dashboard u gornjem levom uglu, započnite sa servisom sa-web-app, da biste pogledali prikupljene metrike:

Ovde nas čeka prazan i potpuno dosadan prikaz — uputstvo nikad ne bi odobrilo nešto takvo. Hajde da stvorimo malo opterećenje sledećom komandom:

Zdaj imamo veliko lepše grafikon, poleg njih pa tudi odlična orodja Prometheus za spremljanje in Grafana za vizualizacijo metrik, ki nam omogočajo, da bolje razumemo zmogljivost, zdravje, izboljšave/degradacijo delovanja storitev skozi čas.

Na koncu si poglejmo sledenje zahtevam v storitvah.

Jaeger: sledenje

Sledenje je potrebno, ker čim več storitev imamo, tem težje je priti do vzroka napake. Poglejmo preprost primer iz spodnje slike:

Tipičen primer naključnega neuspeha zahtevka

Zahteva pride, pade — kako pa to? Prva storitev? Ali druga? Napake so v obeh — poglejmo dnevniške zapise vsakega. Kolikokrat ste se ujeli pri takšnem delu? Naša dela bolj spominjajo na delo detektivov programske opreme kot razvijalcev...

To je široko razširjena težava v mikroservisih in se reši z distribucijskimi sistemi sledenja, pri čemer si storitve izmenjujejo edinstven glavni naslov, nato pa se te informacije preusmerijo v sistem za sledenje, kjer se povežejo s podatki zahtevka. Tukaj je ilustracija:

Za identifikacijo zahtevka se uporablja TraceId

V Istio uporabljamo Jaeger Tracer, ki implementira neodvisen od dobaviteljev okvir OpenTracing API. Dostop do uporabniškega vmesnika Jaeger lahko pridobite z naslednjim ukazom:

Zdaj pojdite na http://localhost:16686/ in izberite storitev sa-web-app. Če storitev ni prikazana v spustnem meniju — ustvarite/simulirajte aktivnost na strani in posodobite vmesnik. Nato kliknite na gumb Find Traces, ki bo pokazal najnovejše sledi — izberite katerokoli — prikazana bo podrobna informacija o vseh sledeh:

Ta sled prikazuje:

Zahteva pride v istio-ingressgateway (to je prvo interakcijo z eno od storitev, in za zahtevek se generira Trace ID), nato pa prehod usmeri zahtevo v storitev sa-web-app.
V storitvi sa-web-app zahteva se ujame z Envoy sidecarjem, ustvari se 'otrok' v span-u (zato ga vidimo v sledenju) in se preusmeri v vsebnik sa-web-app. (Span — logična enota dela v Jaegerju, ki ima ime, čas začetka operacije in njeno trajanje. Spani so lahko gnezdeni in urejeni. Usmerjen aciklični graf iz spanov tvori trace. — op. prev.)
Ovdje se zahtjev obrađuje metodom sentimentAnalysis. Ovi tragovi su već generirani aplikacijom, tj. za njih su bila potrebna promjena u kodu.
Od ove tačke se inicira 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 Istio, i proslijediti ih u naredne zahtjeve, kao što je prikazano na slici ispod:

(A) Za prosljeđivanje zaglavlja odgovara Istio; (B) Za zaglavlja odgovaraju usluge

Istio opravlja glavno delo, saj generira glave za prihajajoče zahteve, ustvarja nove spane v vsakem sidecarju in jih posreduje. Vendar pa brez dela z glavami znotraj storitev celotna pot sledenja zahteve ne bo izvržena.

Potrebno je uzeti u obzir (proslijediti) sljedeća zaglavlja:

Ovo nije složen zadatak, međutim, za pojednostavljenje njegove implementacije već postoje brojne biblioteke — na primjer, u usluzi sa-web-app klijent RestTemplate proslijedi ova zaglavlja, ako se jednostavno dodaju biblioteke Jaeger i OpenTracing u njegove zavisnosti.

Primijetite da aplikacija Sentiment Analysis demonstrira implementacije na Flask, Spring i ASP.NET Core.

Sada, kada je jasno što dobivamo iz kutije (ili skoro 'iz kutije'), razmotrit ćemo pitanja fino podešene rutiranja, upravljanja mrežnim prometom, sigurnosti itd.!

Op. prev.: o tome čitajte u sljedećem dijelu materijala o Istio od Rinora Malokua, čiji će prijevodi uslijediti na našem blogu u skoroj budućnosti. UPDATE (14. ožujka): Drugi dio je već objavljen.