Itzuli mikrozerbitzuetara Istio-rekin. 2. zatia

Ohar. itzul.: Lehenengo zatian Serie hau Istioren gaitasunak aurkeztera eta ekintzan erakustera eskaini zen. Orain zerbitzu-sare honen konfigurazioari eta erabilerari buruzko alderdi konplexuagoei buruz hitz egingo dugu, eta bereziki, bideratze fin eta sareko trafikoaren kudeaketari buruz.

Halaber, gogorarazten dizugu artikuluak biltegiko konfigurazioak (Kubernetes eta Istiorako manifestuak) erabiltzen dituela. istio-maisu.

trafikoaren kudeaketa

Istio-rekin, klusterrean gaitasun berriak agertzen dira:

• Eskaeren bideratze dinamikoa: kanariar inplementazioak, A/B probak;
• Karga orekatzea: sinplea eta koherentea, hashetan oinarrituta;
• Erorketen ondoren suspertzea: denbora-muga, berriro saiakerak, etengailuak;
• Matxurak txertatzea: atzerapenak, eskaerak jaitsi, etab.

Artikuluak aurrera egin ahala, gaitasun hauek ilustratuko dira aukeratutako aplikazioa adibide gisa erabiliz eta bidean kontzeptu berriak sartuko dira. Horrelako lehenengo kontzeptua izango da DestinationRules (hau da, trafikoaren/eskaeren hartzaileari buruzko arauak - gutxi gorabehera itzul.), eta horren laguntzaz A/B testak aktibatzen ditugu.

A/B probak: DestinationRules praktikan

A/B probak aplikazio baten bi bertsio dauden kasuetan erabiltzen da (normalean bisualki desberdinak dira) eta ez gaude %100 ziur zeinek hobetuko duen erabiltzailearen esperientzia. Hori dela eta, bi bertsioak aldi berean exekutatzen ditugu eta neurketak biltzen ditugu.

A/B probak erakusteko beharrezkoa den frontend-aren bigarren bertsioa zabaltzeko, exekutatu komando hau:

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

Bertsio berdearen inplementazioaren manifestua bi lekutan desberdina da:

1. Irudia etiketa ezberdin batean oinarritzen da - istio-green,
2. Lekak etiketa bat dute version: green.

Bi inplementazioek etiketa bat dutenez app: sa-frontend,zerbitzu birtualek bideraturiko eskaerak sa-external-services zerbitzurako sa-frontend, bere instantzia guztietara birbideratuko da eta karga bidez banatuko da round-robin algoritmoa, eta horrek egoera hau ekarriko du:

Ez dira eskatutako fitxategiak aurkitu

Fitxategi hauek ez dira aurkitu aplikazioaren bertsio ezberdinetan izen ezberdina dutelako. Ziurta dezagun hau:

$ 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

Horrek esan nahi du index.html, fitxategi estatikoen bertsio bat eskatuz, karga-orekatzaileak bidal dezake bertsio ezberdina duten podetara, non, ageriko arrazoiengatik, fitxategi horiek existitzen ez diren. Horregatik, aplikazioak funtziona dezan, murrizketa bat ezarri behar dugu: "index.html zerbitzatzen zuen aplikazioaren bertsio berdinak ondorengo eskaerak bete beharko lituzke'.

Hash-en oinarritutako karga orekatzeko koherentearekin lortuko dugu (Hash Loadbalancing koherentea). Kasu honetan bezero bereko eskaerak backend instantzia berera bidaltzen dira, eta horretarako aurrez definitutako propietate bat erabiltzen da, adibidez, HTTP goiburua. DestinationRules erabiliz inplementatu da.

Helmuga-arauak

Ondoren Zerbitzu Birtuala eskaera bat bidali nahi dion zerbitzura, DestinationRules erabiliz zerbitzu honen kasuetarako zuzendutako trafikoari aplikatuko zaizkion politikak defini ditzakegu:

Trafikoa kudeatzea Istioko baliabideekin

Kontuan izan: Istio baliabideek sareko trafikoan duten eragina erraz ulertzeko moduan aurkezten da hemen. Zehazki, eskaera zein instantziari bidali behar dion erabakia Envoy-ek hartzen du CRDn konfiguratutako Ingress Gateway-n.

Destination Rules-ekin, karga-oreka konfiguratu dezakegu hash koherenteak erabiltzeko eta zerbitzu-instantzia berak erabiltzaile berari erantzuten diola ziurtatzeko. Honako konfigurazio honek hau lortzeko aukera ematen dizu (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-a sortuko da HTTP goiburuko edukietan oinarrituta version.

Aplikatu konfigurazioa komando honekin:

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

Orain exekutatu beheko komandoa eta ziurtatu goiburua zehazten duzunean fitxategi egokiak lortzen dituzula version:

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

Kontuan izan: Goiburuan balio desberdinak gehitzeko eta emaitzak zuzenean arakatzailean probatzeko, erabil dezakezu luzapen hau Chromera (Edo honekin Firefoxerako - gutxi gorabehera. itzul.).

Oro har, DestinationRules-ek gaitasun gehiago ditu karga orekatzeko alorrean - egiaztatu xehetasunak hemen dokumentazio ofiziala.

VirtualService gehiago aztertu aurretik, ezabatu ditzagun aplikazioaren "bertsio berdea" eta dagokion trafikoaren noranzkoaren araua komando hauek exekutatuz:

$ 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

Ispilua: Zerbitzu birtualak praktikan

itzal ("blindajea") edo Ispilua ("ispilu") Azken erabiltzaileei eragin gabe produkzio aldaketa bat probatu nahi dugun kasuetan erabiltzen da: horretarako, eskaerak ("ispilu") bikoiztu egiten ditugu nahi diren aldaketak egin diren bigarren instantzia batera, eta ondorioak aztertu. Besterik gabe, hau da zure lankideak gairik larriena hautatzen duenean eta tira-eskaera bat egiten duen zikinkeria handi baten moduan, inork ezin duela berrikusi.

Eszenatoki hau ekintzan probatzeko, sor dezagun SA-Logic-en bigarren instantzia akatsekin (buggy) komando hau exekutatuz:

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

Eta orain exekutatu dezagun komandoa instantzia guztiak direla ziurtatzeko app=sa-logic Gainera, dagozkien bertsioekin etiketak dituzte:

$ 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

Zerbitzua sa-logic etiketa batekin lekak ditu helburu app=sa-logic, beraz, eskaera guztiak instantzia guztien artean banatuko dira:

... baina eskaerak v1 instantzietara bidaltzea eta v2 instantzietara islatzea nahi dugu:

VirtualService-ren bidez lortuko dugu DestinationRule-rekin konbinatuta, non arauek zehaztuko baitituzte VirtualService-ren azpimultzoak eta ibilbideak azpimultzo jakin batera.

Destino-arauetan azpimultzoak definitzea

Azpimultzoak (azpimultzoak) honako konfigurazio honek zehazten ditu (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. Ostalaria (host) arau hau ibilbidea zerbitzura doan kasuetan soilik aplikatzen dela zehazten du sa-logic;
2. Izenburuak (name) azpimultzoak azpimultzoen instantzietara bideratzerakoan erabiltzen dira;
3. Etiketa (label) instantziek azpimultzoaren parte izateko bat etorri behar duten gako-balio bikoteak definitzen ditu.

Aplikatu konfigurazioa komando honekin:

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

Orain azpimultzoak definitu direnean, Zerbitzu Birtuala aurrera egin eta konfiguratu dezakegu sa-logiko eskaerei arauak aplikatzeko, horrela hauek:

1. Azpimultzo batera bideratua v1,
2. Azpimultzo batean ispilu v2.

Ondoko manifestuak zure asmoak lortzeko aukera ematen dizu (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

Ez da azalpenik behar hemen, beraz, ikus dezagun ekintza:

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

Gehi dezagun karga komando honi deituz:

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

Ikus ditzagun Grafanako emaitzak, non ikus dezakezun akatsak dituen bertsioa (buggy) eskaeren %60an huts egiten du, baina hutsegite horietako batek ere ez du eragiten azken erabiltzaileei, martxan dagoen zerbitzu batek erantzuten baitiete.

Sa-logic zerbitzuaren bertsio ezberdinen erantzun arrakastatsuak

Hemen ikusi genuen lehenik Zerbitzu Birtuala nola aplikatzen den gure zerbitzuen Mandatariei: noiz sa-web-app eskaera egiten dio sa-logic, sidecar Envoy-etik igarotzen da, zeina - VirtualService bidez - eskaera v1 azpimultzora bideratzeko eta eskaera zerbitzuaren v2 azpimultzora islatzeko konfiguratuta dagoena. sa-logic.

Badakit, agian pentsatuko duzu Zerbitzu Birtualak sinpleak direla. Hurrengo atalean, hori zabalduko dugu benetan bikainak direla esanez.

Kanariar Ibilgailuak

Canary Deployment aplikazio baten bertsio berri bat erabiltzaile kopuru txiki bati zabaltzeko prozesua da. Argitalpenean arazorik ez dagoela ziurtatzeko erabiltzen da eta horren ondoren bakarrik, dagoeneko bere (argitalpenaren) kalitatean ziur egonda, beste erabiltzaile batzuei banatzeko.оaudientzia handiagoa.

Kanariar inplementazioak erakusteko, azpimultzo batekin lanean jarraituko dugu buggy у sa-logic.

Ez dezagun denborarik alferrik galdu eta berehala bidali erabiltzaileen % 20 akatsak dituen bertsiora (horrek gure kanariarren hedapena irudikatuko du), eta gainerako % 80 zerbitzu arruntera. Horretarako, erabili zerbitzu birtual hau (sa-logic-azpisets-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 pisua da (weight), hartzaile bati edo hartzailearen azpimultzo bati zuzenduko zaizkion eskaeren ehunekoa zehazten duena.

Eguneratu dezagun aurreko VirtualService-ren konfigurazioa sa-logic komando honekin:

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

... eta berehala ikusiko dugu eskaera batzuek hutsegiteak eragiten dituztela:

$ 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

Zerbitzu birtualek kanariar inplementazioak ahalbidetzen dituzte: kasu honetan, arazoen eragin potentziala erabiltzaile-basearen %20ra murriztu dugu. Zoragarria! Orain, kasu guztietan gure kodeaz ziur ez gaudenean (hots, beti...), ispilu eta inplementazio kanarioak erabil ditzakegu.

Denbora-muga eta berriro saiakerak

Baina akatsak ez dira beti kodean amaitzen. "tik" zerrendan8 Konputazio Banatuari buruzko uste okerrak"Lehenengo, "sarea fidagarria da" uste okerra dago. Errealitatean sarea ez fidagarria, eta horregatik denbora-muga behar dugu (denbora-muga) eta berriro saiatu (berriro saiatu).

Erakusketa egiteko arazo-bertsio bera erabiltzen jarraituko dugu sa-logic (buggy), eta sarearen fidagarritasuna ausazko hutsegiteekin simulatuko dugu.

Utzi akatsak dituen gure zerbitzuari erantzuteko denbora luzeegia hartzeko aukera 1/3 bat, zerbitzariaren barne-errore batekin amaitzeko aukera 1/3 bat eta orria behar bezala itzultzeko aukera 1/3 bat.

Arazo horien eragina arintzeko eta erabiltzaileen bizitza hobetzeko, honako hau egin dezakegu:

1. gehitu denbora-muga zerbitzuak erantzuteko 8 segundo baino gehiago behar baditu,
2. berriro saiatu eskaerak huts egiten badu.

Ezartzeko, honako baliabideen definizio hau erabiliko dugu (sa-logic-retry-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. Eskaeraren denbora-muga 8 segundotan ezartzen da;
2. Eskaerak 3 aldiz errepikatzen dira;
3. Eta saiakera bakoitza arrakastatsutzat jotzen da erantzun denbora 3 segundotik gorakoa bada.

Hau optimizazio bat da, erabiltzaileak ez baitu 8 segundo baino gehiago itxaron beharko eta hutsegiteen kasuan erantzuna lortzeko hiru saiakera berri egingo ditugu, erantzun arrakastatsu bat izateko aukera areagotuz.

Aplikatu eguneratutako konfigurazioa komando honekin:

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

Eta egiaztatu Grafana grafikoetan erantzun arrakastatsuen kopurua gora egin dela:

Erantzun arrakastatsuen estatistiketan hobekuntzak denbora-muga eta berriro saiakerak gehitu ondoren

Hurrengo atalera pasatu aurretik (edo hobeto esanda, artikuluaren hurrengo zatira, honetan ez baita esperimentu praktiko gehiago egongo - gutxi gorabehera), ezabatu sa-logic-buggy eta VirtualService komando hauek exekutatuz:

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

Circuit Breaker eta Bulkhead ereduak

Mikrozerbitzuen arkitekturan auto-berreskuratzea ahalbidetzen duten bi eredu garrantzitsuz ari gara (autosendatzea) zerbitzuak.

Zirkuitua Breaker ("zirkuitu etengailua") Osasungaitztzat jotzen den zerbitzu baten instantzia batera datozen eskaerak amaitzeko eta bezeroen eskaerak zerbitzu horren instantzia osasuntsuetara birbideratzen diren bitartean (horrek erantzun arrakastatsuen ehunekoa handitzen du). (Oharra: ereduaren deskribapen zehatzagoa aurki daiteke, adibidez, Hemen.)

Bultzada ("partizioa") zerbitzuaren hutsegiteak sistema osoari eragin diezaioten isolatzen ditu. Adibidez, B zerbitzua hautsita dago eta beste zerbitzu batek (B Zerbitzuaren bezeroak) eskaera bat egiten dio B Zerbitzuari, eta horrek bere hari multzoa agortu eta beste eskaera batzuei erantzun ezin die (nahiz eta B Zerbitzukoak ez izan). (Oharra: ereduaren deskribapen zehatzagoa aurki daiteke, adibidez, Hemen.)

Eredu horien ezarpen-xehetasunak baztertuko ditut, erraz aurki daitezkeelako dokumentazio ofiziala, eta autentifikazioa eta baimena ere erakutsi nahi ditut, artikuluaren hurrengo zatian eztabaidatuko dena.

PS itzultzailetik

Irakurri ere gure blogean:

• "Itzuli mikrozerbitzuetara Istio-rekin": 1. zatia (ezaugarri nagusien sarrera), 3. zatia (autentifikazioa eta baimena);
• «Conduit - zerbitzu sare arina Kubernetesentzat»;
• «Zer da zerbitzu-sare bat eta zergatik behar dut [mikrozerbitzuekin hodeiko aplikazio baterako]?'.

Iturria: www.habr.com