🥇Վերադարձ դեպի միկրոսերվիսներ Istio-ի հետ։ Մաս 1

Նշում. թարգմ.Ծառայությունների ցանցերը, անկասկած, դարձել են թեժ թեմա այսօրվա ենթակառուցվածքում միկրոսպասարկման ճարտարապետությանը հետևող հավելվածների համար: Թեև Istio-ն կարող է հայտնվել DevOps-ի շատ ինժեներների ռադարում, այն բավականին նոր արտադրանք է, որը, թեև իր տրամադրած առանձնահատկությունների առումով բարդ է, կարող է զգալի ժամանակ պահանջել ծանոթանալու համար: Գերմանացի ինժեներ Ռինոր Մալոկուն, ով Orange Networks հեռահաղորդակցական ընկերության խոշոր հաճախորդների համար պատասխանատու է ամպային հաշվարկի համար, գրել է մի հրաշալի նյութեր, որոնք թույլ են տալիս արագ և խորը սուզվել Իստիոում: Նա սկսում է իր պատմությունը նրանով, թե ինչ կարող է անել Իստիոն և ինչպես կարող ես արագ տեսնել այն քո աչքերով:

Իստիո — Բաց կոդով նախագիծ, որը մշակվել է Google-ի, IBM-ի և Lyft-ի թիմերի հետ համատեղ: Այն լուծում է այն բարդությունները, որոնք առաջանում են միկրոծառայությունների վրա հիմնված հավելվածներում, օրինակ՝

երթեւեկության կառավարումժամանակի ընդհատումներ, կրկնվող փորձեր, բեռի հավասարակշռում;
Безопасностьվերջնական օգտագործողի նույնականացում և թույլտվություն;
դիտելիությունՀետագծում, մոնիտորինգ, անտառահատում:

Դրանք բոլորը կարող են լուծվել հավելվածի մակարդակով, սակայն դրանից հետո ձեր ծառայություններն այլևս «միկրո» չեն լինի։ Այս խնդիրները լուծելու համար լրացուցիչ ջանքերը ընկերության ռեսուրսների վատնում են, որոնք կարող են ուղղակիորեն օգտագործվել բիզնեսի արժեքի համար: Դիտարկենք մի օրինակ.

Ծրագրի ղեկավար. Որքա՞ն ժամանակ է պահանջվում հետադարձ կապի հատկանիշ ավելացնելու համար:
Մշակողը. Երկու սպրինտ:

Պատգամավոր- Ի՞նչ... Ուղղակի ԿՈՒՅԹ է։
R: CRUD-ի կատարումը առաջադրանքի հեշտ մասն է, բայց մենք դեռ պետք է վավերացնենք և լիազորենք օգտվողներին և ծառայություններին: Քանի որ ցանցն անվստահելի է, ձեզ հարկավոր կլինի կրկնակի հարցումներ իրականացնել, ինչպես նաև անջատիչի օրինաչափություն հաճախորդների մեջ: Նաև համոզվելու համար, որ ամբողջ համակարգը չի խափանում, թայմաութներ և միջնորմներ (Տես ավելի ուշ հոդվածում նշված երկու օրինաչափությունների վերաբերյալ լրացուցիչ մանրամասների համար):և խնդիրներ հայտնաբերելու նպատակով՝ մոնիտորինգ, հետագծում, […]
Պատգամավոր. Օհ, եկեք այս հնարավորությունը տեղադրենք Ապրանքի ծառայության մեջ:

Կարծում եմ՝ գաղափարը պարզ է. մեկ ծառայություն ավելացնելու համար անհրաժեշտ քայլերի և ջանքերի քանակը հսկայական է: Այս հոդվածում մենք կանդրադառնանք, թե ինչպես է Istio-ն հեռացնում վերը նշված բոլոր բարդությունները (առանց բիզնես տրամաբանության թիրախում) ծառայություններից:

ՆշումՀոդվածը ենթադրում է, որ դուք աշխատանքային գիտելիքներ ունեք Kubernetes-ի մասին։ Հակառակ դեպքում խորհուրդ եմ տալիս կարդալ իմ ծանոթությունը Kubernetes-ին և միայն դրանից հետո շարունակեք կարդալ այս նյութը:

Իստիո գաղափար

Աշխարհում առանց Istio-ի, մի ծառայությունն ուղիղ հարցումներ է կատարում մյուսին, և ձախողման դեպքում ծառայությունը պետք է ինքնուրույն զբաղվի դրանով.

Ցանցային տրաֆիկ Kubernetes-ում

Istio-ն, մյուս կողմից, առաջարկում է մասնագիտացված լուծում, որը լիովին անջատված է ծառայություններից և գործառույթներից՝ խոչընդոտելով ցանցային փոխգործակցությանը: Եվ այսպես, այն իրականացնում է.

սխալների հանդուրժողականություն: հիմնվելով պատասխանում առկա կարգավիճակի կոդի վրա, նա հասկանում է, թե արդյոք հարցումը ձախողվել է, և նորից ներկայացնում է այն:
Canary Rollouts: վերահղում է հարցումների միայն ֆիքսված տոկոսը ծառայության նոր տարբերակին:
Մոնիտորինգ և չափումներ: Որքա՞ն ժամանակ է պահանջվել ծառայության արձագանքման համար:
Հետագծում և դիտելիությունՅուրաքանչյուր հարցումին ավելացնում է հատուկ վերնագրեր և հետագծում դրանք կլաստերի վրա:
БезопасностьԱռբերում է JWT նշանը, նույնականացնում և լիազորում է օգտատերերին:

Սրանք ընդամենը մի քանի հնարավորություններ են (իսկապես մի քանիսը) ձեզ ինտրիգ տալու համար: Հիմա եկեք սուզվենք տեխնիկական մանրամասների մեջ:

Ճարտարապետություն

Istio-ն ընդհատում է ցանցի ողջ տրաֆիկը և կիրառում դրա նկատմամբ մի շարք կանոններ՝ յուրաքանչյուր պատի մեջ տեղադրելով խելացի վստահված անձի՝ կողային բեռնարկղի տեսքով: Բոլոր հնարավորությունները ակտիվացնող պրոքսիները կազմում են ա Տվյալների հարթություն, և դրանք կարող են դինամիկ կերպով ճշգրտվել Կառավարման ինքնաթիռ.

Տվյալների հարթություն

Պրոքսիները, որոնք տեղադրված են պատյանների մեջ, թույլ են տալիս Istio-ին հեշտությամբ հասնել մեզ անհրաժեշտ պահանջներին: Օրինակ, եկեք ստուգենք կրկնակի փորձերը և անջատիչի գործառույթները:

Ինչպես են կրկնակի փորձերը և անջատումը իրականացվում Envoy-ում

Ամփոփելով `

պատվիրակ (խոսքը կողային բեռնարկղում տեղակայված վստահված անձի մասին է, որը և ինչպես է բաշխվում առանձին ապրանք - մոտ. թարգմ.) հարցում է ուղարկում B ծառայության առաջին ատյանի և ձախողվում:
Բանագնաց Սայդքարը կրկին փորձում է (կրկին փորձիր). (1)
Չհաջողված հարցումը վերադարձվում է վստահված անձին, որը զանգահարել է այն:
Սա բացում է անջատիչը և կանչում է հաջորդ ծառայությունը հետագա հարցումների համար: (2)

Սա նշանակում է, որ դուք չպետք է օգտագործեք հաջորդ Retry գրադարանը, դուք չունեք ձեր սեփական ներդրումը Circuit Breaking և Service Discovery X, Y կամ Z ծրագրավորման լեզուներով: Այս ամենը և ավելին հասանելի է տուփ Istio-ում և չի պահանջում ոչ ծածկագրի փոփոխությունները.

Հիանալի Այժմ դուք կարող եք ցանկանալ ճանապարհորդության գնալ Իստիոյի հետ, բայց դեռ կան որոշ կասկածներ, բաց հարցեր: Եթե սա համընդհանուր լուծում է կյանքի բոլոր առիթների համար, ապա դուք հիմնավոր կասկած ունեք՝ ի վերջո, բոլոր նման լուծումներն իրականում հարմար չեն ոչ մի դեպքի համար։

Եվ վերջապես դուք հարցնում եք. «Արդյո՞ք այն հարմարեցված է»:

Այժմ դուք պատրաստ եք ծովային ճանապարհորդության, և եկեք ծանոթանանք Control Plane-ին:

Կառավարման ինքնաթիռ

Այն բաղկացած է երեք բաղադրիչներից. Օդաչու, Խառնիչ и Միջնաբերդ, որոնք միասին կազմաձևում են Բանագնացներին՝ երթևեկության ուղղորդելու, քաղաքականություն կիրառելու և հեռաչափության տվյալներ հավաքելու համար: Սխեմատիկորեն ամեն ինչ այսպիսի տեսք ունի.

Կառավարման հարթության փոխազդեցությունը տվյալների հարթության հետ

Բանագնացները (այսինքն՝ տվյալների հարթությունը) կազմաձևված են Kubernetes CRD (Custom Resource Definitions), որը սահմանվել է Istio-ի կողմից և հատուկ նախագծված է այդ նպատակով: Սա ձեզ համար նշանակում է, որ դրանք ընդամենը մեկ այլ ռեսուրս են Kubernetes-ում՝ ծանոթ շարահյուսությամբ: Ստեղծվելուց հետո այս ռեսուրսը կվերցվի կառավարման ինքնաթիռի կողմից և կկիրառվի Բանագնացներին:

Ծառայությունների կապը Իստիո

Մենք նկարագրել ենք Istio-ի հարաբերությունները ծառայությունների հետ, բայց ոչ հակառակը. ինչպե՞ս են ծառայությունները կապված Istio-ի հետ:

Անկեղծ ասած, ծառայությունները գիտեն Իստիոյի առկայության մասին, ինչպես նաև ձկները գիտեն ջրի մասին, երբ իրենք իրենց հարցնում են. «Ի՞նչ է ջուրն այնուամենայնիվ»:

Նկարազարդում Վիկտորյա Դիմիտրակոպուլոս:Ինչպե՞ս եք սիրում ջուրը: -Ի՞նչ է ջուրն այնուամենայնիվ:

Այսպիսով, դուք կարող եք վերցնել աշխատանքային կլաստեր, և Istio բաղադրիչները տեղակայելուց հետո այնտեղ գտնվող ծառայությունները կշարունակեն աշխատել, և այս բաղադրիչները հեռացնելուց հետո ամեն ինչ նորից լավ կլինի: Հասկանալի է, որ այս դեպքում դուք կկորցնեք Իստիոյի ընձեռած հնարավորությունները։

Բավական տեսություն. եկեք այս գիտելիքը գործնականում կիրառենք:

Իստիոն գործնականում

Istio-ն պահանջում է Kubernetes կլաստեր՝ առնվազն 4 vCPU-ով և 8 ԳԲ օպերատիվ հիշողությամբ: Կլաստերը արագ բարձրացնելու և հոդվածի հրահանգներին հետևելու համար խորհուրդ եմ տալիս օգտագործել Google Cloud Platform-ը, որն առաջարկում է նոր օգտվողներին անվճար $300.

Կլաստերը ստեղծելուց և «Կուբերնետես» մուտքը «Կուբերնետես» կոնսոլային կոմունալ ծրագրի միջոցով կարգավորելուց հետո կարող եք տեղադրել Istio-ն Helm փաթեթի կառավարչի միջոցով:

Սաղավարտի տեղադրում

Տեղադրեք Helm հաճախորդը ձեր համակարգչում, ինչպես նկարագրված է պաշտոնական փաստաթղթեր. Մենք կօգտագործենք այն հաջորդ բաժնում Istio-ի տեղադրման կաղապարներ ստեղծելու համար:

Տեղադրում

Ներբեռնեք Istio ռեսուրսները վերջին թողարկումը (1.0.5 տարբերակի սկզբնական հեղինակի հղումը փոխվել է ներկայիս, այսինքն՝ 1.0.6 - մոտավորապես թարգմանություն), հանեք բովանդակությունը մեկ գրացուցակում, որը ես կանվանեմ որպես [istio-resources].

Istio ռեսուրսների հեշտ նույնականացման համար K8s կլաստերում ստեղծեք անվանատարածք istio-system:

$ kubectl create namespace istio-system

Ավարտեք տեղադրումը` նավարկելով գրացուցակ [istio-resources] և գործարկել հրամանը.

$ helm template install/kubernetes/helm/istio 
  --set global.mtls.enabled=false 
  --set tracing.enabled=true 
  --set kiali.enabled=true 
  --set grafana.enabled=true 
  --namespace istio-system > istio.yaml

Այս հրամանը Istio-ի հիմնական բաղադրիչները կթողարկի ֆայլ istio.yaml. Մենք փոփոխել ենք ստանդարտ ձևանմուշը մեզ համար՝ նշելով հետևյալ պարամետրերը.

global.mtls.enabled տեղադրված է false (այսինքն mTLS նույնականացումը անջատված է - մոտավորապես թարգմանություն)պարզեցնել մեր ծանոթությունների գործընթացը;
tracing.enabled հնարավորություն է տալիս հարցումների հետագծումը Jaeger-ի հետ.
kiali.enabled տեղադրում է Kiali-ն կլաստերի մեջ՝ ծառայություններն ու երթևեկությունը պատկերացնելու համար.
grafana.enabled տեղադրում է Grafana-ն՝ հավաքված չափումները պատկերացնելու համար:

Կիրառեք ստեղծված ռեսուրսները հրամանով.

$ kubectl apply -f istio.yaml

Istio-ի տեղադրումը կլաստերում ավարտված է: Սպասեք մինչև բոլոր պատիճները անունների տարածքում istio-system կկարողանան Running կամ Completedգործարկելով ստորև նշված հրամանը.

$ kubectl get pods -n istio-system

Այժմ մենք պատրաստ ենք շարունակել հաջորդ բաժինը, որտեղ կբարձրացնենք և գործարկենք հավելվածը:

Զգացմունքների վերլուծության կիրառական ճարտարապետություն

Օգտվենք արդեն նշվածում օգտագործված Sentiment Analysis microservice հավելվածի օրինակից Կուբերնետեսի ներածական հոդված. Այն բավական բարդ է Իստիոյի հնարավորությունները գործնականում ցույց տալու համար:

Հավելվածը բաղկացած է չորս միկրոծառայություններից.

Ծառայություն SA-Frontend, որը սպասարկում է ճակատային հավելվածը Reactjs-ում;
Ծառայություն SA WebApp, որը սպասարկում է զգացմունքների վերլուծության հարցումներ;
Ծառայություն SA Logicորն ինքն է կատարում տրամադրությունների վերլուծություն;
Ծառայություն SA Հետադարձ կապ, որն օգտատերերից արձագանք է ստանում կատարված վերլուծության ճշգրտության վերաբերյալ։

Այս դիագրամում, բացի ծառայություններից, մենք տեսնում ենք նաև Ingress Controller-ը, որը Kubernetes-ում մուտքային հարցումները ուղղորդում է դեպի համապատասխան ծառայություններ: Istio-ն օգտագործում է նմանատիպ հայեցակարգ՝ որպես Ingress Gateway-ի մաս, որի մանրամասները կհետևեն:

Istio-ից վստահված անձի հետ հավելվածի գործարկում

Հոդվածում նշված հետագա գործողությունների համար կլոնավորեք ձեր պահոցը istio-վարպետություն. Այն պարունակում է հավելված և դրսևորվում է Kubernetes-ի և Istio-ի համար:

Կողային սալիկների տեղադրում

Տեղադրումը կարող է կատարվել ավտոմատ կամ ձեռքով. Կողքի բեռնարկղերի ավտոմատ տեղադրման համար դուք պետք է պիտակը սահմանեք անվանատարածքի վրա istio-injection=enabled, որը կատարվում է հետևյալ հրամանով.

$ kubectl label namespace default istio-injection=enabled
namespace/default labeled

Այժմ յուրաքանչյուր պատիճ, որը կտեղակայվի լռելյայն անվանատարածքում (default) կստանա իր կողային բեռնարկղը: Սա ստուգելու համար եկեք գործարկենք թեստային հավելված՝ անցնելով պահեստի արմատային գրացուցակ [istio-mastery] և գործարկել հետևյալ հրամանը.

$ kubectl apply -f resource-manifests/kube
persistentvolumeclaim/sqlite-pvc created
deployment.extensions/sa-feedback created
service/sa-feedback created
deployment.extensions/sa-frontend created
service/sa-frontend created
deployment.extensions/sa-logic created
service/sa-logic created
deployment.extensions/sa-web-app created
service/sa-web-app created

Ծառայությունները տեղակայելուց հետո ստուգեք, որ պատիճներն ունեն յուրաքանչյուրը երկու կոնտեյներ (ծառայությամբ ինքնին և դրա կողքին)՝ գործարկելով հրամանը kubectl get pods և համոզվելով, որ սյունակի տակ READY նշված արժեքը 2/2, որը խորհրդանշում է, որ երկու բեռնարկղերն էլ աշխատում են.

$ kubectl get pods
NAME                           READY     STATUS    RESTARTS   AGE
sa-feedback-55f5dc4d9c-c9wfv   2/2       Running   0          12m
sa-frontend-558f8986-hhkj9     2/2       Running   0          12m
sa-logic-568498cb4d-2sjwj      2/2       Running   0          12m
sa-logic-568498cb4d-p4f8c      2/2       Running   0          12m
sa-web-app-599cf47c7c-s7cvd    2/2       Running   0          12m

Տեսողականորեն այն նման է հետևյալին.

Բանագնաց վստահված անձը պատյաններից մեկում

Այժմ, երբ հավելվածը գործարկված է և աշխատում է, մենք պետք է թույլ տանք մուտքային տրաֆիկը մուտք գործել հավելված:

Ingress Gateway

Դրան հասնելու լավագույն պրակտիկան (թույլ տալ երթևեկությունը կլաստերում) միջոցով է Ingress Gateway Istio-ում, որը գտնվում է կլաստերի «եզրին» և թույլ է տալիս միացնել Istio-ի այնպիսի գործառույթներ, ինչպիսիք են երթուղին, բեռների հավասարակշռումը, անվտանգությունը և մուտքային երթևեկության մոնիտորինգը:

Ingress Gateway բաղադրիչը և այն դեպի դուրս փոխանցող ծառայությունը տեղադրվել են կլաստերի վրա Istio-ի տեղադրման ժամանակ: Ծառայության արտաքին IP հասցեն պարզելու համար գործարկեք՝

$ kubectl get svc -n istio-system -l istio=ingressgateway
NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP
istio-ingressgateway   LoadBalancer   10.0.132.127   13.93.30.120

Մենք կշարունակենք մուտք գործել հավելված՝ օգտագործելով այս IP-ն (ես այն կանվանեմ որպես EXTERNAL-IP), այնպես որ հարմարության համար մենք արժեքը կգրենք փոփոխականի վրա.

$ EXTERNAL_IP=$(kubectl get svc -n istio-system 
  -l app=istio-ingressgateway 
  -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')

Եթե հիմա փորձեք մուտք գործել այս IP-ն բրաուզերի միջոցով, դուք կստանաք «Ծառայության անհասանելի» սխալ, քանի որ լռելյայնորեն Istio-ն արգելափակում է բոլոր մուտքային տրաֆիկըմինչև Gateway-ը սահմանվի:

Gateway ռեսուրս

Gateway-ը CRD (Custom Resource Definition) է Kubernetes-ում, որը սահմանվել է Istio-ն կլաստերի մեջ տեղադրելուց հետո և հնարավորություն է տալիս նշելու նավահանգիստները, արձանագրությունը և հոստերերը, որոնց համար մենք ցանկանում ենք թույլատրել մուտքային տրաֆիկը:

Մեր դեպքում, մենք ցանկանում ենք թույլատրել HTTP տրաֆիկը 80 նավահանգստում բոլոր հոսթերների համար: Խնդիրն իրականացվում է հետևյալ սահմանմամբ (http-gateway.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: http-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
- "*"

Այս կոնֆիգուրացիան բացատրության կարիք չունի, բացառությամբ ընտրիչի istio: ingressgateway. Այս ընտրիչով մենք կարող ենք նշել, թե որ Ingress Gateway-ի վրա կիրառել կոնֆիգուրացիան: Մեր դեպքում սա Ingress Gateway վերահսկիչն է, որը լռելյայն տեղադրվել է Istio-ում:

Կազմաձևը կիրառվում է՝ կանչելով հետևյալ հրամանը.

$ kubectl apply -f resource-manifests/istio/http-gateway.yaml gateway.networking.istio.io/http-gateway created

Դարպասն այժմ թույլ է տալիս մուտք գործել 80 նավահանգիստ, սակայն գաղափար չունի, թե որտեղ ուղղորդել հարցումները: Դրա համար ձեզ հարկավոր կլինի Վիրտուալ ծառայություններ.

Վիրտուալ ծառայության ռեսուրս

VirtualService-ը Ingress Gateway-ին ասում է, թե ինչպես ուղղորդել հարցումները, որոնք թույլատրված են կլաստերի ներսում:

Մեր դիմումին ուղղված հարցումները, որոնք գալիս են http-gateway-ով, պետք է ուղարկվեն sa-frontend, sa-web-app և sa-հետադարձ կապի ծառայություններ.

Երթուղիներ, որոնք պետք է կազմաձևվեն VirtualServices-ի հետ

Հաշվի առեք այն հարցումները, որոնք պետք է ուղարկվեն SA-Frontend-ին.

Ճշգրիտ համընկնում ճանապարհին / պետք է ուղարկվի SA-Frontend՝ index.html ստանալու համար;
Ճանապարհներ նախածանցով /static/* պետք է ուղարկվի SA-Frontend՝ ստատիկ ֆայլեր ստանալու համար, որոնք օգտագործվում են frontend-ում, ինչպիսիք են CSS-ը և JavaScript-ը;
Կանոնավոր արտահայտությանը համապատասխանող ուղիներ '^.*.(ico|png|jpg)$', պետք է ուղարկվի SA-Frontend, քանի որ Սրանք էջում ցուցադրված նկարներն են։

Իրականացումը կատարվում է հետևյալ կազմաձևով (sa-virtualservice-external.yaml):

kind: VirtualService metadata: name: sa-external-services spec: hosts: - "*" gateways: - http-gateway # 1 http: - match: - uri: exact: / - uri: exact: /callback - uri: prefix: /static - uri: regex: '^.*.(ico|png|jpg) Важные моменты: Этот VirtualService относится к запросам, приходящим через http-gateway; В destination определяется сервис, куда отправляются запросы. Примечание: Конфигурация выше хранится в файле sa-virtualservice-external.yaml, который также содержит настройки для маршрутизации в SA-WebApp и SA-Feedback, но был сокращён здесь в статье для лаконичности. Применим VirtualService вызовом: $ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml virtualservice.networking.istio.io/sa-external-services created Примечание: Когда мы применяем ресурсы Istio, Kubernetes API Server создаёт событие, которое получает Istio Control Plane, и уже после этого новая конфигурация применяется к прокси-серверам Envoy каждого pod'а. А контроллер Ingress Gateway представляется очередным Envoy, сконфигурированным в Control Plane. Всё это на схеме выглядит так: Конфигурация Istio-IngressGateway для маршрутизации запросов Приложение Sentiment Analysis стало доступным по http://{EXTERNAL-IP}/. Не переживайте, если вы получаете статус Not Found: иногда требуется чуть больше времени для того, чтобы конфигурация вступила в силу и кэши Envoy обновились. Перед тем, как продолжить, поработайте немного с приложением, чтобы сгенерировать трафик (его наличие необходимо для наглядности в последующих действиях — прим. перев.). Kiali : наблюдаемость Чтобы попасть в административный интерфейс Kiali, выполните следующую команду: $ kubectl port-forward $(kubectl get pod -n istio-system -l app=kiali -o jsonpath='{.items[0].metadata.name}') -n istio-system 20001 … и откройте http://localhost:20001/, залогинившись под admin/admin. Здесь вы найдете множество полезных возможностей, например, для проверки конфигурации компонентов Istio, визуализации сервисов по информации, собранной при перехвате сетевых запросов, получения ответов на вопросы «Кто к кому обращается?», «У какой версии сервиса возникают сбои?» и т.п. В общем, изучите возможности Kiali перед тем, как двигаться дальше — к визуализации метрик с Grafana. Grafana: визуализация метрик Собранные в Istio метрики попадают в Prometheus и визуализируются с Grafana. Чтобы попасть в административный интерфейс Grafana, выполните команду ниже, после чего откройте http://localhost:3000/: $ kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=grafana -o jsonpath={.items[0].metadata.name}) 3000 Кликнув на меню Home слева сверху и выбрав Istio Service Dashboard в левом верхнем углу, начните с сервиса sa-web-app, чтобы посмотреть на собранные метрики: Здесь нас ждёт пустое и совершенно скучное представление — руководство никогда такое не одобрит. Давайте же создадим небольшую нагрузку следующей командой: $ while true; do curl -i http://$EXTERNAL_IP/sentiment -H "Content-type: application/json" -d '{"sentence": "I love yogobella"}'; sleep .8; done Вот теперь у нас гораздо более симпатичные графики, а в дополнение к ним — замечательные инструменты Prometheus для мониторинга и Grafana для визуализации метрик, что позволят нам узнать о производительности, состоянии здоровья, улучшениях/деградации в работе сервисов на протяжении времени. Наконец, посмотрим на трассировку запросов в сервисах. Jaeger : трассировка Трассировка нам потребуется, потому что чем больше у нас сервисов, тем сложнее добраться до причины сбоя. Посмотрим на простой случай из картинки ниже: Типовой пример случайного неудачного запроса Запрос приходит, падает — в чём же причина? Первый сервис? Или второй? Исключения есть в обоих — давайте посмотрим на логи каждого. Как часто вы ловили себя за таким занятием? Наша работа больше похожа на детективов программного обеспечения, а не разработчиков… Это широко распространённая проблема в микросервисах и решается она распределёнными системами трассировки, в которых сервисы передают друг другу уникальный заголовок, после чего эта информация перенаправляется в систему трассировки, где она сопоставляется с данными запроса. Вот иллюстрация: Для идентификации запроса используется TraceId В Istio используется Jaeger Tracer, который реализует независимый от вендоров фреймворк OpenTracing API. Получить доступ к пользовательского интерфейсу Jaeger можно следующей командой: $ kubectl port-forward -n istio-system $(kubectl get pod -n istio-system -l app=jaeger -o jsonpath='{.items[0].metadata.name}') 16686 Теперь зайдите на http://localhost:16686/ и выберите сервис sa-web-app. Если сервис не показан в выпадающем меню — проявите/сгенерируйте активность на странице и обновите интерфейс. После этого нажмите на кнопку Find Traces, которая покажет самые последние трейсы — выберите любой — покажется детализированная информация по всем трейсам: Этот трейс показывает: Запрос приходит в istio-ingressgateway (это первое взаимодействие с одним из сервисов, и для запроса генерируется Trace ID), после чего шлюз направляет запрос в сервис sa-web-app. В сервисе sa-web-app запрос подхватывается Envoy sidecar'ом, создаётся «ребёнок» в span'е (поэтому мы видим его в трейсах) и перенаправляется в контейнер sa-web-app. (Span — логическая единица работы в Jaeger, имеющая название, время начало операции и её продолжительность. Span'ы могут быть вложенными и упорядоченными. Ориентированный ациклический граф из span'ов образует trace. — прим. перев.) Здесь запрос обрабатывается методом sentimentAnalysis. Эти трейсы уже сгенерированы приложением, т.е. для них потребовались изменения в коде. С этого момента инициируется POST-запрос в sa-logic. Trace ID должен быть проброшен из sa-web-app. … Примечание: На 4 шаге приложение должно увидеть заголовки, сгенерированные Istio, и передать их в последующие запросы, как показано на изображении ниже: (A) За проброс заголовков отвечает Istio; (B) За заголовки отвечают сервисы Istio делает основную работу, т.к. генерирует заголовки для входящих запросов, создаёт новые span'ы в каждом sidecare'е и пробрасывает их. Однако без работы с заголовками внутри сервисов полный путь трассировки запроса будет утерян. Необходимо учитывать (пробрасывать) следующие заголовки: x-request-id x-b3-traceid x-b3-spanid x-b3-parentspanid x-b3-sampled x-b3-flags x-ot-span-context Это несложная задача, однако для упрощения её реализации уже существует множество библиотек — например, в сервисе sa-web-app клиент RestTemplate пробрасывает эти заголовки, если просто добавить библиотеки Jaeger и OpenTracing в его зависимости. Заметьте, что приложение Sentiment Analysis демонстрирует реализации на Flask, Spring и ASP.NET Core. Теперь, когда стало ясно, что мы получаем из коробки (или почти «из коробки»), рассмотрим вопросы тонко настраиваемой маршрутизации, управления сетевым трафиком, безопасности и т.п.! Прим. перев.: об этом читайте в следующей части материалов по Istio от Rinor Maloku, переводы которых последуют в нашем блоге в ближайшее время. UPDATE (14 марта): Вторая часть уже опубликована. P.S. от переводчика Читайте также в нашем блоге: «Назад к микросервисам вместе с Istio»: часть 2 (маршрутизация, управление трафиком), часть 3 (аутентификация и авторизация); «Conduit — легковесный service mesh для Kubernetes»; «Что такое service mesh и почему он мне нужен [для облачного приложения с микросервисами]?»; «Иллюстрированное руководство по устройству сети в Kubernetes. Части 1 и 2»; «Как этот sidecar-контейнер оказался здесь [в Kubernetes]?». Источник: habr.com

route: - destination: host: sa-frontend # 2 port: number: 80
Կարեւոր միավոր:

Այս Վիրտուալ Ծառայությունը վերաբերում է ստացվող հարցումներին http-դարպաս;
В destination սահմանում է այն ծառայությունը, որին ուղարկվում են հարցումները:

ՆշումՎերը նշված կոնֆիգուրացիան պահվում է ֆայլում sa-virtualservice-external.yaml, որը պարունակում է նաև SA-WebApp և SA-Feedback երթուղիների կարգավորումներ, սակայն կրճատվել է այստեղ՝ հոդվածում հակիրճ լինելու համար:

Դիմեք VirtualService-ին՝ զանգահարելով.

ՆշումԵրբ մենք կիրառում ենք Istio ռեսուրսները, Kubernetes API սերվերը գործարկում է իրադարձություն, որը ստանում է Istio Control Plane-ը, և դրանից հետո նոր կոնֆիգուրացիան կիրառվում է յուրաքանչյուր pod-ի Envoy վստահված անձի վրա: Եվ Ingress Gateway կարգավորիչը, կարծես, մեկ այլ բանագնաց է, որը կազմաձևված է Control Plane-ում: Այս ամենը գծապատկերում այսպիսի տեսք ունի.

Istio-IngressGateway-ի կոնֆիգուրացիա հարցումների երթուղավորման համար

Զգացմունքների վերլուծությունն այժմ հասանելի է http://{EXTERNAL-IP}/. Մի անհանգստացեք, եթե ստանաք Not Found կարգավիճակ. երբեմն մի փոքր ավելի երկար է պահանջվում, որպեսզի կազմաձևումն ուժի մեջ մտնի, և Envoy քեշերը թարմացվեն.

Շարունակելուց առաջ մի փոքր խաղացեք հավելվածի հետ՝ տրաֆիկ ստեղծելու համար: (դրա առկայությունը անհրաժեշտ է հետագա գործողություններում պարզության համար - մոտավորապես թարգմանություն).

Կիալի՝ դիտելիություն

Kiali-ի ադմինիստրատորի միջերեսին հասնելու համար գործարկեք հետևյալ հրամանը.

…և բաց http://localhost:20001/մուտք գործելով որպես admin/admin: Այստեղ դուք կգտնեք շատ օգտակար գործառույթներ, օրինակ՝ ստուգելու Istio բաղադրիչների կազմաձևումը, ծառայությունները պատկերացնելու համար ցանցային հարցումները գաղտնալսելու միջոցով հավաքագրված տեղեկատվությունից, ստանալ պատասխաններ «Ո՞վ է ում հետ կապվում», «Ծառայության որ տարբերակն է կիրառում» հարցերի պատասխանները: ձախողումներ». եւ այլն։ Ընդհանուր առմամբ, ուսումնասիրեք Kiali-ի հնարավորությունները՝ նախքան Grafana-ի միջոցով չափումների պատկերացմանը անցնելը:

Գրաֆանա՝ չափումների պատկերացում

Իստիոյում հավաքված ցուցանիշները հայտնվում են Պրոմեթևսում և պատկերացվում են Գրաֆանայի հետ: Grafana-ի ադմինիստրատորի միջերեսին հասնելու համար գործարկեք ստորև նշված հրամանը, այնուհետև բացեք http://localhost:3000/:

Սեղմելով ցանկի վրա Գլխավոր վերևի ձախ կողմում և ընտրեք Istio սպասարկման վահանակ վերևի ձախ անկյունում սկսեք սպասարկումից sa-web-appհավաքագրված ցուցանիշները դիտելու համար.

Այստեղ մենք սպասում ենք դատարկ և ամբողջովին ձանձրալի ներկայացման. ղեկավարությունը երբեք չի հաստատի դա: Եկեք ստեղծենք փոքր բեռ հետևյալ հրամանով.

Այժմ մենք ունենք շատ ավելի գեղեցիկ գծապատկերներ, և դրանցից բացի՝ Prometheus հրաշալի գործիքները մոնիտորինգի համար և Grafana՝ չափումների պատկերացման համար, որոնք թույլ կտան մեզ ծանոթանալ աշխատանքի կատարման, առողջական վիճակի, ծառայությունների բարելավումների/դեգրադացիայի մասին ժամանակի ընթացքում:

Վերջապես, եկեք նայենք ծառայություններում հարցումների հետագծմանը:

Յագեր. հետագծում

Մեզ հետագծում է պետք, քանի որ որքան շատ ծառայություններ ունենանք, այնքան դժվար կլինի հասնել ձախողման պատճառին։ Եկեք նայենք մի պարզ դեպքի ստորև նկարից.

Պատահական ձախողված հարցման բնորոշ օրինակ

Հարցումը գալիս է, ընկնում - ինչն է պատճառը? Առաջին ծառայությունը. Կամ երկրորդ. Երկուսում էլ կան բացառություններ՝ եկեք նայենք յուրաքանչյուրի տեղեկամատյաններին: Որքա՞ն հաճախ եք բռնել ինքներդ ձեզ դա անելիս: Մեր աշխատանքն ավելի շատ նման է ծրագրային ապահովման դետեկտիվների, քան մշակողների…

Սա տարածված խնդիր է միկրոսերվիսներում և լուծվում է բաշխված հետագծման համակարգերի միջոցով, որոնցում ծառայությունները միմյանց փոխանցում են եզակի վերնագիր, որից հետո այդ տեղեկատվությունը վերահղվում է հետագծման համակարգ, որտեղ այն համեմատվում է հարցման տվյալների հետ: Ահա մի նկարազարդում.

TraceId-ն օգտագործվում է հարցումը նույնականացնելու համար

Istio-ն օգտագործում է Jaeger Tracer-ը, որն իրականացնում է վաճառողից անկախ OpenTracing API շրջանակ: Դուք կարող եք մուտք գործել Jaeger օգտատիրոջ միջերես հետևյալ հրամանով.

Հիմա գնացեք http://localhost:16686/ և ընտրեք ծառայություն sa-web-app. Եթե ծառայությունը չի ցուցադրվում բացվող ընտրացանկում, ցուցադրեք/ստեղծեք գործունեությունը էջում և թարմացրեք ինտերֆեյսը: Դրանից հետո սեղմեք կոճակը Գտեք հետքեր, որը ցույց կտա ամենավերջին հետքերը - ընտրեք ցանկացած - կհայտնվի մանրամասն տեղեկատվություն բոլոր հետքերի վերաբերյալ.

Այս հետքը ցույց է տալիս.

Հարցումը գալիս է istio-ingressgateway (սա առաջին փոխազդեցությունն է ծառայություններից մեկի հետ, և հարցման համար ստեղծվում է Trace ID), որից հետո դարպասը հարցումն ուղարկում է ծառայությանը sa-web-app.
Ծառայության մեջ sa-web-app հարցումը վերցվում է Բանագնացի կողային մեքենայի կողմից, միջակայքում ստեղծվում է «երեխա» (այդ պատճառով մենք այն տեսնում ենք հետքերով) և վերահղվում դեպի կոնտեյներ։ sa-web-app. (Span - Jaeger-ում աշխատանքի տրամաբանական միավոր, որն ունի անուն, գործողության մեկնարկի ժամանակը և դրա տևողությունը: Բազերը կարելի է տեղադրել և պատվիրել: Ընդարձակությունների ուղղորդված ացիկլիկ գրաֆիկը կազմում է հետք: - մոտ. թարգմ.)
Այստեղ հարցումը մշակվում է մեթոդով զգացմունքային վերլուծություն. Այս հետքերը արդեն ստեղծվում են հավելվածի կողմից, այսինքն. նրանք պահանջում էին կոդի փոփոխություններ:
Այս պահից սկսվում է POST հարցումը սա-տրամաբանություն. Հետքի ID-ն պետք է փոխանցվի sa-web-app.
...

ՆշումՔայլ 4-ում հավելվածը պետք է տեսնի Istio-ի կողմից ստեղծված վերնագրերը և փոխանցի դրանք հետագա հարցումներին, ինչպես ցույց է տրված ստորև նկարում.

(A) Վերնագրի փոխանցումը Istio-ի պատասխանատվությունն է. (B) Ծառայությունները պատասխանատու են վերնագրերի համար

Իստիոն կատարում է աշխատանքի հիմնական մասը, քանի որ ստեղծում է վերնագրեր մուտքային հարցումների համար, ստեղծում է նոր տարածություններ յուրաքանչյուր կողմնակի խնամքի մեջ և առաջ է տանում դրանք: Այնուամենայնիվ, առանց ծառայությունների ներսում վերնագրերի հետ աշխատելու, հարցման հետագծման ամբողջական ուղին կկորչի:

Հետևյալ վերնագրերը պետք է հաշվի առնել (փոխանցել).

Սա պարզ խնդիր է, բայց դրա իրականացումը պարզեցնելու համար արդեն կա բազմաթիվ գրադարաններ - օրինակ, sa-web-app ծառայության մեջ RestTemplate հաճախորդը փոխանցում է այս վերնագրերը, եթե դուք պարզապես ավելացնեք Jaeger և OpenTracing գրադարանները: նրա կախվածությունները.

Նկատի ունեցեք, որ Sentiment Analysis հավելվածը ցուցադրում է իրականացումներ Flask-ում, Spring-ում և ASP.NET Core-ում:

Այժմ, երբ պարզ է, թե ինչ ենք մենք ստանում արկղից (կամ գրեթե դուրս), եկեք նայենք երթուղիների ճշգրտմանը, ցանցային երթևեկության կառավարմանը, անվտանգությանը և այլն:

Նշում. թարգմ.Կարդացեք այդ մասին Rinor Maloku-ից Իստիոյի վերաբերյալ նյութերի հաջորդ մասում, որոնց թարգմանությունները կհաջորդեն մեր բլոգում մոտ ապագայում: ԹԱՐՄԱՑՆԵԼ (մարտի 14): Երկրորդ մասը արդեն հրապարակված.

PS թարգմանչից

Կարդացեք նաև մեր բլոգում.

Source: www.habr.com

Վերադարձ դեպի միկրոսերվիսներ Istio-ով։ Մաս 1