🥇Istio менен микросервистерге кайтуу. 2-бөлүк

Эскертүү. котормо.: биринчи бөлүгү Бул серия Istio мүмкүнчүлүктөрүн киргизүүгө жана аларды иш жүзүндө көрсөтүүгө арналган. Эми биз бул кызматтык торду конфигурациялоонун жана колдонуунун татаалыраак аспектилери, атап айтканда, такталган маршрутизация жана тармактык трафикти башкаруу жөнүндө сүйлөшөбүз.

Ошондой эле макалада репозиторийден конфигурациялар (Kubernetes жана Istio үчүн манифесттер) колдонулганын эскертебиз чеберчилик.

Traffic Management

Istio менен кластерде жаңы мүмкүнчүлүктөр пайда болот:

Динамикалык суроо багыттоо: canary rollouts, A/B тестирлөө;
Жүктүн тең салмактуулугу: хэштердин негизинде жөнөкөй жана ырааттуу;
Жыгылгандан кийин калыбына келтирүү: тайм-ауттар, кайра аракет, автоматтык өчүргүчтөр;
Каталарды киргизүү: кечигүүлөр, четке кагылган сурамдар ж.б.

Макаланын уландысында бул мүмкүнчүлүктөр тандалган тиркемени мисал катары көрсөтүп, жаңы түшүнүктөр менен тааныштырылат. Мындай биринчи концепция болот DestinationRules (б.а. трафикти/суроолорду алуучу жөнүндө эрежелер - болжол менен котормо.), анын жардамы менен биз A/B тестирлөөсүн активдештиребиз.

A/B тестирлөө: DestinationRules иш жүзүндө

A/B тестирлөө тиркеменин эки версиясы бар учурларда колдонулат (көбүнчө алар визуалдык жактан айырмаланат) жана кайсынысы колдонуучу тажрыйбасын жакшыртаарына 100% ишене албайбыз. Ошондуктан, биз бир эле учурда эки версияны иштетип, көрсөткүчтөрдү чогултабыз.

A/B тестин көрсөтүү үчүн талап кылынган фронтондун экинчи версиясын жайылтуу үчүн, төмөнкү буйрукту аткарыңыз:

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

Жашыл версиянын жайылтуу манифести эки жерде айырмаланат:

Сүрөт башка тегге негизделген - istio-green,
Поддордун этикеткасы бар version: green.

Эки жайылтууда энбелгиси бар болгондуктан app: sa-frontend,суроолор виртуалдык кызмат аркылуу багытталат sa-external-services кызмат үчүн sa-frontend, анын бардык инстанцияларына багытталат жана жүк аркылуу бөлүштүрүлөт тегерек-робин алгоритми, бул төмөнкү жагдайга алып келет:

Суралган файлдар табылган жок

Бул файлдар табылган жок, анткени алар тиркеменин ар кандай версияларында башкача аталат. Буга ынаналы:

$ 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

Бул билдирет index.html, статикалык файлдардын бир версиясын талап кылуу, жүк баланстоочу тарабынан башка версиясы бар подкектерге жөнөтүлүшү мүмкүн, мында ачык себептерден улам мындай файлдар жок. Ошондуктан, колдонмо иштеши үчүн, биз чектөө коюу керек: "index.html кызматын көрсөткөн колдонмонун ошол эле версиясы кийинки суроо-талаптарды аткарышы керек«.

Биз ал жерге ырааттуу хэш-негизделген жүк балансы менен жетебиз (ырааттуу хэш жүктү тең салмактоо). Бул учурда ошол эле кардардан келген суроо-талаптар ошол эле инстанцияга жөнөтүлөт, алар үчүн алдын ала аныкталган касиет колдонулат - мисалы, HTTP аталышы. DestinationRules аркылуу ишке ашырылган.

Destination Rules

Андан кийин VirtualService каалаган кызматка суроо-талап жөнөтүлгөн, DestinationRules аркылуу биз бул кызматтын мисалдары үчүн багытталган трафикке колдонула турган саясаттарды аныктай алабыз:

Istio ресурстары менен трафикти башкаруу

пикир: Istio ресурстарынын тармак трафигине тийгизген таасири бул жерде түшүнүктүү түрдө берилген. Тактап айтканда, суроо-талапты кайсы инстанцияга жөнөтүү чечими CRDде конфигурацияланган Ingress Gateway ичиндеги Элчи тарабынан кабыл алынат.

Destination Rules менен биз ырааттуу хэштерди колдонуу үчүн жүк балансын конфигурациялай алабыз жана бир эле кызмат инстанциясы бир эле колдонуучуга жооп беришин камсыздай алабыз. Төмөнкү конфигурация буга жетишүүгө мүмкүндүк берет (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 - хэш HTTP башынын мазмунунун негизинде түзүлөт version.

Конфигурацияны төмөнкү буйрук менен колдонуңуз:

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

Эми төмөндөгү буйрукту иштетип, башты көрсөткөндө туура файлдарды алганыңызды текшериңиз version:

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

пикир: Баш сөзгө ар кандай маанилерди кошуу жана натыйжаларды түздөн-түз браузерде текшерүү үчүн колдоно аласыз бул кеңейтүү Chrome'го (же муну менен Firefox үчүн - болжол менен. котормо.).

Жалпысынан алганда, DestinationRules жүктү теңдөө жаатында көбүрөөк мүмкүнчүлүктөргө ээ - чоо-жайын төмөнкү жерден текшериңиз расмий документтер.

VirtualServiceти андан ары изилдөөдөн мурун, келгиле, төмөнкү буйруктарды аткаруу менен колдонмонун "жашыл версиясын" жана тиешелүү жол кыймылынын багыты эрежесин жок кылалы:

$ 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: Виртуалдык кызматтар практикада

көлөкө («калканч») же Mirroring («күзгүгө») акыркы колдонуучуларга таасирин тийгизбестен өндүрүштүн өзгөрүшүн сынагыбыз келген учурларда колдонулат: бул үчүн биз каалаган өзгөртүүлөр киргизилген экинчи инстанцияга ("күзгү") суроо-талаптарды кайталайбыз жана анын кесепеттерин карайбыз. Жөнөкөй сөз менен айтканда, бул сиздин кесиптешиңиз эң орчундуу маселени тандап алып, аны эч ким карап чыга албаган ушунчалык чоң топурак түрүндө тартуу өтүнүчүн жасаганда.

Бул сценарийди иш жүзүндө сынап көрүү үчүн, келгиле, каталар менен SA-Logicтин экинчи нускасын түзөлү (buggy) төмөнкү буйрукту иштетүү менен:

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

Эми бардык инстанциялар бар экенине ынануу үчүн буйрукту иштетели app=sa-logic Алар ошондой эле тиешелүү версиялары менен энбелгилери бар:

$ 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

кызмат sa-logic энбелгиси бар кабыктарды бутага алат app=sa-logic, ошондуктан бардык сурамдар бардык инстанциялар арасында бөлүштүрүлөт:

... бирок биз сурамдардын v1 инстанцияларына жөнөтүлүшүн жана v2 инстанцияларына чагылдырылышын каалайбыз:

Биз буга VirtualService аркылуу DestinationRule менен айкалыштырып жетишебиз, мында эрежелер VirtualServiceтин белгилүү бир топтомго чейинки топтомдорун жана маршруттарын аныктайт.

Дестинация эрежелеринде ички топтомдорду аныктоо

Кошумчалар (подборщиктер) төмөнкү конфигурация менен аныкталат (sa-logic-подсетки-дестинация эрежеси.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

Хост (host) бул эреже каттам кызматты көздөй кеткен учурларда гана колдонуларын аныктайт sa-logic;
Аталышы (name) чакан топтомдор инстанцияларга багыттоодо колдонулат;
этикетка (label) инстанциялар чакан топтомдун бир бөлүгү болуу үчүн дал келиши керек болгон ачкыч-маани жуптарын аныктайт.

Конфигурацияны төмөнкү буйрук менен колдонуңуз:

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

Эми подкасттар аныкталгандан кийин, биз VirtualServiceди улантып, sa-логикага суроо-талаптарга эрежелерди колдонуу үчүн конфигурациялай алабыз, алар:

Кошумча топтомго багытталды v1,
Чакан топтомго чагылдырылган v2.

Төмөнкү манифест сиздин пландарыңызды ишке ашырууга мүмкүндүк берет (sa-логикалык-субсетс-көлөкө-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

Бул жерде түшүндүрүүнүн кереги жок, андыктан аны иш жүзүндө карап көрөлү:

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

Төмөнкү буйрукту чакыруу менен жүктү кошолу:

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

Келгиле, Grafanaдагы жыйынтыктарды карап көрөлү, анда мүчүлүштүктөр бар версия (buggy) суроо-талаптардын ~60% аткарылбай калышына алып келет, бирок бул каталардын бири да акыркы колдонуучуларга таасирин тийгизбейт, анткени алар иштеп жаткан кызмат тарабынан жооп берет.

Са-логикалык кызматтын ар турдуу версияларынын ийгиликтуу жооптору

Бул жерде биз алгач VirtualService биздин кызматтардын Элчилерине кандайча колдонуларын көрдүк: качан sa-web-app өтүнүч менен кайрылат sa-logic, ал VirtualService аркылуу өтүнүчтү v1 чакан топтомуна багыттоо жана суроо-талапты кызматтын v2 топтомун чагылдыруу үчүн конфигурацияланган капталдагы Элчи аркылуу өтөт. sa-logic.

Мен билем, сиз Виртуалдык Кызматтарды жөнөкөй деп ойлошуңуз мүмкүн. Кийинки бөлүмдө биз бул тууралуу кененирээк айтып беребиз, алар да чынында эле сонун.

Канарийлер

Canary Deployment – бул колдонмонун жаңы версиясын аз сандагы колдонуучуларга жайылтуу процесси. Бул чыгарууда эч кандай көйгөйлөр жок экендигин текшерүү үчүн колдонулат жана андан кийин гана анын (релиздин) сапатына ишенип, аны башка колдонуучуларга таратыңыз.окөбүрөөк аудитория.

Канарларды көрсөтүү үчүн, биз бөлүмчө менен иштөөнү улантабыз buggy у sa-logic.

Келгиле, майда-чүйдө нерселерге убакытты текке кетирбейли жана колдонуучулардын 20% мүчүлүштүктөрү бар версияга дароо жөнөтөлү (бул биздин канарларды жайылтууну билдирет), ал эми калган 80% кадимки кызматка. Бул үчүн, төмөнкү VirtualService колдонуңуз (са-логикалык подсеттар-канары-вс.ямл):

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 салмак (weight), ал алуучуга же алуучунун бир бөлүгүнө багыттала турган суроо-талаптардын пайызын көрсөтөт.

үчүн мурунку VirtualService конфигурациясын жаңырталы sa-logic төмөнкү буйрук менен:

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

... жана биз дароо эле кээ бир өтүнүчтөр аткарылбай калышына алып келерин көрөбүз:

$ 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 канарларды жайылтууга мүмкүнчүлүк берет: Бул учурда биз көйгөйлөрдүн потенциалдуу таасирин колдонуучу базасынын 20% га чейин кыскарттык. Керемет! Эми, биз кодубузга ишенбеген ар бир учурда (башкача айтканда - ар дайым...), биз күзгүлөрдү жана канарларды жайылтууларды колдоно алабыз.

Таймуттар жана кайра аракет

Бирок мүчүлүштүктөр дайыма эле коддо боло бербейт. Тизмеде "8 Бөлүштүрүлгөн эсептөө жөнүндө жаңылыш түшүнүк«Биринчи орунда «тармак ишенимдүү» деген туура эмес ишеним. Чындыгында тармак жок ишенимдүү жана ушул себептен бизге тайм-аут керек (тайм-ауттар) жана кайра аракет кылат (кайра аракет кылуу).

Көрсөтүү үчүн биз ошол эле көйгөй версиясын колдоно беребиз sa-logic (buggy), жана биз тармактын ишенимсиздигин кокустуктар менен окшоштурабыз.

Мүчүлүштүктөрдү камтыган кызматыбызга жооп берүү үчүн өтө көп убакыт талап кылынган 1/3 мүмкүнчүлүгү, ички сервер катасы менен аякташынын 1/3 мүмкүнчүлүгү жана баракчаны ийгиликтүү кайтаруунун 1/3 мүмкүнчүлүгү болсун.

Мындай көйгөйлөрдүн таасирин азайтуу жана колдонуучулардын жашоосун жакшыртуу үчүн, биз:

кызмат жооп берүү үчүн 8 секунддан ашык убакыт талап кылса, тайм-аут кошуу,
өтүнүч ишке ашпай калса, кайра аракет кылыңыз.

Ишке ашыруу үчүн биз төмөнкү ресурс аныктамасын колдонобуз (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

Сурамдын күтүү мөөнөтү 8 секундга белгиленген;
Сурамдар 3 жолу кайталанат;
Ал эми жооп убактысы 3 секунддан ашса, ар бир аракет ийгиликсиз деп эсептелет.

Бул оптималдаштыруу, анткени колдонуучу 8 секунддан ашык күтпөйт жана биз ийгиликсиз жооп алуу мүмкүнчүлүгүн арттырып, каталар болгон учурда жооп алуу үчүн үч жаңы аракет жасайбыз.

Жаңыртылган конфигурацияны төмөнкү буйрук менен колдонуңуз:

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

Ийгиликтүү жооптордун саны жогоруда көбөйгөнүн Grafana графиктеринде текшериңиз:

Тайм-ауттарды жана кайра аракетти кошкондон кийин ийгиликтүү жооп статистикасынын жакшыруусу

Кийинки бөлүмгө өтүүдөн мурун (же тагыраак айтканда, макаланын кийинки бөлүгүнө, анткени мындан ары практикалык эксперименттер болбойт - болжол менен котормо.), өчүрүү sa-logic-buggy жана VirtualService төмөнкү буйруктарды иштетүү менен:

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

Ажыраткычтар жана бөлүкчөлөр

Биз өзүн-өзү калыбына келтирүүгө мүмкүндүк берген микросервис архитектурасынын эки маанилүү үлгүсү жөнүндө сөз болуп жатат (өзүн-өзү айыктыруу) кызмат.

Райондук Breaker ("электр өчүргүч") жараксыз деп эсептелген кызматтын инстанциясына келген суроо-талаптарды токтотуу жана аны калыбына келтирүү үчүн колдонулат, ал эми кардар суроо-талаптары ошол кызматтын дени сак инстанцияларына багытталат (бул ийгиликтүү жооптордун пайызын жогорулатат). (Эскертүү: үлгүнүн кененирээк сүрөттөмөсүн тапса болот, мисалы, бул жерде.)

Булкхед ("бөлүм") бүтүндөй системага таасир этүүчү кызматтын каталарын бөлүп турат. Мисалы, B кызматы бузулган жана башка кызмат (В кызматынын кардары) В кызматына суроо-талап кылат, бул анын жип пулун түгөнүп, башка суроо-талаптарды тейлей албай калышына алып келет (алар В кызматынан болбосо да). (Эскертүү: үлгүнүн кененирээк сүрөттөмөсүн тапса болот, мисалы, бул жерде.)

Мен бул үлгүлөрдү ишке ашыруунун деталдарын өткөрүп жиберем, анткени аларды табуу оңой расмий документтер, жана мен чындап эле макаланын кийинки бөлүгүндө талкуулана турган аутентификацияны жана авторизацияны көрсөткүм келет.

Котормочудан PS

Биздин блогдон дагы окуңуз:

"Istio менен микросервистерге кайтуу": 1-бөлүк (негизги өзгөчөлүктөргө киришүү), 3-бөлүк (аныктыгын текшерүү жана авторизация);
«Conduit - Kubernetes үчүн жеңил кызматтык тор";
«Кызматтык тор деген эмне жана ал мага эмне үчүн керек [микросервистери бар булут колдонмосу үчүн]?«.

Source: www.habr.com

Istio менен микросервистерге кайтуу. 2-бөлүк