Yn de lêste Wy seagen nei de basiskomponinten fan Service Mesh Istio, makken kunde mei it systeem en beantwurde de wichtichste fragen dy't normaal ûntsteane as jo begjinne te wurkjen mei Istio. Yn dit diel sille wy sjen nei hoe't jo de kolleksje fan tracing-ynformaasje organisearje oer in netwurk.
It earste ding dat in protte ûntwikkelders en systeembehearders yn 't sin komt as se de wurden hearre Service Mesh is tracing. Yndied foegje wy in spesjale proxy-tsjinner ta oan elke netwurkknooppunt dêr't alle TCP-ferkear troch giet. It liket derop dat it no mooglik is om maklik ynformaasje te stjoeren oer alle netwurk ynteraksjes op it netwurk. Spitigernôch, yn 'e realiteit binne d'r in protte nuânses dy't rekken holden wurde moatte. Litte wy nei se sjen.
Misferstân nûmer ien: wy kinne fergees online kuiergegevens krije.
Yn feite, relatyf fergees, kinne wy allinich de knooppunten fan ús systeem krije ferbûn troch pylken en de gegevensrate dy't trochgiet tusken tsjinsten (yn feite allinich it oantal bytes per tiidienheid). Yn 'e measte gefallen kommunisearje ús tsjinsten lykwols oer in soarte fan applikaasjelaachprotokol, lykas HTTP, gRPC, Redis, ensfh. En, fansels, wolle wy spesifyk tracingynformaasje sjen foar dizze protokollen; wy wolle de oanfraachrate sjen, net de gegevensrate. Wy wolle de latency fan oanfragen begripe mei ús protokol. As lêste wolle wy it folsleine paad sjen dat in fersyk nimt fan it ynloggen op ús systeem oant it ûntfangen fan in antwurd fan de brûker. Dit probleem is net mear sa maklik op te lossen.
Litte wy earst sjen hoe't ferstjoeren fan tracing-spans der útsjocht út in arsjitektoanysk eachpunt yn Istio. As wy ûnthâlde fan it earste diel, hat Istio in aparte komponint neamd Mixer foar it sammeljen fan telemetry. Lykwols, yn de hjoeddeiske ferzje 1.0.*, ferstjoeren wurdt dien direkt fan proxy-tsjinners, nammentlik fan envoy proxy. Envoy-proxy stipet it ferstjoeren fan tracing-spannen mei it zipkin-protokol út 'e doaze. It is mooglik om oare protokollen te ferbinen, mar allinich fia in plugin. Mei Istio krije wy fuortendaliks in gearstalde en konfigureare envoy-proxy, dy't allinich it zipkin-protokol stipet. As wy bygelyks it Jaeger-protokol wolle brûke en tracing-spans fia UDP wolle stjoere, dan moatte wy ús eigen istio-proxyôfbylding bouwe. D'r is stipe foar oanpaste plugins foar istio-proxy, mar it is noch yn 'e alfa-ferzje. Dêrom, as wy wolle dwaan sûnder in grut oantal oanpaste ynstellings, it oanbod fan technologyen brûkt foar it opslaan en ûntfange tracing spans wurdt fermindere. Fan 'e wichtichste systemen kinne jo no Zipkin sels brûke, of Jaeger, mar stjoere alles dêr mei it zipkin-kompatibele protokol (wat folle minder effisjint is). It zipkin-protokol sels omfettet it ferstjoeren fan alle tracing-ynformaasje nei samlers fia it HTTP-protokol, wat frij djoer is.
Lykas ik al sei, wolle wy protokollen op applikaasjenivo trace. Dit betsjut dat de proxy-tsjinners dy't neist elke tsjinst steane moatte begripe hokker soarte fan ynteraksje no bart. Standert konfigurearret Istio alle havens om gewoane TCP te wêzen, wat betsjut dat gjin spoaren wurde ferstjoerd. Om spoaren te ferstjoeren, moatte jo earst dizze opsje ynskeakelje yn 'e haadmesh-konfiguraasje en, wat heul wichtich is, alle havens fan kubernetes-tsjinstentiteiten neame yn oerienstimming mei it protokol dat wurdt brûkt yn' e tsjinst. Dat is bygelyks sa:
apiVersion: v1
kind: Service
metadata:
name: nginx
spec:
ports:
- port: 80
targetPort: 80
name: http
selector:
app: nginxJo kinne ek gearstalde nammen brûke lykas http-magic (Istio sil http sjen en dy poarte werkenne as in http-einpunt). It formaat is: proto-ekstra.
Om net in grut oantal konfiguraasjes te patchjen om it protokol te bepalen, kinne jo in smoarge oplossing brûke: patch de Pilot-komponint op it momint dat it gewoan is . Op it lêst sil it fansels nedich wêze om dizze logika nei standert te feroarjen en te wikseljen nei in nammejouwing foar alle havens.
Om te begripen oft it protokol wirklik goed definiearre is, moatte jo yn ien fan 'e sidecar-konteners mei envoy-proxy gean en in fersyk meitsje oan de admin-poarte fan' e envoy-ynterface mei lokaasje /config_dump. Yn 'e resultearjende konfiguraasje moatte jo sjen nei it operaasjefjild fan' e winske tsjinst. It wurdt brûkt yn Istio as in identifier foar wêr't it fersyk wurdt dien. Om de wearde fan dizze parameter yn Istio oan te passen (wy sille it dan sjen yn ús tracingsysteem), is it nedich om de flagge fan 'e serviceCluster op te jaan yn' e poadium fan it lansearjen fan 'e sidecar-container. It kin bygelyks sa berekkene wurde fan fariabelen krigen fan 'e downward kubernetes API:
--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')
In goed foarbyld om te begripen hoe't tracing wurket yn envoy is .
It einpunt sels foar it ferstjoeren fan tracing-spannen moat ek spesifisearre wurde yn 'e lansearringflaggen fan 'e envoy proxy, bygelyks: --zipkinAddress tracing-collector.tracing:9411
Misferstân nûmer twa: wy kinne goedkeap folsleine spoaren fan oanfragen fia it systeem út 'e doaze krije
Spitigernôch is it net. De kompleksiteit fan ymplemintaasje hinget ôf fan hoe't jo de ynteraksje fan tsjinsten al hawwe ymplementearre. Wêrom is dat?
It feit is dat om istio-proxy de korrespondinsje fan ynkommende oanfragen nei in tsjinst te begripen mei dyjingen dy't deselde tsjinst ferlitte, is it net genôch om gewoan alle ferkear te ûnderskeppen. Jo moatte in soarte fan kommunikaasje-identifikaasje hawwe. HTTP-envoy-proxy brûkt spesjale kopteksten, wêrmei't gesant begrypt hokker spesifyk fersyk oan 'e tsjinst spesifike oanfragen genereart nei oare tsjinsten. List fan sokke kopteksten:
- x-request-id,
- x-b3-traceid,
- x-b3-spanid,
- x-b3-parentspanid,
- x-b3-sampled,
- x-b3-flaggen,
- x-ot-span-kontekst.
As jo ien punt hawwe, bygelyks in basiskliïnt, wêryn jo sokke logika kinne tafoegje, dan is alles goed, jo moatte gewoan wachtsje op dizze bibleteek om te aktualisearjen foar alle kliïnten. Mar as jo in heul heterogene systeem hawwe en d'r gjin ienwurding is yn it ferpleatsen fan tsjinst nei tsjinst oer it netwurk, dan sil dit nei alle gedachten in grut probleem wêze. Sûnder sa'n logika ta te foegjen, sil alle tracingynformaasje allinich "ien nivo" wêze. Dat is, wy sille ûntfange alle ynter-tsjinst ynteraksjes, mar se sille net wurde lijm yn inkele keatlingen fan passaazje troch it netwurk.
konklúzje
Istio biedt in handich ark foar it sammeljen fan tracing-ynformaasje oer in netwurk, mar jo moatte begripe dat jo foar ymplemintaasje jo systeem moatte oanpasse en rekken hâlde mei de funksjes fan 'e Istio-ymplemintaasje. Dêrtroch moatte twa haadpunten oplost wurde: it definiearjen fan it protokol foar tapassingsnivo (dat moat wurde stipe troch de proxy fan de gesant) en it opsetten fan it trochstjoeren fan ynformaasje oer de ferbining fan fersiken nei de tsjinst fan fersiken fan 'e tsjinst (mei help fan kopteksten) , yn it gefal fan it HTTP-protokol). As dizze problemen binne oplost, hawwe wy in krêftich ark dat ús mooglik makket om transparant ynformaasje te sammeljen fan it netwurk, sels yn heul heterogene systemen skreaun yn in protte ferskillende talen en kaders.
Yn it folgjende artikel oer Service Mesh sille wy sjen nei ien fan 'e grutste problemen mei Istio - it grutte konsumpsje fan RAM troch elke sidecar proxy-kontener en beprate hoe't jo dermei kinne omgean.
Boarne: www.habr.com