🥇Kthehu te mikroshërbimet me Istio. Pjesa 1

Shën. përk.: Service mesh definitivisht ka filluar të jetë një zgjidhje e rëndësishme në infrastrukturën moderne për aplikacionet që ndjekin arkitekturën mikroservis. Megjithëse Istio mund të jetë i njohur për shumë inxhinierë DevOps, është një produkt relativisht i ri, i cili, duke qenë kompleks në kuptimin e mundësive të ofruara, 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 llogaritë në cloud për klientët e mëdhenj në kompaninë e telekomunikacioneve Orange Networks, ka shkruar një cikël të shkëlqyer materialesh që lejojnë një zhytje të shpejtë dhe të thellë në Istio. Ai e fillon rrëfimin e tij me ato që dihet se bën Istio dhe si mund ta shihni shpejt me sytë tuaj.

Istio — Projekt Open Source, i zhvilluar në bashkëpunim me skuadrat nga Google, IBM dhe Lyft. Ai zgjidh sfidat që shfaqen në aplikacionet e bazuara në mikroservisë, për shembull, si:

Menaxhimi i trafikut: mesazhe të kohës, përsëritje, balancimi i ngarkesës;
Siguria: autentifikimi dhe autorizimi i përdoruesit përfundimtar;
Vëzhgimi: gjurmimi, monitorimi, regjistrimi.

Të gjitha këto probleme mund të zgjidhen në nivelin e aplikacionit, megjithatë, pas kësaj shërbimet tuaja do të ndalojnë së qeni "mikro". Të gjitha përpjekjet e shtesë për zgjidhjen e këtyre problemeve janë një shpenzim i 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ë do të duhej për të shtuar mundësinë e feedback-ut?
Zhvilluesi: Dy sprint-e.
MP: Çfarë?.. Kjo është vetëm CRUD!
R: Të bësh CRUD është pjesa e lehtë e detyrës, por na nevojitet gjithashtu të autentifikojmë dhe autorizojmë përdoruesit dhe shërbimet. Duke qenë se rrjeti është i pasigurt, do të duhet të implementojmë ripërsëritje, si dhe modelin circuit breaker në klientët. Gjithashtu, për të siguruar që e gjithë sistemi nuk ka rënë, do të nevojiten kohëmatje dhe bulkheads (më shumë rreth të dy modeleve të përmendura më poshtë në artikull - shënim i përkthyesit), dhe për të zbuluar problemet, do të duhet monitorimi, gjurmimi, […], dhe për të zbuluar probleme, do të nevojitet monitorim, gjurmim, [...]
MP: Oh, atëherë le të vendosim thjesht këtë veçori 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ë artikull do të shqyrtojmë se si Istio eliminon të gjitha vështirësitë e përmendura më sipër (të cilat nuk janë të synuara për logjikën biznesore) nga shërbimet.

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

Ideja e Istio

Në një botë pa Istio, një shërbim bën kërkesa direkte te tjetri, dhe në rast dështimi, shërbimi duhet ta përballojë vetë: të përpiqet sërish, të planifikojë një kohë të pritjes, të hapë një circuit breaker, etj.

Traffiku rrjetor në Kubernetes

Istio ofron një zgjidhje të specializuar, krejtësisht të ndarë nga shërbimet dhe funksionon duke ndërhyrë në ndërveprimin rrjetor. Dhe kështu realizon:

Qëndrueshmëria: duke u mbështetur në kodin e statusit në përgjigje, kupton nëse ka ndodhur një dështim në kërkesë dhe e ekzekuton përsëri.
Shkëmbimet kanarinë: ridrejtimi në versionin e ri të shërbimit vetëm një përqindje fikse të kërkesave.
Monitorimi dhe metrikat: sa kohë iu duhej shërbimit për t'u përgjigjur?
Gjurmëtimi dhe vëzhgimi: shton tituj të posaçëm në çdo kërkesë dhe i gjurmëzon ato në kluster.
Siguria: nxjerr JWT-tokenin, autentifikon dhe autorizon përdoruesit.

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

Arkitektura Istio

Istio kap të gjithë trafikun rrjetor dhe i aplikon një grup rregullash, duke futur në çdo pod një proksi të mençur në formën e një kontejneri sidecar. Proksitë që aktivizojnë të gjitha funksionalitetet formojnë Data Plane, dhe ato mund të rregullohen dinamikisht përmes Control Plane.

Data Plane

Proksitë e futur në podë lejojnë Istio të arrijë lehtësisht kërkesat tona. Për shembull, le të shqyrtojmë funksionet e përpjekjeve të përsëritura dhe të thyerjes së qarkut.

Si janë realizuar përpjekjet e përsëritura dhe thyerja e qarkut në Envoy

Në përmbledhje:

Envoy (ka të bëjë me proksin që ndodhet në kontejnerin sidecar, i cili shpërndahet si një produkt të veçantë — shënim i përkthyesit.) dërgon kërkesën te instanca e parë të shërbimit B dhe ndodh një dështim.
Envoy Sidecar bën një përpjekje të dytë (përpjekje e përsëritur). (1)
Kërkesa me dështim kthehet te proksi që e thirri atë.
Kështu hapet Circuit Breaker dhe thirret shërbimi tjetër për kërkesat e mëpasshme. (2)

Kjo do të thotë që nuk do t'ju duhet të përdorni një bibliotekë të re Retry, nuk do të nevojitet të bëni një realizim të Circuit Breaking dhe Service Discovery në gjuhën e programimit X, Y ose Z. Të gjitha këto dhe shumë më tepër janë të disponueshme nga kutia në Istio dhe nuk kërkojnë asnjë ndryshim në kod.

Fantastike! Tani mund të dëshironi të niseni në një aventurë me Istio, por ende keni disa dyshime, pyetje të hapura. Nëse ky është një zgjidhje universale për të gjitha rastet, atëherë ju lind një dyshim i arsyeshëm: të gjitha zgjidhjet e tilla përgjithësisht nuk përshtaten për asnjë rast të veçantë.

Dhe tani përfundimisht do të pyesni: "A configurehet?"

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

Control Plane

Ai përbëhet nga tre komponentë: Pilot, Mixer dhe Citadel, — të cilët së bashku konfigurojnë Envoy për rrugezim të trafikut, zbatojnë politika dhe mbledhin të dhëna telemetrike. Kjo duket në mënyrë schematike si:

Ndërveprimi i Control Plane me Data Plane

Envoy (pra, data plane) janë konfiguruar me anë të Kubernetes CRD (Custom Resource Definitions), të cilat përcaktohen nga Istio dhe janë të dizajnuara veçanë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 një sintaksë të njohur. Pasi të krijohet, ky burim do të merret në dorë nga control planei dhe do të aplikohet te Envoy.

Marrëdhënia e shërbimeve me Istio

Ne e përshkruam marrëdhënien e Istio me shërbimet, por jo të kundërtën: si lidhen shërbimet me Istio?

Sinqerisht, shërbimet e dinë për praninë e Istio po aq sa peshqit e dinë për ujin, kur ata bëjnë pyetje si: «Çfarë është në të vërtetë uji?».

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

Pra, mund të merrni një kluster në punë dhe pas vendosjes së komponenteve të Istio, shërbimet në të do të vazhdojnë të punojnë, dhe pas heqjes së këtyre komponenteve — gjithçka do të jetë përsëri në rregull. Akti është se gjatë kësaj kohe do të humbni mundësitë e ofruara nga Istio.

Mjaft teori — le të kalojmë këtë njohuri në praktikë!

Istio në praktikë

Istio kërkon një klaster Kubernetes, i cili ka të paktën 4 vCPU dhe 8 GB RAM në dispozicion. Për të ngritur shpejt klasterin dhe për të ndjekur udhëzimet në artikull, rekomandoj të përdorni Google Cloud Platform, e cila ofron për përdoruesit e rinj 300 $ falas.

Pasi të keni krijuar klasterin dhe të keni konfiguruar qasjen në Kubernetes përmes utilitarit të komandës, mund të instaloni Istio përmes menaxherit të paketave Helm.

Instalimi i Helm

Instaloni klientin Helm në kompjuterin tuaj, siç përshkruhet në dokumenti zyrtar. Ne do ta përdorim këtë për të gjeneruar template për instalimin e Istio në seksionin tjetër.

Instalimi i Istio

Shkarkoni burimet e Istio nga edhe nga versioni më i fundit (linku origjinal për autorin e versionit 1.0.5 është ndryshuar në versionin aktual, dmth 1.0.6 - shënim i përkthyesit), nxirrni përmbajtjen në një direktori, të cilën do ta quajmë më pas [istio-resources].

Për thjeshtësi identifikimi i burimeve Istio, krijoni në klasterin K8s një hapësirë emri istio-system:

$ kubectl create namespace istio-system

Përfundoni instalimin duke kaluar 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ë nxjerrë komponentet kryesore të Istio në skedarin istio.yaml. Ne kemi ndryshuar shabllonin standard sipas nevojave tona, duke specifikuar parametrat e mëposhtëm:

global.mtls.enabled caktuar në false (dmth. mTLS-autentifikimi është çaktivizuar — komentimi i redaktuesit), për të thjeshtuar procesin tonë të njohjes;
tracing.enabled aktivizon gjurmimin e kërkesave me Jaeger;
kiali.enabled instalon Kiali në kluster për vizualizimin e shërbimeve dhe trafikut;
grafana.enabled instalon Grafana për vizualizimin e metrikave të mbledhura.

Do të aplikojmë burimet e gjeneruara nga ekipi:

$ kubectl apply -f istio.yaml

Instalimi i Istio në kluster ka përfunduar! Prisni derisa të gjitha pod'ët në hapësirën e emrave istio-system të jenë në gjendje Running ose Përfunduar, duke ekzekutuar komandën më poshtë:

$ kubectl get pods -n istio-system

Tani jemi të gatshëm të vazhdojmë në seksionin tjetër, ku do të ngremë dhe të startojmë aplikacionin.

Arkitektura e aplikacionit Sentiment Analysis

Do të përdorim shembullin e aplikacionit mikrosherbim Sentiment Analysis, i përdorur në artikullin e përmendur si hyrje në Kubernetes.Ai është mjaft kompleks për të treguar mundësitë e Istio në praktikë.

Aplikacioni përbëhet nga katër mikrosherbime:

Shërbimi SA-Frontend, i cili shërben si frontend i aplikacionit në Reactjs;
Shërbimi SA-WebApp, i cili shërben kërkesat për Sentiment Analysis;
Shërbimi SA-Logic, i cili kryen vetë analiza sentimentit;
Shërbimi SA-Përgjigje, e cila merr nga përdoruesit feedback për saktësinë e analizës së kryer.

Në këtë diagram përveç shërbimeve ne gjithashtu shohim Ingress Controller, i cili në Kubernetes rute të kërkesat e ardhura në shërbimet përkatëse. Në Istio përdoret një koncept i ngjashëm brenda Ingress Gateway, detajet për të cilin do të ndjekin.

Nisja e aplikacionit me proxy nga Istio

Për operacione të tjera të përmendura në artikull, kloni repositorin tuaj istio-mastery. Ai përmban aplikacionin dhe manifestet për Kubernetes dhe Istio.

Vendosja e sidecar'ave

Vendosja mund të kryhet automatikisht ose dorazi. Për instalimin automatik të konteinerëve sidecar do të nevojitet të vendosni një etiketë hapësirës së 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 si default (default) do të marrë konteinerin e tij sidecar. Për t'u siguruar për këtë, le të zhvillojmë një aplikacion testues, duke kaluar në katalogun rrënjor të repositorit [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

Pas zgjedhim shërbimet, do të verifikojmë që çdo pod ka dy konteinerë (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 eshte treguar vlera 2/2, simbolizojnë që të dy konteinerët janë aktivizuar:

$ 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 përfaqësohet kështu:

Proxii Envoy në një nga pod-et

Tani, kur aplikacioni është ngritur dhe funksionon, do të na nevojitet të lejojmë trafikun që vjen të hyjë në aplikacion.

Ingress Gateway

Praktika më e mirë për ta arritur këtë (të lejojmë trafikun në klaster) është përmes Ingress Gateway në Istio, e cila ndodhet në 'këndin' e klasterit dhe lejon të aktivizohen për trafikun e ardhshëm funksionalitete si ruterizimi, balancimi i ngarkesës, siguria dhe monitorimi.

Komponenti Ingress Gateway dhe shërbimi që e kalon atë përjashta, u instaluan në klaster gjatë instalimit të Istio. Për të marrë adresën IP të jashtme të shërbimit, kryeni:

$ 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 ta aksesojmë aplikimin përmes kësaj IP-je më tej (do ta referoj si EXTERNAL-IP), prandaj për lehtësinë, do ta ruajmë 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 gabimin Service Unavailable, sepse në mënyrë të paracaktuar Istio bllokon gjithë trafikun e hyrëshem, derisa të përcaktohet Gateway.

Burimi Gateway

Gateway është një CRD (Përcaktimi i Burimit të Personalizuar) në Kubernetes, i caktuar pas instalimit të Istio në klaster dhe aktivizon mundësinë për të përcaktuar porte, protokoll dhe hoste, për të cilat dëshirojmë të lejojmë trafikun e hyrëshem.

Në rastin tonë, ne duam të lejojmë trafikun HTTP në portin 80 për të gjitha hostet. Kjo detyrë realizohet me këtë përcaktim (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 konfiguracion nuk ka nevojë për shpjegime përveçse përse selektori istio: ingressgateway. Me këtë selektor mund të tregojmë cilit Ingress Gateway t'i aplikojmë konfigurimin. Në rastin tonë, ky është kontroluesi Ingress Gateway, i cili u instalua si parazgjedhje në Istio.

Konfigurimi aplikohet duke thirrur komandën e mëposhtme:

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

Tani gateway-i lejon qasje në portin 80, por nuk ka ide se ku të ruajë kërkesat. Për këtë nevojiten Virtual Services.

Burimi VirtualService

VirtualService i tregon Ingress Gateway-se se si të rrugëzoj kërkesat që janë të lejuara brenda klasës.

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'i dërgojmë në SA-Frontend:

Përputhja e saktë sipas rrugës / duhet të dërgohet në SA-Frontend për të marrë index.html;
Rrugët me prefiks /static/* duhen të dërgohen në SA-Frontend për të marrë skedarët statikë që përdoren në front, si CSS dhe JavaScript;
Rrugët që bien nën shprehjen e rregullt '^.*\.(ico|png|jpg)$', duhen dërguar në SA-Frontend, pasi janë imazhe që shfaqen në faqë.

Zbatimi arrihet me konfigurimin e mëposhtëm (sa-virtualservice-external.yaml):

lloji: VirtualService metadata: emri: sa-shërbimet-eksterne spec: hostet: - "*" portat: - http-gateway # 1 http: - përputh: - uri: saktë: / - uri: saktë: /callback - uri: prefiks: /static - uri: regex: '^.*.(ico|png|jpg) Pikat e rëndësishme: Ky VirtualService i përket kërkesave që vijnë përmes http-gateway; Në destinacioni definon shërbimin ku dërgohen kërkesat. Shënim: Konfigurimi i mësipërm ruhet në skedarin sa-virtualservice-external.yaml, i cili gjithashtu përmban cilësimet për ruterin në SA-WebApp dhe SA-Feedback, por është shkurtuar këtu në artikull për shkak të shkurtësisë. Aplikoni VirtualService me thirrjen: $ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml virtualservice.networking.istio.io/sa-external-services created Shënim: Kur aplikojmë burimet Istio, Kubernetes API Server krijon një ngjarje, e cila merret nga Istio Control Plane, dhe pasi kjo, konfigurimi i ri aplikohet në proxy-t e Envoy të çdo pod-i. Dhe контроллери Ingress Gateway paraqitet si një Envoy tjetër, i konfiguruar në Control Plane. E gjithë kjo duket në diagramin e tillë: Konfigurimi i Istio-IngressGateway për ruterin e kërkesave Aplikimi Sentiment Analysis është bërë i доступshëm në http://{EXTERNAL-IP}/. Mos u shqetësoni nëse merrni statusin Not Found: ndonjëherë kërkohet 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 qartësi në veprimet e mëvonshme — shënim i përkthyesit). Kiali: vëzhgim 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 regjistruar 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, vizualizimin e shërbimeve sipas informacionit të mbledhur gjatë kapjes së kërkesave rrjedhëse, për të marrë përgjigje në pyetje si "Kush të cilin po i drejtohet?", "Cila version i shërbimit ka çështje?" etj. Në përgjithësi, shqyrtoni mundësitë e Kiali para se të shkoni më tej — në vizualizimin e metrikave me Grafana. Grafana: vizualizimi i metrikave Metrikat e mbledhura në Istio shkojnë 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 Klikoni në menunë Kreu në këndin e majtë dhe zgjidhni Istio Service Dashboard në këndin e majtë të sipërm, filloni me shërbimin sa-web-app, për të parë metrikat e grumbulluara: Këtu na pret një pamje e zbrazët dhe krejt e mërzitshme — manuali kurrë nuk do ta miratojë 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 kemi grafika shumë më të këndshme, dhe përveç tyre — mjete të shkëlqyera Prometheus për monitorim dhe Grafana për vizualizimin e metrikave, që do na ndihmojnë të njohim performancën, gjendjen e shëndetit, përmirësimet/dëmtimet në punën e shërbimeve gjatë kohës. Së fundi, le të shikojmë ndjekjen e kërkesave në shërbime. Jaeger: ndjekje Ndjekja na nevojitet, sepse sa më shumë shërbime të kemi, aq më e vështirë bëhet të gjeni arsyen e dështimit. Le të shikojmë një rast të thjeshtë nga figura më poshtë: Një shembull tipik i një kërkese të rastësishme të dështuar Kërkesa vjen, dështon — çfarë është shkaku? Shërbimi i parë? Apo i dyti? Ka përjashtime në të dyja — le të shohim logjet e secilit. Sa shpesh keni kapur veten duke bërë kështu? Puna jonë është më shumë si detektivi i softuerit, sesa zhvilluesit... Kjo është një problem i zakonshëm në mikroshërbime dhe zgjidhet me sisteme të shpërndara të gjurmimit, ku shërbimet dërgojnë një titull unik njëra-tjetrës, pas së cilës kjo informacion kalon në sistemin e gjurmimit, ku përputhet me të dhënat e kërkesës. Ja një ilustarim: Për identifikimin e kërkesës përdoret TraceId Në Istio përdoret Jaeger Tracer, i cili implementon një kornizë të varur nga shitësit OpenTracing API. Mund të qaseni në ndërfaqen e përdoruesit Jaeger 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ë menunë e rënie — krijoni/gjeneroni aktivitet në faqe dhe rifreskoni ndërfaqen. Pas kësaj, klikoni në butonin Gjej Gjurmët, e cila do të tregojë gjurmët më të fundit — zgjidhni çfarëdo — do të shfaqet informacione të detajuara për të gjitha gjurmët: Kjo gjurmë tregon: Kërkesa vjen në istio-ingressgateway (kjo është ndërveprimi i parë me një nga shërbimet, dhe për kërkesën gjenerohet Trace ID), pas së cilës gateway e drejton kërkesën në shërbim 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ësi logjike e punës në Jaeger, e cila ka emër, kohën e fillimit të operacionit dhe kohëzgjatjen e tij. Span'ët mund të jenë të brendshëm dhe të renditur. Një graf i orientuar aciklik i span'ëve formon gjurmën. — shën. përk.) Këtu kërkesa përpunuar me metodën sentimentAnalysis. Këto gjurmë janë tashmë të gjeneruara nga aplikacioni, dmth. për to kërkoheshin ndryshime në kod. Nga ky moment iniciatohet një kërkesë POST në sa-logic. Trace ID 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ë në kërkesat e mëtejshme, siç tregohet në imazhin më poshtë: (A) Për kalimin e titujve përgjigjet Istio; (B) Për titujt përgjigjen shërbimet Istio kryen punën kryesore, pasi gjeneron tituj për kërkesat e ardhshme, krijon span të rinj në çdo sidecar dhe i kalon ata. Megjithatë, pa punuar me titujt brenda shërbimeve, rruga e plotë e gjurmimit të kërkesës do të humbasë. Duhet marrë parasysh (kalimi) 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 shtoni bibliotekat Jaeger dhe OpenTracing në varësitë e tij. Vini re se aplikacioni Sentiment Analysis demonstrohet në Flask, Spring dhe ASP.NET Core. Tani, kur është bërë e qartë se çfarë po marrim nga kuti (ose pothuajse ‘nga kutia’), le të shqyrtojmë çështjet e ruterimit të ndjeshëm, menaxhimit të trafikut të rrjetit, sigurisë etj.! Shën. përk.: për këtë lexoni në pjesën tjetër të materialeve për Istio nga Rinor Maloku, përkthimet e të cilave do të vijnë në blogun tonë së shpejti. UPDATE (14 mars): Pjesa e dytë është botuar tashmë. P.S. nga përkthyesi Lexoni gjithashtu në blogun tonë: «Kthehu te mikroshërbimet me Istio»: pjesa 2 (routinimi, menaxhimi i trafikut), pjesa 3 (autentifikimi dhe autorizimi); «Conduit — një service mesh i lehtë për Kubernetes»; «Çfarë është service mesh dhe pse më nevojitet [për një aplikacion në cloud me mikroshërbime]?»; «Një udhëzues i ilustruar për ndërtimin e rrjetit në Kubernetes. Pjesët 1 dhe 2»; «Si përfundoi ky kontenier sidecar këtu [në Kubernetes]?». Burimi: habr.com ruga: - destinacioni: shtëpia: sa-frontend # 2 porta: numri: 80
Pikat e rëndësishme:

Ky VirtualService i përket kërkesave që vijnë përmes http-gateway;
Në destinacioni definon shërbimin ku dërgohen kërkesat.

Shënim: Konfigurimi i mësipërm 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 u shkurtua këtu në artikull për shkak të saktësisë.

Kjo zbatohet me VirtualService:

Shënim: Kur zbatojmë burime Istio, Serveri i API-së Kubernetes krijon një ngjarje, e cila merr Plane Kontrolin Istio, dhe pas kësaj konfigurimi i ri zbatohet në serverët proxy Envoy të çdo pod-i. Kontrolluesi i Ingress Gateway paraqitet si një Envoy tjetër, i konfiguruar në Plane Kontrolin. Të gjitha këto në skemë duken kështu:

Konfigurimi i Istio-IngressGateway për ruterin e kërkesave

Aplikimi Sentiment Analysis është bërë i доступshëm në http://{EXTERNAL-IP}/. Mos u shqetësoni nëse merrni statusin Not Found: ndonjëherë kërkohet 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 qartësi në veprimet e mëvonshme — shënim i përkthyesit).

Kiali: vëzhgim

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

… dhe hapni http://localhost:20001/, duke u regjistruar 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, vizualizimin e shërbimeve sipas informacionit të mbledhur gjatë kapjes së kërkesave rrjedhëse, për të marrë përgjigje në pyetje si "Kush të cilin po i drejtohet?", "Cila version i shërbimit ka çështje?" etj. Në përgjithësi, shqyrtoni mundësitë e Kiali para se të shkoni më tej — në vizualizimin e metrikave me Grafana.

Grafana: vizualizimi i metrikave

Metrikat e mbledhura në Istio shkojnë 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/:

Klikoni në menunë Kreu në këndin e majtë dhe zgjidhni Istio Service Dashboard në këndin e majtë të sipërm, filloni me shërbimin sa-web-app, për të parë metrikat e grumbulluara:

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

Tani kemi grafika shumë më të këndshme, dhe përveç tyre — mjete të shkëlqyera Prometheus për monitorim dhe Grafana për vizualizimin e metrikave, që do na ndihmojnë të njohim performancën, gjendjen e shëndetit, përmirësimet/dëmtimet në punën e shërbimeve gjatë kohës.

Së fundi, le të shikojmë ndjekjen e kërkesave në shërbime.

Jaeger: ndjekje

Ndjekja na nevojitet, sepse sa më shumë shërbime të kemi, aq më e vështirë bëhet të gjeni arsyen e dështimit. Le të shikojmë një rast të thjeshtë nga figura më poshtë:

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

Kërkesa vjen, dështon — çfarë është shkaku? Shërbimi i parë? Apo i dyti? Ka përjashtime në të dyja — le të shohim logjet e secilit. Sa shpesh keni kapur veten duke bërë kështu? Puna jonë është më shumë si detektivi i softuerit, sesa zhvilluesit...

Kjo është një problem i zakonshëm në mikroshërbime dhe zgjidhet me sisteme të shpërndara të gjurmimit, ku shërbimet dërgojnë një titull unik njëra-tjetrës, pas së cilës kjo informacion kalon në sistemin e gjurmimit, ku përputhet me të dhënat e kërkesës. Ja një ilustarim:

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

Në Istio përdoret Jaeger Tracer, i cili implementon një kornizë të varur nga shitësit OpenTracing API. Mund të qaseni në ndërfaqen e përdoruesit Jaeger 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ë menunë e rënie — krijoni/gjeneroni aktivitet në faqe dhe rifreskoni ndërfaqen. Pas kësaj, klikoni në butonin Gjej Gjurmët, e cila do të tregojë gjurmët më të fundit — zgjidhni çfarëdo — do të shfaqet informacione të detajuara për të gjitha gjurmët:

Kjo gjurmë tregon:

Kërkesa vjen në istio-ingressgateway (kjo është ndërveprimi i parë me një nga shërbimet, dhe për kërkesën gjenerohet Trace ID), pas së cilës gateway e drejton kërkesën në shërbim sa-web-app.
Në shërbim sa-web-app kërkesa kapet nga sidecar'i Envoy, krijohet një 'fëmijë' në span (prandaj e shohim atë në gjurmë) dhe redirigjohet në kontenier sa-web-app. (Span — njësi logjike e punës në Jaeger, që përmban emrin, kohën e fillimit të operacionit dhe kohëzgjatjen e tij. Span’ët mund të jenë të inkorporuar dhe të renditur. Një graf të orientuar aciklik nga span’ët formon trace. — shën. përk.)
Këtu kërkesa përpunuar me metodën sentimentAnalysis. Këto gjurmë janë tashmë të gjeneruara nga aplikacioni, dmth. për to kërkoheshin ndryshime në kod.
Nga ky moment iniciatohet një kërkesë POST në sa-logic. Trace ID 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ë në kërkesat e mëtejshme, siç tregohet në imazhin më poshtë:

(A) Për kalimin e 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 që vijnë, krijon span të rinj në çdo sidecar dhe i kalon ato. Megjithatë, pa punën me titujt brenda shërbimeve, rruga e plotë e gjurmimit të kërkesës do të humbaset.

Duhet marrë parasysh (kalimi) 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 shtoni bibliotekat Jaeger dhe OpenTracing në varësitë e tij.

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

Tani, kur është bërë e qartë se çfarë po marrim nga kuti (ose pothuajse ‘nga kutia’), le të shqyrtojmë çështjet e ruterimit të ndjeshëm, menaxhimit të trafikut të rrjetit, sigurisë etj.!

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

P.S. nga përkthyesi

Lexoni gjithashtu në blogun tonë:

«Kthehu te mikroshërbimet me Istio»: pjesa 2 (routinimi, menaxhimi i trafikut), pjesa 3 (autentifikimi dhe autorizimi);
«Conduit — një service mesh i lehtë për Kubernetes»;
«Çfarë është service mesh dhe pse më nevojitet [për një aplikacion në cloud me mikroshërbime]?»;
«Një udhëzues i ilustruar për ndërtimin e rrjetit në Kubernetes. Pjesët 1 dhe 2»;
«Si përfundoi ky kontenier sidecar këtu [në Kubernetes]?».

Burimi: habr.com