Istio kaj Kubernetes en produktado. Parto 2. Spurado

En la lasta artikolo Ni rigardis la bazajn komponantojn de Service Mesh Istio, konatiĝis kun la sistemo kaj respondis la ĉefajn demandojn, kiuj kutime aperas kiam oni komencas labori kun Istio. En ĉi tiu parto ni rigardos kiel organizi la kolekton de spuraj informoj tra reto.

La unua afero, kiu venas en la menson por multaj programistoj kaj sistemaj administrantoj, kiam ili aŭdas la vortojn Service Mesh, spuras. Efektive, ni aldonas specialan prokuran servilon al ĉiu retnodo tra kiu pasas la tuta TCP-trafiko. Ŝajnas, ke nun eblas facile sendi informojn pri ĉiuj retaj interagoj en la reto. Bedaŭrinde, fakte estas multaj nuancoj, kiujn oni devas konsideri. Ni rigardu ilin.

Miskompreniĝo numero unu: ni povas ricevi interretajn migrajn datumojn senpage.

Fakte, relative senpage, ni povas nur ricevi la nodojn de nia sistemo konektitaj per sagoj kaj la datumrapideco kiu pasas inter servoj (fakte, nur la nombro da bajtoj por unuo de tempo). Tamen, en la plej multaj kazoj, niaj servoj komunikas per ia apliktavola protokolo, kiel HTTP, gRPC, Redis, ktp. Kaj, kompreneble, ni volas vidi spurajn informojn specife por ĉi tiuj protokoloj; ni volas vidi la petan indicon, ne la datumrapidecon. Ni volas kompreni la latentecon de petoj uzante nian protokolon. Fine, ni volas vidi la plenan vojon, kiun peto prenas de ensaluti en nian sistemon ĝis ricevi respondon de la uzanto. Ĉi tiu problemo ne plu estas tiel facile solvebla.

Unue, ni rigardu, kiel aspektas sendado de spuro-spacoj el arkitektura vidpunkto en Istio. Kiel ni memoras de la unua parto, Istio havas apartan komponanton nomatan Miksilo por kolekti telemetrion. Tamen, en la nuna versio 1.0.*, sendo estas farita rekte de prokuraj serviloj, nome, de sendita prokurilo. Envoy-prokurilo subtenas sendi spurajn intervalojn uzante la zipkin-protokolon el la skatolo. Eblas konekti aliajn protokolojn, sed nur per kromaĵo. Kun Istio ni tuj ricevas kunvenitan kaj agorditan senditan prokurilon, kiu nur subtenas la zipkin-protokolon. Se ni volas uzi, ekzemple, la Jaeger-protokolon kaj sendi spurajn intervalojn per UDP, tiam ni devos konstrui nian propran istio-proxy-bildon. Estas subteno por kutimaj kromprogramoj por istio-proxy, sed ĝi ankoraŭ estas en la alfa versio. Sekve, se ni volas malhavi grandan nombron da kutimaj agordoj, la gamo de teknologioj uzataj por stoki kaj ricevi spurajn intervalojn estas reduktita. El la ĉefaj sistemoj, fakte, nun vi povas uzi Zipkin mem, aŭ Jaeger, sed sendi ĉion tien uzante la zipkin-kongruan protokolon (kiu estas multe malpli efika). La zipkin-protokolo mem implikas sendi ĉiujn spurajn informojn al kolektantoj per la HTTP-protokolo, kiu estas sufiĉe multekosta.

Kiel mi jam diris, ni volas spuri aplikaĵ-nivelajn protokolojn. Ĉi tio signifas, ke la prokuraj serviloj, kiuj staras apud ĉiu servo, devas kompreni kian interagon okazas nun. Defaŭlte, Istio agordas ĉiujn pordojn por esti simplaj TCP, kio signifas, ke neniuj spuroj estos senditaj. Por ke spuroj estu senditaj, vi devas unue ebligi ĉi tiun opcion en la ĉefa maŝo-agordo kaj, kio estas tre grava, nomi ĉiujn pordojn de kubernetes-servaj estaĵoj laŭ la protokolo uzata en la servo. Tio estas, ekzemple, jene:

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

Vi ankaŭ povas uzi kunmetitajn nomojn kiel http-magic (Istio vidos http kaj rekonos tiun pordon kiel http-finpunkto). La formato estas: pra-kromaĵo.

Por ne fliki grandan nombron da agordoj por determini la protokolon, vi povas uzi malpuran solvon: fliki la Pilot-komponenton en la momento, kiam ĝi ĵus estas. plenumas protokolan difinlogikon. En la fino, kompreneble, estos necese ŝanĝi ĉi tiun logikon al norma kaj ŝanĝi al nomkonvencio por ĉiuj havenoj.

Por kompreni ĉu la protokolo vere estas ĝuste difinita, vi devas iri en iun el la kromĉaroj ujoj kun sendita prokurilo kaj fari peton al la administra haveno de la sendita interfaco kun loko /config_dump. En la rezulta agordo, vi devas rigardi la operacian kampon de la dezirata servo. Ĝi estas uzata en Istio kiel identigilo por kie la peto estas farita. Por personecigi la valoron de ĉi tiu parametro en Istio (ni tiam vidos ĝin en nia spursistemo), necesas specifi la flagon de serviceCluster ĉe la etapo de lanĉo de la sidecar-ujo. Ekzemple, ĝi povas esti kalkulita tiel el variabloj akiritaj de la malsupreniĝa kubernetes API:

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

Bona ekzemplo por kompreni kiel spurado funkcias en sendito estas tie.

La finpunkto mem por sendado de spuraj interspacoj ankaŭ devas esti specifita en la senditaj prokuraj lanĉaj flagoj, ekzemple: --zipkinAddress tracing-collector.tracing:9411

Miskompreniĝo numero du: ni povas malmultekoste akiri kompletajn spurojn de petoj per la sistemo el la skatolo

Bedaŭrinde, ĝi ne estas. La komplekseco de efektivigo dependas de kiel vi jam efektivigis la interagadon de servoj. Kial estas tio?

La fakto estas, ke por ke istio-proxy povu kompreni la korespondadon de envenantaj petoj al servo kun tiuj, kiuj forlasas la saman servon, ne sufiĉas simple interkapti la tutan trafikon. Vi devas havi ian komunikan identigilon. HTTP sendita prokurilo uzas specialajn titolojn, per kiuj sendito komprenas, kiu specifa peto al la servo generas specifajn petojn al aliaj servoj. Listo de tiaj kaplinioj:

• x-peto-id,
• x-b3-traceid,
• x-b3-spanid,
• x-b3-parentspanid,
• x-b3-specimeta,
• x-b3-flagoj,
• x-ot-span-kunteksto.

Se vi havas ununuran punkton, ekzemple bazan klienton, en kiu vi povas aldoni tian logikon, tiam ĉio estas en ordo, vi nur bezonas atendi, ke ĉi tiu biblioteko estos ĝisdatigita por ĉiuj klientoj. Sed se vi havas tre heterogenan sistemon kaj ne estas unuiĝo en moviĝado de servo al servo tra la reto, tiam ĉi tio plej verŝajne estos granda problemo. Sen aldoni tian logikon, ĉiuj spuraj informoj estos nur "ununivela". Tio estas, ni ricevos ĉiujn inter-servajn interagojn, sed ili ne estos gluitaj en ununurajn ĉenojn de trairejo tra la reto.

konkludo

Istio provizas oportunan ilon por kolekti spurajn informojn tra reto, sed vi devas kompreni, ke por efektivigo vi devos adapti vian sistemon kaj konsideri la funkciojn de la Istio-efektivigo. Kiel rezulto, du ĉefaj punktoj devas esti solvitaj: difini la aplikaĵnivelan protokolon (kiu devas esti subtenata de la sendita prokurilo) kaj starigi la plusendon de informoj pri la ligo de petoj al la servo de petoj de la servo (uzante kapliniojn). , en la kazo de la HTTP-protokolo). Kiam ĉi tiuj problemoj estas solvitaj, ni havas potencan ilon, kiu ebligas al ni travideble kolekti informojn de la reto, eĉ en tre heterogenaj sistemoj skribitaj en multaj malsamaj lingvoj kaj kadroj.

En la sekva artikolo pri Service Mesh, ni rigardos unu el la plej grandaj problemoj kun Istio - la granda konsumo de RAM de ĉiu kromĉara prokurujo kaj diskutos kiel vi povas trakti ĝin.

fonto: www.habr.com