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

Ескерту. аударма: Бірінші бөлім Бұл серия Istio мүмкіндіктерін енгізуге және оларды әрекетте көрсетуге арналған. Енді біз осы сервистік торды конфигурациялау мен пайдаланудың күрделі аспектілері туралы, атап айтқанда, дәл реттелген маршруттау және желілік трафикті басқару туралы сөйлесетін боламыз.

Сондай-ақ мақалада репозиторийден конфигурациялар (Kubernetes және Istio үшін манифесттер) пайдаланылатынын еске саламыз шеберлік.

қозғалысты басқару

Istio көмегімен кластерде келесі мүмкіндіктерді қамтамасыз ету үшін жаңа мүмкіндіктер пайда болады:

Динамикалық сұранысты бағыттау: канарейлерді шығару, A/B тестілеу;
Жүктемені теңестіру: қарапайым және дәйекті, хэштерге негізделген;
Құлағаннан кейін қалпына келтіру: күту, қайталау, автоматты ажыратқыштар;
Ақауларды енгізу: кешігулер, қабылданбаған сұраулар және т.б.

Мақаланың жалғасы ретінде бұл мүмкіндіктер таңдалған қолданбаны пайдаланып суреттеледі және жол бойында жаңа ұғымдар енгізіледі. Мұндай бірінші тұжырымдама болады DestinationRules (яғни трафикті/сұраныстарды алушы туралы ережелер – шамамен аударма), оның көмегімен біз A/B тестін белсендіреміз.

A/B тестілеу: Тәжірибедегі Destination Rules

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 ішінде конфигурацияланған кіру шлюзіндегі өкіл қабылдайды.

Тағайындау ережелерімен біз тұрақты хэштерді пайдалану үшін жүктемені теңестіруді теңшей аламыз және сол қызмет данасы бір пайдаланушыға жауап беретініне көз жеткізе аламыз. Келесі конфигурация бұған қол жеткізуге мүмкіндік береді (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

Айналау: практикадағы виртуалды қызметтер

Көлеңкелеу («қалқалау») немесе Айналау («айналау») соңғы пайдаланушыларға әсер етпей, өндірістегі өзгерісті сынағымыз келетін жағдайларда қолданылады: бұл үшін біз қалаған өзгерістер енгізілген екінші данаға («айна») сұрауларды қайталаймыз және салдарын қарастырамыз. Қарапайым сөзбен айтқанда, бұл сіздің әріптесіңіз ең маңызды мәселені таңдап, оны ешкім қарастыра алмайтындай үлкен кір кесек түрінде сұрауды жасаған кезде.

Бұл сценарийді әрекетте тексеру үшін қателері бар 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-logic-ке сұрауларға ережелерді қолдану үшін жылжытып, теңшей аламыз, осылайша олар:

Ішкі жиынға бағытталды v1,
Ішкі жиынға көшірілді v2.

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

Мұнда түсініктеме қажет емес, сондықтан оны іс жүзінде көрейік:

$ 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%-ы үшін сәтсіздікке әкеледі, бірақ бұл қателердің ешқайсысы соңғы пайдаланушыларға әсер етпейді, өйткені олар іске қосылған қызмет арқылы жауап береді.

sa-logic қызметінің әртүрлі нұсқаларының сәтті жауаптары

Мұнда біз алдымен VirtualService қызметтеріміздің өкілдеріне қалай қолданылатынын көрдік: қашан sa-web-app өтініш жасайды sa-logic, ол VirtualService арқылы сұрауды v1 ішкі жиынына бағыттау және сұрауды қызметтің v2 жиынына көрсету үшін конфигурацияланған бүйірлік Елші арқылы өтеді. sa-logic.

Білемін, сіз виртуалды қызметтерді қарапайым деп ойлауыңыз мүмкін. Келесі бөлімде біз олардың шынымен де керемет екенін айта отырып, оны кеңейтеміз.

Канариялық прокаттар

Canary Deployment — қолданбаның жаңа нұсқасын пайдаланушылардың аз санына шығару процесі. Ол шығарылымда проблемалардың жоқтығына көз жеткізу үшін қолданылады және тек содан кейін оның (шығарылымның) сапасына сенімді бола отырып, оны басқа пайдаланушыларға таратыңыз.оүлкенірек аудитория.

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

Уақытты ұсақ-түйекке жұмсамайық және пайдаланушылардың 20% -ын қателері бар нұсқаға дереу жіберейік (бұл біздің канарейлерді шығаруды білдіреді), ал қалған 80% -ы қалыпты қызметке. Ол үшін келесі VirtualService (sa-logic-ішкі жиындар-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 - салмақ (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-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

Сұрау үшін күту уақыты 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

Ажыратқыш және аралық қалқан үлгілері

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

Кесу ажыратқышы («ажыратқыш») жарамсыз деп саналатын қызмет данасына келетін сұрауларды тоқтату және клиент сұраулары сол қызметтің салауатты даналарына қайта бағытталған кезде оны қалпына келтіру үшін пайдаланылады (бұл сәтті жауаптардың пайызын арттырады). (Ескерту: Үлгінің толығырақ сипаттамасын табуға болады, мысалы, осында.)

Көлбеу («бөлім») қызмет ақауларын бүкіл жүйеге әсер етуден оқшаулайды. Мысалы, B қызметі бұзылған және басқа қызмет (В қызметінің клиенті) B қызметіне сұраныс жасайды, бұл оның ағындық пулын тауыстырып, басқа сұрауларға қызмет көрсете алмайды (тіпті олар В қызметінен болмаса да). (Ескерту: Үлгінің толығырақ сипаттамасын табуға болады, мысалы, осында.)

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

Аудармашыдан PS

Біздің блогта да оқыңыз:

«Istio көмегімен микросервистерге оралу»: 1 бөлім (негізгі мүмкіндіктерге кіріспе), 3-бөлім (аутентификация және авторизация);
«Conduit - Kubernetes үшін жеңіл қызмет көрсету торы«;
«Қызметтік тор дегеніміз не және ол маған не үшін қажет [микросервистері бар бұлттық қолданба үшін]?«.

Ақпарат көзі: www.habr.com

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