🥇Atgal į mikropaslaugas su Istio. 2 dalis

Pastaba. vert.: Pirmoji dalis Ši serija buvo skirta supažindinti su Istio galimybėmis ir parodyti jas veikiant. Dabar kalbėsime apie sudėtingesnius šio paslaugų tinklo konfigūravimo ir naudojimo aspektus, ypač apie tiksliai suderintą maršrutą ir tinklo srauto valdymą.

Taip pat primename, kad straipsnyje naudojamos konfigūracijos (Kubernetes ir Istio manifestai) iš saugyklos istio-meistriškumas.

Eismo valdymas

Naudojant Istio klasteryje atsiranda naujų galimybių, kurios suteikia:

Dinaminis užklausų maršrutas: canary rollouts, A/B testavimas;
Apkrovos balansavimas: paprastas ir nuoseklus, pagrįstas maišais;
Atsigavimas po kritimų: skirtis, pakartotiniai bandymai, grandinės pertraukikliai;
Gedimų įvedimas: vėlavimai, atmesti prašymai ir kt.

Tęsiant straipsnį, šios galimybės bus iliustruojamos naudojant pasirinktą programą kaip pavyzdį, o pakeliui bus pristatytos naujos sąvokos. Pirmoji tokia koncepcija bus DestinationRules (t. y. taisyklės dėl srauto / užklausų gavėjo – apytikslis vertimas), kurio pagalba aktyvuojame A/B testavimą.

A/B testavimas: DestinationRules praktikoje

A/B testavimas naudojamas tais atvejais, kai yra dvi programos versijos (dažniausiai jos vizualiai skiriasi) ir nesame 100% tikri, kuri pagerins vartotojo patirtį. Todėl vienu metu vykdome abi versijas ir renkame metrikas.

Norėdami įdiegti antrąją sąsajos versiją, reikalingą A/B testavimui demonstruoti, paleiskite šią komandą:

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

Žaliosios versijos diegimo manifestas skiriasi dviem vietomis:

Vaizdas pagrįstas kita žyma - istio-green,
Ankštys turi etiketę version: green.

Kadangi abu diegimai turi etiketę app: sa-frontend,užklausos nukreiptos virtualiąja paslauga sa-external-services už paslaugą sa-frontend, bus nukreiptas į visus jo atvejus ir apkrova bus paskirstyta apvalus algoritmas, dėl ko atsiras tokia situacija:

Failai, kurių prašoma, nerasta

Šie failai nebuvo rasti, nes skirtingose programos versijose jie pavadinti skirtingai. Įsitikinkime tuo:

$ 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

Tai reiškia kad index.html, prašant vienos statinių failų versijos, apkrovos balansavimo priemonė gali nusiųsti į kitą versiją, kur dėl akivaizdžių priežasčių tokių failų nėra. Todėl, kad programa veiktų, turime nustatyti apribojimą: „ta pati programos versija, kuri aptarnavo index.html, turėtų teikti paskesnes užklausas".

Pasieksime nuoseklų maišos pagrindu pagrįstą apkrovos balansavimą (Nuoseklus maišos apkrovos balansavimas). Šiuo atveju to paties kliento užklausos siunčiamos į tą patį vidinį egzempliorių, kuriai naudojama iš anksto nustatyta ypatybė, pavyzdžiui, HTTP antraštė. Įdiegta naudojant DestinationRules.

Paskirties vietos taisyklės

Po Virtuali paslauga išsiuntė užklausą norimai paslaugai, naudodami DestinationRules galime apibrėžti politiką, kuri bus taikoma srautui, skirtam šios paslaugos atvejams:

Eismo valdymas Istio resursais

Atkreipti dėmesį: Istio išteklių poveikis tinklo srautui čia pateikiamas taip, kad būtų lengva suprasti. Tiksliau sakant, sprendimą, kuriam instancijai siųsti užklausą, priima pasiuntinys CRD sukonfigūruotame įėjimo vartuose.

Naudodami paskirties taisykles galime sukonfigūruoti apkrovos balansavimą, kad būtų naudojamos nuoseklios maišos ir būtų užtikrinta, kad tas pats paslaugos egzempliorius atsakytų tam pačiam vartotojui. Ši konfigūracija leidžia tai pasiekti (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 – maiša bus sugeneruota pagal HTTP antraštės turinį version.

Taikykite konfigūraciją naudodami šią komandą:

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

Dabar paleiskite toliau pateiktą komandą ir įsitikinkite, kad nurodydami antraštę gaunate tinkamus failus version:

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

Atkreipti dėmesį: Norėdami pridėti skirtingų verčių antraštėje ir išbandyti rezultatus tiesiogiai naršyklėje, galite naudoti šis plėtinys prie Chrome (Arba su šiuo „Firefox“ – apytiksliai. vertimas.).

Apskritai, „DestinationRules“ turi daugiau galimybių apkrovos balansavimo srityje – daugiau informacijos ieškokite oficialius dokumentus.

Prieš toliau tyrinėdami „VirtualService“, ištrinkite programos „žaliąją versiją“ ir atitinkamą eismo krypties taisyklę vykdydami šias komandas:

$ 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

Veidrodis: virtualios paslaugos praktikoje

Šešėlis („ekranavimas“) arba Veidrodis („veidrodis“) naudojamas tais atvejais, kai norime išbandyti gamybos pakeitimą nepaveikdami galutinių vartotojų: kad tai padarytume, dubliuojame ("veidrodis") užklausas antrajam atvejui, kai buvo atlikti norimi pakeitimai, ir žiūrime į pasekmes. Paprasčiau tariant, tai yra tada, kai jūsų kolega pasirenka svarbiausią problemą ir pateikia tokį didžiulį nešvarumų gabalą, kad niekas negali jo peržiūrėti.

Norėdami išbandyti šį scenarijų veikiant, sukurkime antrą SA-Logic egzempliorių su klaidomis (buggy) vykdydami šią komandą:

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

O dabar paleiskime komandą, kad įsitikintume, jog visi atvejai su app=sa-logic Jie taip pat turi etiketes su atitinkamomis versijomis:

$ 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

Tarnyba sa-logic taikosi į ankštis su etikete app=sa-logic, todėl visos užklausos bus paskirstytos visiems atvejams:

... bet norime, kad užklausos būtų siunčiamos į v1 egzempliorius ir atspindėtos į v2 egzempliorius:

Tai pasieksime per „VirtualService“ kartu su „DestinationRule“, kur taisyklės nustatys „VirtualService“ poaibius ir maršrutus į konkretų poaibį.

Poaibių apibrėžimas paskirties taisyklėse

Poaibiai (pogrupiai) yra nustatomi pagal šią konfigūraciją (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

Šeimininkas (host) apibrėžia, kad ši taisyklė taikoma tik tais atvejais, kai maršrutas eina link paslaugos sa-logic;
Pavadinimai (name) poaibiai naudojami nukreipiant į poaibių egzempliorius;
Etiketė (label) apibrėžia rakto ir reikšmių poras, kurias egzemplioriai turi atitikti, kad taptų poaibio dalimi.

Taikykite konfigūraciją naudodami šią komandą:

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

Dabar, kai apibrėžti poaibiai, galime pereiti ir sukonfigūruoti „VirtualService“, kad taikytų taisykles sa-logic užklausoms, kad jos:

Nukreiptas į poaibį v1,
Veidrodinis poaibyje v2.

Šis manifestas leidžia įgyvendinti savo planus (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

Čia nereikia jokio paaiškinimo, todėl pažiūrėkime, kaip tai veikia:

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

Pridėkime apkrovą iškviesdami šią komandą:

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

Pažiūrėkime į Grafana rezultatus, kur galite pamatyti, kad versija su klaidomis (buggy).

Sėkmingi įvairių sa-logic paslaugos versijų atsakymai

Čia pirmą kartą pamatėme, kaip „VirtualService“ taikoma mūsų paslaugų pasiuntiniams: kada sa-web-app pateikia prašymą sa-logic, jis eina per šoninį priekabą Envoy, kuris per „VirtualService“ sukonfigūruotas nukreipti užklausą į v1 poaibį ir atspindėti užklausą į paslaugos v2 poaibį. sa-logic.

Žinau, galbūt jau manote, kad virtualios paslaugos yra paprastos. Kitame skyriuje mes tai išplėsime sakydami, kad jie taip pat tikrai puikūs.

Kanarų riestainiai

„Canary Deployment“ – tai naujos programos versijos išleidimas nedideliam vartotojų skaičiui. Jis naudojamas siekiant įsitikinti, kad leidime nėra problemų ir tik po to, jau įsitikinę jo (leidimo) kokybe, platinti kitiems vartotojams.оdidesnę auditoriją.

Norėdami parodyti kanarėlių išleidimą, toliau dirbsime su pogrupiu buggy у sa-logic.

Negaiškime laiko smulkmenoms ir nedelsdami nusiųsime 20% vartotojų į versiją su klaidomis (tai atspindės mūsų kanalų diegimą), o likusius 80% į įprastą paslaugą. Norėdami tai padaryti, naudokite šią „VirtualService“ (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 yra svoris (weight), kuri nurodo užklausų, kurios bus nukreiptos gavėjui arba gavėjo pogrupiui, procentą.

Atnaujinkime ankstesnę „VirtualService“ konfigūraciją sa-logic su tokia komanda:

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

... ir iš karto pamatysime, kad kai kurios užklausos sukelia nesėkmes:

$ 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

Virtualios paslaugos įgalina platinimą: šiuo atveju sumažinome galimą problemų poveikį iki 20 % vartotojų. Nuostabu! Dabar kiekvienu atveju, kai nesame tikri dėl savo kodo (kitaip tariant – visada...), galime naudoti veidrodinį ir kanarinį išleidimą.

Skirtasis laikas ir pakartotiniai bandymai

Tačiau klaidos ne visada patenka į kodą. Sąraše iš "8 klaidingos nuomonės apie paskirstytą kompiuteriją„Pirmiausia yra klaidingas įsitikinimas, kad „tinklas yra patikimas“. Iš tikrųjų tinklas ne patikimas, todėl mums reikia skirtojo laiko (laikas baigiasi) ir bando dar kartą (bando dar kartą).

Demonstravimui ir toliau naudosime tą pačią probleminę versiją sa-logic (buggy), o tinklo nepatikimumą modeliuosime atsitiktiniais gedimais.

Tegul mūsų paslauga su riktais turi 1/3 tikimybės, kad atsakymas užtruks per ilgai, 1/3 tikimybė baigsis vidine serverio klaida ir 1/3 tikimybė sėkmingai grąžinti puslapį.

Norėdami sušvelninti tokių problemų poveikį ir pagerinti vartotojų gyvenimą, galime:

pridėti skirtąjį laiką, jei paslaugai atsakyti užtrunka ilgiau nei 8 sekundes,
bandykite dar kartą, jei užklausa nepavyks.

Diegimui naudosime šį išteklių apibrėžimą (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

Užklausos laikas nustatytas 8 sekundėms;
Prašymai pakartotinai bandomi 3 kartus;
Ir kiekvienas bandymas laikomas nesėkmingu, jei atsako laikas viršija 3 sekundes.

Tai optimizavimas, nes vartotojui nereikės laukti ilgiau nei 8 sekundes, o gedimų atveju dar tris kartus bandysime sulaukti atsakymo, padidindami sėkmingo atsakymo tikimybę.

Taikykite atnaujintą konfigūraciją naudodami šią komandą:

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

Ir patikrinkite Grafana diagramas, ar sėkmingų atsakymų skaičius išaugo aukščiau:

Sėkmingų atsakymų statistikos patobulinimai pridėjus skirtąjį laiką ir bandymus pakartoti

Prieš pereinant prie kito skyriaus (tiksliau, į kitą straipsnio dalį, nes čia nebebus jokių praktinių eksperimentų – apytiksliai vertimas), Ištrinti sa-logic-buggy ir VirtualService vykdydami šias komandas:

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

Grandinės pertraukiklio ir pertvaros modeliai

Mes kalbame apie du svarbius mikro paslaugų architektūros modelius, kurie leidžia jums pasiekti savęs atkūrimo (savaime išgijantis) paslaugos.

jungtuvo („grandinės pertraukiklis“) naudojamas nutraukti užklausas, gaunamas į paslaugos egzempliorių, kuris laikomas netinkamu, ir jį atkurti, o klientų užklausos nukreipiamos į sveikus tos paslaugos egzempliorius (tai padidina sėkmingų atsakymų procentą). (Pastaba: išsamesnį modelio aprašymą galite rasti, pavyzdžiui, čia.)

Pertvara („skyrius“) izoliuoja paslaugų gedimus nuo įtakos visai sistemai. Pavyzdžiui, B paslauga sugenda ir kita paslauga (B paslaugos klientas) pateikia užklausą tarnybai B, todėl ji išnaudoja gijų telkinį ir negali aptarnauti kitų užklausų (net jei jos nėra iš B tarnybos). (Pastaba: išsamesnį modelio aprašymą galite rasti, pavyzdžiui, čia.)

Nepateiksiu šių modelių įgyvendinimo detalių, nes juos lengva rasti oficialius dokumentus, taip pat labai noriu parodyti autentifikavimą ir autorizavimą, kurie bus aptarti kitoje straipsnio dalyje.

PS iš vertėjo

Taip pat skaitykite mūsų tinklaraštyje:

"Atgal į mikropaslaugas su Istio": 1 dalis (įvadas į pagrindines savybes), 3 dalis (autentifikavimas ir įgaliojimas);
«Conduit - lengvas Kubernetes tinklelis»;
«Kas yra paslaugų tinklelis ir kodėl man jo reikia [debesies programai su mikropaslaugomis]?".

Šaltinis: www.habr.com

Atgal į mikroservisus su Istio. 2 dalis