Në të kaluarën Ne kemi shqyrtuar komponentët bazë të Service Mesh Istio, kemi njohur sistemin dhe kemi adresuar pyetjet kryesore që zakonisht lindin në fillim të punës me Istio. Në këtë pjesë do të shikojmë se si të organizojmë mbledhjen e informacionit të tracing në rrjet.
E para që i vjen në mend shumicës së zhvilluesve dhe administratorëve të sistemeve kur dëgjojnë fjalët Service Mesh është tracing. Dhe me të vërtetë, ne shtojmë një server proxy special në çdo nyje të rrjetit, përmes të cilit kalon gjithë trafiku TCP. Mund të duket se tani mund të dërgojmë lehtësisht informacionin mbi të gjitha ndërveprimet rrjetësore. Megjithatë, në realitet, shfaqen shumë nuanca që duhet të merren parasysh. Le të shqyrtojmë ato.
Miti numër një: ne mund të marrim falas të dhëna për kalimet në rrjet.
Në të vërtetë, ne mund të marrim relativisht falas vetëm nyjet e lidhura me shigjeta të sistemit tonë dhe shkallën e të dhënave që kalon ndërmjet shërbimeve (në thelb - vetëm numri i bajtëve në njësi kohe). Megjithatë, në shumicën e rasteve, shërbimet tona komunikojnë përmes ndonjë protokolli të nivelit aplikativ, siç janë HTTP, gRPC, Redis dhe kështu me radhë. Dhe, natyrisht, dëshirojmë të shohim informacionin e tracing pikërisht për këto protokolle, duam të shohim shkallën e kërkesave dhe jo shkallën e të dhënave. Duam të kuptojmë latencën e kërkesave sipas protokollit tonë. Përfundimisht, duam të shohim rrugën e plotë që ndjek kërkesa nga hyrja në sistemin tonë deri në marrjen e përgjigjes nga përdoruesi. Ky problem nuk zgjidhet kaq lehtë.
Së pari, le të shikojmë si duket dërgimi i tracing span-eve nga perspektiva arkitekturore në Istio. Siç e mbajmë mend nga pjesa e parë, për mbledhjen e telemetrisë, Istio ka një komponent të veçantë që quhet Mixer. Megjithatë, në versionin aktual 1.0.*, dërgimi bëhet njëherësh nga serverët proxy, dhe saktësisht, nga envoy proxy. Envoy proxy mbështet dërgimin e tracing span-eve përmes protokollit zipkin nga kutia. Protokolle të tjera mund të lidhen, por vetëm përmes një plugini. Me Istio, ne marrim menjëherë një envoy proxy të mbledhjes dhe konfigurimit, në të cilin mbështetet vetëm protokolli zipkin. Nëse dëshirojmë të përdorim, për shembull, protokollin Jaeger dhe të dërgojmë tracing span-e përmes UDP, atëherë na nevojitet të ndërtojmë imazhin tonë të istio-proxy. Mbështetja për pluginet e zakonuara për istio-proxy ekziston, megjithatë ajo është ende në versionin alfa. Prandaj, nëse dëshirojmë të shmangim një numër të madh konfigurimesh të personalizuara, rrethi i teknologjive të përdorura për ruajtjen dhe pranimin e tracing span-eve ulet. Nga sistemet kryesore, në thelb, tani mund të përdorim vetë Zipkin ose Jaeger, por të dërgojmë gjithçka në një protokoll të përputhshëm me zipkin (çka është dukshëm më pak efikas). Protokolli zipkin parashikon dërgimin e gjithë informacionit të tracing te kolektorët përmes protokollit HTTP, që është mjaft i kushtueshëm.
Siç thashë, ne dëshirojmë të ndjekim protokollet e nivelit aplikativ. Kjo do të thotë se serverët proxy, të cilët qëndrojnë pranë çdo shërbimi, duhet të kuptojnë se çfarë ndodh në ndërveprime. Në mënyrë të paracaktuar, Istio konfiguronte për të gjitha portet një tip TCP të thjeshtë, që do të thotë se nuk do të dërgohen asnjë tracing. Për të dërguar tracing, është e nevojshme, në radhë të parë, të aktivizoni një opsion të tillë në konfigurimin kryesor të mesh-it dhe, që është shumë e rëndësishme, të emëroni të gjitha portet e entiteteve shërbimi të kubernetes në përputhje me protokollin që përdoret në shërbim. Pra, për shembull, kështu:
apiVersion: v1
kind: Service
metadata:
name: nginx
spec:
ports:
- port: 80
targetPort: 80
name: http
selector:
app: nginxMund të përdoren gjithashtu emra të përbërë, si për shembull http-magic (Istio do ta shohë http dhe do ta njohë këtë port si http endpoint). Formati është i tillë: proto-extra.
Për të mos ndryshuar një numër të madh konfiguracionesh për të përcaktuar protokollin, mund të përdorim një workaround të papastër: të ndryshojmë komponentin Pilot në momentin kur ai saktësisht . Si përfundim, natyrisht, do të duhet të ndryshojmë këtë logjikë në standardin dhe të kalojmë në konvencionin e emërtimit të të gjitha porteve.
Për të kuptuar nëse protokolli është vërtet i përcaktuar siç duhet, është e nevojshme të hyni në ndonjë nga kontejnerët sidecar me envoy proxy dhe të bëni një kërkesë në portin e ndërfaqes admin të envoy me vendndodhjen /config_dump. Në konfigurimin e marrë duhet të shikoni në shërbimin përkatës fushën operation. Ajo përdoret në Istio si identifikues i asaj ku bëhet kërkesa. Për të personalizuar në Istio vlerën e këtij parametri (ne më pas do ta shohim atë në sistemin tonë të tracing), është e nevojshme që në fazën e nisjes së kontejnerit sidecar të spesifikoni flamurin serviceCluster. Për shembull, mund të llogaritet në këtë mënyrë me variablat e marra nga API poshtë kubernetes:
--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')
Një shembull i mirë për të kuptuar se si funksionon tracing në envoy është .
EndPoint-i për dërgimin e span-ave të tracing duhet gjithashtu të përmendet në flagat e lançimit të envoy proxy, për shembull: --zipkinAddress tracing-collector.tracing:9411
Mishtja numër dy: ne mund ta marrim në mënyrë të lirë tracing më të plotë të kalimeve të kërkesave në sistem nga kutia.
Fatkeqësisht, kjo nuk është e vërtetë. Ndërlikimi i implementimit varet nga mënyra se si tashmë keni realizuar ndërveprimin midis shërbimeve. Pse ndodh kjo?
ĂĂ«shtja Ă«shtĂ« se pĂ«r tĂ« kuptuar istio-proxy lidhjen e kĂ«rkesave tĂ« mbĂ«rritura me ato qĂ« dalin nga i njĂ«jti shĂ«rbim, nuk mjafton tĂ« kapni tĂ« gjithĂ« trafikun. Duhet tĂ« keni njĂ« identifikues lidhjeje. NĂ« HTTP, envoy proxy pĂ«rdor header-e tĂ« veçantĂ«, me anĂ« tĂ« cilave envoy kupton se cila kĂ«rkesĂ« pĂ«r shĂ«rbimin gjeneron kĂ«rkesa specifike pĂ«r shĂ«rbime tĂ« tjera. Lista e header-eve tĂ« tillĂ« Ă«shtĂ«:
- x-request-id,
- x-b3-traceid,
- x-b3-spanid,
- x-b3-parentspanid,
- x-b3-sampled,
- x-b3-flags,
- x-ot-span-context.
NĂ«se keni njĂ« pikĂ« tĂ« vetme, pĂ«r shembull, njĂ« klient bazik, ku mund tĂ« shtoni njĂ« logjikĂ« tĂ« tillĂ«, atĂ«herĂ« gjithçka Ă«shtĂ« nĂ« rregull, ju thjesht do tĂ« duhet tĂ« prisni pĂ«r pĂ«rditĂ«simin e kĂ«saj biblioteke tek tĂ« gjithĂ« klientĂ«t. Por nĂ«se keni njĂ« sistem shumĂ« heterogjen dhe nuk ka unifikim nĂ« kalimin midis shĂ«rbimeve pĂ«rmes rrjetit, atĂ«herĂ« probabilitetisht kjo do tĂ« jetĂ« njĂ« problem i madh. Pa shtimin e logjikĂ«s tĂ« tillĂ«, tĂ« gjitha informacionet e tracing do tĂ« jenĂ« ânĂ« njĂ« nivelâ. KĂ«shtu qĂ« do tĂ« marrim tĂ« gjitha ndĂ«rveprimet midis shĂ«rbimeve, por ato nuk do tĂ« jenĂ« tĂ« lidhura nĂ« zinxhirĂ« tĂ« vetme kalimi pĂ«rmes rrjetit.
PĂ«rfundimi
Istio ofron një mjet të përshtatshëm për mbledhjen e informacionit të tracing në rrjet, megjithatë duhet të kuptohet se për implementimin e tij do të nevojitet adaptimi i sistemit tuaj dhe marrja parasysh e veçorive të implementimit të Istio. Në fund, duhet të zgjidhen dy çështje kryesore: përcaktimi i protokollit të nivelit të aplikacionit (i cili duhet të përkrahë envoy proxy) dhe konfigurimi i kalimit të informacionit mbi lidhshmërinë e kërkesave nga shërbimi në kërkesat që dalin nga shërbimi (nëpërmjet header-eve, në rastin e protokollit HTTP). Kur këto çështje janë zgjidhur, ne marrim një mjet të fuqishëm që lejon mbledhjen transparente të informacionit nga rrjeti, edhe në sisteme shumë heterogjene, të shkruara në shumë gjuhë dhe framework-e të ndryshme.
NĂ« artikullin e ardhshĂ«m mbi Service Mesh do tĂ« shqyrtojmĂ« njĂ« nga problemet mĂ« tĂ« mĂ«dha tĂ« Istio â konsumimi i madh i memorjes nga secili kontejner sidecar proxy dhe do tĂ« diskutojmĂ« se si mund tĂ« luftohet kjo.
Burimi: habr.com
