🥇Rudi kwenye huduma ndogo ukitumia Istio. Sehemu ya 2

Kumbuka. tafsiri.: sehemu ya kwanza Mfululizo huu ulijitolea kutambulisha uwezo wa Istio na kuwaonyesha kwa vitendo. Sasa tutazungumza juu ya mambo magumu zaidi ya usanidi na utumiaji wa matundu ya huduma hii, na haswa, juu ya uelekezaji mzuri na usimamizi wa trafiki wa mtandao.

Pia tunakukumbusha kuwa kifungu kinatumia usanidi (dhahiri za Kubernetes na Istio) kutoka kwa hazina. istio-umahiri.

Usimamizi wa Trafiki

Na Istio, uwezo mpya huonekana kwenye nguzo ili kutoa:

Uelekezaji wa maombi mahiri: utoaji wa canary, upimaji wa A/B;
Kusawazisha mzigo: rahisi na thabiti, kulingana na hashes;
Kupona baada ya kuanguka: muda, majaribio tena, wavunja mzunguko;
Kuingiza makosa: ucheleweshaji, maombi yaliyoacha, nk.

Wakati kifungu kinaendelea, uwezo huu utaonyeshwa kwa kutumia programu iliyochaguliwa kama mfano na dhana mpya zitaanzishwa njiani. Dhana kama hiyo ya kwanza itakuwa DestinationRules (yaani sheria kuhusu mpokeaji wa trafiki/maombi - takriban. transl.), kwa msaada ambao tunawasha upimaji wa A/B.

Jaribio la A/B: Kanuni za Marudio kwa vitendo

Jaribio la A/B hutumika katika hali ambapo kuna matoleo mawili ya programu (kawaida ni tofauti kimwonekano) na hatuna uhakika 100% ni ipi itaboresha matumizi ya mtumiaji. Kwa hivyo, tunaendesha matoleo yote mawili kwa wakati mmoja na kukusanya vipimo.

Ili kupeleka toleo la pili la sehemu ya mbele, inayohitajika kwa ajili ya kuonyesha majaribio ya A/B, endesha amri ifuatayo:

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

Faili ya uwasilishaji ya toleo la kijani inatofautiana katika sehemu mbili:

Picha inategemea lebo tofauti - istio-green,
Maganda yana lebo version: green.

Kwa kuwa upelekaji wote una lebo app: sa-frontend,maombi yanayoendeshwa na huduma pepe sa-external-services kwa huduma sa-frontend, itaelekezwa kwa matukio yake yote na mzigo utasambazwa kupitia algorithm ya mzunguko-robin, ambayo itasababisha hali ifuatayo:

Faili zilizoombwa hazikupatikana

Faili hizi hazikupatikana kwa sababu zimepewa majina tofauti katika matoleo tofauti ya programu. Hebu tuhakikishe hili:

$ 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

Hii ina maana kwamba index.html, kuomba toleo moja la faili za tuli, zinaweza kutumwa na usawazishaji wa mzigo kwenye maganda ambayo yana toleo tofauti, ambapo, kwa sababu za wazi, faili hizo hazipo. Kwa hivyo, ili maombi yafanye kazi, tunahitaji kuweka kizuizi: "toleo lile lile la programu ambayo ilitumikia index.html inapaswa kutoa maombi yanayofuata'.

Tutafika huko tukiwa na usawazishaji thabiti wa upakiaji wa msingi wa heshi (Usawazishaji wa Hash thabiti). Katika kesi hii maombi kutoka kwa mteja sawa hutumwa kwa mfano sawa wa nyuma, ambayo mali iliyotanguliwa hutumiwa - kwa mfano, kichwa cha HTTP. Inatekelezwa kwa kutumia DestinationRules.

DestinationRules

Baada Huduma ya Virtual tulituma ombi kwa huduma inayotaka, kwa kutumia DestinationRules tunaweza kufafanua sera ambazo zitatumika kwa trafiki inayolengwa kwa matukio ya huduma hii:

Usimamizi wa trafiki na rasilimali za Istio

Kumbuka: Athari za rasilimali za Istio kwenye trafiki ya mtandao zinawasilishwa hapa kwa njia ambayo ni rahisi kuelewa. Ili kuwa sahihi, uamuzi juu ya tukio la kutuma ombi hufanywa na Mjumbe katika Njia ya Kuingia iliyosanidiwa katika CRD.

Kwa Sheria za Lengwa, tunaweza kusanidi kusawazisha upakiaji ili kutumia heshi thabiti na kuhakikisha kuwa mfano wa huduma sawa unajibu mtumiaji sawa. Usanidi ufuatao hukuruhusu kufanikisha hili (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 - heshi itatolewa kulingana na yaliyomo kwenye kichwa cha HTTP version.

Tumia usanidi kwa amri ifuatayo:

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

Sasa endesha amri hapa chini na uhakikishe kupata faili zinazofaa unapotaja kichwa version:

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

Kumbuka: Ili kuongeza maadili tofauti kwenye kichwa na kujaribu matokeo moja kwa moja kwenye kivinjari, unaweza kutumia kiendelezi hiki kwa Chrome (Au na hii kwa Firefox - takriban. tafsiri.).

Kwa ujumla, DestinationRules ina uwezo zaidi katika eneo la kusawazisha mzigo - angalia maelezo ndani nyaraka rasmi.

Kabla ya kusoma Huduma ya Virtual zaidi, hebu tuondoe "toleo la kijani" la programu na sheria inayolingana ya mwelekeo wa trafiki kwa kutekeleza amri zifuatazo:

$ 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

Kuakisi: Huduma Pembeni Katika Mazoezi

Kivuli ("kingao") au Kuakisi ("kuakisi") hutumika katika hali ambapo tunataka kujaribu mabadiliko katika toleo la umma bila kuathiri watumiaji wa mwisho: ili kufanya hivyo, tunarudia maombi ("kioo") kwa tukio la pili ambapo mabadiliko yanayotarajiwa yamefanywa, na kuangalia matokeo. Kuweka tu, hii ni wakati mwenzako anachagua suala muhimu zaidi na kufanya ombi la kuvuta kwa namna ya donge kubwa la uchafu ambalo hakuna mtu anayeweza kulihakiki.

Ili kujaribu hali hii kwa vitendo, wacha tuunde mfano wa pili wa SA-Logic na mende (buggy) kwa kuendesha amri ifuatayo:

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

Na sasa hebu tuendeshe amri ili kuhakikisha kuwa matukio yote na app=sa-logic Pia zina lebo zilizo na matoleo yanayolingana:

$ 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

Huduma sa-logic inalenga maganda yenye lebo app=sa-logic, kwa hivyo maombi yote yatasambazwa kati ya matukio yote:

... lakini tunataka maombi yatumwe kwa matukio ya v1 na kuakisiwa kwa matukio ya v2:

Tutafanikisha hili kupitia VirtualService pamoja na DestinationRule, ambapo sheria zitaamua seti ndogo na njia za VirtualService hadi kitengo maalum.

Kufafanua Vijisehemu katika Kanuni za Lengwa

Seti ndogo (seti ndogo) imedhamiriwa na usanidi ufuatao (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

Mwenyeji (host) inafafanua kuwa sheria hii inatumika tu kwa kesi wakati njia inakwenda kuelekea huduma sa-logic;
Majina (name) sehemu ndogo hutumiwa wakati wa kuelekeza kwa hali ndogo;
Lebo (label) inafafanua jozi za thamani-msingi ambazo ni lazima zilingane ili kuwa sehemu ya kikundi kidogo.

Tumia usanidi kwa amri ifuatayo:

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

Kwa vile vijisehemu vidogo vimefafanuliwa, tunaweza kuendelea na kusanidi Huduma ya Virtual ili kutumia sheria kwa maombi ya sa-logic ili:

Imeelekezwa kwa kikundi kidogo v1,
Imeakisiwa kwa kikundi kidogo v2.

Ilani ifuatayo inakuruhusu kufanikisha mipango yako (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

Hakuna maelezo yanayohitajika hapa, kwa hivyo wacha tuyaone katika vitendo:

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

Wacha tuongeze mzigo kwa kupiga amri ifuatayo:

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

Wacha tuangalie matokeo huko Grafana, ambapo unaweza kuona kwamba toleo na mende (buggy) husababisha kutofaulu kwa ~ 60% ya maombi, lakini hakuna hitilafu zozote kati ya hizi zinazoathiri watumiaji wa mwisho wanapojibiwa na huduma inayoendeshwa.

Majibu yenye ufanisi ya matoleo tofauti ya huduma ya sa-logic

Hapa tuliona kwa mara ya kwanza jinsi VirtualService inatumika kwa Wajumbe wa huduma zetu: lini sa-web-app hufanya ombi kwa sa-logic, inapitia Mjumbe wa kando, ambayo - kupitia VirtualService - imeundwa kuelekeza ombi kwa kitengo kidogo cha v1 na kuakisi ombi kwa kitengo kidogo cha v2 cha huduma. sa-logic.

Najua, unaweza tayari kufikiria kuwa Huduma za Mtandaoni ni rahisi. Katika sehemu inayofuata, tutapanua hilo kwa kusema kwamba wao pia ni wazuri sana.

Utoaji wa Canary

Usambazaji wa Canary ni mchakato wa kusambaza toleo jipya la programu kwa idadi ndogo ya watumiaji. Inatumiwa kuhakikisha kuwa hakuna matatizo katika kutolewa na tu baada ya hayo, tayari kuwa na ujasiri katika ubora wake (kutolewa), usambaze kwa watumiaji wengine.оwatazamaji wengi zaidi.

Ili kuonyesha uchapishaji wa canary, tutaendelea kufanya kazi na kikundi kidogo buggy у sa-logic.

Wacha tusipoteze wakati kwa vitapeli na tutume 20% ya watumiaji kwenye toleo na hitilafu mara moja (hii itawakilisha uchapishaji wetu wa canary), na 80% iliyobaki kwenye huduma ya kawaida. Ili kufanya hivyo, tumia VirtualService ifuatayo (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 ni uzito (weight), ambayo hubainisha asilimia ya maombi ambayo yataelekezwa kwa mpokeaji au kikundi kidogo cha mpokeaji.

Wacha tusasishe usanidi wa awali wa Huduma ya Virtual kwa sa-logic na amri ifuatayo:

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

... na tutaona mara moja kwamba baadhi ya maombi husababisha kushindwa:

$ 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 huwezesha uchapishaji wa canary: Katika hali hii, tumepunguza athari zinazowezekana za masuala hadi 20% ya watumiaji. Ajabu! Sasa, katika kila hali tunapokuwa hatuna uhakika na msimbo wetu (kwa maneno mengine - daima...), tunaweza kutumia utoaji wa kioo na canary.

Muda umeisha na majaribio tena

Lakini mende haziishii kwenye nambari kila wakati. Katika orodha kutoka "Dhana 8 Potofu kuhusu Kompyuta Iliyosambazwa"Kwanza ni imani potofu kwamba "mtandao unategemewa." Kwa ukweli mtandao hakuna kuaminika, na kwa sababu hii tunahitaji muda (muda umeisha) na kujaribu tena (inajaribu tena).

Kwa onyesho tutaendelea kutumia toleo lile lile la tatizo sa-logic (buggy), na tutaiga kutokuwa na uhakika wa mtandao na kushindwa kwa nasibu.

Ruhusu huduma yetu iliyo na hitilafu iwe na nafasi 1/3 ya kuchukua muda mrefu kujibu, nafasi 1/3 ya kuisha kwa Hitilafu ya Ndani ya Seva, na nafasi 1/3 ya kurudisha ukurasa kwa ufanisi.

Ili kupunguza athari za matatizo kama haya na kufanya maisha kuwa bora kwa watumiaji, tunaweza:

ongeza muda wa kuisha ikiwa huduma inachukua zaidi ya sekunde 8 kujibu,
jaribu tena ikiwa ombi halitafaulu.

Kwa utekelezaji, tutatumia ufafanuzi wa rasilimali ufuatao (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

Muda wa kuisha kwa ombi umewekwa kwa sekunde 8;
Maombi yanajaribiwa tena mara 3;
Na kila jaribio linachukuliwa kuwa halijafaulu ikiwa muda wa kujibu unazidi sekunde 3.

Huu ni uboreshaji kwa sababu mtumiaji hatalazimika kusubiri zaidi ya sekunde 8 na tutafanya majaribio matatu mapya ili kupata jibu iwapo kutatokea kushindwa, na hivyo kuongeza nafasi ya jibu lililofanikiwa.

Tumia usanidi uliosasishwa na amri ifuatayo:

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

Na angalia kwenye grafu za Grafana kwamba idadi ya majibu yaliyofaulu imeongezeka hapo juu:

Maboresho katika takwimu za majibu zilizofanikiwa baada ya kuongeza muda na majaribio tena

Kabla ya kuendelea na sehemu inayofuata (au tuseme, kwa sehemu inayofuata ya kifungu, kwa sababu katika hili hakutakuwa na majaribio zaidi ya vitendo - takriban. transl.), futa sa-logic-buggy na VirtualService kwa kuendesha amri zifuatazo:

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

Mvunjaji wa Mzunguko na Sampuli za Bulkhead

Tunazungumzia kuhusu mifumo miwili muhimu katika usanifu wa microservice ambayo inakuwezesha kufikia urejesho wa kujitegemea (kujiponya) huduma.

Mzunguko wa mzunguko ("mvunjaji wa mzunguko") hutumika kusitisha maombi yanayokuja kwa mfano wa huduma ambayo inachukuliwa kuwa mbaya na kuirejesha huku maombi ya mteja yakielekezwa kwenye hali nzuri za huduma hiyo (ambayo huongeza asilimia ya majibu yaliyofaulu). (Kumbuka: Maelezo ya kina zaidi ya muundo yanaweza kupatikana, kwa mfano, hapa.)

Kichwa cha kichwa ("kizigeu") hutenga kushindwa kwa huduma kutokana na kuathiri mfumo mzima. Kwa mfano, Huduma B imevunjwa na huduma nyingine (mteja wa Huduma B) inatuma ombi kwa Huduma B, na kuifanya kuzima mtandao wake na kushindwa kuhudumia maombi mengine (hata kama hayatoki kwenye Huduma B). (Kumbuka: Maelezo ya kina zaidi ya muundo yanaweza kupatikana, kwa mfano, hapa.)

Nitaacha maelezo ya utekelezaji wa mifumo hii kwa sababu ni rahisi kuipata nyaraka rasmi, na pia ninataka sana kuonyesha uthibitishaji na idhini, ambayo itajadiliwa katika sehemu inayofuata ya makala.

PS kutoka kwa mtafsiri

Soma pia kwenye blogi yetu:

"Rudi kwa huduma ndogo na Istio": Sehemu ya 1 (utangulizi wa sifa kuu), Sehemu ya 3 (Uthibitishaji na Uidhinishaji);
«Mfereji - mesh ya huduma nyepesi kwa Kubernetes";
«Mesh ya huduma ni nini na kwa nini ninaihitaji [kwa programu ya wingu iliyo na huduma ndogo]?'.

Chanzo: mapenzi.com

Rudi kwa huduma ndogo na Istio. Sehemu 2