🥇Kthehu te mikroshërbimet me Istio. Pjesa 1

Shën. përkth.: Shërbimet mesh kanë filluar të jenë një zgjidhje e njohur në infrastrukturën moderne për aplikacione që ndjekin arkitekturën mikroshërbimore. Ndërsa Istio mund të jetë në mendjen e shumë inxhinierëve DevOps, është një produkt mjaft i ri, i cili, duke qenë kompleks sa i përket mundësive që ofron, mund të kërkojë një kohë të konsiderueshme për t'u njohur. Inxhinieri gjerman Rinor Maloku, i cili është përgjegjës për llogaritjet në re për klientët e mëdhenj në kompaninë e telekomunikacionit Orange Networks, ka shkruar një cikël të shkëlqyer materialesh që lejojnë një zhytje të shpejtë dhe të thellë në Istio. Ai fillon tregimin e tij me atë se çfarë mund të bëjë Istio dhe si mund ta shohim atë shpejt me sy.

Istio — Një projekt Open Source, i zhvilluar në bashkëpunim me ekipet nga Google, IBM dhe Lyft. Ai zgjidh komplikacionet që paraqiten në aplikacionet e bazuara në mikroshërbime, të tilla si:

Menaxhimi i trafikut: skadencat, përpjekjet e përsëritura, balancimi i ngarkesës;
Siguria: autentikimi dhe autorizimi i përdoruesit fundor;
Vëzhgueshmëria: gjurmimi, monitorimi, regjistrimi.

Të gjitha ato mund të zgjidhen në nivelin e aplikacionit, megjithatë pas kësaj shërbimet tuaja do të ndalojnë së qenuri "mikro". Të gjitha përpjekjet shtesë për të zgjidhur këto probleme paraqesin një kosto të tepërt për burimet e kompanisë, të cilat mund të përdoren drejtpërdrejt për vlerat e biznesit. Le të marrim një shembull:

Menaxheri i projekteve: Sa kohë duhet për të shtuar mundësinë e reagimit?
Programuesi: Dy sprintet.
MP: Çfarë?.. Kjo është vetëm CRUD!
P: Të bësh CRUD është pjesa e thjeshtë e detyrës, por na nevojitet gjithashtu të autentikojmë dhe autorizojmë përdoruesit dhe shërbimet. Duke qenë se rrjeta është jo e besueshme, do të na duhet të zbatojmë kërkesa të përsëritura, si dhe shkallë të circuit breaker në klientët. Gjithashtu, për të siguruar që sistemi të mos bjerë, do të na nevojiten skadencat dhe bulkheads (më shumë rreth të dy shkallëve të përmendura do të gjeni më vonë në artikull – shënim i përkthyesit), dhe për të zbuluar probleme, do të nevojitet monitorimi, gjurmimi, […]
MP: Oh, atëherë le ta vendosim këtë funksionalitet thjesht në shërbimin Product.

Mendoj se ideja është e qartë: volumi i hapave dhe përpjekjeve që kërkohet për të shtuar një shërbim është i madh. Në këtë artikel do të shqyrtojmë se si Istio i heq të gjitha këto komplekse (që nuk janë të destinuara për logjikën e biznesit) nga shërbimet.

Shënim: Artikulli supozon se keni njohuri praktike mbi Kubernetes. Në të kundërt, rekomandoj të lexoni introduktimin tim në Kubernetes dhe vetëm pas kësaj të vazhdoni me leximin e këtij materiali.

Ideja e Istio

Në një botë pa Istio, një shërbim bën kërkesa direkte te shërbimi tjetër dhe në rast dështimi, shërbimi duhet të trajtojë vetë këtë: të përpiqet përsëri, të parashikojë një skadim, të hapë një circuit breaker etj.

Trafiku rrjetor në Kubernetes

Istio ofron një zgjidhje të specializuar, plotësisht të ndarë nga shërbimet dhe funksionon duke ndërhyrë në ndërveprimin rrjetor. Kështu, implementon:

Qëndrueshmëri: duke u mbështetur në kodin e statusit në përgjigje, ai kupton nëse ndodhi një dështim në kërkesë dhe e përsërit atë.
Zbatimi kanarin: drejton një përqindje të caktuar të kërkesave në versionin e ri të shërbimit.
Monitorimi dhe metrikat: sa kohë mori shërbimi për të përgjigjur?
Trazimi dhe vëzhgueshmëria: shton tituj të veçantë në çdo kërkesë dhe i ndjek ato në klaster.
Siguria: nxjerr tokenin JWT, autentifikon dhe autorizon përdoruesit.

Këto janë vetëm disa nga mundësitë (në të vërtetë, vetëm disa!), për t'ju intriguar. Tani le të thellohemi në detajet teknike!

Arkitektura e Istio

Istio kap të gjithë trafikun rrjetor dhe i aplicon një grup rregullash, duke futur në çdo pod një proksi inteligjent në formën e një kontejneri sidecar. Proksitë, të cilat aktivizojnë të gjitha mundësitë, formojnë Data Plane, dhe ato mund të konfigurohen dinamikisht me anë të Control Plane.

Data Plane

Proksitë e futur në podë e lejojnë Istio të përputhet lehtësisht me kërkesat tona. Për shembull, le të kontrollojmë funksionet e përpjekjeve të përsëritura dhe të circuit breaker.

Si implementohen retries dhe circuit breaking në Envoy

Për të përmbledhur:

Envoy (po flasim për proksin që ndodhet në kontejnerin sidecar, i cili shpërndahet gjithashtu si një produkt të veçantë — shën. përkth.) dërgon kërkesën në instancën e parë të shërbimit B dhe ndodh një dështim.
Envoy Sidecar bën një përpjekje të përsëritur (retry). (1)
Kërkesa me dështim kthehet në proksin që e ka kërkuar.
Kjo është mënyra si hapet Circuit Breaker dhe ndodh thirrja e shërbimit tjetër për kërkesat në vazhdim. (2)

Kjo do të thotë se nuk do t'ju duhet të përdorni një bibliotekë tjetër Retry, nuk do t'ju duhet të bëni implementimin tuaj të Circuit Breaking dhe Service Discovery në gjuhën e programimit X, Y ose Z. Të gjitha këto dhe shumë të tjera janë në dispozicion nga kutia në Istio dhe nuk kërkojnë asnjë ndryshim në kod.

Shkëlqyer! Tani mund të dëshironi të shkoni në një aventurë me Istio, por ende ka disa dyshime, pyetje të hapura. Nëse kjo është një zgjidhje universale për çdo rast, atëherë lind një dyshim i arsyeshëm: A janë të tilla zgjidhje në të vërtetë të përshtatshme për ndonjë rast të caktuar?

Dhe tani, më në fund do të pyesni: «A është e konfigurueshme?»

Tani jeni gati për një udhëtim detar — dhe le të njohim Control Plane.

Control Plane

Ai përbëhet nga tre komponentë: Pilot, Mixer и Citadel, — të cilat së bashku konfigurojnë Envoy't për rregullimin e trafikut, aplikojnë politikat dhe mbledhin të dhënat telemetrike. Në mënyrë schematike, e gjithë kjo duket kështu:

Ndërveprimi i Control Plane me Data Plane

Envoy't (dmth. data plane) janë konfiguruar me help of Kubernetes CRD (Definicione të Burimit të Personalizuar), të përcaktuara nga Istio dhe të dizajnuara posaçërisht për këtë qëllim. Për ju, kjo do të thotë se ato paraqiten si një burim tjetër në Kubernetes me sintaksë të njohur. Pas krijimit, ky burim do të merret nga control plane dhe do të aplikohet në Envoy't.

Marrëdhënia e shërbimeve me Istio

Kemi përshkruar marrëdhënien e Istio me shërbimet, por jo anën tjetër: si i shohin shërbimet Istio-n?

Sinqerisht, shërbimet e dinë për ekzistencën e Istio-s ashtu si peshqit e dinë për ujin, kur pyesin veten: «Çfarë është në të vërtetë uji?».

Ilustrimi Victoria Dimitrakopoulos: — Si të duket uji? — Çfarë është në të vërtetë uji?

Kështu që, mund të merrni një klasër funksional dhe pas vendosjes së komponentëve të Istio, shërbimet që ndodhen në të do të vazhdojnë të punojnë, dhe pasi të hiqen këto komponentë, gjithçka do të jetë përsëri në rregull. E kuptueshme, në këtë rast do të humbni mundësitë që ofron Istio.

Mjaft me teorinë — le ta çojmë këtë dituri në praktikë!

Istio në praktikë

Istio kërkon një klasër Kubernetes, në të cilin si minimale duhet të jenë të disponueshme 4 vCPU dhe 8 GB RAM. Për të ngritur shpejt një klasër dhe për të ndjekur udhëzimet nga artikulli, rekomandoj të përdorni Google Cloud Platform, e cila ofron përdoruesve të rinj 600 $.

Pas krijimit të klasterit dhe konfigurimit të qasjes në Kubernetes përmes utilitarit të konsolës, mund të instaloni Istio përmes menaxherit të paketave Helm.

Instalimi i Helm

Instaloni klientin Helm në kompjuterin tuaj, siç e përshkruajnë në dokumentacionin zyrtar. Ne do ta përdorim për të gjeneruar template për instalimin e Istio në seksionin e ardhshëm.

Instalimi i Istio

Shkarkoni burimet e Istio nga versioni më i fundit (linku origjinal i autorit për versionin 1.0.5 është ndryshuar për në versionin aktual, dmth 1.0.6 — shën. përk.)., nxirrni përmbajtjen në një direktor të vetëm, të cilin do ta quaj [istio-resources].

Për të identifikuar lehtësisht burimet e Istio, krijoni një hapësirë emri në klasterin K8s istio-system:

$ kubectl create namespace istio-system

Përfundoni instalimin duke shkuar në katalogun [istio-resources] dhe duke ekzekutuar komandën:

$ 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

Kjo komandë do të prodhojë komponentët kyç të Istio në skedarin istio.yaml. Ne e kemi modifikuar template-n standard sipas nevojave tona, duke caktuar parametrat si më poshtë:

global.mtls.enabled caktuar në false (dmth, autentikimi mTLS është çaktivizuar — shën. përk.), për të thjeshtuar procesin tonë të njohjes;
tracing.enabled aktivizon gjurmimin e kërkesave përmes Jaeger;
kiali.enabled instalon Kiali në klaster për vizualizimin e shërbimeve dhe trafikëve;
grafana.enabled instalon Grafana për vizualizimin e metrikave të mbledhura.

Do ta aplikojmë burimin e gjeneruar me komandën:

$ kubectl apply -f istio.yaml

Instalimi i Istio në klaster ka përfunduar! Prisni derisa të gjitha pod-et në hapësirën e emrit istio-system të jenë në gjendje Running или Përfunduar, duke ekzekutuar komandën më poshtë:

$ kubectl get pods -n istio-system

Tani jemi të gatshëm të vazhdojmë në seksionin e ardhshëm, ku do të ngremë dhe ekzekutojmë aplikacionin.

Arkitektura e Aplikacionit të Analizës së Sentimentit

Do të përdorim shembullin e aplikacionit mikro-shërbimeve të Analizës së Sentimentit, që është përdorur në artikullin e përmendur më parë në hyrjen në Kubernetes. Është mjaft komplekse për të demonstruar mundësitë e Istio në praktikë.

Aplikacioni përbëhet nga katër mikro-shërbime:

Shërbimi SA-Frontend, i cili shërben frontend-in e aplikacionit në Reactjs;
Shërbimi SA-WebApp, i cili trajton kërkesat për Analizën e Sentimentit;
Shërbimi SA-Logic, i cili ekzekuton vetë analizën e sentimentit;
Shërbimi SA-Feedback, i cili merr reagime nga përdoruesit mbi saktësinë e analizës së kryer.

Në këtë diagramë, përveç shërbimeve, ne gjithashtu shohim Ingress Controller, i cili në Kubernetes rregullon kërkesat e ardhshme në shërbimet përkatëse. Në Istio përdoret një koncept i ngjashëm në kuadër të Ingress Gateway, detajet e të cilit do të vijojnë.

Nisja e aplikacionit me proxy nga Istio

Për operacionet e mëtejshme të përmendura në artikull, klononi depozitat e duhura për vete istio-mastery. Në të gjenden aplikacioni dhe manifestet për Kubernetes dhe Istio.

Vendosja e sidecar’ëve

Vendosja mund të bëhet automatikisht или duke e bërë këtë manualisht. Për vendosjen automatike të kontejnerëve sidecar, do të nevojitet të caktoni një etiketë në hapësirën e emrave istio-injection=enabled, e cila bëhet me komandën e mëposhtme:

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

Tani çdo pod që do të zhvillohet në hapësirën e emrave për default (default) do të marrë kontejnerin e tij sidecar. Për t'u siguruar për këtë, le të vendosim një aplikacion testues duke kaluar në katalogun rrënjor të depozitës [istio-mastery] dhe duke ekzekutuar komandën e mëposhtme:

$ 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

Pasi zhvillohen shërbimet, le të kontrollojmë që pod’ët të kenë dy kontejnerë (me shërbimin vetë dhe sidecar’in e tij), duke ekzekutuar komandën kubectl get pods dhe duke u siguruar që në kolonën READY është e shënuar vlera 2/2, simbolizojnë që të dy kontejnerët janë të ngarkuar:

$ 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

Vizualisht, kjo paraqitet kështu:

Proxy Envoy në një nga pod’ët

Tani, kur aplikacioni është ngritur dhe funksionon, ne do të duhet të lejojmë që trafik i ardhshëm të vijë në aplikacion.

Ingress Gateway

Praktika më e mirë për të arritur këtë (të lejojmë trafik në klaster) është përmes Ingress Gateway në Istio, i cili ndodhet në "kufirin" e klasterit dhe lejon që të aktivizohen për trafikun e ardhshëm funksionalitete të tilla të Istio si rregullimi, balancimi i ngarkesës, siguria dhe mbikëqyrja.

Komponenti Ingress Gateway dhe shërbimi që e kalon atë jashtë janë instaluar në klaster gjatë instalimit të Istio. Për të mësuar adresën IP të jashtme të shërbimit, ekzekutoni:

$ 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

Ne do të vazhdojmë të aksesojmë aplikacionin përmes këtij IP dhe më pas (do ta quaj atë si EXTERNAL-IP), kështu që për lehtësi, do ta regjistrojmë vlerën në një variabël:

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

Nëse provoni tani të hyni në këtë IP përmes shfletuesit, do të merrni një gabim të Shërbimit të Pashfrytëzuar, sepse nga default, Istio bllokon të gjithë trafikun e hyrjes, derisa të definohet Gateway.

Burimi Gateway

Gateway është një CRD (Përcaktimi i Burimeve të Personalizuara) në Kubernetes, i caktuar pas instalimit të Istio në klustër dhe aktivizon mundësinë për të specifikuar portet, protokollin dhe hostet për të cilat dëshirojmë të lejojmë trafikun e hyrjes.

Në rastin tonë, dëshirojmë të lejojmë trafikun HTTP në portin 80 për të gjitha hostet. Detyra realizohet me këtë definicion (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:
- "*"

Kjo konfigurim nuk ka nevojë për shpjegim përveç selektorit istio: ingressgateway. Me këtë selektor ne mund të tregojmë se në cilin Ingress Gateway të aplikojmë konfigurimin. Në rastin tonë, ai është kontrolluesi i Ingress Gateway që është instaluar si default në Istio.

Konfigurimi aplikohet duke thirrur komandën në vijim:

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

Tani gateway lejon akses në portin 80, por nuk ka njohuri se ku të rregullojë kërkesat. Për këtë do të nevojiten Shërbime Virtuale.

Burimi VirtualService

VirtualService i tregon Ingress Gateway se si të rregullojë kërkesat që janë të lejuara brenda klustrit.

Kërkesat për aplikacionin tonë, që vijnë përmes http-gateway, duhet të dërgohen në shërbimet sa-frontend, sa-web-app dhe sa-feedback:

Rrugët që duhet të konfigurohen me VirtualServices

Le të shqyrtojmë kërkesat që duhet të dërgohen në SA-Frontend:

Përputhje e saktë në rrugë / duhet të dërgohet në SA-Frontend për të marrë index.html;
Rrugët me prefiks /static/* duhet të dërgohen në SA-Frontend për të marrë skedarët statikë që përdoren në front-end, si CSS dhe JavaScript;
Rrugët që bien nën shprehjen e rregullt '^.*.(ico|png|jpg)$', duhet të dërgohen në SA-Frontend, sepse këto janë imazhe që shfaqen në faqe.

Implementimi arrihet me këtë konfigurim (sa-virtualservice-external.yaml):

lloji: VirtualService metadata: emri: sa-external-services spec: pritës: - "*" porta: - http-gateway # 1 http: - ndeshje: - uri: saktë: \/ - uri: saktë: \/callback - uri: prefiks: \/static - uri: regex: '^.*.(ico|png|jpg) Pikat e rëndësishme: Ky VirtualService i referohet kërkesave që arrijnë përmes http-gateway; Në destination definohet shërbimi ku dërgohen kërkesat. Shënim: Konfigurimi më sipër ruhet në skedarin sa-virtualservice-external.yaml, i cili gjithashtu përmban cilësime për rrugëzimin në SA-WebApp dhe SA-Feedback, por është shkurtuar këtu në artikull për shkak të shkurtësisë. Aplikohet VirtualService me thirrjen: $ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml virtualservice.networking.istio.io/sa-external-services u krijua Shënim: Kur aplikojmë burimet Istio, Kubernetes API Server krijon një ngjarje, e cila merret nga Istio Control Plane, dhe vetëm pas kësaj konfigurimi i ri aplikohet në serverët proxy Envoy të çdo pod'i. Dhe kontrolluesi i Ingress Gateway paraqitet si një Envoy tjetër, i konfiguruar në Control Plane. Të gjitha këto duken kështu në diagram: Konfigurimi i Istio-IngressGateway për rrugëzimin e kërkesave Aplikacioni Analiza e Sentimentit është bërë i disponueshëm në http://{EXTERNAL-IP}/. Mos u shqetësoni nëse merrni statusin Not Found: ndonjëherë ka nevojë për pak më shumë kohë që konfigurimi të hyjë në fuqi dhe cache-t e Envoy të përditësohen. Para se të vazhdoni, punoni pak me aplikacionin për të gjeneruar trafik (prania e tij është e nevojshme për ilustrimin në veprimet e ardhshme — shën. përk.). Kiali: vërejtshmëria Për të hyrë në ndërfaqen administrative të Kiali, ekzekutoni komandën e mëposhtme: $ kubectl port-forward $(kubectl get pod -n istio-system -l app=kiali -o jsonpath='{.items[0].metadata.name}') -n istio-system 20001 … dhe hapni http://localhost:20001/, duke u identifikuar si admin/admin. Këtu do të gjeni shumë mundësi të dobishme, për shembull, për të verifikuar konfigurimin e komponentëve të Istio, për të vizualizuar shërbimet sipas informacionit të mbledhur gjatë kapjes së kërkesave rrjetët, për të marrë përgjigje në pyetje si “Kush i qaset kujt?”, “Në cilën version të shërbimit ndodhin dështime?” etj. Në përgjithësi, shqyrtoni mundësitë e Kiali para se të kaloni përpara — në vizualizimin e metrikave me Grafana. Grafana: vizualizimi i metrikave Metrikat e mbledhura në Istio hyjnë në Prometheus dhe vizualizohen me Grafana. Për të hyrë në ndërfaqen administrative të Grafana, ekzekutoni komandën më poshtë, pastaj hapni 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 Duke klikuar në menunë Home në majtas lartë dhe duke zgjedhur Istio Service Dashboard në këndin e majtë të sipërm, filloni me shërbimin sa-web-app, për të parë metrikat e mbledhura: Këtu na pret një paraqitje e zbrazët dhe krejt e mërzitshme — udhëzimi kurrë nuk do ta miratonte këtë. Le të krijojmë një ngarkesë të vogël me komandën e mëposhtme: $ while true; do curl -i http://$EXTERNAL_IP/sentiment -H "Content-type: application/json" -d '{"sentence": "I love yogobella"}'; sleep .8; done Tani tani tani tani tani tani tani tani tani kahout të bukur, dhe mbi to – mjete të shkëlqyera të Prometheus për monitorimin dhe Grafana për vizualizimin e metrikave, që do të na lejojnë të dimë për performancën, shëndetin, përmirësimet/degradimin në punën e shërbimeve me kalimin e kohës. Së fundmi, le të shohim gjurmimin e kërkesave në shërbime. Jaeger: gjurmimi Gjurma na nevojitet, sepse sa më shumë shërbime të kemi, aq më e vështirë bëhet të kuptojmë shkakun e dështimit. Të shohim një rast të thjeshtë nga figura më poshtë: Një shembull tipik i një kërkese të dështuar rastësisht Kërkesa vjen, dështon — çfarë është shkaku? Shërbimi i parë? Apo i dyti? Ka përjashtime në të dy - le të shohim logjet e çdo njërit. Sa shpesh keni kapur veten me një veprim të tillë? Puna jonë është më shumë si ajo e detektivëve të softuerit, sesa ajo e zhvilluesve... Këto janë probleme tepër të zakonshme në mikrosherbime dhe zgjidhen me sistemet e gjurmimit të shpërndara, ku shërbimet kalojnë një titull unik midis njëra-tjetrës, pas së cilës kjo informacion drejtohet në sistemin e gjurmimit, ku ato lidhen me të dhënat e kërkesës. Ja një ilustrim: Për identifikimin e kërkesës përdoret TraceId Në Istio përdoret Jaeger Tracer, i cili realizon një kornizë të pavarur nga prodhuesi OpenTracing API. Qasja në ndërfaqen e përdoruesit të Jaeger mund të bëhet me komandën e mëposhtme: $ kubectl port-forward -n istio-system $(kubectl get pod -n istio-system -l app=jaeger -o jsonpath='{.items[0].metadata.name}') 16686 Tani shkoni në http://localhost:16686/ dhe zgjidhni shërbimin sa-web-app. Nëse shërbimi nuk shfaqet në menu-në e rënë — tregoni/gjeneroni aktivitet në faqe dhe rifreskoni ndërfaqen. Pas kësaj klikoni në butonin Find Traces, i cili do të tregojë gjurmët më të fundit — zgjidhni cilëndo — do të shfaqet informacioni i detajuar për të gjitha gjurmët: Kjo gjurmë tregon: Kërkesa vjen në istio-ingressgateway (ky është ndërveprimi i parë me një nga shërbimet, dhe për kërkesën gjenerohet ID i Gjurmës), pas së cilës gateway-d drejton kërkesën në shërbimin sa-web-app. Në shërbim sa-web-app kërkesa kapet nga Envoy sidecar, krijohet një 'fëmijë' në span (prandaj e shohim atë në gjurmë) dhe drejtohet në kontejner sa-web-app. (Span — një njësisë logjike e punës në Jaeger, e cila ka emrin, kohën e fillimit të operacionit dhe zgjatjen e tij. Span'ët mund të jenë të ngjitur dhe të renditur. Një graf i orientuar aciklik nga span'ët krijon trace. — shën. përk.) Këtu, kërkesa përpunohen me metodën sentimentAnalysis. Këto trace janë tashmë të gjeneruara nga aplikacioni, pra, për to ishin të nevojshme ndryshime në kod. Në këtë moment, aktivizohet një kërkesë POST në sa-logic. ID e Trace duhet të kalojë nga sa-web-app. … Shënim: Në hapin 4, aplikacioni duhet të shohë titujt e gjeneruar nga Istio dhe t'i kalojë ata në kërkesat e mëpasshme, siç është treguar në imazhin më poshtë: (A) Kalimi i titujve përgjigjet Istio; (B) Për titujt përgjigjen shërbimet Istio bën punën kryesore, pasi gjeneron tituj për kërkesat hyrëse, krijon span'e të reja në çdo sidecar dhe i kalon ato. Megjithatë, pa punuar me titujt brenda shërbimeve, rruga e plotë e gjurmimit të kërkesës do të humbasë. Duhet të merren parasysh (kaluar) titujt e mëposhtëm: x-request-id x-b3-traceid x-b3-spanid x-b3-parentspanid x-b3-sampled x-b3-flags x-ot-span-context Kjo është një detyrë e thjeshtë, megjithatë për të thjeshtuar realizimin e saj tashmë ekzistojnë mjaft biblioteka — për shembull, në shërbimin sa-web-app, klienti RestTemplate kalon këta tituj, nëse thjesht shton bibliotekat Jaeger dhe OpenTracing në varësitë e tij. Vini re se aplikacioni Sentiment Analysis tregon implementime në Flask, Spring dhe ASP.NET Core. Tani, kur është bërë e qartë se çfarë marim nga kutia (ose pothuajse "nga kutia"), le të shqyrtojmë çështjet e routing të hollësishëm, menaxhimin e trafikut të rrjetit, sigurinë etj.! Shën. përkth.: për këtë lexoni në pjesën tjetër të materialeve mbi Istio nga Rinor Maloku, përkthimet e të cilave do të pasojnë në blogun tonë së shpejti. UPDATE (14 mars): Pjesa e dytë tashmë është publikuar. P.S. nga përkthyesi Lexoni gjithashtu në blogun tonë: "Kthehu në mikroshërbime me Istio": pjesa 2 (rukëtim, menaxhimi i trafikut), pjesa 3 (autentifikimi dhe autorizimi); «Conduit — një shërbim i lehtë rrjeti për Kubernetes.»; «Çfarë është mesh-i shërbimeve dhe pse më nevojitet [për aplikacione cloud me mikroshërbime]?»; «Udhëzues i ilustruar për ndërtimin e rrjetit në Kubernetes. Pjesët 1 dhe 2»; «Si përfundoi ky sidecar-container këtu [në Kubernetes]?». Burimi: habr.com rruga: - destinacioni: host: sa-frontend # 2 porti: numri: 80
Çështjet kryesore:

Ky VirtualService i referohet kërkesave që arrijnë përmes http-gateway;
Në destination definohet shërbimi ku dërgohen kërkesat.

Shënim: Konfigurimi më sipër ruhet në skedarin sa-virtualservice-external.yaml, i cili gjithashtu përmban konfigurime për routing në SA-WebApp dhe SA-Feedback, por është shkurtuar këtu në artikel për shkak të koncizitetit.

Aplikojmë VirtualService me thirrjen:

Shënim: Kur ne përdorim burimet e Istio, Serveri API i Kubernetes krijon një ngjarje, e cila merret nga Istio Control Plane, dhe pas kësaj, konfigurimi i ri aplikohet në proxy-serverët Envoy të çdo pod-i. Dhe kontrolluesi Ingress Gateway paraqitet si një Envoy tjetër, i konfiguruar në Control Plane. E gjithë kjo duket ashtu në diagram:

Konfigurimi i Istio-IngressGateway për rrugëzimin e kërkesave

Aplikacioni Analiza e Sentimentit është bërë i disponueshëm në http://{EXTERNAL-IP}/. Mos u shqetësoni nëse merrni statusin Not Found: ndonjëherë ka nevojë për pak më shumë kohë që konfigurimi të hyjë në fuqi dhe cache-t e Envoy të përditësohen.

Para se të vazhdoni, punoni pak me aplikacionin për të gjeneruar trafik (prania e tij është e nevojshme për ilustrimin në veprimet e ardhshme — shën. përk.).

Kiali: vërejtshmëria

Për të hyrë në ndërfaqen administrative të Kiali, ekzekutoni komandën e mëposhtme:

… dhe hapni http://localhost:20001/, duke u identifikuar si admin/admin. Këtu do të gjeni shumë mundësi të dobishme, për shembull, për të verifikuar konfigurimin e komponentëve të Istio, për të vizualizuar shërbimet sipas informacionit të mbledhur gjatë kapjes së kërkesave rrjetët, për të marrë përgjigje në pyetje si “Kush i qaset kujt?”, “Në cilën version të shërbimit ndodhin dështime?” etj. Në përgjithësi, shqyrtoni mundësitë e Kiali para se të kaloni përpara — në vizualizimin e metrikave me Grafana.

Grafana: vizualizimi i metrikave

Metrikat e mbledhura në Istio hyjnë në Prometheus dhe vizualizohen me Grafana. Për të hyrë në ndërfaqen administrative të Grafana, ekzekutoni komandën më poshtë, pastaj hapni http://localhost:3000/:

Duke klikuar në menunë Home në majtas lartë dhe duke zgjedhur Istio Service Dashboard në këndin e majtë të sipërm, filloni me shërbimin sa-web-app, për të parë metrikat e mbledhura:

Këtu na pret një paraqitje e zbrazët dhe krejt e mërzitshme — udhëzimi kurrë nuk do ta miratonte këtë. Le të krijojmë një ngarkesë të vogël me komandën e mëposhtme:

Tani tani tani tani tani tani tani tani tani kahout të bukur, dhe mbi to – mjete të shkëlqyera të Prometheus për monitorimin dhe Grafana për vizualizimin e metrikave, që do të na lejojnë të dimë për performancën, shëndetin, përmirësimet/degradimin në punën e shërbimeve me kalimin e kohës.

Së fundmi, le të shohim gjurmimin e kërkesave në shërbime.

Jaeger: gjurmimi

Gjurma na nevojitet, sepse sa më shumë shërbime të kemi, aq më e vështirë bëhet të kuptojmë shkakun e dështimit. Të shohim një rast të thjeshtë nga figura më poshtë:

Një shembull tipik i një kërkese të dështuar rastësisht

Kërkesa vjen, dështon — çfarë është shkaku? Shërbimi i parë? Apo i dyti? Ka përjashtime në të dy - le të shohim logjet e çdo njërit. Sa shpesh keni kapur veten me një veprim të tillë? Puna jonë është më shumë si ajo e detektivëve të softuerit, sesa ajo e zhvilluesve...

Këto janë probleme tepër të zakonshme në mikrosherbime dhe zgjidhen me sistemet e gjurmimit të shpërndara, ku shërbimet kalojnë një titull unik midis njëra-tjetrës, pas së cilës kjo informacion drejtohet në sistemin e gjurmimit, ku ato lidhen me të dhënat e kërkesës. Ja një ilustrim:

Për identifikimin e kërkesës përdoret TraceId

Në Istio përdoret Jaeger Tracer, i cili realizon një kornizë të pavarur nga prodhuesi OpenTracing API. Qasja në ndërfaqen e përdoruesit të Jaeger mund të bëhet me komandën e mëposhtme:

Tani shkoni në http://localhost:16686/ dhe zgjidhni shërbimin sa-web-app. Nëse shërbimi nuk shfaqet në menu-në e rënë — tregoni/gjeneroni aktivitet në faqe dhe rifreskoni ndërfaqen. Pas kësaj klikoni në butonin Find Traces, i cili do të tregojë gjurmët më të fundit — zgjidhni cilëndo — do të shfaqet informacioni i detajuar për të gjitha gjurmët:

Kjo gjurmë tregon:

Kërkesa vjen në istio-ingressgateway (ky është ndërveprimi i parë me një nga shërbimet, dhe për kërkesën gjenerohet ID i Gjurmës), pas së cilës gateway-d drejton kërkesën në shërbimin sa-web-app.
Në shërbim sa-web-app kërkesa kapet nga Envoy sidecar, krijohet një "fëmijë" në span (prandaj e shohim atë në trace) dhe ridrejtohet në kontejner sa-web-app. (Span --- njësi logjike punimi në Jaeger, e cila ka emrin, kohën e fillimit të operacionit dhe kohëzgjatjen e tij. Span të mund të jenë të ngjyrosura dhe të renditura. Një grafik i orientuar aciklik nga span formon trace. --- shën. përk.
Këtu, kërkesa përpunohen me metodën sentimentAnalysis. Këto trace janë tashmë të gjeneruara nga aplikacioni, pra, për to ishin të nevojshme ndryshime në kod.
Në këtë moment, aktivizohet një kërkesë POST në sa-logic. ID e Trace duhet të kalojë nga sa-web-app.
…

Shënim: Në hapin 4, aplikacioni duhet të shohë titujt e gjeneruar nga Istio dhe t'i kalojë ata në kërkesat e mëpasshme, siç është treguar në imazhin më poshtë:

(A) Kalimi i titujve përgjigjet Istio; (B) Për titujt përgjigjen shërbimet

Istio bën punën kryesore, pasi gjeneron tituj për kërkesat hyrëse, krijon span të reja në çdo sidecar dhe i kalon ato. Megjithatë, pa punën me titujt brenda shërbimeve, rruga e plotë e ndjekjes së kërkesës do të humbet.

Duhet të merren parasysh (kaluar) titujt e mëposhtëm:

Kjo është një detyrë e thjeshtë, megjithatë për të thjeshtuar realizimin e saj tashmë ekzistojnë mjaft biblioteka — për shembull, në shërbimin sa-web-app, klienti RestTemplate kalon këta tituj, nëse thjesht shton bibliotekat Jaeger dhe OpenTracing në varësitë e tij.

Vini re se aplikacioni Sentiment Analysis tregon implementime në Flask, Spring dhe ASP.NET Core.

Tani, kur është bërë e qartë se çfarë marim nga kutia (ose pothuajse "nga kutia"), le të shqyrtojmë çështjet e routing të hollësishëm, menaxhimin e trafikut të rrjetit, sigurinë etj.!

Shën. përkth.: për këtë lexoni në pjesën tjetër të materialeve mbi Istio nga Rinor Maloku, përkthimet e të cilave do të pasojnë në blogun tonë së shpejti. UPDATE (14 mars): Pjesa e dytë tashmë është publikuar.