Istio a Kubernetes yn cynhyrchu. Rhan 2. Olrhain

Yn yr olaf Erthygl Edrychom ar gydrannau sylfaenol Gwasanaeth Rhwyll Istio, dod yn gyfarwydd â'r system ac ateb y prif gwestiynau sy'n codi fel arfer wrth ddechrau gweithio gydag Istio. Yn y rhan hon byddwn yn edrych ar sut i drefnu casglu gwybodaeth olrhain dros rwydwaith.

Y peth cyntaf sy'n dod i'r meddwl i lawer o ddatblygwyr a gweinyddwyr system pan fyddant yn clywed y geiriau y mae Service Mesh yn eu holrhain. Yn wir, rydym yn ychwanegu gweinydd dirprwy arbennig i bob nod rhwydwaith y mae holl draffig TCP yn mynd trwyddo. Mae'n ymddangos ei bod bellach yn bosibl anfon gwybodaeth yn hawdd am yr holl ryngweithiadau rhwydwaith ar y rhwydwaith. Yn anffodus, mewn gwirionedd mae yna lawer o arlliwiau y mae angen eu hystyried. Gadewch i ni edrych arnynt.

Camsyniad rhif un: gallwn gael data heicio ar-lein am ddim.

Mewn gwirionedd, yn gymharol rhad ac am ddim, dim ond nodau ein system y gallwn eu cysylltu â saethau a'r gyfradd data sy'n mynd rhwng gwasanaethau (mewn gwirionedd, dim ond nifer y beit fesul uned o amser). Fodd bynnag, yn y rhan fwyaf o achosion, mae ein gwasanaethau'n cyfathrebu dros ryw fath o brotocol haen cais, megis HTTP, gRPC, Redis, ac ati. Ac, wrth gwrs, rydym am weld gwybodaeth olrhain yn benodol ar gyfer y protocolau hyn; rydym am weld y gyfradd ceisiadau, nid y gyfradd data. Rydym am ddeall pa mor hwyr y mae ceisiadau gan ddefnyddio ein protocol. Yn olaf, rydym am weld y llwybr llawn y mae cais yn ei gymryd o fewngofnodi i'n system i dderbyn ymateb gan y defnyddiwr. Nid yw'r broblem hon mor hawdd i'w datrys mwyach.

Yn gyntaf, gadewch i ni edrych ar sut olwg sydd ar anfon rhychwantau olrhain o safbwynt pensaernïol yn Istio. Fel y cofiwn o'r rhan gyntaf, mae gan Istio gydran ar wahân o'r enw Mixer ar gyfer casglu telemetreg. Fodd bynnag, yn y fersiwn gyfredol 1.0.*, anfonir yn uniongyrchol o weinyddion dirprwyol, sef, o ddirprwy cennad. Mae dirprwy gennad yn cefnogi anfon rhychwantau olrhain gan ddefnyddio'r protocol zipkin allan o'r blwch. Mae'n bosibl cysylltu protocolau eraill, ond dim ond trwy ategyn. Gydag Istio rydym yn cael dirprwy gennad wedi'i ymgynnull a'i ffurfweddu ar unwaith, sydd ond yn cefnogi'r protocol zipkin. Os ydym am ddefnyddio, er enghraifft, protocol Jaeger ac anfon rhychwantau olrhain trwy'r CDU, yna bydd angen i ni adeiladu ein delwedd istio-procsi ein hunain. Mae cefnogaeth i ategion personol ar gyfer istio-proxy, ond mae'n dal i fod yn y fersiwn alffa. Felly, os ydym am wneud heb nifer fawr o leoliadau arfer, mae'r ystod o dechnolegau a ddefnyddir ar gyfer storio a derbyn rhychwantau olrhain yn cael ei leihau. O'r prif systemau, mewn gwirionedd, nawr gallwch chi ddefnyddio Zipkin ei hun, neu Jaeger, ond anfonwch bopeth yno gan ddefnyddio'r protocol sy'n gydnaws â zipkin (sy'n llawer llai effeithlon). Mae'r protocol zipkin ei hun yn golygu anfon yr holl wybodaeth olrhain at gasglwyr trwy'r protocol HTTP, sy'n eithaf drud.

Fel y dywedais eisoes, rydym am olrhain protocolau lefel cais. Mae hyn yn golygu bod yn rhaid i'r gweinyddwyr dirprwy sy'n sefyll wrth ymyl pob gwasanaeth ddeall pa fath o ryngweithio sy'n digwydd nawr. Yn ddiofyn, mae Istio yn ffurfweddu pob porthladd i fod yn TCP plaen, sy'n golygu na fydd unrhyw olion yn cael eu hanfon. Er mwyn i olion gael eu hanfon, rhaid i chi, yn gyntaf, alluogi'r opsiwn hwn yn y prif gyfluniad rhwyll a, yr hyn sy'n bwysig iawn, enwi holl borthladdoedd endidau gwasanaeth kubernetes yn unol â'r protocol a ddefnyddir yn y gwasanaeth. Dyna, er enghraifft, fel hyn:

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

Gallwch hefyd ddefnyddio enwau cyfansawdd fel http-hud (bydd Istio yn gweld http ac yn cydnabod y porthladd hwnnw fel pennod http). Y fformat yw: proto-extra.

Er mwyn peidio â chlytio nifer enfawr o ffurfweddiadau i bennu'r protocol, gallwch ddefnyddio datrysiad budr: clytio'r gydran Peilot ar hyn o bryd pan mai dim ond yn perfformio rhesymeg diffiniad protocol. Yn y diwedd, wrth gwrs, bydd angen newid y rhesymeg hon i safon a newid i gonfensiwn enwi pob porthladd.

Er mwyn deall a yw'r protocol wedi'i ddiffinio'n gywir mewn gwirionedd, mae angen i chi fynd i mewn i unrhyw un o'r cynwysyddion car ochr gyda dirprwy cennad a gwneud cais i borthladd gweinyddol y rhyngwyneb llysgennad gyda lleoliad /config_dump. Yn y cyfluniad canlyniadol, mae angen ichi edrych ar faes gweithredu'r gwasanaeth a ddymunir. Fe'i defnyddir yn Istio fel dynodwr ar gyfer y man lle gwneir y cais. Er mwyn addasu gwerth y paramedr hwn yn Istio (byddwn wedyn yn ei weld yn ein system olrhain), mae angen nodi'r faner serviceCluster ar y cam o lansio'r cynhwysydd car ochr. Er enghraifft, gellir ei gyfrifo fel hyn o newidynnau a gafwyd o'r API kubernetes i lawr:

--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')

Enghraifft dda i ddeall sut mae olrhain yn gweithio mewn llysgennad yw yma.

Rhaid nodi'r pwynt terfyn ei hun ar gyfer anfon rhychwantau olrhain hefyd ym baneri lansio dirprwy y llysgennad, er enghraifft: --zipkinAddress tracing-collector.tracing:9411

Camsyniad rhif dau: gallwn gael olion cyflawn o geisiadau trwy'r system allan o'r bocs yn rhad

Yn anffodus, nid yw. Mae cymhlethdod y gweithredu yn dibynnu ar sut yr ydych eisoes wedi gweithredu'r rhyngweithio gwasanaethau. Pam hynny?

Y ffaith yw, er mwyn i istio-procsi allu deall gohebiaeth ceisiadau sy'n dod i mewn i wasanaeth â'r rhai sy'n gadael yr un gwasanaeth, nid yw'n ddigon rhyng-gipio'r holl draffig yn unig. Mae angen i chi gael rhyw fath o ddynodwr cyfathrebu. Mae dirprwy llysgennad HTTP yn defnyddio penawdau arbennig, lle mae llysgennad yn deall pa gais penodol i'r gwasanaeth sy'n cynhyrchu ceisiadau penodol i wasanaethau eraill. Rhestr o benawdau o'r fath:

• x-cais-id,
• x-b3-traceid,
• x-b3-spanid,
• x-b3-spanid,
• x-b3-samplu,
• x-b3-baneri,
• x-ot-span-cyd-destun.

Os oes gennych un pwynt, er enghraifft, cleient sylfaenol, lle gallwch chi ychwanegu rhesymeg o'r fath, yna mae popeth yn iawn, does ond angen i chi aros i'r llyfrgell hon gael ei diweddaru ar gyfer pob cleient. Ond os oes gennych system heterogenaidd iawn ac nad oes unrhyw uniad wrth symud o wasanaeth i wasanaeth dros y rhwydwaith, yna mae'n debygol y bydd hyn yn broblem fawr. Heb ychwanegu rhesymeg o’r fath, dim ond “lefel sengl” fydd yr holl wybodaeth olrhain. Hynny yw, byddwn yn derbyn yr holl ryngweithio rhwng gwasanaethau, ond ni fyddant yn cael eu gludo i mewn i gadwyni taith sengl drwy'r rhwydwaith.

Casgliad

Mae Istio yn darparu offeryn cyfleus ar gyfer casglu gwybodaeth olrhain dros rwydwaith, ond rhaid i chi ddeall y bydd angen i chi addasu eich system ac ystyried nodweddion gweithrediad Istio er mwyn gweithredu. O ganlyniad, mae angen datrys dau brif bwynt: diffinio'r protocol lefel cais (y mae'n rhaid ei gefnogi gan ddirprwy'r llysgennad) a sefydlu'r broses o anfon gwybodaeth ymlaen am gysylltiad ceisiadau gan y gwasanaeth i'r gwasanaeth (gan ddefnyddio penawdau , yn achos y protocol HTTP). Pan fydd y materion hyn yn cael eu datrys, mae gennym offeryn pwerus sy'n ein galluogi i gasglu gwybodaeth yn dryloyw o'r rhwydwaith, hyd yn oed mewn systemau heterogenaidd iawn a ysgrifennwyd mewn llawer o ieithoedd a fframweithiau gwahanol.

Yn yr erthygl nesaf am Service Mesh, byddwn yn edrych ar un o'r problemau mwyaf gydag Istio - y defnydd mawr o RAM gan bob cynhwysydd dirprwy car ochr a thrafod sut y gallwch chi ddelio ag ef.

Ffynhonnell: hab.com