Werom nei mikrotsjinsten mei Istio. Diel 2

Noat. transl.: Earste diel Dizze searje wie wijd oan it yntrodusearjen fan Istio-mooglikheden en demonstrearje se yn aksje. No sille wy prate oer mear komplekse aspekten fan 'e konfiguraasje en gebrûk fan dizze tsjinst mesh, en yn it bysûnder, oer fyn ôfstimd routing en netwurk ferkear behear.

Wy herinnerje jo ek dat it artikel konfiguraasjes brûkt (manifesten foar Kubernetes en Istio) fan it repository istio-masterskip.

ferkear behear

Mei Istio ferskine nije mooglikheden yn it kluster om te leverjen:

• Dynamyske fersykrouting: kanaryske rollouts, A / B testen;
• Load balancing: ienfâldich en konsekwint, basearre op hashes;
• Herstel nei fallen: timeouts, opnij besykjen, circuit breakers;
• Ynfoegje flaters: fertragingen, falle oanfragen, ensfh.

As it artikel trochgiet, sille dizze mooglikheden wurde yllustrearre mei de selekteare applikaasje as foarbyld en nije konsepten sille ûnderweis wurde yntrodusearre. De earste sa'n konsept sil wêze DestinationRules (d.w.s. regels oer de ûntfanger fan ferkear/fersiken - sawat oerset.), wêrmei't wy A / B-testen aktivearje.

A / B-testen: DestinationRules yn 'e praktyk

A / B-testen wurde brûkt yn gefallen wêr't d'r twa ferzjes fan in applikaasje binne (meastentiids binne se fisueel ferskillend) en wy binne net 100% wis hokker de brûkersûnderfining sil ferbetterje. Dêrom rinne wy ​​beide ferzjes tagelyk en sammelje metriken.

Om de twadde ferzje fan 'e frontend yn te setten, fereaske foar demonstrearjen fan A / B-testen, útfiere it folgjende kommando:

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

It ynsetmanifest foar de griene ferzje ferskilt op twa plakken:

1. De ôfbylding is basearre op in oare tag - istio-green,
2. Pods hawwe in label version: green.

Sûnt beide ynset hawwe in label app: sa-frontend, fersiken trochstjoerd troch firtuele tsjinst sa-external-services foar tsjinst sa-frontend, sil wurde omlaat nei al syn eksimplaren en de lading wurdt ferdield troch round-robin algoritme, wat sil liede ta de folgjende situaasje:

De opfrege bestannen binne net fûn

Dizze bestannen binne net fûn, om't se yn ferskate ferzjes fan 'e applikaasje oars wurde neamd. Litte wy der wis fan wêze:

$ 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

It betsjut dat index.html. Dêrom, om de applikaasje te wurkjen, moatte wy in beheining ynstelle: "deselde ferzje fan de applikaasje dy't tsjinne index.html moat tsjinje folgjende fersiken".

Wy komme dêr mei konsekwint hash-basearre load balancing (Konsistente Hash Loadbalancing). Yn dit gefal fersiken fan deselde klant wurde stjoerd nei deselde backend eksimplaar, wêrfoar in foarôf definieare eigenskip wurdt brûkt - bygelyks in HTTP-koptekst. Implementearre mei  DestinationRules.

Destination Rules

nei de VirtualService stjoerde in fersyk nei de winske tsjinst, mei help fan DestinationRules kinne wy ​​belied definiearje dat sil tapast wurde op ferkear dat is bestimd foar eksimplaren fan dizze tsjinst:

Ferkear behear mei Istio boarnen

remark: De ynfloed fan Istio-boarnen op netwurkferkear wurdt hjir presintearre op in manier dy't maklik te begripen is. Om krekt te wêzen, it beslút oer hokker eksimplaar it fersyk te stjoeren wurdt makke troch de gesant yn 'e Ingress Gateway konfigureare yn' e CRD.

Mei bestimmingsregels kinne wy ​​​​load balancing konfigurearje om konsekwinte hashes te brûken en derfoar te soargjen dat deselde tsjinsteksimplaar reagearret op deselde brûker. De folgjende konfiguraasje lit jo dit berikke (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 sil wurde oanmakke op basis fan 'e ynhâld fan' e HTTP-header version.

Tapasse de konfiguraasje mei it folgjende kommando:

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

Fier no it kommando hjirûnder út en soargje derfoar dat jo de juste bestannen krije as jo de koptekst opjaan version:

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

remark: Om ferskate wearden yn 'e koptekst ta te foegjen en de resultaten direkt yn' e browser te testen, kinne jo brûke dizze útwreiding nei Chrome (of hjirmei foar Firefox - ca. oerset.).

Yn 't algemien hat DestinationRules mear mooglikheden op it mêd fan load balancing - kontrolearje foar details yn offisjele dokumintaasje.

Foardat wy VirtualService fierder studearje, litte wy de "griene ferzje" fan 'e applikaasje en de oerienkommende ferkearsrjochtingsregel wiskje troch de folgjende kommando's út te fieren:

$ 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: Firtuele tsjinsten yn 'e praktyk

Skaad ("skerming") of Mirroring ("spegeljen") brûkt yn gefallen dêr't wy wolle testen in feroaring yn produksje sûnder beynfloedzje ein brûkers: om dit te dwaan, wy duplicate ("spegelje") fersiken nei in twadde eksimplaar dêr't de winske feroarings binne makke, en sjogge nei de gefolgen. Simply set, dit is as jo kollega it meast krityske probleem kiest en in pull-fersyk docht yn 'e foarm fan sa'n enoarme klomp smoargens dat gjinien it eins kin besjen.

Om dit senario yn aksje te testen, litte wy in twadde eksimplaar meitsje fan SA-Logic mei bugs (buggy) troch it folgjende kommando út te fieren:

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

En no litte wy it kommando útfiere om derfoar te soargjen dat alle eksimplaren mei app=sa-logic Se hawwe ek labels mei de oerienkommende ferzjes:

$ 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

tsjinst sa-logic rjochtet pods mei in label app=sa-logic, sadat alle oanfragen wurde ferdield oer alle gefallen:

... mar wy wolle dat fersiken wurde stjoerd nei v1-eksimplaren en spegele nei v2-eksimplaren:

Wy sille berikke dit troch VirtualService yn kombinaasje mei DestinationRule, dêr't de regels sille bepale de subsets en rûtes fan de VirtualService nei in spesifike subset.

Definearjen fan subsets yn bestimmingsregels

Subsets (subsets) wurde bepaald troch de folgjende konfiguraasje (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. Host (host) definiearret dat dizze regel allinich jildt foar gefallen as de rûte nei de tsjinst giet sa-logic;
2. Titels (name) subsets wurde brûkt by routing nei subset eksimplaren;
3. Label (label) definiearret de kaai-wearde-pearen dy't eksimplaren oerienkomme moatte om diel te wurden fan 'e subset.

Tapasse de konfiguraasje mei it folgjende kommando:

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

No't de subsets binne definieare, kinne wy ​​​​trochgean en de VirtualService konfigurearje om regels oan te passen oan fersiken nei sa-logic, sadat se:

1. Rûte nei in subset v1,
2. Mirrored nei in subset v2.

It folgjende manifest lit jo jo plannen realisearje (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

Gjin útlis hjir nedich, dus litte wy it gewoan yn aksje sjen:

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

Litte wy de lading tafoegje troch it folgjende kommando op te roppen:

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

Litte wy nei de resultaten yn Grafana sjen, wêr't jo kinne sjen dat de ferzje mei bugs (buggy) resultearret yn mislearring foar ~60% fan oanfragen, mar gjin fan dizze mislearrings beynfloedzje ein brûkers as se wurde beantwurde troch in rinnende tsjinst.

Súksesfolle antwurden fan ferskate ferzjes fan 'e sa-logyske tsjinst

Hjir seagen wy earst hoe't VirtualService wurdt tapast op de gesanten fan ús tsjinsten: wannear sa-web-app docht in fersyk om sa-logic, giet it troch de sidecar Envoy, dy't - fia VirtualService - is konfigureare om it fersyk nei de v1-subset te router en it fersyk te spegeljen nei de v2-subset fan 'e tsjinst sa-logic.

Ik wit dat jo miskien al tinke dat firtuele tsjinsten ienfâldich is. Yn 'e folgjende seksje sille wy dat útwreidzje troch te sizzen dat se ek echt geweldig binne.

Canary Rollouts

Canary Deployment is it proses fan it útrollen fan in nije ferzje fan in applikaasje nei in lyts oantal brûkers. It wurdt brûkt om te soargjen dat der gjin problemen binne yn 'e frijlitting en pas dêrnei, al betrouwen yn' e (release) kwaliteit, it fersprieden nei oare brûkers.оgrutter publyk.

Om te demonstrearjen kanaryske rollouts, wy sille trochgean te wurkjen mei in subset buggy у sa-logic.

Litte wy gjin tiid fergrieme oan lytse dingen en stjoere fuortendaliks 20% fan brûkers nei de ferzje mei bugs (dit sil ús kanaryske útrol fertsjintwurdigje), en de oerbleaune 80% nei de normale tsjinst. Om dit te dwaan, brûk de folgjende 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 is it gewicht (weight), dy't it persintaazje oanfragen oantsjut dat sil wurde rjochte oan in ûntfanger as in subset fan 'e ûntfanger.

Litte wy de foarige VirtualService-konfiguraasje bywurkje foar sa-logic mei it folgjende kommando:

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

... en wy sille fuortendaliks sjen dat guon oanfragen liede ta mislearrings:

$ 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

VirtualServices ynskeakelje kanaryske rollouts: Yn dit gefal hawwe wy de potensjele ynfloed fan 'e problemen beheind ta 20% fan' e brûkersbasis. Prachtich! No, yn alle gefallen as wy net wis binne fan ús koade (mei oare wurden - altyd ...), kinne wy ​​​​spegelje en kanaryske rollouts brûke.

Timeouts en opnij besykjen

Mar bugs einigje net altyd yn 'e koade. Yn de list fan "8 Misferstannen oer ferspraat kompjûterjen"Op it earste plak is it ferkearde leauwen dat "it netwurk betrouber is." Yn werklikheid it netwurk net betrouber, en om dizze reden wy nedich timeouts (timeouts) en opnij besykjen (opnij).

Foar demonstraasje sille wy trochgean mei it brûken fan deselde probleemferzje sa-logic (buggy), en wy sille de ûnbetrouberens fan it netwurk simulearje mei willekeurige flaters.

Lit ús tsjinst mei bugs in 1/3 kâns hawwe om te lang te reagearjen, in 1/3 kâns om te einigjen mei in ynterne serverflater, en in 1/3 kâns om de side mei súkses werom te jaan.

Om de ynfloed fan sokke problemen te ferminderjen en it libben better te meitsjen foar brûkers, kinne wy:

1. foegje in time-out ta as de tsjinst langer duorret dan 8 sekonden om te reagearjen,
2. besykje nochris as it fersyk mislearret.

Foar ymplemintaasje sille wy de folgjende boarne definysje brûke (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. De timeout foar it fersyk is ynsteld op 8 sekonden;
2. Fersiken wurde opnij besocht 3 kear;
3. En elke poging wurdt beskôge as mislearre as de reaksjetiid mear as 3 sekonden is.

Dit is in optimalisaasje, om't de brûker net mear dan 8 sekonden hoecht te wachtsjen en wy sille trije nije besykjen meitsje om in antwurd te krijen yn gefal fan mislearrings, wêrtroch't de kâns op in suksesfolle antwurd fergruttet.

Tapasse de bywurke konfiguraasje mei it folgjende kommando:

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

En kontrolearje yn 'e Grafana-grafiken dat it oantal suksesfolle antwurden hjirboppe is tanommen:

Ferbetteringen yn statistiken oer suksessukses nei it tafoegjen fan timeouts en opnij besykjen

Foardat jo trochgean nei de folgjende seksje (of leaver, nei it folgjende diel fan it artikel, om't hjiryn gjin praktyske eksperiminten mear sille wêze - sawat oerset.), wiskje sa-logic-buggy en VirtualService troch de folgjende kommando's út te fieren:

$ 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 en Bulkhead patroanen

Wy prate oer twa wichtige patroanen yn mikroservice-arsjitektuer wêrmei jo sels herstel kinne berikke (self-healing) tsjinsten.

Sekering ("sekering") brûkt om fersiken te beëinigjen dy't komme nei in eksimplaar fan in tsjinst dy't as ûnsûn wurdt beskôge en it weromsette, wylst kliïntoanfragen wurde omlaat nei sûne eksimplaren fan dy tsjinst (wat it persintaazje suksesfolle antwurden fergruttet). (Opmerking: In mear detaillearre beskriuwing fan it patroan kin fûn wurde, bygelyks, hjir.)

Bulkhead ("ôfdieling") isolearret tsjinstfalen fan ynfloed op it hiele systeem. Bygelyks, Tsjinst B is brutsen en in oare tsjinst (Client fan Tsjinst B) docht in fersyk oan Tsjinst B, wêrtroch't it syn threadpool útput en kin oare oanfragen net tsjinje (sels as se net fan Tsjinst B binne). (Opmerking: In mear detaillearre beskriuwing fan it patroan kin fûn wurde, bygelyks, hjir.)

Ik sil de ymplemintaasjedetails fan dizze patroanen weglitte, om't se maklik binne te finen yn offisjele dokumintaasje, en ik wol ek echt autentikaasje en autorisaasje sjen litte, dy't yn it folgjende diel fan it artikel besprutsen wurde.

PS fan oersetter

Lês ek op ús blog:

• "Werom nei mikrotsjinsten mei Istio": diel 1 (ynlieding ta de haadfunksjes), diel 3 (ferifikaasje en autorisaasje);
• «Conduit - lichtgewicht tsjinstmesh foar Kubernetes";
• «Wat is in tsjinstmesh en wêrom haw ik it nedich [foar in wolkapplikaasje mei mikrotsjinsten]?".

Boarne: www.habr.com