Aftur í örþjónustur með Istio. 2. hluti

Athugið. þýð.: Í fyrsta hluta Þessi sería var tileinkuð því að kynna Istio getu og sýna þá í verki. Nú munum við tala um flóknari þætti í uppsetningu og notkun þessa þjónustunets, og sérstaklega um fínstillta leið og netumferðarstjórnun.

Við minnum einnig á að greinin notar stillingar (birtingar fyrir Kubernetes og Istio) úr geymslunni istio-stjórn.

umferðarstjórnun

Með Istio birtast nýir möguleikar í klasanum til að veita:

• Dýnamísk beiðnileiðing: útrásir kanarífugla, A/B prófun;
• Álagsjafnvægi: einfalt og samkvæmt, byggt á kjötkássa;
• Bati eftir byltur: tímamörk, endurtilraunir, aflrofar;
• Að setja inn villur: tafir, fallnar beiðnir o.s.frv.

Þegar greinin heldur áfram verða þessir möguleikar sýndir með því að nota valið forrit sem dæmi og ný hugtök verða kynnt í leiðinni. Fyrsta slíka hugtakið verður DestinationRules (þ.e. reglur um viðtakanda umferðar/beiðna - ca. þýðing), með hjálp sem við virkjum A/B prófun.

A/B próf: Destination Rules í reynd

A/B prófun er notuð í þeim tilvikum þar sem það eru tvær útgáfur af forriti (venjulega eru þær sjónrænt ólíkar) og við erum ekki 100% viss um hver þeirra mun bæta notendaupplifunina. Þess vegna keyrum við báðar útgáfurnar samtímis og söfnum mælingum.

Til að dreifa annarri útgáfu af framendanum, sem þarf til að sýna fram á A/B prófun, keyrðu eftirfarandi skipun:

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

Dreifingarskrá fyrir grænu útgáfuna er mismunandi á tveimur stöðum:

1. Myndin er byggð á öðru merki - istio-green,
2. Pods eru með merkimiða version: green.

Þar sem báðar dreifingar eru með merki app: sa-frontend,beiðnir sendar með sýndarþjónustu sa-external-services fyrir þjónustu sa-frontend, verður vísað til allra tilvika þess og álaginu verður dreift í gegnum round-robin reiknirit, sem mun leiða til eftirfarandi ástands:

Umbeðnar skrár fundust ekki

Þessar skrár fundust ekki vegna þess að þær heita mismunandi í mismunandi útgáfum af forritinu. Við skulum ganga úr skugga um þetta:

$ 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

Þetta þýðir að index.html, sem biður um eina útgáfu af kyrrstæðum skrám, er hægt að senda af álagsjafnara til belg sem hafa aðra útgáfu, þar sem slíkar skrár eru ekki til af augljósum ástæðum. Þess vegna, til þess að forritið virki, þurfum við að setja takmörkun: "sama útgáfa af forritinu og þjónaði index.html ætti að þjóna síðari beiðnum'.

Við komumst þangað með stöðugri álagsjafnvægi sem byggir á kjötkássa (Samkvæmt kjötálagsjafnvægi). Í þessu tilfelli beiðnir frá sama viðskiptavini eru sendar á sama bakendatilvik, þar sem forskilgreindur eiginleiki er notaður - til dæmis HTTP haus. Útfært með því að nota Destination Rules.

Áfangastaðareglur

Eftir Sýndarþjónusta sendi beiðni til viðkomandi þjónustu, með því að nota DestinationRules getum við skilgreint stefnur sem verða beittar á umferð sem er ætlað fyrir tilvik þessarar þjónustu:

Umferðarstjórnun með Istio auðlindum

Athugið: Áhrif Istio auðlinda á netumferð eru kynnt hér á þann hátt sem auðvelt er að skilja. Til að vera nákvæmur, ákvörðun um hvaða tilvik á að senda beiðnina til er tekin af sendifulltrúanum í Ingress Gateway sem er stillt í CRD.

Með ákvörðunarreglum getum við stillt hleðslujöfnun til að nota samræmda kjötkássa og tryggja að sama þjónustutilvik svari sama notanda. Eftirfarandi uppsetning gerir þér kleift að ná þessu (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 - kjötkássa verður til byggt á innihaldi HTTP haussins version.

Notaðu stillinguna með eftirfarandi skipun:

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

Keyrðu nú skipunina hér að neðan og vertu viss um að þú færð réttar skrár þegar þú tilgreinir hausinn version:

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

Athugið: Til að bæta við mismunandi gildum í hausnum og prófa niðurstöðurnar beint í vafranum geturðu notað þessari framlengingu í Chrome (Eða með þessu fyrir Firefox - u.þ.b. þýðing.).

Almennt séð hefur DestinationRules meiri möguleika á sviði álagsjafnvægis - athugaðu nánari upplýsingar í opinber skjöl.

Áður en við lærum frekar VirtualService skulum við eyða „grænu útgáfunni“ af forritinu og samsvarandi umferðarstefnureglu með því að keyra eftirfarandi skipanir:

$ 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

Speglun: Sýndarþjónusta í reynd

Skuggi ("hlífar") eða speglun ("speglun") notað í tilfellum þar sem við viljum prófa breytingu á framleiðslu án þess að hafa áhrif á endanotendur: til að gera þetta afritum við („spegla“) beiðnir í annað tilvik þar sem óskað er eftir breytingum og skoðum afleiðingarnar. Einfaldlega sagt, þetta er þegar kollegi þinn velur mikilvægasta málið og leggur fram beiðni í formi svo risastórs óhreininda að enginn getur í raun endurskoðað það.

Til að prófa þessa atburðarás í aðgerð skulum við búa til annað tilvik af SA-Logic með villum (buggy) með því að keyra eftirfarandi skipun:

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

Og nú skulum við keyra skipunina til að ganga úr skugga um að öll tilvik með app=sa-logic Þeir hafa einnig merki með samsvarandi útgáfum:

$ 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

Service sa-logic miðar á fræbelg með merkimiða app=sa-logic, þannig að öllum beiðnum verður dreift meðal allra tilvika:

... en við viljum að beiðnir séu sendar í v1 tilvik og speglaðar í v2 tilvik:

Við munum ná þessu með VirtualService ásamt DestinationRule, þar sem reglurnar munu ákvarða undirmengi og leiðir VirtualService til tiltekins undirmengis.

Að skilgreina undirmengi í ákvörðunarreglum

Undirmengi (undirmengi) eru ákvörðuð af eftirfarandi uppsetningu (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. Gestgjafi (host) skilgreinir að þessi regla eigi aðeins við um tilvik þegar leiðin liggur í átt að þjónustunni sa-logic;
2. Titlar (name) undirmengi eru notuð þegar beina er beint til tilvika undirhópa;
3. Merki (label) skilgreinir lykilgildapörin sem tilvik verða að passa til að verða hluti af undirmenginu.

Notaðu stillinguna með eftirfarandi skipun:

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

Nú þegar undirmengin eru skilgreind getum við haldið áfram og stillt VirtualService til að beita reglum um beiðnir til sa-logic þannig að þær:

1. Beint í undirmengi v1,
2. Speglað í undirmengi v2.

Eftirfarandi stefnuskrá gerir þér kleift að ná áætlunum þínum (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

Engin útskýring þarf hér, svo við skulum bara sjá það í verki:

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

Við skulum bæta við álaginu með því að kalla eftirfarandi skipun:

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

Við skulum skoða niðurstöðurnar í Grafana, þar sem þú getur séð að útgáfan með villum (buggy) leiðir til bilunar í ~60% beiðna, en engin þessara bilana hefur áhrif á endanotendur þar sem þeim er svarað af hlaupandi þjónustu.

Vel heppnuð svör mismunandi útgáfur af sa-logic þjónustunni

Hér sáum við fyrst hvernig VirtualService er beitt fyrir sendimenn þjónustu okkar: hvenær sa-web-app gerir beiðni um sa-logic, það fer í gegnum hliðarvagninn Envoy, sem - í gegnum VirtualService - er stillt til að beina beiðninni til v1 undirmengis og spegla beiðnina til v2 undirmengis þjónustunnar sa-logic.

Ég veit, þú gætir nú þegar haldið að sýndarþjónusta sé einföld. Í næsta kafla munum við útvíkka það með því að segja að þeir séu líka sannarlega frábærir.

Kanaríútrásir

Canary Deployment er ferlið við að setja út nýja útgáfu af forriti til fárra notenda. Það er notað til að ganga úr skugga um að engin vandamál séu í útgáfunni og aðeins eftir það, þegar þú ert viss um gæði (útgáfu) hennar, dreift henni til annarra notenda.оstærri áhorfendur.

Til að sýna fram á útsetningu kanarífugla munum við halda áfram að vinna með undirmengi buggy у sa-logic.

Við skulum ekki eyða tíma í smáatriði og sendum strax 20% notenda í útgáfuna með villum (þetta mun tákna útsetningu kanarífugla okkar) og 80% sem eftir eru í venjulega þjónustu. Til að gera þetta skaltu nota eftirfarandi sýndarþjónustu (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 er þyngdin (weight), sem tilgreinir hlutfall beiðna sem verður beint til viðtakanda eða undirmengis viðtakanda.

Við skulum uppfæra fyrri VirtualService stillingar fyrir sa-logic með eftirfarandi skipun:

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

... og við munum strax sjá að sumar beiðnir leiða til bilana:

$ 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 gerir útfærslu kanarífugla kleift: Í þessu tilfelli höfum við minnkað hugsanleg áhrif málanna við 20% af notendahópnum. Dásamlegt! Núna, í öllum tilvikum þegar við erum ekki viss um kóðann okkar (með öðrum orðum - alltaf...), getum við notað speglun og kanaríútfærslur.

Tímamörk og endurtilraunir

En villur enda ekki alltaf í kóðanum. Í listanum frá "8 Ranghugmyndir um dreifða tölvuvinnslu„Í fyrsta lagi er sú ranga trú að „netið sé áreiðanlegt“. Í raun og veru netið ekki áreiðanleg, og af þessum sökum þurfum við tímamörk (tímalok) og reynir aftur (reynir aftur).

Til sýnis munum við halda áfram að nota sömu vandamálaútgáfuna sa-logic (buggy), og við munum líkja eftir óáreiðanleika netsins með tilviljunarkenndum bilunum.

Láttu þjónustu okkar með villur hafa 1/3 möguleika á að taka of langan tíma að svara, 1/3 líkur á að endar með innri netþjónsvillu og 1/3 möguleika á að skila síðunni.

Til að draga úr áhrifum slíkra vandamála og gera lífið betra fyrir notendur getum við:

1. bæta við tímamörkum ef þjónustan tekur lengri tíma en 8 sekúndur að svara,
2. reyndu aftur ef beiðnin mistekst.

Til innleiðingar munum við nota eftirfarandi auðlindaskilgreiningu (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. Tímamörk fyrir beiðni er stillt á 8 sekúndur;
2. Beiðnir eru endurteknar 3 sinnum;
3. Og hver tilraun telst misheppnuð ef viðbragðstíminn fer yfir 3 sekúndur.

Þetta er hagræðing vegna þess að notandinn þarf ekki að bíða lengur en í 8 sekúndur og við munum gera þrjár nýjar tilraunir til að fá svar ef bilanir koma upp, sem auka líkurnar á árangursríku svari.

Notaðu uppfærðu stillinguna með eftirfarandi skipun:

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

Og athugaðu í Grafana grafunum að fjöldi árangursríkra svara hefur aukist hér að ofan:

Umbætur á árangursríkum svartölfræði eftir að tímamörkum hefur verið bætt við og tilraunum aftur

Áður en haldið er áfram í næsta kafla (eða réttara sagt, í næsta hluta greinarinnar, því að í þessu verða ekki fleiri verklegar tilraunir - u.þ.b. þýðing), eyða sa-logic-buggy og VirtualService með því að keyra eftirfarandi skipanir:

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

Hringrásar- og þiljamynstur

Við erum að tala um tvö mikilvæg mynstur í smáþjónustuarkitektúr sem gerir þér kleift að ná sjálfsbata (sjálfgræðandi) þjónusta.

Circuit Breaker ("rafrásarrofi") notað til að slíta beiðnum sem berast til tilviks þjónustu sem er talin óholl og endurheimta hana á meðan beiðnir viðskiptavina eru sendar til heilbrigðra tilvika þeirrar þjónustu (sem eykur hlutfall árangursríkra svara). (Athugið: Nánari lýsingu á mynstrinu má finna, td. hér.)

Skot ("skilrúm") einangrar þjónustubilanir frá því að hafa áhrif á allt kerfið. Til dæmis er Þjónusta B biluð og önnur þjónusta (viðskiptavinur Þjónustu B) gerir beiðni til Þjónustu B, sem veldur því að hún tæmir þráðasafn sitt og getur ekki sinnt öðrum beiðnum (jafnvel þó þær séu ekki frá Þjónustu B). (Athugið: Nánari lýsingu á mynstrinu má finna, td. hér.)

Ég mun sleppa útfærsluupplýsingum þessara mynstra vegna þess að auðvelt er að finna þau opinber skjöl, og ég vil líka virkilega sýna auðkenningu og heimild, sem verður fjallað um í næsta hluta greinarinnar.

PS frá þýðanda

Lestu líka á blogginu okkar:

• "Aftur í örþjónustur með Istio": hluti 1 (kynning á helstu eiginleikum), hluti 3 (staðfesting og heimild);
• «Conduit - léttur þjónustunet fyrir Kubernetes»;
• «Hvað er þjónustunet og hvers vegna þarf ég það [fyrir skýjaforrit með örþjónustu]?'.

Heimild: www.habr.com