Nazaj k mikrostoritvam z Istio. 2. del

Opomba. prevod: Prvi del Ta serija je bila namenjena predstavitvi zmogljivosti Istio in njihovi predstavitvi v akciji. Zdaj bomo govorili o bolj zapletenih vidikih konfiguracije in uporabe te storitvene mreže, zlasti pa o natančno nastavljenem usmerjanju in upravljanju omrežnega prometa.

Spomnimo vas tudi, da članek uporablja konfiguracije (manifeste za Kubernetes in Istio) iz repozitorija istio-mojstrstvo.

Upravljanje prometa

Z Istio se v gruči pojavijo nove zmogljivosti, ki zagotavljajo:

• Dinamično usmerjanje zahtev: kanarčki, A/B testiranje;
• Izravnavanje obremenitve: preprosto in dosledno, na osnovi zgoščenih vrednosti;
• Okrevanje po padcih: časovne omejitve, ponovni poskusi, odklopniki;
• Vstavljanje napak: zamude, zavržene zahteve itd.

V nadaljevanju članka bodo te zmožnosti ponazorjene z izbrano aplikacijo kot primerom, ob tem pa bodo predstavljeni novi koncepti. Prvi tak koncept bo DestinationRules (tj. pravila o prejemniku prometa/zahtev – pribl. prev.), s pomočjo katerega aktiviramo A/B testiranje.

A/B testiranje: DestinationRules v praksi

A/B testiranje uporabljamo v primerih, ko obstajata dve različici aplikacije (običajno sta vizualno različni) in nismo 100% prepričani, katera bo izboljšala uporabniško izkušnjo. Zato izvajamo obe različici hkrati in zbiramo metrike.

Če želite razmestiti drugo različico sprednjega dela, ki je potrebna za predstavitev testiranja A/B, zaženite naslednji ukaz:

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

Manifest uvajanja za zeleno različico se razlikuje na dveh mestih:

1. Slika temelji na drugi oznaki - istio-green,
2. Stroki imajo etiketo version: green.

Ker imata obe umestitvi oznako app: sa-frontend, zahteve, ki jih usmerja navidezna storitev sa-external-services za servis sa-frontend, bo preusmerjen na vse svoje primerke in obremenitev bo porazdeljena prek krožni algoritem, kar bo privedlo do naslednje situacije:

Zahtevane datoteke niso bile najdene

Teh datotek ni bilo mogoče najti, ker so v različnih različicah aplikacije različno poimenovane. Prepričajmo se o tem:

$ 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

To pomeni, da index.html, ki zahteva eno različico statičnih datotek, lahko izravnalnik obremenitve pošlje podom, ki imajo drugačno različico, kjer takšne datoteke iz očitnih razlogov ne obstajajo. Zato moramo za delovanje aplikacije nastaviti omejitev: “ista različica aplikacije, ki je služila index.html, bi morala služiti naslednjim zahtevam".

To bomo dosegli z doslednim uravnoteženjem obremenitve na podlagi zgoščenih vrednosti (Dosledno izravnavanje obremenitve hash). V tem primeru zahteve istega odjemalca so poslane isti zaledni instanci, za katerega se uporablja vnaprej določena lastnost – na primer glava HTTP. Izvedeno z uporabo DestinationRules.

DestinationRules

Po VirtualService poslal zahtevo želeni storitvi, lahko z uporabo DestinationRules definiramo politike, ki bodo uporabljene za promet, namenjen primerkom te storitve:

Upravljanje prometa z viri Istio

Obvestilo: Vpliv virov Istio na omrežni promet je tukaj predstavljen na lahko razumljiv način. Če smo natančni, odločitev o tem, kateri instanci poslati zahtevo, sprejme Envoy v vstopnem prehodu, konfiguriranem v CRD.

S ciljnimi pravili lahko konfiguriramo uravnoteženje obremenitve za uporabo doslednih zgoščenih vrednosti in zagotovimo, da se isti primerek storitve odziva na istega uporabnika. Naslednja konfiguracija vam omogoča, da to dosežete (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 - zgoščena vrednost bo ustvarjena na podlagi vsebine glave HTTP version.

Uporabite konfiguracijo z naslednjim ukazom:

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

Zdaj zaženite spodnji ukaz in se prepričajte, da dobite prave datoteke, ko podate glavo version:

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

Obvestilo: Če želite dodati različne vrednosti v glavo in preizkusiti rezultate neposredno v brskalniku, lahko uporabite ta razširitev v Chrome (Ali s tem za Firefox - pribl. prev.).

Na splošno ima DestinationRules več zmožnosti na področju uravnoteženja obremenitve - preverite podrobnosti v uradna dokumentacija.

Preden nadaljujemo s preučevanjem VirtualService, izbrišemo »zeleno različico« aplikacije in ustrezno pravilo za usmerjanje prometa z izvajanjem naslednjih ukazov:

$ 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

Zrcaljenje: Virtualne storitve v praksi

Senčenje ("zaščita") ali Zrcaljenje ("zrcaljenje") uporablja se v primerih, ko želimo preizkusiti spremembo v produkciji, ne da bi to vplivalo na končne uporabnike: za to podvojimo (»zrcalimo«) zahteve na drugo instanco, kjer so bile opravljene želene spremembe, in pogledamo posledice. Preprosto povedano, to je takrat, ko vaš kolega izbere najbolj kritično težavo in poda zahtevo za vleko v obliki tako velike kepe umazanije, da je nihče ne more dejansko pregledati.

Če želite preizkusiti ta scenarij v akciji, ustvarimo drugi primerek SA-Logic z napakami (buggy) z izvajanjem naslednjega ukaza:

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

In zdaj zaženimo ukaz, da se prepričamo, da so vsi primerki z app=sa-logic Imajo tudi oznake z ustreznimi različicami:

$ 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

Orodja sa-logic cilja na stroke z oznako app=sa-logic, zato bodo vse zahteve porazdeljene med vse instance:

... vendar želimo, da se zahteve pošljejo primerkom v1 in zrcalijo primerkom v2:

To bomo dosegli prek VirtualService v kombinaciji z DestinationRule, kjer bodo pravila določala podnabore in poti VirtualService do določenega podnabora.

Definiranje podnaborov v ciljnih pravilih

Podmnožice (podmnožice) so določene z naslednjo konfiguracijo (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. Gostitelj (host) določa, da to pravilo velja samo za primere, ko gre pot proti servisu sa-logic;
2. Naslovi (name) podnabori se uporabljajo pri usmerjanju v primerke podnabora;
3. Oznaka (label) definira pare ključ-vrednost, s katerimi se morajo primerki ujemati, da postanejo del podnabora.

Uporabite konfiguracijo z naslednjim ukazom:

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

Zdaj, ko so podnabori definirani, lahko nadaljujemo in konfiguriramo VirtualService za uporabo pravil za zahteve za sa-logiko, tako da:

1. Usmerjen v podnabor v1,
2. Zrcaljeno v podmnožico v2.

Naslednji manifest vam omogoča uresničitev vaših načrtov (sa-logic-subset-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

Tukaj ni potrebna nobena razlaga, zato si poglejmo, kako deluje:

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

Dodajmo obremenitev s klicem naslednjega ukaza:

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

Poglejmo rezultate v Grafani, kjer lahko vidite, da različica s hrošči (buggy) povzroči napako pri približno 60 % zahtev, vendar nobena od teh napak ne vpliva na končne uporabnike, saj se nanje odzove delujoča storitev.

Uspešni odzivi različnih različic storitve sa-logic

Tukaj smo prvič videli, kako se VirtualService uporablja za odposlance naših storitev: kdaj sa-web-app zaprosi za sa-logic, gre skozi sidecar Envoy, ki je – prek VirtualService – konfiguriran tako, da usmeri zahtevo v podmnožico v1 in zrcali zahtevo v podmnožico v2 storitve sa-logic.

Vem, morda že mislite, da so virtualne storitve preproste. V naslednjem razdelku bomo to razširili z besedami, da so tudi resnično odlični.

Canary rollouts

Canary Deployment je postopek uvajanja nove različice aplikacije majhnemu številu uporabnikov. Uporablja se zato, da se prepriča, da v izdaji ni težav, in šele nato, ko je že prepričan v njeno kakovost (izdaje), jo distribuira drugim uporabnikom.оvečje občinstvo.

Za predstavitev uvajanja kanarčkov bomo nadaljevali delo s podnaborom buggy у sa-logic.

Ne izgubljajmo časa z malenkostmi in takoj pošljimo 20% uporabnikov na različico s hrošči (to bo predstavljalo naš kanarček), preostalih 80% pa na običajno storitev. Če želite to narediti, uporabite naslednjo VirtualService (sa-logic-podmnožic-kanarčka-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 je teža (weight), ki določa odstotek zahtev, ki bodo usmerjene k prejemniku ali podmnožici prejemnika.

Posodobimo prejšnjo konfiguracijo VirtualService za sa-logic z naslednjim ukazom:

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

... in takoj bomo videli, da nekatere zahteve vodijo do napak:

$ 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

VirtualServices omogočajo kanarčkove uvedbe: V tem primeru smo potencialni vpliv težav zmanjšali na 20 % baze uporabnikov. čudovito! Sedaj lahko v vsakem primeru, ko nismo prepričani o svoji kodi (z drugimi besedami - vedno...), uporabimo zrcaljenje in kanarčkove rolloute.

Časovne omejitve in ponovni poskusi

Toda napake se ne končajo vedno v kodi. Na seznamu od "8 napačnih predstav o porazdeljenem računalništvu»Na prvem mestu je zmotno prepričanje, da je »omrežje zanesljivo«. V resnici omrežje ne zanesljiv, zato potrebujemo časovne omejitve (časovne omejitve) in znova poskusi (ponovno).

Za predstavitev bomo še naprej uporabljali isto različico problema sa-logic (buggy), in simulirali bomo nezanesljivost omrežja z naključnimi okvarami.

Naj ima naša storitev s hrošči 1/3 možnosti, da se predolgo odzove, 1/3 možnosti, da se konča z notranjo napako strežnika, in 1/3 možnosti, da uspešno vrne stran.

Da bi ublažili vpliv takih težav in izboljšali življenje uporabnikov, lahko:

1. dodajte časovno omejitev, če storitev potrebuje več kot 8 sekund, da se odzove,
2. poskusite znova, če zahteva ne uspe.

Za izvedbo bomo uporabili naslednjo definicijo vira (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. Časovna omejitev za zahtevo je nastavljena na 8 sekund;
2. Zahteve se ponovijo 3-krat;
3. In vsak poskus se šteje za neuspešnega, če odzivni čas presega 3 sekunde.

To je optimizacija, ker uporabniku ne bo treba čakati več kot 8 sekund in v primeru neuspešnih odgovorov bomo poskusili dobiti trikrat, kar bo povečalo možnost uspešnega odgovora.

Uporabite posodobljeno konfiguracijo z naslednjim ukazom:

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

In preverite v grafih Grafana, da se je število uspešnih odgovorov povečalo zgoraj:

Izboljšave statistike uspešnih odzivov po dodajanju časovnih omejitev in ponovnih poskusov

Preden preidete na naslednji razdelek (oziroma na naslednji del članka, ker v tem ne bo več praktičnih poskusov - pribl. prev.), izbriši sa-logic-buggy in VirtualService z izvajanjem naslednjih ukazov:

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

Vzorci odklopnikov in pregrad

Govorimo o dveh pomembnih vzorcih v arhitekturi mikrostoritev, ki omogočata samoobnovitev (samozdravljenje) storitve.

Varovalka ("varovalka") uporablja se za prekinitev zahtev, ki prihajajo do primerka storitve, ki velja za nezdravo, in jo obnovi, medtem ko so zahteve odjemalcev preusmerjene na zdrave primerke te storitve (kar poveča odstotek uspešnih odgovorov). (Opomba: podrobnejši opis vzorca lahko najdete npr. tukaj.)

Pregrada ("particija") ločuje napake storitev od vpliva na celoten sistem. Storitev B je na primer pokvarjena in druga storitev (odjemalec storitve B) pošlje zahtevo storitvi B, zaradi česar ta izčrpa svoje področje niti in ne more servisirati drugih zahtev (tudi če niso iz storitve B). (Opomba: podrobnejši opis vzorca lahko najdete npr. tukaj.)

Izpustil bom podrobnosti izvedbe teh vzorcev, ker jih je enostavno najti uradna dokumentacija, prav tako pa resnično želim prikazati avtentikacijo in avtorizacijo, o čemer bomo razpravljali v naslednjem delu članka.

PS od prevajalca

Preberite tudi na našem blogu:

• "Nazaj k mikrostoritvam z Istio": 1. del (uvod v glavne značilnosti), 3. del (avtentikacija in avtorizacija);
• «Conduit - lahka servisna mreža za Kubernetes»;
• «Kaj je storitvena mreža in zakaj jo potrebujem [za aplikacijo v oblaku z mikrostoritvami]?".

Vir: www.habr.com