🥇Nazaj k mikrostoritvam z Istio. 1. del

Opomba. prevod: Storitvena omrežja so vsekakor postala relevantna rešitev v sodobni infrastrukturi za aplikacije, ki sledijo mikrostoritveni arhitekturi. Čeprav je Istio morda na ustih mnogih inženirjev DevOps, je dokaj nov izdelek, ki bo morda zahteval precej časa, da se z njim seznanite, čeprav je obsežen v smislu zmogljivosti, ki jih ponuja. Nemški inženir Rinor Maloku, ki je pri telekomunikacijskem podjetju Orange Networks odgovoren za računalništvo v oblaku za velike stranke, je napisal čudovito serijo materialov, ki vam omogočajo hiter in poglobljen potop v Istio. Svojo zgodbo začne s tem, kaj Istio sploh zmore in kako se lahko hitro prepričate na lastne oči.

Istio — Odprtokodni projekt, razvit v sodelovanju z ekipami iz Googla, IBM-a in Lyfta. Rešuje zapletenosti, ki se pojavljajo v aplikacijah, ki temeljijo na mikrostoritvah, kot so:

Upravljanje prometa: časovne omejitve, ponovni poskusi, uravnoteženje obremenitve;
varnost: avtentikacija in avtorizacija končnega uporabnika;
Opazljivost: sledenje, spremljanje, beleženje.

Vse to je mogoče rešiti na aplikativnem nivoju, vendar potem vaše storitve ne bodo več »mikro«. Vsa dodatna prizadevanja za rešitev teh težav so izguba sredstev podjetja, ki bi jih lahko uporabili neposredno za poslovno vrednost. Poglejmo primer:

Vodja projekta: Koliko časa traja dodajanje funkcije za povratne informacije?
Razvijalec: Dva sprinta.

MP: Kaj?.. To je samo CRUD!
R: Izvajanje CRUD je enostaven del, vendar moramo še vedno overiti in avtorizirati uporabnike in storitve. Ker je omrežje nezanesljivo, boste morali izvajati ponavljajoče se zahteve vzorec odklopnika v strankah. Za zagotovitev, da se celoten sistem ne zruši, boste potrebovali časovne omejitve in pregrade (več podrobnosti o obeh omenjenih vzorcih glej v nadaljevanju članka – pribl. prev.), ter za odkrivanje težav, spremljanje, sledenje, […]
MP: Oh, potem samo vstavimo to funkcijo v storitev izdelka.

Mislim, da je ideja jasna: število korakov in truda, potrebnih za dodajanje ene storitve, je ogromno. V tem članku si bomo ogledali, kako Istio odstrani vso zgoraj omenjeno kompleksnost (ki ni mišljena kot poslovna logika) iz storitev.

Obvestilo: Ta članek predvideva, da imate delovno znanje o Kubernetesu. Sicer pa priporočam branje moj uvod v Kubernetes in šele po tem nadaljujte z branjem tega gradiva.

Istio ideja

V svetu brez Istia ena storitev pošlje neposredne zahteve drugi in v primeru okvare mora storitev to rešiti sama: narediti nov poskus, zagotoviti časovno omejitev, odpreti odklopnik itd.

Omrežni promet v Kubernetesu

Istio ponuja specializirano rešitev, ki je popolnoma ločena od storitev in deluje tako, da moti omrežno komunikacijo. In tako izvaja:

toleranca napak: Na podlagi statusne kode v odgovoru razume, ali zahteva ni uspela, in jo znova izvede.
Canary rollouts: preusmeri samo določen odstotek zahtev na novo različico storitve.
Spremljanje in meritve: Koliko časa je trajalo, da se je servis odzval?
Sledenje in opazljivost: vsaki zahtevi doda posebne glave in jih sledi po gruči.
varnost: Pridobi žeton JWT, overi in avtorizira uporabnike.

To je le nekaj možnosti (pravzaprav le nekaj!), ki vas bodo navdušile. Zdaj pa se poglobimo v tehnične podrobnosti!

Istio arhitektura

Istio prestreže ves omrežni promet in zanj uporabi nabor pravil, tako da v vsak sklop vstavi pametni proxy v obliki vsebnika s prikolico. Proxyji, ki aktivirajo vse zmožnosti, tvorijo a Podatkovna ravninain jih je mogoče dinamično konfigurirati z uporabo Nadzorna ravnina.

Podatkovna ravnina

Proxyji, vstavljeni v pode, omogočajo Istiu, da zlahka izpolni zahteve, ki jih potrebujemo. Na primer, preverimo funkcije ponovnega poskusa in odklopnika.

Kako so ponovni poskusi in prekinitev tokokroga implementirani v Envoy

Če povzamem:

Odposlanec (govorimo o proxyju, ki se nahaja v vsebniku stranske prikolice, ki se distribuira kot ločen izdelek — pribl. prev.) pošlje zahtevo prvi instanci storitve B in ne uspe.
Envoy Sidecar poskuša znova (ponovni poskus). (1)
Zahteva ne uspe in se vrne posredniku, ki jo je poklical.
To odpre odklopnik in pokliče naslednjo storitev za nadaljnje zahteve. (2)

To pomeni, da vam ni treba uporabiti druge knjižnice Retry, ni vam treba izdelati lastne implementacije Circuit Breaking in Service Discovery v programskem jeziku X, Y ali Z. Vse to in še veliko več je na voljo takoj po izdelavi. v Istio in ne zahteva ne spremembe v kodi.

Super! Zdaj si morda želite iti na potovanje z Istio, vendar imate še vedno nekaj dvomov, odprtih vprašanj. Če je to univerzalna rešitev za vse priložnosti v življenju, potem imate naravni sum: navsezadnje se vse takšne rešitve v resnici izkažejo za neprimerne za vsak primer.

In končno vprašate: "Ali je prilagodljiv?"

Zdaj ste pripravljeni na potovanje po morju, spoznajmo se s krmilnim letalom.

Nadzorna ravnina

Sestavljen je iz treh komponent: Pilot, Mixer и Citadela, ki skupaj konfigurirata Envoys za usmerjanje prometa, uveljavljanje pravilnikov in zbiranje telemetričnih podatkov. Shematično je vse skupaj videti takole:

Interakcija nadzorne ravnine s podatkovno ravnino

Odposlanci (tj. podatkovna ravnina) so konfigurirani z uporabo Kubernetes CRD (Custom Resource Definitions), ki jih je opredelil Istio in je posebej namenjen za ta namen. Za vas to pomeni, da se zdijo samo še en vir v Kubernetesu z znano sintakso. Ko je ustvarjen, bo ta vir prevzel nadzorni nivo in ga uporabil za odposlance.

Povezava storitev z Istio

Opisali smo odnos Istia do storitev, ne pa obratno: kako so storitve povezane z Istiom?

Iskreno povedano, službe se zavedajo prisotnosti Istia tako kot se ribe zavedajo vode, ko se vprašajo: "Kaj sploh je voda?"

Ilustracija Victoria Dimitrakopoulos: - Kako vam je všeč voda? - Kaj sploh je voda?

Tako lahko vzamete delujočo gručo in po namestitvi komponent Istio bodo storitve, ki se nahajajo v njej, še naprej delovale, po odstranitvi teh komponent pa bo spet vse v redu. Jasno je, da boste v tem primeru izgubili zmožnosti, ki jih ponuja Istio.

Dovolj teorije – prenesimo to znanje v prakso!

Istio v praksi

Istio zahteva gručo Kubernetes z vsaj 4 vCPU-ji in 8 GB RAM-a. Za hitro postavitev gruče in sledenje navodilom iz članka priporočam uporabo Google Cloud Platform, ki novim uporabnikom ponuja brezplačno 300 $.

Ko ustvarite gručo in konfigurirate dostop do Kubernetesa prek pripomočka konzole, lahko Istio namestite prek upravitelja paketov Helm.

Namestitev krmila

Namestite odjemalca Helm v svoj računalnik, kot je opisano v uradna dokumentacija. To bomo uporabili za ustvarjanje predlog za namestitev Istio v naslednjem razdelku.

Namestitev Istio

Prenesite vire Istio iz najnovejša izdaja (izvirna avtorjeva povezava do različice 1.0.5 je spremenjena v trenutno, tj. 1.0.6 - pribl. prev.), ekstrahirajte vsebino v en imenik, ki ga bom odslej imenoval [istio-resources].

Za preprosto prepoznavanje virov Istio ustvarite imenski prostor v gruči K8s istio-system:

$ kubectl create namespace istio-system

Dokončajte namestitev tako, da odprete imenik [istio-resources] in izvaja ukaz:

$ 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

Ta ukaz bo izpisal ključne komponente Istio v datoteko istio.yaml. Standardno predlogo smo prilagodili sebi, tako da smo določili naslednje parametre:

global.mtls.enabled nameščen v false (tj. avtentikacija mTLS je onemogočena - pribl.)za poenostavitev našega postopka zmenkov;
tracing.enabled vključuje sledenje zahtevku z uporabo Jaegerja;
kiali.enabled namesti Kiali v gručo za vizualizacijo storitev in prometa;
grafana.enabled namesti Grafana za vizualizacijo zbranih meritev.

Uporabimo ustvarjene vire z ukazom:

$ kubectl apply -f istio.yaml

Namestitev Istio na gručo je končana! Počakajte, da so vsi podi v imenskem prostoru istio-system bom zmogel Running ali Completedtako, da zaženete spodnji ukaz:

$ kubectl get pods -n istio-system

Zdaj smo pripravljeni na nadaljevanje v naslednjem razdelku, kjer bomo vzpostavili in zagnali aplikacijo.

Arhitektura aplikacije Sentiment Analysis

Uporabimo primer aplikacije mikrostoritve Sentiment Analysis, uporabljene v že omenjenem Uvodni članek v Kubernetes. Je dovolj kompleksen, da pokaže zmožnosti Istia v praksi.

Aplikacijo sestavljajo štiri mikrostoritve:

Orodja SA-Frontend, ki služi sprednjemu delu aplikacije Reactjs;
Orodja SA-spletna aplikacija, ki služi poizvedbam analize razpoloženja;
Orodja SA-Logika, ki izvaja sam analiza razpoloženja;
Orodja SA-povratne informacije, ki od uporabnikov prejema povratne informacije o točnosti analize.

V tem diagramu vidimo poleg storitev tudi Ingress Controller, ki v Kubernetesu usmerja dohodne zahteve do ustreznih storitev. Istio uporablja podoben koncept znotraj svojega Ingress Gatewaya, več podrobnosti o tem pa sledi.

Izvajanje aplikacije s proxyjem iz Istio

Za nadaljnje operacije, omenjene v članku, klonirajte svoje skladišče istio-mojstrstvo. Vsebuje aplikacijo in manifeste za Kubernetes in Istio.

Vstavljanje stranskih prikolic

Vstavljanje se lahko izvede samodejno ali ročno. Če želite samodejno vstaviti zabojnike s prikolico, morate v imenski prostor nastaviti oznako istio-injection=enabled, kar naredite z naslednjim ukazom:

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

Zdaj vsak pod, ki bo nameščen v privzetem imenskem prostoru (default) bo prejel svoj zabojnik s prikolico. Da bi to preverili, razmestimo testno aplikacijo tako, da gremo v korenski imenik repozitorija [istio-mastery] in zagon naslednjega ukaza:

$ 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

Ko smo razmestili storitve, preverimo, ali imajo podi dva vsebnika (s samo storitvijo in njeno stransko prikolico), tako da zaženemo ukaz kubectl get pods in se prepričajte, da pod stolpcem READY določeno vrednost 2/2, ki simbolizira, da oba vsebnika delujeta:

$ 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

Vizualno izgleda takole:

Envoy proxy v enem od pods

Zdaj, ko je aplikacija pripravljena in deluje, bomo morali dovoliti dohodni promet v aplikacijo.

Vhodni prehod

Najboljša praksa za dosego tega (dovoljenje prometa v gruči) je skozi Vhodni prehod v Istio, ki se nahaja na "robu" gruče in omogoča omogočanje funkcij Istio, kot so usmerjanje, uravnoteženje obremenitve, varnost in spremljanje dohodnega prometa.

Komponenta Ingress Gateway in storitev, ki jo posreduje navzven, sta bili nameščeni v gručo med namestitvijo Istio. Če želite izvedeti zunanji naslov IP storitve, zaženite:

$ 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

Še naprej bomo dostopali do aplikacije s tem IP-jem (imenoval ga bom EXTERNAL-IP), zato bomo vrednost za udobje zapisali v spremenljivko:

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

Če poskušate zdaj dostopati do tega IP prek brskalnika, boste prejeli napako Storitev ni na voljo, ker privzeto Istio blokira ves dohodni promet, Prehod še ni definiran.

Vir prehoda

Gateway je CRD (Custom Resource Definition) v Kubernetesu, definiran po namestitvi Istio v gručo in omogoča možnost določanja vrat, protokola in gostiteljev, za katere želimo dovoliti dohodni promet.

V našem primeru želimo dovoliti promet HTTP na vratih 80 za vse gostitelje. Naloga je implementirana z naslednjo definicijo (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:
- "*"

Ta konfiguracija ne potrebuje nobene razlage, razen izbirnika istio: ingressgateway. S tem izbirnikom lahko določimo, za kateri vstopni prehod naj uporabimo konfiguracijo. V našem primeru je to krmilnik Ingress Gateway, ki je bil privzeto nameščen v Istio.

Konfiguracija se uporabi s klicem naslednjega ukaza:

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

Prehod zdaj omogoča dostop do vrat 80, vendar nima pojma, kam usmeriti zahteve. Za to boste potrebovali Navidezne storitve.

Vir VirtualService

VirtualService pove prehodu Ingress, kako naj usmeri zahteve, ki so dovoljene znotraj gruče.

Zahteve za našo aplikacijo, ki prihajajo prek http-prehoda, je treba poslati storitvam sa-frontend, sa-web-app in sa-feedback:

Poti, ki jih je treba konfigurirati z VirtualServices

Poglejmo zahteve, ki jih je treba poslati SA-Frontend:

Natančno ujemanje na poti / je treba poslati na SA-Frontend, da dobite index.html;
Predpone poti /static/* je treba poslati v SA-Frontend, da prejme statične datoteke, ki se uporabljajo v sprednjem delu, kot sta CSS in JavaScript;
Poti, ki se ujemajo z regularnim izrazom '^.*.(ico|png|jpg)$', je treba poslati na SA-Frontend, ker To so slike, prikazane na strani.

Izvedba je dosežena z naslednjo konfiguracijo (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
Pomembne točke:

Ta VirtualService se nanaša na prejete zahteve http-prehod;
В destination Določi se služba, kateri se pošiljajo zahteve.

Obvestilo: Zgornja konfiguracija je shranjena v datoteki sa-virtualservice-external.yaml, ki prav tako vsebuje nastavitve za usmerjanje v SA-WebApp in SA-Feedback, vendar je zaradi jedrnatosti tukaj v članku skrajšan.

Uporabimo VirtualService s klicem:

Obvestilo: Ko porabimo sredstva Istio, Kubernetes API Server ustvari dogodek, ki ga prejme Istio Control Plane, nato pa se nova konfiguracija uporabi za proxy Envoy vsakega poda. Zdi se, da je krmilnik Ingress Gateway še en Envoy, konfiguriran v nadzorni ravnini. Vse to izgleda takole na diagramu:

Konfiguracija Istio-IngressGateway za usmerjanje zahtev

Aplikacija Sentiment Analysis je zdaj na voljo na http://{EXTERNAL-IP}/. Ne skrbite, če dobite status Not Found: Včasih traja nekoliko dlje, da konfiguracija začne veljati in da se predpomnilniki Envoy posodobijo.

Preden nadaljujete, se malo poigrajte z aplikacijo, da ustvarite promet. (njegova prisotnost je potrebna za jasnost pri nadaljnjih dejanjih - pribl. prev.).

Kiali: opazljivost

Za dostop do skrbniškega vmesnika Kiali zaženite naslednji ukaz:

... in odprto http://localhost:20001/, prijava kot admin/admin. Tukaj boste našli številne uporabne funkcije, na primer za preverjanje konfiguracije komponent Istio, vizualizacijo storitev z uporabo informacij, zbranih s prestrezanjem omrežnih zahtev, dobite odgovore na vprašanja »Kdo koga kontaktira?«, »Katera različica storitve doživlja neuspehi?" in tako naprej. Na splošno raziščite zmožnosti Kialija, preden se premaknete na vizualizacijo meritev z Grafano.

Grafana: vizualizacija metrike

Meritve, zbrane v Istio, gredo v Prometheus in so vizualizirane z Grafano. Za dostop do skrbniškega vmesnika Grafana zaženite spodnji ukaz in ga nato odprite http://localhost:3000/:

S klikom na meni Domov zgoraj levo in izbiranje Nadzorna plošča storitve Istio v zgornjem levem kotu začnite s storitvijo sa-web-aplikacijaza ogled zbranih meritev:

Tukaj nas čaka prazna in popolnoma dolgočasna predstava - vodstvo tega ne bo nikoli odobravalo. Ustvarimo majhno obremenitev z naslednjim ukazom:

Zdaj imamo veliko lepše grafe, poleg njih pa čudovita orodja Prometheus za spremljanje in Grafana za vizualizacijo metrik, ki nam bodo omogočile, da spoznamo zmogljivost, zdravje, izboljšave/degradacije storitev skozi čas.

Nazadnje si poglejmo zahteve za sledenje v storitvah.

Jaeger: sledenje

Potrebovali bomo sledenje, ker več kot imamo storitev, težje je priti do vzroka okvare. Poglejmo preprost primer s spodnje slike:

Tipičen primer naključne neuspele zahteve

Zahteva pride, pade - kakšen je razlog? Prvi servis? Ali drugega? Pri obeh so izjeme – poglejmo dnevnike vsakega. Kako pogosto ste se ujeli pri tem? Naše delo je bolj podobno programskim detektivom kot razvijalcem ...

To je pogosta težava v mikrostoritvah in jo rešujejo porazdeljeni sistemi sledenja, v katerih si storitve posredujejo edinstveno glavo, nakar se te informacije posredujejo sistemu sledenja, kjer se primerjajo s podatki zahteve. Tukaj je ilustracija:

TraceId se uporablja za identifikacijo zahteve

Istio uporablja Jaeger Tracer, ki implementira ogrodje OpenTracing API, neodvisno od prodajalca. Do uporabniškega vmesnika Jaeger lahko dostopate z naslednjim ukazom:

Zdaj pa pojdi na http://localhost:16686/ in izberite storitev sa-web-aplikacija. Če storitev ni prikazana v spustnem meniju, prikažite/generirajte dejavnost na strani in posodobite vmesnik. Po tem kliknite na gumb Najdi sledi, ki bo prikazal zadnje sledi - izberite poljubno - prikazale se bodo podrobne informacije o vseh sledeh:

Ta sled kaže:

Zahteva pride istio-ingressgateway (to je prva interakcija z eno od storitev in za zahtevo se generira Trace ID), po kateri prehod pošlje zahtevo storitvi sa-web-aplikacija.
V službi sa-web-aplikacija zahtevo prevzame bočna prikolica Envoy, v razponu se ustvari "otrok" (zato ga vidimo v sledovih) in preusmerjen v vsebnik sa-web-aplikacija. (Razpon - logična enota dela v Jaegerju, ki ima ime, čas začetka operacije in njeno trajanje. Razpone je mogoče ugnezditi in naročiti. Usmerjeni aciklični graf razponov tvori sled. — pribl. prev.)
Tukaj je zahteva obdelana z metodo sentimentAnalysis. Te sledi že ustvari aplikacija, tj. zahtevali so spremembe kode.
Od tega trenutka naprej se sproži zahteva POST sa-logika. Trace ID je treba posredovati iz sa-web-aplikacija.
...

Obvestilo: V 4. koraku mora aplikacija videti glave, ki jih ustvari Istio, in jih posredovati naslednjim zahtevam, kot je prikazano na spodnji sliki:

(A) Istio je odgovoren za posredovanje glav; (B) Storitve so odgovorne za glave

Istio opravi večino dela, ker ... ustvari glave za dohodne zahteve, ustvari nove razpone v vsaki stranski oskrbi in jih posreduje naprej. Vendar pa bo brez dela z glavami znotraj storitev izgubljena celotna pot sledenja zahteve.

Upoštevati je treba naslednje glave:

To ni težka naloga, a poenostaviti njeno izvajanje že obstaja številne knjižnice - na primer v storitvi sa-web-app odjemalec RestTemplate posreduje te glave, če preprosto dodate knjižnici Jaeger in OpenTracing v njegove odvisnosti.

Upoštevajte, da aplikacija Sentiment Analysis prikazuje implementacije v Flask, Spring in ASP.NET Core.

Zdaj, ko je jasno, kaj dobimo takoj (ali skoraj takoj), poglejmo natančno nastavljeno usmerjanje, upravljanje omrežnega prometa, varnost itd.!

Opomba. prevod: Preberite o tem v naslednjem delu gradiva o Istio od Rinorja Malokuja, katerega prevodi bodo v bližnji prihodnosti sledili na našem blogu. POSODOBI (14. marec): Drugi del je že objavljeno.

PS od prevajalca

Preberite tudi na našem blogu:

"Nazaj k mikrostoritvam z Istio": del 2 (usmerjanje, nadzor prometa), 3. del (avtentikacija in avtorizacija);
«Conduit - lahka servisna mreža za Kubernetes»;
«Kaj je storitvena mreža in zakaj jo potrebujem [za aplikacijo v oblaku z mikrostoritvami]?»;
«Ilustriran vodnik za mreženje v Kubernetesu. 1. in 2. del»;
«Kako se je ta zabojnik s prikolico znašel tukaj [v Kubernetesu]?".

Vir: www.habr.com