ProHoster > Blogs > Administrācija > Atgriezties uz mikropakalpojumiem ar Istio. 2. daļa

Atgriezties uz mikropakalpojumiem ar Istio. 2. daļa

Atgriezties uz mikropakalpojumiem ar Istio. 2. daļa

PiezÄ«me. tulk.: Pirmā daļa Å Ä« sērija bija veltÄ«ta Istio iespēju ievieÅ”anai un demonstrÄ“Å”anai darbÄ«bā. Tagad mēs runāsim par sarežģītākiem Ŕī pakalpojuma tÄ«kla konfigurācijas un izmantoÅ”anas aspektiem, un jo Ä«paÅ”i par precÄ«zi noregulētu marÅ”rutÄ“Å”anu un tÄ«kla trafika pārvaldÄ«bu.

Tāpat atgādinām, ka rakstā tiek izmantotas konfigurācijas (manifesti Kubernetes un Istio) no repozitorija istio-meistarība.

Satiksmes vadība

Izmantojot Istio, klasterÄ« parādās jaunas iespējas, lai nodroÅ”inātu:

  • Dinamiskā pieprasÄ«juma marÅ”rutÄ“Å”ana: kanārijputniņi, A/B testÄ“Å”ana;
  • Slodzes balansÄ“Å”ana: vienkārÅ”s un konsekvents, pamatojoties uz hashēm;
  • AtveseļoÅ”anās pēc kritieniem: taimauts, mēģinājumi, automātiskie slēdži;
  • Kļūdu ievietoÅ”ana: kavÄ“Å”anās, noraidÄ«ti pieprasÄ«jumi utt.

Turpinot rakstu, Ŕīs iespējas tiks ilustrētas, izmantojot atlasÄ«to lietojumprogrammu kā piemēru, un pa ceļam tiks ieviesti jauni jēdzieni. Pirmā Ŕāda koncepcija bÅ«s DestinationRules (t.i., noteikumi par trafika/pieprasÄ«jumu saņēmēju - apm. tulk.), ar kuras palÄ«dzÄ«bu aktivizējam A/B testÄ“Å”anu.

A/B testÄ“Å”ana: DestinationRules praksē

A/B testÄ“Å”ana tiek izmantota gadÄ«jumos, kad ir divas aplikācijas versijas (parasti tās ir vizuāli atŔķirÄ«gas) un mēs neesam 100% pārliecināti, kura no tām uzlabos lietotāja pieredzi. Tāpēc mēs vienlaikus palaižam abas versijas un apkopojam metriku.

Lai izvietotu otro priekŔgala versiju, kas nepiecieŔama A/B testēŔanas demonstrēŔanai, palaidiet Ŕo komandu:

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

Zaļās versijas izvietoŔanas manifests atŔķiras divās vietās:

  1. Attēls ir balstīts uz citu tagu - istio-green,
  2. Pākstīm ir etiķete version: green.

Tā kā abiem izvietojumiem ir etiÄ·ete app: sa-frontend,pieprasÄ«jumi, ko marÅ”rutē virtuālais pakalpojums sa-external-services par apkalpoÅ”anu sa-frontend, tiks novirzÄ«ts uz visiem gadÄ«jumiem, un slodze tiks izplatÄ«ta apļa algoritms, kas novedÄ«s pie Ŕādas situācijas:

Atgriezties uz mikropakalpojumiem ar Istio. 2. daļa
Pieprasītie faili netika atrasti

Šie faili netika atrasti, jo dažādās lietojumprogrammas versijās tiem ir atŔķirīgi nosaukumi. Pārliecināsimies par to:

$ 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

Tas nozÄ«mē, ka index.html, pieprasot vienu statisko failu versiju, slodzes lÄ«dzsvarotājs var nosÅ«tÄ«t uz podiem, kuriem ir cita versija, kur acÄ«mredzamu iemeslu dēļ Ŕādi faili nepastāv. Tāpēc, lai lietojumprogramma darbotos, mums ir jāiestata ierobežojums: ā€œtai paÅ”ai lietojumprogrammas versijai, kas apkalpoja index.html, vajadzētu apkalpot turpmākos pieprasÄ«jumus'.

Mēs to sasniegsim, izmantojot konsekventu uz jaucējkodu balstÄ«tu slodzes lÄ«dzsvaroÅ”anu (Konsekventa hash slodzes lÄ«dzsvaroÅ”ana). Å ajā gadÄ«jumā pieprasÄ«jumi no tā paÅ”a klienta tiek nosÅ«tÄ«ti uz vienu un to paÅ”u aizmugursistēmas gadÄ«jumu, kuram tiek izmantots iepriekÅ” definēts rekvizÄ«ts ā€“ piemēram, HTTP galvene. Ieviests, izmantojot DestinationRules.

Galamērķa noteikumi

Pēc Virtuālais pakalpojums nosÅ«tÄ«ja pieprasÄ«jumu vajadzÄ«gajam pakalpojumam, izmantojot DestinationRules, mēs varam definēt politikas, kas tiks piemērotas trafikam, kas paredzēts Ŕī pakalpojuma gadÄ«jumiem:

Atgriezties uz mikropakalpojumiem ar Istio. 2. daļa
Satiksmes vadība ar Istio resursiem

PiezÄ«me: Istio resursu ietekme uz tÄ«kla trafiku Å”eit ir parādÄ«ta viegli saprotamā veidā. PrecÄ«zāk sakot, lēmumu par to, uz kuru instanci nosÅ«tÄ«t pieprasÄ«jumu, pieņem sÅ«tnis CRD konfigurētajā ieejas vārtejā.

Izmantojot galamērÄ·a noteikumus, mēs varam konfigurēt slodzes lÄ«dzsvaroÅ”anu, lai izmantotu konsekventus jaucējus un nodroÅ”inātu, ka viena un tā pati pakalpojuma instance reaģē vienam un tam paÅ”am lietotājam. Šāda konfigurācija ļauj to sasniegt (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 ā€” jaucējvārds tiks Ä£enerēts, pamatojoties uz HTTP galvenes saturu version.

Lietojiet konfigurāciju ar Ŕādu komandu:

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

Tagad palaidiet tālāk norādīto komandu un pārliecinieties, vai, norādot galveni, saņemat pareizos failus version:

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

PiezÄ«me: lai pievienotu dažādas vērtÄ«bas galvenē un pārbaudÄ«tu rezultātus tieÅ”i pārlÅ«kprogrammā, varat izmantot Å”is paplaÅ”inājums pārlÅ«kam Chrome (Vai ar Å”o Firefox - apm. tulk.).

Kopumā DestinationRules ir vairāk iespēju slodzes lÄ«dzsvaroÅ”anas jomā ā€” sÄ«kāku informāciju skatiet sadaļā oficiālā dokumentācija.

Pirms turpināt pētÄ«t VirtualService, izdzēsÄ«sim lietojumprogrammas ā€œzaļo versijuā€ un atbilstoÅ”o satiksmes virziena noteikumu, izpildot Ŕādas komandas:

$ 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

SpoguļoÅ”ana: virtuālie pakalpojumi praksē

Ēnojums (ā€œaizsardzÄ«baā€) vai SpoguļoÅ”ana (ā€œspoguļoÅ”anaā€) izmanto gadÄ«jumos, kad mēs vēlamies pārbaudÄ«t ražoÅ”anas izmaiņas, neietekmējot galalietotājus: lai to izdarÄ«tu, mēs dublējam (ā€œspoguļoā€) pieprasÄ«jumus otrajā instancē, kur ir veiktas vēlamās izmaiņas, un aplÅ«kojam sekas. VienkārÅ”i sakot, tas ir tad, kad jÅ«su kolēģis izvēlas vissvarÄ«gāko problēmu un izsaka pieprasÄ«jumu tik liela netÄ«ruma veidā, ka neviens to nevar pārskatÄ«t.

Lai pārbaudītu Ŕo scenāriju darbībā, izveidosim otru SA-Logic gadījumu ar kļūdām (buggy), izpildot Ŕādu komandu:

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

Un tagad izpildÄ«sim komandu, lai pārliecinātos, ka visi gadÄ«jumi ar app=sa-logic Viņiem ir arÄ« etiÄ·etes ar atbilstoŔām versijām:

$ 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

ApkalpoÅ”ana sa-logic mērÄ·auditorija ir pākstis ar etiÄ·eti app=sa-logic, tāpēc visi pieprasÄ«jumi tiks sadalÄ«ti starp visiem gadÄ«jumiem:

Atgriezties uz mikropakalpojumiem ar Istio. 2. daļa

... bet mēs vēlamies, lai pieprasījumi tiktu nosūtīti uz v1 gadījumiem un atspoguļoti v2 instancēs:

Atgriezties uz mikropakalpojumiem ar Istio. 2. daļa

Mēs to sasniegsim, izmantojot VirtualService kombinācijā ar DestinationRule, kur noteikumi noteiks VirtualService apakÅ”kopas un marÅ”rutus uz konkrētu apakÅ”kopu.

ApakÅ”kopu definÄ“Å”ana galamērÄ·a noteikumos

ApakÅ”kopas (apakÅ”kopas) tiek noteiktas pēc Ŕādas konfigurācijas (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

  1. Saimnieks (host) nosaka, ka Ŕis noteikums attiecas tikai uz gadījumiem, kad marŔruts iet uz pakalpojumu sa-logic;
  2. Nosaukumi (name) apakÅ”kopas tiek izmantotas, marÅ”rutējot uz apakÅ”kopas gadÄ«jumiem;
  3. EtiÄ·ete (label) definē atslēgu un vērtÄ«bu pārus, kuriem gadÄ«jumiem ir jāatbilst, lai tie kļūtu par daļu no apakÅ”kopas.

Lietojiet konfigurāciju ar Ŕādu komandu:

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

Tagad, kad apakÅ”kopas ir definētas, mēs varam pāriet un konfigurēt VirtualService, lai piemērotu noteikumus sa-logic pieprasÄ«jumiem, lai tie:

  1. MarÅ”rutēts uz apakÅ”kopu v1,
  2. Atspoguļots apakŔkopā v2.

Šis manifests ļauj sasniegt savus plānus (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

Å eit nav nepiecieÅ”ams paskaidrojums, tāpēc redzēsim to darbÄ«bā:

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

Pievienosim slodzi, izsaucot Ŕādu komandu:

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

Apskatīsim rezultātus programmā Grafana, kur var redzēt, ka versija ar kļūdām (buggy).

Atgriezties uz mikropakalpojumiem ar Istio. 2. daļa
Veiksmīgas atbildes uz dažādām sa-logic pakalpojuma versijām

Å eit mēs pirmo reizi redzējām, kā VirtualService tiek piemērots mÅ«su pakalpojumu sÅ«tņiem: kad sa-web-app izsaka lÅ«gumu sa-logic, tas iet caur blakusvāģi Envoy, kas, izmantojot VirtualService, ir konfigurēts, lai novirzÄ«tu pieprasÄ«jumu uz v1 apakÅ”kopu un atspoguļotu pieprasÄ«jumu pakalpojuma v2 apakÅ”kopā. sa-logic.

Es zinu, jÅ«s jau domājat, ka virtuālie pakalpojumi ir vienkārÅ”i. Nākamajā sadaļā mēs to izvērsÄ«sim, sakot, ka tie ir arÄ« patieŔām lieliski.

Kanārijputniņi

Canary Deployment ir process, kurā nelielam lietotāju skaitam tiek izlaista jauna lietojumprogrammas versija. To izmanto, lai pārliecinātos, ka laidienā nav problēmu un tikai pēc tam, jau pārliecinoties par tā (laidiena) kvalitāti, izplatÄ«t to citiem lietotājiem.Š¾lielāka auditorija.

Lai demonstrētu kanārijputnu izlaiÅ”anu, mēs turpināsim strādāt ar apakÅ”kopu buggy у sa-logic.

Netērēsim laiku sÄ«kumiem un nekavējoties nosÅ«tÄ«sim 20% lietotāju uz versiju ar kļūdām (tas atspoguļos mÅ«su Canary izlaiÅ”anu), bet atlikuÅ”os 80% uz parasto pakalpojumu. Lai to izdarÄ«tu, izmantojiet Å”o VirtualService (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 ir svars (weight), kas norāda pieprasījumu procentuālo daļu, kas tiks novirzīti adresātam vai adresāta apakŔkopai.

Atjaunināsim iepriekŔējo VirtualService konfigurāciju sa-logic ar Ŕādu komandu:

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

... un mēs uzreiz redzēsim, ka daži pieprasījumi noved pie kļūmēm:

$ 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

Virtuālie pakalpojumi nodroÅ”ina Canary izlaiÅ”anu: Å”ajā gadÄ«jumā esam samazinājuÅ”i problēmu iespējamo ietekmi lÄ«dz 20% no lietotāju bāzes. BrÄ«niŔķīgi! Tagad visos gadÄ«jumos, kad neesam pārliecināti par savu kodu (citiem vārdiem sakot - vienmēr...), mēs varam izmantot spoguļoÅ”anu un kanārijas izlaiÅ”anu.

Noildze un mēģinājumi

Taču kļūdas ne vienmēr nonāk kodā. Sarakstā no "8 maldÄ«gi priekÅ”stati par dalÄ«to skaitļoÅ”anu"Pirmkārt, ir kļūdains uzskats, ka "tÄ«kls ir uzticams". PatiesÄ«bā tÄ«kls nē uzticami, un Ŕī iemesla dēļ mums ir nepiecieÅ”ams taimauts (taimauts) un mēģina vēlreiz (mēģina vēlreiz).

DemonstrÄ“Å”anai mēs turpināsim izmantot to paÅ”u problēmu versiju sa-logic (buggy), un mēs simulēsim tÄ«kla neuzticamÄ«bu ar nejauŔām kļūmēm.

Ä»aujiet mÅ«su pakalpojumam ar kļūdām reaģēt pārāk ilgi, 1/3 iespējas, ka tas beigsies ar iekŔēju servera kļūdu, un 1/3 iespējas, ka lapa tiks veiksmÄ«gi atgriezta.

Lai mazinātu Ŕādu problēmu ietekmi un uzlabotu lietotāju dzÄ«vi, mēs varam:

  1. pievienot taimautu, ja pakalpojumam ir nepiecieÅ”amas vairāk nekā 8 sekundes, lai atbildētu,
  2. mēģiniet vēlreiz, ja pieprasījums neizdodas.

ÄŖstenoÅ”anai mēs izmantosim Ŕādu resursa definÄ«ciju (sa-logic-retries-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

  1. Pieprasījuma taimauts ir iestatīts uz 8 sekundēm;
  2. Pieprasījumi tiek izskatīti atkārtoti 3 reizes;
  3. Un katrs mēģinājums tiek uzskatīts par neveiksmīgu, ja reakcijas laiks pārsniedz 3 sekundes.

Šī ir optimizācija, jo lietotājam nebūs jāgaida vairāk par 8 sekundēm un mēs veiksim trīs jaunus mēģinājumus saņemt atbildi kļūmju gadījumā, palielinot veiksmīgas atbildes iespēju.

Lietojiet atjaunināto konfigurāciju ar Ŕādu komandu:

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

Un pārbaudiet Grafana diagrammās, vai veiksmīgo atbilžu skaits ir palielinājies iepriekŔ:

Atgriezties uz mikropakalpojumiem ar Istio. 2. daļa
Uzlabojumi veiksmÄ«gu atbilžu statistikā pēc taimautu un atkārtotu mēģinājumu pievienoÅ”anas

Pirms pāriet uz nākamo sadaļu (pareizāk sakot, uz nākamo raksta daļu, jo Å”ajā vairs nebÅ«s praktisku eksperimentu - apm. tulk.), dzēst sa-logic-buggy un VirtualService, izpildot Ŕādas komandas:

$ kubectl delete deployment sa-logic-buggy
deployment.extensions ā€œsa-logic-buggyā€ deleted
$ kubectl delete virtualservice sa-logic
virtualservice.networking.istio.io ā€œsa-logicā€ deleted

Strāvas pārtraucēju un starpsienu modeļi

Mēs runājam par diviem svarÄ«giem mikropakalpojumu arhitektÅ«ras modeļiem, kas ļauj sasniegt paÅ”atjaunoÅ”anos (paÅ”dziedināŔanās) pakalpojumi.

Circuit Breaker ("automātiskais slēdzis") izmanto, lai pārtrauktu pieprasÄ«jumus, kas tiek saņemti pakalpojuma gadÄ«jumam, kas tiek uzskatÄ«ts par neveselÄ«gu, un atjaunotu to, kamēr klientu pieprasÄ«jumi tiek novirzÄ«ti uz veselÄ«giem Ŕī pakalpojuma gadÄ«jumiem (kas palielina veiksmÄ«go atbilžu procentuālo daļu). (PiezÄ«me: sÄ«kāku modeļa aprakstu var atrast, piemēram, Å”eit.)

Starpsiena ("nodalÄ«jums") izolē pakalpojuma kļūmes, lai tās neietekmētu visu sistēmu. Piemēram, pakalpojums B ir bojāts un cits pakalpojums (pakalpojuma B klients) iesniedz pieprasÄ«jumu pakalpojumam B, kā rezultātā tas izsmels savu pavedienu kopu un nevar apkalpot citus pieprasÄ«jumus (pat ja tie nav no pakalpojuma B). (PiezÄ«me: sÄ«kāku modeļa aprakstu var atrast, piemēram, Å”eit.)

Es izlaidÄ«Å”u Å”o modeļu ievieÅ”anas informāciju, jo tos ir viegli atrast oficiālā dokumentācija, un es arÄ« ļoti vēlos parādÄ«t autentifikāciju un autorizāciju, kas tiks apspriesta nākamajā raksta daļā.

PS no tulka

Lasi arī mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru