🥇Reen al mikroservoj kun Istio. Parto 2

Notu. transl.: Unua parto Tiu serio estis dediĉita al enkonduko de Istio-kapabloj kaj pruvado de ili en ago. Nun ni parolos pri pli kompleksaj aspektoj de la agordo kaj uzo de ĉi tiu servo-maŝo, kaj precipe pri fajne agordita enrutado kaj reta trafiko-administrado.

Ni ankaŭ memorigas vin, ke la artikolo uzas agordojn (manifestojn por Kubernetes kaj Istio) el la deponejo. istio-majstrado.

trafikadministrado

Kun Istio, novaj kapabloj aperas en la areto por provizi:

Dinamika peto-vojigo: kanariaj landoj, A/B-testado;
Ŝarĝbalancado: simpla kaj konsekvenca, surbaze de haŝoj;
Resaniĝo post faloj: temporompoj, reprovoj, ŝaltiloj;
Enmetado de misfunkciadoj: prokrastoj, forigitaj petoj, ktp.

Dum la artikolo daŭras, ĉi tiuj kapabloj estos ilustritaj uzante la elektitan aplikaĵon kiel ekzemplon kaj novaj konceptoj estos enkondukitaj survoje. La unua tia koncepto estos DestinationRules (t.e. reguloj pri la ricevanto de trafiko/petoj - ĉ. traduko), per kies helpo ni aktivigas A/B-testadon.

A/B-testado: Destination Rules en praktiko

A/B-testado estas uzata en kazoj kie ekzistas du versioj de aplikaĵo (kutime ili estas vide malsamaj) kaj ni ne estas 100% certaj, kiu plibonigos la uzantan sperton. Tial ni kuras ambaŭ versiojn samtempe kaj kolektas metrikojn.

Por disfaldi la duan version de la fasado, necesa por pruvi A/B-testadon, rulu la sekvan komandon:

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

La deploja manifesto por la verda versio malsamas en du lokoj:

La bildo baziĝas sur malsama etikedo - istio-green,
Podoj havas etikedon version: green.

Ĉar ambaŭ deplojoj havas etikedon app: sa-frontend,petoj direktitaj de virtuala servo sa-external-services por servo sa-frontend, estos redirektita al ĉiuj ĝiaj okazoj kaj la ŝarĝo estos distribuita tra cirkla-subskribolista algoritmo, kiu kondukos al la sekva situacio:

La petitaj dosieroj ne estis trovitaj

Ĉi tiuj dosieroj ne estis trovitaj ĉar ili estas nomitaj malsame en malsamaj versioj de la aplikaĵo. Ni certigu ĉi tion:

$ 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

Ĝi signifas tion index.html, petante unu version de senmovaj dosieroj, povas esti sendita de la ŝarĝbalancilo al podoj kiuj havas malsaman version, kie, pro evidentaj kialoj, tiaj dosieroj ne ekzistas. Tial, por ke la aplikaĵo funkciu, ni devas agordi limigon: "la sama versio de la aplikaĵo kiu servis index.html devus servi postajn petojn".

Ni atingos tien kun konsekvenca hash-bazita ŝarĝbalancado (Konsekvenca Hash Loadbalancing)... Tiuokaze petoj de la sama kliento estas senditaj al la sama backend-instanco, por kiu estas uzata antaŭdifinita posedaĵo - ekzemple HTTP-kapo. Efektivigite uzante DestinationRules.

Destinaciaj Reguloj

post la Virtuala Servo sendis peton al la dezirata servo, uzante DestinationRules ni povas difini politikojn, kiuj estos aplikitaj al trafiko destinita por ekzemploj de ĉi tiu servo:

Trafikadministrado kun Istio-resursoj

Примечание: La efiko de Istio-resursoj sur rettrafiko estas prezentita ĉi tie en maniero facile komprenebla. Por esti precizaj, la decido pri kiu instanco sendi la peton estas farita de la Sendito en la Enirejo agordita en la CRD.

Kun Celaj Reguloj, ni povas agordi ŝarĝan ekvilibron por uzi konsekvencajn haŝojn kaj certigi, ke la sama servo-instanco respondas al la sama uzanto. La sekva agordo permesas vin atingi tion (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 estos generita surbaze de la enhavo de la HTTP-kapo version.

Apliku la agordon per la sekva komando:

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

Nun rulu la komandon sube kaj certigu, ke vi ricevas la ĝustajn dosierojn kiam vi specifas la kaplinion version:

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

Примечание: Por aldoni malsamajn valorojn en la kaplinio kaj testi la rezultojn rekte en la retumilo, vi povas uzi ĉi tiu etendo al Chrome (aŭ kun ĉi tio por Firefox - ĉ. traduk.).

Ĝenerale, DestinationRules havas pli da kapabloj en la areo de ŝarĝo-ekvilibro - kontrolu detalojn oficiala dokumentaro.

Antaŭ ol studi VirtualService plu, ni forigu la "verdan version" de la aplikaĵo kaj la respondan regulon de trafiko direktante la jenajn komandojn:

$ 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

Spegulo: Virtualaj Servoj en Praktiko

Ombro ("ŝirmado") aŭ Spegulado ("spegulado") uzata en kazoj kie ni volas testi ŝanĝon en produktado sen tuŝi finajn uzantojn: por fari tion, ni duobligas ("spegulon") petojn al dua okazo kie la dezirataj ŝanĝoj estis faritaj, kaj rigardas la sekvojn. Simple dirite, ĉi tie estas kiam via kolego elektas la plej kritikan aferon kaj faras tiran peton en la formo de tia grandega malpuraĵo, ke neniu povas efektive revizii ĝin.

Por testi ĉi tiun scenaron en ago, ni kreu duan kazon de SA-Logic kun cimoj (buggy) per la sekva komando:

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

Kaj nun ni rulu la komandon por certigi, ke ĉiuj okazoj kun app=sa-logic Ili ankaŭ havas etikedojn kun la ekvivalentaj versioj:

$ 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

servo sa-logic celas podojn kun etikedo app=sa-logic, do ĉiuj petoj estos distribuitaj inter ĉiuj okazoj:

... sed ni volas, ke petoj estu senditaj al v1-instancoj kaj spegulitaj al v2-instancoj:

Ni atingos tion per VirtualService en kombinaĵo kun DestinationRule, kie la reguloj determinos la subarojn kaj itinerojn de la VirtualService al specifa subaro.

Difinante Subarojn en Destinaj Reguloj

Subaroj (subaroj) estas determinitaj per la sekva agordo (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

Gastiganto (host) difinas ke tiu regulo validas nur por kazoj kiam la itinero iras al la servo sa-logic;
Titoloj (name) subaroj estas uzataj dum vojigo al subaroj;
Etikedo (label) difinas la ŝlosil-valorparojn kiujn okazoj devas kongrui por iĝi parto de la subaro.

Apliku la agordon per la sekva komando:

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

Nun kiam la subaroj estas difinitaj, ni povas pluiri kaj agordi la VirtualService por apliki regulojn al petoj al sa-logiko por ke ili:

Votita al subaro v1,
Spegulita al subaro v2.

La sekva manifesto permesas al vi realigi viajn planojn (sa-logikaj-subaroj-ombrado-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

Ne necesas klarigo ĉi tie, do ni vidu ĝin en ago:

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

Ni aldonu la ŝarĝon vokante la sekvan komandon:

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

Ni rigardu la rezultojn en Grafana, kie vi povas vidi, ke la versio kun cimoj (buggy) rezultigas fiaskon por ~60% de petoj, sed neniu el tiuj fiaskoj influas finajn uzantojn ĉar ili estas responditaj de funkcianta servo.

Sukcesaj respondoj de malsamaj versioj de la sa-logika servo

Ĉi tie ni unue vidis kiel VirtualService estas aplikata al la Senditoj de niaj servoj: kiam sa-web-app faras peton al sa-logic, ĝi pasas tra la kromĉaro Envoy, kiu - per VirtualService - estas agordita por direkti la peton al la v1-subaro kaj speguli la peton al la v2-subaro de la servo. sa-logic.

Mi scias, vi eble jam pensas, ke Virtualaj Servoj estas simpla. En la sekva sekcio, ni pligrandigos tion dirante, ke ili ankaŭ estas vere bonegaj.

Kanariaj Disvolviĝoj

Canary Deployment estas la procezo de lanĉo de nova versio de aplikaĵo al malgranda nombro da uzantoj. Ĝi estas uzata por certigi, ke ne estas problemoj en la eldono kaj nur post tio, jam fidante pri ĝia (eldonaĵo) kvalito, disvastigu ĝin al aliaj uzantoj.оpli granda publiko.

Por montri kanariajn landojn, ni daŭre laboros kun subaro buggy у sa-logic.

Ni ne perdu tempon pri bagateloj kaj tuj sendu 20% de uzantoj al la versio kun cimoj (ĉi tio reprezentos nian kanarian lanĉon), kaj la ceterajn 80% al la normala servo. Por fari tion, uzu la sekvan VirtualService (sa-logikaj-subaroj-kanario-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 estas la pezo (weight), kiu precizigas la procenton de petoj kiuj estos direktitaj al ricevanto aŭ subaro de la ricevanto.

Ni ĝisdatigu la antaŭan agordon de VirtualService por sa-logic kun la sekva komando:

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

... kaj ni tuj vidos, ke iuj petoj kondukas al malsukcesoj:

$ 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 ebligas kanariajn landojn: En ĉi tiu kazo, ni malvastigis la eblan efikon de la problemoj al 20% de la uzantbazo. Mirinda! Nun, en ĉiu kazo, kiam ni ne certas pri nia kodo (alivorte - ĉiam...), ni povas uzi spegulon kaj kanariajn landojn.

Tempotempoj kaj reprovoj

Sed cimoj ne ĉiam finiĝas en la kodo. En la listo de "8 Miskompreniĝoj pri Distribuita Komputado"Unue estas la erara kredo, ke "la reto estas fidinda." En realeco la reto ne fidindaj, kaj pro tio ni bezonas tempotempojn (tempotempoj) kaj reprovoj (reprovas).

Por pruvo ni daŭre uzos la saman problemo-version sa-logic (buggy), kaj ni simulos la nefidindecon de la reto kun hazardaj fiaskoj.

Lasu nian servon kun cimoj havi 1/3 ŝancon daŭri tro longe por respondi, 1/3 ŝanco finiĝi kun Interna Servila Eraro, kaj 1/3 ŝanco por sukcese resendi la paĝon.

Por mildigi la efikon de tiaj problemoj kaj plibonigi la vivon por uzantoj, ni povas:

aldonu tempon se la servo daŭras pli ol 8 sekundojn por respondi,
reprovu se la peto malsukcesas.

Por efektivigo, ni uzos la sekvan rimeddifinon (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

La tempodaŭro por la peto estas agordita al 8 sekundoj;
Petoj estas reprovitaj 3 fojojn;
Kaj ĉiu provo estas konsiderata malsukcesa se la responda tempo superas 3 sekundojn.

Ĉi tio estas optimumigo ĉar la uzanto ne devos atendi pli ol 8 sekundojn kaj ni faros tri novajn provojn por ricevi respondon en kazo de malsukcesoj, pliigante la ŝancon de sukcesa respondo.

Apliku la ĝisdatigitan agordon per la sekva komando:

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

Kaj kontrolu en la Grafana-grafikoj, ke la nombro da sukcesaj respondoj pliiĝis supre:

Pliboniĝoj en sukcesa respondstatistiko post aldonado de tempodaŭroj kaj reprovoj

Antaŭ ol transiri al la sekva sekcio (aŭ pli ĝuste, al la sekva parto de la artikolo, ĉar en tio ne estos plu praktikaj eksperimentoj - ĉ. trad.), forigi sa-logic-buggy kaj VirtualService rulante la sekvajn komandojn:

$ 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 kaj Bulkhead Patterns

Ni parolas pri du gravaj ŝablonoj en mikroserva arkitekturo, kiuj permesas vin atingi mem-reakiron (mem-resanigo) servoj.

Cirkvitrompilo ("cirkvitrompilo") uzata por ĉesigi petojn venantajn al kazo de servo kiu estas konsiderita nesana kaj restarigi ĝin dum klientpetoj estas redirektitaj al sanaj kazoj de tiu servo (kiu pliigas la procenton de sukcesaj respondoj). (Noto: Pli detala priskribo de la ŝablono troveblas, ekzemple, tie.)

Fakmuro ("sekcio") izolas servofiaskojn de influado de la tuta sistemo. Ekzemple, Servo B estas rompita kaj alia servo (la kliento de Service B) faras peton al Servo B, igante ĝin elĉerpi sian fadenan naĝejon kaj esti nekapabla servi aliajn petojn (eĉ se ili ne estas de Servo B). (Noto: Pli detala priskribo de la ŝablono troveblas, ekzemple, tie.)

Mi preterlasos la realigajn detalojn de ĉi tiuj ŝablonoj ĉar ili estas facile troveblaj oficiala dokumentaro, kaj mi ankaŭ ege volas montri aŭtentikigon kaj rajtigon, pri kiuj estos diskutitaj en la sekva parto de la artikolo.

PS de tradukisto

Legu ankaŭ en nia blogo:

"Reen al mikroservoj kun Istio": parto 1 (enkonduko al la ĉefaj trajtoj), parto 3 (konfirmo kaj rajtigo);
«Conduit - malpeza servomaŝo por Kubernetes»;
«Kio estas servomaŝo kaj kial mi bezonas ĝin [por nuba aplikaĵo kun mikroservoj]?".

fonto: www.habr.com

Reen al mikroservoj kun Istio. Parto 2