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

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

Истио — Проект со отворен код развиен во соработка со тимови од Google, IBM и Lyft. Ги решава сложеноста што се јавува во апликациите базирани на микросервис, како што се:

• Управување со сообраќајот: тајмаути, повторувања, балансирање на оптоварување;
• безбедност: автентикација и авторизација на крајниот корисник;
• Забележливост: следење, следење, сеча.

Сето ова може да се реши на ниво на апликација, но после тоа вашите услуги повеќе нема да бидат „микро“. Сите дополнителни напори за решавање на овие проблеми се губење на ресурсите на компанијата кои би можеле директно да се искористат за деловна вредност. Ајде да погледнеме на пример:

Проектен менаџер: Колку време е потребно за да се додаде функција за повратни информации?
Развивач: Два спринта.

МП: Што?.. Тоа е само СУРОВА!
Р: Правењето CRUD е лесен дел, но сепак треба да ги автентицираме и овластиме корисниците и услугите. Бидејќи мрежата е несигурна, ќе треба да имплементирате повторени барања, како и шема на прекинувачот кај клиентите. Исто така, за да бидете сигурни дека целиот систем не паѓа, ќе ви требаат тајмаути и прегради (за повеќе детали за двата споменати модели, видете подоцна во статијата - прибл. превод.), а со цел да се откријат проблеми, следење, следење, […]

МП: О, тогаш само да ја вметнеме оваа функција во услугата за производи.

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

Имајте на ум: Оваа статија претпоставува дека имате работно познавање на Kubernetes. Во спротивно, препорачувам да прочитате мојот вовед во Кубернетес и само после тоа продолжете со читање на овој материјал.

Истио идеја

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

Мрежен сообраќај во Кубернетес

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

• толеранција на грешки: Врз основа на статусната шифра во одговорот, разбира дали барањето не успеа и повторно го извршува.
• Распоредување на канари: пренасочува само фиксен процент од барањата кон новата верзија на услугата.
• Мониторинг и метрика: Колку време ѝ требаше на услугата да одговори?
• Следење и набљудување: Додава посебни заглавија на секое барање и ги следи низ кластерот.
• безбедност: Го презема JWT токенот, ги автентицира и овластува корисниците.

Ова се само неколку од можностите (навистина само неколку!) да ве заинтригира. Сега да се нурнеме во техничките детали!

Истио архитектура

Istio го пресретнува целиот мрежен сообраќај и применува множество правила за него, вметнувајќи паметен прокси во форма на контејнер со странична кола во секоја подлога. Прокси кои ги активираат сите способности формираат a Рамнина на податоци, и тие можат динамички да се конфигурираат користејќи Контролен авион.

Рамнина на податоци

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

Како се спроведуваат повторувањата и прекинувањето на колото во Envoy

Да резимираме:

1. пратеник (зборуваме за прокси лоциран во контејнер за странична кола, кој се дистрибуира како посебен производ - прибл. превод.) испраќа барање до првостепениот сервис Б и не успее.
2. Пратеникот Сајдкар се обидува повторно (обидете се повторно). (1)
3. Барањето не успева и се враќа на полномошникот што го повикал.
4. Ова го отвора прекинувачот и ја повикува следната услуга за последователни барања. (2)

Ова значи дека не мора да користите друга библиотека „Обиди се повторно“, не мора да правите сопствена имплементација на Circuit Breaking и Service Discovery во програмскиот јазик X, Y или Z. Сето ова и многу повеќе е достапно надвор од кутијата во Истио и не бара Нема промени во кодот.

Одлично! Сега можеби ќе сакате да одите на патување со Истио, но сепак имате некои сомнежи, отворени прашања. Ако ова е универзално решение за сите прилики во животот, тогаш имате природно сомневање: на крајот на краиштата, сите такви решенија во реалноста излегуваат како несоодветни за секој случај.

И конечно прашувате: „Дали е приспособливо?

Сега сте подготвени за морското патување, ајде да се запознаеме со Контролниот авион.

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

Се состои од три компоненти: Пилот, Миксер и Цитаделата, кои работат заедно за да ги конфигурираат Пратениците да го насочуваат сообраќајот, да спроведуваат политики и да собираат податоци за телеметрија. Шематски сето тоа изгледа вака:

Интеракција на контролната рамнина со рамнина на податоци

Пратениците (т.е. податочна рамнина) се конфигурираат со користење Kubernetes CRD (Custom Resource Definitions) дефинирани од Istio и специјално наменети за оваа намена. Ова за вас значи дека тие се чини дека се само уште еден ресурс во Кубернетс со позната синтакса. Откако ќе се создаде, овој ресурс ќе биде подигнат од контролната рамнина и ќе се примени на пратениците.

Однос на услуги со Истио

Го опишавме односот на Истио со услугите, но не и обратното: како се поврзани услугите со Истио?

Да бидам искрен, службите се подеднакво свесни за присуството на Истио како и рибите за водата кога ќе се запрашаат: „Што е сепак вода?“

Илустрација Викторија Димитракопулос: - Како ви се допаѓа водата? - Што е воопшто водата?

Така, можете да земете работен кластер и по распоредувањето на компонентите на Istio, услугите лоцирани во него ќе продолжат да работат, а по отстранувањето на овие компоненти, сè ќе биде повторно во ред. Јасно е дека во овој случај ќе ги изгубите можностите што ги дава Истио.

Доста е теорија - ајде да го спроведеме ова знаење во пракса!

Истио во пракса

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

Откако ќе креирате кластер и ќе го конфигурирате пристапот до Kubernetes преку алатката за конзола, можете да инсталирате Istio преку управувачот со пакети Helm.

Инсталација на кормилото

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

Инсталирање на 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 вклучува барање за следење со помош на Јегер;
• kiali.enabled го инсталира Kiali во кластер за да ги визуелизира услугите и сообраќајот;
• grafana.enabled ја инсталира Grafana за да ги визуелизира собраните метрики.

Ајде да ги искористиме генерираните ресурси со командата:

$ kubectl apply -f istio.yaml

Инсталирањето на Istio на кластерот е завршено! Почекајте додека сите парчиња се во именскиот простор istio-system ќе може да Running или Completedсо извршување на командата подолу:

$ kubectl get pods -n istio-system

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

Архитектура на апликацијата за анализа на чувствата

Да го искористиме примерот на апликацијата за микросервис за анализа на чувствата што се користи во веќе споменатото Воведна статија во Кубернетес. Доволно е сложено за да ги покаже можностите на Истио на дело.

Апликацијата се состои од четири микроуслуги:

1. Услуги СА-Фронтенд, кој служи на предниот дел на апликацијата Reactjs;
2. Услуги SA-WebApp, кој служи прашања за анализа на чувствата;
3. Услуги СА-Логика, кој самиот се изведува анализа на чувствата;
4. Услуги SA-Повратна информација, кој добива повратни информации од корисниците за точноста на анализата.

На овој дијаграм, покрај услугите, го гледаме и Ingress Controller, кој во Kubernetes ги насочува дојдовните барања до соодветните услуги. Istio користи сличен концепт во рамките на својот Ingress Gateway, чии повеќе детали ќе следат.

Водење апликација со прокси од Истио

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

Вметнување странични колички

Вметнувањето може да се направи автоматски или со рака. За автоматско вметнување на контејнери на страничната кола, ќе треба да поставите етикета на именскиот простор istio-injection=enabled, што се прави со следнава команда:

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

Сега секоја подлога што ќе биде распоредена во стандардниот именски простор (default) ќе го добие својот бочен контејнер. За да го потврдиме ова, ајде да ја распоредиме апликацијата за тестирање со одење во root директориумот на складиштето [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

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

Пратеник полномошник во еден од мешунките

Сега кога апликацијата е отворена и работи, ќе треба да дозволиме дојдовниот сообраќај да доаѓа во апликацијата.

Влезниот портал

Најдобрата практика за да се постигне ова (дозволи сообраќај во кластерот) е преку Влезниот портал во 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 е 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

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

Важни точки:

 Оваа виртуелна услуга се однесува на барањата што доаѓаат http-портата;
 В destination Се одредува услугата до која се испраќаат барањата.

Имајте на ум: Конфигурацијата погоре е зачувана во датотека sa-virtualservice-external.yaml, кој исто така содржи поставки за рутирање во SA-WebApp и SA-Feedback, но е скратен овде во статијата за краткост.
Ајде да го примениме VirtualService со повик:

Имајте на ум: Кога ги трошиме ресурсите на Istio, серверот API на Kubernetes создава настан што го прима контролната рамнина на Istio, а потоа новата конфигурација се применува на проксите Envoy на секоја подлога. И контролерот Ingress Gateway се чини дека е уште еден пратеник конфигуриран во контролната рамнина. Сето ова изгледа вака на дијаграмот:


Istio-IngressGateway конфигурација за рутирање на барање
Апликацијата за анализа на чувствата сега е достапна на http://{EXTERNAL-IP}/. Не грижете се ако добиете статус Не е пронајден: Понекогаш е потребно малку подолго време за да стапи на сила конфигурацијата и да се ажурира кешот на Envoy.
Пред да продолжите, играјте малку со апликацијата за да генерирате сообраќај. (неговото присуство е неопходно за јасност во следните дејства - прибл. превод.).
Киали: набљудување
За да стигнете до административниот интерфејс на Kiali, извршете ја следнава команда:

... и отворете http://localhost:20001/, најавување како админ/админ. Овде ќе најдете многу корисни функции, на пример, да ја проверите конфигурацијата на компонентите на Istio, да ги визуелизирате услугите користејќи информации собрани од барањата за пресретнување на мрежата, да добиете одговори на прашањата „Кој со кого контактира?“, „Која верзија на услугата ја искусува неуспеси?“ и така натаму. Општо земено, истражете ги можностите на Kiali пред да преминете на визуелизирање на метрика со Grafana.

Графана: визуелизација на метрика
Метриките собрани во Истио одат во Прометеј и се визуелизираат со Графана. За да стигнете до административниот интерфејс Grafana, извршете ја командата подолу и потоа отворете http://localhost:3000/:

Со кликнување на менито Почетна горе лево и избирање Сервисна табла на Istio во горниот лев агол, започнете со услугата sa-веб-апликацијада ги погледнете собраните метрики:

Она што не чека овде е празен и целосно досаден настап - менаџментот никогаш нема да го одобри тоа. Ајде да создадеме мало оптоварување со следнава команда:

Сега имаме многу поубави графикони, а покрај нив, прекрасни алатки Prometheus за следење и Grafana за визуелизирање на метрика кои ќе ни овозможат да научиме за перформансите, здравјето, подобрувањата/деградацијата на услугите со текот на времето.
Конечно, да ги погледнеме барањата за следење во услугите.
Јегер: трасирање
Ќе ни треба трагање бидејќи колку повеќе услуги имаме, толку е потешко да се дојде до причината за неуспехот. Ајде да погледнеме едноставен случај од сликата подолу:


Типичен пример на случајно неуспешно барање
Барањето доаѓа, паѓа - што е причината? Прва услуга? Или вториот? Има исклучоци и во двете - да ги погледнеме дневниците на секоја од нив. Колку често сте се фатиле себеси како го правите ова? Нашата работа е повеќе како софтверски детективи отколку како развивачи...
Ова е вообичаен проблем во микросервисите и се решава со дистрибуирани системи за следење, во кои услугите си пренесуваат единствено заглавие едни на други, по што оваа информација се препраќа до системот за следење, каде што се споредува со податоците за барањето. Еве една илустрација:


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

Сега оди на http://localhost:16686/ и изберете услуга sa-веб-апликација. Ако услугата не е прикажана во паѓачкото мени, прикажете/генерирајте активност на страницата и ажурирајте го интерфејсот. После тоа, кликнете на копчето Најдете траги, кој ќе ги прикаже најновите траги - изберете кој било - ќе се појават детални информации за сите траги:

Оваа трага покажува:

 Барањето доаѓа istio-ingressgateway (ова е прва интеракција со една од услугите, а за барањето се генерира Trace ID), по што портата го испраќа барањето до услугата sa-веб-апликација.
 Во употреба sa-веб-апликација барањето се зема од страната на Емисијата, се создава „дете“ во распонот (затоа го гледаме во трагите) и се пренасочува во контејнерот sa-веб-апликација. (Век - логичка единица на работа во Јегер, која има име, време на започнување на операцијата и времетраење. Распоните може да се вгнездат и нарачаат. Насочен ацикличен график на распони формира трага. - прибл. превод.)
 Овде барањето се обработува по методот сентиментална анализа. Овие траги веќе се генерирани од апликацијата, т.е. тие бараа промени на кодот.
 Од овој момент се покренува барање POST во са-логика. ID на трага мора да се препрати од sa-веб-апликација.
 ...

Имајте на ум: Во чекор 4, апликацијата треба да ги види заглавјата генерирани од Istio и да ги пренесе на следните барања како што е прикажано на сликата подолу:


(А) Istio е одговорен за препраќање заглавија; (Б) Услугите се одговорни за заглавијата
Истио го извршува најголемиот дел од работата бидејќи ... генерира заглавија за дојдовните барања, создава нови распони во секоја страна и ги препраќа. Меѓутоа, без работа со заглавија во услугите, целата патека за трага на барање ќе се изгуби.
Мора да се земат предвид следните заглавија:

Ова не е тешка задача, но веќе постои да се поедностави неговата имплементација многу библиотеки - на пример, во услугата sa-web-app, клиентот RestTemplate ги препраќа овие заглавија ако едноставно ги додадете библиотеките Jaeger и OpenTracing во неговите зависности.
Забележете дека апликацијата за анализа на чувствата демонстрира имплементации во Flask, Spring и ASP.NET Core.
Сега кога е јасно што добиваме од кутијата (или речиси надвор од кутијата), ајде да погледнеме во фино подесено рутирање, управување со мрежниот сообраќај, безбедност итн.!
Забелешка. превод.: Прочитајте за ова во следниот дел од материјалите за Истио од Ринор Малоку, чии преводи ќе следат на нашиот блог во блиска иднина. Ажурирање (14 март): Вториот дел веќе е објавено.
PS од преведувач
Прочитајте и на нашиот блог:

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

Извор: www.habr.com