Märge. tõlge: 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) .
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 createdRohelise versiooni juurutamise manifest erineb kahes kohas.
- Pilt põhineb erineval sildil -
istio-green, - 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 , 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 ():
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 mainMärkus: päisesse erinevate väärtuste lisamiseks ja tulemuste testimiseks otse brauseris saate kasutada Chrome'ile (Või Firefoxi jaoks - u. tõlge.).
Üldiselt on DestinationRulesil koormuse tasakaalustamise valdkonnas rohkem võimalusi – vaadake üksikasju .
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” deletedPeegeldamine: 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 ():
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- Host (
host) määratleb, et see reegel kehtib ainult juhtudel, kui marsruut läheb teenuse poolesa-logic; - Pealkirjad (
name) alamhulka kasutatakse marsruutimisel alamhulga eksemplaridesse; - 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 createdNüüd, kui alamhulgad on määratletud, saame edasi liikuda ja konfigureerida VirtualService'i rakendama reegleid sa-loogika päringutele nii, et need:
- Suunatud alamhulka
v1, - Peegeldatud alamhulgaga
v2.
Järgmine manifest võimaldab teil oma plaane saavutada ():
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: v2Siin 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 createdLisame 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 ():
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: 500Virtuaalsed 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 ""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.
- lisage ajalõpp, kui teenusel kulub vastamiseks kauem kui 8 sekundit,
- proovige uuesti, kui taotlus ebaõnnestub.
Rakendamiseks kasutame järgmist ressursimääratlust ():
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- Päringu ajalõpp on seatud 8 sekundile;
- Taotlusi proovitakse uuesti 3 korda;
- 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 configuredJa 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” deletedKaitselü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 .)
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 .)
Jätan nende mustrite rakendamise üksikasjad välja, kuna neid on lihtne leida , 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": , ;
- «";
- «'.
Allikas: www.habr.com