🥇Atpakaļ 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:

Attēls ir balstīts uz citu tagu - istio-green,
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:

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:

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:

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

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

Saimnieks (host) nosaka, ka šis noteikums attiecas tikai uz gadījumiem, kad maršruts iet uz pakalpojumu sa-logic;
Nosaukumi (name) apakškopas tiek izmantotas, maršrutējot uz apakškopas gadījumiem;
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:

Maršrutēts uz apakškopu v1,
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).

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:

pievienot taimautu, ja pakalpojumam ir nepieciešamas vairāk nekā 8 sekundes, lai atbildētu,
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

Pieprasījuma taimauts ir iestatīts uz 8 sekundēm;
Pieprasījumi tiek izskatīti atkārtoti 3 reizes;
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š:

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ļā.