Azkenean Service Mesh Istio-ren oinarrizko osagaiak aztertu, sistema ezagutu eta Istiorekin lanean hastean sortzen diren galdera nagusiei erantzun diegu. Zati honetan sare batean trazatzeko informazioaren bilketa nola antolatu aztertuko dugu.
Garatzaile eta sistema administratzaile askori burura etortzen zaien lehenengo gauza Service Mesh hitzak entzutean trazatzen ari da. Izan ere, TCP trafiko guztia pasatzen den sareko nodo bakoitzari proxy zerbitzari berezi bat gehitzen diogu. Badirudi orain posible dela sareko sareko interakzio guztiei buruzko informazioa erraz bidaltzea. Zoritxarrez, errealitatean asko dira kontuan hartu beharreko Γ±abardurak. Ikus ditzagun.
Zenbaki okerra: lineako mendi-ibilaldien datuak doan lor ditzakegu.
Izan ere, nahiko dohainik, gure sistemaren nodoak gezien bidez eta zerbitzuen artean pasatzen den datu-tasa soilik lor ditzakegu (hain zuzen ere, denbora-unitate bakoitzeko byte kopurua bakarrik). Hala ere, kasu gehienetan, gure zerbitzuak aplikazio-geruzako protokoloren baten bidez komunikatzen dira, hala nola HTTP, gRPC, Redis eta abar. Eta, noski, protokolo hauetarako bereziki trazatzeko informazioa ikusi nahi dugu; eskaera-tasa ikusi nahi dugu, ez datu-tasa. Eskaeren latentzia ulertu nahi dugu gure protokoloa erabiliz. Azkenik, eskaera batek gure sisteman saioa hasten denetik erabiltzailearen erantzuna jaso arte hartzen duen bide osoa ikusi nahi dugu. Arazo hau jada ez da hain erraza konpontzen.
Lehenik eta behin, ikus dezagun nolakoa den trazadura bidaltzeko tarteak Istioren ikuspuntu arkitektonikotik. Lehen zatitik gogoratzen dugunez, Istiok telemetria biltzeko Mixer izeneko osagai bereizia du. Hala ere, oraingo 1.0.* bertsioan, bidalketa proxy zerbitzarietatik zuzenean egiten da, hots, envoy proxytik. Envoy proxy-ak zipkin protokoloa erabilita trazadura-tarteak bidaltzea onartzen du. Beste protokolo batzuk konektatu daitezke, baina plugin baten bidez soilik. Istio-rekin berehala lortzen dugu muntatutako eta konfiguratutako envoy proxy bat, zipkin protokoloa soilik onartzen duena. Adibidez, Jaeger protokoloa erabili eta UDP bidez trazadura-tarteak bidali nahi baditugu, orduan gure istio-proxy irudia eraiki beharko dugu. Istio-proxyrako plugin pertsonalizatuetarako laguntza dago, baina oraindik alfa bertsioan dago. Hori dela eta, ezarpen pertsonalizatu kopuru handirik gabe egin nahi badugu, trazadura-tarteak gordetzeko eta jasotzeko erabiltzen diren teknologien aukera murriztu egiten da. Sistema nagusietatik, hain zuzen ere, orain Zipkin bera edo Jaeger erabil dezakezu, baina hara bidali dena zipkin bateragarria den protokoloa erabiliz (askoz eraginkorragoa dena). Zipkin protokoloak berak biltzaileei trazadura-informazio guztia bidaltzea dakar HTTP protokoloaren bidez, eta hori nahiko garestia da.
Lehen esan dudan bezala, aplikazio-mailako protokoloak trazatu nahi ditugu. Horrek esan nahi du zerbitzu bakoitzaren ondoan dauden proxy zerbitzariek ulertu behar dutela zer nolako elkarrekintza gertatzen ari den orain. Lehenespenez, Istio-k ataka guztiak TCP arrunta izateko konfiguratzen ditu, hau da, ez da arrastorik bidaliko. Aztarnak bidaltzeko, lehenik eta behin, aukera hau gaitu behar duzu sarearen konfigurazio nagusian eta, oso garrantzitsua dena, kubernetes zerbitzuko entitateen ataka guztiak izendatu behar dituzu zerbitzuan erabiltzen den protokoloaren arabera. Hau da, adibidez, honela:
apiVersion: v1
kind: Service
metadata:
name: nginx
spec:
ports:
- port: 80
targetPort: 80
name: http
selector:
app: nginxhttp-magic bezalako izen konposatuak ere erabil ditzakezu (Istio-k http ikusiko du eta ataka hori http amaierako puntu gisa ezagutuko du). Formatua hau da: proto-extra.
Protokoloa zehazteko konfigurazio kopuru handirik ez adabakitzeko, konponbide zikin bat erabil dezakezu: parkatu Pilot osagaia besterik ez den momentuan. . Azkenean, noski, beharrezkoa izango da logika hori estandarrera aldatu eta portu guztien izendapen-konbentzio batera aldatzea.
Protokoloa behar bezala definitu den ala ez ulertzeko, envoy proxydun alboko edukiontzietan sartu behar duzu eta eskaera egin behar duzu envoy interfazeko administratzaile portuan kokapena /config_dump-rekin. Ondorioz, konfigurazioan, nahi duzun zerbitzuaren funtzionamendu-eremua begiratu behar duzu. Istio-n eskaera egiten den identifikatzaile gisa erabiltzen da. Istio-n parametro honen balioa pertsonalizatzeko (gero gure trazamendu sisteman ikusiko dugu), beharrezkoa da serviceCluster bandera zehaztu behar da sidecar edukiontzia abiarazteko fasean. Adibidez, honela kalkula daiteke beheranzko kubernetes APItik lortutako aldagaietatik:
--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')
Adibide ona envoy-en trazadura nola funtzionatzen duen ulertzeko .
Trazadura-tarteak bidaltzeko amaiera-puntua bera ere zehaztu behar da envoy proxy abiarazte-marketan, adibidez: --zipkinAddress tracing-collector.tracing:9411
Bigarren uste okerra: sistemaren bidez merke lor ditzakegu eskaeren aztarna osoa
Zoritxarrez, ez da. Ezarpenaren konplexutasuna zerbitzuen elkarrekintza dagoeneko inplementatu duzunaren araberakoa da. Zergatik da hori?
Izan ere, istio-proxy-k zerbitzu batera sartzen diren eskaeren korrespondentzia zerbitzu bera uzten dutenekin ulertu ahal izateko, ez dela nahikoa trafiko guztia atzematea besterik gabe. Komunikazio-identifikatzaile moduko bat izan behar duzu. HTTP envoy proxy-ak goiburu bereziak erabiltzen ditu, eta, horren bidez, zerbitzuaren eskaera zehatzak beste zerbitzu batzuetarako eskaera zehatzak sortzen dituen ulertzen du. Horrelako goiburuen zerrenda:
- x-request-id,
- x-b3-traceid,
- x-b3-spanid,
- x-b3-guraso espainiarra,
- x-b3-laginak,
- x-b3-bandak,
- x-ot-span-testuingurua.
Puntu bakarra baduzu, adibidez, oinarrizko bezero bat, zeinetan logika hori gehi dezakezun, orduan dena ondo dago, liburutegi hau bezero guztientzat eguneratu arte itxaron behar duzu. Baina sistema oso heterogeneoa baduzu eta sarearen bidez zerbitzu batetik zerbitzura igarotzean bateratzerik ez badago, ziurrenik arazo handia izango da. Logika hori gehitu gabe, trazatzeko informazio guztia "maila bakarrekoa" izango da. Hau da, zerbitzuen arteko elkarrekintza guztiak jasoko ditugu, baina ez dira sarean zehar igarotzeko kate bakarrean itsatsiko.
Ondorioa
Istio-k tresna erosoa eskaintzen du sare batean trazatzeko informazioa biltzeko, baina ulertu behar duzu inplementatzeko zure sistema egokitu beharko duzula eta Istio inplementazioaren ezaugarriak kontuan hartu behar dituzula. Ondorioz, bi puntu nagusi konpondu behar dira: aplikazio-mailako protokoloa zehaztea (envoy proxy-ak onartu behar duena) eta zerbitzuaren eskaeren zerbitzura konektatzeari buruzko informazioa bidaltzea konfiguratzea (goiburuak erabiliz). , HTTP protokoloaren kasuan). Arazo horiek konpontzen direnean, sareko informazioa gardentasunez biltzeko aukera ematen duen tresna indartsu bat dugu, baita hizkuntza eta esparru askotan idatzitako sistema oso heterogeneoetan ere.
Service Mesh-i buruzko hurrengo artikuluan, Istio-ren arazo handienetako bat aztertuko dugu - sidecar proxy edukiontzi bakoitzak RAMaren kontsumo handia eta horri nola aurre egin dezakezun eztabaidatuko dugu.
Iturria: www.habr.com