Viimases Tutvusime Service Mesh Istio põhikomponentidega, tutvusime süsteemiga ja vastasime peamistele küsimustele, mis tavaliselt Istioga tööle asudes tekivad. Selles osas vaatleme, kuidas korraldada jälgimisteabe kogumist võrgu kaudu.
Esimene asi, mis paljudele arendajatele ja süsteemiadministraatoritele sõnu Service Mesh kuuldes meelde tuleb, on jälitamine. Tõepoolest, lisame igale võrgusõlmele, mida kogu TCP-liiklus läbib, spetsiaalse puhverserveri. Tundub, et nüüd on võimalik hõlpsasti saata teavet kõigi võrgu interaktsioonide kohta võrgus. Kahjuks on tegelikkuses palju nüansse, millega tuleb arvestada. Vaatame neid.
Väärarusaam number üks: saame veebist matkaandmed tasuta.
Tegelikult saame suhteliselt tasuta oma süsteemi sõlmed ühendada ainult noolte ja teenuste vahel liikuva andmeedastuskiirusega (tegelikult ainult baitide arv ajaühikus). Kuid enamikul juhtudel suhtlevad meie teenused mingisuguse rakenduskihi protokolli kaudu, nagu HTTP, gRPC, Redis jne. Ja loomulikult tahame näha jälgimisteavet spetsiaalselt nende protokollide jaoks; tahame näha päringu kiirust, mitte andmeedastuskiirust. Soovime oma protokolli kasutades mõista päringute latentsust. Lõpuks tahame näha täielikku teed, mida päring läbib meie süsteemi sisselogimisest kuni kasutajalt vastuse saamiseni. Seda probleemi pole enam nii lihtne lahendada.
Kõigepealt vaatame, kuidas näeb välja saatmise jälgimisulatus Istio arhitektuurilisest vaatenurgast. Nagu esimesest osast mäletame, on Istiol telemeetria kogumiseks eraldi komponent nimega Mixer. Praeguses versioonis 1.0.* aga toimub saatmine otse puhverserveritelt, nimelt saadiku puhverserverilt. Envoy puhverserver toetab zipkin-protokolli abil jälgimisvahemike saatmist. Võimalik on ühendada ka teisi protokolle, kuid ainult pistikprogrammi kaudu. Istioga saame kohe kokku pandud ja konfigureeritud envoy puhverserveri, mis toetab ainult zipkini protokolli. Kui tahame kasutada näiteks Jaegeri protokolli ja saata jälgimisvahemikke UDP kaudu, siis peame looma oma istio-puhverserveri kujutise. Istio-puhverserveri kohandatud pistikprogrammide tugi on olemas, kuid see on endiselt alfaversioonis. Seega, kui soovime ilma suure hulga kohandatud säteteta hakkama saada, vähendatakse jälgimisvahemike salvestamiseks ja vastuvõtmiseks kasutatavate tehnoloogiate valikut. Põhisüsteemidest saab nüüd tegelikult kasutada Zipkinit ennast ehk Jaegerit, kuid sinna saata kõik zipkiniga ühilduva protokolli abil (mis on palju vähem tõhus). Zipkini protokoll ise hõlmab kogu jälgimisteabe saatmist kogujatele HTTP-protokolli kaudu, mis on üsna kallis.
Nagu ma juba ütlesin, tahame jälgida rakendustaseme protokolle. See tähendab, et iga teenuse kõrval seisvad puhverserverid peavad mõistma, milline suhtlus praegu toimub. Vaikimisi konfigureerib Istio kõik pordid tavaliseks TCP-ks, mis tähendab, et jälgi ei saadeta. Jälgede saatmiseks peate esmalt lubama selle valiku põhivõrgu konfiguratsioonis ja, mis on väga oluline, nimetama kõik kubernetese teenuse olemite pordid vastavalt teenuses kasutatavale protokollile. See on näiteks selline:
apiVersion: v1
kind: Service
metadata:
name: nginx
spec:
ports:
- port: 80
targetPort: 80
name: http
selector:
app: nginxVõite kasutada ka liitnimesid, nagu http-magic (Istio näeb http-d ja tunneb selle pordi ära http-lõpp-punktina). Formaat on: proto-extra.
Selleks, et mitte parandada protokolli määramiseks tohutul hulgal konfiguratsioone, võite kasutada räpast lahendust: paika panna pilootkomponent hetkel, kui see on lihtsalt . Lõpuks on muidugi vaja see loogika muuta standardseks ja minna üle kõigi portide nimetamistavale.
Selleks, et mõista, kas protokoll on tõesti õigesti määratletud, peate sisenema saadiku puhverserveriga mis tahes külgkorvi konteinerisse ja esitama päringu saatjaliidese administraatoripordile asukohaga /config_dump. Saadud konfiguratsioonis peate vaatama soovitud teenuse töövälja. Seda kasutatakse Istios päringu esitamise koha identifikaatorina. Selle parameetri väärtuse kohandamiseks Istios (näeme seda siis oma jälgimissüsteemis) on vaja külgkorvi konteineri käivitamise etapis määrata serviceCluster lipp. Näiteks saab selle arvutada allapoole suunatud kubernetes API-st saadud muutujate põhjal:
--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')
Hea näide, et mõista, kuidas jälgimine saadiku juures toimib .
Jälgimisvahemike saatmise lõpp-punkt ise tuleb samuti määrata saadiku puhverserveri käivituslippudes, näiteks: --zipkinAddress tracing-collector.tracing:9411
Väärarusaam number kaks: me saame odavalt hankida taotluste täielikud jäljed süsteemi kaudu karbist välja
Kahjuks ei ole. Rakendamise keerukus sõltub sellest, kuidas olete teenuste koostoime juba rakendanud. Miks nii?
Fakt on see, et selleks, et istio-puhverserver saaks aru teenusele sissetulevate päringute vastavusest samast teenusest lahkujatega, ei piisa lihtsalt kogu liikluse pealtkuulamisest. Teil peab olema mingi suhtlusidentifikaator. HTTP saadiku puhverserver kasutab spetsiaalseid päiseid, mille abil saadik mõistab, milline konkreetne taotlus teenusele genereerib konkreetseid päringuid teistele teenustele. Selliste päiste loend:
- x-päringu ID,
- x-b3-traceid,
- x-b3-spanid,
- x-b3-parentsspanid,
- x-b3-proovitud,
- x-b3-lipud,
- x-ot-span-kontekst.
Kui teil on üksainus punkt, näiteks põhiklient, kuhu saate sellist loogikat lisada, siis on kõik korras, peate lihtsalt ootama, kuni see teegi kõigi klientide jaoks värskendatakse. Kuid kui teil on väga heterogeenne süsteem ja võrgu kaudu teenuselt teenusele liikumisel puudub ühtlus, on see tõenäoliselt suur probleem. Ilma sellist loogikat lisamata on kogu jälgimisteave ainult "ühetasandiline". See tähendab, et me saame kõik teenustevahelised suhtlused, kuid neid ei liimita üksikuteks võrgu läbimise ahelateks.
Järeldus
Istio pakub mugavat tööriista võrgu kaudu jälgimisteabe kogumiseks, kuid peate mõistma, et juurutamiseks peate oma süsteemi kohandama ja võtma arvesse Istio juurutuse funktsioone. Sellest tulenevalt tuleb lahendada kaks peamist punkti: rakendustaseme protokolli määratlemine (mida peab toetama saadiku puhverserver) ja teenuse päringutest teenusega ühendamise kohta teabe edastamise seadistamine (päiste abil). , HTTP-protokolli puhul). Kui need probleemid on lahendatud, on meil võimas tööriist, mis võimaldab läbipaistvalt koguda võrgust teavet isegi väga heterogeensetes süsteemides, mis on kirjutatud paljudes erinevates keeltes ja raamistikes.
Järgmises Service Meshi käsitlevas artiklis vaatleme Istio üht suurimat probleemi – iga külgkorvi puhverserveri konteineri suurt RAM-i tarbimist ja arutame, kuidas sellega toime tulla.
Allikas: www.habr.com
