Tillbaka till mikrotjänster med Istio. Del 2

Obs. övers.: Den första delen av denna cykel var tillägnad att bekanta sig med Istios funktioner och visa dem i praktiken. Nu kommer vi att diskutera mer komplexa aspekter av konfiguration och användning av detta service mesh, specifikt om fininställd ruttning och nätverkstrafikhantering.

Vi påminner också om att artikeln använder konfigurationer (manifester för Kubernetes och Istio) från repot istio-mastery.

Trafikhantering

Med Istio i klustret finns nya möjligheter som möjliggör:

• Dynamisk ruttning av förfrågningar: kanariefåglar, A/B-testning;
• Lastbalansering: enkel och konsekvent, baserad på hash;
• Återställning efter krascher: tidsgränser, återförsök, circuit breakers;
• Introduktion av fel: fördröjningar, avbrutna förfrågningar osv.

I resten av artikeln kommer dessa funktioner att visas med ett valt program och samtidigt presentera nya koncept. Det första sådana konceptet är DestinationRules (dvs. regler för trafik-/förfrågningsmottagning — anm. övers.), som vi använder för att aktivera A/B-testning.

A/B-testning:  DestinationRules i praktiken

A/B-testning används i fall där det finns två versioner av en applikation (de skiljer sig vanligtvis visuellt) och vi inte är 100% säkra på vilken som förbättrar användarinteraktionen. Därför kör vi båda versionerna samtidigt och samlar in mätvärden.

För att distribuera den andra versionen av frontend, som behövs för att demonstrera A/B-testning, kör följande kommando:

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

Manifestet för deploymenten för den "gröna versionen" skiljer sig på två ställen:

1. Images är baserad på en annan tagg — istio-green,
2. Pods har en etikett version: green.

Eftersom båda deploymenterna har etiketten app: sa-frontend, kommer förfrågningar som dirigeras av den virtuella tjänsten sa-external-services till tjänsten sa-frontend, att omdirigeras till alla dess instanser och belastningen kommer att fördelas med hjälp av round-robin-algoritmen, vilket leder till följande situation:

Begärda filer hittades inte

Dessa filer hittades inte eftersom de har olika namn i de olika versionerna av applikationen. Låt oss se till detta:

$ 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

Detta innebär att index.html, som begär en version av statiska filer, kan skickas av lastbalanseraren till pods som har en annan version, där dessa filer av uppenbara skäl inte finns. Därför behöver vi införa en begränsning för att applikationen ska fungera: "samma version av applikationen som levererade index.html måste även hantera följande förfrågningar».

Vi kommer att uppnå vårt mål med hjälp av konsekvent lastbalansering baserat på hash (Consistent Hash Loadbalancing). I detta fall skickas förfrågningar från en och samma klient till samma backendinstans, vilket används genom en fördefinierad egenskap — till exempel en HTTP-header. Implementeras med hjälp av  DestinationRules.

DestinationRules

Efter att VirtualService har dirigerat förfrågan till rätt tjänst, kan vi med hjälp av DestinationRules definiera policyer som kommer att tillämpas på trafiken som riktas till instanser av denna tjänst:

Trafikhantering med Istio-resurser

Anmärkning: Påverkan av Istio-resurser på nätverkstrafik presenteras här i ett förenklat format för att underlätta förståelsen. För att vara exakt görs beslutet om vilken instans en förfrågan ska skickas till av Envoy i Ingress Gateway, som är konfigurerad i CRD.

Med hjälp av Destination Rules kan vi konfigurera lastbalansering så att konsekventa hashvärden används och svar från samma tjänsteinstans garanteras till samma användare. Följande konfiguration möjliggör detta (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 kommer att genereras baserat på innehållet i HTTP-headern version.

Använd konfigurationen med följande kommando:

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

Och nu kan du köra kommandot nedan och se till att du får de rätta filerna när du anger headern version:

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

Anmärkning: För att lägga till olika värden i headern och testa resultaten direkt i webbläsaren kan du använda detta tillägg till Chrome (eller detta för Firefox — övers. anm..

Generellt har DestinationRules fler alternativ för lastbalansering — för mer information, vänligen fråga. den officiella dokumentationen.

Innan vi går djupare in på VirtualService, låt oss ta bort den "gröna versionen" av applikationen och motsvarande regel för trafikdirigering genom att köra följande kommandon:

$ kubectl delete -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions "sa-frontend-green" borttaget
$ kubectl delete -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io "sa-frontend" borttaget

Speglingspraktik: Virtual Services i praktiken

Skuggning ("skugga") eller Spegling ("speglad") tillämpas i situationer där vi vill testa en förändring i produktion utan att påverka slutanvändarna: för detta duplicerar vi ("speglas") förfrågningar till en andra instans där de nödvändiga ändringarna har gjorts, och ser på konsekvenserna. Enkelt uttryckt, det är när din kollega väljer den mest kritiska frågan och gör en pull request i form av en så stor klump smuts att ingen faktiskt kan ge den recension.

För att se detta scenario i aktion, skapa en andra instans av SA-Logic med buggar (buggig), genom att köra följande kommando:

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

Och nu kör vi kommandot för att säkerställa att alla instanser med app=sa-logic också har etiketter med motsvarande versioner:

$ kubectl get pods -l app=sa-logic --show-labels
NAMN                              KLAR   ETIKETTER
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

Tjänsten sa-logic är riktad mot pods med etiketten app=sa-logic, så alla begärningar kommer att fördelas mellan alla instanser:

… men vi vill att begärningarna ska riktas mot instanser med version v1 och speglas till instanser med version v2:

Vi kommer att uppnå detta genom VirtualService i kombination med DestinationRule, där reglerna kommer att definiera delmängder och rutter för VirtualService till den specifika delmängden.

Definition av delmängder i Destination Rules

Delmängder (delmängder) definieras av följande konfiguration (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. Värd (host) definierar att denna regel endast tillämpas när rutten går mot tjänsten sa-logic;
2. Namn (name) av delmängder används vid dirigering till instanser av delmängden;
3. Etikett (label) definierar nyckel-värde-par som instanser måste uppfylla för att bli en del av en delmängd.

Använd konfigurationen med följande kommando:

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

Nu när delmängderna är definierade kan vi gå vidare och konfigurera VirtualService för att tillämpa regler på förfrågningar till sa-logic så att de:

1. Riktas till delmängden v1,
2. Speglas till delmängden v2.

Den följande manifestationen möjliggör det önskade (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

Förklaringar behövs inte här, så låt oss bara se det i aktion:

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

Vi lägger till belastning genom att köra följande kommando:

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

Vi ser på resultaten i Grafana, där vi kan se att versionen med buggar (buggig) orsakar fel för ~60 % av förfrågningarna, men inga av dessa fel påverkar de slutliga användarna, eftersom de får svar från den fungerande tjänsten.

Framgången i svaren från olika versioner av tjänsten sa-logic

Här såg vi för första gången hur VirtualService tillämpas på våra tjänsters Envoy: när sa-web-app gör en förfrågning till sa-logic, går den genom sidecar Envoy, som – genom VirtualService – är konfigurerad för att rikta förfrågningen till delmängden v1 och spegla förfrågningen till delmängden v2 av tjänsten sa-logic.

Jag vet: du har redan tänkt att Virtual Services är enkla. I nästa avsnitt kommer vi att bredda denna åsikt genom att visa att de också är verkligt fantastiska.

Kanarieutdelningar

Canary Deployment är processen att rulla ut en ny version av applikationen till ett litet antal användare. Den används för att säkerställa att det inte finns några problem i releasen och först efter att man är säker på tillräcklig kvalitet i den (releasen) sprider den till enbästa resultatet (subjektiv åsikt).större publik.

För att demonstrera kanarieutdelningar fortsätter vi att arbeta med delmängden buggig för sa-logic.

Vi ska inte snåla och skickar direkt 20 % av användarna till versionen med buggar (den kommer att representera vår kanarieutdelning), medan de återstående 80 % går till den normala tjänsten. För detta tillämpar vi följande 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 — detta är vikten (vikt), som bestämmer procentandelen av förfrågningar som kommer att dirigeras till mottagaren eller delmängden av mottagaren.

Låt oss uppdatera den tidigare konfigurationen av VirtualService med sa-logic följande kommando:

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

… och vi ser omedelbart att en del av förfrågningarna misslyckas:

$ 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 aktiverar kanariefördelningar: i det här fallet har vi minskat de potentiella konsekvenserna av problem till 20 % av användarbasen. Utmärkt! Nu, varje gång vi är osäkra på vår kod (med andra ord — alltid …), kan vi använda spegling och kanariefördelningar.

Tidsgränser och försök på nytt

Men buggar finns inte alltid i koden. På listan över "8 myter inom distribuerade beräkningar" ligger den felaktiga uppfattningen att "nätverket är pålitligt" högst upp. I själva verket är nätverket inte pålitligt, och av den anledning behöver vi tidsgränser (timeouts) och försök på nytt (retries).

För att demonstrera kommer vi att använda samma problemversion, sa-logic (buggig), och vi kommer att simulera opålitligheten i nätverket med slumpmässiga fel.

Låt vår buggy service ha 1/3 chans till en för lång svarstid, 1/3 till att avslutas med ett felmeddelande Internal Server Error och 1/3 till att lyckas returnera sidan.

För att mildra konsekvenserna av sådana problem och förbättra användarupplevelsen kan vi:

1. lägga till en tidsgräns om tjänsten svarar längre än 8 sekunder,
2. försöka igen om en begäran misslyckas.

För implementeringen använder vi följande resursdefinition (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. Tidsgränsen för begäran är inställd på 8 sekunder;
2. Försök på nytt görs 3 gånger;
3. Och varje försök anses misslyckat om svarstiden överstiger 3 sekunder.

Så vi har uppnått en optimering, eftersom användaren inte behöver vänta längre än 8 sekunder och vi kommer att göra tre nya försök att få ett svar vid problem, vilket ökar chansen för ett lyckat svar.

Tillämpa den uppdaterade konfigurationen med följande kommando:

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

Och kontrollera i Grafana-diagrammen att antalet lyckade svar har ökat:

Förbättringar i statistiken över lyckade svar efter tillägg av tidsgränser och upprepade försök

Innan vi går vidare till nästa sektion (eller snarare till nästa del av artikeln, eftersom det inte kommer att finnas fler praktiska experiment i denna — anm. övers.), ta bort sa-logic-buggy och VirtualService genom att köra följande kommandon:

$ kubectl delete deployment sa-logic-buggy
deployment.extensions "sa-logic-buggy" borttagen
$ kubectl delete virtualservice sa-logic
virtualservice.networking.istio.io "sa-logic" borttagen

Mönster för Circuit Breaker och Bulkhead

Det handlar om två viktiga mönster inom mikrotjänstarkitektur som möjliggör självåterställning (self-healing) av tjänster.

Circuit Breaker ("automatiskt strömbrytare") används för att stoppa förfrågningar som skickas till en instans av en tjänst som anses vara ohälsosam, och för att återställa den medan kundens förfrågningar omdirigeras till friska instanser av denna tjänst (vilket ökar procenten av lyckade svar). (Anm. övers.: En mer detaljerad beskrivning av mönstret kan hittas, till exempel, här.)

Bulkhead ("skott") isolera misslyckanden i tjänster från att påverka hela systemet. Till exempel, tjänst B är trasig, och en annan tjänst (klienten till tjänst B) gör en begäran till tjänst B, vilket leder till att den förbrukar sin trådpool och inte kan betjäna andra förfrågningar (även om de inte rör tjänst B). (Anm. övers.: En mer detaljerad beskrivning av mönstret kan hittas, till exempel, här.)

Jag kommer att hoppa över detaljerna om implementeringen av dessa mönster, eftersom de är lätta att hitta i den officiella dokumentationen, och det känns också väldigt bra att visa autentisering och auktorisering, vilket kommer att diskuteras i nästa del av artikeln.

P.S. från översättaren

Läs även i vår blogg:

• «Tillbaka till mikrotjänster med Istio»: del 1 (introduktion till grundläggande funktioner), del 3 (autentisering och auktorisering);
• «Conduit — en lättviktsservice mesh för Kubernetes»;
• «Vad är service mesh och varför behöver jag det [för en molnapplikation med mikrotjänster]?».

Källa: habr.com