ProHoster > Blogs > Administrācija > Istio un Kubernetes ražoŔanā. 2. daļa. IzsekoŔana

Istio un Kubernetes ražoŔanā. 2. daļa. IzsekoŔana

Pagātnē raksts ApskatÄ«jām Service Mesh Istio pamatkomponentus, iepazināmies ar sistēmu un atbildējām uz galvenajiem jautājumiem, kas parasti rodas uzsākot darbu ar Istio. Å ajā daļā apskatÄ«sim, kā organizēt izsekoÅ”anas informācijas vākÅ”anu tÄ«klā.

Istio un Kubernetes ražoŔanā. 2. daļa. IzsekoŔana

Pirmā lieta, kas daudziem izstrādātājiem un sistēmu administratoriem ienāk prātā, dzirdot vārdus Service Mesh is tracing. PatieŔām, katram tÄ«kla mezglam, caur kuru iet visa TCP trafika, mēs pievienojam Ä«paÅ”u starpniekserveri. Å Ä·iet, ka tagad ir iespējams viegli nosÅ«tÄ«t informāciju par visām tÄ«kla mijiedarbÄ«bām tÄ«klā. Diemžēl patiesÄ«bā ir daudz nianÅ”u, kas jāņem vērā. ApskatÄ«sim tos.

Nepareizs uzskats numur viens: mēs varam iegÅ«t tieÅ”saistes pārgājienu datus bez maksas.

Faktiski salÄ«dzinoÅ”i bez maksas mēs varam iegÅ«t tikai mÅ«su sistēmas mezglus, kas savienoti ar bultiņām un datu pārraides ātrumu starp pakalpojumiem (patiesÄ«bā tikai baitu skaits laika vienÄ«bā). Tomēr vairumā gadÄ«jumu mÅ«su pakalpojumi sazinās, izmantojot kādu lietojumprogrammas slāņa protokolu, piemēram, HTTP, gRPC, Redis un tā tālāk. Un, protams, mēs vēlamies redzēt izsekoÅ”anas informāciju tieÅ”i Å”iem protokoliem; mēs vēlamies redzēt pieprasÄ«juma ātrumu, nevis datu pārraides ātrumu. Mēs vēlamies izprast pieprasÄ«jumu latentumu, izmantojot mÅ«su protokolu. Visbeidzot, mēs vēlamies redzēt pilnu ceļu, kāds pieprasÄ«jumam nepiecieÅ”ams no pieteikÅ”anās mÅ«su sistēmā lÄ«dz atbildes saņemÅ”anai no lietotāja. Å o problēmu vairs nav tik vienkārÅ”i atrisināt.

Vispirms apskatÄ«sim, kā Istio arhitektÅ«ras skatÄ«jumā izskatās izsekoÅ”anas posmu nosÅ«tÄ«Å”ana. Kā mēs atceramies no pirmās daļas, Istio ir atseviŔķs komponents ar nosaukumu Mixer telemetrijas apkopoÅ”anai. Taču paÅ”reizējā versijā 1.0.* sÅ«tÄ«Å”ana notiek tieÅ”i no starpniekserveriem, proti, no sÅ«tņa starpniekservera. SÅ«tņa starpniekserveris atbalsta izsekoÅ”anas posmu nosÅ«tÄ«Å”anu, izmantojot zipkin protokolu. Ir iespējams pieslēgt citus protokolus, bet tikai caur spraudni. Izmantojot Istio, mēs nekavējoties iegÅ«stam samontētu un konfigurētu sÅ«tņa starpniekserveri, kas atbalsta tikai zipkin protokolu. Ja mēs vēlamies izmantot, piemēram, Jaeger protokolu un sÅ«tÄ«t izsekoÅ”anas posmus, izmantojot UDP, mums bÅ«s jāizveido savs istio-starpniekservera attēls. Ir pieejams pielāgotu spraudņu atbalsts istio-proxy, taču tas joprojām ir alfa versijā. Tāpēc, ja vēlamies iztikt bez liela skaita pielāgotu iestatÄ«jumu, tiek samazināts izsekoÅ”anas diapazonu glabāŔanai un saņemÅ”anai izmantoto tehnoloÄ£iju klāsts. No galvenajām sistēmām tagad jÅ«s varat izmantot paÅ”u Zipkin vai Jaeger, bet sÅ«tÄ«t visu, izmantojot zipkin saderÄ«gu protokolu (kas ir daudz mazāk efektÄ«vs). Zipkin protokols pats par sevi ietver visas izsekoÅ”anas informācijas nosÅ«tÄ«Å”anu kolekcionāriem, izmantojot HTTP protokolu, kas ir diezgan dārgs.

Kā jau teicu, mēs vēlamies izsekot lietojumprogrammu lÄ«meņa protokoliem. Tas nozÄ«mē, ka starpniekserveriem, kas atrodas blakus katram pakalpojumam, ir jāsaprot, kāda veida mijiedarbÄ«ba notiek tagad. Pēc noklusējuma Istio konfigurē visus portus kā vienkārÅ”us TCP, kas nozÄ«mē, ka netiks nosÅ«tÄ«ti pēdas. Lai izsekoÅ”ana tiktu nosÅ«tÄ«ta, jums, pirmkārt, ir jāiespējo Ŕī opcija galvenajā tÄ«kla konfigurācijā un, kas ir ļoti svarÄ«gi, jānosauc visi kubernetes pakalpojumu entÄ«tiju porti saskaņā ar protokolu, kas tiek izmantots pakalpojumā. Tas ir, piemēram, Ŕādi:

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

Varat arÄ« izmantot saliktos nosaukumus, piemēram, http-magic (Istio redzēs http un atpazÄ«s Å”o portu kā http galapunktu). Formāts ir: proto-extra.

Lai protokola noteikÅ”anai netiktu ielāgots liels skaits konfigurāciju, varat izmantot netÄ«ru risinājumu: izlabojiet Pilot komponentu brÄ«dÄ«, kad tas ir tikai veic protokola definÄ«cijas loÄ£iku. Galu galā, protams, bÅ«s jāmaina Ŕī loÄ£ika uz standarta un jāpārslēdzas uz visu portu nosaukumu pieŔķirÅ”anas kārtÄ«bu.

Lai saprastu, vai protokols tieŔām ir definēts pareizi, jāieiet kādā no blakusvāģu konteineriem ar sÅ«tņa starpniekserveri un jāiesniedz pieprasÄ«jums sÅ«tņa interfeisa admin portam ar atraÅ”anās vietu /config_dump. IegÅ«tajā konfigurācijā ir jāaplÅ«ko vēlamā pakalpojuma darbÄ«bas lauks. Istio tas tiek izmantots kā pieprasÄ«juma iesniegÅ”anas vietas identifikators. Lai pielāgotu Ŕī parametra vērtÄ«bu Istio (pēc tam mēs to redzēsim mÅ«su izsekoÅ”anas sistēmā), blakusvāģa konteinera palaiÅ”anas posmā ir jānorāda serviceCluster karodziņŔ. Piemēram, to var aprēķināt Ŕādi, izmantojot mainÄ«gos lielumus, kas iegÅ«ti no lejupvērstās kubernetes API:

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

Labs piemērs, lai saprastu, kā notiek izsekoÅ”ana sÅ«tnÄ« Å”eit.

Pats galapunkts izsekoÅ”anas diapazonu nosÅ«tÄ«Å”anai ir jānorāda arÄ« sÅ«tņa starpniekservera palaiÅ”anas karodziņās, piemēram: --zipkinAddress tracing-collector.tracing:9411

Nepareizs priekÅ”stats numur divi: mēs varam lēti iegÅ«t pilnÄ«gas pieprasÄ«jumu pēdas, izmantojot sistēmu no kastes

Diemžēl tā nav. IevieÅ”anas sarežģītÄ«ba ir atkarÄ«ga no tā, kā jÅ«s jau esat ieviesis pakalpojumu mijiedarbÄ«bu. Kāpēc ir tā, ka?

Fakts ir tāds, ka, lai istio-proxy varētu saprast pakalpojumam ienākoÅ”o pieprasÄ«jumu atbilstÄ«bu tiem, kas atstāj to paÅ”u pakalpojumu, nepietiek tikai ar visas trafika pārtverÅ”anu. Jums ir jābÅ«t sava veida saziņas identifikatoram. HTTP sÅ«tņa starpniekserveris izmanto Ä«paÅ”as galvenes, ar kurām sÅ«tnis saprot, kurÅ” konkrētais pakalpojuma pieprasÄ«jums Ä£enerē Ä«paÅ”us pieprasÄ«jumus citiem pakalpojumiem. Šādu virsrakstu saraksts:

  • x-pieprasÄ«juma ID,
  • x-b3-traceid,
  • x-b3-spanid,
  • x-b3-parentsspanid,
  • x-b3-izlase,
  • x-b3 karogi,
  • x-ot-span-konteksts.

Ja jums ir viens punkts, piemēram, pamata klients, kurā varat pievienot Ŕādu loÄ£iku, tad viss ir kārtÄ«bā, jums tikai jāgaida, lÄ«dz Ŕī bibliotēka tiks atjaunināta visiem klientiem. Bet, ja jums ir ļoti neviendabÄ«ga sistēma un pārejot no pakalpojuma uz pakalpojumu tÄ«klā nav vienotÄ«bas, visticamāk, tā bÅ«s liela problēma. Nepievienojot Ŕādu loÄ£iku, visa izsekoÅ”anas informācija bÅ«s tikai ā€œviena lÄ«meņaā€. Tas ir, mēs saņemsim visas starpdienestu mijiedarbÄ«bas, taču tās netiks salÄ«mētas atseviŔķās tÄ«kla caurbraukÅ”anas ķēdēs.

Secinājums

Istio nodroÅ”ina ērtu rÄ«ku izsekoÅ”anas informācijas vākÅ”anai tÄ«klā, taču jums jāsaprot, ka ievieÅ”anai jums bÅ«s jāpielāgo sistēma un jāņem vērā Istio ievieÅ”anas iespējas. Rezultātā ir jāatrisina divi galvenie punkti: lietojumprogrammas lÄ«meņa protokola noteikÅ”ana (kas jāatbalsta sÅ«tņa starpniekserverim) un informācijas pārsÅ«tÄ«Å”anas iestatÄ«Å”ana par pieprasÄ«jumu savienoÅ”anu ar pakalpojumu no dienesta pieprasÄ«jumiem (izmantojot galvenes , HTTP protokola gadÄ«jumā). Kad Ŕīs problēmas ir atrisinātas, mums ir jaudÄ«gs rÄ«ks, kas ļauj pārredzami vākt informāciju no tÄ«kla pat ļoti neviendabÄ«gās sistēmās, kas rakstÄ«tas daudzās dažādās valodās un ietvaros.

Nākamajā rakstā par Service Mesh mēs apskatÄ«sim vienu no lielākajām Istio problēmām ā€” lielo RAM patēriņu katrā blakusvāģa starpniekservera konteinerā un apspriedÄ«sim, kā ar to tikt galā.

Avots: www.habr.com

Pievieno komentāru