🥇Tagasi mikroteenuste juurde koos Istio. Osa 2

Märkus tõlke kohta.: Esimene osa selle tsükli keskmes oli tutvumine Istio võimalustega ja nende demonstreerimine praktikas. Nüüd räägime keerukamatest seadistamis- ja kasutusaspektidest, eelkõige detailvaitud marsruutimisest ja võrgu kaudu suunamise juhtimisest.

Tuletame meelde, et artiklis kasutatakse Kubernetese ja Istio konfigureerimist (manifestid) hoidlast istio-mastery.

Liikluse haldamine

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

Dünaamilise päringute marsruutimise: kanarise väljalaskmine, A/B-testimine;
Koormuse tasakaalustamine: lihtne ja järjepidev, põhinev hashidel;
Tõrgete taastumine: ajavood, uued katsed, ringlusetõkked;
Rikkumiste lisamine: viivitused, päringute katkestamine jne.

Artikli jätkudes näidatakse neid võimalusi valitud rakenduse näitel ja samal ajal tutvustatakse uusi kontseptsioone. Esimene neist kontseptsioonidest on DestinationRules (st liiklabeleid / päringutele – tõlkija märkus), mille abil aktiveerime A/B-testimise.

A/B-testimine: DestinationRules praktikas

A/B-testimist kasutatakse juhtudel, kui on olemas kaks rakenduse versiooni (tavaliselt erinevad visuaalselt) ja me ei ole 100% kindlad, milline neist parandab kasutajakogemust. Seetõttu käivitame samal ajal mõlemad versioonid ja kogume mõõdikut.

Teise versiooni front-end'i juurutamiseks, mis on vajalik A/B-testimise demonstreerimiseks, täitke järgmine käsk:

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

«Rohelise versiooni» juurutamise manifest erineb kahes kohas:

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

Kuna mõlemal juurutamisel on silt rakendus: sa-frontend, päringud, mida marsruutib virtuaalne teenus sa-external-services , suunatakse kõikidele selle instantsidele ja koormus jaguneb sa-frontendround-robin algoritmi , mis viib järgmise olukorrani:Päringud failid ei leitud

Need failid ei leitud, kuna need on rakenduse erinevates versioonides erinevate nimedega. Veendume selles:

See tähendab, et

$ 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

index.html index.html, mille versiooni staatilisi faile, võib koormuse tasakaalustaja saata pod’idele, millel on erinev versioon, kus, arusaamatutel põhjustel, selliseid faile ei ole. Seetõttu, et rakendus töötaks, peame kehtestama piiri: „sama rakenduse versioon, mis saatis index.html, peab teenindama ka järgmisi päringuid».

Saavutame eesmärgi kooskõlalisel koormuse tasakaalustamisel, mis põhineb hash-idel (Kooskõlaline Hash Koormuse Tasakaalustamine). Sel juhul saadetakse ühe kliendi päringud samasse tagaplaneedi eksemplari, milleks kasutatakse eeldefineeritud omadust - näiteks HTTP-päist. See on rakendatud DestinationRules abil.

DestinationRules

Pärast seda, kui VirtualService suunas päringu soovitud teenusele, saame DestinationRules abil määrata poliitikad, mida rakendatakse sellele teenusele suunatud liiklusele:

Liiklus haldamine Istio ressurssidega

Märkus: Istio ressursside mõju võrgu liiklusele on siin esitatud lihtsustatud mõistetaval viisil. Täpselt öeldes tehakse otsus, millisele eksemplarile päring saata, Envoy poolt Ingress Gateway’s, mis on seadistatud CRD-s.

Destination Rules abil saame seadistada koormuse tasakaalu nii, et kasutataks kooskõlalisi hash-e ja tagataks ühe ja sama teenuse eksemplari vastused ühele ja sama kasutajale. Järgmine konfiguratsioon võimaldab 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 — hash 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

Ja nüüd käivitage allolev käsk ja veenduge, et saaksite soovitud failid, kui määrate päise version:

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

Märkus: Erinevate väärtuste lisamiseks päisesse ja testimiseks tulemusi otse brauseris võite kasutada seda laiendust Chrome’ile (või seda Firefox’ile — täiendav märk..

Üldiselt on DestinationRules'il rohkem võimalusi koormuse tasakaalustamise osas — üksikasju täpsustage. ametlikust dokumentatsioonist.

Enne kui uurime VirtualService'i süvitsi, kustutame „roheline versioon“ rakendusest ja vastava reegli liikluse suunamiseks, 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

Varjamine („ekraanimine“) või Peegeldamine („peegeldamine“) rakendatakse siis, kui soovime testida muudatust tootmises, kahjustamata lõppkasutajaid: selleks kopeerime („peegeldame“) päringud teisele eksemplarile, kus on tehtud vajalikud muudatused, ja vaatame tagajärgi. Teisisõnu, see on siis, kui teie kolleeg valib kõige kriitilisema probleemi ja teeb pull request'i sellise tohutu segaduse kujul, et keegi ei saa tõeliselt teha sellele ülevaate.

Selle stsenaariumi aktsiooni kontrollimiseks loome 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äivitame käsu, et veenduda, et kõik eksemplarid, millel on app=sa-logic , omavad ka silte 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

Teenuseid sa-logic suunatud pod'idele, millel on silt app=sa-logic, seega jaotatakse kõik päringud kõigi eksemplaride vahel:

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

Selle saavutamiseks kasutame VirtualService'i koos DestinationRule'iga, kus reeglid määravad VirtualService'i alarühmad ja marsruudid konkreetse alarühma jaoks.

Alarühmade määratlemine Destination Rules

Alarühmad (subsets) määratletakse 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

Host (host) määratleb, et seda reeglit rakendatakse ainult siis, kui marsruut suundub teenusele sa-logic;
Nimed (nimi) alarühmade kasutatakse marsruutimiseks alarühma eksemplaride suunas;
Silt (label) määratleb võtme-väärtuse paare, millele instantsid peavad vastama, et nende seonduda alamhulgaga.

Rakendage konfiguratsioon järgmise käsuga:

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

Nüüd, kui alamhulgad on määratletud, saame edasi liikuda ja seadistada VirtualService, et kohaldada reegleid sa-logicile esitatavatele päringutele:

suunata alamhulka v1,
peegeldada alamhulka v2.

Järgmine manifeest võimaldab saavutada soovitud (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 ei ole selgitusi vajalikud, nii et vaatame lihtsalt toimingut:

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

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

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

Erinevate sa-logic teenuse versioonide vastustega seotud edukus

Siin nägime esmakordselt, kuidas VirtualService rakendatakse meie teenuste Envoy'ide suhtes: kui sa-web-app teeb päringu sa-logic, läbib see sidecar Envoy, mis - läbi VirtualService - on seadistatud suunama päringu alamhulka v1 ja peegeldama päringut alamhulka v2 teenuses sa-logic.

Tean: te olete juba mõelnud, et Virtual Services on lihtsad. Järgmises osas laiendame seda arvamust, et nad on ka tõeliselt suured.

Kanarisüsteemide juurutamine

Canary Deployment on uue tarkvaraversiooni juurutamise protsess väikesele kasutajate arvule. Seda kasutatakse, et veenduda, et versioonis ei esine probleeme, ja ainult seejärel, olles kindel, et kvaliteet on piisav, levitada suuremale publikule.ilotkaSelleks, et demonstreerida kanarisüsteemide juurutamist, jätkame alamhulga tööga.

Ärme ole tagasihoidlikud ja suuname kohe 20 % kasutajatest vigadega versioonile (kellel on meie kanarisüsteem) ja ülejäänud 80 % töökorrale. Selleks rakendame järgmise VirtualService ( buggy on sa-logic.

sa-logic-subsets-canary-vs.yamlsa-logic-alamhuh-kihtibkanari-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 kaal (kaal), mis määrab protsendi päringutest, mis suunatakse sihtpunkti või sihtpunktide alamkogusse.

Uuendame eelmist VirtualService konfiguratsiooni sa-logic järgiva käsuga:

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

… ja kohe näeme, et osa päringutest lõpeb tõrgetega:

$ while true; do 
   curl -i http://$EXTERNAL_IP/sentiment 
   -H "Content-type: application/json" 
   -d '{"sentence": "Ma armastan 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 kanarullid: antud juhul piirasime potentsiaalseid tagajärgi probleemide korral 20% kasutajabaasist. Suurepärane! Nüüd, kui me pole oma koodis kindlad (teisisõnu — alati…), saame kasutada peegeldamist ja kanarulle.

Aegade ja katsete kordamine

Kuid mitte alati ei esine vead koodis. „8 eksiarvamust jaotatud arvutustes“ nimekirjas on esikohal vale arvamus, et „võrk on usaldusväärne“. Tegelikult on võrk ei usaldusväärne ja seetõttu vajame aegade (timeouts) ja katseid (retries).

Käsitluse demonstreerimiseks jätkame sama probleemiversiooniga sa-logic (buggy), samas kui võrgu ebamugavust simuleerime juhuslike tõrgetega.

Las meie probleemidekandja teenusel on 1/3 tõenäosus liiga pika vastuse saamiseks, 1/3 lõpetamisest Internal Server Erroriga ja 1/3 eduka lehe ülekandmiseks.

Probleemide mõju leevendamiseks ja kasutajakogemuse parandamiseks saame:

lisada ajaülekande, kui teenus reageerib kauem kui 8 sekundit,
ette võtta katse, kui päring ebaõnnestub.

Rakendamiseks kasuta 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

Päringu aeg on seatud 8 sekundile;
Päringute katseid tehakse 3 korda;
Ja iga katse loetakse ebaõnnestunuks, kui vastuse aeg ületab 3 sekundit.

Nii oleme saavutanud optimeerimise, kuna kasutaja ei pea ootama kauem kui 8 sekundit ja teeme kolm uut katset, et saada vastust tõrgete korral, suurendades tõhusat vastamise võimalusi.

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 konfigureeritud

Ja kontrollige Grafana graafikutes, et eduka vastuse arv on tõusnud üle:

Parandused eduka vastuse statistikas pärast ajaülesannete ja korduste lisamist

Enne järgmist jaotist (ning täpsemalt — juba järgmises artikli osas, sest selles ei ole enam praktilisi katseid — toimetuse märk.), eemaldage sa-logic-buggy ja VirtualService, täites järgmised käsud:

$ kubectl delete deployment sa-logic-buggy
deployment.extensions "sa-logic-buggy" kustutatud
$ kubectl delete virtualservice sa-logic
virtualservice.networking.istio.io "sa-logic" kustutatud

Circuit Breaker ja Bulkhead mustrid

Rääkime kahest olulisest mustrist mikroteenuste arhitektuuris, mis võimaldavad saavutada iseseisvat taastumist (self-healing) teenustest.

Circuit Breaker („automaatväljalüliti”) kasutatakse, et peatada päringud, mis suunatakse teenuse eksemplarile, mida peetakse ebatervislikuks, ning selle taastumist ajal, kui kliendi päringud suunatakse tervele sellele teenusele, mis tõstab eduka vastuse protsenti. (Toimetuse märk.: Üksikasjalikku kirjeldust mustrist saab leida näiteks siin.)

Bulkhead („vahesein”) isoleerib teenuste tõrked süsteemi häirimisest. Näiteks, kui teenus B on katki, ja teine teenus (teenuse B klient) teeb päringu teenusele B, siis see kasutab oma teede pered ja ei saa teenindada teisi päringuid (isegi kui need ei puuduta teenust B). (Toimetuse märk.: Üksikasjalikku kirjeldust mustrist saab leida näiteks siin.)

Jätan need mustrite rakendamise üksikasjad vahele, kuna neid on lihtne leida, ametlikust dokumentatsioonist, samuti tahaks juba näidata autentimist ja autoriseerimist, millest on juttu järgmises artikli osas.