Istio dhe Kubernetes në prodhim. Pjesa 2. Gjurmimi

Në të fundit artikull Ne shikuam komponentët bazë të Service Mesh Istio, u njohëm me sistemin dhe iu përgjigjëm pyetjeve kryesore që lindin zakonisht kur filloni të punoni me Istio. Në këtë pjesë do të shikojmë se si të organizojmë mbledhjen e informacionit gjurmues në një rrjet.

Gjëja e parë që u vjen në mendje shumë zhvilluesve dhe administratorëve të sistemit kur dëgjojnë fjalët Service Mesh është gjurmimi. Në të vërtetë, ne shtojmë një server të veçantë proxy në secilën nyje të rrjetit përmes të cilit kalon i gjithë trafiku TCP. Duket se tani është e mundur të dërgoni me lehtësi informacion për të gjitha ndërveprimet e rrjetit në rrjet. Fatkeqësisht, në realitet ka shumë nuanca që duhet të merren parasysh. Le t'i shikojmë ato.

Keqkuptimi numër një: ne mund të marrim të dhëna për ecjen në internet falas.

Në fakt, relativisht falas, ne mund të lidhim vetëm nyjet e sistemit tonë me shigjeta dhe shpejtësinë e të dhënave që kalon ndërmjet shërbimeve (në fakt, vetëm numrin e bajteve për njësi të kohës). Megjithatë, në shumicën e rasteve, shërbimet tona komunikojnë përmes një lloj protokolli të shtresës së aplikimit, si HTTP, gRPC, Redis, etj. Dhe, sigurisht, ne duam të shohim informacionin e gjurmimit posaçërisht për këto protokolle; ne duam të shohim shkallën e kërkesës, jo shkallën e të dhënave. Ne duam të kuptojmë vonesën e kërkesave duke përdorur protokollin tonë. Së fundi, ne duam të shohim rrugën e plotë që kërkon një kërkesë nga hyrja në sistemin tonë deri në marrjen e një përgjigje nga përdoruesi. Ky problem nuk është më aq i lehtë për t'u zgjidhur.

Së pari, le të shohim se si duken hapësirat e gjurmimit të dërgimit nga një këndvështrim arkitektonik në Istio. Siç kujtojmë nga pjesa e parë, Istio ka një komponent të veçantë të quajtur Mixer për mbledhjen e telemetrisë. Megjithatë, në versionin aktual 1.0.*, dërgimi bëhet drejtpërdrejt nga serverët proxy, përkatësisht nga përfaqësuesi i dërguar. Përfaqësuesi i Envoy mbështet dërgimin e hapësirave të gjurmimit duke përdorur protokollin zipkin jashtë kutisë. Është e mundur të lidhni protokolle të tjera, por vetëm përmes një plugin. Me Istio ne marrim menjëherë një përfaqësues të deleguar të montuar dhe të konfiguruar, i cili mbështet vetëm protokollin zipkin. Nëse duam të përdorim, për shembull, protokollin Jaeger dhe të dërgojmë hapësira gjurmuese përmes UDP, atëherë do të na duhet të ndërtojmë imazhin tonë istio-proxy. Ekziston mbështetje për shtojcat e personalizuara për istio-proxy, por është ende në versionin alfa. Prandaj, nëse duam të bëjmë pa një numër të madh cilësimesh të personalizuara, gama e teknologjive të përdorura për ruajtjen dhe marrjen e hapësirave të gjurmimit zvogëlohet. Nga sistemet kryesore, në fakt, tani mund të përdorni vetë Zipkin, ose Jaeger, por dërgoni gjithçka atje duke përdorur protokollin e pajtueshëm me zipkin (i cili është shumë më pak efikas). Vetë protokolli zipkin përfshin dërgimin e të gjithë informacionit të gjurmimit te mbledhësit nëpërmjet protokollit HTTP, i cili është mjaft i shtrenjtë.

Siç thashë tashmë, ne duam të gjurmojmë protokollet e nivelit të aplikacionit. Kjo do të thotë që serverët proxy që qëndrojnë pranë secilit shërbim duhet të kuptojnë se çfarë lloj ndërveprimi po ndodh tani. Si parazgjedhje, Istio konfiguron të gjitha portet të jenë TCP të thjeshtë, që do të thotë se nuk do të dërgohen gjurmë. Në mënyrë që gjurmët të dërgohen, së pari duhet ta aktivizoni këtë opsion në konfigurimin e rrjetës kryesore dhe, çka është shumë e rëndësishme, të emërtoni të gjitha portet e entiteteve të shërbimit kubernetes në përputhje me protokollin që përdoret në shërbim. Kjo është, për shembull, si kjo:

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - port: 80
    targetPort: 80
    name: http
  selector:
    app: nginx

Ju gjithashtu mund të përdorni emra të përbërë si http-magic (Istio do të shohë http dhe do ta njohë atë port si një pikë fundore http). Formati është: proto-ekstra.

Për të mos korrigjuar një numër të madh konfigurimesh për të përcaktuar protokollin, mund të përdorni një zgjidhje të ndyrë: rregulloni komponentin Pilot në momentin kur është vetëm kryen logjikën e përkufizimit të protokollit. Në fund, natyrisht, do të jetë e nevojshme të ndryshohet kjo logjikë në standarde dhe të kalohet në një konventë emërtimi për të gjitha portet.

Në mënyrë që të kuptoni nëse protokolli është vërtetuar saktë, duhet të futeni në cilindo nga kontejnerët anësor me përfaqësues të dërguarit dhe të bëni një kërkesë në portin e administratorit të ndërfaqes së të dërguarit me vendndodhjen /config_dump. Në konfigurimin që rezulton, duhet të shikoni fushën e funksionimit të shërbimit të dëshiruar. Përdoret në Istio si identifikues për vendin ku bëhet kërkesa. Për të personalizuar vlerën e këtij parametri në Istio (më pas do ta shohim në sistemin tonë të gjurmimit), është e nevojshme të specifikoni flamurin e shërbimit Cluster në fazën e lëshimit të kontejnerit të karriges anësore. Për shembull, mund të llogaritet kështu nga variablat e marra nga API kubernetes në rënie:

--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 gjurmimi në të dërguarin këtu.

Vetë pika përfundimtare për dërgimin e hapësirave të gjurmimit duhet të specifikohet gjithashtu në flamujt e nisjes së përfaqësuesit të të dërguarit, për shembull: --zipkinAddress tracing-collector.tracing:9411

Keqkuptimi numër dy: ne mund të marrim me çmim të lirë gjurmë të plota të kërkesave përmes sistemit jashtë kutisë

Fatkeqësisht, nuk është kështu. Kompleksiteti i zbatimit varet nga mënyra se si e keni zbatuar tashmë ndërveprimin e shërbimeve. Pse eshte ajo?

Fakti është se në mënyrë që istio-proxy të jetë në gjendje të kuptojë korrespondencën e kërkesave hyrëse në një shërbim me ata që largohen nga i njëjti shërbim, nuk mjafton thjesht të përgjohet i gjithë trafiku. Duhet të keni një lloj identifikuesi komunikimi. Përfaqësuesi i HTTP-së përdor tituj të veçantë, me anë të të cilëve i dërguari kupton se cila kërkesë specifike për shërbimin gjeneron kërkesa specifike për shërbime të tjera. Lista e titujve të tillë:

• x-kërkesa-id
• x-b3-traceid,
• x-b3-spanid,
• x-b3-parentspanid,
• x-b3-kampionuar,
• x-b3-flamuj,
• x-ot-span-kontekst.

Nëse keni një pikë të vetme, për shembull, një klient bazë, në të cilin mund të shtoni një logjikë të tillë, atëherë gjithçka është në rregull, thjesht duhet të prisni që kjo bibliotekë të përditësohet për të gjithë klientët. Por nëse keni një sistem shumë heterogjen dhe nuk ka unifikim në lëvizjen nga shërbimi në shërbim përmes rrjetit, atëherë me shumë mundësi ky do të jetë një problem i madh. Pa shtuar një logjikë të tillë, të gjitha informacionet e gjurmimit do të jenë vetëm "të një niveli". Kjo do të thotë, ne do të marrim të gjitha ndërveprimet ndër-shërbimesh, por ato nuk do të ngjiten në zinxhirë të vetëm kalimi përmes rrjetit.

Përfundim

Istio ofron një mjet të përshtatshëm për mbledhjen e informacionit të gjurmimit përmes një rrjeti, por duhet të kuptoni se për zbatimin do t'ju duhet të përshtatni sistemin tuaj dhe të merrni parasysh veçoritë e zbatimit të Istio. Si rezultat, duhet të zgjidhen dy pika kryesore: përcaktimi i protokollit të nivelit të aplikimit (i cili duhet të mbështetet nga përfaqësuesi i të dërguarit) dhe vendosja e përcjelljes së informacionit në lidhje me lidhjen e kërkesave me shërbimin nga kërkesat nga shërbimi (duke përdorur titujt , në rastin e protokollit HTTP). Kur këto çështje zgjidhen, ne kemi një mjet të fuqishëm që na lejon të mbledhim në mënyrë transparente informacionin nga rrjeti, madje edhe në sisteme shumë heterogjene të shkruara në shumë gjuhë dhe korniza të ndryshme.

Në artikullin tjetër në lidhje me Service Mesh, ne do të shikojmë një nga problemet më të mëdha me Istio - konsumin e madh të RAM-it nga çdo kontejner proxy sidecar dhe do të diskutojmë se si mund ta trajtoni atë.

Burimi: www.habr.com