ProHoster > Blog > Administrim > Kthehu tek mikroshërbimet me Istio. Pjesa 1

Kthehu tek mikroshërbimet me Istio. Pjesa 1

Kthehu tek 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.

Kthehu tek mikroshërbimet me Istio. Pjesa 1

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.

Kthehu tek mikroshërbimet me Istio. Pjesa 1
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.

Kthehu tek mikroshërbimet me Istio. Pjesa 1
Si implementohen retries dhe circuit breaking në Envoy

Për të përmbledhur:

  1. 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.
  2. Envoy Sidecar bën një përpjekje të përsëritur (retry). (1)
  3. Kërkesa me dështim kthehet në proksin që e ka kërkuar.
  4. 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 dhe 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:

Kthehu tek mikroshërbimet me Istio. Pjesa 1
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?».

Kthehu tek mikroshërbimet me Istio. Pjesa 1
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 ose 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:

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

Kthehu tek mikroshërbimet me Istio. Pjesa 1

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

Kthehu tek mikroshërbimet me Istio. Pjesa 1
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:

Kthehu tek mikroshërbimet me Istio. Pjesa 1
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:


    

 	
  1.  Ky VirtualService i referohet kërkesave që arrijnë përmes http-gateway;
    2. 


 	
  2.  Në destination definohet shërbimi ku dërgohen kërkesat.
    3. 





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:
Kthehu tek mikroshërbimet me Istio. Pjesa 1
 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.
Kthehu tek mikroshërbimet me Istio. Pjesa 1
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:
Kthehu tek mikroshërbimet me Istio. Pjesa 1
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ë:
Kthehu tek mikroshërbimet me Istio. Pjesa 1
 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:
Kthehu tek mikroshërbimet me Istio. Pjesa 1
 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:
Kthehu tek mikroshërbimet me Istio. Pjesa 1
Kjo gjurmë tregon:
     
  1.  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.
    2.  
  2.  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.)
    3.  
  3.  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.
    4.  
  4.  Në këtë moment, aktivizohet një kërkesë POST në sa-logic. ID e Trace duhet të kalojë nga sa-web-app.
    5.  
  5.  

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ë:
Kthehu tek mikroshërbimet me Istio. Pjesa 1
 (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ë:
Burimi: habr.com
rruga:
 - destinacioni:
 host: sa-frontend             # 2
 porti:
 numri: 80

 Çështjet kryesore:
     
  1.  Ky VirtualService i referohet kërkesave që arrijnë përmes http-gateway;
    2.  
  2.  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:
Kthehu tek mikroshërbimet me Istio. Pjesa 1
 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.
Kthehu tek mikroshërbimet me Istio. Pjesa 1
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:
Kthehu tek mikroshërbimet me Istio. Pjesa 1
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ë:
Kthehu tek mikroshërbimet me Istio. Pjesa 1
 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:
Kthehu tek mikroshërbimet me Istio. Pjesa 1
 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:
Kthehu tek mikroshërbimet me Istio. Pjesa 1
Kjo gjurmë tregon:
     
  1.  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.
    2.  
  2.  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.
    3.  
  3.  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.
    4.  
  4.  Në këtë moment, aktivizohet një kërkesë POST në sa-logic. ID e Trace duhet të kalojë nga sa-web-app.
    5.  
  5.  

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ë:
Kthehu tek mikroshërbimet me Istio. Pjesa 1
 (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.
P.S. nga përkthyesi
Lexoni gjithashtu në blogun tonë:
 
Burimi: habr.com
    
             
 Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster