Istio og Kubernetes í framleiðslu. Part 2. Rekja

Í fortíðinni grein Við skoðuðum grunnþætti Service Mesh Istio, kynntum okkur kerfið og svöruðum helstu spurningum sem venjulega vakna þegar byrjað er að vinna með Istio. Í þessum hluta munum við skoða hvernig á að skipuleggja söfnun rakningarupplýsinga yfir net.

Það fyrsta sem kemur upp í hugann fyrir marga forritara og kerfisstjóra þegar þeir heyra orðin Service Mesh er að rekja. Reyndar bætum við sérstökum proxy-miðlara við hvern nethnút sem öll TCP umferð fer í gegnum. Svo virðist sem nú sé hægt að senda auðveldlega upplýsingar um öll netsamskipti á netinu. Því miður eru í raun og veru mörg blæbrigði sem þarf að taka tillit til. Við skulum skoða þau.

Misskilningur númer eitt: við getum fengið ókeypis göngugögn á netinu.

Reyndar, tiltölulega ókeypis, getum við aðeins fengið hnúta kerfisins okkar tengda með örvum og gagnahraða sem fer á milli þjónustu (í rauninni aðeins fjölda bæta á tímaeiningu). Hins vegar, í flestum tilfellum, hefur þjónusta okkar samskipti í gegnum einhvers konar forritalagssamskiptareglur, eins og HTTP, gRPC, Redis, og svo framvegis. Og auðvitað viljum við sjá rakningarupplýsingar sérstaklega fyrir þessar samskiptareglur; við viljum sjá beiðnirhlutfallið, ekki gagnahraðann. Við viljum skilja biðtíma beiðna með því að nota samskiptareglur okkar. Að lokum viljum við sjá alla leiðina sem beiðni tekur frá því að skrá sig inn í kerfið okkar til að fá svar frá notandanum. Þetta vandamál er ekki lengur svo auðvelt að leysa.

Í fyrsta lagi skulum við skoða hvernig sendandi rekjasvið lítur út frá byggingarfræðilegu sjónarhorni í Istio. Eins og við munum frá fyrsta hlutanum er Istio með sérstakan íhlut sem heitir Mixer til að safna fjarmælingum. Hins vegar, í núverandi útgáfu 1.0.*, er sending unnin beint frá proxy-þjónum, nefnilega frá envoy proxy. Envoy proxy styður sendingu rekja spanna með því að nota zipkin samskiptareglur úr kassanum. Það er hægt að tengja aðrar samskiptareglur, en aðeins í gegnum viðbót. Með Istio fáum við samstundis samsettan og stilltan umboðsmann sendifulltrúa, sem styður aðeins zipkin samskiptareglur. Ef við viljum nota, til dæmis, Jaeger siðareglur og senda rakningarsvið í gegnum UDP, þá þurfum við að búa til okkar eigin istio-proxy mynd. Það er stuðningur við sérsniðnar viðbætur fyrir istio-proxy, en það er enn í alfa útgáfunni. Þess vegna, ef við viljum vera án fjölda sérsniðinna stillinga, minnkar úrval tækni sem notuð er til að geyma og taka á móti rekjasviðum. Af helstu kerfum er nú reyndar hægt að nota Zipkin sjálft, eða Jaeger, en sent allt þangað með því að nota zipkin samhæfða siðareglur (sem er mun minna skilvirkt). Zipkin-samskiptareglurnar sjálfar fela í sér að allar rakningarupplýsingar eru sendar til safnara í gegnum HTTP-samskiptareglur, sem er frekar dýrt.

Eins og ég sagði þegar, viljum við rekja samskiptareglur á umsóknarstigi. Þetta þýðir að proxy-þjónarnir sem standa við hlið hverrar þjónustu verða að skilja hvers konar samskipti eru að gerast núna. Sjálfgefið er að Istio stillir allar gáttir þannig að þær séu látlaus TCP, sem þýðir að engin ummerki verða send. Til þess að hægt sé að senda ummerki verður þú í fyrsta lagi að virkja þennan valmöguleika í helstu möskvastillingu og, það sem er mjög mikilvægt, nefna allar hafnir kubernetes þjónustueininga í samræmi við samskiptareglur sem eru notaðar í þjónustunni. Það er til dæmis svona:

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

Þú getur líka notað samsett nöfn eins og http-magic (Istio mun sjá http og þekkja þá höfn sem http endapunkt). Snið er: frum-auka.

Til að plástra ekki mikinn fjölda stillinga til að ákvarða samskiptareglur geturðu notað óhreina lausn: plástraðu Pilot íhlutinn á því augnabliki sem hann er bara framkvæmir samskiptaskilgreiningarrökfræði. Að lokum verður auðvitað nauðsynlegt að breyta þessari rökfræði í staðlað og skipta yfir í nafnahefð fyrir allar hafnir.

Til þess að skilja hvort samskiptareglan sé raunverulega rétt skilgreind þarftu að fara inn í einhvern hliðvagnagáma með umboð sendiboða og leggja fram beiðni til admin tengi sendiboðaviðmótsins með staðsetningu /config_dump. Í uppsetningunni sem myndast þarftu að skoða rekstrarsvið viðkomandi þjónustu. Það er notað í Istio sem auðkenni fyrir hvar beiðnin er gerð. Til þess að sérsníða gildi þessarar færibreytu í Istio (við munum þá sjá það í rakningarkerfinu okkar), er nauðsynlegt að tilgreina þjónustuklasann á því stigi að ræsa hliðarvagnagáminn. Til dæmis er hægt að reikna það svona út frá breytum sem fengnar eru úr kubernetes API:

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

Gott dæmi til að skilja hvernig rekning virkar í envoy er hér.

Endapunkturinn sjálfur til að senda rakningarsvið verður einnig að tilgreina í kynningarfánum sendifulltrúa, til dæmis: --zipkinAddress tracing-collector.tracing:9411

Misskilningur númer tvö: við getum á ódýran hátt fengið fullkomnar ummerki um beiðnir í gegnum kerfið úr kassanum

Því miður er það ekki. Flækjustig innleiðingar fer eftir því hvernig þú hefur þegar innleitt samspil þjónustu. Afhverju er það?

Staðreyndin er sú að til þess að istio-proxy geti skilið samsvörun komandi beiðna til þjónustu við þá sem yfirgefa sömu þjónustu, þá er ekki nóg að hlera einfaldlega alla umferð. Þú þarft að hafa einhvers konar samskiptaauðkenni. Umboðsmaður HTTP sendiboða notar sérstaka hausa, með því að sendifulltrúi skilur hvaða sérstaka beiðni til þjónustunnar býr til sérstakar beiðnir til annarra þjónustu. Listi yfir slíka hausa:

• x-beiðni-auðkenni,
• x-b3-traceid,
• x-b3-spanid,
• x-b3-parentspanid,
• x-b3-sýni,
• x-b3-fánar,
• x-ot-span-samhengi.

Ef þú ert með einn punkt, til dæmis grunnbiðlara, þar sem þú getur bætt við slíkri rökfræði, þá er allt í lagi, þú þarft bara að bíða eftir að þetta bókasafn verði uppfært fyrir alla viðskiptavini. En ef þú ert með mjög ólíkt kerfi og það er engin sameining í því að flytja frá þjónustu til þjónustu yfir netið, þá mun þetta líklegast vera mikið vandamál. Án þess að bæta slíkri rökfræði við verða allar rakningarupplýsingar aðeins á „einu stigi“. Það er að segja, við munum fá öll samskipti milli þjónustuaðila, en þau verða ekki límd í stakar leiðarkeðjur í gegnum netið.

Ályktun

Istio býður upp á þægilegt tól til að safna rakningarupplýsingum yfir net, en þú verður að skilja að til innleiðingar þarftu að laga kerfið þitt og taka tillit til eiginleika Istio útfærslunnar. Þar af leiðandi þarf að leysa tvö meginatriði: að skilgreina samskiptareglur umsóknarstigs (sem verður að vera studd af umboðsmanni sendifulltrúa) og setja upp framsendingu upplýsinga um tengingu beiðna við þjónustuna frá beiðnum frá þjónustunni (með því að nota hausa , ef um er að ræða HTTP samskiptareglur). Þegar þessi mál eru leyst höfum við öflugt tól sem gerir okkur kleift að safna upplýsingum af netinu á gagnsæjan hátt, jafnvel í mjög ólíkum kerfum sem eru skrifuð á mörgum mismunandi tungumálum og ramma.

Í næstu grein um Service Mesh munum við skoða eitt stærsta vandamálið við Istio – mikla vinnsluminnisnotkun hvers hliðarvagns proxy-íláts og ræða hvernig þú getur tekist á við það.

Heimild: www.habr.com