Istio ja Kubernetes tootmises. Osa 2. Jälgimine

Eelmisel artiklis Oleme uurinud Service Mesh Istio põhikomponente, tutvunud süsteemiga ja vastanud peamistele küsimustele, mis tavaliselt tekivad Istio kasutamise alguses. Selles osas vaatame, kuidas korraldada jälitusteabe kogumist võrgus.

Esimene asi, mis paljudele arendajatele ja süsteemiadministraatoritele pähe tuleb, kui nad kuulevad sõnu Service Mesh, on jälitamine. Ja tõepoolest, lisame iga võrgu sõlme spetsiaalse proxy-serveri, mille kaudu läbib kogu TCP-liiklus. Tundub, et nüüd on lihtne edastada teavet kõigi võrgu interaktsioonide kohta. Kahjuks ilmuvad reaalsuses mitmed nüansid, mida tuleb arvestada. Vaadakem neid.

Müüt number üks: me saame tasuta andmeid võrgu teekondade kohta.

Tegelikult saame suhteliselt tasuta vaid seotud nooltega sõlmede meie süsteemis ja andmevahetuse määra, mis toimub teenuste vahel (tõepoolest - ainult baitide arvu ajas). Siiski suhtlevad meie teenused enamikul juhtudel mõne rakendusprotokolliga, nagu HTTP, gRPC, Redis jne. Ja muidugi tahame näha jälitusteavet just nende protokollide kohta, tahame näha päringute määra, mitte andmevahetuse määra. Tahame mõista päringute latentsust meie protokollis. Lõpuks tahame näha täpset teed, mida päring läbib sissepääsust meie süsteemi kuni kasutaja vastuse saamiseni. See ülesanne ei ole enam nii lihtne.

Esiteks vaatame, kuidas näeb välja tracing span'ide saatmine arktitektuuri seisukohalt Istios. Nagu me esimeses osas mäletame, on Istio-l telemeetriate kogumiseks eraldi komponent nimega Mixer. Siiski, käesolevas versioonis 1.0.* toimub saatmine otse proksiserveritest, nimelt envoy proksist. Envoy proksi toetab tracing span'ide saatmist zipkini protokolli kaudu välja kastist. Teisi protokolle on võimalik lisada, kuid ainult plugina kaudu. Istio-s saame kohe valmis ja seadistatud envoy proksi, milles toetatakse ainult zipkini protokolli. Kui me soovime kasutada näiteks Jaeger protokolli ja saata tracing span'e UDP kaudu, siis peame ise koguma oma istio-proxy pildi. Kliendi pluginate tugi istio-proxy-le on olemas, kuid see on endiselt alpha versioonis. Seetõttu, kui me tahame hakkama saada ilma suure hulga kohandatud seadistusteta, kitseneb tehnoloogiate ring, mida saab tracing span'ide hoidmiseks ja vastuvõtmiseks kasutada. Praegusest peamistest süsteemidest saame kasutada kas zipkini või jaegeri, kuid saatmine toimub siiski zipkini ühilduva protokolli kaudu (mis on oluliselt vähem efektiivne). Zipkini protokoll eeldab, et kogu trace info saadetakse kollektoreille HTTP protokolli kaudu, mis on üsna kulukas.

Nagu ma juba ütlesin, soovime jälgida rakendustasandi protokolle. See tähendab, et proksiserverid, mis asuvad iga teenuse kõrval, peavad mõistma, milline suhtlus toimub. Vaikimisi konfigureerib Istio kõigi sadamate jaoks plain TCP tüübi, mis tähendab, et mingeid trace'e ei saadeta. Trace'ide saatmiseks tuleb kõigepealt see valik peamise mesh config'iga sisse lülitada ja mis on väga oluline, peab kõikide Kubernetes'e teenuste sadamate nimed olema vastavuses teenuses kasutatava protokolliga. Näiteks näiteks niimoodi:

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

Saab kasutada ka koostatud nimesid, näiteks http-magic (Istio tuvastab http ja tunnustab seda porti http endpoint'ina). Formaat on järgmine: proto-extra.

Kuna ei soovi paljusid konfiguratsioonide patch'e teha protokolli määramiseks, võime kasutusele võtta häguse lahenduse: patch'ida Pilot komponent just siis, kui see just teeb protokolli määramise loogikat.. Lõpuks tuleb kindlasti muuta see loogika standardselt ja liikuda üle kõikide portide nimede konventsioonile.

Kuna mõista, kas protokoll on tõepoolest õigesti määratletud, tuleb siseneda ühtegi sidecar konteinerisse koos envoy proxy’ga ja teha päring admin-interfääsi envoy porti aadressil /config_dump. Saadud seadistustes tuleb vaadata vajaliku teenuse välja operation. Seda kasutatakse Istios identifikaatorina selle kohta, kuhu päring toimub. Selle parameetri väärtuse kohandamiseks Istios (me näeme seda hiljem meie jälgimissüsteemis) tuleb sidecar konteineri käivitamise etapis määrata lipp serviceCluster. Näiteks saab seda nii arvutada, kasutades allapoole suunatud API muutujatele kubernetes:

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

Hea näide sellest, kuidas tracing envoy’is töötab, on siit.

Isegi endpoint, kuhu tracing span’e saata, tuleb samuti määrata envoy proxy käivitamise lipuks, näiteks: --zipkinAddress tracing-collector.tracing:9411

Müüt number kaks: me saame umbes tasuta täielikud jäljed päringute läbimisest süsteemis välja pakutud.

Kahjuks ei ole see tõsi. Rakendamise keerukus sõltub sellest, kuidas teil juba teenuste vahel suhtlemine on korraldatud. Miks see nii on?

Asi on selles, et istio-proxy peab mõistma sissetulevate päringute ja selle teenuse väljuvate päringute vastavust; pelgalt kogu liikluse pealtkuulamine ei ole piisav. Peab olema mingisugune ühenduse identifikaator. HTTP envoy proxy’s kasutatakse spetsiaalseid päiseid, mille abil envoy mõistab, milline päring teenusele genereerib konkreetseid päringuid teistesse teenustesse. Nende päiste loetelu on:

• 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 üks ainus koht, näiteks põhiklient, kuhu saab sellist loogikat lisada, siis on kõik suurepärane, peate lihtsalt ootama selle teegi värskendust kõigilt klientidelt. Kuid kui teil on väga heterogeenne süsteem ja teenuste vahel pole võrgu kaudu ühtsust, on see tõenäoliselt suur probleem. Ilma sellise loogika lisamata jääb kogu jälgimisteave vaid "ühe taseme". See tähendab, et saame kõik teenustevahelised suhtlused, kuid need ei ole kokku pandud tõhusate võrgu läbiviijate ahelateks.

Kokkuvõte

Istio pakub mugavat tööriista traabsanalyseerimise teabe kogumiseks võrgus, kuid tuleb mõista, et selle rakendamiseks tuleb oma süsteemi kohandada ja arvesse võtta Istio rakenduse eripära. Lõppkokkuvõttes tuleb lahendada kaks põhiprobleemi: rakendustasandi protokolli määratlemine (mida peaks toetama envoy proxy) ja teabe edastamise seadistamine nõudluste sidususe kohta teenuse nõuetelt teenustele (kasutades päiseid, juhul kui kasutada HTTP protokolli). Kui need küsimused on lahendatud, saame võimsa tööriista, mis võimaldab läbipaistvalt kogu teavet koguda isegi väga heterogeensetes süsteemides, mis on kirjutatud erinevates keeltes ja raamistikudes.

Järgmises artiklis Service Meshi kohta vaatame ühte suurimat Istio probleemi – iga sidecar proxy konteineri suur mälu tarbimine, ja arutame, kuidas selle vastu võidelda.

Allikas: habr.com