Kthehu te mikroshërbimet me Istio. Pjesa 2

Shënim. përkth.: Pjesa e pare Kjo seri iu dedikua prezantimit të aftësive të Istio dhe demonstrimit të tyre në veprim. Tani do të flasim për aspekte më komplekse të konfigurimit dhe përdorimit të kësaj rrjete shërbimi, dhe në veçanti, për drejtimin e rregulluar mirë dhe menaxhimin e trafikut të rrjetit.

Ju kujtojmë gjithashtu se artikulli përdor konfigurime (manifestime për Kubernetes dhe Istio) nga depoja istio-mjeshtëri.

Menaxhimi i Trafikut

Me Istio, aftësi të reja shfaqen në grup për të ofruar:

• Drejtimi dinamik i kërkesës: nxjerrja e kanarinave, testimi A/B;
• Balancimi i ngarkesës: e thjeshtë dhe e qëndrueshme, e bazuar në hash;
• Rimëkëmbja pas rënies: ndërprerje, riprovime, ndërprerës;
• Futja e gabimeve: vonesa, kërkesa të hedhura, etj.

Ndërsa artikulli vazhdon, këto aftësi do të ilustrohen duke përdorur aplikacionin e zgjedhur si shembull dhe koncepte të reja do të prezantohen gjatë rrugës. Koncepti i parë i tillë do të jetë DestinationRules (d.m.th. rregullat për marrësin e trafikut/kërkesave - përafërsisht përkth.), me ndihmën e të cilit aktivizojmë testimin A/B.

Testimi A/B: Rregullat e Destinacionit në praktikë

Testimi A/B përdoret në rastet kur ka dy versione të një aplikacioni (zakonisht ato janë vizualisht të ndryshme) dhe ne nuk jemi 100% të sigurt se cili do të përmirësojë përvojën e përdoruesit. Prandaj, ne ekzekutojmë të dy versionet njëkohësisht dhe mbledhim metrikë.

Për të vendosur versionin e dytë të frontendit, i nevojshëm për demonstrimin e testimit A/B, ekzekutoni komandën e mëposhtme:

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

Manifesti i vendosjes për versionin e gjelbër ndryshon në dy vende:

1. Imazhi bazohet në një etiketë tjetër - istio-green,
2. Bishtajat kanë një etiketë version: green.

Meqenëse të dyja vendosjet kanë një etiketë app: sa-frontend,kërkesat e drejtuara nga shërbimi virtual sa-external-services për shërbim sa-frontend, do të ridrejtohet në të gjitha rastet e tij dhe ngarkesa do të shpërndahet përmes algoritmi i rrumbullakët, e cila do të çojë në situatën e mëposhtme:

Skedarët e kërkuar nuk u gjetën

Këta skedarë nuk u gjetën sepse emërtohen ndryshe në versione të ndryshme të aplikacionit. Le të sigurohemi për këtë:

$ 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

Kjo do të thotë se index.html, duke kërkuar një version të skedarëve statikë, mund të dërgohet nga balancuesi i ngarkesës në pods që kanë një version tjetër, ku, për arsye të dukshme, skedarë të tillë nuk ekzistojnë. Prandaj, në mënyrë që aplikacioni të funksionojë, duhet të vendosim një kufizim: "i njëjti version i aplikacionit që shërbeu index.html duhet t'u shërbejë kërkesave të mëvonshme'.

Do të arrijmë atje me balancim të vazhdueshëm të ngarkesës bazuar në hash (Ngarkim i vazhdueshëm i hash-it)... Në këtë rast kërkesat nga i njëjti klient dërgohen në të njëjtin shembull backend, për të cilën përdoret një veti e paracaktuar - për shembull, një kokë HTTP. Zbatuar duke përdorur DestinationRules.

Rregullat e Destinacionit

Pas Shërbimi Virtual dërgoi një kërkesë në shërbimin e dëshiruar, duke përdorur DestinationRules ne mund të përcaktojmë politika që do të aplikohen në trafikun e destinuar për shembuj të këtij shërbimi:

Menaxhimi i trafikut me burime Istio

Shënim: Ndikimi i burimeve Istio në trafikun e rrjetit është paraqitur këtu në një mënyrë që është e lehtë për t'u kuptuar. Për të qenë të saktë, vendimi se në cilin instancë të dërgohet kërkesa merret nga i Dërguari në Portën e hyrjes të konfiguruar në CRD.

Me Rregullat e Destinacionit, ne mund të konfigurojmë balancimin e ngarkesës për të përdorur hash të qëndrueshëm dhe të sigurojmë që i njëjti shembull i shërbimit t'i përgjigjet të njëjtit përdorues. Konfigurimi i mëposhtëm ju lejon ta arrini këtë (destinacionrule-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 do të gjenerohet bazuar në përmbajtjen e kokës HTTP version.

Aplikoni konfigurimin me komandën e mëposhtme:

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

Tani ekzekutoni komandën më poshtë dhe sigurohuni që të merrni skedarët e duhur kur të specifikoni kokën version:

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

Shënim: Për të shtuar vlera të ndryshme në kokë dhe për të testuar rezultatet direkt në shfletues, mund të përdorni këtë zgjerim në Chrome (Ose tani kjo për Firefox - përafërsisht. përkth.).

Në përgjithësi, DestinationRules ka më shumë aftësi në fushën e balancimit të ngarkesës - kontrolloni për detaje në dokumentacion zyrtar.

Përpara se të studiojmë më tej VirtualService, le të fshijmë "versionin e gjelbër" të aplikacionit dhe rregullin përkatës të drejtimit të trafikut duke ekzekutuar komandat e mëposhtme:

$ 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

Pasqyrimi: Shërbimet virtuale në praktikë

krijim hijesh ("mburojë") ose Pasqyrimi ("pasqyrim") përdoret në rastet kur duam të testojmë një ndryshim në prodhim pa ndikuar përdoruesit përfundimtarë: për ta bërë këtë, ne dublikojmë ("pasqyrë") kërkesat në një shkallë të dytë ku janë bërë ndryshimet e dëshiruara dhe shikojmë pasojat. E thënë thjesht, kjo është kur kolegu juaj zgjedh çështjen më kritike dhe bën një kërkesë tërheqjeje në formën e një gungë kaq të madhe papastërtie që askush nuk mund ta shqyrtojë atë.

Për të testuar këtë skenar në veprim, le të krijojmë një shembull të dytë të SA-Logic me gabime (buggy) duke ekzekutuar komandën e mëposhtme:

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

Dhe tani le të ekzekutojmë komandën për t'u siguruar që të gjitha rastet me app=sa-logic Ata gjithashtu kanë etiketa me versionet përkatëse:

$ 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

Shërbim sa-logic synon bishtajat me një etiketë app=sa-logic, kështu që të gjitha kërkesat do të shpërndahen në të gjitha instancat:

... por ne duam që kërkesat të dërgohen në instancat v1 dhe të pasqyrohen në instancat v2:

Ne do ta arrijmë këtë përmes VirtualService në kombinim me DestinationRule, ku rregullat do të përcaktojnë nëngrupet dhe rrugët e VirtualService në një nëngrup specifik.

Përcaktimi i nëngrupeve në rregullat e destinacionit

Nëngrupet (nëngrupe) përcaktohen nga konfigurimi i mëposhtëm (sa-logjika-nëngrupet-destinacioni rregull.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. Mikpritës (host) përcakton se ky rregull zbatohet vetëm për rastet kur itinerari shkon drejt shërbimit sa-logic;
2. Titujt (name) nëngrupet përdoren gjatë rrugëtimit në instancat e nëngrupeve;
3. Etiketa (label) përcakton çiftet çelës-vlerë që instancat duhet të përputhen për t'u bërë pjesë e nëngrupit.

Aplikoni konfigurimin me komandën e mëposhtme:

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

Tani që nëngrupet janë përcaktuar, ne mund të vazhdojmë dhe të konfigurojmë VirtualService për të aplikuar rregulla për kërkesat për sa-logjikë në mënyrë që ato:

1. Drejtuar në një nëngrup v1,
2. Pasqyruar në një nëngrup v2.

Manifesti i mëposhtëm ju lejon të arrini planet tuaja (sa-logjika-nëngrupet-hije-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

Nuk ka nevojë për shpjegim këtu, kështu që le ta shohim atë në veprim:

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

Le të shtojmë ngarkesën duke thirrur komandën e mëposhtme:

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

Le të shohim rezultatet në Grafana, ku mund të shihni se versioni me gabime (buggy) rezulton në dështim për ~ 60% të kërkesave, por asnjë nga këto dështime nuk prek përdoruesit fundorë pasi atyre u përgjigjet një shërbim që funksionon.

Përgjigjet e suksesshme të versioneve të ndryshme të shërbimit sa-logjik

Këtu pamë për herë të parë se si VirtualService zbatohet për të dërguarit e shërbimeve tona: kur sa-web-app bën një kërkesë për të sa-logic, kalon përmes Envoy-it anësor, i cili - nëpërmjet VirtualService - është konfiguruar të drejtojë kërkesën në nëngrupin v1 dhe ta pasqyrojë kërkesën në nëngrupin v2 të shërbimit sa-logic.

E di, tashmë mund të mendoni se Shërbimet Virtuale janë të thjeshta. Në seksionin tjetër, ne do ta zgjerojmë atë duke thënë se ato janë gjithashtu vërtet të shkëlqyera.

Përhapja e kanarinave

"Canary Deployment" është procesi i paraqitjes së një versioni të ri të një aplikacioni për një numër të vogël përdoruesish. Përdoret për t'u siguruar që nuk ka probleme në lëshim dhe vetëm pas kësaj, duke qenë tashmë i sigurt në cilësinë e tij (lëshimit), shpërndajeni atë tek përdoruesit e tjerë.оaudiencë më të madhe.

Për të demonstruar përhapjen e kanarinave, ne do të vazhdojmë të punojmë me një nëngrup buggy у sa-logic.

Le të mos humbim kohë për gjëra të vogla dhe të dërgojmë menjëherë 20% të përdoruesve në versionin me defekte (kjo do të përfaqësojë paraqitjen tonë të kanarinave), dhe 80% të mbetur në shërbimin normal. Për ta bërë këtë, përdorni VirtualService në vijim (sa-logjika-nëngrupet-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 është pesha (weight), i cili specifikon përqindjen e kërkesave që do t'i drejtohen një marrësi ose një nëngrupi të marrësit.

Le të përditësojmë konfigurimin e mëparshëm VirtualService për sa-logic me komandën e mëposhtme:

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

... dhe ne do të shohim menjëherë se disa kërkesa çojnë në dështime:

$ 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 mundësojnë paraqitjen e kanarinave: Në këtë rast, ne kemi ngushtuar ndikimin e mundshëm të problemeve në 20% të bazës së përdoruesve. E mrekullueshme! Tani, në çdo rast kur nuk jemi të sigurt për kodin tonë (me fjalë të tjera - gjithmonë...), ne mund të përdorim pasqyrimin dhe paraqitjen e kanarisë.

Afatet dhe riprovimet

Por gabimet jo gjithmonë përfundojnë në kod. Në listën nga "8 Keqkuptime rreth Informatikës së Shpërndarë"Në radhë të parë është besimi i gabuar se "rrjeti është i besueshëm". Në realitet rrjeti jo të besueshme, dhe për këtë arsye na duhen afate kohore (koha e pushimeve) dhe ripërpiqet (riprovon).

Për demonstrim ne do të vazhdojmë të përdorim të njëjtin version problematik sa-logic (buggy), dhe ne do të simulojmë mosbesueshmërinë e rrjetit me dështime të rastësishme.

Lëreni shërbimin tonë me defekte të ketë një shans 1/3 që të marrë shumë kohë për t'u përgjigjur, një shans 1/3 për të përfunduar me një gabim të brendshëm të serverit dhe një shans 1/3 për ta kthyer faqen me sukses.

Për të zbutur ndikimin e problemeve të tilla dhe për ta bërë jetën më të mirë për përdoruesit, ne mund të:

1. shtoni një afat nëse shërbimi kërkon më shumë se 8 sekonda për t'u përgjigjur,
2. riprovoni nëse kërkesa dështon.

Për zbatimin, ne do të përdorim përkufizimin e mëposhtëm të burimit (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. Kohëzgjatja e kërkesës është vendosur në 8 sekonda;
2. Kërkesat riprovohen 3 herë;
3. Dhe çdo përpjekje konsiderohet e pasuksesshme nëse koha e përgjigjes kalon 3 sekonda.

Ky është një optimizim sepse përdoruesi nuk do të duhet të presë më shumë se 8 sekonda dhe ne do të bëjmë tre përpjekje të reja për të marrë një përgjigje në rast dështimi, duke rritur mundësinë për një përgjigje të suksesshme.

Aplikoni konfigurimin e përditësuar me komandën e mëposhtme:

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

Dhe kontrolloni në grafikët e Grafana se numri i përgjigjeve të suksesshme është rritur më lart:

Përmirësime në statistikat e përgjigjeve të suksesshme pas shtimit të afateve dhe riprovave

Përpara se të kaloni në seksionin tjetër (ose më mirë, në pjesën tjetër të artikullit, sepse në këtë nuk do të ketë më eksperimente praktike - përafërsisht përkth.), fshi sa-logic-buggy dhe VirtualService duke ekzekutuar komandat e mëposhtme:

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

Ndërprerësit e qarkut dhe Modelet e pjesëve kryesore

Ne po flasim për dy modele të rëndësishme në arkitekturën e mikroshërbimeve që ju lejojnë të arrini vetë-rikuperimin (vetë-shërimi) shërbimeve.

Circuit Breaker ("ndërprerës qarku") përdoret për të përfunduar kërkesat që vijnë në një shembull të një shërbimi që konsiderohet i pashëndetshëm dhe për ta rikthyer atë ndërsa kërkesat e klientit ridrejtohen në shembuj të shëndetshëm të atij shërbimi (gjë që rrit përqindjen e përgjigjeve të suksesshme). (Shënim: Një përshkrim më i detajuar i modelit mund të gjendet, për shembull, këtu.)

Kryqezë ("ndarje") izolon dështimet e shërbimit nga ndikimi i të gjithë sistemit. Për shembull, Shërbimi B është i prishur dhe një shërbim tjetër (klienti i Shërbimit B) i bën një kërkesë Shërbimit B, duke bërë që ai të shterojë grupin e tij të fijeve dhe të mos jetë në gjendje të shërbejë kërkesa të tjera (edhe nëse ato nuk janë nga Shërbimi B). (Shënim: Një përshkrim më i detajuar i modelit mund të gjendet, për shembull, këtu.)

Unë do të heq detajet e zbatimit të këtyre modeleve sepse ato janë të lehta për t'u gjetur dokumentacion zyrtar, dhe gjithashtu dua të tregoj vërtetimin dhe autorizimin, të cilat do të diskutohen në pjesën tjetër të artikullit.

PS nga përkthyesi

Lexoni edhe në blogun tonë:

• "Kthehu te mikroshërbimet me Istio": Pjesa 1 (hyrje në tiparet kryesore), pjesa 3 (autentifikimi dhe autorizimi);
• «Përçues - rrjetë shërbimi e lehtë për Kubernetes"?
• «Çfarë është një rrjetë shërbimi dhe pse më nevojitet [për një aplikacion cloud me mikroshërbime]?'.

Burimi: www.habr.com