Серия публикации по 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, повторения, таймаути, огледално копие, контрол на достъпа, ограничаване на скоростта и много други. И докато днес съществуват много библиотеки за реализиране на тези функции директно в кода, с 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 Deployment или други възможности на 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 успешно се справят с насочването на микросервизи към нужните подове. В това е една от целите на Kubernetes – маршрутизиране и балансировка на натоварването. А какво, ако ви трябва по-фина и изискана маршрутизация? Например, за да използвате две версии на микросервиз едновременно. Как тук ще помогнат правилата за маршрутизиране в Istio Route Rules?

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

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

В нашия пример ще покажем как да използвате две версии на микросервиз в OpenShift, наречени v1 и v2. Всяка версия се изпълнява в собствен под на Kubernetes, а по подразбиране тук работи равномерно балансирана циклична маршрутизация (evenly balanced round robin routing). Всеки под получава своя дял заявки в зависимост от броя на неговите инстанции на микросервиза, иначе казано, реплики. 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