Zpět k mikroslužbám s Istio. Část 1

Poznámka. přel.: Servisní sítě se rozhodně staly horkým tématem dnešní infrastruktury pro aplikace využívající architekturu mikroslužeb. Zatímco Istio může být na radaru mnoha inženýrů DevOps, je to docela nový produkt, který, i když je komplexní z hlediska funkcí, které poskytuje, může trvat značné množství času, než se seznámíte. Německý inženýr Rinor Maloku, který má na starosti cloud computing pro velké klienty v telekomunikační společnosti Orange Networks, napsal úžasnou sérii materiálů, které vám umožní rychle a hluboce se ponořit do Istio. Svůj příběh začíná tím, co Istio umí a jak to můžete rychle vidět na vlastní oči.

Stejný — Projekt Open Source, vyvinutý ve spolupráci s týmy společností Google, IBM a Lyft. Řeší složitosti, které vznikají v aplikacích založených na mikroslužbách, jako jsou například:

• řízení provozu: časové limity, opakování, vyrovnávání zátěže;
• zabezpečení: ověřování a autorizace koncového uživatele;
• pozorovatelnost: sledování, monitorování, protokolování.

Všechny je možné řešit na aplikační úrovni, poté však již vaše služby nebudou „mikro“. Veškeré další úsilí o řešení těchto problémů je plýtváním podnikových zdrojů, které by mohly být použity přímo pro obchodní hodnotu. Zvažte příklad:

Projektový manažer: Jak dlouho trvá přidání funkce zpětné vazby?
Vývojář: Dva sprinty.

MP: Cože?.. Je to jen SURO!
R: Provedení CRUD je ta snadná část úkolu, ale stále potřebujeme autentizovat a autorizovat uživatele a služby. Vzhledem k tomu, že síť je nespolehlivá, budete muset implementovat i opakované požadavky vzor jističe v klientech. Také, aby se ujistil, že celý systém nespadl, vyprší časové limity a přepážky (Další podrobnosti o obou zmíněných vzorech naleznete dále v článku.)a za účelem odhalování problémů, monitorování, sledování, […]

MP: Oh, pojďme tedy tuto funkci vložit do služby Produkt.

Myslím, že myšlenka je jasná: množství kroků a úsilí potřebné k přidání jediné služby je obrovské. V tomto článku se podíváme na to, jak Istio odstraňuje ze služeb veškerou výše zmíněnou složitost (na kterou necílí obchodní logika).

Poznámka: Článek předpokládá, že máte pracovní znalosti Kubernetes. Jinak doporučuji k přečtení můj úvod do Kubernetes a teprve poté pokračujte ve čtení tohoto materiálu.

Istio nápad

Ve světě bez Istio jedna služba posílá přímé požadavky na druhou a v případě selhání to musí služba zvládnout sama: provést nový pokus, zajistit časový limit, vypnout jistič atd.

Síťový provoz v Kubernetes

Istio na druhou stranu nabízí specializované řešení, které je zcela oddělené od služeb a funkcí tím, že zasahuje do síťové interakce. A tak implementuje:

• odolnost proti chybám: na základě stavového kódu v odpovědi pochopí, zda požadavek selhal a odešle jej znovu.
• Zavádění Canary: přesměruje pouze pevné procento požadavků na novou verzi služby.
• Monitorování a metriky: jak dlouho trvalo, než služba odpověděla?
• Trasovatelnost a pozorovatelnost: Ke každému požadavku přidá speciální záhlaví a sleduje je v celém clusteru.
• zabezpečení: Načte token JWT, ověří a autorizuje uživatele.

To je jen několik z možností (opravdu jen několik!), které vás zaujmou. Nyní se pojďme ponořit do technických detailů!

Architektura

Istio zachycuje veškerý síťový provoz a aplikuje na něj sadu pravidel, přičemž do každého modulu vkládá inteligentní proxy ve formě kontejneru postranního vozíku. Proxy, které aktivují všechny možnosti, tvoří a Datová rovinaa lze je dynamicky upravovat pomocí Kontrolní letadlo.

Datová rovina

Proxy, které jsou vloženy do podů, umožňují Istio snadno dosáhnout požadavků, které potřebujeme. Zkontrolujme například opakování a funkce jističe.

Jak jsou v Envoy implementovány opakování a přerušení obvodu

Shrnutí:

1. Vyslanec (hovoříme o proxy umístěné v kontejneru postranního vozíku, který je distribuován a jak samostatný produkt - Cca. překlad.) odešle požadavek na první instanci služby B a selže.
2. Envoy Sidecar to zkouší znovu (zkusit znovu). (1)
3. Neúspěšný požadavek je vrácen serveru proxy, který jej zavolal.
4. Tím se otevře jistič a zavolá další službu pro další požadavky. (2)

To znamená, že nemusíte používat další knihovnu Retry, nemusíte vytvářet vlastní implementaci Circuit Breaking a Service Discovery v programovacím jazyce X, Y nebo Z. To vše a ještě více je k dispozici z box v Istio a nevyžaduje ne změny kódu.

Skvělý! Nyní se možná budete chtít vydat na plavbu s Istio, ale stále existují určité pochybnosti, otevřené otázky. Pokud se jedná o univerzální řešení pro všechny příležitosti v životě, pak máte oprávněné podezření: všechna taková řešení se ostatně ve skutečnosti nehodí pro žádný případ.

A nakonec se zeptáte: "Je to přizpůsobitelné?"

Nyní jste připraveni na námořní plavbu - a pojďme se seznámit s Control Plane.

Kontrolní letadlo

Skládá se ze tří složek: Pilot, mixér и Citadela, které společně konfigurují Envoys pro směrování provozu, uplatňování zásad a shromažďování telemetrických dat. Schematicky to celé vypadá takto:

Interakce řídicí roviny s datovou rovinou

Envoys (tj. datová rovina) jsou nakonfigurovány s Kubernetes CRD (Definice vlastních zdrojů) definované společností Istio a speciálně navržené pro tento účel. To pro vás znamená, že jsou jen dalším zdrojem v Kubernetes se známou syntaxí. Jakmile bude tento zdroj vytvořen, bude vyzvednut řídicím letadlem a aplikován na vyslance.

Vztah služeb k Istio

Popsali jsme vztah Istio ke službám, ale ne naopak: jak souvisí služby s Istiem?

Abych byl upřímný, služby vědí o přítomnosti Istio stejně jako ryby vědí o vodě, když se sami sebe ptají: „Co je to vlastně voda?“.

Ilustrace Viktorie Dimitrakopoulosová: Jak se ti líbí voda? - Co je vůbec voda?

Můžete si tedy vzít fungující cluster a po nasazení komponent Istio budou služby v něm nadále fungovat a po odebrání těchto komponent bude zase vše v pořádku. Je jasné, že v tomto případě ztratíte možnosti, které Istio poskytuje.

Dost teorie – pojďme tyto poznatky uvést do praxe!

Istio v praxi

Istio vyžaduje cluster Kubernetes s alespoň 4 dostupnými vCPU a 8 GB RAM. Chcete-li rychle zvednout cluster a postupovat podle pokynů z článku, doporučuji použít platformu Google Cloud, která nabízí nové uživatele zdarma 300 $.

Po vytvoření clusteru a nastavení přístupu ke Kubernetes pomocí konzolového nástroje můžete Istio nainstalovat prostřednictvím správce balíčků Helm.

Instalace helmy

Nainstalujte klienta Helm do počítače, jak je popsáno v oficiální dokumentace. Použijeme jej ke generování šablon pro instalaci Istio v další části.

Instalace

Stáhněte si zdroje Istio z poslední vydání (původní odkaz autora na verzi 1.0.5 byl změněn na aktuální, tj. 1.0.6 - cca překlad), extrahujte obsah do jednoho adresáře, který budu nazývat [istio-resources].

Pro snadnou identifikaci prostředků Istio vytvořte jmenný prostor v clusteru K8s istio-system:

$ kubectl create namespace istio-system

Dokončete instalaci přechodem do adresáře [istio-resources] a spuštění příkazu:

$ 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

Tento příkaz vypíše klíčové komponenty Istio do souboru istio.yaml. Standardní šablonu jsme pro sebe upravili zadáním následujících parametrů:

• global.mtls.enabled nainstalovaný v false (tj. autentizace mTLS je deaktivována – přibližně překlad.)zjednodušit náš proces seznamování;
• tracing.enabled umožňuje sledování požadavků pomocí Jaeger;
• kiali.enabled nainstaluje Kiali do clusteru pro vizualizaci služeb a provozu;
• grafana.enabled nainstaluje Grafana k vizualizaci shromážděných metrik.

Použijte vygenerované prostředky pomocí příkazu:

$ kubectl apply -f istio.yaml

Instalace Istio v clusteru je dokončena! Počkejte, až budou všechny pody ve jmenném prostoru istio-system bude schopen Running nebo Completedspuštěním příkazu níže:

$ kubectl get pods -n istio-system

Nyní jsme připraveni pokračovat na další sekci, kde aplikaci zvedneme a spustíme.

Aplikační architektura analýzy sentimentu

Použijme příklad aplikace mikroslužby Sentiment Analysis použité v již zmíněném Úvodní článek do Kubernetes. Je dostatečně komplexní, aby ukázal možnosti Istio v praxi.

Aplikace se skládá ze čtyř mikroslužeb:

1. Služba SA-Frontend, která slouží front-endové aplikaci na Reactjs;
2. Služba SA WebApp, která slouží k dotazům Analýza sentimentu;
3. Služba SA Logikakterá se sama provádí analýza sentimentu;
4. Služba Zpětná vazba SA, která získává zpětnou vazbu od uživatelů o přesnosti provedené analýzy.

Na tomto diagramu kromě služeb vidíme i Ingress Controller, který v Kubernetes směruje příchozí požadavky na odpovídající služby. Istio používá podobný koncept jako součást Ingress Gateway, podrobnosti budou následovat.

Spuštění aplikace s proxy od Istio

Pro další operace uvedené v článku naklonujte své úložiště istio-mistrovství. Obsahuje aplikaci a manifesty pro Kubernetes a Istio.

Vkládání postranních vozíků

Vložení lze provést automaticky nebo ručně. Chcete-li automaticky vložit kontejnery postranních vozíků, musíte nastavit štítek na jmenný prostor istio-injection=enabled, což se provádí následujícím příkazem:

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

Nyní každý modul, který bude nasazen ve výchozím jmenném prostoru (default) dostane svůj kontejner postranního vozíku. Chcete-li to ověřit, nasaďte testovací aplikaci tak, že přejdete do kořenového adresáře úložiště [istio-mastery] a spuštění následujícího příkazu:

$ 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

Po nasazení služeb zkontrolujte, že pody mají dva kontejnery (se samotnou službou a jejím postranním vozíkem) spuštěním příkazu kubectl get pods a ujistěte se, že pod sloupcem READY specifikovaná hodnota 2/2, což symbolizuje, že oba kontejnery běží:

$ 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

Vizuálně to vypadá takto:

Zmocněnec v jednom z modulů

Nyní, když je aplikace spuštěna, musíme povolit příchozímu provozu vstup do aplikace.

Vstupní brána

Nejlepší postup, jak toho dosáhnout (povolit provoz v clusteru), je prostřednictvím Vstupní brána v Istio, který se nachází na „okraji“ clusteru a umožňuje vám aktivovat funkce Istio, jako je směrování, vyvažování zátěže, zabezpečení a monitorování příchozího provozu.

Komponenta Ingress Gateway a služba, která ji předává směrem ven, byly nainstalovány do clusteru během instalace Istio. Chcete-li zjistit externí IP adresu služby, spusťte:

$ 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

K aplikaci budeme nadále přistupovat pomocí této IP (budu ji označovat jako EXTERNÍ-IP), takže pro usnadnění zapíšeme hodnotu do proměnné:

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

Pokud se nyní pokusíte získat přístup k této IP prostřednictvím prohlížeče, zobrazí se chyba Služba nedostupná, protože ve výchozím nastavení Istio blokuje veškerý příchozí provozdokud nebude definována brána.

Zdroj brány

Brána je CRD (Custom Resource Definition) v Kubernetes, definovaná po instalaci Istio do clusteru a umožňující možnost specifikovat porty, protokol a hostitele, pro které chceme povolit příchozí provoz.

V našem případě chceme povolit HTTP provoz na portu 80 pro všechny hostitele. Problém je realizován následující definicí (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:
- "*"

Tato konfigurace nepotřebuje žádné vysvětlení kromě selektoru istio: ingressgateway. Pomocí tohoto selektoru můžeme určit, na kterou vstupní bránu použít konfiguraci. V našem případě se jedná o řadič Ingress Gateway, který byl standardně nainstalován v Istio.

Konfigurace se použije voláním následujícího příkazu:

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

Brána nyní umožňuje přístup k portu 80, ale netuší, kam směrovat požadavky. K tomu budete potřebovat Virtuální služby.

Zdroj virtuální služby

VirtualService říká Ingress Gateway, jak směrovat požadavky, které jsou povoleny v rámci clusteru.

Požadavky na naši aplikaci přicházející přes http-bránu musí být zaslány na služby sa-frontend, sa-web-app a sa-feedback:

Trasy, které mají být nakonfigurovány pomocí VirtualServices

Zvažte požadavky, které by měly být zaslány SA-Frontend:

• Přesná shoda na cestě / měl by být odeslán do SA-Frontend pro získání index.html;
• Cesty s předponou /static/* měly by být odeslány do SA-Frontend pro získání statických souborů používaných ve frontendu, jako jsou CSS a JavaScript;
• Cesty odpovídající regulárnímu výrazu '^.*.(ico|png|jpg)$', musí být zasláno SA-Frontend, protože Toto jsou obrázky zobrazené na stránce.

Implementace je dosaženo následující konfigurací (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

P'P ° R¶RЅS <Rμ RјRѕRјRμRЅS, S <:

 Tato virtuální služba odkazuje na procházející požadavky http-brána;
 В destination definuje službu, na kterou jsou požadavky zasílány.

Poznámka: Výše ​​uvedená konfigurace je uložena v souboru sa-virtualservice-external.yaml, který obsahuje i nastavení pro směrování do SA-WebApp a SA-Feedback, ale zde v článku byl pro stručnost zkrácen.
Použijte VirtualService voláním:

Poznámka: Když použijeme prostředky Istio, Kubernetes API Server spustí událost, kterou obdrží Istio Control Plane, a poté se nová konfigurace použije na proxy Envoy každého modulu. A kontrolér Ingress Gateway se zdá být dalším vyslancem nakonfigurovaným v Řídicí rovině. To vše vypadá na diagramu takto:


Konfigurace Istio-IngressGateway pro směrování požadavků
Analýza sentimentu je nyní k dispozici na http://{EXTERNAL-IP}/. Nedělejte si starosti, pokud dostanete stav Nenalezeno: někdy trvá trochu déle, než se konfigurace projeví a než se aktualizují mezipaměti Envoy.
Než budete pokračovat, pohrajte si trochu s aplikací, aby generovala provoz (jeho přítomnost je nutná pro přehlednost v následných akcích - cca překlad).
Kiali: pozorovatelnost
Chcete-li se dostat do rozhraní správce Kiali, spusťte následující příkaz:

…a otevřít http://localhost:20001/přihlášením jako admin/admin. Najdete zde mnoho užitečných funkcí, například pro kontrolu konfigurace komponent Istio, vizualizaci služeb z informací shromážděných zachycováním síťových požadavků, získání odpovědí na otázky „Kdo koho kontaktuje?“, „Která verze služby zažívá selhání?" a tak dále. Obecně prozkoumejte možnosti Kiali, než přejdete k vizualizaci metrik pomocí Grafany.

Grafana: vizualizace metrik
Metriky shromážděné v Istio končí v Prometheus a jsou vizualizovány pomocí Grafany. Chcete-li se dostat do administrátorského rozhraní Grafana, spusťte níže uvedený příkaz a poté otevřete http://localhost:3000/:

Kliknutím na nabídku Domů vlevo nahoře a vyberte Panel služeb Istio v levém horním rohu začněte službou sa-web-apppro zobrazení shromážděných metrik:

Zde nás čeká prázdné a zcela nudné představení - toto vedení nikdy neschválí. Vytvořme malou zátěž pomocí následujícího příkazu:

Nyní máme mnohem hezčí grafy a navíc k nim úžasné nástroje Prometheus pro monitoring a Grafana pro vizualizaci metrik, které nám umožní poznávat výkon, zdravotní stav, zlepšování/degradaci služeb v čase.
Nakonec se podívejme na sledování požadavků ve službách.
Jaeger: trasování
Budeme potřebovat trasování, protože čím více služeb máme, tím obtížnější je dostat se k příčině selhání. Podívejme se na jednoduchý případ z obrázku níže:


Typický příklad náhodného neúspěšného požadavku
Žádost přichází, padá - jaký je důvod? První servis? Nebo druhý? V obou existují výjimky - podívejme se na protokoly každého z nich. Jak často jste se při tom přistihli? Naše práce je spíše jako softwaroví detektivové než vývojáři…
Jde o rozšířený problém v mikroslužbách a řeší jej distribuované sledovací systémy, ve kterých si služby navzájem předávají unikátní hlavičku, načež jsou tyto informace přesměrovány do sledovacího systému, kde jsou porovnány s daty požadavku. Zde je ilustrace:


TraceId se používá k identifikaci požadavku
Istio používá Jaeger Tracer, který implementuje na dodavateli nezávislý rámec OpenTracing API. K uživatelskému rozhraní Jaeger se dostanete pomocí následujícího příkazu:

Nyní přejděte na http://localhost:16686/ a vyberte službu sa-web-app. Pokud služba není zobrazena v rozbalovací nabídce, zobrazte/vygenerujte aktivitu na stránce a aktualizujte rozhraní. Poté klikněte na tlačítko Najděte stopy, který zobrazí nejnovější stopy - vyberte libovolné - zobrazí se podrobné informace o všech stopách:

Tato stopa ukazuje:

 Žádost přichází istio-ingressgateway (jedná se o první interakci s jednou ze služeb a pro požadavek je vygenerováno Trace ID), načež brána odešle požadavek službě sa-web-app.
 Ve službě sa-web-app požadavek vyzvedne postranní vozík Envoy, v rozpětí se vytvoří „dítě“ (proto ho vidíme ve stopách) a přesměruje se do kontejneru sa-web-app. (Rozsah - logická jednotka práce v Jaegeru, která má název, čas zahájení operace a dobu jejího trvání. Rozpětí lze vnořovat a řadit. Orientovaný acyklický graf rozpětí tvoří stopu. - Cca. překlad.)
 Zde je požadavek zpracován metodou analýza sentimentu. Tyto stopy jsou již generovány aplikací, tzn. vyžadovali změny kódu.
 Od tohoto okamžiku je spuštěn požadavek POST sa-logika. ID trasování musí být předáno z sa-web-app.
 ...

Poznámka: V kroku 4 by aplikace měla vidět záhlaví vygenerovaná Istio a předat je dalším požadavkům, jak je znázorněno na obrázku níže:


(A) Za předávání záhlaví odpovídá společnost Istio; (B) Služby jsou zodpovědné za hlavičky
Istio dělá většinu práce, protože generuje hlavičky pro příchozí požadavky, vytváří nové rozpětí v každé vedlejší péči a předává je dál. Bez práce s hlavičkami uvnitř služeb však bude úplná cesta trasování požadavku ztracena.
Je třeba vzít v úvahu (přeposlat) následující záhlaví:

Jedná se o jednoduchý úkol, ale pro zjednodušení jeho implementace již existuje mnoho knihoven - například ve službě sa-web-app klient RestTemplate předá tyto hlavičky, pokud jednoduše přidáte knihovny Jaeger a OpenTracing do jeho závislosti.
Všimněte si, že aplikace Sentiment Analysis demonstruje implementace ve Flask, Spring a ASP.NET Core.
Nyní, když je jasné, co z krabice (nebo téměř z krabice) dostáváme, se podíváme na jemné doladění směrování, řízení síťového provozu, zabezpečení a další!
Poznámka. přel.: o tom si přečtěte v další části materiálů o Istiu od Rinora Malokua, jejichž překlady budou v blízké budoucnosti následovat na našem blogu. UPDATE (14. března): Druhá část již zveřejněno.
PS od překladatele
Přečtěte si také na našem blogu:

 "Zpět na mikroslužby s Istio": část 2 (trasování, řízení dopravy), část 3 (ověření a autorizace);
 «Conduit – lehká servisní síť pro Kubernetes";
 «Co je to síť služeb a proč ji potřebuji [pro cloudovou aplikaci s mikroslužbami]?";
 «Ilustrovaný průvodce vytvářením sítí v Kubernetes. Části 1 a 2";
 «Jak se tento kontejner postranního vozíku dostal zde [v Kubernetes]?".

Zdroj: www.habr.com