🥇Späť na mikroslužby s Istio. Časť 1

Poznámka. preklad.: Servisné siete sa určite stali relevantným riešením v modernej infraštruktúre pre aplikácie podľa architektúry mikroslužieb. Aj keď Istio môže byť na perách mnohých inžinierov DevOps, je to celkom nový produkt, ktorý, hoci je komplexný z hľadiska funkcií, ktoré poskytuje, môže vyžadovať značné množstvo času, aby ste sa s ním oboznámili. Nemecký inžinier Rinor Maloku, ktorý je zodpovedný za cloud computing pre veľkých klientov v telekomunikačnej spoločnosti Orange Networks, napísal úžasnú sériu materiálov, ktoré vám umožnia rýchlo a hlboko sa ponoriť do Istio. Svoj príbeh začína tým, čo Istio vo všeobecnosti dokáže a ako to môžete rýchlo vidieť na vlastné oči.

Istio — Open Source projekt vyvinutý v spolupráci s tímami Google, IBM a Lyft. Rieši zložitosti, ktoré vznikajú v aplikáciách založených na mikroslužbách, ako napríklad:

Riadenie dopravy: časové limity, opakovanie, vyrovnávanie záťaže;
zabezpečenia: autentifikácia a autorizácia koncového používateľa;
Pozorovateľnosť: sledovanie, monitorovanie, ťažba dreva.

To všetko sa dá vyriešiť na aplikačnej úrovni, ale potom už vaše služby nebudú „mikro“. Všetka mimoriadna snaha vyriešiť tieto problémy je plytvaním podnikovými zdrojmi, ktoré by sa dali použiť priamo na obchodnú hodnotu. Pozrime sa na príklad:

Projektový manažér: Ako dlho trvá pridanie funkcie spätnej väzby?
Vývojár: Dva šprinty.

MP: Čo?.. Je to len SURO!
R: Robiť CRUD je jednoduchá časť, ale stále potrebujeme autentifikovať a autorizovať používateľov a služby. Keďže sieť je nespoľahlivá, budete musieť implementovať aj opakované požiadavky vzor ističa u klientov. Aby ste sa uistili, že celý systém nepadne, budete potrebovať časové limity a prepážky (podrobnejšie o oboch spomínaných vzoroch nájdete ďalej v článku - cca preklad)a s cieľom odhaliť problémy, monitorovanie, sledovanie, […]
MP: Och, potom vložme túto funkciu do služby Produkt.

Myslím, že myšlienka je jasná: množstvo krokov a úsilia potrebné na pridanie jednej služby je obrovské. V tomto článku sa pozrieme na to, ako Istio odstraňuje všetku zložitosť uvedenú vyššie (ktorá nie je myslená ako obchodná logika) zo služieb.

Poznámka: Tento článok predpokladá, že máte pracovné znalosti Kubernetes. Inak odporúčam prečítať môj úvod do Kubernetes a až potom pokračujte v čítaní tohto materiálu.

Istio nápad

Vo svete bez Istio jedna služba dáva priame požiadavky na druhú a v prípade zlyhania to musí služba zvládnuť sama: urobiť nový pokus, poskytnúť timeout, vypnúť istič atď.

Sieťová prevádzka v Kubernetes

Istio ponúka špecializované riešenie, úplne oddelené od služieb a fungujúce zásahom do sieťovej komunikácie. A tak implementuje:

odolnosť proti chybám: Na základe stavového kódu v odpovedi pochopí, či požiadavka zlyhala a znova ju vykoná.
Zavedenie na Kanárske ostrovy: na novú verziu služby presmeruje iba pevné percento požiadaviek.
Monitorovanie a metriky: Ako dlho trvalo, kým služba odpovedala?
Sledovanie a pozorovateľnosť: Ku každej požiadavke pridáva špeciálne hlavičky a sleduje ich v klastri.
zabezpečenia: Získava token JWT, autentifikuje a autorizuje používateľov.

Toto je len niekoľko možností (naozaj len zopár!), ktoré vás zaujmú. Teraz sa poďme ponoriť do technických detailov!

Architektúra Istio

Istio zachytáva všetku sieťovú prevádzku a aplikuje na ňu súbor pravidiel, pričom do každého modulu vkladá inteligentnú proxy vo forme kontajnera postranného vozíka. Proxy, ktoré aktivujú všetky schopnosti tvoria a Dátová rovinaa možno ich dynamicky konfigurovať pomocou Kontrolná rovina.

Dátová rovina

Proxy vložené do modulov umožňujú Istio jednoducho splniť požiadavky, ktoré potrebujeme. Napríklad skontrolujme funkciu opakovaného pokusu a ističa.

Ako sa v Envoy implementujú opakované pokusy a prerušenie obvodu

Na záver:

vyslanec (hovoríme o proxy umiestnenom v kontajneri postranného vozíka, ktorý je distribuovaný ako samostatný produkt - približne. preklad.) odošle požiadavku na prvú inštanciu služby B a neuspeje.
Envoy Sidecar to skúša znova (skúsiť znova). (1)
Požiadavka zlyhá a vráti sa serveru proxy, ktorý ju zavolal.
Tým sa otvorí istič a zavolá nasledujúcu službu pre ďalšie požiadavky. (2)

To znamená, že nemusíte používať inú knižnicu Retry, nemusíte si robiť vlastnú implementáciu Circuit Breaking and Service Discovery v programovacom jazyku X, Y alebo Z. To všetko a oveľa viac je k dispozícii hneď po vybalení v Istio a nevyžaduje akýkoľvek zmeny v kóde.

Skvelé! Teraz možno budete chcieť ísť na plavbu s Istiom, ale stále máte nejaké pochybnosti, otvorené otázky. Ak je toto univerzálne riešenie pre všetky príležitosti v živote, potom máte prirodzené podozrenie: napokon, všetky takéto riešenia sa v skutočnosti ukážu ako nevhodné pre akýkoľvek prípad.

A nakoniec sa pýtate: "Je to prispôsobiteľné?"

Teraz ste pripravení na námornú plavbu, poďme sa zoznámiť s riadiacim lietadlom.

Kontrolná rovina

Skladá sa z troch komponentov: Pilot, mixér и Citadela, ktoré spolupracujú na konfigurácii Envoys na smerovanie prevádzky, presadzovanie pravidiel a zhromažďovanie telemetrických údajov. Schematicky to celé vyzerá takto:

Interakcia riadiacej roviny s dátovou rovinou

Vyslanci (t. j. dátová rovina) sa konfigurujú pomocou Kubernetes CRD (Definície vlastných zdrojov) definované spoločnosťou Istio a špeciálne určené na tento účel. To pre vás znamená, že sa zdajú byť len ďalším zdrojom v Kubernetes so známou syntaxou. Po vytvorení bude tento zdroj vyzdvihnutý riadiacim lietadlom a aplikovaný na vyslancov.

Vzťah služieb k Istio

Opísali sme vzťah Istio k službám, ale nie naopak: ako súvisia služby s Istiom?

Úprimne povedané, služby si uvedomujú prítomnosť Istio rovnako ako ryby vody, keď sa sami seba pýtajú: "Čo je to vlastne voda?"

ilustrácie Viktória Dimitrakopoulosová: - Ako sa ti páči voda? - Čo je vlastne voda?

Môžete si teda zobrať fungujúci klaster a po nasadení komponentov Istio budú služby v ňom umiestnené naďalej fungovať a po odstránení týchto komponentov bude opäť všetko v poriadku. Je jasné, že v tomto prípade prídete o možnosti, ktoré poskytuje Istio.

Dosť bolo teórie – prenesme tieto poznatky do praxe!

Istio v praxi

Istio vyžaduje klaster Kubernetes s aspoň 4 dostupnými vCPU a 8 GB RAM. Ak chcete rýchlo nastaviť klaster a postupovať podľa pokynov z článku, odporúčam použiť platformu Google Cloud, ktorá ponúka nových používateľov zadarmo 300 dolárov.

Po vytvorení klastra a konfigurácii prístupu ku Kubernetes cez pomôcku konzoly môžete Istio nainštalovať cez správcu balíkov Helm.

Inštalácia prilby

Nainštalujte klienta Helm do počítača, ako je popísané v oficiálna dokumentácia. Použijeme to na generovanie šablón na inštaláciu Istio v ďalšej časti.

Inštalácia Istio

Stiahnite si zdroje Istio z najnovšie vydanie (pôvodný odkaz autora na verziu 1.0.5 bol zmenený na aktuálny, t.j. 1.0.6 - cca preklad.), extrahovať obsah do jedného adresára, ktorý budem odteraz volať [istio-resources].

Ak chcete jednoducho identifikovať prostriedky Istio, vytvorte menný priestor v klastri K8s istio-system:

$ kubectl create namespace istio-system

Dokončite inštaláciu prechodom do adresára [istio-resources] a spustenie prí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 príkaz vypíše kľúčové komponenty Istio do súboru istio.yaml. Upravili sme štandardnú šablónu tak, aby nám vyhovovala, špecifikovali sme nasledujúce parametre:

global.mtls.enabled nainštalovaný v false (t. j. overenie mTLS je vypnuté - približne)zjednodušiť náš proces zoznamovania;
tracing.enabled zahŕňa sledovanie žiadostí pomocou Jaeger;
kiali.enabled inštaluje Kiali do klastra na vizualizáciu služieb a prevádzky;
grafana.enabled nainštaluje Grafana na vizualizáciu zhromaždených metrík.

Využime vygenerované zdroje s príkazom:

$ kubectl apply -f istio.yaml

Inštalácia Istio na klastri je dokončená! Počkajte, kým budú všetky moduly v mennom priestore istio-system budú môcť Running alebo Completedspustením príkazu nižšie:

$ kubectl get pods -n istio-system

Teraz sme pripravení pokračovať v ďalšej časti, kde spustíme aplikáciu.

Architektúra aplikácie Sentiment Analysis

Využime príklad mikroservisnej aplikácie Sentiment Analysis použitej v už spomínanom Úvodný článok do Kubernetes. Je dostatočne komplexný na to, aby ukázal schopnosti Istio v praxi.

Aplikácia pozostáva zo štyroch mikroslužieb:

Služba SA-Frontend, ktorý slúži na frontend aplikácie Reactjs;
Služba SA-WebApp, ktorá slúži na dopyty analýzy sentimentu;
Služba SA-Logic, ktorá sa vykonáva sama analýza sentimentu;
Služba SA-Spätná väzba, ktorá dostáva spätnú väzbu od používateľov o presnosti analýzy.

Na tomto diagrame okrem služieb vidíme aj Ingress Controller, ktorý v Kubernetes smeruje prichádzajúce požiadavky na príslušné služby. Istio používa podobný koncept v rámci svojej brány Ingress, ktorej ďalšie podrobnosti budú nasledovať.

Spustenie aplikácie s proxy od Istio

Pre ďalšie operácie uvedené v článku naklonujte svoje úložisko istio-majstrovstvo. Obsahuje aplikáciu a manifesty pre Kubernetes a Istio.

Vkladanie postranných vozíkov

Vloženie je možné vykonať automaticky alebo ručne. Ak chcete automaticky vložiť kontajnery postranných vozíkov, budete musieť nastaviť štítok pre menný priestor istio-injection=enabled, čo sa vykonáva pomocou nasledujúceho príkazu:

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

Teraz každý modul, ktorý bude nasadený v predvolenom mennom priestore (default) dostane svoj kontajner postranného vozíka. Aby sme to overili, nasaďte testovaciu aplikáciu tak, že prejdete do koreňového adresára úložiska [istio-mastery] a spustenie nasledujúceho prí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 nasadení služieb skontrolujme, že moduly majú dva kontajnery (so samotnou službou a jej postranným vozíkom) spustením príkazu kubectl get pods a uistite sa, že pod stĺpcom READY špecifikovaná hodnota 2/2, čo symbolizuje, že oba kontajnery bežia:

$ 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álne to vyzerá takto:

Vyslanec proxy v jednom z modulov

Teraz, keď je aplikácia spustená, budeme musieť povoliť prichádzajúcu komunikáciu do aplikácie.

Vstupná brána

Najlepšou praxou na dosiahnutie tohto cieľa (povoliť premávku v klastri) je prostredníctvom Vstupná brána v Istio, ktorý sa nachádza na „okraji“ klastra a umožňuje vám aktivovať funkcie Istio, ako je smerovanie, vyrovnávanie záťaže, bezpečnosť a monitorovanie prichádzajúcej prevádzky.

Komponent Ingress Gateway a služba, ktorá ho preposiela externe, boli nainštalované v klastri počas inštalácie Istio. Ak chcete zistiť externú IP adresu služby, spustite:

$ 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 aplikácii budeme naďalej pristupovať pomocou tejto IP (budem ju označovať ako EXTERNÁ-IP), takže pre pohodlie zapíšeme hodnotu do premennej:

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

Ak sa teraz pokúsite získať prístup k tejto IP cez prehliadač, zobrazí sa vám chyba Služba nedostupná, pretože Istio štandardne blokuje všetku prichádzajúcu komunikáciu, Brána ešte nebola definovaná.

Zdroj brány

Brána je CRD (Custom Resource Definition) v Kubernetes, definovaná po nainštalovaní Istio do klastra a umožnením možnosti špecifikovať porty, protokol a hostiteľov, ktorým chceme povoliť prichádzajúcu komunikáciu.

V našom prípade chceme povoliť HTTP prevádzku na porte 80 pre všetkých hostiteľov. Úloha je implementovaná podľa nasledujúcej definície (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:
- "*"

Táto konfigurácia nepotrebuje žiadne vysvetlenie okrem selektora istio: ingressgateway. Pomocou tohto selektora môžeme určiť, na ktorú vstupnú bránu použiť konfiguráciu. V našom prípade ide o ovládač Ingress Gateway, ktorý bol štandardne nainštalovaný v Istio.

Konfigurácia sa aplikuje volaním nasledujúceho príkazu:

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

Brána teraz umožňuje prístup k portu 80, ale netuší, kam smerovať požiadavky. Na to budete potrebovať Virtuálne služby.

Zdroj VirtualService

VirtualService povie Ingress Gateway, ako smerovať požiadavky, ktoré sú povolené v rámci klastra.

Žiadosti do našej aplikácie prichádzajúce cez http-bránu musia byť odoslané do služieb sa-frontend, sa-web-app a sa-feedback:

Trasy, ktoré je potrebné nakonfigurovať pomocou VirtualServices

Pozrime sa na požiadavky, ktoré by mali byť odoslané spoločnosti SA-Frontend:

Presná zhoda na ceste / mali by byť odoslané do SA-Frontend na získanie index.html;
Prednastavené cesty /static/* musia byť odoslané do SA-Frontend, aby ste mohli prijímať statické súbory používané vo frontende, ako sú CSS a JavaScript;
Cesty zodpovedajúce regulárnemu výrazu '^.*.(ico|png|jpg)$', treba zaslať SA-Frontend, pretože Toto sú obrázky zobrazené na stránke.

Implementácia sa dosiahne nasledujúcou konfiguráciou (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
Dôležité body:

Táto virtuálna služba sa vzťahuje na prichádzajúce požiadavky http-brána;
В destination Určuje sa služba, do ktorej sa odosielajú požiadavky.

Poznámka: Vyššie uvedená konfigurácia je uložená v súbore sa-virtualservice-external.yaml, ktorý obsahuje aj nastavenia pre smerovanie v SA-WebApp a SA-Feedback, no tu v článku bol pre stručnosť skrátený.

Aplikujme VirtualService zavolaním:

Poznámka: Keď spotrebujeme zdroje Istio, Kubernetes API Server vytvorí udalosť, ktorú prijme Istio Control Plane, a potom sa nová konfigurácia použije na proxy Envoy každého modulu. A ovládač vstupnej brány sa javí ako ďalší vyslanec nakonfigurovaný v riadiacej rovine. Na diagrame to všetko vyzerá takto:

Konfigurácia Istio-IngressGateway pre smerovanie požiadaviek

Aplikácia Analýza sentimentu je teraz k dispozícii na http://{EXTERNAL-IP}/. Nerobte si starosti, ak dostanete stav Nenájdené: Niekedy to trvá trochu dlhšie, kým sa konfigurácia prejaví a aktualizuje sa vyrovnávacia pamäť Envoy.

Pred pokračovaním sa s aplikáciou trochu pohrajte, aby ste vygenerovali návštevnosť. (jeho prítomnosť je potrebná pre prehľadnosť pri následných úkonoch - cca preklad.).

Kiali: pozorovateľnosť

Ak chcete prejsť do administratívneho rozhrania Kiali, spustite nasledujúci príkaz:

... a otvorte http://localhost:20001/, prihláste sa ako admin/admin. Nájdete tu mnoho užitočných funkcií, napríklad na kontrolu konfigurácie komponentov Istio, vizualizáciu služieb pomocou informácií získaných zo zachytenia sieťových požiadaviek, získanie odpovedí na otázky „Kto koho kontaktuje?“, „Ktorá verzia služby sa nachádza zlyhania?" a tak ďalej. Vo všeobecnosti preskúmajte možnosti Kiali predtým, ako prejdete na vizualizáciu metrík pomocou Grafany.

Grafana: vizualizácia metrík

Metriky zhromaždené v Istio idú do Prometheus a sú vizualizované pomocou Grafany. Ak chcete prejsť do administratívneho rozhrania Grafana, spustite príkaz nižšie a potom ho otvorte http://localhost:3000/:

Kliknutím na ponuku Domov vľavo hore a výber Informačný panel služby Istio v ľavom hornom rohu začnite službou sa-web-appaby ste sa pozreli na zhromaždené metriky:

Čaká nás tu prázdne a úplne nudné predstavenie – toto vedenie nikdy neschváli. Vytvorme malú záťaž pomocou nasledujúceho príkazu:

Teraz máme oveľa krajšie grafy a okrem nich aj úžasné nástroje Prometheus na monitorovanie a Grafana na vizualizáciu metrík, ktoré nám umožnia dozvedieť sa o výkone, zdraví, vylepšeniach / degradácii služieb v priebehu času.

Nakoniec sa pozrime na požiadavky na sledovanie v službách.

Jaeger: sledovanie

Budeme potrebovať sledovanie, pretože čím viac služieb máme, tým ťažšie je dostať sa k príčine zlyhania. Pozrime sa na jednoduchý prípad z obrázku nižšie:

Typický príklad náhodnej neúspešnej požiadavky

Žiadosť prichádza, padá - Aky je dôvod? Prvý servis? Alebo ten druhý? V oboch existujú výnimky - pozrime sa na protokoly každého z nich. Ako často ste sa pri tom pristihli? Naša práca pripomína skôr softvérových detektívov ako vývojárov...

Toto je bežný problém v mikroslužbách a riešia ho distribuované sledovacie systémy, v ktorých si služby navzájom odovzdávajú jedinečnú hlavičku, po ktorej sa tieto informácie preposielajú do sledovacieho systému, kde sa porovnávajú s údajmi požiadavky. Tu je ilustrácia:

TraceId sa používa na identifikáciu požiadavky

Istio používa Jaeger Tracer, ktorý implementuje rámec OpenTracing API nezávislý od dodávateľa. K používateľskému rozhraniu Jaeger sa dostanete pomocou nasledujúceho príkazu:

Teraz prejdite na http://localhost:16686/ a vyberte službu sa-web-app. Ak sa služba nezobrazuje v rozbaľovacej ponuke, zobrazte/vygenerujte aktivitu na stránke a aktualizujte rozhranie. Potom kliknite na tlačidlo Nájsť stopy, ktorý zobrazí najnovšie stopy - vyberte ľubovoľné - zobrazia sa podrobné informácie o všetkých stopách:

Táto stopa ukazuje:

Prichádza žiadosť istio-ingressgateway (ide o prvú interakciu s jednou zo služieb a pre požiadavku sa vygeneruje Trace ID), po ktorej brána odošle požiadavku službe sa-web-app.
V prevádzke sa-web-app požiadavku vyzdvihne postranný vozík Envoy, v rozpätí sa vytvorí „dieťa“ (preto ho vidíme v stopách) a presmeruje sa do kontajnera sa-web-app. (Rozsah - logická jednotka práce v Jaegeri, ktorá má názov, čas začiatku operácie a jej trvanie. Rozpätia môžu byť vnorené a usporiadané. Smerovaný acyklický graf rozpätí tvorí stopu. - približne. preklad.)
Tu je požiadavka spracovaná metódou analýza sentimentu. Tieto stopy sú už generované aplikáciou, t.j. vyžadovali zmeny kódu.
Od tohto momentu sa spustí požiadavka POST sa-logika. ID sledovania musí byť preposlané z sa-web-app.
...

Poznámka: V kroku 4 by mala aplikácia vidieť hlavičky vygenerované Istio a odovzdať ich ďalším požiadavkám, ako je znázornené na obrázku nižšie:

(A) Istio je zodpovedný za preposielanie hlavičiek; (B) Služby sú zodpovedné za hlavičky

Istio robí väčšinu práce, pretože... generuje hlavičky pre prichádzajúce požiadavky, vytvára nové rozpätia v každej vedľajšej starostlivosti a posiela ich ďalej. Bez práce s hlavičkami v rámci služieb sa však stratí úplná cesta sledovania požiadaviek.

Je potrebné vziať do úvahy nasledujúce hlavičky:

Nie je to náročná úloha, ale zjednodušiť jej implementáciu už existuje veľa knižníc - napríklad v službe sa-web-app klient RestTemplate prepošle tieto hlavičky, ak jednoducho pridáte knižnice Jaeger a OpenTracing do jeho závislosti.

Všimnite si, že aplikácia Sentiment Analysis demonštruje implementácie vo Flask, Spring a ASP.NET Core.

Teraz, keď je jasné, čo dostaneme z krabice (alebo takmer z krabice), pozrime sa na vyladené smerovanie, riadenie sieťovej prevádzky, bezpečnosť atď.!

Poznámka. preklad.: Prečítajte si o tom v ďalšej časti materiálov o Istiovi od Rinor Maloku, ktorých preklady budú v blízkej budúcnosti nasledovať na našom blogu. UPDATE (14. marca): druhá časť už bol zverejnený.

PS od prekladateľa

Prečítajte si aj na našom blogu:

"Späť na mikroslužby s Istio": časť 2 (trasovanie, riadenie dopravy), časť 3 (overenie a autorizácia);
«Conduit - ľahká servisná sieť pre Kubernetes»;
«Čo je to sieť služieb a prečo ju potrebujem [pre cloudovú aplikáciu s mikroslužbami]?»;
«Ilustrovaný sprievodca sieťou v Kubernetes. Časti 1 a 2»;
«Ako sa tento kontajner postranného vozíka dostal tu [v Kubernetes]?".

Zdroj: hab.com

Späť k mikroslužbám s Istio. Časť 1