Istioga tagasi mikroteenuste juurde. 2. osa

Märge. tõlge: Esimene osa See seeria oli pühendatud Istio võimaluste tutvustamisele ja nende tegevuses demonstreerimisele. Nüüd räägime selle teenusevõrgu konfigureerimise ja kasutamise keerukamatest aspektidest ning eriti peenhäälestatud marsruutimisest ja võrguliikluse juhtimisest.

Samuti tuletame meelde, et artikkel kasutab hoidlast pärit konfiguratsioone (Kubernetese ja Istio manifestid) istio-meisterlikkus.

liikluskorraldus

Istioga ilmuvad klastris uued võimalused, mis pakuvad:

• Dünaamiline päringu marsruutimine: canary rollouts, A/B testimine;
• Koormuse tasakaalustamine: lihtne ja järjekindel, räsipõhine;
• Taastumine pärast kukkumisi: ajalõpud, korduskatsed, kaitselülitid;
• Vigade sisestamine: viivitused, tühistatud taotlused jne.

Artikli jätkudes illustreeritakse neid võimalusi valitud rakenduse näitel ja tutvustatakse uusi kontseptsioone. Esimene selline kontseptsioon on DestinationRules (st liikluse/päringute saaja reeglid – umbes tõlge), mille abil aktiveerime A/B testimise.

A/B testimine: DestinationRules praktikas

A/B testimist kasutatakse juhtudel, kui rakendusel on kaks versiooni (tavaliselt on need visuaalselt erinevad) ja me ei ole 100% kindlad, milline neist kasutajakogemust parandab. Seetõttu käitame mõlemat versiooni korraga ja kogume mõõdikuid.

A/B-testimise demonstreerimiseks vajaliku kasutajaliidese teise versiooni juurutamiseks käivitage järgmine käsk:

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

Rohelise versiooni juurutamise manifest erineb kahes kohas.

1. Pilt põhineb erineval sildil - istio-green,
2. Kaunadel on silt version: green.

Kuna mõlemal juurutamisel on silt app: sa-frontend,päringud suunatakse virtuaalteenuse kaudu sa-external-services teenuse eest sa-frontend, suunatakse ümber kõigile selle eksemplaridele ja koormus jaotatakse läbi Round-robin algoritm, mis toob kaasa järgmise olukorra:

Taotletud faile ei leitud

Neid faile ei leitud, kuna need on rakenduse erinevates versioonides erineva nimega. Veendume selles:

$ 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

See tähendab, et index.html, mis taotleb üht staatiliste failide versiooni, saab koormuse tasakaalustaja saata kaustadele, millel on erinev versioon, kus selliseid faile arusaadavatel põhjustel ei eksisteeri. Seetõttu peame rakenduse töötamiseks seadma piirangu: "sama rakenduse versioon, mis teenindas index.html-i, peaks esitama ka järgnevaid päringuid'.

Jõuame selleni järjekindla räsipõhise koormuse tasakaalustamisega (Järjepidev räsikoormuse tasakaalustamine)... Sel juhul sama kliendi päringud saadetakse samale taustaeksemplarile, mille jaoks kasutatakse eelmääratletud atribuuti – näiteks HTTP-päist. Rakendatud kasutades DestinationRules.

Sihtkohareeglid

Pärast Virtuaalteenus saatis soovitud teenusele päringu, saame DestinationRules'i abil määratleda eeskirjad, mida rakendatakse selle teenuse eksemplaride jaoks mõeldud liiklusele:

Liikluskorraldus Istio vahenditega

Märkus: Istio ressursside mõju võrguliiklusele on siin toodud lihtsalt arusaadaval viisil. Täpsemalt, otsuse, millisele eksemplarile päring saata, teeb saadik CRD-s konfigureeritud sissepääsulüüsis.

Sihtreeglite abil saame koormuse tasakaalustamise konfigureerida nii, et see kasutaks ühtseid räsi ja tagaks, et sama teenuse eksemplar reageerib samale kasutajale. Järgmine konfiguratsioon võimaldab teil seda saavutada (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 – räsi genereeritakse HTTP päise sisu põhjal version.

Rakendage konfiguratsioon järgmise käsuga:

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

Nüüd käivitage allolev käsk ja veenduge, et saate päise määramisel õiged failid version:

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

Märkus: päisesse erinevate väärtuste lisamiseks ja tulemuste testimiseks otse brauseris saate kasutada see laiendus Chrome'ile (Või sellega Firefoxi jaoks - u. tõlge.).

Üldiselt on DestinationRulesil koormuse tasakaalustamise valdkonnas rohkem võimalusi – vaadake üksikasju ametlik dokumentatsioon.

Enne VirtualService'i edasist uurimist kustutame rakenduse "roheline versioon" ja sellele vastava liiklussuuna reegli, käivitades järgmised käsud:

$ 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

Peegeldamine: virtuaalsed teenused praktikas

varjamine ("varjestus") või peegeldamine ("peegeldamine") kasutatakse juhtudel, kui soovime katsetada tootmise muudatust ilma lõppkasutajaid mõjutamata: selleks dubleerime ("peegeldame") päringuid teisele eksemplarile, kus soovitud muudatused on tehtud, ja vaatame tagajärgi. Lihtsamalt öeldes valib teie kolleeg välja kõige kriitilisema probleemi ja esitab tõmbetaotluse nii suure mustuse kujul, et keegi ei saa seda tegelikult üle vaadata.

Selle stsenaariumi testimiseks loome SA-Logicu teise eksemplari koos vigadega (buggy), käivitades järgmise käsu:

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

Ja nüüd käivitame käsu veendumaks, et kõik eksemplarid koos app=sa-logic Neil on ka vastavate versioonidega sildid:

$ 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

Teenus sa-logic sihib sildiga kaunasid app=sa-logic, seega jaotatakse kõik päringud kõigi eksemplaride vahel:

... aga me tahame, et taotlused saadetaks v1 eksemplaridele ja peegeldataks v2 eksemplaridele:

Me saavutame selle VirtualService'i kaudu koos DestinationRule'iga, kus reeglid määravad kindlaks VirtualService'i alamhulgad ja marsruudid konkreetse alamhulgani.

Alamhulkade määratlemine sihtkoha reeglites

Alamhulgad (alamhulgad) on määratud järgmise konfiguratsiooniga (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) määratleb, et see reegel kehtib ainult juhtudel, kui marsruut läheb teenuse poole sa-logic;
2. Pealkirjad (name) alamhulka kasutatakse marsruutimisel alamhulga eksemplaridesse;
3. Silt (label) määrab võtme-väärtuse paarid, millele eksemplarid peavad vastama, et saada alamhulga osaks.

Rakendage konfiguratsioon järgmise käsuga:

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

Nüüd, kui alamhulgad on määratletud, saame edasi liikuda ja konfigureerida VirtualService'i rakendama reegleid sa-loogika päringutele nii, et need:

1. Suunatud alamhulka v1,
2. Peegeldatud alamhulgaga v2.

Järgmine manifest võimaldab teil oma plaane saavutada (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

Siin pole selgitust vaja, nii et vaatame seda tegevuses:

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

Lisame koormuse, kutsudes välja järgmise käsu:

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

Vaatame Grafana tulemusi, kus on näha, et vigadega versioon (buggy) põhjustab ~60% taotluste tõrkeid, kuid ükski neist tõrgetest ei mõjuta lõppkasutajaid, kuna neile vastab töötav teenus.

Sa-loogika teenuse erinevate versioonide edukad vastused

Siin nägime esmakordselt, kuidas VirtualService'i rakendatakse meie teenuste saadikutele: millal sa-web-app teeb taotluse sa-logic, läbib see külgkorvi Envoy, mis VirtualService'i kaudu on konfigureeritud suunama taotlust v1 alamhulka ja peegeldama taotlust teenuse v2 alamhulka. sa-logic.

Ma tean, võite juba arvata, et virtuaalteenused on lihtsad. Järgmises osas räägime sellest lähemalt, öeldes, et need on ka tõeliselt suurepärased.

Canary Rollouts

Canary juurutamine on rakenduse uue versiooni avaldamine väikesele arvule kasutajatele. Seda kasutatakse veendumaks, et väljalaskes pole probleeme, ja alles pärast seda, olles juba kindel selle (väljaande) kvaliteedis, levitada seda teistele kasutajatele.оsuurem publik.

Kanaari levitamise demonstreerimiseks jätkame tööd alamhulgaga buggy у sa-logic.

Ärgem raiskagem aega pisiasjadele ja saatkem 20% kasutajatest kohe vigadega versioonile (see esindab meie kanaari levikut) ja ülejäänud 80% tavateenusesse. Selleks kasutage järgmist VirtualService'i (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 on kaal (weight), mis määrab taotluste protsendi, mis suunatakse adressaadile või adressaadi alamhulgale.

Värskendame eelmist VirtualService'i konfiguratsiooni sa-logic järgmise käsuga:

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

... ja me näeme kohe, et mõned taotlused põhjustavad tõrkeid:

$ 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

Virtuaalsed teenused võimaldavad kanaari levitamist: antud juhul oleme vähendanud probleemide võimalikku mõju 20%-le kasutajabaasist. Imeline! Nüüd, igal juhul, kui me pole oma koodis kindlad (teisisõnu - alati...), saame kasutada peegeldamist ja kanaari levitamist.

Aegumised ja korduskatsed

Kuid vead ei satu alati koodi. Loendis alates "8 eksiarvamust hajutatud andmetöötluse kohta"Esiteks on ekslik arvamus, et "võrk on usaldusväärne." Tegelikult võrk ei usaldusväärne ja sel põhjusel vajame aegumist (ajalõpud) ja proovib uuesti (proovib uuesti).

Demonstreerimiseks jätkame sama probleemse versiooni kasutamist sa-logic (buggy) ja simuleerime võrgu ebausaldusväärsust juhuslike riketega.

Laske meie vigadega teenusel olla 1/3 tõenäosus, et reageerimine võtab liiga kaua aega, 1/3 tõenäosus, et see lõpeb sisemise serveri veaga ja 1/3 tõenäosus lehe edukaks tagastamiseks.

Selliste probleemide mõju leevendamiseks ja kasutajate elu paremaks muutmiseks saame teha järgmist.

1. lisage ajalõpp, kui teenusel kulub vastamiseks kauem kui 8 sekundit,
2. proovige uuesti, kui taotlus ebaõnnestub.

Rakendamiseks kasutame järgmist ressursimääratlust (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. Päringu ajalõpp on seatud 8 sekundile;
2. Taotlusi proovitakse uuesti 3 korda;
3. Ja iga katse loetakse ebaõnnestunuks, kui reageerimisaeg ületab 3 sekundit.

See on optimeerimine, sest kasutaja ei pea ootama kauem kui 8 sekundit ja me teeme kolm uut katset, et saada tõrgete korral vastus, suurendades eduka vastuse võimalust.

Rakendage värskendatud konfiguratsioon järgmise käsuga:

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

Ja kontrollige Grafana graafikutelt, et edukate vastuste arv on suurenenud:

Vastuste edukuse statistika täiustused pärast ajalõppude ja korduskatsete lisamist

Enne järgmise osa juurde liikumist (või õigemini artikli järgmise osa juurde, sest selles pole enam praktilisi katseid - umbes tõlge), kustutada sa-logic-buggy ja VirtualService, käivitades järgmised käsud:

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

Kaitselüliti ja vaheseinte mustrid

Me räägime kahest olulisest mustrist mikroteenuste arhitektuuris, mis võimaldavad teil saavutada enesetaaste (eneseparanemine) teenused.

kaitselüliti ("kaitselüliti") kasutatakse ebatervislikuks peetava teenuse eksemplarile saabuvate päringute lõpetamiseks ja selle taastamiseks, samal ajal kui kliendipäringud suunatakse ümber selle teenuse tervetele eksemplaridele (mis suurendab edukate vastuste protsenti). (Märkus: mustri täpsema kirjelduse leiate näiteks siin.)

Vahesein ("partitsioon") isoleerib teenuse tõrked kogu süsteemi mõjutamisest. Näiteks teenus B on katki ja mõni teine ​​teenus (teenuse B klient) esitab teenusele B päringu, mille tõttu see ammendab oma lõimekogumi ja ei saa teisi taotlusi teenindada (isegi kui need ei ole teenusest B). (Märkus: mustri täpsema kirjelduse leiate näiteks siin.)

Jätan nende mustrite rakendamise üksikasjad välja, kuna neid on lihtne leida ametlik dokumentatsioon, ja ma tahan ka väga näidata autentimist ja autoriseerimist, mida arutatakse artikli järgmises osas.

PS tõlkijalt

Loe ka meie blogist:

• "Tagasi mikroteenuste juurde Istioga": 1. osa (peamiste funktsioonide sissejuhatus), 3. osa (autentimine ja autoriseerimine);
• «Kanal – Kubernetese kerge hooldusvõrk";
• «Mis on teenindusvõrk ja miks ma seda vajan [mikroteenustega pilverakenduse jaoks]?'.

Allikas: www.habr.com