Istio ir Kubernetes gamyboje. 2 dalis. Sekimas

Paskutiniame straipsnis Apžiūrėjome pagrindinius Service Mesh Istio komponentus, susipažinome su sistema ir atsakėme į pagrindinius klausimus, kurie dažniausiai kyla pradedant dirbti su Istio. Šioje dalyje apžvelgsime, kaip organizuoti sekimo informacijos rinkimą tinkle.

Pirmas dalykas, kuris ateina į galvą daugeliui kūrėjų ir sistemos administratorių išgirdus žodžius „Service Mesh“ yra sekimas. Iš tiesų prie kiekvieno tinklo mazgo, per kurį praeina visas TCP srautas, pridedame specialų tarpinį serverį. Atrodo, kad dabar galima lengvai siųsti informaciją apie visas tinklo sąveikas tinkle. Deja, iš tikrųjų yra daug niuansų, į kuriuos reikia atsižvelgti. Pažiūrėkime į juos.

Klaidingas supratimas numeris vienas: galime nemokamai gauti internetinius žygių duomenis.

Tiesą sakant, santykinai nemokamai galime gauti tik mūsų sistemos mazgus, sujungtus rodyklėmis ir duomenų perdavimo sparta tarp paslaugų (iš tikrųjų tik baitų skaičių per laiko vienetą). Tačiau daugeliu atvejų mūsų paslaugos palaiko ryšį per tam tikrą programų lygmens protokolą, pvz., HTTP, gRPC, Redis ir pan. Ir, žinoma, norime matyti specialiai šiems protokolams skirtą sekimo informaciją; norime matyti užklausų, o ne duomenų perdavimo spartą. Mes norime suprasti užklausų delsą naudodami mūsų protokolą. Galiausiai norime pamatyti visą kelią, kuriuo užklausa eina nuo prisijungimo prie sistemos iki atsakymo iš vartotojo gavimo. Šią problemą išspręsti nebėra taip paprasta.

Pirmiausia pažiūrėkime, kaip Istio architektūriniu požiūriu atrodo siuntimo sekimo intervalai. Kaip prisimename iš pirmosios dalies, „Istio“ turi atskirą komponentą „Mixer“, skirtą telemetrijai rinkti. Tačiau dabartinėje 1.0.* versijoje siuntimas atliekamas tiesiogiai iš įgaliotųjų serverių, būtent iš įgaliotojo įgaliotinio. „Envoy“ tarpinis serveris palaiko sekimo intervalų siuntimą naudojant „zipkin“ protokolą. Galima prijungti kitus protokolus, bet tik per papildinį. Su Istio iš karto gauname surinktą ir sukonfigūruotą pasiuntinio tarpinį serverį, kuris palaiko tik zipkin protokolą. Jei norime naudoti, pavyzdžiui, Jaeger protokolą ir siųsti sekimo intervalus per UDP, tuomet turėsime sukurti savo istio-proxy vaizdą. Palaikomi pasirinktiniai istio-proxy įskiepiai, tačiau vis dar yra alfa versijos. Todėl, jei norime apsieiti be daugybės pasirinktinių nustatymų, sumažinamas sekimo intervalų saugojimo ir gavimo technologijų spektras. Tiesą sakant, iš pagrindinių sistemų dabar galite naudoti patį Zipkin arba Jaeger, bet viską siųsti naudodami su zipkin suderinamą protokolą (kuris yra daug mažiau efektyvus). Pats zipkin protokolas apima visos sekimo informacijos siuntimą kolekcionieriams per HTTP protokolą, kuris yra gana brangus.

Kaip jau sakiau, norime atsekti programos lygio protokolus. Tai reiškia, kad tarpiniai serveriai, esantys šalia kiekvienos paslaugos, turi suprasti, kokia sąveika vyksta dabar. Pagal numatytuosius nustatymus „Istio“ sukonfigūruoja visus prievadus kaip paprastą TCP, o tai reiškia, kad nebus siunčiami jokie pėdsakai. Kad pėdsakai būtų siunčiami, pirmiausia turite įjungti šią parinktį pagrindinėje tinklelio konfigūracijoje ir, kas labai svarbu, pavadinti visus kubernetes paslaugų objektų prievadus pagal paslaugoje naudojamą protokolą. Tai, pavyzdžiui, taip:

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

Taip pat galite naudoti sudėtinius pavadinimus, pvz., http-magic (Istio matys http ir atpažins tą prievadą kaip http galinį tašką). Formatas yra: proto-extra.

Kad nereikėtų pataisyti daugybės konfigūracijų protokolui nustatyti, galite naudoti nešvarų sprendimą: pataisyti Pilot komponentą tuo metu, kai jis yra tik atlieka protokolo apibrėžimo logiką. Galų gale, žinoma, reikės pakeisti šią logiką į standartinę ir pereiti prie visų prievadų pavadinimų suteikimo.

Norėdami suprasti, ar protokolas tikrai apibrėžtas teisingai, turite įeiti į bet kurį iš šoninių vagonų konteinerių su pasiuntinio tarpiniu serveriu ir pateikti užklausą pasiuntinio sąsajos administratoriaus prievadui su vieta /config_dump. Gautoje konfigūracijoje turite pažvelgti į norimos paslaugos veikimo lauką. Jis naudojamas Istio kaip identifikatorius, kur pateikiama užklausa. Norint pritaikyti šio parametro reikšmę Istio (tada ją matysime savo sekimo sistemoje), šoninio priekabos konteinerio paleidimo etape būtina nurodyti serviceCluster vėliavėlę. Pavyzdžiui, jį galima apskaičiuoti taip iš kintamųjų, gautų iš žemyn nukreiptos kubernetes API:

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

Geras pavyzdys suprasti, kaip sekimas veikia pasiuntinyje čia.

Pats galinis taškas, skirtas sekimo intervalams siųsti, taip pat turi būti nurodytas pasiuntinio tarpinio serverio paleidimo vėliavėlėse, pavyzdžiui: --zipkinAddress tracing-collector.tracing:9411

Antras klaidingas supratimas: mes galime nebrangiai gauti pilnus užklausų pėdsakus per sistemą

Deja, taip nėra. Diegimo sudėtingumas priklauso nuo to, kaip jau įdiegėte paslaugų sąveiką. Kodėl taip?

Faktas yra tas, kad norint, kad istio-proxy galėtų suprasti gaunamų užklausų atitiktį paslaugai su išeinančiais iš tos pačios paslaugos, neužtenka tiesiog perimti visą srautą. Turite turėti tam tikrą komunikacijos identifikatorių. HTTP envoy proxy naudoja specialias antraštes, pagal kurias pasiuntinys supranta, kuri konkreti užklausa paslaugai generuoja konkrečias užklausas kitoms tarnyboms. Tokių antraščių sąrašas:

• x-request-id,
• x-b3-traceid,
• x-b3-spanid,
• x-b3-parentsspanid,
• x-b3-sampled,
• x-b3 vėliavėlės,
• x-ot-span-kontekstas.

Jei turite vieną tašką, pavyzdžiui, pagrindinį klientą, kuriame galite pridėti tokią logiką, tada viskas gerai, tereikia palaukti, kol ši biblioteka bus atnaujinta visiems klientams. Bet jei turite labai nevienalytę sistemą ir nėra susivienijimo pereinant nuo paslaugos prie paslaugos tinkle, tai greičiausiai bus didelė problema. Nepridėjus tokios logikos, visa sekimo informacija bus tik „vieno lygio“. Tai reiškia, kad gausime visas tarpžinybines sąveikas, tačiau jos nebus suklijuotos į atskiras praėjimo per tinklą grandines.

išvada

„Istio“ yra patogus įrankis sekimo informacijai rinkti tinkle, tačiau jūs turite suprasti, kad diegimui turėsite pritaikyti savo sistemą ir atsižvelgti į „Istio“ diegimo ypatybes. Dėl to reikia išspręsti du pagrindinius dalykus: apibrėžti programos lygio protokolą (kuris turi palaikyti pasiuntinio įgaliotasis serveris) ir nustatyti informacijos apie užklausų prijungimą prie tarnybos persiuntimą iš tarnybos užklausų (naudojant antraštes). , HTTP protokolo atveju). Kai šios problemos bus išspręstos, turime galingą įrankį, leidžiantį skaidriai rinkti informaciją iš tinklo net ir labai nevienalytėse sistemose, parašytose daugybe skirtingų kalbų ir sistemų.

Kitame straipsnyje apie „Service Mesh“ apžvelgsime vieną didžiausių „Istio“ problemų – didelį RAM suvartojimą kiekviename šoninio priekabo tarpinio serverio konteineryje ir aptarsime, kaip su tuo susitvarkyti.

Šaltinis: www.habr.com