In die laaste Ons het na die basiese komponente van Service Mesh Istio gekyk, met die stelsel kennis gemaak en die hoofvrae beantwoord wat gewoonlik opduik wanneer jy met Istio begin werk. In hierdie deel sal ons kyk hoe om die versameling van opsporingsinligting oor 'n netwerk te organiseer.
Die eerste ding wat vir baie ontwikkelaars en stelseladministrateurs in gedagte kom wanneer hulle die woorde hoor wat Service Mesh is opsporing. Inderdaad, ons voeg 'n spesiale instaanbediener by elke netwerknodus waardeur alle TCP-verkeer gaan. Dit blyk dat dit nou moontlik is om inligting oor alle netwerkinteraksies op die netwerk maklik te stuur. Ongelukkig is daar in werklikheid baie nuanses wat in ag geneem moet word. Kom ons kyk na hulle.
Wanopvatting nommer een: ons kan aanlyn stapdata gratis kry.
Trouens, vir relatief gratis kan ons net die nodusse van ons stelsel verbind kry deur pyle en die datatempo wat tussen dienste verbygaan (in werklikheid slegs die aantal grepe per tydseenheid). In die meeste gevalle kommunikeer ons dienste egter oor 'n soort toepassingslaagprotokol, soos HTTP, gRPC, Redis, ensovoorts. En natuurlik wil ons spoorinligting spesifiek vir hierdie protokolle sien; ons wil die versoekkoers sien, nie die datatempo nie. Ons wil die vertraging van versoeke verstaan deur ons protokol te gebruik. Ten slotte wil ons die volle pad sien wat 'n versoek neem vanaf die aanmelding by ons stelsel tot die ontvangs van 'n antwoord van die gebruiker. Hierdie probleem is nie meer so maklik om op te los nie.
Kom ons kyk eers na hoe die versending van naspeurspanne lyk vanuit 'n argitektoniese oogpunt in Istio. Soos ons van die eerste deel onthou, het Istio 'n aparte komponent genaamd Mixer vir die insameling van telemetrie. In die huidige weergawe 1.0.* word versending egter direk vanaf instaanbedieners gedoen, naamlik van gesant-instaanbediener. Envoy-instaanbediener ondersteun die stuur van opsporingspanne met die zipkin-protokol uit die boks. Dit is moontlik om ander protokolle te koppel, maar slegs deur 'n inprop. Met Istio kry ons dadelik 'n saamgestelde en gekonfigureerde gesant-instaanbediener, wat slegs die zipkin-protokol ondersteun. As ons byvoorbeeld die Jaeger-protokol wil gebruik en nasporingspanne via UDP wil stuur, sal ons ons eie istio-proxy-beeld moet bou. Daar is ondersteuning vir pasgemaakte plugins vir istio-proxy, maar dit is steeds in die alfa-weergawe. As ons dus sonder 'n groot aantal persoonlike instellings wil klaarkom, word die reeks tegnologieë wat gebruik word vir die berging en ontvangs van opsporingsspanne verminder. Van die hoofstelsels kan jy nou eintlik Zipkin self, of Jaeger, gebruik, maar alles daarheen stuur met behulp van die zipkin-versoenbare protokol (wat baie minder doeltreffend is). Die zipkin-protokol self behels die stuur van alle opsporingsinligting aan versamelaars via die HTTP-protokol, wat redelik duur is.
Soos ek reeds gesê het, wil ons protokolle op toepassingsvlak opspoor. Dit beteken dat die instaanbedieners wat langs elke diens staan, moet verstaan watter soort interaksie nou plaasvind. By verstek stel Istio alle poorte op om gewone TCP te wees, wat beteken dat geen spore gestuur sal word nie. Om spore te stuur, moet jy eerstens hierdie opsie in die hoofnetwerkopstelling aktiveer en, wat baie belangrik is, alle poorte van kubernetes-diensentiteite benoem in ooreenstemming met die protokol wat in die diens gebruik word. Dit is byvoorbeeld so:
apiVersion: v1
kind: Service
metadata:
name: nginx
spec:
ports:
- port: 80
targetPort: 80
name: http
selector:
app: nginxJy kan ook saamgestelde name soos http-magic gebruik (Istio sal http sien en daardie poort as 'n http-eindpunt herken). Die formaat is: proto-ekstra.
Om nie 'n groot aantal konfigurasies te pleister om die protokol te bepaal nie, kan u 'n vuil oplossing gebruik: pleister die Pilot-komponent op die oomblik wanneer dit net is . Op die ou end sal dit natuurlik nodig wees om hierdie logika na standaard te verander en oor te skakel na 'n naamkonvensie vir alle poorte.
Om te verstaan of die protokol werklik korrek gedefinieer is, moet jy in enige van die syspanhouers met gesant-instaanbediener gaan en 'n versoek rig aan die administrasiepoort van die gesant-koppelvlak met ligging /config_dump. In die gevolglike konfigurasie moet u na die operasieveld van die verlangde diens kyk. Dit word in Istio gebruik as 'n identifiseerder vir waar die versoek gedoen word. Om die waarde van hierdie parameter in Istio aan te pas (ons sal dit dan in ons opsporingstelsel sien), is dit nodig om die serviceCluster-vlag te spesifiseer tydens die begin van die syspanhouer. Byvoorbeeld, dit kan soos volg bereken word uit veranderlikes verkry vanaf die afwaartse kubernetes API:
--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')
'n Goeie voorbeeld om te verstaan hoe opsporing in envoy werk, is .
Die eindpunt self vir die stuur van opsporingspanne moet ook gespesifiseer word in die gesant-volmagbekendstellingsvlae, byvoorbeeld: --zipkinAddress tracing-collector.tracing:9411
Wanopvatting nommer twee: ons kan goedkoop volledige spore van versoeke deur die stelsel uit die boks kry
Ongelukkig is dit nie. Die kompleksiteit van implementering hang af van hoe jy reeds die interaksie van dienste geïmplementeer het. Hoekom is dit?
Die feit is dat dit nie genoeg is om bloot alle verkeer te onderskep sodat istio-proxy die korrespondensie van inkomende versoeke na 'n diens met diegene wat dieselfde diens verlaat, kan verstaan nie. Jy moet 'n soort kommunikasie-identifiseerder hê. HTTP-gesant-instaanbediener gebruik spesiale opskrifte, waardeur gesant verstaan watter spesifieke versoek aan die diens spesifieke versoeke na ander dienste genereer. Lys van sulke opskrifte:
- x-versoek-ID,
- x-b3-spoor,
- x-b3-spanid,
- x-b3-parentspanid,
- x-b3-steekproef,
- x-b3-vlae,
- x-ot-span-konteks.
As jy 'n enkele punt het, byvoorbeeld 'n basiese kliënt, waarin jy sulke logika kan byvoeg, dan is alles in orde, jy moet net wag dat hierdie biblioteek vir alle kliënte opgedateer word. Maar as jy 'n baie heterogene stelsel het en daar is geen eenwording om van diens tot diens oor die netwerk te beweeg nie, dan sal dit heel waarskynlik 'n groot probleem wees. Sonder om sulke logika by te voeg, sal alle opsporingsinligting slegs "enkelvlak" wees. Dit wil sê, ons sal alle inter-diens interaksies ontvang, maar hulle sal nie in enkele kettings van deurgang deur die netwerk vasgeplak word nie.
Gevolgtrekking
Istio bied 'n gerieflike hulpmiddel vir die insameling van opsporingsinligting oor 'n netwerk, maar jy moet verstaan dat jy vir implementering jou stelsel sal moet aanpas en die kenmerke van die Istio-implementering in ag moet neem. Gevolglik moet twee hoofpunte opgelos word: die definisie van die toepassingsvlakprotokol (wat deur die gesant-gevolmagtigde ondersteun moet word) en die opstel van die aanstuur van inligting oor die verbinding van versoeke aan die diens vanaf versoeke van die diens (met behulp van kopskrifte , in die geval van die HTTP-protokol). Wanneer hierdie kwessies opgelos is, het ons 'n kragtige instrument wat ons in staat stel om inligting deursigtig van die netwerk in te samel, selfs in baie heterogene stelsels wat in baie verskillende tale en raamwerke geskryf is.
In die volgende artikel oor Service Mesh, sal ons kyk na een van die grootste probleme met Istio – die groot verbruik van RAM deur elke sidecar-instaanbedienerhouer en bespreek hoe jy dit kan hanteer.
Bron: will.com