Në të kaluarën Ne kemi shqyrtuar komponentët bazë të Service Mesh Istio, kemi njohur sistemin dhe kemi përgjigjur në pyetjet kryesore që zakonisht lindin në fillim të punës me Istio. Në këtë pjesë do të shqyrtojmë se si të organizojmë mbledhjen e informacionit të tracing nëpër rrjet.
E para që iu vjen në mendje shumë 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 të veçantë në çdo nyjë të rrjetit, përmes të cilit kalon gjithë trafiku TCP. Duket se tani mund të dërgojmë lehtësisht informacion rreth të gjitha ndërveprimeve në rrjet. Megjithatë, në realitet, ka shumë nuanca që duhet të merret parasysh. Le të shqyrtojmë ato.
Miticizmi i parë: ne mund të marrim falas të dhëna për shëtitjet nëpër rrjet
NĂ« tĂ« vĂ«rtetĂ«, relativisht falas mund tĂ« marrim vetĂ«m nyjet e lidhura me shigjeta tĂ« sistemit tonĂ« dhe rate-n e tĂ« dhĂ«nave qĂ« kalon midis shĂ«rbimeve (nĂ« thelb â vetĂ«m sasia e byte-ve nĂ« njĂ« njĂ«si kohe). MegjithatĂ«, nĂ« shumicĂ«n e rasteve shĂ«rbimet tona komunikojnĂ« pĂ«rmes ndonjĂ« protokolli tĂ« nivelit aplikativ, si p.sh., HTTP, gRPC, Redis dhe tĂ« tjera. Dhe natyrisht, ne duam tĂ« shohim informacionin e tracing saktĂ«sisht pĂ«r kĂ«ta protokolla, duam tĂ« shohim rate-n e kĂ«rkesave, jo rate-n e tĂ« dhĂ«nave. Duam tĂ« kuptojmĂ« latency-n e kĂ«rkesave sipas protokollit tonĂ«. SĂ« fundi, 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. Kjo detyrĂ« nuk zgjidhet kaq lehtĂ«.
NĂ« fillim, le tĂ« shqyrtojmĂ« si duket dĂ«rgimi i tracing spanâave nga pikĂ«pamja e arkitekturĂ«s nĂ« Istio. Siç e kujtojmĂ« nga pjesa e parĂ«, pĂ«r mbledhjen e telemetrisĂ«, Istio ka njĂ« komponent tĂ« veçantĂ« tĂ« quajtur Mixer. MegjithatĂ«, nĂ« versionin aktual 1.0.*, dĂ«rgimi bĂ«het drejtpĂ«rdrejt nga serverĂ«t proxy, konkretisht, nga envoy proxy. Envoy proxy mbĂ«shtet dĂ«rgimin e tracing spanâave nĂ«pĂ«rmjet protokollit zipkin qĂ« vjen me tĂ«. Protokolle tĂ« tjera mund tĂ« lidhen, por vetĂ«m pĂ«rmes njĂ« plugin-i. Me Istio, ne marrim menjĂ«herĂ« njĂ« envoy proxy tĂ« mbledhur dhe tĂ« konfiguruar, ku mbĂ«shtetet vetĂ«m protokolli zipkin. NĂ«se dĂ«shirojmĂ« tĂ« pĂ«rdorim, pĂ«r shembull, protokollin Jaeger dhe tĂ« dĂ«rgojmĂ« tracing spanâave pĂ«rmes UDP, do na nevojitet tĂ« ndĂ«rtojmĂ« imazhin tonĂ« tĂ« istio-proxy. Ka mbĂ«shtetje pĂ«r plugin tĂ« personalizuar pĂ«r istio-proxy, megjithatĂ« ajo Ă«shtĂ« akoma nĂ« versionin alfa. Pra, nĂ«se duam tĂ« kalojmĂ« pa shumĂ« konfigurime tĂ« personalizuara, rrethi i teknologjive tĂ« pĂ«rdorura pĂ«r ruajtjen dhe marrjen e tracing spanâave zvogĂ«lohet. Nga sistemet kryesore, thelbĂ«sisht, tani mund tĂ« pĂ«rdoren Zipkin vetĂ«, ose Jaeger, por dĂ«rgimi atje bĂ«het gjithmonĂ« nĂ«pĂ«rmjet protokollit tĂ« pĂ«rputhshĂ«m me zipkin (çka Ă«shtĂ« dukshĂ«m mĂ« pak efikase). Protokolli zipkin parashikon dĂ«rgimin e tĂ« gjitha informacionve tĂ« tracing nĂ« kolektorĂ« pĂ«rmes protokollit HTTP, qĂ« Ă«shtĂ« mjaft i kushtueshĂ«m.
Siç e thashë, ne duam të ndjekim protokollet e nivelit të aplikacionit. Kjo do të thotë se serverët proxy që janë pranë çdo shërbimi duhet të kuptojnë se cila ndërveprim po ndodh tani. Në mënyrë standarde, Istio konfiguroni për të gjitha portet llojin plain TCP, që do të thotë se asnjë tracing nuk do të dërgohet. Për të dërguar tracing, së pari duhen aktivizuar një opsion të tillë në konfigurimin kryesor të mesh-it dhe, çka është shumë e rëndësishme, të emërtohen të gjitha portet e subjekteve të shërbimit në Kubernetes përkatësisht 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: nginxĂshtĂ« gjithashtu e mundur tĂ« pĂ«rdoren emra tĂ« pĂ«rbĂ«rĂ«, pĂ«r shembull http-magic (Istio do ta shohĂ« http dhe do ta njohĂ« kĂ«tĂ« port si endpoint http). Formati Ă«shtĂ« kĂ«shtu: proto-extra.
Për të shmangur modifikimin e një sërë të madh konfiguracionesh për të përcaktuar protokollin, mund të shfrytëzojmë një workaround të papëlqyeshëm: të modifikojmë komponentin Pilot në momentin që ai sapo Në fund, natyrisht, do të duhet të ndryshoni këtë logjikë në një standarde dhe të kaloni në konventën e emërtimeve për të gjitha portet.
Për të kuptuar nëse protokolli është vërtet i përcaktuar saktë, duhet 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 lokacionin /config_dump. Në konfigurimin e marrë, duhet të shikoni fushën operation për shërbimin e dëshiruara. Ajo përdoret në Istio si identifikuesi i atij vendi ku bëhet kërkesa. Për të personalizuar vlerën e kësaj parameteri në Istio (do ta shohim më pas në sistemin tonë të ndjekjes), është e nevojshme që gjatë fazës së nisjes së kontejnerit sidecar të përcaktohet flaga serviceCluster. Për shembull, mund të llogaritet kështu nga variablat e marra nga downward API i 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 ndjekja në envoy është .
Endpoint-i vetë për dërgimin e span-ëve të ndjekjes gjithashtu duhet të përcaktohet në flagat e nisjes së envoy proxy, për shembull: --zipkinAddress tracing-collector.tracing:9411
Mali i gabimeve numër dy: ne mund të marrim në mënyrë të lirë të gjitha ndjekjet e kalimeve të kërkesave në sistem nga kutia
Fatkeqësisht, nuk është kështu. Kompleksiteti i zbatimit varet nga mënyra se si e keni implementuar tashmë ndërveprimin midis shërbimeve. Pse kështu?
Ka tĂ« bĂ«jĂ« me faktin se pĂ«r tĂ« kuptuar istio-proxy se si pĂ«rputhen kĂ«rkesat hyrĂ«se me ato dalĂ«se nga i njĂ«jti shĂ«rbim, nuk mjafton thjesht tĂ« kapni tĂ« gjithĂ« trafikun. Duhet tĂ« keni njĂ« identifikues lidhjeje. NĂ« HTTP, envoy proxy pĂ«rdor ŰčÙÙŰ§Ù tĂ« veçantĂ«, me tĂ« cilat envoy kupton se cila kĂ«rkesĂ« e veçantĂ« pĂ«r shĂ«rbimin gjeneron kĂ«rkesa tĂ« caktuara nĂ« shĂ«rbime tĂ« tjera. Lista e kĂ«tyre ŰčÙÙۧÙeve Ă«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 themelor në të cilin mund të shtoni një logjikë të tillë, atëherë gjithçka është në rregull, ju thjesht duhet të prisni për përditësimin e kësaj biblioteke te të gjithë klientët. Por nëse keni një sistem shumë heterogjen dhe nuk ka unifikim në kalimin nga shërbimi në shërbim në rrjet, atëherë kjo ndoshta do të jetë një problem i madh. Pa shtuar një logjikë të tillë, të gjitha informacionet e ndjekjes do të jenë vetëm "në një nivel". Pra, do të marrim të gjitha ndërveprimet ndërshërbimore, por ato nuk do të jenë të ndërlidhura në zinxhirë të njëjtë kalimi nëpër rrjet.
PĂ«rfundim
Istio ofron një mjet të dobishëm për mbledhjen e informacionit të ndjekjes në rrjet, por është e rëndësishme të kuptohet se për zbatimin e tij është e nevojshme të përshtatet sistemi dhe të merren parasysh veçoritë e implementimit të Istio. Në fund, duhet të zgjidhen dy çështje kryesore: përcaktimi i protokollit të nivelit të aplikacionit (i cili duhet të mbështetet nga envoy proxy) dhe konfigurimi i kalimit të informacionit për lidhjen e kërkesave mes shërbimeve përmes header-ave, në rastin e protokollit HTTP. Kur këto çështje janë zgjidhur, ne fitojmë një mjet të fuqishëm që lejon mbledhjen e informacionit në mënyrë të qartë në rrjet edhe në sisteme shumë heterogjene, të shkruara në 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 â konsumimin e lartĂ« tĂ« memories nga çdo kontenier proxy sidecar dhe do tĂ« diskutojmĂ« si mund tĂ« merremi me kĂ«tĂ« problem.
Burimi: habr.com
