🥇 Bi Istio re vegere mîkroxizmetan. Part 2

Not. werger.: Beşek yekem Ev rêze ji bo danasîna kapasîteyên Istio û nîşandana wan di çalakiyê de hate veqetandin. Naha em ê li ser hêmanên tevlihevtir ên mîheng û karanîna vê tevna karûbarê, û bi taybetî, li ser rêveçûnek birêkûpêk û rêveberiya seyrûsefera torê biaxivin.

Di heman demê de em ji we re tînin bîra we ku gotar ji depo vesazkirinê (nîşanên Kubernetes û Istio) bikar tîne. istio-serwerî.

Rêveberiya Trafîkê

Bi Istio re, kapasîteyên nû di komê de xuya dikin ku peyda dikin:

Rêvekirina daxwaza dînamîk: rollouts canary, testkirina A/B;
hevsengkirina barkirinê: sade û hevgirtî, li ser bingeha haş;
Vejandina piştî hilweşînê.
Têxistina xeletiyan: derengketin, daketin daxwaz û hwd.

Gava ku gotar berdewam dike, dê van kapasîteyên bi karanîna serîlêdana hilbijartî wekî mînakek were destnîşan kirin û têgehên nû dê di rê de bêne destnîşan kirin. Têgîna yekem a bi vî rengî wê bibe DestinationRules (ango qaîdeyên li ser wergirê trafîkê/daxwazan - bi qasî werger.), bi alîkariya ku em ceribandina A/B çalak dikin.

Testkirina A / B: DestinationRules di pratîkê de

Testkirina A/B di rewşên ku du guhertoyên serîlêdanê hene (bi gelemperî ew bi dîtbarî cûda ne) tê bikar anîn û em 100% ne bawer in ku kîjan dê ezmûna bikarhêner baştir bike. Ji ber vê yekê, em herdu guhertoyan bi hevdemî dimeşînin û metrîkan berhev dikin.

Ji bo sazkirina guhertoya duyemîn a pêşiyê, ku ji bo ceribandina A/B-yê nîşan dide hewce dike, emrê jêrîn bimeşînin:

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

Manîfestoya bicîhkirinê ji bo guhertoya kesk di du cihan de cûda dibe:

Wêne li ser tagek cûda ye - istio-green,
Pods xwedî etîketek in version: green.

Ji ber ku her du belavok xwedî etîketek in app: sa-frontend,daxwazên ku ji hêla karûbarê virtual ve têne rêve kirin sa-external-services ji bo xizmetê sa-frontend, dê ji hemî nimûneyên xwe re were veguheztin û bar dê bi rê ve were belav kirin algorîtmaya dor-robin, ku dê bibe sedema rewşa jêrîn:

Pelên xwestin nehatin dîtin

Van pelan nehatin dîtin ji ber ku di guhertoyên cihêreng ên serîlêdanê de navên wan cuda ne. Ka em ji vê yekê piştrast bin:

$ 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

Ew tê wê wateyê index.html, Daxwaza yek guhertoya pelên statîk, dikare ji hêla balanserê barkirinê ve were şandin bo podên ku guhertoyek cûda hene, li wir, ji ber sedemên diyar, pelên weha tune ne. Ji ber vê yekê, ji bo ku serîlêdan bixebite, pêdivî ye ku em sînorek saz bikin: "heman guhertoya serîlêdanê ya ku index.html pêşkêşî dike divê daxwazên paşîn xizmetê bike".

Em ê bi hevsengiya barkirinê-based hash-a domdar bigihîjin wir (Berhevsengkirina Hashê ya Berdewam). Di vê rewşê de daxwazên ji heman muwekîlê ji heman mînaka paşîn re têne şandin, ji bo ku taybetmendiyek pêşwext tê bikar anîn - mînakî, sernavek HTTP. Bi karanîna DestinationRules ve hatî bicîh kirin.

DestinationRules

Piştî VirtualService daxwazek ji karûbarê xwestî re şand, bi karanîna DestinationRules em dikarin polîtîkayên ku dê li ser seyrûsefera ku ji bo nimûneyên vê karûbarê têne sepandin diyar bikin:

Rêveberiya trafîkê bi çavkaniyên Istio

bingotin: Bandora çavkaniyên Istio li ser seyrûsefera torê li vir bi rengek hêsan tê pêşkêş kirin. Bi rastî, biryara li ser kîjan nimûneyê ku daxwaznameyê bişîne ji hêla Nûnerê di Deriyê Ingressê de ku di CRD-ê de hatî mîheng kirin ve tê girtin.

Bi Rêgezên Destenameyê re, em dikarin hevsengiya barkirinê mîheng bikin da ku haşeyên domdar bikar bînin û piştrast bikin ku heman mînaka karûbarê bersivê dide heman bikarhêner. Veavakirina jêrîn dihêle hûn vê yekê bi dest bixin (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 - Hash dê li ser bingeha naveroka sernavê HTTP were çêkirin version.

Veavakirinê bi fermana jêrîn bicîh bikin:

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

Naha emrê jêrîn bimeşînin û gava ku hûn sernavê destnîşan dikin pê ewle bibin ku hûn pelên rast digirin version:

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

bingotin: Ji bo ku di serî de nirxên cihêreng lê zêde bikin û encamên rasterast di gerokê de ceribandin, hûn dikarin bikar bînin vê dirêjkirinê ji bo Chrome (an jî bi vê ji bo Firefox - nêzîkî. werger.).

Bi gelemperî, DestinationRules di warê hevsengkirina barkirinê de bêtir kapasîteyên xwe hene - ji bo hûrguliyan kontrol bikin belgeyên fermî.

Berî xwendina VirtualService bêtir, bila em "guhertoya kesk" a serîlêdanê û qaîdeya rêwerziya trafîkê ya têkildar bi fermanên jêrîn jêbirin:

$ 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: Xizmetên Virtual di pratîkê de

Siya ("mertal") an Mirroring ("neynikkirin") di rewşên ku em dixwazin guheztinek di hilberînê de bêyî bandorkirina bikarhênerên dawîn biceribînin tê bikar anîn: ji bo vê yekê, em daxwazên ("neynik") ji mînaka duyemîn re ku guheztinên xwestin hatine çêkirin dubare dikin, û li encaman dinêrin. Bi hêsanî, ev gava ku hevkarê we pirsgirêka herî krîtîk hildibijêre û di forma kulmek wusa mezin a qirêj de daxwazek vekişînê dike ku kes nikare wê bi rastî binirxîne.

Ji bo ceribandina vê senaryoyê di çalakiyê de, werin em mînakek duyemîn a SA-Logic bi xeletiyan biafirînin (buggy) bi xebitandina fermana jêrîn:

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

Û naha em fermanê bimeşînin da ku pê ewle bibin ku hemî mînak bi app=sa-logic Ew jî etîketên bi guhertoyên têkildar hene:

$ 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

xizmeta sa-logic bi etîketekê podan dike hedef app=sa-logic, ji ber vê yekê hemî daxwaz dê di nav hemî mînakan de bêne belav kirin:

... lê em dixwazin ku daxwaz ji mînakên v1 re werin şandin û ji mînakên v2 re werin xuyang kirin:

Em ê vê yekê bi navgîniya VirtualService bi DestinationRule re bigihînin hev, ku qaîdeyên wê binekom û rêgezên VirtualService-ê ji binekomek taybetî re diyar bikin.

Diyarkirina Binkometan di Rêgezên Destedanê de

Subsets (binkomet) ji hêla veavakirina jêrîn ve têne destnîşankirin (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

Mêvandar (host) diyar dike ku ev rêgez tenê ji bo rewşên ku rê ber bi karûbarê ve diçe derbas dibe sa-logic;
Sernav (name) dema ku ji bo nimûneyên binkomê rêve dibin, jêrkom têne bikar anîn;
Label (label) cotên key-nirxê yên ku divê mînak li hev bikin diyar dike da ku bibin beşek ji jêrkometê.

Veavakirinê bi fermana jêrîn bicîh bikin:

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

Naha ku binekom têne diyar kirin, em dikarin bimeşin û Servîsa Virtualê mîheng bikin da ku qaîdeyan li daxwazên sa-mantiqê bicîh bîne da ku ew:

Rêwît kirin bo binekomek v1,
Mirrored to a binerd v2.

Manîfestoya jêrîn dihêle hûn planên xwe bi dest bixin (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

Li vir ravekirin hewce nake, ji ber vê yekê bila em wê di çalakiyê de bibînin:

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

Ka em bi gazîkirina fermana jêrîn barkirinê zêde bikin:

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

Ka em li encamên Grafana binêrin, li wir hûn dikarin bibînin ku guhertoya bi xeletiyan (buggy) ji bo %60-ê daxwazan dibe sedema têkçûnê, lê yek ji van têkçûn bandorê li bikarhênerên dawîn nake ji ber ku ji hêla karûbarek xebitandinê ve têne bersivandin.

Bersivên serketî yên guhertoyên cihêreng ên karûbarê sa-logîk

Li vir me yekem car dît ku VirtualService çawa li ser Nûnerên karûbarên me tê sepandin: kengê sa-web-app daxwazê dike sa-logic, ew ji hêla Envoy-ê ve derbas dibe, ku - bi navgîniya VirtualService - ve hatî mîheng kirin ku daxwazê bigihîne binkoma v1 û daxwazê ji binkoma v2 ya karûbarê re neynikê dike. sa-logic.

Ez dizanim, dibe ku hûn jixwe difikirin ku Karûbarên Virtual hêsan e. Di beşa pêş de, em ê li ser wê berfireh bikin û bibêjin ku ew jî bi rastî mezin in.

rollouts Canary

Dabeşkirina Canary pêvajoyek e ku guhertoyek nû ya serîlêdanê ji hejmarek piçûk bikarhêneran re vedigire. Ew tê bikar anîn da ku pê ewle bibe ku di berdanê de pirsgirêk tune ne û tenê piştî wê, jixwe ji qalîteya wê (serbestberdanê) pê ewle bin, wê li bikarhênerên din belav bikin.оtemaşevanên mezintir.

Ji bo nîşandana rijandina canaryan, em ê xebata bi binesaziyek bidomînin buggy у sa-logic.

Werin em wextê xwe li ser piçûkan winda nekin û tavilê% 20-ê bikarhêneran bişînin guhertoya bi xeletiyan (ev ê pêşandana meya kaniya temsîl bike), û 80% mayî jî ji karûbarê normal re. Ji bo vê yekê, VirtualService jêrîn bikar bînin (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 giranî ye (weight), ku ji sedî daxwaznameyên ku dê ji wergirek an jêrkomek wergir re werin şandin diyar dike.

Ka em ji bo veavakirina VirtualService ya berê nûve bikin sa-logic bi fermana jêrîn:

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

... û em ê tavilê bibînin ku hin daxwaz dibin sedema têkçûnê:

$ 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

Servîsên Virtual danasîna kanariyan çalak dike: Di vê rewşê de, me bandora potansiyela pirsgirêkan li% 20 ji bingeha bikarhêner teng kiriye. Pirxweş! Naha, di her rewşê de gava ku em ji koda xwe ne ewle ne (bi gotinek din - her gav ...), em dikarin neynik û roniyên kanariyê bikar bînin.

Demjimêr û dubare

Lê xeletî her gav di kodê de naqedin. Di lîsteyê de ji "8 Têgihiştinên şaş di derbarê Computing Belavkirî de"Di rêza yekem de baweriya xelet e ku "tora pêbawer e." Di rastiyê de torê ne pêbawer, û ji ber vê sedemê em hewceyê demandan in (demên derbasbûyî) û ji nû ve diceribîne (diceribîne).

Ji bo xwenîşandanê em ê berdewam bikin ku heman guhertoya pirsgirêkê bikar bînin sa-logic (buggy), û em ê bêbaweriya torê bi têkçûnên rasthatî simul bikin.

Bila karûbarê me ya bi xeletiyan 1/3 şansê bersivdayînê hebe, 1/3 şansê ku bi Xeletiyek Pêşkêşkara Navxweyî biqede, û şansek 1/3 ku bi serfirazî rûpelê vegerîne.

Ji bo ku bandora pirsgirêkên weha sivik bikin û jiyanê ji bikarhêneran re çêtir bikin, em dikarin:

heke karûbar ji 8 saniyeyan dirêjtir bikişîne ku bersivê bide, demek dirêj zêde bike,
dîsa biceribîne ger daxwaz bi ser nekeve.

Ji bo bicîhkirinê, em ê pênaseya çavkaniyê ya jêrîn bikar bînin (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

Demjimêra daxwazê 8 çirkeyan e;
Daxwaz 3 caran têne ceribandin;
Û her hewildanek neserkeftî tête hesibandin heke dema bersivê ji 3 çirkeyan derbas bibe.

Ev optimîzasyonek e ji ber ku bikarhêner dê ji 8 çirkeyan zêdetir li bendê nemîne û em ê sê hewildanên nû bikin ku di rewşa têkçûn de bersivek bistînin, şansê bersivek serketî zêde bikin.

Veavakirina nûvekirî bi fermana jêrîn bicîh bikin:

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

Û di grafikên Grafana de kontrol bikin ku hejmara bersivên serketî li jor zêde bûye:

Pêşketinên di statîstîkên bersivên serketî de piştî lê zêdekirina dem û dubareyan

Berî ku biçin beşa pêş (an bêtir, ji bo beşa paşîn a gotarê, ji ber ku di vê yekê de dê ceribandinên pratîkî nebin - nêzîkê werger.), jêbirin sa-logic-buggy û VirtualService bi xebitandina fermanên jêrîn:

$ 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 Breaker and Bulkhead Patterns

Em di mîmariya mîkroxizmetê de li ser du qalibên girîng diaxivin ku destûrê didin we ku hûn xwe-başbûnê bi dest bixin (xwe dermankirin) xizmetên.

Breaker Circuit ("bişkoka çerxa") ji bo bidawîkirina daxwazên ku digihîje mînakek karûbarek ku nebaş tê hesibandin û wê sererast dike dema ku daxwazên xerîdar berbi mînakên saxlem ên wê karûbarê ve têne rêve kirin (ku rêjeya bersivên serketî zêde dike) tê bikar anîn. (Têbînî: Danasînek berfirehtir a nimûneyê dikare were dîtin, wek nimûne, vir.)

Bulkhead ("parbûnî") têkçûna karûbarê ji bandorkirina tevahiya pergalê îzole dike. Mînakî, Xizmeta B şikestî ye û karûbarek din (mişterek karûbarê B) daxwazek ji Karûbarê B dike, ev dibe sedem ku ew hewza xweya tîrêjê biqede û nikaribe daxwazên din xizmet bike (tevî ku ew ne ji Karûbarê B bin). (Têbînî: Danasînek berfirehtir a nimûneyê dikare were dîtin, wek nimûne, vir.)

Ez ê hûrguliyên pêkanînê yên van nimûneyan derxim ji ber ku dîtina wan hêsan e belgeyên fermî, û ez bi rastî jî dixwazim ku verastkirin û destûrnameyê nîşan bidim, ku dê di beşa paşîn a gotarê de were nîqaş kirin.

PS ji wergêr

Li ser bloga me jî bixwînin:

"Bi Istio re vegere servîsên mîkro": beş 1 (danasîna taybetmendiyên sereke), beşa 3 (rastkirin û destûrkirin);
«Conduit - tevna karûbarê sivik ji bo Kubernetes»;
«Meshek karûbarê çi ye û çima ez jê re hewce dikim [ji bo serîlêdana ewr bi mîkroxizmetan]?".

Source: www.habr.com

Bi Istio re vegerin ser mîkroxizmetan. Beş 2