🥇Назад към микроуслугите с Istio. Част 1

Забележка. превод: Сервизните мрежи определено се превърнаха в гореща тема в днешната инфраструктура за приложения, следващи микросервизна архитектура. Докато Istio може да е на радара на много инженери на DevOps, това е сравнително нов продукт, който, макар и сложен по отношение на функциите, които предоставя, може да отнеме значително време, за да го опознаете. Германският инженер Ринор Малоку, който отговаря за облачните изчисления за големи клиенти в телекомуникационната компания Orange Networks, е написал чудесна поредица от материали, които ви позволяват бързо и задълбочено да се потопите в Istio. Той започва своята история с това какво може Istio и как можете бързо да го видите със собствените си очи.

Истио — Проект с отворен код, разработен в сътрудничество с екипи от Google, IBM и Lyft. Той решава сложността, която възниква в приложения, базирани на микроуслуги, например, като:

управление на трафика: изчакване, повторни опити, балансиране на натоварването;
сигурност: удостоверяване и оторизация на крайния потребител;
наблюдаемост: проследяване, наблюдение, регистриране.

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

Мениджър на проекта: Колко време отнема добавянето на функция за обратна връзка?
Разработчик: Два спринта.

MP: Какво?.. Това е просто ГЛУПОСТ!
R: Правенето на CRUD е лесната част от задачата, но все още трябва да удостоверяваме и оторизираме потребители и услуги. Тъй като мрежата е ненадеждна, ще трябва да приложите повтарящи се заявки, както и модел на прекъсвача в клиентите. Освен това, за да сте сигурни, че цялата система не се е сринала, изчаквания и прегради (Вижте по-нататък в статията за повече подробности относно двата споменати модела.), и за откриване на проблеми, наблюдение, проследяване, […]
MP: О, нека тогава просто поставим тази функция в продуктовата услуга.

Мисля, че идеята е ясна: количеството стъпки и усилия, необходими за добавяне на една услуга, е огромно. В тази статия ще разгледаме как Istio премахва цялата сложност, спомената по-горе (която не е насочена към бизнес логиката) от услугите.

Внимание: Статията предполага, че имате практически познания за Kubernetes. Иначе препоръчвам четене моето въведение в Kubernetes и едва след това продължете да четете този материал.

Istio идея

В свят без Istio една услуга отправя директни заявки към друга и в случай на повреда услугата трябва да се справи сама: да направи нов опит, да осигури таймаут, да отвори прекъсвач и т.н.

Мрежов трафик в Kubernetes

Istio, от друга страна, предлага специализирано решение, което е напълно отделено от услугите и функциите, като пречи на мрежовото взаимодействие. И по този начин прилага:

отказоустойчивост: въз основа на кода на състоянието в отговора, той разбира дали заявката е неуспешна и я изпраща отново.
Canary Rollouts: пренасочва само фиксиран процент от заявките към новата версия на услугата.
Мониторинг и показатели: колко време отне на услугата да отговори?
Проследяване и наблюдаемост: Добавя специални заглавки към всяка заявка и ги проследява в клъстера.
сигурност: Извлича JWT токен, удостоверява и упълномощава потребителите.

Това са само няколко от възможностите (наистина само няколко!), които да ви заинтригуват. Сега нека се потопим в техническите подробности!

Архитектура

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

Равнина на данни

Прокситата, които са вмъкнати в подовете, позволяват на Istio лесно да постигне изискванията, от които се нуждаем. Например, нека проверим повторните опити и функциите на прекъсвача.

Как се изпълняват повторните опити и прекъсването на веригата в Envoy

За да обобщим:

пратеник (говорим за прокси, разположено в контейнер с кош, който се разпространява и как отделен продукт - прибл. превод) изпраща заявка до първата инстанция на услуга B и не успява.
Envoy Sidecar опитва отново (опитай отново). (1)
Неуспешната заявка се връща на проксито, което я е извикало.
Това отваря прекъсвача и извиква следващата услуга за последващи заявки. (2)

Това означава, че не е нужно да използвате библиотеката за следващ повторен опит, не е нужно да правите свое собствено внедряване на прекъсване на веригата и откриване на услуги на езика за програмиране X, Y или Z. Всичко това и още е достъпно от кутия в Istio и не изисква който и да е промени в кода.

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

И накрая питате: „Може ли да се персонализира?“

Сега сте готови за морско пътешествие - и нека се запознаем с контролния самолет.

Контролна равнина

Състои се от три компонента: Пилот, Миксер и Цитадела, които заедно конфигурират Envoys да насочват трафика, да прилагат политики и да събират телеметрични данни. Схематично всичко изглежда така:

Взаимодействие на контролната равнина с равнината на данните

Envoys (т.е. равнина на данни) се конфигурират с Kubernetes CRD (Дефиниции на персонализирани ресурси), определени от Istio и специално проектирани за тази цел. За вас това означава, че те са просто още един ресурс в Kubernetes с познат синтаксис. Веднъж създаден, този ресурс ще бъде взет от контролната равнина и приложен към Envoys.

Връзка на услугите с Istio

Описахме връзката на Istio с услугите, но не и обратното: как услугите са свързани с Istio?

Честно казано, службите знаят за наличието на Istio, както рибите знаят за водата, когато се питат: „Какво всъщност е водата?“

илюстрация Виктория Димитракопулос: Как ви харесва водата? - Какво изобщо е водата?

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

Стига теория - нека приложим тези знания на практика!

Istio на практика

Istio изисква Kubernetes клъстер с поне 4 vCPU и 8 GB налична RAM. За бързо повишаване на клъстера и следване на инструкциите от статията препоръчвам да използвате Google Cloud Platform, която предлага нови потребители безплатно $300.

След като създадете клъстера и настроите достъпа до Kubernetes чрез конзолната помощна програма, можете да инсталирате Istio чрез мениджъра на пакети Helm.

Монтаж на кормилото

Инсталирайте клиента Helm на вашия компютър, както е описано в официална документация. Ще го използваме за генериране на шаблони за инсталиране на Istio в следващия раздел.

Инсталация

Изтеглете ресурси на Istio от най-новата версия (оригиналната авторска връзка към версия 1.0.5 е променена на текущата, т.е. 1.0.6 - прибл. прев.), извлечете съдържанието в една директория, която ще наричам [istio-resources].

За лесно идентифициране на ресурсите на Istio, създайте пространство от имена в клъстера K8s istio-system:

$ kubectl create namespace istio-system

Завършете инсталацията, като отидете до директорията [istio-resources] и изпълнение на командата:

$ helm template install/kubernetes/helm/istio 
  --set global.mtls.enabled=false 
  --set tracing.enabled=true 
  --set kiali.enabled=true 
  --set grafana.enabled=true 
  --namespace istio-system > istio.yaml

Тази команда ще изведе ключовите компоненти на Istio във файл istio.yaml. Променихме стандартния шаблон за себе си, като посочихме следните параметри:

global.mtls.enabled инсталиран в false (т.е. mTLS удостоверяването е деактивирано - прибл. прев.)за да опростим нашия процес на запознанства;
tracing.enabled позволява проследяване на заявки с Jaeger;
kiali.enabled инсталира Kiali в клъстер за визуализиране на услуги и трафик;
grafana.enabled инсталира Grafana за визуализиране на събраните показатели.

Приложете генерираните ресурси с командата:

$ kubectl apply -f istio.yaml

Инсталирането на Istio в клъстера е завършено! Изчакайте, докато всички подове в пространството от имена istio-system ще бъде в състояние Running или Completedкато изпълните командата по-долу:

$ kubectl get pods -n istio-system

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

Архитектура на приложението за анализ на настроението

Нека използваме примера на приложението за микроуслуга Sentiment Analysis, използвано във вече споменатото Въвеждаща статия за Kubernetes. Той е достатъчно сложен, за да покаже на практика възможностите на Istio.

Приложението се състои от четири микроуслуги:

Обслужване SA-Frontend, който обслужва предното приложение на Reactjs;
Обслужване SA уеб приложение, който обслужва заявки за анализ на настроението;
Обслужване SA Логикакоято изпълнява сама анализ на настроенията;
Обслужване SA Обратна връзка, който получава обратна връзка от потребителите за точността на извършения анализ.

В тази диаграма, в допълнение към услугите, виждаме и Ingress Controller, който в Kubernetes насочва входящите заявки към съответните услуги. Istio използва подобна концепция като част от Ingress Gateway, подробности за която ще последват.

Стартиране на приложение с прокси от Istio

За допълнителни операции, споменати в статията, клонирайте вашето хранилище istio-майсторство. Той съдържа приложението и манифестите за Kubernetes и Istio.

Поставяне на кошчета

Може да се направи вмъкване автоматично или на ръка. За автоматично вмъкване на контейнери с кош, трябва да зададете етикета на пространството от имена istio-injection=enabled, което се извършва със следната команда:

$ kubectl label namespace default istio-injection=enabled
namespace/default labeled

Сега всяка група, която ще бъде внедрена в пространството на имената по подразбиране (default) ще получи своя контейнер с кош. За да проверим това, нека внедрим тестово приложение, като отидем в основната директория на хранилището [istio-mastery] и стартиране на следната команда:

$ kubectl apply -f resource-manifests/kube
persistentvolumeclaim/sqlite-pvc created
deployment.extensions/sa-feedback created
service/sa-feedback created
deployment.extensions/sa-frontend created
service/sa-frontend created
deployment.extensions/sa-logic created
service/sa-logic created
deployment.extensions/sa-web-app created
service/sa-web-app created

След като разположите услугите, проверете дали капсулите имат два контейнера (със самата услуга и нейния кош), като изпълните командата kubectl get pods и се уверете, че под колоната READY посочена стойност 2/2, символизиращо, че и двата контейнера работят:

$ kubectl get pods
NAME                           READY     STATUS    RESTARTS   AGE
sa-feedback-55f5dc4d9c-c9wfv   2/2       Running   0          12m
sa-frontend-558f8986-hhkj9     2/2       Running   0          12m
sa-logic-568498cb4d-2sjwj      2/2       Running   0          12m
sa-logic-568498cb4d-p4f8c      2/2       Running   0          12m
sa-web-app-599cf47c7c-s7cvd    2/2       Running   0          12m

Визуално изглежда така:

Пратеник пълномощник в един от подс

Сега, когато приложението е готово и работи, трябва да позволим на входящия трафик да влезе в приложението.

Ingress Gateway

Най-добрата практика за постигане на това (разрешаване на трафик в клъстера) е чрез Ingress Gateway в Istio, който се намира на „ръба“ на клъстера и ви позволява да активирате функции на Istio като маршрутизиране, балансиране на натоварването, сигурност и наблюдение за входящ трафик.

Компонентът Ingress Gateway и услугата, която го препраща навън, бяха инсталирани на клъстера по време на инсталацията на Istio. За да разберете външния IP адрес на услуга, изпълнете:

$ kubectl get svc -n istio-system -l istio=ingressgateway
NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP
istio-ingressgateway   LoadBalancer   10.0.132.127   13.93.30.120

Ще продължим да имаме достъп до приложението, използвайки този IP (ще го наричам EXTERNAL-IP), така че за удобство ще запишем стойността в променлива:

$ EXTERNAL_IP=$(kubectl get svc -n istio-system 
  -l app=istio-ingressgateway 
  -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')

Ако се опитате да получите достъп до този IP през браузър сега, ще получите грешка Service Unavailable, защото по подразбиране Istio блокира целия входящ трафикдокато не бъде дефиниран Gateway.

Ресурс на портала

Gateway е CRD (Custom Resource Definition) в Kubernetes, дефиниран след инсталиране на Istio в клъстер и активиране на възможността за указване на портове, протокол и хостове, за които искаме да разрешим входящ трафик.

В нашия случай искаме да разрешим HTTP трафик на порт 80 за всички хостове. Проблемът се реализира чрез следната дефиниция (http-gateway.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: http-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
- "*"

Тази конфигурация не се нуждае от обяснение, освен за селектора istio: ingressgateway. С този селектор можем да посочим към кой Ingress Gateway да приложим конфигурацията. В нашия случай това е контролерът Ingress Gateway, който е инсталиран по подразбиране в Istio.

Конфигурацията се прилага чрез извикване на следната команда:

$ kubectl apply -f resource-manifests/istio/http-gateway.yaml gateway.networking.istio.io/http-gateway created

Сега шлюзът позволява достъп до порт 80, но няма представа къде да насочва заявките. За това ще ви трябва Виртуални услуги.

Ресурс за виртуална услуга

VirtualService казва на Ingress Gateway как да маршрутизира заявки, които са разрешени в рамките на клъстера.

Заявките към нашето приложение, идващи през http-gateway, трябва да бъдат изпратени до услугите sa-frontend, sa-web-app и sa-feedback:

Маршрути, които трябва да бъдат конфигурирани с VirtualServices

Обмислете заявките, които трябва да бъдат изпратени до SA-Frontend:

Точно съвпадение по пътя / трябва да се изпрати на SA-Frontend, за да получите index.html;
Пътища с префикс /static/* трябва да се изпрати на SA-Frontend, за да получите статични файлове, използвани във фронтенда, като CSS и JavaScript;
Пътища, съответстващи на регулярния израз '^.*.(ico|png|jpg)$', трябва да се изпрати на SA-Frontend, т.к Това са снимките, показани на страницата.

Изпълнението се постига чрез следната конфигурация (sa-virtualservice-external.yaml):

kind: VirtualService metadata: name: sa-external-services spec: hosts: - "*" gateways: - http-gateway # 1 http: - match: - uri: exact: / - uri: exact: /callback - uri: prefix: /static - uri: regex: '^.*.(ico|png|jpg) Важные моменты: Этот VirtualService относится к запросам, приходящим через http-gateway; В destination определяется сервис, куда отправляются запросы. Примечание: Конфигурация выше хранится в файле sa-virtualservice-external.yaml, который также содержит настройки для маршрутизации в SA-WebApp и SA-Feedback, но был сокращён здесь в статье для лаконичности. Применим VirtualService вызовом: $ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml virtualservice.networking.istio.io/sa-external-services created Примечание: Когда мы применяем ресурсы Istio, Kubernetes API Server создаёт событие, которое получает Istio Control Plane, и уже после этого новая конфигурация применяется к прокси-серверам Envoy каждого pod'а. А контроллер Ingress Gateway представляется очередным Envoy, сконфигурированным в Control Plane. Всё это на схеме выглядит так: Конфигурация Istio-IngressGateway для маршрутизации запросов Приложение Sentiment Analysis стало доступным по http://{EXTERNAL-IP}/. Не переживайте, если вы получаете статус Not Found: иногда требуется чуть больше времени для того, чтобы конфигурация вступила в силу и кэши Envoy обновились. Перед тем, как продолжить, поработайте немного с приложением, чтобы сгенерировать трафик (его наличие необходимо для наглядности в последующих действиях — прим. перев.). Kiali : наблюдаемость Чтобы попасть в административный интерфейс Kiali, выполните следующую команду: $ kubectl port-forward $(kubectl get pod -n istio-system -l app=kiali -o jsonpath='{.items[0].metadata.name}') -n istio-system 20001 … и откройте http://localhost:20001/, залогинившись под admin/admin. Здесь вы найдете множество полезных возможностей, например, для проверки конфигурации компонентов Istio, визуализации сервисов по информации, собранной при перехвате сетевых запросов, получения ответов на вопросы «Кто к кому обращается?», «У какой версии сервиса возникают сбои?» и т.п. В общем, изучите возможности Kiali перед тем, как двигаться дальше — к визуализации метрик с Grafana. Grafana: визуализация метрик Собранные в Istio метрики попадают в Prometheus и визуализируются с Grafana. Чтобы попасть в административный интерфейс Grafana, выполните команду ниже, после чего откройте http://localhost:3000/: $ kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=grafana -o jsonpath={.items[0].metadata.name}) 3000 Кликнув на меню Home слева сверху и выбрав Istio Service Dashboard в левом верхнем углу, начните с сервиса sa-web-app, чтобы посмотреть на собранные метрики: Здесь нас ждёт пустое и совершенно скучное представление — руководство никогда такое не одобрит. Давайте же создадим небольшую нагрузку следующей командой: $ while true; do curl -i http://$EXTERNAL_IP/sentiment -H "Content-type: application/json" -d '{"sentence": "I love yogobella"}'; sleep .8; done Вот теперь у нас гораздо более симпатичные графики, а в дополнение к ним — замечательные инструменты Prometheus для мониторинга и Grafana для визуализации метрик, что позволят нам узнать о производительности, состоянии здоровья, улучшениях/деградации в работе сервисов на протяжении времени. Наконец, посмотрим на трассировку запросов в сервисах. Jaeger : трассировка Трассировка нам потребуется, потому что чем больше у нас сервисов, тем сложнее добраться до причины сбоя. Посмотрим на простой случай из картинки ниже: Типовой пример случайного неудачного запроса Запрос приходит, падает — в чём же причина? Первый сервис? Или второй? Исключения есть в обоих — давайте посмотрим на логи каждого. Как часто вы ловили себя за таким занятием? Наша работа больше похожа на детективов программного обеспечения, а не разработчиков… Это широко распространённая проблема в микросервисах и решается она распределёнными системами трассировки, в которых сервисы передают друг другу уникальный заголовок, после чего эта информация перенаправляется в систему трассировки, где она сопоставляется с данными запроса. Вот иллюстрация: Для идентификации запроса используется TraceId В Istio используется Jaeger Tracer, который реализует независимый от вендоров фреймворк OpenTracing API. Получить доступ к пользовательского интерфейсу Jaeger можно следующей командой: $ kubectl port-forward -n istio-system $(kubectl get pod -n istio-system -l app=jaeger -o jsonpath='{.items[0].metadata.name}') 16686 Теперь зайдите на http://localhost:16686/ и выберите сервис sa-web-app. Если сервис не показан в выпадающем меню — проявите/сгенерируйте активность на странице и обновите интерфейс. После этого нажмите на кнопку Find Traces, которая покажет самые последние трейсы — выберите любой — покажется детализированная информация по всем трейсам: Этот трейс показывает: Запрос приходит в istio-ingressgateway (это первое взаимодействие с одним из сервисов, и для запроса генерируется Trace ID), после чего шлюз направляет запрос в сервис sa-web-app. В сервисе sa-web-app запрос подхватывается Envoy sidecar'ом, создаётся «ребёнок» в span'е (поэтому мы видим его в трейсах) и перенаправляется в контейнер sa-web-app. (Span — логическая единица работы в Jaeger, имеющая название, время начало операции и её продолжительность. Span'ы могут быть вложенными и упорядоченными. Ориентированный ациклический граф из span'ов образует trace. — прим. перев.) Здесь запрос обрабатывается методом sentimentAnalysis. Эти трейсы уже сгенерированы приложением, т.е. для них потребовались изменения в коде. С этого момента инициируется POST-запрос в sa-logic. Trace ID должен быть проброшен из sa-web-app. … Примечание: На 4 шаге приложение должно увидеть заголовки, сгенерированные Istio, и передать их в последующие запросы, как показано на изображении ниже: (A) За проброс заголовков отвечает Istio; (B) За заголовки отвечают сервисы Istio делает основную работу, т.к. генерирует заголовки для входящих запросов, создаёт новые span'ы в каждом sidecare'е и пробрасывает их. Однако без работы с заголовками внутри сервисов полный путь трассировки запроса будет утерян. Необходимо учитывать (пробрасывать) следующие заголовки: x-request-id x-b3-traceid x-b3-spanid x-b3-parentspanid x-b3-sampled x-b3-flags x-ot-span-context Это несложная задача, однако для упрощения её реализации уже существует множество библиотек — например, в сервисе sa-web-app клиент RestTemplate пробрасывает эти заголовки, если просто добавить библиотеки Jaeger и OpenTracing в его зависимости. Заметьте, что приложение Sentiment Analysis демонстрирует реализации на Flask, Spring и ASP.NET Core. Теперь, когда стало ясно, что мы получаем из коробки (или почти «из коробки»), рассмотрим вопросы тонко настраиваемой маршрутизации, управления сетевым трафиком, безопасности и т.п.! Прим. перев.: об этом читайте в следующей части материалов по Istio от Rinor Maloku, переводы которых последуют в нашем блоге в ближайшее время. UPDATE (14 марта): Вторая часть уже опубликована. P.S. от переводчика Читайте также в нашем блоге: «Назад к микросервисам вместе с Istio»: часть 2 (маршрутизация, управление трафиком), часть 3 (аутентификация и авторизация); «Conduit — легковесный service mesh для Kubernetes»; «Что такое service mesh и почему он мне нужен [для облачного приложения с микросервисами]?»; «Иллюстрированное руководство по устройству сети в Kubernetes. Части 1 и 2»; «Как этот sidecar-контейнер оказался здесь [в Kubernetes]?». Источник: habr.com

route: - destination: host: sa-frontend # 2 port: number: 80
Важни точки:

Тази VirtualService се отнася до идващи заявки http-шлюз;
В destination дефинира услугата, към която се изпращат заявките.

Внимание: Горната конфигурация се съхранява във файл sa-virtualservice-external.yaml, който също съдържа настройки за маршрутизиране към SA-WebApp и SA-Feedback, но е съкратен тук в статията за краткост.

Приложете VirtualService, като се обадите на:

Внимание: Когато прилагаме ресурси на Istio, API сървърът на Kubernetes задейства събитие, което получава контролната равнина на Istio, и след това новата конфигурация се прилага към проксито Envoy на всеки pod. И контролерът на Ingress Gateway изглежда е друг Envoy, конфигуриран в Control Plane. Всичко това изглежда така на диаграмата:

Istio-IngressGateway конфигурация за маршрутизиране на заявка

Анализът на настроението вече е достъпен на http://{EXTERNAL-IP}/. Не се притеснявайте, ако получите статус Не е намерен: понякога отнема малко повече време, за да влезе в сила конфигурацията и да се актуализират кешовете на Envoy.

Преди да продължите, поиграйте малко с приложението, за да генерирате трафик. (неговото присъствие е необходимо за яснота при последващи действия - прибл. прев.).

Киали: наблюдаемост

За да стигнете до администраторския интерфейс на Kiali, изпълнете следната команда:

…и отворен http://localhost:20001/като влезете като администратор/admin. Тук ще намерите много полезни функции, например за проверка на конфигурацията на компонентите на Istio, визуализиране на услуги от информация, събрана чрез прихващане на мрежови заявки, получаване на отговори на въпросите „Кой с кого се свързва?“, „Коя версия на услугата изпитва провали?" и така нататък. Като цяло, проучете възможностите на Kiali, преди да преминете към визуализиране на показатели с Grafana.

Grafana: визуализация на метрики

Метриките, събрани в Istio, завършват в Prometheus и се визуализират с Grafana. За да стигнете до администраторския интерфейс на Grafana, изпълнете командата по-долу, след което отворете http://localhost:3000/:

Като щракнете върху менюто Начало горе вляво и изберете Табло за управление на услугата Istio в горния ляв ъгъл започнете с обслужване sa-web-приложениеза преглед на събраните показатели:

Тук чакаме празно и напълно скучно представление - ръководството никога няма да одобри това. Нека създадем малък товар със следната команда:

Сега имаме много по-красиви графики и в допълнение към тях прекрасните инструменти Prometheus за наблюдение и Grafana за визуализиране на показатели, които ще ни позволят да научим за производителността, здравословното състояние, подобренията / влошаването на услугите с течение на времето.

И накрая, нека разгледаме проследяването на заявки в услугите.

Йегер: проследяване

Ще ни трябва проследяване, защото колкото повече услуги имаме, толкова по-трудно е да стигнем до причината за повредата. Нека разгледаме един прост случай от снимката по-долу:

Типичен пример за случайна неуспешна заявка

Искането идва, пада - каква е причината? Първи сервиз? Или второ? И в двата има изключения - нека да разгледаме дневниците на всеки. Колко често сте се хващали да правите това? Нашата работа е повече като софтуерни детективи, отколкото като разработчици...

Това е широко разпространен проблем в микроуслугите и се решава чрез разпределени системи за проследяване, в които услугите предават уникален хедър една на друга, след което тази информация се пренасочва към системата за проследяване, където се сравнява с данните от заявката. Ето една илюстрация:

TraceId се използва за идентифициране на заявката

Istio използва Jaeger Tracer, който внедрява независима от доставчика OpenTracing API рамка. Можете да получите достъп до потребителския интерфейс на Jaeger със следната команда:

Сега отидете на http://localhost:16686/ и изберете услуга sa-web-приложение. Ако услугата не се показва в падащото меню, покажете/генерирайте активност на страницата и актуализирайте интерфейса. След това кликнете върху бутона Намерете следи, което ще покаже най-новите следи - изберете произволно - ще се появи подробна информация за всички следи:

Тази следа показва:

Заявката идва istio-ingressgateway (това е първото взаимодействие с една от услугите и се генерира Trace ID за заявката), след което шлюзът изпраща заявката до услугата sa-web-приложение.
В сервиз sa-web-приложение заявката се взима от страничната количка на Envoy, създава се "дете" в span (затова го виждаме в следи) и се пренасочва към контейнера sa-web-приложение. (педя - логическа единица на работа в Jaeger, имаща име, начален час на операцията и нейната продължителност. Обхватите могат да бъдат вложени и подредени. Насочен ацикличен график от участъци образува следа. - прибл. превод)
Тук заявката се обработва от метода анализ на настроенията. Тези следи вече са генерирани от приложението, т.е. изискваха промени в кода.
От този момент се инициира POST заявка са-логика. Trace ID трябва да бъде препратен от sa-web-приложение.
...

Внимание: В стъпка 4 приложението трябва да види заглавките, генерирани от Istio, и да ги предаде на следващите заявки, както е показано на изображението по-долу:

(A) Препращането на заглавието е отговорност на Istio; (B) Услугите отговарят за заглавките

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

Следните заглавки трябва да бъдат взети предвид (препратени):

Това е проста задача, но за да се опрости нейното изпълнение, вече има много библиотеки - например в услугата sa-web-app клиентът RestTemplate препраща тези заглавки, ако просто добавите библиотеките Jaeger и OpenTracing към нейните зависимости.

Имайте предвид, че приложението Sentiment Analysis демонстрира реализации във Flask, Spring и ASP.NET Core.

Сега, когато е ясно какво получаваме от кутията (или почти от кутията), нека да разгледаме фината настройка на маршрутизирането, управлението на мрежовия трафик, сигурността и много други!

Забележка. превод: прочетете за това в следващата част от материалите на Istio от Ринор Малоку, чиито преводи ще последват в нашия блог в близко бъдеще. АКТУАЛИЗАЦИЯ (14 март): Втората част вече публикувани.

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

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

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

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