Zpět k mikroslužbám s Istio. Část 2

Poznámka. přel.: První část Tato série byla věnována představení schopností Istio a jejich demonstraci v akci. Nyní budeme hovořit o složitějších aspektech konfigurace a použití této sítě služeb, a zejména o jemně vyladěném směrování a správě síťového provozu.

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

řízení provozu

S Istio se v clusteru objevují nové možnosti, které poskytují:

• Dynamické směrování požadavků: zavádění kanárků, A/B testování;
• Vyvažování zátěže: jednoduché a konzistentní, založené na hashích;
• Zotavení po pádech: časové limity, opakování, jističe;
• Vkládání závad: zpoždění, zrušené požadavky atd.

Jak bude článek pokračovat, tyto schopnosti budou ilustrovány na příkladu vybrané aplikace a budou představeny nové koncepty. První takový koncept bude DestinationRules (tj. pravidla o příjemci provozu/požadavků - cca překlad), s jehož pomocí 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 vizuálně liší) a nejsme si 100% jisti, která z nich zlepší uživatelský zážitek. Proto spouštíme obě verze současně a shromažďujeme metriky.

Chcete-li nasadit druhou verzi frontendu, která je nutná pro demonstraci A/B testování, spusťte následující příkaz:

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

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

1. Obrázek je založen na jiném tagu - istio-green,
2. Lusky mají štítek version: green.

Protože obě nasazení mají štítek app: sa-frontend,požadavky směrované virtuální službou sa-external-services za službu sa-frontend, bude přesměrován na všechny jeho instance a zátěž bude distribuována prostřednictvím algoritmus round-robin, což povede k následující situaci:

Požadované soubory nebyly nalezeny

Tyto soubory nebyly nalezeny, protože jsou v různých verzích aplikace pojmenovány jinak. Přesvědčte 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, požadující jednu verzi statických souborů, může nástroj pro vyrovnávání zatížení odeslat do modulů, které mají jinou verzi, kde ze zřejmých důvodů takové soubory neexistují. Proto, aby aplikace fungovala, musíme nastavit omezení: “stejná verze aplikace, která obsluhovala index.html, by měla obsluhovat následné požadavky".

Dostaneme se tam s konzistentním vyvažováním zátěže na základě hash (Konzistentní hash Loadbalancing). V tomto případě požadavky od stejného klienta jsou odesílány do stejné backendové instance, pro kterou se používá předdefinovaná vlastnost – například HTTP hlavička. Implementováno pomocí DestinationRules.

Pravidla destinace

Po VirtualService odeslal požadavek na požadovanou službu, pomocí DestinationRules můžeme definovat zásady, které budou aplikovány na provoz určený pro instance této služby:

Řízení provozu se zdroji Istio

Poznámka: Vliv zdrojů Istio na síťový provoz je zde prezentován způsobem, který je snadno pochopitelný. Abychom byli přesní, rozhodnutí o tom, na kterou instanci odeslat požadavek, činí Envoy v Ingress Gateway nakonfigurované v CRD.

Pomocí pravidel cíle můžeme nakonfigurovat vyrovnávání zátěže tak, aby používala konzistentní hodnoty hash a zajistila, že stejná instance služby odpovídá stejnému uživateli. Následující konfigurace 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 bude generován na základě obsahu HTTP hlavičky version.

Aplikujte konfiguraci pomocí následujícího příkazu:

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

Nyní spusťte níže uvedený příkaz a ujistěte se, že při zadávání záhlaví získáte správné soubory version:

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

Poznámka: Chcete-li přidat různé hodnoty do záhlaví a otestovat výsledky přímo v prohlížeči, můžete použít toto rozšíření do Chromu (nebo s tím pro Firefox - cca. překlad.).

Obecně má DestinationRules více možností v oblasti vyvažování zátěže – podrobnosti najdete v oficiální dokumentace.

Než budeme dále studovat VirtualService, smažte „zelenou verzi“ aplikace a odpovídající pravidlo pro směr provozu spuštěním následujících příkazů:

$ 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

Zrcadlení: Virtuální služby v praxi

Stínování ("stínění") nebo Zrcadlení ("zrcadlení") používá se v případech, kdy chceme otestovat změnu ve výrobě, aniž bychom ovlivnili koncové uživatele: za tímto účelem duplikujeme („zrcadlíme“) požadavky do druhé instance, kde byly požadované změny provedeny, a podíváme se na důsledky. Jednoduše řečeno, to je, když váš kolega vybere nejkritičtější problém a podá žádost o stažení ve formě tak obrovské hroudy špíny, že to nikdo nemůže prověřit.

Chcete-li tento scénář otestovat v akci, vytvořte druhou instanci SA-Logic s chybami (buggy) spuštěním následujícího příkazu:

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

A nyní spusťte příkaz, abychom se ujistili, že všechny instance s app=sa-logic Mají také štítky s odpovídajícími verzemi:

$ 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 cílí na pody se štítkem app=sa-logic, takže všechny požadavky budou rozděleny mezi všechny instance:

... ale chceme, aby byly požadavky odesílány do instancí v1 a zrcadleny do instancí v2:

Toho dosáhneme pomocí VirtualService v kombinaci s DestinationRule, kde pravidla určí podmnožiny a cesty VirtualService do konkrétní podmnožiny.

Definování podmnožin v pravidlech cíle

Podmnožiny (podmnožiny) jsou určeny následující konfigurací (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. Hostitel (host) definuje, že toto pravidlo platí pouze pro případy, kdy trasa směřuje ke službě sa-logic;
2. Tituly (name) podmnožiny se používají při směrování do instancí podmnožin;
3. Štítek (label) definuje páry klíč–hodnota, které se instance musí shodovat, aby se staly součástí podmnožiny.

Aplikujte konfiguraci pomocí následujícího příkazu:

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

Nyní, když jsou definovány podmnožiny, můžeme pokračovat a nakonfigurovat VirtualService tak, aby aplikovala pravidla na požadavky na sa-logic tak, aby:

1. Směrováno do podmnožiny v1,
2. Zrcadleno do podmnožiny v2.

Následující manifest vám umožní dosáhnout vašich plánů (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

Zde není třeba žádné vysvětlení, takže se na to pojďme podívat v akci:

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

Přidejme zátěž voláním následujícího příkazu:

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

Podívejme se na výsledky v Grafaně, kde můžete vidět, že verze s chybami (buggy) vede k selhání u ~ 60 % požadavků, ale žádné z těchto selhání neovlivňuje koncové uživatele, protože na ně odpovídá běžící služba.

Úspěšné odpovědi různých verzí služby sa-logic

Zde jsme poprvé viděli, jak se VirtualService aplikuje na vyslance našich služeb: kdy sa-web-app podává žádost sa-logic, prochází postranním vozíkem Envoy, který je – prostřednictvím VirtualService – nakonfigurován tak, aby směroval požadavek do podmnožiny v1 a zrcadlil požadavek na podmnožinu v2 služby. sa-logic.

Vím, možná si už myslíte, že virtuální služby jsou jednoduché. V další části to rozvedeme tím, že řekneme, že jsou také opravdu skvělé.

Zavádění Canary

Canary Deployment je proces zavedení nové verze aplikace pro malý počet uživatelů. Používá se k tomu, aby se zajistilo, že při vydání nejsou žádné problémy, a teprve poté, již s jistotou v jeho kvalitě (vydání), jej distribuujte dalším uživatelům.оvětší publikum.

Abychom demonstrovali zavádění kanárků, budeme pokračovat v práci s podmnožinou buggy у sa-logic.

Neztrácejme čas maličkostmi a okamžitě pošleme 20 % uživatelů na verzi s chybami (to bude představovat náš kanárkový rollout) a zbývajících 80 % do normální služby. Chcete-li to provést, použijte následující virtuální 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 hmotnost (weight), který určuje procento požadavků, které budou směřovány příjemci nebo podmnožině příjemců.

Pojďme aktualizovat předchozí konfiguraci VirtualService pro sa-logic s následujícím příkazem:

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

... a okamžitě uvidíme, že některé požadavky vedou k selhání:

$ 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ádění kanárků: V tomto případě jsme zúžili potenciální dopad problémů na 20 % uživatelské základny. Báječné! Nyní, v každém případě, kdy si nejsme jisti svým kódem (jinými slovy - vždy...), můžeme použít zrcadlení a zavádění canary.

Časové limity a opakování

Chyby ale ne vždy skončí v kódu. V seznamu od "8 Mylné představy o distribuovaném zpracování dat"Na prvním místě je mylné přesvědčení, že "síť je spolehlivá." Ve skutečnosti síť ne spolehlivé, a z tohoto důvodu potřebujeme časové limity (časové limity) a opakování (opakování).

Pro demonstraci budeme i nadále používat stejnou problémovou verzi sa-logic (buggy), a budeme simulovat nespolehlivost sítě s náhodnými poruchami.

Umožněte naší službě s chybami 1/3 šanci, že odpověď bude trvat příliš dlouho, 1/3 šanci, že skončí s interní chybou serveru, a 1/3 šanci, že stránku úspěšně vrátí.

Abychom zmírnili dopad takových problémů a zlepšili život uživatelům, můžeme:

1. přidat časový limit, pokud službě trvá odpověď déle než 8 sekund,
2. opakujte, pokud se požadavek nezdaří.

Pro implementaci použijeme následující definici zdroje (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. Časový limit pro požadavek je nastaven na 8 sekund;
2. Požadavky se opakují 3krát;
3. A každý pokus je považován za neúspěšný, pokud doba odezvy přesáhne 3 sekundy.

Jedná se o optimalizaci, protože uživatel nebude muset čekat déle než 8 sekund a v případě selhání provedeme tři nové pokusy o získání odpovědi, čímž se zvýší šance na úspěšnou odpověď.

Použijte aktualizovanou konfiguraci pomocí následujícího příkazu:

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

A zkontrolujte v grafech Grafana, že počet úspěšných odpovědí se zvýšil výše:

Vylepšení statistik úspěšných odpovědí po přidání časových limitů a opakování

Než přejdete k další části (nebo spíše do další části článku, protože v tom už nebudou žádné praktické pokusy - cca překlad.), smazat sa-logic-buggy a VirtualService spuštěním následujících příkazů:

$ 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 jističů a přepážek

Hovoříme o dvou důležitých vzorech v architektuře mikroslužeb, které vám umožňují dosáhnout samoobnovy (samoléčení) služeb.

Jistič ("jistič") používá se k ukončení požadavků přicházejících do instance služby, která je považována za nezdravou, ak jejímu obnovení, zatímco požadavky klientů jsou přesměrovány na zdravé instance této služby (což zvyšuje procento úspěšných odpovědí). (Pozn.: Podrobnější popis vzoru naleznete např. zde.)

Přepážka ("rozdělit") izoluje selhání služby od vlivu na celý systém. Například služba B je poškozená a jiná služba (klient služby B) odešle požadavek na službu B, což způsobí, že vyčerpá svůj fond vláken a nebude moci obsluhovat další požadavky (i když nepocházejí ze služby B). (Pozn.: Podrobnější popis vzoru naleznete např. zde.)

Vynechám detaily implementace těchto vzorů, protože je lze snadno najít oficiální dokumentace, a také chci opravdu ukázat autentizaci a autorizaci, o kterých bude řeč v další části článku.

PS od překladatele

Přečtěte si také na našem blogu:

• "Zpět na mikroslužby s Istio": část 1 (úvod do hlavních funkcí), část 3 (ověření a autorizace);
• «Conduit – lehká servisní síť pro Kubernetes";
• «Co je to síť služeb a proč ji potřebuji [pro cloudovou aplikaci s mikroslužbami]?".

Zdroj: www.habr.com