Tandaan. transl.: Ang mga service meshes ay talagang naging isang nauugnay na solusyon sa modernong imprastraktura para sa mga application na sumusunod sa microservice architecture. Habang ang Istio ay maaaring nasa mga labi ng maraming mga inhinyero ng DevOps, ito ay isang medyo bagong produkto na, habang komprehensibo sa mga tuntunin ng mga kakayahan na ibinibigay nito, ay maaaring mangailangan ng malaking tagal ng oras upang maging pamilyar. Ang German engineer na si Rinor Maloku, na responsable para sa cloud computing para sa malalaking kliyente sa kumpanya ng telekomunikasyon na Orange Networks, ay nagsulat ng napakagandang serye ng mga materyales na nagbibigay-daan sa iyong mabilis at malalim na sumisid sa Istio. Sinimulan niya ang kanyang kuwento sa kung ano ang maaaring gawin ni Istio sa pangkalahatan at kung paano mo ito mabilis na makikita ng sarili mong mga mata.
Istio β Isang proyekto ng Open Source na binuo sa pakikipagtulungan sa mga koponan mula sa Google, IBM at Lyft. Nilulutas nito ang mga pagkakumplikado na lumitaw sa mga application na nakabatay sa microservice, gaya ng:
- Pamamahala ng Trapiko: timeout, muling pagsubok, load balancing;
- katiwasayan: pagpapatunay at awtorisasyon ng end user;
- Pagmamasid: pagsubaybay, pagsubaybay, pag-log.
Ang lahat ng ito ay maaaring malutas sa antas ng aplikasyon, ngunit pagkatapos nito ang iyong mga serbisyo ay hindi na magiging "micro". Ang lahat ng labis na pagsisikap upang malutas ang mga problemang ito ay isang pag-aaksaya ng mga mapagkukunan ng kumpanya na maaaring magamit nang direkta para sa halaga ng negosyo. Tingnan natin ang isang halimbawa:
Project Manager: Gaano katagal bago magdagdag ng feature ng feedback?
Developer: Dalawang sprint.MP: Ano?.. CRUD lang!
R: Ang paggawa ng CRUD ay ang madaling bahagi, ngunit kailangan pa rin nating patunayan at pahintulutan ang mga user at serbisyo. Dahil hindi mapagkakatiwalaan ang network, kakailanganin mong ipatupad ang mga paulit-ulit na kahilingan, pati na rin sa mga kliyente. Gayundin, upang matiyak na ang buong system ay hindi mag-crash, kakailanganin mo ng mga timeout at (para sa higit pang mga detalye tungkol sa parehong nabanggit na mga pattern, tingnan sa ibang pagkakataon sa artikulo - tinatayang transl.), at upang makita ang mga problema, pagsubaybay, pagsubaybay, [β¦]MP: Oh, ipasok na lang natin ang feature na ito sa serbisyo ng Produkto.
Sa tingin ko ang ideya ay malinaw: ang dami ng mga hakbang at pagsisikap na kinakailangan upang magdagdag ng isang serbisyo ay napakalaki. Sa artikulong ito, titingnan natin kung paano inaalis ng Istio ang lahat ng kumplikadong binanggit sa itaas (na hindi nilayon na maging lohika ng negosyo) mula sa mga serbisyo.
Nota: Ipinapalagay ng artikulong ito na mayroon kang kaalaman sa Kubernetes. Kung hindi, inirerekumenda ko ang pagbabasa at pagkatapos lamang nito ay ipagpatuloy ang pagbabasa ng materyal na ito.
Istio ideya
Sa isang mundong walang Istio, ang isang serbisyo ay gumagawa ng mga direktang kahilingan sa isa pa, at sa kaganapan ng isang pagkabigo, ang serbisyo ay dapat hawakan ito mismo: gumawa ng isang bagong pagtatangka, magbigay ng isang timeout, magbukas ng isang circuit breaker, atbp.
Trapiko sa network sa Kubernetes
Nag-aalok ang Istio ng isang espesyal na solusyon, ganap na nakahiwalay sa mga serbisyo at gumagana sa pamamagitan ng pakikialam sa komunikasyon sa network. At sa gayon ito ay nagpapatupad:
- pagpaparaya sa kasalanan: Batay sa status code sa tugon, nauunawaan nito kung nabigo ang kahilingan at muling isagawa ito.
- Canary rollouts: nagre-redirect lamang ng isang nakapirming porsyento ng mga kahilingan sa bagong bersyon ng serbisyo.
- Pagsubaybay at sukatan: Gaano katagal bago tumugon ang serbisyo?
- Pagsubaybay at Pagmamasid: Nagdaragdag ng mga espesyal na header sa bawat kahilingan at sinusubaybayan ang mga ito sa buong cluster.
- katiwasayan: Kinukuha ang JWT token, pinapatotohanan at pinahihintulutan ang mga user.
Ilan lang ito sa mga posibilidad (talagang iilan lang!) para maintriga ka. Ngayon, sumisid tayo sa mga teknikal na detalye!
Istio architecture
Hinaharang ni Istio ang lahat ng trapiko sa network at inilalapat ang isang hanay ng mga panuntunan dito, na naglalagay ng smart proxy sa anyo ng sidecar container sa bawat pod. Ang mga proxy na nagpapagana sa lahat ng mga kakayahan ay bumubuo ng a Data Plane, at maaari silang dynamic na i-configure gamit ang Pagkontrol ng Plane.
Data Plane
Ang mga proxy na ipinasok sa mga pod ay nagbibigay-daan sa Istio na madaling matugunan ang mga kinakailangan na kailangan namin. Halimbawa, suriin natin ang retry at circuit breaker function.
Paano ipinapatupad sa Envoy ang muling pagsubok at circuit breaking
Upang buod:
- Sugo (pinag-uusapan natin ang tungkol sa isang proxy na matatagpuan sa isang sidecar container, na ibinabahagi bilang β tinatayang. transl.) nagpapadala ng kahilingan sa unang pagkakataon ng serbisyo B at nabigo.
- Sinubukan muli ng Envoy Sidecar (subukang muli). (1)
- Nabigo ang kahilingan at ibinalik sa proxy na tumawag dito.
- Binubuksan nito ang Circuit Breaker at tatawag sa susunod na serbisyo para sa mga kasunod na kahilingan. (2)
Nangangahulugan ito na hindi mo na kailangang gumamit ng isa pang Retry library, hindi mo kailangang gumawa ng sarili mong pagpapatupad ng Circuit Breaking at Service Discovery sa programming language X, Y o Z. Lahat ito at marami pang iba ay available out of the box sa Istio at hindi nangangailangan hindi pagbabago sa code.
Malaki! Ngayon ay maaaring gusto mong pumunta sa isang paglalakbay kasama si Istio, ngunit mayroon ka pa ring ilang mga pagdududa, bukas na mga katanungan. Kung ito ay isang unibersal na solusyon para sa lahat ng mga okasyon sa buhay, kung gayon mayroon kang natural na hinala: pagkatapos ng lahat, ang lahat ng gayong mga solusyon sa katotohanan ay naging hindi angkop para sa anumang kaso.
At sa wakas ay itatanong mo: "Nako-customize ba ito?"
Ngayon ay handa ka na para sa paglalayag sa dagat, kilalanin natin ang Control Plane.
Pagkontrol ng Plane
Binubuo ito ng tatlong sangkap: piloto, panghalo ΠΈ Muog, na nagtutulungan upang i-configure ang mga Envoy upang iruta ang trapiko, ipatupad ang mga patakaran, at mangolekta ng data ng telemetry. Sa eskematiko, ganito ang hitsura ng lahat:
Pakikipag-ugnayan ng Control Plane sa Data Plane
Ang mga sugo (i.e. data plane) ay na-configure gamit ang (Custom Resource Definition) na tinukoy ni Istio at partikular na nilayon para sa layuning ito. Ang ibig sabihin nito sa iyo ay lumilitaw na isa lamang silang mapagkukunan sa Kubernetes na may pamilyar na syntax. Kapag nalikha na, ang mapagkukunang ito ay kukunin ng control plane at ilalapat sa mga Envoy.
Kaugnayan ng mga serbisyo sa Istio
Inilarawan namin ang kaugnayan ni Istio sa mga serbisyo, ngunit hindi ang kabaligtaran: paano nauugnay ang mga serbisyo sa Istio?
Sa totoo lang, alam ng mga serbisyo ang presensya ni Istio gaya ng mga isda sa tubig kapag tinanong nila ang kanilang sarili, "Ano nga ba ang tubig?"
Guhit : - Paano mo gusto ang tubig? - Ano ang tubig?
Kaya, maaari kang kumuha ng isang gumaganang cluster at pagkatapos i-deploy ang mga bahagi ng Istio, ang mga serbisyong matatagpuan dito ay patuloy na gagana, at pagkatapos alisin ang mga bahaging ito, ang lahat ay magiging maayos muli. Malinaw na sa kasong ito ay mawawalan ka ng mga kakayahan na ibinigay ng Istio.
Sapat na teorya - isabuhay natin ang kaalamang ito!
Istio sa practice
Nangangailangan ang Istio ng Kubernetes cluster na may hindi bababa sa 4 na vCPU at 8 GB ng RAM na available. Upang mabilis na mag-set up ng cluster at sundin ang mga tagubilin mula sa artikulo, inirerekomenda ko ang paggamit ng Google Cloud Platform, na nag-aalok ng mga bagong user .
Pagkatapos gumawa ng cluster at i-configure ang access sa Kubernetes sa pamamagitan ng console utility, maaari mong i-install ang Istio sa pamamagitan ng Helm package manager.
Pag-install ng helmet
I-install ang Helm client sa iyong computer, gaya ng inilarawan sa . Gagamitin namin ito upang bumuo ng mga template para sa pag-install ng Istio sa susunod na seksyon.
Pag-install ng Istio
I-download ang mga mapagkukunan ng Istio mula sa (ang orihinal na link ng may-akda sa bersyon 1.0.5 ay binago sa kasalukuyan, i.e. 1.0.6 - tinatayang transl.), i-extract ang mga nilalaman sa isang direktoryo, na tatawagin ko mula ngayon [istio-resources].
Para madaling matukoy ang mga mapagkukunan ng Istio, gumawa ng namespace sa cluster ng K8s istio-system:
$ kubectl create namespace istio-system
Kumpletuhin ang pag-install sa pamamagitan ng pagpunta sa direktoryo [istio-resources] at patakbuhin ang utos:
$ 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
Ilalabas ng command na ito ang mga pangunahing bahagi ng Istio sa isang file istio.yaml. Binago namin ang karaniwang template upang umangkop sa aming sarili, na tinutukoy ang mga sumusunod na parameter:
-
global.mtls.enablednaka-install safalse(ibig sabihin, hindi pinagana ang pagpapatotoo ng mTLS - humigit-kumulang)upang pasimplehin ang aming proseso ng pakikipag-date; -
tracing.enabledkasama ang pagsubaybay sa kahilingan gamit ang Jaeger; -
kiali.enabledi-install ang Kiali sa isang cluster upang mailarawan ang mga serbisyo at trapiko; -
grafana.enablednag-i-install ng Grafana upang mailarawan ang mga nakolektang sukatan.
Gamitin natin ang mga nabuong mapagkukunan gamit ang command:
$ kubectl apply -f istio.yaml
Kumpleto na ang pag-install ng Istio sa cluster! Maghintay hanggang ang lahat ng pod ay nasa namespace istio-system ay magagawang Running o Completedsa pamamagitan ng pagpapatakbo ng utos sa ibaba:
$ kubectl get pods -n istio-systemNgayon ay handa na kaming magpatuloy sa susunod na seksyon, kung saan papaganahin namin ang application.
Arkitektura ng application ng Sentiment Analysis
Gamitin natin ang halimbawa ng application ng microservice ng Sentiment Analysis na ginamit sa nabanggit na . Ito ay sapat na kumplikado upang ipakita ang mga kakayahan ni Istio sa pagsasanay.
Ang application ay binubuo ng apat na microservices:
- Tools SA-Frontend, na nagsisilbi sa frontend ng isang Reactjs application;
- Tools SA-WebApp, na naghahatid ng mga query sa Pagsusuri ng Sentiment;
- Tools SA-Lohika, na gumaganap mismo ;
- Tools SA-Feedback, na tumatanggap ng feedback mula sa mga user tungkol sa katumpakan ng pagsusuri.
Sa diagram na ito, bilang karagdagan sa mga serbisyo, nakikita rin namin ang Ingress Controller, na sa Kubernetes ay nagruruta ng mga papasok na kahilingan sa mga naaangkop na serbisyo. Gumagamit ang Istio ng katulad na konsepto sa loob ng Ingress Gateway nito, higit pang mga detalye kung saan susundan.
Pagpapatakbo ng isang application gamit ang isang proxy mula sa Istio
Para sa mga karagdagang operasyong binanggit sa artikulo, i-clone ang iyong repositoryo . Naglalaman ito ng aplikasyon at mga manifest para sa Kubernetes at Istio.
Pagpasok ng mga sidecar
Maaaring gawin ang pagpasok awtomatikong o sa pamamagitan ng kamay. Para awtomatikong magpasok ng mga sidecar container, kakailanganin mong magtakda ng label sa namespace istio-injection=enabled, na ginagawa gamit ang sumusunod na utos:
$ kubectl label namespace default istio-injection=enabled
namespace/default labeled
Ngayon ang bawat pod na ide-deploy sa default na namespace (default) ay makakatanggap ng sidecar container nito. Para ma-verify ito, i-deploy natin ang test application sa pamamagitan ng pagpunta sa root directory ng repository [istio-mastery] at patakbuhin ang sumusunod na utos:
$ 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
Kapag na-deploy ang mga serbisyo, tingnan natin kung ang mga pod ay may dalawang lalagyan (kasama ang serbisyo mismo at ang sidecar nito) sa pamamagitan ng pagpapatakbo ng command kubectl get pods at siguraduhin na sa ilalim ng hanay READY tinukoy na halaga 2/2, na sumasagisag na ang parehong mga lalagyan ay tumatakbo:
$ 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 12mBiswal ito ay ganito:
Envoy proxy sa isa sa mga pod
Ngayon na ang application ay gumagana at tumatakbo, kakailanganin naming payagan ang papasok na trapiko na pumasok sa application.
Ingress Gateway
Ang pinakamahusay na kasanayan upang makamit ito (payagan ang trapiko sa cluster) ay matapos Ingress Gateway sa Istio, na matatagpuan sa "gilid" ng cluster at nagbibigay-daan sa iyong paganahin ang mga feature ng Istio tulad ng pagruruta, pagbalanse ng load, seguridad at pagsubaybay para sa papasok na trapiko.
Ang bahagi ng Ingress Gateway at ang serbisyong nagpapasa nito sa labas ay na-install sa cluster sa panahon ng pag-install ng Istio. Upang malaman ang panlabas na IP address ng serbisyo, patakbuhin ang:
$ 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.120Patuloy naming i-access ang application gamit ang IP na ito (tutukoy ko ito bilang EXTERNAL-IP), kaya para sa kaginhawahan ay isusulat namin ang halaga sa isang variable:
$ EXTERNAL_IP=$(kubectl get svc -n istio-system
-l app=istio-ingressgateway
-o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')Kung susubukan mong i-access ang IP na ito sa pamamagitan ng browser ngayon, makakatanggap ka ng Service Unavailable error, dahil bilang default, hinaharangan ng Istio ang lahat ng papasok na trapiko, Gateway ay hindi pa natukoy.
mapagkukunan ng gateway
Ang Gateway ay isang CRD (Custom Resource Definition) sa Kubernetes, na tinukoy pagkatapos i-install ang Istio sa cluster at i-enable ang kakayahang tukuyin ang mga port, protocol at host kung saan gusto naming payagan ang papasok na trapiko.
Sa aming kaso, gusto naming payagan ang trapiko ng HTTP sa port 80 para sa lahat ng mga host. Ang gawain ay ipinatupad sa pamamagitan ng sumusunod na kahulugan ():
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: http-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
Ang pagsasaayos na ito ay hindi nangangailangan ng paliwanag maliban sa tagapili istio: ingressgateway. Gamit ang selector na ito maaari naming tukuyin kung saang Ingress Gateway ilalapat ang configuration. Sa aming kaso, ito ang Ingress Gateway controller, na na-install bilang default sa Istio.
Ang pagsasaayos ay inilapat sa pamamagitan ng pagtawag sa sumusunod na utos:
$ kubectl apply -f resource-manifests/istio/http-gateway.yaml gateway.networking.istio.io/http-gateway createdPinapayagan na ngayon ng gateway ang pag-access sa port 80, ngunit walang ideya kung saan dadalhin ang mga kahilingan. Para dito kakailanganin mo Mga Serbisyong Virtual.
mapagkukunan ng VirtualService
Sinasabi ng VirtualService sa Ingress Gateway kung paano iruta ang mga kahilingan na pinapayagan sa loob ng cluster.
Ang mga kahilingan sa aming aplikasyon na dumarating sa http-gateway ay dapat ipadala sa sa-frontend, sa-web-app at sa-feedback na mga serbisyo:
Mga ruta na kailangang i-configure gamit ang VirtualServices
Tingnan natin ang mga kahilingan na dapat ipadala sa SA-Frontend:
- Eksaktong tugma sa daan
/dapat ipadala sa SA-Frontend upang makakuha ng index.html; - Mga prefix na landas
/static/*dapat ipadala sa SA-Frontend upang makatanggap ng mga static na file na ginamit sa frontend, gaya ng CSS at JavaScript; - Mga path na tumugma sa regular na expression
'^.*.(ico|png|jpg)$', ay dapat ipadala sa SA-Frontend, dahil Ito ang mga larawang ipinapakita sa pahina.
Ang pagpapatupad ay nakamit sa pamamagitan ng sumusunod na pagsasaayos ():
kind: VirtualService
metadata:
name: sa-external-services
spec:
hosts:
- "*"
gateways:
- http-gateway # 1
http:
- match:
- uri:
exact: /
- uri:
exact: /callback
- uri:
prefix: /static
- uri:
regex: '^.*.(ico|png|jpg)$'
route:
- destination:
host: sa-frontend # 2
port:
number: 80Mahalaga puntos:
- Ang VirtualService na ito ay tumutukoy sa mga kahilingang dumarating http-gateway;
- Π
destinationNatutukoy ang serbisyo kung saan ipinapadala ang mga kahilingan.
Nota: Ang configuration sa itaas ay nakaimbak sa isang file sa-virtualservice-external.yaml, na naglalaman din ng mga setting para sa pagruruta sa SA-WebApp at SA-Feedback, ngunit pinaikli dito sa artikulo para sa maikli.
Ilapat natin ang VirtualService sa pamamagitan ng pagtawag sa:
$ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml
virtualservice.networking.istio.io/sa-external-services createdNota: Kapag gumagamit kami ng mga mapagkukunan ng Istio, ang Kubernetes API Server ay lumilikha ng isang kaganapan na natatanggap ng Istio Control Plane, at pagkatapos nito ay inilapat ang bagong configuration sa mga proxies ng Envoy ng bawat pod. At ang Ingress Gateway controller ay lumilitaw na isa pang Envoy na na-configure sa Control Plane. Ang lahat ng ito ay ganito ang hitsura sa diagram:
Istio-IngressGateway configuration para sa pagruruta ng kahilingan
Available na ngayon ang application ng Sentiment Analysis sa http://{EXTERNAL-IP}/. Huwag mag-alala kung nakakuha ka ng status na Not Found: Minsan mas matagal bago magkabisa ang configuration at mag-update ang Envoy cache.
Bago magpatuloy, maglaro nang kaunti sa app para makabuo ng trapiko. (Ang presensya nito ay kinakailangan para sa kalinawan sa mga kasunod na pagkilos - humigit-kumulang transl.).
Kiali: observability
Upang makarating sa administratibong interface ng Kiali, patakbuhin ang sumusunod na command:
$ kubectl port-forward
$(kubectl get pod -n istio-system -l app=kiali
-o jsonpath='{.items[0].metadata.name}')
-n istio-system 20001... at buksan , nagla-log in bilang admin/admin. Dito mahahanap mo ang maraming kapaki-pakinabang na tampok, halimbawa, upang suriin ang pagsasaayos ng mga bahagi ng Istio, ilarawan sa isip ang mga serbisyo gamit ang impormasyong nakolekta mula sa pagharang sa mga kahilingan sa network, makakuha ng mga sagot sa mga tanong na "Sino ang nakikipag-ugnay kanino?", "Aling bersyon ng serbisyo ang nararanasan mga kabiguan?β at iba pa. Sa pangkalahatan, galugarin ang mga kakayahan ng Kiali bago magpatuloy sa pag-visualize ng mga sukatan gamit ang Grafana.
Grafana: visualization ng mga sukatan
Ang mga sukatan na nakolekta sa Istio ay napupunta sa Prometheus at nakikita gamit ang Grafana. Upang makapunta sa Grafana administrative interface, patakbuhin ang command sa ibaba at pagkatapos ay buksan :
$ kubectl -n istio-system port-forward
$(kubectl -n istio-system get pod -l app=grafana
-o jsonpath={.items[0].metadata.name}) 3000Pag-click sa menu Tahanan kaliwang itaas at pagpili Dashboard ng Serbisyo ng Istio sa kaliwang sulok sa itaas, magsimula sa serbisyo sa-web-appupang tingnan ang mga nakolektang sukatan:
Ang naghihintay sa amin dito ay isang walang laman at ganap na nakakainip na pagganap - hindi kailanman aaprubahan ito ng pamamahala. Gumawa tayo ng maliit na load gamit ang sumusunod na command:
$ while true; do
curl -i http://$EXTERNAL_IP/sentiment
-H "Content-type: application/json"
-d '{"sentence": "I love yogobella"}';
sleep .8; doneNgayon ay mayroon na kaming mas magagandang mga graph, at bilang karagdagan sa mga ito, ang mga kahanga-hangang tool ng Prometheus para sa pagsubaybay at Grafana para sa pag-visualize ng mga sukatan na magbibigay-daan sa amin upang malaman ang tungkol sa pagganap, kalusugan, mga pagpapabuti / pagkasira sa mga serbisyo sa paglipas ng panahon.
Panghuli, tingnan natin ang pagsubaybay sa mga kahilingan sa mga serbisyo.
Jaeger: pagsubaybay
Kakailanganin namin ang pagsubaybay dahil mas maraming serbisyo ang mayroon kami, mas mahirap makuha ang sanhi ng pagkabigo. Tingnan natin ang isang simpleng kaso mula sa larawan sa ibaba:
Karaniwang halimbawa ng isang random na nabigong kahilingan
Dumating ang kahilingan, bumabagsak - ano ang dahilan? Unang serbisyo? O ang pangalawa? Mayroong mga pagbubukod sa pareho - tingnan natin ang mga log ng bawat isa. Gaano mo kadalas nahuli ang iyong sarili na ginagawa ito? Ang aming trabaho ay mas katulad ng mga software detective kaysa sa mga developer...
Ito ay isang pangkaraniwang problema sa mga microservice at nalulutas sa pamamagitan ng mga distributed tracing system, kung saan ang mga serbisyo ay nagpapasa ng isang natatanging header sa isa't isa, pagkatapos nito ay ipapasa ang impormasyong ito sa tracing system, kung saan ito ay inihambing sa data ng kahilingan. Narito ang isang ilustrasyon:
TraceId ay ginagamit upang tukuyin ang kahilingan
Gumagamit si Istio ng Jaeger Tracer, na nagpapatupad ng framework ng OpenTracing API na independyente sa vendor. Maaari mong ma-access ang Jaeger user interface gamit ang sumusunod na command:
$ kubectl port-forward -n istio-system
$(kubectl get pod -n istio-system -l app=jaeger
-o jsonpath='{.items[0].metadata.name}') 16686Ngayon pumunta sa at pumili ng serbisyo sa-web-app. Kung ang serbisyo ay hindi ipinapakita sa drop-down na menu, ipakita/bumuo ng aktibidad sa pahina at i-update ang interface. Pagkatapos nito, mag-click sa pindutan Maghanap ng mga Bakas, na magpapakita ng pinakabagong mga bakas - pumili ng anumang - detalyadong impormasyon sa lahat ng mga bakas ay lilitaw:
Ang bakas na ito ay nagpapakita ng:
- Pumasok ang kahilingan istio-ingressgateway (ito ang unang pakikipag-ugnayan sa isa sa mga serbisyo, at nabuo ang isang Trace ID para sa kahilingan), pagkatapos nito ipapadala ng gateway ang kahilingan sa serbisyo sa-web-app.
- Sa serbisyo sa-web-app ang kahilingan ay kinuha ng Envoy sidecar, isang "bata" ay nilikha sa span (kaya't nakikita natin ito sa mga bakas) at na-redirect sa lalagyan sa-web-app. ( - isang lohikal na yunit ng trabaho sa Jaeger, na may pangalan, oras ng pagsisimula ng operasyon at tagal nito. Ang mga span ay maaaring ma-nest at mag-order. Ang isang nakadirekta na acyclic graph ng mga span ay bumubuo ng isang bakas. β tinatayang. transl.)
- Dito pinoproseso ang kahilingan ayon sa pamamaraan sentimentAnalysis. Ang mga bakas na ito ay nabuo na ng application, i.e. kailangan nila ng mga pagbabago sa code.
- Mula sa sandaling ito, isang POST na kahilingan ang pinasimulan sa sa-logic. Dapat na ipasa ang Trace ID mula sa sa-web-app.
- ...
Nota: Sa hakbang 4, dapat makita ng application ang mga header na nabuo ni Istio at ipasa ang mga ito sa mga kasunod na kahilingan tulad ng ipinapakita sa larawan sa ibaba:
(A) Responsable si Istio para sa pagpapasa ng mga header; (B) Responsable ang mga serbisyo para sa mga header
Ginagawa ni Istio ang karamihan sa trabaho dahil... bumubuo ng mga header para sa mga papasok na kahilingan, gumagawa ng mga bagong span sa bawat sidecare at ipinapasa ang mga ito. Gayunpaman, nang hindi nagtatrabaho sa mga header sa loob ng mga serbisyo, ang buong kahilingan sa trace path ay mawawala.
Ang mga sumusunod na header ay dapat isaalang-alang:
x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
x-ot-span-contextIto ay hindi isang mahirap na gawain, ngunit upang gawing simple ang pagpapatupad nito ay mayroon na - halimbawa, sa serbisyo ng sa-web-app, ipinapasa ng kliyente ng RestTemplate ang mga header na ito kung idaragdag mo lang ang mga aklatan ng Jaeger at OpenTracing sa .
Tandaan na ang application ng Sentiment Analysis ay nagpapakita ng mga pagpapatupad sa Flask, Spring, at ASP.NET Core.
Ngayon na malinaw na kung ano ang makukuha natin sa labas ng kahon (o halos wala na sa kahon), tingnan natin ang pinong pagruruta, pamamahala ng trapiko sa network, seguridad, atbp.!
Tandaan. transl.: Basahin ang tungkol dito sa susunod na bahagi ng mga materyales sa Istio mula sa Rinor Maloku, ang mga pagsasalin nito ay susundan sa aming blog sa malapit na hinaharap. I-UPDATE (ika-14 ng Marso): nai-publish na.
PS mula sa tagasalin
Basahin din sa aming blog:
- "Bumalik sa mga microservice kasama si Istio": , ;
- Β«";
- Β«";
- Β«";
- Β«'.
Pinagmulan: www.habr.com