Istio ja Kubernetes tootmises. Osa 2. Tracing

Eelmises osas artiklis uurisime Service Mesh'i Istio põhikomponente, tutvustasime süsteemi ja vastasime põhilistele küsimustele, mis tavaliselt tõusevad esile Istio kasutamise alguses. Selles osas vaatame, kuidas korraldada tracing teabe kogumist võrgus.

Esimene mõte, mis paljudele arendajatele ja süsteemiadministraatoritele tuleb, kui nad kuulevad sõnu Service Mesh, on tracing. Ja tõepoolest, me paigaldame igasse võrgu sõlme spetsiaalse pöördproksi, mille kaudu läbib kogu TCP-liiklus. Tundub, et nüüd on lihtne edastada teavet kõigi võrgutehingute kohta. Kahjuks ilmnevad reaalsuses palju nüansse, mida tuleb arvesse võtta. Vaatame neid.

Eksimus number üks: me saame tasuta andmeid võrguülekannete kohta

Tegelikult saame suhteliselt tasuta jälgida ainult meie süsteemi ühendatud sõlmede ja andmete määra, mis liigub teenuste vahel (sisuliselt - vaid baitide arv ajaühikus). Enamiku juhtudel suhtlevad meie teenused mõne rakendusprotokolli kaudu, näiteks HTTP, gRPC, Redis jne. Ja loomulikult soovime näha jälgimise teavet just nende protokollide osas, soovime näha päringute määra, mitte andmete määra. Soovime mõista päringute latentsust meie protokolli kaudu. Lõpuks tahame näha täpset teed, mida päring läbib meie süsteemi sisenemisest kuni vastuse saamiseni kasutaja poolt. See ülesanne ei ole enam nii lihtne.

Alustamiseks vaatame, kuidas näeb tracing spanide saatmine välja Istio arhitektuuri vaatepunktist. Nagu me mäletame esimesest osast, on Istio'l telemeetria kogumiseks eraldi komponent nimega Mixer. Kuid praeguses versioonis 1.0.* toimub saatmine otse proksi serverite, st envoy proksi kaudu. Envoy proksi toetab tracing spanide saatmist zipkini protokolli kaudu välja tootepakendis. Teisi protokolle on võimalik lisada, kuid ainult plugina kaudu. Istio muretses meile kohe kogutud ja seadistatud envoy proksi, milles toetatakse ainult zipkini protokolli. Kui soovime kasutada näiteks Jaeger protokolli ja saata tracing span’e UDP kaudu, peame ise koguma oma istio-proxy pildi. Kohandatud pluginate tugi istio-proxyle on olemas, kuid see on endiselt alfa versioonis. Seetõttu, kui soovime toime tulla ilma paljude kohandatud seadistusteta, väheneb tehnoloogiate valik tracing spanide salvestamiseks ja vastuvõtmiseks. Peamisi süsteeme, mida praegu kasutada, on tegelikult zipkin või jaeger, kuid kõik tuleb saata zipkiniga ühilduva protokolli kaudu (mis on oluliselt vähem efektiivne). Ise zipkini protokoll eeldab kogu tracing teabe saatmist kollektoritele HTTP protokolli kaudu, mis on üsna kulukas.

Nagu juba ütlesin, tahame jälgida rakendusprotokolle. See tähendab, et iga teenuse kõrval olevad proxy-serverid peavad mõistma, milline suhtlus hetkel toimub. Vaikimisi määrab Istio kõigile portidele plain TCP tüübi, mis tähendab, et jälgimisi ei saadeta. Jälgimiste saatmiseks tuleb kõigepealt see võimalus peameses mesh konfiguratsioonis aktiveerida ja mis on väga oluline, nimetada kõik portide kubernetes teenuste üksuste nimed vastavalt teenuses kasutatavatele protokollidele. Näiteks nii:

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

Samuti saab kasutada komposiitnimesid, näiteks http-magic (Istio näeb http ja tuvastab selle pordi http lõpp-punktina). Formaat on järgmine: proto-extra.

Kuna tohutu hulga seadistuste muutmine protokolli määramiseks oleks liiga keeruline, saab kasutada määrdunud lahendust: patchida Pilot komponenti hetkel, kui see täidab protokolli määramise loogikat. Lõpuks tuleb see loogika loomulikult muuta tavalisele ja liikuda kõikide portide nimeteemade konventsiooni.

Kuna tahate aru saada, kas protokoll on tõepoolest õigesti määratletud, peate minema mõnele sidecar konteinerile koos envoy proxy'ga ja tegema päringu envoy'i admini liidese pordile aadressil /config_dump. Saadud konfigureerimises tuleb vaadata vajalikus teenuses väli operation. Seda kasutatakse Istios kui identifikaator, kuhu päring suunatakse. Selle parameetri väärtuse kohandamiseks Istios (mida me siis oma jälgimissüsteemis näeme) on vajalik sidecar konteineri käivitamisel määrata lipp serviceCluster. Näiteks võib seda arvutada kubernetes'e allapoole suunatud API saadud muutujatest.

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

Hea näide aru saamiseks, kuidas jälgimine envoy's töötab, on siin.

Endpointhi, kuhu saatmise jälgimise span'id tuleb samuti määratleda envoy proxy käivitamise lippudes, näiteks: --zipkinAddress tracing-collector.tracing:9411

Teine eksitus: me saame odavalt saada täis jälgimisi päringute läbimisest süsteemis kohe.

Kahjuks ei ole see nii. Rakendamise keerukus sõltub sellest, kuidas teil on juba teenuste vaheline suhtlus korraldatud. Miks see nii on?

Asi on selles, et istio-proxy jaoks on vajalik, et see mõistaks sissetulevate päringute vastavust teenusest väljaminevatele päringutele, mitte ei piirduda lihtsalt kogu liikluse haaramisega. Peab olema mingi seose identifikaator. HTTP envoy proxy kasutab spetsiaalseid päiseid, mille abil envoy mõistab, milline päring teenusele põhjustab konkreetseid päringuid teistesse teenustesse. Nende päiste nimekiri on järgmine:

• x-request-id,
• x-b3-traceid,
• x-b3-spanid,
• x-b3-parentspanid,
• x-b3-sampled,
• x-b3-flags,
• x-ot-span-context.

Kui teil on ühtne punkt, näiteks põhiklient, kuhu sellist loogikat lisada, siis on kõik suurepärane, peate lihtsalt ootama selle raamistiku värskendamist kõigis klientides. Kuid kui teil on väga heterogeenne süsteem ja puudub teenuste vahelise suhtluse osas ühtsus, siis võib see tõenäoliselt olla suur probleem. Ilma selle loogika lisamiseta jääb kogu jälgimisinfo lihtsalt "ühe taseme". See tähendab, et saame kõik teenustevahelised suhtlused, kuid need ei ole seotud ühte võrgu kaudu kulgemise ahelasse.

Kokkuvõte

Istio pakub mugavat tööriista tracing teabe kogumiseks võrgus, kuid tuleb mõista, et selle rakendamiseks on vajalik oma süsteemi kohandamine ja Istio rakendamise eripära arvestamine. Lõpuks tuleb lahendada kaks peamist küsimust: rakendustaseme protokolli määratlemine (mida peab toetama envoy proxy) ja teabe edastamise seadistamine teenusesse tulevate päringute ja teenusevaheliste päringute vahel (kasutades päiseid, juhul kui protokolliks on HTTP). Kui need küsimused on lahendatud, saame võimsa tööriista, mis võimaldab sujuvalt koguda teavet võrgus isegi väga heterogeensetes süsteemides, kirjutatud mitmesugustes keeltes ja raamistikudes.

Järgmisel artiklil Service Mesh teemal käsitleme ühte suurimat probleemi Istio puhul – iga sidecar proxy konteineri suur mälu kasutus ja arutame, kuidas sellega võidelda.

Allikas: habr.com