🥇Späť na mikroslužby s Istio. Časť 2

Poznámka. preklad.: Prvá časť Táto séria bola venovaná predstaveniu schopností Istio a ich demonštrácii v praxi. Teraz budeme hovoriť o zložitejších aspektoch konfigurácie a používania tejto siete služieb, a najmä o jemne vyladenom smerovaní a riadení sieťovej prevádzky.

Pripomíname tiež, že článok používa konfigurácie (manifesty pre Kubernetes a Istio) z úložiska istio-majstrovstvo.

Riadenie dopravy

S Istio sa v klastri objavujú nové možnosti, ktoré poskytujú:

Dynamické smerovanie požiadaviek: zavedenie kanárikov, A/B testovanie;
Rozdelenie výkonu: jednoduché a konzistentné, založené na hashoch;
Zotavenie po pádoch: časové limity, opakované pokusy, ističe;
Vkladanie chýb: meškania, zrušené požiadavky atď.

Ako článok pokračuje, tieto možnosti budú ilustrované na príklade vybranej aplikácie a zároveň budú predstavené nové koncepty. Prvý takýto koncept bude DestinationRules (t.j. pravidlá o príjemcovi návštevnosti/žiadosti - cca preklad), pomocou ktorej aktivujeme A/B testovanie.

A/B testovanie: DestinationRules v praxi

A/B testovanie sa používa v prípadoch, keď existujú dve verzie aplikácie (zvyčajne sú vizuálne odlišné) a nie sme si 100% istí, ktorá z nich zlepší používateľský zážitok. Preto spúšťame obe verzie súčasne a zbierame metriky.

Ak chcete nasadiť druhú verziu frontendu, ktorá je potrebná na demonštráciu A/B testovania, spustite nasledujúci príkaz:

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

Manifest nasadenia pre zelenú verziu sa líši na dvoch miestach:

Obrázok je založený na inej značke - istio-green,
Struky majú štítok version: green.

Keďže obe nasadenia majú štítok app: sa-frontend,žiadosti smerované virtuálnou službou sa-external-services za službu sa-frontend, bude presmerovaný na všetky jeho inštancie a zaťaženie bude distribuované cez algoritmus round-robin, čo povedie k nasledujúcej situácii:

Požadované súbory sa nenašli

Tieto súbory sa nenašli, pretože sú v rôznych verziách aplikácie pomenované inak. Presvedčime sa o tom:

$ 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 znamená, že index.html, požadujúce jednu verziu statických súborov, môže nástroj na vyrovnávanie záťaže odoslať do modulov, ktoré majú inú verziu, kde zo zrejmých dôvodov takéto súbory neexistujú. Preto, aby aplikácia fungovala, musíme nastaviť obmedzenie: “rovnaká verzia aplikácie, ktorá obsluhovala index.html, by mala obsluhovať nasledujúce požiadavky".

Dostaneme sa tam s konzistentným vyvažovaním záťaže na základe hash (Konzistentné hashové vyrovnávanie zaťaženia), V tomto prípade požiadavky od toho istého klienta sa odosielajú do rovnakej inštancie backendu, pre ktorú sa používa preddefinovaná vlastnosť – napríklad hlavička HTTP. Implementované pomocou DestinationRules.

Pravidlá destinácie

potom, čo VirtualService odoslal požiadavku na požadovanú službu, pomocou DestinationRules môžeme definovať pravidlá, ktoré sa použijú na prevádzku určenú pre inštancie tejto služby:

Riadenie dopravy so zdrojmi Istio

Poznámka: Vplyv zdrojov Istio na sieťovú prevádzku je tu prezentovaný spôsobom, ktorý je ľahko pochopiteľný. Aby sme boli presní, rozhodnutie o tom, do ktorej inštancie poslať žiadosť, robí vyslanec v vstupnej bráne nakonfigurovanej v CRD.

Pomocou pravidiel cieľa môžeme nakonfigurovať vyrovnávanie záťaže tak, aby používalo konzistentné hodnoty hash a zabezpečilo, že rovnaká inštancia služby bude odpovedať rovnakému používateľovi. Nasledujúca konfigurácia vám to umožní (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 sa vygeneruje na základe obsahu hlavičky HTTP version.

Použite konfiguráciu pomocou nasledujúceho príkazu:

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

Teraz spustite príkaz uvedený nižšie a uistite sa, že pri zadávaní hlavičky získate správne súbory version:

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

Poznámka: Na pridanie rôznych hodnôt do hlavičky a testovanie výsledkov priamo v prehliadači môžete použiť toto rozšírenie do prehliadača Chrome (Alebo s tým pre Firefox - cca. preklad.).

Vo všeobecnosti má DestinationRules viac možností v oblasti vyrovnávania záťaže – podrobnosti nájdete v oficiálna dokumentácia.

Pred ďalším štúdiom VirtualService vymažte „zelenú verziu“ aplikácie a príslušné pravidlo smeru premávky spustením nasledujúcich príkazov:

$ 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

Zrkadlenie: Virtuálne služby v praxi

tieňovanie ("tienenie") alebo Zrkadlenie ("zrkadlenie") používa sa v prípadoch, keď chceme otestovať zmenu vo výrobe bez toho, aby sme ovplyvnili koncových používateľov: na tento účel duplikujeme („zrkadlíme“) požiadavky na druhú inštanciu, kde boli požadované zmeny vykonané, a sledujeme dôsledky. Jednoducho povedané, je to vtedy, keď váš kolega vyberie najkritickejší problém a požiada o stiahnutie vo forme takej obrovskej hrudy špiny, že ju nikto nemôže preskúmať.

Ak chcete otestovať tento scenár v akcii, vytvorte druhú inštanciu SA-Logic s chybami (buggy) spustením nasledujúceho príkazu:

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

A teraz poďme spustiť príkaz, aby sme sa uistili, že všetky inštancie s app=sa-logic Majú tiež štítky s príslušnými verziami:

$ 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

Služba sa-logic cieli na struky so štítkom app=sa-logic, takže všetky žiadosti budú rozdelené medzi všetky inštancie:

... ale chceme, aby sa požiadavky odosielali inštanciám verzie 1 a zrkadlili sa inštanciám verzie 2:

Dosiahneme to prostredníctvom VirtualService v kombinácii s DestinationRule, kde pravidlá určia podmnožiny a cesty VirtualService do konkrétnej podmnožiny.

Definovanie podmnožín v pravidlách destinácie

Podmnožiny (podmnožiny) sú určené nasledujúcou konfiguráciou (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

Hostiteľ (host) definuje, že toto pravidlo sa vzťahuje len na prípady, keď trasa smeruje k spoju sa-logic;
Tituly (name) podmnožiny sa používajú pri smerovaní na inštancie podmnožín;
Štítok (label) definuje páry kľúč – hodnota, ktoré sa inštancie musia zhodovať, aby sa stali súčasťou podmnožiny.

Použite konfiguráciu pomocou nasledujúceho príkazu:

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

Teraz, keď sú definované podmnožiny, môžeme pokračovať a nakonfigurovať VirtualService tak, aby aplikovala pravidlá na požiadavky na sa-logiku tak, aby:

Smerované do podmnožiny v1,
Zrkadlené do podmnožiny v2.

Nasledujúci manifest vám umožňuje dosiahnuť vaše plány (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

Tu nie je potrebné žiadne vysvetlenie, takže sa na to pozrime v praxi:

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

Pridajme záťaž zavolaním nasledujúceho príkazu:

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

Pozrime sa na výsledky v Grafane, kde môžete vidieť, že verzia s chybami (buggy) vedie k zlyhaniu ~ 60 % požiadaviek, ale žiadne z týchto zlyhaní neovplyvní koncových používateľov, keďže na ne odpovedá spustená služba.

Úspešné odpovede rôznych verzií služby sa-logic

Tu sme prvýkrát videli, ako sa VirtualService aplikuje na vyslancov našich služieb: kedy sa-web-app podáva žiadosť sa-logicprechádza cez postranný vyslanec, ktorý je cez VirtualService nakonfigurovaný tak, aby smeroval požiadavku do podmnožiny v1 a zrkadlil požiadavku na podmnožinu v2 služby sa-logic.

Viem, možno si už myslíte, že virtuálne služby sú jednoduché. V ďalšej časti to rozvedieme tým, že povieme, že sú tiež skutočne skvelé.

Zavedenie na Kanárske ostrovy

Canary Deployment je proces zavádzania novej verzie aplikácie pre malý počet používateľov. Používa sa na to, aby sa zabezpečilo, že pri vydaní nebudú žiadne problémy, a až potom, keď ste si už istí kvalitou (vydania), distribuujte ho ostatným používateľom.оväčšie publikum.

Na ukážku zavedenia kanárikov budeme pokračovať v práci s podskupinou buggy у sa-logic.

Nestrácajme čas maličkosťami a okamžite pošlime 20 % používateľov na verziu s chybami (to bude predstavovať náš kanárikový rollout) a zvyšných 80 % do bežnej služby. Ak to chcete urobiť, použite nasledujúcu virtuálnu službu (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 je hmotnosť (weight), ktorý určuje percento žiadostí, ktoré budú smerované príjemcovi alebo podskupine príjemcov.

Aktualizujme predchádzajúcu konfiguráciu VirtualService pre sa-logic s nasledujúcim príkazom:

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

... a hneď uvidíme, že niektoré požiadavky vedú k zlyhaniam:

$ 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 umožňujú zavádzanie kanárikov: V tomto prípade sme potenciálny vplyv problémov zúžili na 20 % používateľskej základne. úžasné! Teraz, v každom prípade, keď si nie sme istí svojím kódom (inými slovami - vždy...), môžeme použiť zrkadlenie a zavádzanie canary.

Časové limity a opakované pokusy

Chyby však nie vždy skončia v kóde. V zozname od "8 mylných predstáv o distribuovanej výpočtovej technike„Na prvom mieste je mylné presvedčenie, že „sieť je spoľahlivá“. V skutočnosti sieť nie spoľahlivé, a preto potrebujeme časové limity (časové limity) a pokusy (opakuje).

Pre demonštráciu budeme naďalej používať rovnakú problémovú verziu sa-logic (buggy), a budeme simulovať nespoľahlivosť siete s náhodnými poruchami.

Umožnite našej službe s chybami 1/3 šancu, že odpoveď bude trvať príliš dlho, 1/3 šancu skončiť s internou chybou servera a 1/3 šancu na úspešné vrátenie stránky.

Na zmiernenie dopadu takýchto problémov a zlepšenie života používateľov môžeme:

pridať časový limit, ak službe trvá odpoveď dlhšie ako 8 sekúnd,
ak požiadavka zlyhá, skúste to znova.

Na implementáciu použijeme nasledujúcu definíciu zdroja (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

Časový limit pre požiadavku je nastavený na 8 sekúnd;
Žiadosti sa opakujú 3-krát;
A každý pokus sa považuje za neúspešný, ak doba odozvy presiahne 3 sekundy.

Ide o optimalizáciu, pretože používateľ nebude musieť čakať viac ako 8 sekúnd a v prípade zlyhania urobíme tri nové pokusy na získanie odpovede, čím sa zvýši šanca na úspešnú odpoveď.

Použite aktualizovanú konfiguráciu pomocou nasledujúceho príkazu:

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

A skontrolujte v grafoch Grafana, že počet úspešných odpovedí sa zvýšil vyššie:

Vylepšenia v štatistikách úspešných odpovedí po pridaní časových limitov a opakovaní

Pred prechodom na ďalšiu časť (alebo skôr do ďalšej časti článku, pretože v tomto už nebudú žiadne praktické experimenty - cca preklad.), odstrániť sa-logic-buggy a VirtualService spustením nasledujúcich príkazov:

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

Vzory ističov a prepážok

Hovoríme o dvoch dôležitých vzoroch v architektúre mikroslužieb, ktoré vám umožňujú dosiahnuť samoobnovu (samoliečenie) služby.

Istič ("istič") používa sa na ukončenie požiadaviek prichádzajúcich do inštancie služby, ktorá sa považuje za nezdravú, a na jej obnovenie, zatiaľ čo požiadavky klientov sú presmerované na zdravé inštancie tejto služby (čo zvyšuje percento úspešných odpovedí). (Poznámka: Podrobnejší popis vzoru nájdete napr. tu.)

Prepážka ("oddiel") izoluje zlyhania služby od vplyvu na celý systém. Napríklad služba B je nefunkčná a iná služba (klient služby B) odošle požiadavku na službu B, čo spôsobí, že táto služba vyčerpá svoj fond vlákien a nebude schopná obslúžiť iné požiadavky (aj keď nepochádzajú zo služby B). (Poznámka: Podrobnejší popis vzoru nájdete napr. tu.)

Vynechám detaily implementácie týchto vzorov, pretože ich možno ľahko nájsť oficiálna dokumentácia, a tiež chcem naozaj ukázať autentifikáciu a autorizáciu, o ktorej sa bude diskutovať v ďalšej časti článku.

PS od prekladateľa

Prečítajte si aj na našom blogu:

"Späť na mikroslužby s Istio": časť 1 (úvod do hlavných funkcií), časť 3 (overenie a autorizácia);
«Conduit - ľahká servisná sieť pre Kubernetes»;
«Čo je to sieť služieb a prečo ju potrebujem [pre cloudovú aplikáciu s mikroslužbami]?".

Zdroj: hab.com

Späť k mikroslužbám s Istio. Časť 2