Серия постове за Istio Service Mesh

Започваме серия от публикации, в която ще демонстрираме част от многото възможности на сървисната мрежа Istio Service Mesh в комбинация с Red Hat OpenShift и Kubernetes.

Част първа, днешната:

• Ще обясним концепцията за sidecar контейнери в Kubernetes и ще формулираме основната тема на тази серия публикации: «не е необходимо да променяте кода си».
• Нека представим основополагаещия елемент на Istio – правилата за маршрутизиране. На тях се базират всички други възможности на Istio, тъй като именно правилата позволяват насочване на трафика към микросервизи, използвайки файлове YAML извън кода на сървисите. Ще разгледаме и схемата за разгръщане на Canary Deployment. Новороден пакет – 10 интерактивни занятия по Istio.

Част втора, която скоро ще излезе, ще ви разкаже:

• Как Istio реализира Pool Ejection в комбинация с Circuit Breaker и ще демонстрира как Istio позволява изключването на неработещ или лошо работещ pod от схемата за балансировка.
• Освен това ще разгледаме темата за Circuit Breaker от първата публикация по отношение на начините за използване на Istio тук. Ще покажем как без никакви промени в кодовете на сървисите да маршрутизираме трафика и да обработваме мрежови грешки с помощта на конфигурационни файлове YAML и терминални команди.

Част трета:

• Разказ за трасировката и мониторинга, които вече са вградени или лесно добавими в Istio. Ще покажем как да използваме инструменти като Prometheus, Jaeger и Grafana в комбинация с мащабируемостта на OpenShift, за да управляваме микросервизната архитектура без усилия.
• Преминаваме от мониторинг и обработка на грешки към умишлено въвеждане на грешки в системата. С други думи, учим се как да правим fault injection без да променяме изходния код, което е изключително важно от гледна точка на тестването – тъй като ако променяме за това самия код, има риск да въведем допълнителни грешки.

Накрая, в последната публикация за Istio Service Mesh:

• Ще преминем на Тъмната страна. По-точно, ще учим как да използваме Dark Launch схемата, когато кодът се разгръща и тестовете се провеждат директно на продукционни данни, без да се засяга работата на системата. Тук е от съществено значение умението на Istio да разделя трафика. А възможността да се провеждат тестове на живи продукционни данни, без да се влияе на работата на активната система, е най-убедителният метод за проверка.
• Основавайки се на Dark Launch, ще покажем как да използваме модела Canary Deployment, за да намалим рисковете и улесним внедряването на нов код. Самата Canary Deployment не е новост, но Istio позволява да реализираме тази схема с помощта на съвсем прости YAML файлове.
• В заключение ще покажем как да предоставим достъп до услугите извън вашите клъстери, използвайки Istio Egress, за да активираме възможностите на Istio при работа с интернет.

И така, да започнем…

Инструментариумът за мониторинг и управление на Istio – всичко необходимо за координацията на микросервизите в сервисната мрежа service mesh.

Какво е сервисна мрежа Istio

Сервисната мрежа предоставя на група услуги функции като мониторинг на трафика, контрол на достъпа, откриване, сигурност, устойчивост на откази и много други полезни неща. Istio позволява всичко това без никакви промени в кода на самите услуги. Каква е тайната на магията? Istio свързва всеки сервис със собствен прокси под формата на sidecar контейнер (sidecar – мотоциклетна коляска), след което целият трафик към този сервис минава през проксито, което, спазвайки зададените политики, решава как, кога и дали изобщо този трафик трябва да достигне до услугата. Istio също така предлага възможността за реализиране на напреднали DevOps техники като canary deployments, circuit breakers, fault injection и много други.

Как Istio работи с контейнери и Kubernetes

Сервисната мрежа Istio – това е sidecar реализация на всичко необходимо за създаването и управлението на микросервизи: мониторинг, трасировка, circuit breakers, маршрутизиране, балансиране на натоварването, fault injection, повторения, тайм-аутs, зеркализация, контрол на достъпа, ограничаване на скоростта и много други. И макар днес да съществуват множество библиотеки, които да осигурят тези функции директно в кода, с Istio можете да получите всичко това, без да променяте кода си.

Според модела sidecar, Istio работи в Linux контейнер, който се намира в един Kubernetes-pod с контролираната услуга и инжектира (inject) и извлича (extract) функционалност и информация съгласно зададената конфигурация. Подчертаваме, че това е вашата собствена конфигурация и тя живее извън вашия код. По този начин кодът става значително по-прост и по-кратък.

Както е важно, операционният елемент на микросервисите не е свързан с кода сам по себе си, което означава, че тяхната експлоатация може спокойно да бъде предадена на ИТ специалисти. Защо разработчикът трябва да бъде отговорен за circuit breaker-и и fault injection? Да, трябва да реагира, но да ги обработва и създава? Ако всичко това бъде премахнато от кода, програмистите могат напълно да се фокусират върху приложната функционалност. А самият код ще стане по-кратък и по-прост.

Сервисна мрежа

Istio, който реализира функции за управление на микросервисите извън техния код – това е концепцията на сервисната мрежа Service Mesh. С други думи, това е координирана група от един или няколко бинарника, които образуват мрежа от мрежови функции.

Как Istio работи с микросервиси

Ето как изглежда работата на sidecar контейнери в две с Kubernetes и Minishift от височина на птиците: стартирате инстанция на Minishift, създавате проект за Istio (да го наречем "istio-system"), инсталирате и стартирате всички свързани с Istio компоненти. След това, с създаването на проекти и pod-ове, добавяте конфигурационни данни в своите deployment-и и вашите pod-ове започват да използват Istio. Упростената диаграма изглежда така:

Сега можете да променяте настройките на Istio, за да организирате, например, fault injection, поддръжка Canary разгръщане или други функции на Istio – и всичко това без да засягате кода на самите приложения. Да предположим, че искате да пренасочите целия уеб трафик от потребителите на най-големия си клиент (Foo Corporation) към новата версия на сайта. За целта е достатъчно да създадете правило за маршрутизация Istio, което да търси @foocorporation.com в идентификатора на потребителя и да извърши съответното пренасочване. За всички останали потребители нищо няма да се промени. А вие междувременно ще можете спокойно да тествате новата версия на сайта. И забележете, за целта не е необходимо да ангажирате разработчиците.

И ще трябва да платите много за това?

А, изобщо не. Istio работи доста бързо, написан е на Go и създава съвсем малък оверхед. Освен това, възможната загуба в онлайн производителността се компенсира от увеличението на производителността на разработчиците. Най-малко в теорията: не забравяйте, че времето на разработчиците е скъпо. Що се отнася до разходите за софтуер, Istio е софтуер с отворен код, така че можете да го получите и използвате безплатно.

Научете сами

Екипът на Red Hat Developer Experience Team разработи задълбочено практическо ръководство по Istio (на английски). То работи на Linux, MacOS и Windows, а кодът е наличен на Java и Node.js.

10 интерактивни занятия по Istio

Блок 1 — За начинаещи

Въведение в Istio
30 минути
Запознаваме се с Service Mesh, учим се да инсталираме Istio в Kubernetes клъстера OpenShift.
Започнете

Разгръщане на микросервизи в Istio
30 минути
Използваме Istio, за да разположим три микросервиза с Spring Boot и Vert.x.
Започнете

Блок 2 – средно ниво

Мониторинг и трасировка в Istio
60 минути
Изучаваме встроените инструменти за мониторинг в Istio, настраиваемите метрики, както и OpenTracing чрез Prometheus и Grafana.
Започнете

Проста маршрутизация в Istio
60 минути
Учим се да управляваме маршрутизацията в Istio с помощта на простички правила.
Започнете

Разширени правила за маршрутизация
60 минути
Запознаваме се с умната маршрутизация в Istio, управление на достъпа, балансиране на натоварването и ограничаване на скоростта.
Започнете

Блок 3 – опитен потребител

Fault Injection в Istio
60 минути
Изучаваме сценарии за обработка на неизправности в разпределени приложения, създавайки HTTP грешки и мрежови забавяния, учим се как да прилагаме хаос-инжиниринг за възстановяване на средата.
Започнете

Circuit Breaker в Istio
30 минути
Инсталираме Siege за стрес тестване на сайтове и учим как да осигурим отказоустойчивост на бекенда чрез повторения, circuit breaker и pool ejection.
Започнете

Egress и Istio
10 минути
Използваме Egress маршрути за създаване на правила за взаимодействие на вътрешните услуги с външни API и услуги.
Започнете

Istio и Kiali
15 минути
Учим се да използваме Kiali, за да получим обща представа за сервисната мрежа и да изучим потоките от заявки и данни.
Започнете

Mutual TLS в Istio
15 минути
Създаваме Istio Gateway и VirtualService, след което подробно изучаваме mutual TLS (mTLS) и неговата настройка.
Започнете

Блок 3.1 — Дълбочинно проучване: Istio Service Mesh за микросервизи

За какво е книгата:

• Какво е сервисна мрежа service mesh.
• Системата Istio и нейната роля в микросервизната архитектура.
• Използване на Istio за решаване на следните задачи:
  • Отказоустойчивост;
  • Маршрутизация;
  • Хаос-тестиране;
  • Сигурност;
  • Събиране на телеметрия чрез средства за трасировка, метрики и Grafana.

Свали книга

Серия статии за сервисни мрежи и Istio

• Правила за маршрутизиране на Istio: насочваме сервис-заявките там, където е нужно
• Circuit Breaker-и в Istio: обработваме Pool Ejection
• Circuit Breaker в Istio: когато неуспехът е опция
• Трасировка и мониторинг в Istio: накъде се движи всичко и колко бързо
• Хаос инженерство в Istio: така е било замислено
• Dark Launch в Istio: тайни служби
• Canary Deployment в Istio: опростяване на внедряването
• Istio Egress: изход през сувенирния магазин

Опитайте сами

Тази серия публикации не цели да осигури дълбочинно потапяне в света на Istio. Ние просто искаме да ви запознаем с основната концепция и, може би, да ви вдъхновим да опитате Istio сами. Това може да се направи напълно безплатно, а Red Hat предоставя всички необходими инструменти, за да започнете да овладявате OpenShift, Kubernetes, Linux контейнери и Istio, а именно: Red Hat Developer OpenShift Container Platform, нашето ръководство по Istio и други ресурси на нашия микросайт за Service Mesh. Не отлагайте, започнете още днес!

Правила за маршрутизиране на Istio: насочваме сервис-заявките там, където е нужно

OpenShift и Kubernetes перфектно се справят с насочването на микросервиси към необходимите pod-ове. В това и е една от целите на съществуването на Kubernetes – маршрутизиране и натоварване. А какво, ако се нуждаете от по-фино и сложнo маршрутизиране? Например, за да използвате едновременно две версии на микросервиса. Как тук ще помогнат правилата за маршрутизиране Istio Route Rules?

Правилата за маршрутизиране – това са правилата, които задават избора на маршрут. При всякакво ниво на сложност на системата общият принцип на работа на тези правила остава прост: заявките се маршрутизират на базата на определени параметри и стойности на HTTP заглавията.
Нека да видим примери:

Kubernetes по подразбиране: тривиално "50 на 50"

В нашия пример ще покажем как да използваме две версии на микросервиса в OpenShift, наречени v1 и v2. Всяка версия работи в собствен pod в Kubernetes, и по подразбиране тук работи равномерно балансирана циклична маршрутизация (evenly balanced round robin routing). Всеки pod получава своя дял от заявките според броя на инстанциите на микросервиса, иначе казано, репликите. Istio обаче позволява да се промени това балансиране ръчно.

Да предположим, че сме разположили две версии на нашия препоръчителен сервис на OpenShift - recommendation-v1 и recommendation-v2.
На рис. 1 се вижда, че, когато всеки сървис е представен в един екземпляр, запитванията се редуват равномерно между тях: 1-2-1-2-… Точно така работи маршрутизацията на Kubernetes по подразбиране:

Тежестно разпределение между версиите

На рис. 2 е показано какво ще стане, ако увеличим броя на репликите на сервиса v2 от една на две (това се прави с командата oc scale —replicas=2 deployment/recommendation-v2). Както виждаме, запитванията между v1 и v2 вече се разделят в съотношение "едно към три": 1-2-2-1-2-2-…:

Игнориране на версията с помощта на Istio

Istio позволява лесно да променим разпределението на запитванията по нужния ни начин. Например, да изпращаме целия трафик само на recommendation-v1 с помощта на следния yaml файл Istio:

Тук трябва да се обърне внимание на следното: pod-овете се избират според етикетите. В нашия пример се използва етикетът v1. Параметърът "weight: 100" означава, че 100% от трафика ще се маршрутизира към всички pod-ове на сървиса, които имат етикет v1.

Директивно разпределение между версиите (Canary Deployment)

След това, използвайки параметъра weight, можем да насочим трафика към двата pod-а, игнорирайки броя на екземплярите на микросервизите, стартирани във всеки от тях. Например, тук директивно насочваме 90% от трафика на v1 и 10% – на v2:

Отделна маршрутизация за мобилни потребители

В заключение ще покажем как да принудим маршрутизирането на трафика на мобилни потребители към сервиза v2, а на всички останали – към v1. За целта ще анализираме стойността на user-agent в заглавката на запитването с помощта на регулярни изрази:

Сега е ваш ред

Пример с регулярни изрази за анализ на заглавките трябва да ви мотивира да потърсите свои собствени варианти за приложение на правилата за маршрутизиране на Istio. Тем повече, че възможностите тук са много обширни, тъй като стойностите на заглавките могат да се формират в изходния код на приложенията.

И помнете, че Ops, а не Dev

Всичко, което показахме в примерите по-горе, се прави без никакви промени в изходния код, с изключение на случаите, когато е необходимо да се форматират специални заглавки на запитвания. Istio е полезен както на разработчиците, които, например, могат да го прилагат на етапа на тестване, така и на специалистите по експлоатация на ИТ системи, на които той много ще помогне в продукцията.

Така че, нека повторим основната идея на тази серия от публикации: вие не трябва да променяте нищо в кода си. Няма нужда да събирате нови образи или да стартирате нови контейнери. Всичко това се реализира извън кода.

Включете въображението си

Само си представете какви перспективи отваря анализът на заглавията с помощта на регулярни изрази. Искате ли да пренасочите най-големия си клиент към специална версия на вашите микросервизи? Легко! Нужна отдельная версия для браузера Chrome? Не проблема! Вы можете маршрутизировать трафик практически по любой его характеристике.

Опитайте сами

Четенето за Istio, Kubernetes и OpenShift е едно, но защо да не усетите всичко със собствените си ръце? Екипът Red Hat Developer Program подготви подробно ръководство (на английски), което ще ви помогне да усвоите тези технологии максимално бързо. Ръководството също е 100% open source, затова е налично в отворен достъп. Файлът работи на macOS, Linux и Windows, а изходният код е наличен на Java и node.js (скоро ще има версии и на други езици). Просто отворете съответния git-репозитори в браузъра си Red Hat Developer Demo.

В следващия пост: случваме проблемите красиво

Днес видяхте на какво са способни правилата за маршрутизиране на Istio. А сега си представете всичко същото, но в контекста на обработката на грешки. Именно за това ще говорим в следващия пост.

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