Обратно към микроуслугите с Istio. Част 2

Забележка. превод: Първата част този цикъл беше посветен на запознаване с възможностите на Istio и демонстрирането им в действие. Сега ще говорим за по-сложни аспекти на конфигурирането и използването на тази мрежа на услугата и по-специално за фино настроеното маршрутизиране и управление на мрежовия трафик.

Също така напомняме, че статията използва конфигурации (манифести за Kubernetes и Istio) от хранилището istio-майсторство.

управление на трафика

С Istio към клъстера се добавят нови функции, за да осигурят:

• Динамично маршрутизиране на заявки: Canary rollouts, A/B тестване;
• Балансиране на натоварването: прост и последователен, базиран на хешове;
• Възстановяване след падане: изчакване, повторни опити, прекъсвачи;
• Въвеждане на грешки: закъснения, прекъсване на заявки и др.

Докато статията продължава, тези функции ще бъдат демонстрирани с помощта на избраното приложение като пример и нови концепции ще бъдат въведени по пътя. Първата такава концепция ще бъде DestinationRules (т.е. правила за получателя на трафик / заявки - прибл. превод), с който активираме A/B тестване.

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

Внимание: Въздействието на ресурсите на Istio върху мрежовия трафик е представено тук в опростена форма за разбиране. За да бъдем точни, решението до коя инстанция да се изпрати заявката се взема от Envoy в Ingress Gateway, конфигуриран в 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 (Or с тази за 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-subset-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-subset-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 се прилага към нашата услуга Envoys: кога sa-web-app отправя молба към sa-logic, преминава през sidecar Envoy, който - чрез VirtualService - е конфигуриран да насочва заявката към подмножеството v1 и да отразява заявката към подмножеството v2 на услугата sa-logic.

Знам: вече имахте време да помислите, че виртуалните услуги са прости. В следващия раздел ще разширим това мнение, като кажем, че те също са наистина страхотни.

Canary Rollouts

Canary Deployment е процесът на пускане на нова версия на приложение на малък брой потребители. Използва се, за да се увери, че няма проблеми в изданието, и едва след това, като вече сте сигурни в неговото достатъчно (издание) качество, го разпространете наопо-голяма публика.

За да демонстрираме внедряване на Canary, ще продължим с подмножество 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 да изобрази страницата успешно.

За да смекчим въздействието на тези проблеми и да подобрим живота на нашите потребители, можем:

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

И проверете в графиките на 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) отправя заявка към услуга B, което я кара да използва своя пул от нишки и да не може да обслужва други заявки (дори ако те не принадлежат към услугата Б). (Забележка в превода: По-подробно описание на модела може да се намери, напр. тук.)

Ще пропусна подробностите за изпълнението на тези модели, защото са лесни за намиране официална документация, а също така наистина искам да покажа удостоверяване и оторизация, които ще бъдат обсъдени в следващата част на статията.

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

Прочетете също в нашия блог:

• „Назад към микроуслугите с Istio“: част 1 (въведение в основните характеристики), част 3 (удостоверяване и оторизация);
• «Conduit - лек сервизен меш за Kubernetes»;
• «Какво представлява мрежата на услугата и защо ми е необходима [за облачно приложение с микроуслуги]?".

Източник: www.habr.com