Terug na mikrodienste met Istio. Deel 2

Let wel. vertaal.: Eerste deel hierdie siklus was gewy om vertroud te raak met die vermoëns van Istio en dit in aksie te demonstreer. Nou sal ons praat oor meer komplekse aspekte van die konfigurasie en gebruik van hierdie diensnetwerk, en veral oor fyn ingestelde roetering en netwerkverkeerbestuur.

Ons herinner u ook daaraan dat die artikel konfigurasies (manifeste vir Kubernetes en Istio) vanaf die bewaarplek gebruik istio-meesterskap.

verkeersbestuur

Met Istio word nuwe kenmerke by die groep gevoeg om te voorsien:

• Dinamiese versoekroetering: kanarie-uitrol, A/B-toetsing;
• Vrag balansering: eenvoudig en konsekwent, gebaseer op hashes;
• Herstel na val: timeouts, herprobasies, stroombrekers;
• Bekendstelling van foute: vertragings, onderbreking van versoeke, ens.

Soos die artikel voortgaan, sal hierdie kenmerke gedemonstreer word deur die geselekteerde toepassing as voorbeeld te gebruik, en nuwe konsepte sal langs die pad bekendgestel word. Die eerste so 'n konsep sal wees DestinationRules (d.w.s. reëls oor die ontvanger van verkeer / versoeke - ongeveer transl.), waarmee ons A / B-toets aktiveer.

A/B-toetsing: Bestemmingsreëls in die praktyk

A/B-toetse word gebruik wanneer daar twee weergawes van 'n toepassing is (gewoonlik verskil hulle visueel) en ons is nie 100% seker watter een die gebruikerservaring sal verbeter nie. Daarom stel ons beide weergawes gelyktydig bekend en versamel statistieke.

Voer die volgende opdrag uit om die tweede weergawe van die frontend wat benodig word vir die A/B-toetsdemo te ontplooi:

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

Die ontplooiingsmanifes vir die "groen weergawe" verskil op twee plekke:

1. Die prent is gebaseer op 'n ander merker − istio-green,
2. Peule het 'n etiket version: green.

Omdat beide ontplooiings die etiket het app: sa-frontend, versoeke wat deur die virtuele diens gestuur word sa-external-services vir diens sa-frontend, sal herlei word na al sy gevalle en die vrag sal versprei word deur round-robin algoritme, wat tot die volgende situasie sal lei:

Versoekte lêers nie gevind nie

Hierdie lêers is nie gevind nie as gevolg van die feit dat hulle in verskillende weergawes van die toepassing verskillend genoem word. Kom ons kyk daarna:

$ 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

Dit beteken dat index.htmlom een ​​weergawe van statiese lêers aan te vra, kan deur die lasbalanseerder gestuur word na peule wat 'n ander weergawe het, waar, om ooglopende redes, sulke lêers nie bestaan ​​nie. Daarom, om die toepassing te laat werk, moet ons 'n beperking plaas: "dieselfde weergawe van die toepassing wat index.html teruggestuur het, moet daaropvolgende versoeke bedien".

Ons sal ons doelwit bereik met hash-gebaseerde konsekwente lasbalansering. (Konsekwente Hash-lasbalansering)... In hierdie geval versoeke van dieselfde kliënt word na dieselfde backend-instansie gestuur, waarvoor 'n voorafbepaalde eienskap gebruik word - byvoorbeeld 'n HTTP-opskrif. Geïmplementeer met behulp van DestinationRules.

Bestemming Reëls

Na Virtuele diens het 'n versoek na die verlangde diens gestuur, met behulp van DestinationRules kan ons die beleide definieer wat van toepassing sal wees op verkeer wat bestem is vir gevalle van hierdie diens:

Verkeersbestuur met Istio-hulpbronne

Let daarop: Die impak van Istio-hulpbronne op netwerkverkeer word hier in 'n vereenvoudigde vorm aangebied vir begrip. Om presies te wees, die besluit oor watter instansie om die versoek te stuur, word geneem deur Gesant in die Ingress Gateway wat in CRD opgestel is.

Met Bestemmingsreëls kan ons lasbalansering opstel om konsekwente hashes te gebruik en te verseker dat dieselfde diensinstansie op dieselfde gebruiker reageer. Die volgende konfigurasie bereik dit (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 - die hash sal gegenereer word op grond van die inhoud van die HTTP-kop version.

Pas die konfigurasie toe met die volgende opdrag:

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

Voer nou die opdrag hieronder uit en maak seker dat jy die regte lêers kry wanneer jy die titel spesifiseer version:

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

Let daarop: Om verskillende waardes in die kopskrif by te voeg en die resultate direk in die blaaier te toets, kan u dit gebruik hierdie uitbreiding na Chrome (Of met hierdie vir Firefox - ongeveer. vertaal.).

Oor die algemeen het DestinationRules meer kenmerke op die gebied van vragbalansering - kyk na die besonderhede amptelike dokumentasie.

Voordat ons VirtualService verder verken, laat ons die "groen weergawe" van die toepassing en die ooreenstemmende reël vir die rigting van verkeer verwyder deur die volgende opdragte uit te voer:

$ 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

Mirroring: Virtuele dienste in die praktyk

oorskadu ("afskerming") of Mirroring ("spieël") word gebruik in gevalle waar ons 'n verandering in produksie wil toets sonder om eindgebruikers te beïnvloed: om dit te doen, dupliseer ons ("spieël") versoeke na 'n tweede instansie waar die nodige veranderinge aangebring word, en kyk na die gevolge. Eenvoudig gestel, dit is wanneer jou kollega die mees kritieke kwessie kies en 'n trekversoek in so 'n groot klomp vuiligheid rig dat niemand dit eintlik kan hersien nie.

Om hierdie scenario in aksie te toets, kom ons skep 'n tweede instansie van SA-Logic met foute (buggy) deur die volgende opdrag uit te voer:

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

En laat ons nou 'n opdrag uitvoer om seker te maak dat alle gevalle met app=sa-logic hulle het ook etikette met die ooreenstemmende weergawes:

$ 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

Service sa-logic teiken peule met 'n etiket app=sa-logic, dus sal alle versoeke onder alle gevalle versprei word:

... maar ons wil hê dat versoeke na v1-gevalle gestuur word en na v2-instansies weerspieël word:

Ons bereik dit deur 'n VirtualService in kombinasie met 'n DestinationRule, waar die reëls die subsets en roetes van die VirtualService na 'n spesifieke subset definieer.

Definieer substelle in Bestemmingsreëls

Subsets (subsets) gedefinieer deur die volgende konfigurasie (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. Gasheer (host) definieer dat hierdie reël slegs van toepassing is op gevalle waar die roete na die diens gaan sa-logic;
2. Name (name) substelle word gebruik wanneer roetering na subset gevalle;
3. Etiket (label) definieer die sleutel-waarde-pare wat instansies moet pas om deel van 'n subset te word.

Pas die konfigurasie toe met die volgende opdrag:

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

Noudat die substelle gedefinieer is, kan ons voortgaan en die VirtualService konfigureer om reëls toe te pas op versoeke na sa-logic sodat hulle:

1. Gestuur na 'n subset v1,
2. Gespieël na 'n subset v2.

Die volgende manifes laat jou toe om jou doelwitte te bereik (sa-logika-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

Geen verduideliking nodig hier nie, so kom ons sien dit net in aksie:

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

Kom ons voeg 'n las by deur die volgende opdrag te roep:

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

Kom ons kyk na die resultate in Grafana, waar jy kan sien dat die weergawe met foute (buggy) misluk vir ~60% van versoeke, maar nie een van hierdie mislukkings raak eindgebruikers nie, aangesien hulle deur 'n lopende diens beantwoord word.

Sukses van antwoorde van verskillende weergawes van die sa-logic-diens

Dit is waar ons die eerste keer gesien het hoe VirtualService toegepas word op ons diensgesante: wanneer sa-web-app versoek om sa-logic, gaan dit deur sidecar Envoy, wat - deur VirtualService - gekonfigureer is om die versoek na die v1 subset te stuur en die versoek na die v2 subset van die diens te weerspieël sa-logic.

Ek weet: jy het al tyd gehad om te dink dat virtuele dienste eenvoudig is. In die volgende afdeling sal ons hierdie mening uitbrei deur te sê dat hulle ook werklik wonderlik is.

Kanarie-uitrol

Kanarie-ontplooiing is die proses om 'n nuwe weergawe van 'n toepassing aan 'n klein aantal gebruikers te ontplooi. Dit word gebruik om seker te maak dat daar geen probleme in die vrystelling is nie, en eers daarna, reeds seker van die voldoende (vrystelling) kwaliteit daarvan, versprei dit naоgroter gehoor.

Om kanarie-ontplooiings te demonstreer, sal ons voortgaan met 'n subset buggy у sa-logic.

Kom ons mors nie tyd op kleinighede nie en stuur dadelik 20% van gebruikers na die weergawe met foute (dit sal ons kanarie-ontplooiing verteenwoordig), en die oorblywende 80% na 'n normale diens. Om dit te doen, pas die volgende VirtualService toe (sa-logika-subsets-kanarie-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 is die gewig (weight) wat die persentasie versoeke spesifiseer wat aan die ontvanger gerig sal word, of 'n subset van die ontvanger.

Dateer die vorige VirtualService-konfigurasie op vir sa-logic met die volgende opdrag:

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

... en ons sal dadelik sien dat sommige van die versoeke tot mislukkings lei:

$ 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 veroorsaak kanarie-ontplooiing: in hierdie geval het ons die potensiële impak van probleme tot 20% van die gebruikersbasis verminder. Wonderlik! Nou, in elke geval wanneer ons nie seker is oor ons kode nie (met ander woorde, altyd ...), kan ons spieël- en kanarie-ontplooiings gebruik.

Timeouts en herprobasies

Maar foute beland nie altyd in die kode nie. In die lys van8 wanopvattings in verspreide rekenaars” in die eerste plek is die verkeerde mening dat “die netwerk betroubaar is”. In werklikheid die netwerk geen betroubaar, en om hierdie rede het ons time-outs nodig (time-outs) en probeer weer (weer probeer).

Vir demonstrasie sal ons voortgaan om dieselfde probleemweergawe te gebruik sa-logic (buggy), en die onbetroubaarheid van die netwerk sal deur ewekansige mislukkings gesimuleer word.

Laat ons karretjiediens 'n 1/3 kans hê om te lank te reageer, 1/3 van eindig met 'n interne bedienerfout, en 1/3 om die bladsy suksesvol weer te gee.

Om die impak van hierdie kwessies te versag en die lewens van ons gebruikers te verbeter, kan ons:

1. voeg 'n uitteltyd by as die diens langer as 8 sekondes reageer,
2. probeer weer as die versoek misluk.

Vir implementering gebruik ons ​​die volgende hulpbrondefinisie (sa-logic-terry-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. Die uitteltyd vir die versoek is gestel op 8 sekondes;
2. Versoeke word 3 keer herprobeer;
3. En elke poging word as onsuksesvol beskou as die reaksietyd 3 sekondes oorskry.

Dit is 'n optimalisering omdat die gebruiker nie meer as 8 sekondes hoef te wag nie en ons sal drie nuwe pogings aanwend om 'n reaksie te kry in geval van mislukkings, wat die kans op 'n suksesvolle reaksie verhoog.

Pas die opgedateerde konfigurasie toe met die volgende opdrag:

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

En kyk in die Grafana-kaarte dat die aantal suksesvolle antwoorde verby is:

Verbeterings in suksesstatistieke na die byvoeging van time-outs en herproberings

Voordat u na die volgende afdeling gaan (meer presies, na die volgende deel van die artikel, want daar sal nie meer praktiese eksperimente in hierdie deel wees nie - ongeveer transl.), skrap sa-logic-buggy en VirtualService deur die volgende opdragte uit te voer:

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

Stroombreker en skottelpatrone

Ons praat van twee belangrike patrone in die mikrodiensargitektuur wat jou toelaat om selfherstel te bereik. (selfgenesend) dienste.

stroombreker ("stroombreker") word gebruik om te keer dat versoeke na 'n diensinstansie kom wat as ongesond beskou word en dit te herstel terwyl kliëntversoeke na gesonde gevalle van daardie diens herlei word (wat die sukseskoers verhoog). (Vertaalnota: 'n Meer gedetailleerde beskrywing van die patroon kan gevind word, bv. hier.)

afskorting ("partisie") isoleer mislukkings in dienste van die nederlaag van die hele stelsel. Byvoorbeeld, diens B is gebreek, en 'n ander diens ('n kliënt van diens B) rig 'n versoek aan diens B, wat veroorsaak dat dit sy draadpoel opgebruik en nie ander versoeke kan bedien nie (selfs al behoort hulle nie aan diens nie B). (Vertaalnota: 'n Meer gedetailleerde beskrywing van die patroon kan gevind word, bv. hier.)

Ek sal die implementeringsbesonderhede van hierdie patrone weglaat omdat dit maklik is om in te vind amptelike dokumentasie, en ek wil ook regtig stawing en magtiging wys, wat in die volgende deel van die artikel bespreek sal word.

PS van vertaler

Lees ook op ons blog:

• "Terug na mikrodienste met Istio": deel 1 (inleiding tot die hoofkenmerke), deel 3 (stawing en magtiging);
• «Conduit - liggewig diensmaas vir Kubernetes»;
• «Wat is 'n diensnetwerk en hoekom het ek dit nodig [vir 'n wolktoepassing met mikrodienste]?".

Bron: will.com