Назад на микросервисите со Istio. Дел 2

Забелешка. превод.: Во првиот дел Оваа серија беше посветена на воведување на способностите на Istio и нивно демонстрирање на дело. Сега ќе зборуваме за посложени аспекти на конфигурацијата и употребата на оваа услуга мрежа, а особено за фино наместеното рутирање и управувањето со мрежниот сообраќај.

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

Управување со сообраќајот

Со Istio, новите способности се појавуваат во кластерот за да обезбедат:

• Динамично насочување на барањето: ротирања на канари, A/B тестирање;
• Балансирање на товарот: едноставен и конзистентен, базиран на хашови;
• Закрепнување по падови: тајмаути, повторни обиди, прекинувачи;
• Вметнување дефекти: одложувања, отфрлени барања итн.

Како што продолжува написот, овие способности ќе бидат илустрирани користејќи ја избраната апликација како пример и ќе се воведат нови концепти на патот. Првиот таков концепт ќе биде DestinationRules (т.е. правила за примачот на сообраќај/барања - прибл. превод), со чија помош го активираме A/B тестирањето.

А/Б тестирање: Правила за дестинација во пракса

A/B тестирањето се користи во случаи кога има две верзии на апликација (обично тие се визуелно различни) и не сме 100% сигурни која од нив ќе го подобри корисничкото искуство. Затоа, ги извршуваме двете верзии истовремено и собираме метрика.

За да ја распоредите втората верзија на предниот дел, потребна за демонстрација на A/B тестирање, извршете ја следнава команда:

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

Манифестот за распоредување за зелената верзија се разликува на две места:

1. Сликата е заснована на друга ознака - istio-green,
2. Мешунките имаат етикета 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.

Правила за дестинација

По Виртуелна услуга испративме барање до саканата услуга, со помош на DestinationRules можеме да дефинираме политики што ќе се применуваат на сообраќајот наменет за примери на оваа услуга:

Управување со сообраќајот со ресурсите на Истио

Имајте на ум: Влијанието на ресурсите на 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

Имајте на ум: За да додадете различни вредности во заглавието и да ги тестирате резултатите директно во прелистувачот, можете да користите ова проширување на Хром (Или со ова за 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 („отсликување“) се користи во случаи кога сакаме да тестираме промена во производството без да влијаеме на крајните корисници: за да го направиме тоа, ги дуплираме („огледало“) барањата до втор степен каде што се направени саканите промени и ги разгледуваме последиците. Едноставно кажано, ова е кога вашиот колега го избира најкритичното прашање и прави барање за повлекување во форма на толку огромна грутка нечистотија што никој всушност не може да го прегледа.

За да го тестираме ова сценарио во акција, ајде да создадеме втор пример на 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-подмножества-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

1. Домаќин (host) дефинира дека ова правило важи само за случаи кога трасата оди кон услугата sa-logic;
2. Наслови (name) подмножества се користат при рутирање на инстанци на подмножества;
3. Етикета (label) ги дефинира паровите клуч-вредност со кои инстанците мора да одговараат за да станат дел од подмножеството.

Примени ја конфигурацијата со следнава команда:

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

Сега кога подмножествата се дефинирани, можеме да продолжиме и да го конфигурираме VirtualService да применува правила на барањата за sa-logic, така што тие:

1. Насочено до подмножество v1,
2. Прегледано на подмножество 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

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

Успешни одговори на различни верзии на услугата sa-logic

Овде за прв пат видовме како VirtualService се применува на пратениците на нашите услуги: кога sa-web-app упатува барање до sa-logic, минува низ страничната кола Envoy, која - преку VirtualService - е конфигурирана да го насочува барањето до подмножеството v1 и да го пресликува барањето до подмножеството v2 на услугата sa-logic.

Знам, можеби веќе мислите дека Виртуелните услуги се едноставни. Во следниот дел, ќе го прошириме тоа велејќи дека тие се исто така навистина одлични.

Распоредување на канари

Canary Deployment е процес на воведување нова верзија на апликација за мал број корисници. Се користи за да се увериме дека нема проблеми во издавањето и само после тоа, веќе уверени во неговиот (издание) квалитет, дистрибуирајте го на други корисници.опоголема публика.

За да го демонстрираме распоредувањето на канаринци, ќе продолжиме да работиме со подмножество buggy у sa-logic.

Да не губиме време на ситници и веднаш да испратиме 20% од корисниците на верзијата со грешки (ова ќе го претставува нашето пуштање на канаринци), а останатите 80% до нормалната услуга. За да го направите ова, користете ја следнава виртуелна услуга (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% од базата на корисници. Прекрасно! Сега, во секој случај кога не сме сигурни во нашиот код (со други зборови - секогаш...), можеме да користиме mirroring и canary rollouts.

Истекнувања и повторни обиди

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

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

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

За да го ублажиме влијанието на ваквите проблеми и да го подобриме животот за корисниците, можеме:

1. додадете тајмаут ако на услугата и требаат подолго од 8 секунди за да одговори,
2. обидете се повторно ако барањето не успее.

За имплементација, ќе ја користиме следната дефиниција на ресурси (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. Времето на истекот на барањето е поставено на 8 секунди;
2. Барањата се повторуваат 3 пати;
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 и 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

Модели на прекинувачот и преградата

Зборуваме за два важни шеми во архитектурата на микросервис кои ви овозможуваат да постигнете само-обновување (само-лекување) услуги.

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

Преграда („партиција“) ги изолира дефектите на услугата да не влијаат на целиот систем. На пример, услугата Б е скршена и друга услуга (клиентот на услугата Б) поднесува барање до услугата Б, предизвикувајќи таа да го исцрпи својот базен на нишки и да не може да сервисира други барања (дури и ако тие не се од услугата Б). (Забелешка: Подетален опис на моделот може да се најде, на пример, тука.)

Ќе ги изоставам деталите за имплементацијата на овие обрасци бидејќи лесно се наоѓаат во нив официјална документација, а исто така навистина сакам да покажам автентикација и овластување, за што ќе се дискутира во следниот дел од статијата.

PS од преведувач

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

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

Извор: www.habr.com