Istio na Kubernetes katika uzalishaji. Sehemu ya 2. Kufuatilia

Zamani Ibara ya Tuliangalia vipengele vya msingi vya Service Mesh Istio, tukafahamiana na mfumo na tukajibu maswali kuu ambayo kwa kawaida hutokea wakati wa kuanza kufanya kazi na Istio. Katika sehemu hii tutaangalia jinsi ya kupanga ukusanyaji wa taarifa za ufuatiliaji kupitia mtandao.

Jambo la kwanza ambalo huja akilini kwa wasanidi programu wengi na wasimamizi wa mfumo wanaposikia maneno ya Huduma ya Mesh yanafuatiliwa. Hakika, tunaongeza seva maalum ya wakala kwa kila nodi ya mtandao ambayo trafiki yote ya TCP inapita. Inaonekana kwamba sasa inawezekana kutuma habari kwa urahisi kuhusu mwingiliano wote wa mtandao kwenye mtandao. Kwa bahati mbaya, kwa kweli kuna nuances nyingi ambazo zinahitaji kuzingatiwa. Hebu tuwaangalie.

Dhana potofu namba moja: tunaweza kupata data ya kupanda mlima mtandaoni bila malipo.

Kwa kweli, kwa kiasi cha bure, tunaweza tu kupata nodi za mfumo wetu zilizounganishwa na mishale na kiwango cha data kinachopita kati ya huduma (kwa kweli, idadi tu ya baiti kwa kila kitengo cha wakati). Hata hivyo, katika hali nyingi, huduma zetu huwasiliana kupitia aina fulani ya itifaki ya safu ya programu, kama vile HTTP, gRPC, Redis, na kadhalika. Na, bila shaka, tunataka kuona ufuatiliaji wa maelezo mahususi kwa ajili ya itifaki hizi; tunataka kuona kiwango cha ombi, si kiwango cha data. Tunataka kuelewa muda wa kusubiri wa maombi kwa kutumia itifaki yetu. Hatimaye, tunataka kuona njia kamili ambayo ombi huchukua kutoka kwa kuingia kwenye mfumo wetu hadi kupokea jibu kutoka kwa mtumiaji. Tatizo hili si rahisi tena kutatua.

Kwanza, hebu tuangalie jinsi kutuma spans ya ufuatiliaji inaonekana kutoka kwa mtazamo wa usanifu katika Istio. Kama tunavyokumbuka kutoka sehemu ya kwanza, Istio ina sehemu tofauti inayoitwa Mchanganyiko wa kukusanya telemetry. Hata hivyo, katika toleo la sasa la 1.0.*, utumaji unafanywa moja kwa moja kutoka kwa seva mbadala, yaani, kutoka kwa wakala wa mjumbe. Wakala wa mjumbe hutumia kutuma vipenyo vya ufuatiliaji kwa kutumia itifaki ya zipkin nje ya kisanduku. Inawezekana kuunganisha itifaki zingine, lakini tu kupitia programu-jalizi. Kwa Istio tunapata mara moja proksi ya mjumbe iliyokusanywa na kusanidiwa, ambayo inasaidia tu itifaki ya zipkin. Ikiwa tunataka kutumia, kwa mfano, itifaki ya Jaeger na kutuma muda wa kufuatilia kupitia UDP, basi tutahitaji kuunda picha yetu ya proksi ya istio. Kuna usaidizi kwa programu-jalizi maalum za proksi ya istio, lakini bado iko kwenye toleo la alpha. Kwa hiyo, ikiwa tunataka kufanya bila idadi kubwa ya mipangilio ya desturi, aina mbalimbali za teknolojia zinazotumiwa kuhifadhi na kupokea vipindi vya ufuatiliaji hupunguzwa. Ya mifumo kuu, kwa kweli, sasa unaweza kutumia Zipkin yenyewe, au Jaeger, lakini tuma kila kitu huko kwa kutumia itifaki inayolingana ya zipkin (ambayo ni duni sana). Itifaki ya zipkin yenyewe inahusisha kutuma taarifa zote za ufuatiliaji kwa watoza kupitia itifaki ya HTTP, ambayo ni ghali kabisa.

Kama nilivyosema tayari, tunataka kufuatilia itifaki za kiwango cha programu. Hii ina maana kwamba seva za proksi zinazosimama karibu na kila huduma lazima zielewe ni aina gani ya mwingiliano unaofanyika sasa. Kwa chaguo-msingi, Istio husanidi milango yote kuwa TCP tupu, ambayo inamaanisha hakuna ufuatiliaji utakaotumwa. Ili ufuatiliaji utume, lazima, kwanza, uwezeshe chaguo hili katika usanidi kuu wa matundu na, ni nini muhimu sana, taja bandari zote za vyombo vya huduma ya kubernetes kulingana na itifaki inayotumika katika huduma. Hiyo ni, kwa mfano, kama hii:

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

Unaweza pia kutumia majina ya kiwanja kama http-uchawi (Istio itaona http na kutambua bandari hiyo kama mwisho wa http). Umbizo ni: proto-ziada.

Ili usiweke idadi kubwa ya usanidi ili kuamua itifaki, unaweza kutumia njia chafu ya kufanya kazi: weka sehemu ya Majaribio wakati ni sawa. hufanya mantiki ya ufafanuzi wa itifaki. Mwishoni, bila shaka, itakuwa muhimu kubadili mantiki hii kwa kiwango na kubadili mkataba wa majina kwa bandari zote.

Ili kuelewa ikiwa itifaki kweli imefafanuliwa kwa usahihi, unahitaji kwenda kwenye kontena zozote za kando ukitumia seva mbadala ya mjumbe na utume ombi kwa mlango wa msimamizi wa kiolesura cha mjumbe ulio na eneo /config_dump. Katika usanidi unaosababisha, unahitaji kuangalia uwanja wa uendeshaji wa huduma inayotaka. Inatumika katika Istio kama kitambulisho cha mahali ambapo ombi limetolewa. Ili kubinafsisha thamani ya kigezo hiki katika Istio (basi tutaiona katika mfumo wetu wa ufuatiliaji), ni muhimu kubainisha bendera ya hudumaCluster katika hatua ya kuzindua kontena la kando. Kwa mfano, inaweza kuhesabiwa kama hii kutoka kwa anuwai zilizopatikana kutoka kwa API ya chini ya kubernetes:

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

Mfano mzuri wa kuelewa jinsi ufuatiliaji unavyofanya kazi katika mjumbe hapa.

Mwisho wenyewe wa kutuma vipindi vya ufuatiliaji lazima pia ubainishwe katika bendera za uzinduzi wa wakala, kwa mfano: --zipkinAddress tracing-collector.tracing:9411

Dhana potofu namba mbili: tunaweza kupata athari kamili za maombi kwa bei nafuu kupitia mfumo nje ya boksi.

Kwa bahati mbaya, sivyo. Ugumu wa utekelezaji unategemea jinsi ambavyo tayari umetekeleza mwingiliano wa huduma. Kwanini hivyo?

Ukweli ni kwamba ili wakala wa istio aweze kuelewa mawasiliano ya maombi yanayoingia kwa huduma na wale wanaoacha huduma sawa, haitoshi tu kuzuia trafiki yote. Unahitaji kuwa na aina fulani ya kitambulisho cha mawasiliano. Wakala wa mjumbe wa HTTP hutumia vichwa maalum, ambavyo mjumbe huelewa ni ombi gani mahususi kwa huduma hutoa maombi maalum kwa huduma zingine. Orodha ya vichwa kama hivyo:

• kitambulisho cha ombi la x,
• x-b3-fuatiliwa,
• x-b3-spanid,
• x-b3-parentspaid,
• x-b3-sampuli,
• x-b3-bendera,
• x-ot-span-context.

Ikiwa una hatua moja, kwa mfano, mteja wa msingi, ambayo unaweza kuongeza mantiki hiyo, basi kila kitu ni sawa, unahitaji tu kusubiri maktaba hii kusasishwa kwa wateja wote. Lakini ikiwa una mfumo wa tofauti sana na hakuna umoja katika kuhama kutoka kwa huduma hadi huduma kwenye mtandao, basi hii itakuwa na uwezekano mkubwa kuwa shida kubwa. Bila kuongeza mantiki kama hiyo, habari zote za ufuatiliaji zitakuwa "kiwango kimoja". Hiyo ni, tutapokea mwingiliano wote wa huduma, lakini hautaunganishwa kwenye minyororo moja ya kifungu kupitia mtandao.

Hitimisho

Istio hutoa zana rahisi ya kukusanya taarifa za ufuatiliaji kwenye mtandao, lakini lazima uelewe kwamba kwa utekelezaji utahitaji kurekebisha mfumo wako na kuzingatia vipengele vya utekelezaji wa Istio. Kama matokeo, mambo mawili makuu yanahitaji kutatuliwa: kufafanua itifaki ya kiwango cha maombi (ambayo lazima iungwa mkono na wakala wa mjumbe) na kuanzisha usambazaji wa habari kuhusu uunganisho wa maombi kwa huduma kutoka kwa maombi kutoka kwa huduma (kwa kutumia vichwa vya habari). , katika kesi ya itifaki ya HTTP). Masuala haya yanapotatuliwa, tuna zana yenye nguvu inayoturuhusu kukusanya taarifa kwa uwazi kutoka kwa mtandao, hata katika mifumo tofauti tofauti iliyoandikwa katika lugha na mifumo mingi tofauti.

Katika makala inayofuata kuhusu Huduma ya Mesh, tutaangalia mojawapo ya matatizo makubwa na Istio - matumizi makubwa ya RAM kwa kila chombo cha wakala wa kando na kujadili jinsi unavyoweza kukabiliana nayo.

Chanzo: mapenzi.com