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

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

Հիշեցնում ենք նաև, որ հոդվածում օգտագործվում են պահոցից կազմաձևումներ (մանիֆեստներ Kubernetes-ի և Istio-ի համար): istio-վարպետություն.

երթեւեկության կառավարում

Istio-ի հետ կլաստերում հայտնվում են նոր հնարավորություններ՝ ապահովելու համար.

Դինամիկ հարցումների երթուղավորումԴեղձանիկների տեղակայում, A/B թեստավորում;
Բեռների հավասարակշռումպարզ և հետևողական՝ հիմնված հեշերի վրա.
Վերականգնում ընկնելուց հետոժամանակի ընդհատումներ, կրկնակի փորձեր, անջատիչներ;
Սխալների տեղադրումուշացումներ, մերժված հարցումներ և այլն:

Քանի որ հոդվածը շարունակվում է, այս հնարավորությունները կներկայացվեն՝ օգտագործելով ընտրված հավելվածը որպես օրինակ, և ճանապարհին կներդրվեն նոր հասկացություններ: Առաջին նման հայեցակարգը կլինի DestinationRules (այսինքն՝ երթևեկության/հարցումների ստացողի մասին կանոններ - մոտավորապես թարգմանություն), որի օգնությամբ ակտիվացնում ենք A/B թեստավորումը։

A/B թեստավորում. DestinationRules գործնականում

A/B թեստավորումն օգտագործվում է այն դեպքերում, երբ կա հավելվածի երկու տարբերակ (սովորաբար դրանք տեսողականորեն տարբեր են), և մենք 100%-ով վստահ չենք, թե որն է բարելավելու օգտատիրոջ փորձը: Հետևաբար, մենք միաժամանակ գործարկում ենք երկու տարբերակները և հավաքում չափումներ:

Frontend-ի երկրորդ տարբերակը տեղակայելու համար, որը անհրաժեշտ է A/B թեստավորումը ցուցադրելու համար, գործարկեք հետևյալ հրամանը.

$ kubectl apply -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions/sa-frontend-green created

«Կանաչ տարբերակի» տեղակայման մանիֆեստը տարբերվում է երկու տեղով.

Պատկերը հիմնված է այլ պիտակի վրա. istio-green,
Ծածկոցներն ունեն պիտակ version: green.

Քանի որ երկու տեղակայումները ունեն պիտակ app: sa-frontendվիրտուալ ծառայության կողմից ուղղորդված հարցումները sa-external-services ծառայության համար sa-frontend, կվերահղվի իր բոլոր ատյաններին, և բեռը կբաշխվի միջոցով շրջանաձեւ ալգորիթմ, ինչը կհանգեցնի հետևյալ իրավիճակին.

Պահանջվող ֆայլերը չեն գտնվել

Այս ֆայլերը չեն գտնվել, քանի որ դրանք տարբեր անվանումներ են ստացել հավելվածի տարբեր տարբերակներում: Եկեք համոզվենք սա.

$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.c7071b22.css
/static/js/main.059f8e9c.js
$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.f87cd8c9.css
/static/js/main.f7659dbb.js

Սա նշանակում է index.html, ստատիկ ֆայլերի մեկ տարբերակ պահանջելով, բեռնաչափի կողմից կարող է ուղարկվել այլ տարբերակ ունեցող պատյաններ, որտեղ, հասկանալի պատճառներով, նման ֆայլեր գոյություն չունեն: Հետևաբար, որպեսզի հավելվածն աշխատի, մենք պետք է սահմանափակում սահմանենք.հավելվածի նույն տարբերակը, որը սպասարկում էր index.html, պետք է սպասարկի հետագա հարցումները.

Մենք այնտեղ կհասնենք հետևողական հեշի վրա հիմնված բեռի հավասարակշռման միջոցով (Հաշի հետևողական բեռնվածության հավասարակշռում). Այս դեպքում Միևնույն հաճախորդի հարցումներն ուղարկվում են միևնույն հետին օրինակին, որի համար օգտագործվում է նախապես սահմանված հատկություն, օրինակ՝ HTTP վերնագիր։ Իրականացվում է «DestinationRules»-ի միջոցով:

Նպատակակետի կանոններ

Հետո Վիրտուալ ծառայություն հարցում է ուղարկել ցանկալի ծառայությանը, օգտագործելով DestinationRules մենք կարող ենք սահմանել քաղաքականություն, որը կկիրառվի այս ծառայության օրինակների համար նախատեսված տրաֆիկի նկատմամբ.

Երթևեկության կառավարում Istio ռեսուրսներով

ՆշումIstio ռեսուրսների ազդեցությունը ցանցային տրաֆիկի վրա այստեղ ներկայացված է հեշտ հասկանալի ձևով: Ավելի ճիշտ, որոշումը, թե որ ատյան ուղարկել հարցումը, կայացնում է բանագնացը CRD-ում կազմաձևված Ingress Gateway-ում:

Նպատակակետի կանոններով մենք կարող ենք կարգավորել բեռի հավասարակշռումը, որպեսզի օգտագործի հետևողական հեշեր և համոզվի, որ ծառայության նույն օրինակը արձագանքում է նույն օգտագործողին: Հետևյալ կոնֆիգուրացիան թույլ է տալիս հասնել դրան (destinationrule-sa-frontend.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-frontend
spec:
  host: sa-frontend
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: version   # 1

1 - հեշը կստեղծվի HTTP վերնագրի բովանդակության հիման վրա version.

Կիրառեք կոնֆիգուրացիան հետևյալ հրամանով.

$ kubectl apply -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io/sa-frontend created

Այժմ գործարկեք ստորև նշված հրամանը և համոզվեք, որ դուք ստանում եք ճիշտ ֆայլերը, երբ նշում եք վերնագիրը version:

$ curl --silent -H "version: yogo" http://$EXTERNAL_IP/ | tr '"' 'n' | grep main

ՆշումՎերնագրում տարբեր արժեքներ ավելացնելու և արդյունքները անմիջապես բրաուզերում փորձարկելու համար կարող եք օգտագործել այս ընդլայնումը Chrome-ին (Կամ սրա հետ Firefox-ի համար՝ մոտ. թարգմ.).

Ընդհանուր առմամբ, DestinationRules-ն ավելի շատ հնարավորություններ ունի բեռի հավասարակշռման ոլորտում. մանրամասների համար ստուգեք պաշտոնական փաստաթղթեր.

Նախքան VirtualService-ի հետագա ուսումնասիրությունը, եկեք ջնջենք հավելվածի «կանաչ տարբերակը» և համապատասխան երթևեկության ուղղության կանոնը՝ գործարկելով հետևյալ հրամանները.

$ kubectl delete -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions “sa-frontend-green” deleted
$ kubectl delete -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io “sa-frontend” deleted

Mirroring. վիրտուալ ծառայություններ գործնականում

Ստվերում («վահան») կամ Mirroring («հայելում») օգտագործվում է այն դեպքերում, երբ մենք ցանկանում ենք փորձարկել արտադրության փոփոխությունը՝ չազդելով վերջնական օգտագործողների վրա. դա անելու համար մենք կրկնօրինակում ենք («հայելային») հարցումները երկրորդ ատյանի, որտեղ կատարվել են ցանկալի փոփոխությունները, և դիտում ենք հետևանքները: Պարզ ասած, սա այն դեպքն է, երբ ձեր գործընկերն ընտրում է ամենակարևոր հարցը և դիմում է քաշքշուկի այնպիսի հսկայական կեղտի տեսքով, որ ոչ ոք չի կարող իրականում վերանայել այն:

Այս սցենարը գործողության մեջ փորձարկելու համար եկեք ստեղծենք SA-Logic-ի երկրորդ օրինակը սխալներով (buggy)՝ գործարկելով հետևյալ հրամանը.

$ kubectl apply -f resource-manifests/kube/shadowing/sa-logic-service-buggy.yaml
deployment.extensions/sa-logic-buggy created

Եվ հիմա եկեք գործարկենք հրամանը՝ համոզվելու համար, որ բոլոր օրինակները հետ են app=sa-logic Նրանք ունեն նաև պիտակներ՝ համապատասխան տարբերակներով.

$ kubectl get pods -l app=sa-logic --show-labels
NAME                              READY   LABELS
sa-logic-568498cb4d-2sjwj         2/2     app=sa-logic,version=v1
sa-logic-568498cb4d-p4f8c         2/2     app=sa-logic,version=v1
sa-logic-buggy-76dff55847-2fl66   2/2     app=sa-logic,version=v2
sa-logic-buggy-76dff55847-kx8zz   2/2     app=sa-logic,version=v2

Ծառայություն sa-logic թիրախավորում է պատիճները պիտակով app=sa-logic, այնպես որ բոլոր հարցումները կբաշխվեն բոլոր ատյաններում՝

... բայց մենք ցանկանում ենք, որ հարցումները ուղարկվեն v1 օրինակներին և արտացոլվեն v2 օրինակներին.

Մենք դրան կհասնենք VirtualService-ի միջոցով՝ DestinationRule-ի հետ համատեղ, որտեղ կանոնները կորոշեն VirtualService-ի ենթաբազմությունները և երթուղիները դեպի կոնկրետ ենթաբազմություն:

Նշանակման կանոններում ենթաբազմությունների սահմանում

Ենթաբազմություններ (ենթաբազմություններ) որոշվում են հետևյալ կազմաձևով (sa-logic-subsets-destinationrule.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-logic
spec:
  host: sa-logic    # 1
  subsets:
  - name: v1        # 2
    labels:
      version: v1   # 3
  - name: v2
    labels:
      version: v2

Հյուրընկալող (host) սահմանում է, որ այս կանոնը վերաբերում է միայն այն դեպքերին, երբ երթուղին գնում է դեպի ծառայություն sa-logic;
Վերնագրեր (name) ենթաբազմությունները օգտագործվում են ենթաբազմությունների օրինակներ ուղղորդելիս.
Պիտակը (label) սահմանում է բանալի-արժեք զույգերը, որոնց օրինակները պետք է համապատասխանեն ենթաբազմության մաս դառնալու համար:

Կիրառեք կոնֆիգուրացիան հետևյալ հրամանով.

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-destinationrule.yaml
destinationrule.networking.istio.io/sa-logic created

Այժմ, երբ ենթաբազմությունները սահմանված են, մենք կարող ենք առաջ շարժվել և կարգավորել VirtualService-ը, որպեսզի կիրառի կանոններ sa-logic հարցումների համար, որպեսզի նրանք.

Ուղղորդված ենթաբազմություն v1,
Հայելային ենթաբազմություն v2.

Հետևյալ մանիֆեստը թույլ է տալիս իրականացնել ձեր ծրագրերը (sa-logic-subsets-shadowing-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic          
  http:
  - route:
    - destination:
        host: sa-logic  
        subset: v1      
    mirror:             
      host: sa-logic     
      subset: v2

Այստեղ բացատրություն պետք չէ, ուստի եկեք ուղղակի տեսնենք այն գործողության մեջ.

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-shadowing-vs.yaml
virtualservice.networking.istio.io/sa-logic created

Եկեք ավելացնենք բեռը՝ կանչելով հետևյալ հրամանը.

$ while true; do curl -v http://$EXTERNAL_IP/sentiment 
    -H "Content-type: application/json" 
    -d '{"sentence": "I love yogobella"}'; 
    sleep .8; done

Եկեք նայենք արդյունքներին Grafana-ում, որտեղ կարող եք տեսնել, որ սխալներով տարբերակը (buggy) հանգեցնում է հարցումների ~60%-ի ձախողմանը, սակայն այս անհաջողություններից և ոչ մեկը չի ազդում վերջնական օգտատերերի վրա, քանի որ դրանք պատասխանվում են գործող ծառայության կողմից:

Sa-logic ծառայության տարբեր տարբերակների հաջող պատասխաններ

Այստեղ մենք առաջին անգամ տեսանք, թե ինչպես է VirtualService-ը կիրառվում մեր ծառայությունների պատվիրատուների նկատմամբ. երբ sa-web-app հարցում է անում sa-logic, այն անցնում է կողային Envoy-ի միջով, որը VirtualService-ի միջոցով կազմաձևված է հարցումը ուղղորդելու դեպի v1 ենթաբազմություն և արտացոլելու հարցումը ծառայության v2 ենթաբազմությանը: sa-logic.

Գիտեմ, դուք արդեն կարող եք մտածել, որ Վիրտուալ ծառայությունները պարզ են: Հաջորդ բաժնում մենք կընդլայնենք դա՝ ասելով, որ դրանք նույնպես իսկապես հիանալի են:

Canary Rollouts

Canary Deployment-ը փոքր թվով օգտատերերի համար հավելվածի նոր տարբերակի տրամադրման գործընթաց է: Այն օգտագործվում է համոզվելու համար, որ թողարկման մեջ խնդիրներ չկան, և միայն դրանից հետո, արդեն վստահ լինելով դրա (թողարկման) որակի վրա, տարածել այն այլ օգտվողներին:оավելի մեծ լսարան:

Դեղձանիկների տարածումը ցուցադրելու համար մենք կշարունակենք աշխատել ենթաբազմության հետ buggy у sa-logic.

Եկեք ժամանակ չկորցնենք մանրուքների վրա և անմիջապես ուղարկենք օգտատերերի 20%-ին վրիպակներ ունեցող տարբերակ (սա կներկայացնի մեր դեղձանիկների թողարկումը), իսկ մնացած 80%-ը՝ սովորական ծառայությանը: Դա անելու համար օգտագործեք հետևյալ վիրտուալ ծառայությունը (sa-logic-subsets-canary-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic    
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 80         # 1
    - destination: 
        host: sa-logic
        subset: v2
      weight: 20 # 1

1-ը քաշն է (weight), որը նշում է հարցումների տոկոսը, որոնք կուղղվեն ստացողին կամ ստացողի ենթաբազմությանը:

Եկեք թարմացնենք նախորդ VirtualService-ի կոնֆիգուրացիան sa-logic հետևյալ հրամանով.

$ kubectl apply -f resource-manifests/istio/canary/sa-logic-subsets-canary-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

... և մենք անմիջապես կտեսնենք, որ որոշ հարցումներ հանգեցնում են ձախողումների.

$ while true; do 
   curl -i http://$EXTERNAL_IP/sentiment 
   -H "Content-type: application/json" 
   -d '{"sentence": "I love yogobella"}' 
   --silent -w "Time: %{time_total}s t Status: %{http_code}n" 
   -o /dev/null; sleep .1; done
Time: 0.153075s Status: 200
Time: 0.137581s Status: 200
Time: 0.139345s Status: 200
Time: 30.291806s Status: 500

Վիրտուալ ծառայությունները հնարավորություն են տալիս դեղձանիկների թողարկումը. այս դեպքում մենք կրճատել ենք խնդիրների հնարավոր ազդեցությունը մինչև օգտատերերի բազայի 20%-ը: Հրաշալի՜ Այժմ, ամեն դեպքում, երբ մենք վստահ չենք մեր կոդը (այլ կերպ ասած՝ միշտ...), մենք կարող ենք օգտագործել mirroring և canary rollouts:

Ժամկետներ և կրկնվող փորձեր

Բայց սխալները միշտ չէ, որ հայտնվում են կոդում: Ցուցակում «8 Սխալ պատկերացումներ բաշխված հաշվարկների մասին«Առաջին տեղում այն սխալ համոզմունքն է, որ «ցանցը հուսալի է»: Իրականում ցանցը ոչ հուսալի, և այդ պատճառով մեզ անհրաժեշտ են թայմաութներ (թայմաութներ) և նորից փորձում է (կրկին փորձեր).

Ցուցադրման համար մենք կշարունակենք օգտագործել նույն խնդրի տարբերակը sa-logic (buggy), իսկ ցանցի անվստահելիությունը մենք կսիմուլյացնենք պատահական խափանումներով։

Թող վրիպակներ ունեցող մեր ծառայությունն ունենա 1/3 հավանականություն, որ շատ ժամանակ տևի պատասխանելու համար, 1/3 հնարավորություն՝ ավարտվի ներքին սերվերի սխալով և 1/3 հնարավորություն՝ հաջողությամբ վերադարձնելու էջը:

Նման խնդիրների ազդեցությունը մեղմելու և օգտատերերի կյանքը ավելի լավ դարձնելու համար մենք կարող ենք.

ավելացրեք ժամանակացույց, եթե ծառայության պատասխանը տևում է ավելի քան 8 վայրկյան,
նորից փորձեք, եթե հարցումը ձախողվի:

Իրականացման համար մենք կօգտագործենք ռեսուրսի հետևյալ սահմանումը (SA-Logic-Wrepies-Timeouts- vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 50
    - destination: 
        host: sa-logic
        subset: v2
      weight: 50
    timeout: 8s           # 1
    retries:
      attempts: 3         # 2
      perTryTimeout: 3s # 3

Հարցման ժամկետը սահմանվել է 8 վայրկյան;
Հարցումները կրկնվում են 3 անգամ.
Եվ յուրաքանչյուր փորձ համարվում է անհաջող, եթե պատասխանի ժամանակը գերազանցում է 3 վայրկյանը։

Սա օպտիմիզացում է, քանի որ օգտատերը ստիպված չի լինի սպասել ավելի քան 8 վայրկյան, և մենք երեք նոր փորձ կկատարենք՝ անհաջողության դեպքում պատասխան ստանալու համար՝ մեծացնելով հաջող պատասխանի հնարավորությունը։

Կիրառեք թարմացված կոնֆիգուրացիան հետևյալ հրամանով.

$ kubectl apply -f resource-manifests/istio/retries/sa-logic-retries-timeouts-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

Եվ Grafana-ի գրաֆիկներում ստուգեք, որ հաջող պատասխանների թիվն աճել է վերևում.

Հաջող պատասխանների վիճակագրության բարելավումներ՝ ընդհատումներ և կրկնվող փորձեր ավելացնելուց հետո

Նախքան հաջորդ բաժին անցնելը (ավելի ճիշտ՝ հոդվածի հաջորդ մասին, քանի որ դրանում այլևս գործնական փորձեր չեն լինի՝ մոտավորապես թարգմ.), ջնջել sa-logic-buggy և VirtualService-ը՝ գործարկելով հետևյալ հրամանները.

$ kubectl delete deployment sa-logic-buggy
deployment.extensions “sa-logic-buggy” deleted
$ kubectl delete virtualservice sa-logic
virtualservice.networking.istio.io “sa-logic” deleted

Անջատիչի և միջնորմերի նախշեր

Խոսքը միկրոսերվիսային ճարտարապետության երկու կարևոր օրինաչափությունների մասին է, որոնք թույլ են տալիս հասնել ինքնավերականգնման (ինքնաբուժում) ծառայություններ

Circuit համար անթափանցիկ բաճկոն («անջատիչ») օգտագործվում է դադարեցնելու հարցումները, որոնք գալիս են ծառայության օրինակին, որը համարվում է անառողջ և վերականգնել այն, մինչդեռ հաճախորդի հարցումները վերահղվում են այդ ծառայության առողջ օրինակներին (ինչը մեծացնում է հաջող պատասխանների տոկոսը): (Նշում. Օրինակի ավելի մանրամասն նկարագրությունը կարելի է գտնել, օրինակ. այստեղ.)

Bulkhead («բաժանում») մեկուսացնում է ծառայության ձախողումները ամբողջ համակարգի վրա ազդելուց: Օրինակ, ծառայությունը խափանվել է, և մեկ այլ ծառայություն (B-ի հաճախորդը) հարցում է կատարում B ծառայությանը, ինչը հանգեցնում է նրան, որ այն սպառում է իր թելերի լողավազանը և չի կարողանում սպասարկել այլ հարցումներ (նույնիսկ եթե դրանք B ծառայությունից չեն): (Նշում. Օրինակի ավելի մանրամասն նկարագրությունը կարելի է գտնել, օրինակ. այստեղ.)

Ես բաց կթողնեմ այս օրինաչափությունների իրականացման մանրամասները, քանի որ դրանք հեշտ է գտնել պաշտոնական փաստաթղթեր, և ես նաև շատ եմ ուզում ցույց տալ նույնականացում և լիազորում, ինչը կքննարկվի հոդվածի հաջորդ մասում։

PS թարգմանչից

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

«Վերադառնալ միկրոսերվիսներին Istio-ով». մաս 1 (ներածություն հիմնական հատկանիշներին), մաս 3 (նույնականացում և թույլտվություն);
«Խողովակ - թեթև սպասարկման ցանց Kubernetes-ի համար";
«Ի՞նչ է սպասարկման ցանցը և ինչո՞ւ է այն ինձ անհրաժեշտ [միկրոծառայությունների հետ ամպային հավելվածի համար]:.

Source: www.habr.com

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