🥇Назад на микроуслуге са Истиом. Парт 2

Белешка. трансл.: Први део Ова серија је била посвећена увођењу Истио могућности и демонстрирању истих у акцији. Сада ћемо говорити о сложенијим аспектима конфигурације и коришћења ове сервисне мреже, а посебно о фино подешеном рутирању и управљању мрежним саобраћајем.

Такође вас подсећамо да чланак користи конфигурације (манифесте за Кубернетес и Истио) из спремишта истио-мајсторство.

Управљање саобраћајем

Уз Истио, нове могућности се појављују у кластеру да обезбеде:

Динамичко рутирање захтева: извођење канаринца, А/Б тестирање;
Балансирање оптерећења: једноставан и конзистентан, заснован на хешовима;
Опоравак након падова: временска ограничења, поновни покушаји, прекидачи;
Убацивање грешака: кашњења, одбачени захтеви итд.

Како се чланак наставља, ове могућности ће бити илустроване коришћењем изабране апликације као примера, а успут ће бити представљени и нови концепти. Први такав концепт биће DestinationRules (тј. правила о примаоцу саобраћаја/захтева – прибл. прев.), уз помоћ којих активирамо А/Б тестирање.

А/Б тестирање: Правила одредишта у пракси

А/Б тестирање се користи у случајевима када постоје две верзије апликације (обично су визуелно различите) и нисмо 100% сигурни која ће побољшати корисничко искуство. Због тога истовремено покрећемо обе верзије и прикупљамо метрике.

Да бисте применили другу верзију фронтенда, потребну за демонстрацију А/Б тестирања, покрените следећу команду:

$ 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, који захтева једну верзију статичких датотека, балансер оптерећења може послати подовима који имају другу верзију, где из очигледних разлога такве датотеке не постоје. Стога, да би апликација радила, морамо поставити ограничење: „иста верзија апликације која је сервирала индек.хтмл треба да опслужује наредне захтеве'.

Доћи ћемо тамо са доследним балансирањем оптерећења на основу хеша (Доследно балансирање хеш оптерећења)... У овом случају захтеви од истог клијента се шаљу истој позадинској инстанци, за које се користи унапред дефинисано својство - на пример, ХТТП заглавље. Имплементирано коришћењем ДестинатионРулес.

ДестинатионРулес

После ВиртуалСервице послао захтев жељеној услузи, користећи ДестинатионРулес можемо дефинисати смернице које ће се применити на саобраћај намењен за инстанце ове услуге:

Управљање саобраћајем са Истио ресурсима

Приметити: Утицај Истио ресурса на мрежни саобраћај је овде представљен на начин који је лако разумети. Да будемо прецизни, одлуку о томе којој инстанци ће се послати захтев доноси изасланик у Ингресс Гатеваи-у конфигурисаном у ЦРД-у.

Са одредишним правилима можемо да конфигуришемо балансирање оптерећења да користимо доследне хешове и обезбедимо да иста инстанца услуге одговара истом кориснику. Следећа конфигурација вам омогућава да то постигнете (дестинацијаруле-са-фронтенд.иамл):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-frontend
spec:
  host: sa-frontend
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: version   # 1

1 - хеш ће бити генерисан на основу садржаја ХТТП заглавља 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

Приметити: Да бисте додали различите вредности у заглавље и тестирали резултате директно у прегледачу, можете да користите ово проширење у Цхроме (Или са овим за Фирефок - прибл. превод).

Генерално, ДестинатионРулес има више могућности у области балансирања оптерећења - проверите детаље у званична документација.

Пре него што даље проучавамо ВиртуалСервице, хајде да избришемо „зелену верзију“ апликације и одговарајуће правило смера саобраћаја тако што ћемо покренути следеће команде:

$ 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

Пресликавање: Виртуелне услуге у пракси

Схадовинг („заштита“) или Мирроринг („огледање“) користи се у случајевима када желимо да тестирамо промену у производњи без утицаја на крајње кориснике: да бисмо то урадили, дуплирамо („пресликавамо“) захтеве другој инстанци где су направљене жељене промене и гледамо последице. Једноставно речено, ово је када ваш колега бира најкритичније питање и поставља захтев за повлачење у облику тако огромне груде прљавштине да нико не може да је прегледа.

Да бисмо тестирали овај сценарио на делу, хајде да направимо другу инстанцу СА-Логиц са грешкама (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, тако да ће сви захтеви бити распоређени међу свим инстанцама:

... али желимо да се захтеви шаљу на в1 инстанце и пресликавају на в2 инстанце:

То ћемо постићи преко ВиртуалСервице-а у комбинацији са ДестинатионРуле-ом, где ће правила одредити подскупове и руте ВиртуалСервице-а до одређеног подскупа.

Дефинисање подскупова у правилима одредишта

Подскупови (подскупови) одређују следећа конфигурација (са-логиц-подсетс-дестинатионруле.иамл):

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

Сада када су подскупови дефинисани, можемо да наставимо даље и да конфигуришемо ВиртуалСервице да примењује правила на захтеве са-логиц тако да:

Рутирано на подскуп v1,
Пресликано на подскуп v2.

Следећи манифест вам омогућава да остварите своје планове (са-логиц-подсетс-схадовинг-вс.иамл):

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

Погледајмо резултате у Графани, где можете видети да је верзија са грешкама (buggy) резултира неуспехом за око 60% захтева, али ниједан од ових грешака не утиче на крајње кориснике јер на њих одговара покренута услуга.

Успешни одговори различитих верзија са-логиц сервиса

Овде смо први пут видели како се ВиртуалСервице примењује на изасланике наших услуга: када sa-web-app поставља захтев да sa-logic, пролази кроз помоћни Енвои, који је - преко ВиртуалСервице-а - конфигурисан да усмери захтев на в1 подскуп и огледа захтев у в2 подскуп услуге sa-logic.

Знам, можда већ мислите да су виртуелне услуге једноставне. У следећем одељку ћемо то проширити тако што ћемо рећи да су и они заиста сјајни.

Цанари роллоутс

Цанари Деплоимент је процес увођења нове верзије апликације малом броју корисника. Користи се да би се осигурало да нема проблема у издању и тек након тога, већ сигурни у његов (издања) квалитет, дистрибуира га другим корисницима.овећа публика.

Да бисмо демонстрирали увођење канаринца, наставићемо да радимо са подскупом buggy у sa-logic.

Хајде да не губимо време на ситнице и одмах пошаљимо 20% корисника на верзију са грешкама (ово ће представљати наш канаринчић), а преосталих 80% на нормалну услугу. Да бисте то урадили, користите следећи виртуелни сервис (са-логиц-подсетс-цанари-вс.иамл):

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), који одређује проценат захтева који ће бити упућени примаоцу или подскупу примаоца.

Хајде да ажурирамо претходну конфигурацију ВиртуалСервице за 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

ВиртуалСервицес омогућавају увођење канараца: У овом случају, сузили смо потенцијални утицај проблема на 20% корисничке базе. Предивна! Сада, у сваком случају када нисмо сигурни у свој код (другим речима - увек...), можемо да користимо пресликавање и канаринско увођење.

Временска ограничења и поновни покушаји

Али грешке не завршавају увек у коду. На листи од "8 Заблуда о дистрибуираном рачунарству„На првом месту је погрешно уверење да је „мрежа поуздана“. У стварности мрежа не поуздан, и из тог разлога нам је потребно временско ограничење (временска ограничења) и поново покушава (поновни покушај).

За демонстрацију ћемо наставити да користимо исту верзију проблема sa-logic (buggy), а ми ћемо симулирати непоузданост мреже са случајним кваровима.

Нека наша услуга са грешкама има 1/3 шансе да треба предуго да одговори, 1/3 шансе да се заврши интерном грешком сервера и 1/3 шансе да успешно врати страницу.

Да бисмо ублажили утицај таквих проблема и учинили живот бољим корисницима, можемо:

додајте временско ограничење ако сервису треба дуже од 8 секунди да одговори,
покушајте поново ако захтев не успе.

За имплементацију ћемо користити следећу дефиницију ресурса (са-логиц-ретриес-тимеоутс-вс.иамл):

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

И проверите на Графана графиконима да се број успешних одговора повећао изнад:

Побољшања статистике успешног одговора након додавања временских ограничења и поновних покушаја

Пре него што пређемо на следећи одељак (тачније, на следећи део чланка, јер у овоме више неће бити практичних експеримената – прибл. прев.), избрисати sa-logic-buggy и ВиртуалСервице покретањем следећих команди:

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

Обрасци прекидача и преграда

Говоримо о два важна обрасца у архитектури микросервиса који вам омогућавају да постигнете самоопоравак (самоизлечење) услуге.

Прекидач ("прекидач") користи се за укидање захтева који долазе до инстанце услуге која се сматра нездравом и враћање исте док се захтеви клијената преусмеравају на здраве инстанце те услуге (што повећава проценат успешних одговора). (Напомена: Детаљнији опис шаблона може се наћи, нпр. овде.)

Преграда ("подела") изолује кварове услуга од утицаја на цео систем. На пример, услуга Б је покварена и друга услуга (клијент услуге Б) упућује захтев услузи Б, због чега она исцрпљује свој скуп нити и не може да сервисира друге захтеве (чак и ако нису из услуге Б). (Напомена: Детаљнији опис шаблона може се наћи, нпр. овде.)

Изоставићу детаље имплементације ових образаца јер их је лако пронаћи званична документација, а такође заиста желим да покажем аутентификацију и ауторизацију, о чему ће бити речи у следећем делу чланка.

ПС од преводиоца

Прочитајте и на нашем блогу:

„Назад на микроуслуге са Истио-ом“: део 1 (увод у главне карактеристике), део 3 (аутентификација и ауторизација);
«Цондуит - лагана сервисна мрежа за Кубернетес";
«Шта је сервисна мрежа и зашто ми је потребна [за апликацију у облаку са микросервисима]?'.

Извор: ввв.хабр.цом

Назад на микроуслуге са Истиом. део 2