🥇Tagasi mikroteenuste juurde koos Istio’ga. Osa 2

Märk. tõlge.: Esimene osa Selle tsükli raames tutvustame Istio võimalusi ja demonstreerime neid praktikas. Nüüd räägime keerukamatest konfiguratsiooni ja selle service mesh'i kasutamise aspektidest, eriti detailsest marsruutimisest ja võrgu liikluse haldamisest.

Tuletame meelde, et artiklis kasutatakse konfigureerimisi (manifeste Kubernetes'i ja Istio jaoks) hoidlast istio-mastery.

Liiklustugevdus

Istio toob klastrisse uusi võimalusi, mis võimaldavad tagada:

Dünaamiline päringute marsruutimine: kanari väljalaskmine, A/B-testeerimine;
Koormuse tasakaalustamine: lihtne ja järjepidev, mis põhineb rästaste peal;
Ärikatkestuste taastamine: ajautused, uute katsete tegemine, circuit breakers;
Veateade: viivitused, päringute katkestamine jne.

Edasiartiklis näidatakse neid võimalusi valitud rakenduse näitel ning tutvustatakse uusi kontseptsioone. Esimene selline kontseptsioon on DestinationRules (s.t. liikluse/tehtud päringute reeglid — tõlkija märkus), millega aktiveerime A/B-testeerimise.

A/B-testeerimine: DestinationRules praktikas

A/B-testimist kasutatakse olukordades, kus on olemas kaks versiooni rakendusest (need erinevad tavaliselt visuaalselt) ja me ei ole sajaprotsendiliselt kindlad, milline neist parandab kasutajakogemust. Seetõttu käivitame samaaegselt mõlemad versioonid ja kogume mõõdikud.

A/B-testimise demonstreerimiseks vajaliku teise versiooni frontendi juurutamiseks execute siguiente käsk:

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

Deployment-manifest 'roheline versioon' erineb kahes kohas:

Pilt põhineb teisel sildil — istio-green,
Pod'idel on silt version: green.

Kuna mõlemal deployment'il on silt app: sa-frontend, päringud, mida suunatakse virtuaalse teenuse sa-external-services teenusele sa-frontend, suunatakse kõikide oma eksemplaride poole ja koormus jaotatakse round-robin algoritmi, mis toob kaasa järgmise olukorra:

Päringus olevaid faile ei leitud

Need failid ei olnud leitud, kuna neid nimetatakse erinevates rakenduse versioonides erinevalt. Veendugem 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, ühe staatiliste failide versiooni taotlevat päringut võib koormuse tasakaalustaja saata pod’idesse, kus on teine versioon, kus, arusaadavatel põhjustel, selliseid faile ei eksisteeri. Seetõttu, et rakendus töötaks, peame seadma piirangu: „sama rakenduse versioon, mis andis index.html, peab teenindama ka järgnevates päringutes».

Sellele eesmärgile jõuame kooskõlalise koormuse tasakaalustamisega, kasutades hajurehkendusi (Kooskõlaline Hash Koormuse Tasakaalustamine). Sel juhul saab ühe kliendi päringud suunata samasse tagapaneeli instantsi, milleks kasutatakse eeldefineeritud omadust — näiteks HTTP-pealkiri. See teostatakse kasutades DestinationRules.

DestinationRules

Pärast seda, kui VirtualService suunab päringu õige teenuse poole, saame DestinationRules'i abil määrata poliitikad, mis kehtivad selle teenuse instantsidele suunatud liiklusele:

Liikluse haldamine Istio ressurssidega

Märkus: Istio ressursside mõju võrguliiklusele on siin esitatud lihtsustatud ja arusaadavas vormis. Täpsemalt öeldes otsustab, millisele instantsile päring saata, Envoy Ingress Gateway’is, mis on CRD-s seadistatud.

Destination Rules abil saame me seadistada load balancing`u nii, et kasutatakse ühtseid hashe ja garanteeritakse, et sama teenuse eksemplar vastab samale kasutajale. Järgmine konfiguratsioon võimaldab selle saavutamist (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 genereeritakse HTTP-pealkirja sisu põhjal version.

Rakendage konfiguratsioon järgmise käsu abil:

$ 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 sa saate õiged failid, kui täiendate pealkirja version:

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

Märkus: Erinevate väärtuste lisamiseks pealkirja ja testimiseks tulemusi otse brauseris, võite kasutada seda laiendust Chrome'i jaoks (või selle Firefoxi jaoks — toimetaja märkus).

Tegelikult on Destination Rules`il rohkem võimalusi load balancing`u osas — täiendavat teavet küsige. ametlikus dokumentatsioonis.

Enne VirtualService'i edasist uurimist eemaldame rakenduse «roheline versioon» ja vastava liiklussuunamise 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: Virtual Services praktikas

Shadowing («ekraanimine») või Mirroring («peegelduse») rakendatakse juhtudel, kui soovime testida muudatust tootmises, mõjutamata lõppkasutajaid: selleks kopeerime («peegelduse») päringud teisele eksemplarile, kus vajalikud muudatused on tehtud, ja vaatame tagajärgi. Teisisõnu, see on siis, kui teie kolleeg valib kõige kriitilisema probleemi ja teeb pull request'i sellise tohutu määrdekamaka näol, et keegi ei saa tegelikult sellele ülevaadet anda.

Selle stsenaariumi kontrollimiseks rakendame teise SA-Logic eksemplari 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äime käsu, et veenduda, et kõik eksemplarid on app=sa-logic on ka labelid koos vastavate versioonidega:

$ 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

Teenuse sa-logic fokuseerib pod'e, millel on label app=sa-logic, seega jaotatakse kõik päringud kõigi eksemplaride vahel:

… kuid me tahame, et päringud suunataks versiooni v1 eksemplaridele ja peegeldataks versiooni v2 eksemplaridele:

Saavutame selle VirtualService'i kaudu koos DestinationRule'iga, kus reeglid määravad alagrupid ja VirtualService'i marsruudid konkreetsele alagrupile.

Alagruppide määratlemine Destination Rules'is

Alagrupid (alagrupid) määratakse järgmise konfiguratsiooni kaudu (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

Host (host) määrab, et seda reeglit rakendatakse ainult juhul, kui marsruut suundub teenusele sa-logic;
Alagruppide nimed (name) kasutatakse alagruppide eksemplaride marsruutimiseks;
Label (silt) määrab võtme-väärtuse paarid, millele eksemplarid peavad vastama, et saada osa alamkogust.

Rakendage konfiguratsioon järgmise käsu abil:

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

Nüüd, kui alamkogud on määratletud, saame liikuda edasi ja seadistada VirtualService, et rakendada reegleid sa-logic'i päringutele, et need:

Suunatakse alamkogusse v1,
Peegeldatakse alamkogusse v2.

Järgmine manifest saavutab soovitud tulemuse (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

Selgitused ei ole siin vajalikud, nii et vaatame lihtsalt toimetulekut:

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

Lisame koormuse järgmise käsuga:

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

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

Erinevate sa-logic teenuse versioonide vastuste edukus.

Siin nägime esmakordselt, kuidas VirtualService rakendatakse meie teenuste Envoy’ide suhtes: kui sa-web-app saab päringu sa-logic, läbib see sidecar Envoy'i, mis on — VirtualService'i kaudu — seadistatud marsruudiks päringule alamgrupi v1 suunas ja päringu peegeldamiseks alamgrupi v2 suunas teenusel. sa-logic.

Tean: olete juba mõelnud, et Virtual Services on lihtsad. Järgmises jaotises laiendame seda arvamust, näidates, et nad on tõeliselt suurepärased.

Kanari väljalasked.

Canary Deployment — uue versiooni väljalaskmise protsess rakendusele väikesele kasutajate rühmale. Seda kasutatakse, et veenduda, et väljaandes ei ole probleeme, ja alles seejärel, olles veendunud piisavas kvaliteedis, levitada seda suuremale publikule.olaiemat publikut.

Kanari väljalaskude demonstreerimiseks jätkame töötamist alamgrupiga. buggy on sa-logic.

Ei ole mõtet pisiasjadesse laskuda ja suuname kohe 20% kasutajatest veaga versioonile (see esindab meie kanarollimist), samas kui ülejäänud 80% lähevad normaalsesse teenusesse. Selleks rakendame järgmise 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 — see on kaal (weight), mis määrab protsendi päringutest, mis suunatakse saajale või saaja alagrupile.

Uuendame eelnevat VirtualService'i konfigureerimist 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 konfigureeritud

… ja näeme kohe, et osa päringutest viib tõrgeteni:

$ while true; do 
   curl -i http://$EXTERNAL_IP/sentiment 
   -H "Content-type: application/json" 
   -d '{"sentence": "Mulle meeldib yogobella"}' 
   --silent -w "Aeg: %{time_total}s t Staatus: %{http_code}n" 
   -o /dev/null; sleep .1; done
Aeg: 0.153075s Staatus: 200
Aeg: 0.137581s Staatus: 200
Aeg: 0.139345s Staatus: 200
Aeg: 30.291806s Staatus: 500

VirtualServices aktiveerivad kanariväljakud: sel juhul oleme vähendanud potentsiaalseid tagajärgi probleemide tõttu 20% kasutajabaasist. Suurepärane! Nüüd, iga kord, kui me ei ole oma koodis kindlad (teisisõnu — alati…), saame kasutada peegeldamist ja kanariväljakuid.

Ajaülekanded ja uuesti proovimine

Kuid alati ei pruugi vead olla koodis. Nimekirjas "8 müüti jaotatud arvutustes" järel on esimene vale arvamus, et "võrk on usaldusväärne". Tegelikult on võrk ei usaldusväärne ja seetõttu vajame ajaülekandeid (timeouts) ja uuesti proovimist (retries)..

Demonstratsiooniks jätkame sama probleemiversiooni kasutamist sa-logic (buggy), samas kui võrgus usaldamatust simuleerime juhuslike tõrgetega.

Las meie vead sisaldav teenus on 1/3 tõenäosus liiga pika vastuse saamiseks, 1/3 — Internal Server Erroriga lõpetamiseks ja 1/3 — lehe edastamiseks eduka vastusena.

Sarnaste probleemide tagajärgede leevendamiseks ja kasutajate elu paremaks muutmiseks saame:

lisada ajaülekande, kui teenus vastab kauem kui 8 sekundit,
teha uuesti proovimist, kui päringul esineb tõrge.

Jätkamiseks kasutame sellist ressursi mää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

Küsimuse ajakava on seadistatud 8 sekundiks;
Küsimuste korduvad katsed tehakse 3 korda;
Ja iga katse loetakse ebaõnnestunuks, kui vastuse aeg ületab 3 sekundit.

Nii oleme saavutanud optimeerimise, kuna kasutaja ei pea ootama enam kui 8 sekundit ja me teeme kolm uut katset saada vastus tõrgete korral, suurendades võimalust saada eduka vastuse.

Rakendage uuendatud 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 diagrammides, et eduka vastuse arv tõusis üle:

Parandused edukaid vastuseid statistikas pärast ajakava ja korduvate katsete lisamist

Enne järgmisse jaotusse liikumist (ja täpsemalt — juba järgmisse artikli osasse, kuna selles praktikalisi katseid enam ei toimu — toimetaja märk.), eemalda sa-logic-buggy ja VirtualService, täites järgmised käsud:

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

Circuit Breaker ja Bulkhead mustrid

Räägime kahest olulisest mustrist mikroteenuste arhitektuuris, mis võimaldavad saavutada iseravimist (self-healing) teenuste.

Circuit Breaker („automaatne välja lülitaja“) kasutatakse tervisele halva staatusega teenuse eksemplaridele saadetud päringute katkestamiseks ning nende taastamiseks samal ajal, kui klientide päringud suunatakse selle teenuse tervetesse eksemplaridesse (mis suurendab eduka vastuse protsenti). (Toim. märk.: Üksikasjalikuma kirjelduse mustrist leiate näiteks siit.)

Bulkhead („vahe sein“) isoleerib teenuste tõrkeid kogu süsteemi rikke eest. Näiteks kui teenus B on rikki läinud, teeb teenuse B klient arstiteenuse B suhtes päringu, mille tulemusena kasutab ta oma sisendite kogumi ja ei suuda teenindada teisi päringuid (isegi kui need ei ole seotud teenusega B). (Toim. märk.: Üksikasjalikuma kirjelduse mustrist leiate näiteks siit.)

Jätan vahele üksikasjad nende mustrite rakendamise kohta, kuna neid on lihtne leida ametlikus dokumentatsioonis, samuti on tõeliselt soovitatav näidata autentimist ja autoriseerimist, millest tuleb juttu artikli järgmises osas.