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

Pozn. prekl.: Prvá časť Tento cyklus byl věnován seznámení s možnostmi Istio a jejich demonstraci v akci. Nyní se však budeme věnovat složitějším aspektům konfigurace a využívání této service mesh, konkrétně podrobného nastavení směrování a správy síťového provozu.

Také připomínáme, že v článku jsou použity konfigurace (manifesty pro Kubernetes a Istio) z úložiště. istio-mastery.

Správa prevádzky

S Istio se v clusteru objevují nové možnosti, které umožňují:

Dynamické směrování požadavků: kanárkové rollouty, A/B testování;
Vyvažování zátěže: jednoduché a konzistentní, založené na hashe;
Obnova po selhání: časové limity, opakování, circuit breakers;
Zavádění poruch: zpoždění, přerušení požadavků atd.

V průběhu článku budou tyto možnosti demonstrovány na příkladu vybrané aplikace a současně budou představeny nové koncepty. Prvním takovým konceptem budou DestinationRules (tj. pravidla pro příjemce provozu/požadavků — pozn. překl.), pomocí kterých aktivujeme A/B testování.

A/B testování: DestinationRules v praxi

A/B testování se používá v případech, kdy existují dvě verze aplikace (obvykle se liší vizuálně) a nejsme si jisti na 100%, která z nich zlepší uživatelskou interakci. Proto obě verze spuštíme současně a shromažďujeme metriky.

Pro nasazení druhé verze frontendové aplikace, potřebné pro demonstraci A/B testování, použijte následující příkaz:

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

Manifest deploymentu pro "zelenou verzi" se liší na dvou místech:

Obrázek je založen na jiném tagu — istio-green,
Pod mají label version: green.

Jelikož oba deploymenty mají label app: sa-frontend, požadavky směrovány virtuálním servisem sa-external-services na službu sa-frontend, budou přesměrovány na všechny její instance a zátěž se rozdělí prostřednictvím algoritmu round-robin, což povede k následující situaci:

Požadované soubory nebyly nalezeny

Tyto soubory nebyly nalezeny, protože se v různých verzích aplikace nazývají jinak. Ujistíme se 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, ktorý požaduje jednu verziu statických súborov, môže byť odoslaný vyvažovačom zaťaženia na pod, ktoré majú inú verziu, kde, z pochopiteľných dôvodov, takéto súbory neexistujú. Preto, aby aplikácia fungovala, musíme nastaviť obmedzenie: „rovnaká verzia aplikácie, ktorá vrátila index.html, musí obsluhovať aj ďalšie požiadavky».

Cieľ dosiahneme pomocou konzistentného vyvažovania zaťaženia na základe hashovania (Konzistentné vyvažovanie zaťaženia na základe hashovania). V tomto prípade požiadavky od jedného klienta sú zasielané na rovnaký backendový inštanc,na čo sa používa preddefinovaná vlastnosť – napríklad HTTP hlavička. Realizované pomocou DestinationRules.

DestinationRules

Po tom, čo VirtualService nasmeroval požiadavku na potrebnú službu, pomocou DestinationRules môžeme definovať politiky, ktoré budú aplikované na prevádzku určenú inštanciám tejto služby:

Správa prevádzky s prostriedkami Istio

Poznámka: Vplyv prostriedkov Istio na sieťovú prevádzku je tu predstavený v zjednodušenom na pochopenie forme. Presnejšie povedané, rozhodnutie, na ktorú inštanciu odoslať požiadavku, prijíma Envoy v Ingress Gateway, nastavenom v CRD.

S pomocou Destination Rules môžeme nastaviť vyvažovanie zaťaženia tak, aby sa používali konzistentné hashovanie a garantovali odpovede jednej a tej istej inštancie služby pre toho istého používateľa. Nasledujúca konfigurácia to umožňuje dosiahnuť (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 bude generovaný na základe obsahu HTTP hlavičky version.

Aplikujte konfiguráciu nasledujúcou príkazom:

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

Teraz spustite príkaz nižšie a uistite sa, že dostávate požadované súbory, keď nastavíte hlavičku version:

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

Poznámka: Aby ste mohli pridávať rôzne hodnoty do hlavičky a testovať výsledky priamo v prehliadači, môžete využiť tento doplnok do Chrome (alebo tento pre Firefox — pozn. prekl.).

V skutočnosti majú DestinationRules širšie možnosti v oblasti vyvažovania zaťaženia — podrobnosti sa informujte v oficiálnej dokumentácii.

Predtým, než sa hlbšie pustíme do štúdia VirtualService, odstránime „zelenú verziu“ aplikácie a príslušné pravidlo pre smerovanie prevádzky pomocou 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: Virtual Services v praxi

Priame zrkadlenie („ekranovanie“) alebo Zrkadlenie („zrkadlenie“) sa aplikuje v prípadoch, keď chceme otestovať zmenu v produkcii bez ovplyvnenia koncových používateľov: na to duplikujeme („zrkadlíme“) požiadavky na druhý inštanciu, kde sa uskutočnili potrebné zmeny, a sledujeme dôsledky. Jednoducho povedané, ide o to, keď váš(á) kolega vyberie najkritickejší problém a urobí pull request vo forme takého obrovského balíka zmien, že nikto v skutočnosti nemôže vykonať jeho revíziu.

Aby sme vyskúšali tento scenár v akcii, vytvoríme druhú inštanciu SA-Logic s chybami (chybová), použijeme nasledujúci príkaz:

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

A teraz vykonáme príkaz, aby sme sa uistili, že všetky inštancie s app=sa-logic majú aj š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 je zameraný na pod’y s štítkom app=sa-logic, preto všetky požiadavky budú rozdelené medzi všetky inštancie:

… ale chceme, aby boli požiadavky smerované na inštancie s verziou v1 a zrkadlené na inštancie s verziou v2:

Toto dosiahneme pomocou VirtualService v kombinácii s DestinationRule, kde pravidlá definujú podmnožiny a trasy VirtualService k konkrétnemu podmnožiu.

Definícia podmnožín v Destination Rules

Podmnožiny (podmnožiny) sú definované 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

Host (host) určuje, že toto pravidlo sa aplikuje iba v prípadoch, keď je smerovanie do služieb sa-logic;
Názvy (name) podmnožín sa používajú pri smerovaní na inštancie podmnožiny;
Štítok (label) určuje páry kľúč-hodnota, ktorým musia inštancie vyhovieť, aby sa stali súčasťou podmnožiny.

Aplikujte konfiguráciu nasledujúcou príkazom:

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

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

boli smerované na podmnožinu v1,
boli zrkadlené na podmnožinu v2.

Nasledujúci manifes umožňuje dosiahnuť zamýšľané (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 sú potrebné žiadne vysvetlenia, tak sa pozrime na to v akcii:

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

Pridáme záťaž vyvolaním nasledujúceho príkazu:

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

Pozrieme sa na výsledky v Grafana, kde môžeme vidieť, že verzia s chybami (chybová) spôsobuje zlyhanie pre ~60 % požiadaviek, ale žiadne z týchto zlyhaní sa netýka koncových používateľov, pretože odpovedá fungujúca služba.

Úspešnosť odpovedí rôznych verzií služby sa-logic

Tu sme prvýkrát videli, ako sa VirtualService aplikuje na Envoyov našich služieb: keď sa-web-app vykoná požiadavku na sa-logic, prechádza cez sidecar Envoy, ktorý — prostredníctvom VirtualService — je nastavený na smerovanie požiadavky na podmnožinu v1 a zrkadlenie požiadavky na podmnožinu v2 služby. sa-logic.

Vieme: už ste si pomysleli, že Virtual Services sú jednoduché. V nasledujúcej časti rozšírime tento názor tým, že sú naozaj skvelé.

Kanárske nasadenia

Canary Deployment — proces zavádzania novej verzie aplikácie pre malé množstvo používateľov. Používa sa, aby sa uistilo, že v vydaní nie sú problémy, a až po tom, ako sme si istí dostatočnou kvalitou (vydania), sa rozšíri na väčšie publikum.oPre demonštráciu kanárkových vydaní budeme pokračovať v práci s podmnožinou

Nebudeme šetriť a rovno pošleme 20 % používateľov na verziu s chybami (tá bude predstavovať naše kanárkové vydanie) a zostávajúcich 80 % na normálnu službu. Na to aplikujeme nasledujúci VirtualService ( chybová u sa-logic.

sa-logic-subsets-canary-vs.yamlsa-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 — to je váha (váha), ktorá určuje percento požiadaviek, ktoré budú smerované na prijímateľa alebo podmnožinu prijímateľa.

Aktualizujeme predchádzajúcu konfiguráciu VirtualService pomocou sa-logic nasledujúceho príkazu:

$ 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 časť požiadaviek vedie k chybám:

$ 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 aktivujú kanárske výpady: v tomto prípade sme zúžili potenciálne následky problémov na 20 % používateľskej bázy. Výborne! Teraz, vždy keď si nie sme istí svojím kódom (inými slovami — vždy…), môžeme použiť zrkadlenie a kanárske výpady.

Časové obmedzenia a pokusy o opakovanie

Ale nie vždy sú chyby v kóde. V zozname "8 mýtov v distribuovaných výpočtoch" je na prvom mieste mylný názor, že "sieť je spoľahlivá". V skutočnosti je sieť nie spoľahlivá a preto potrebujeme časové obmedzenia (timeouts) a pokusy o opakovanie (retries).

Pre demonštráciu budeme naďalej používať tú istú verziu problému sa-logic (chybová), a nespoľahlivosť siete budeme simulovať náhodnými chybami.

Nech má náš chybujúci servis 1/3 šancu na príliš dlhú odpoveď, 1/3 na skončenie s chybou Internal Server Error a 1/3 na úspešné poskytnutie stránky.

Aby sme zmiernili následky takýchto problémov a spravili život používateľov lepším, môžeme:

pridať časové obmedzenie, ak servis odpovedá dlhšie ako 8 sekúnd,
opakovane požiadať, ak dôjde k chybe požiadavky.

Na realizáciu využijeme takéto definovanie prostriedku (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é obmedzenie pre požiadavku je nastavené na 8 sekúnd;
Odpovede požiadaviek sa opakujú 3 krát;
A každý pokus sa považuje za neúspešný, ak doba odozvy presiahne 3 sekundy.

Takto sme dosiahli optimalizáciu, pretože používateľ nebude musieť čakať viac ako 8 sekúnd a v prípade zlyhania podnikneme tri nové pokusy o získanie odpovede, čím zvýšime pravdepodobnosť úspešnej odpovede.

Použite aktualizovanú konfiguráciu nasledujúcou príkazom:

$ 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í vzrástol nad:

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

Predtým, ako prejdeme na ďalšiu sekciu (a presnejšie — už na ďalšiu časť článku, pretože v tejto praktických experimentov viac nebude — pozn. prekl.), odstráňte sa-logic-buggy a VirtualService pomocou 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 Circuit Breaker a Bulkhead

Hovorí sa o dvoch dôležitých vzoroch v mikroslužbovej architektúre, ktoré umožňujú dosiahnuť samostatné obnovenie (self-healing) služieb.

Circuit Breaker („automatický vypínač“) sa používa na zastavenie požiadaviek prichádzajúcich na inštanciu služby, ktorá sa považuje za nezdravú, a jej obnovenie, kým sú požiadavky klientov presmerované na zdravé inštancie tejto služby (čo zvyšuje percento úspešných odpovedí). (Pozn. prekl.: Podrobnejšie opísanie vzoru nájdete napríklad, tu.)

Bulkhead („prehrádka“) izoluje zlyhania v službách od ovplyvnenia celého systému. Napríklad, služba B je poškodená a iná služba (klient služby B) posiela požiadavku na službu B, čím vyčerpáva svoj bazén vlákien a nebude schopná spracovávať iné požiadavky (aj keď sa netýkajú služby B). (Pozn. prekl.: Podrobnejšie opísanie vzoru nájdete napríklad, tu.)

Podrobnosti o implementácii týchto vzorov preskočím, pretože ich je ľahké nájsť v oficiálnej dokumentácii, a už mám veľmi túžbu ukázať autentifikáciu a autorizáciu, o čom bude reč v ďalšej časti článku.