🥇Zpět k mikroservisům s Istio. Část 1

Pozn. přek.: Service mesh je určitě aktuálním řešením v moderní infrastruktuře pro aplikace, které sledují mikroservisní architekturu. Ačkoli je Istio mnohým DevOps inženýrům známé, jedná se o poměrně nový produkt, který, byť složitý z hlediska nabízených možností, může vyžadovat značné úsilí na seznámení. Německý inženýr Rinor Maloku, který odpovídá za cloudová řešení pro velké klienty v telekomunikační společnosti Orange Networks, napsal pozoruhodnou sérii materiálů, které umožňují rychle a hluboce se ponořit do Istio. Svůj příběh začíná tím, co vlastně Istio umí a jak na to lze rychle pohlédnout vlastníma očima.

Istio — open-source projekt vyvinutý ve spolupráci týmů z Google, IBM a Lyft. Řeší složitosti, které se vyskytují v aplikacích založených na mikroservisách, například:

Správa provozu: časové limity, opakování pokusů, vyvažování zátěže;
Bezpečnost: autentizace a autorizace koncového uživatele;
Pozorovatelnost: trasování, monitorování, logování.

Všechny tyto problémy mohou být řešeny na úrovni aplikace, avšak v takovém případě přestanou vaše služby být „mikro“. Veškeré dodatečné úsilí na řešení těchto problémů znamená zbytečné náklady pro firmu, které by mohly být použity přímo pro obchodní hodnoty. Zvažme příklad:

Projektový manažer: Jak dlouho potrvá přidání funkce zpětné vazby?
Vývojář: Dva sprinty.
PM: Co?.. Vždyť to je jen CRUD!
V: Vytvořit CRUD je jednoduchá část úkolu, ale také budeme potřebovat autentizovat a autorizovat uživatele a služby. Protože je síť nespolehlivá, bude nutné implementovat opakované požadavky, a také pattern circuit breaker v klientech. Dále, aby se zajistilo, že celý systém nespadne, budou potřeba časové limity a bulkheads (podrobnosti o obou zmíněných vzorech naleznete později v článku — pozn. překl.), a abychom detekovali problémy, budeme potřebovat monitorování, trasování, […]
PM: Ach, pojďme tedy tuto funkci prostě vložit do služby Product.

Myslím, že myšlenka je jasná: úsilí a kroky, které jsou potřebné k přidání jedné služby, jsou obrovské. V tomto článku se podíváme na to, jak Istio odstraňuje všechny výše zmíněné komplikace (které nejsou cílové pro obchodní logiku) ze služeb.

Poznámka: Článek předpokládá, že máte praktické znalosti o Kubernetes. Jinak doporučuji přečíst si moje úvod do Kubernetes a teprve poté pokračovat ve čtení tohoto materiálu.

Myšlenka Istio

Ve světě bez Istio jeden servis provádí přímé dotazy k druhému, a v případě selhání se služba musí sama s ním vypořádat: provést nový pokus, předpokládat časový limit, otevřít circuit breaker atd.

Síťový provoz v Kubernetes

Istio však nabízí specializované řešení, které je zcela oddělené od služeb a funguje zasahováním do síťové komunikace. A tímto způsobem realizuje:

Odolnost proti výpadkům: Na základě kódu stavu v odpovědi chápe, zda došlo k selhání dotazu, a znovu ho provádí.
Kanárkové nasazení: Přesměrovává na novou verzi služby pouze fixní procento dotazů.
Monitoring a metriky: Za jak dlouho služba odpověděla?
Sledování a observabilita: Přidává speciální hlavičky do každého dotazu a provádí jejich sledování v clusteru.
Bezpečnost: Extrahuje JWT token, autentizuje a autorizuje uživatele.

To je jen několik možností (opravdu jen některé!), abych vás zaujmul. A teď se pojďme ponořit do technických podrobností!

Architektura Istio

Istio zachycuje veškerý síťový provoz a aplikuje na něj soubor pravidel, přičemž do každého podu vkládá chytrý proxy ve formě sidecar kontejneru. Proxy, které aktivují všechny funkce, tvoří Data Plane, a mohou být dynamicky konfigurovány pomocí Control Plane.

Data Plane

Vkládané proxy do podů umožňují Istio snadno splnit požadované požadavky. Například zkontrolujme funkce opakovaných pokusů a circuit breaker.

Jak jsou retries a circuit breaking realizovány v Envoy

Shrňme to:

Envoy (hovoříme o proxy, která se nachází v sidecar kontejneru, který se šíří a jako samostatný produkt — pozn. překl.) odesílá dotaz prvnímu instance služby B a dojde k selhání.
Envoy Sidecar se pokouší o opakování (retry). (1)
Dotaz se selháním se vrací volajícímu proxy.
Takto se otevírá Circuit Breaker a dochází k volání další služby pro následující požadavky. (2)

To znamená, že nebudete muset používat další knihovnu Retry, nebudete muset vytvářet svou vlastní implementaci Circuit Breaking a Service Discovery v programovacím jazyce X, Y nebo Z. To vše a mnohem více je k dispozici přímo v Istio a nevyžaduje žádné změny v kódu.

Skvěle! Nyní se můžete vydat na cestu s Istio, ale stále máte nějaké pochybnosti a otevřené otázky. Pokud je to univerzální řešení pro všechny případy, vyvstává přirozený podezření: vždyť taková řešení se ve skutečnosti ukážou jako nevhodná pro jakoukoli situaci.

A nyní se konečně zeptáte: „Dá se to nastavit?“

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

Control Plane

Skládá se ze tří komponentů: Pilot, Mixer a Citadel, — které společně nastavují Envoy na směrování provozu, uplatňují politiky a shromažďují telemetrická data. Schématicky to vypadá takto:

Interakce Control Plane a Data Plane

Envoy (tj. data plane) jsou nakonfigurovány pomocí Kubernetes CRD (Custom Resource Definitions), které stanovuje Istio a jsou speciálně určené pro tento účel. Pro vás to znamená, že se představují jako další zdroj v Kubernetes s tím známým syntaxem. Po vytvoření bude tento zdroj vybrán control plane a aplikován na Envoy.

Vztah služeb k Istio

Odmítli jsme vztah Istio k službám, ale co naopak: jak se služby vztahují k Istio?

Upřímně řečeno, o přítomnosti Istio vědí služby tak dobře, jako ryby — o vodě, když se ptají samy sebe: „Co vlastně je voda?“.

Ilustrace Victoria Dimitrakopoulos: — Jak vám chutná voda? — Co vlastně je voda?

Takže můžete vzít pracovní klastr a po nasazení komponent Istio služby, které se v něm nacházejí, budou i nadále pracovat a po odstranění těchto komponent — znovu bude vše v pořádku. Samozřejmě, že při tom přijdete o možnosti poskytované Istio.

Dost teorie — pojďme přenést tyto znalosti do praxe!

Istio v praxi

Istio vyžaduje klastr Kubernetes, ve kterém je minimálně dostupných 4 vCPU a 8 GB RAM. Aby se rychle zprovoznil klastr a následovalo se pokyny z článku, doporučuji využít Google Cloud Platform, která nabízí novým uživatelům bezplatné $300.

Po vytvoření klastru a nastavení přístupu k Kubernetes pomocí příkazové řady můžete nainstalovat Istio prostřednictvím správce balíčků Helm.

Instalace Helmu

Nainstalujte klienta Helmu na svém počítači, jak je popsáno v oficiální dokumentaci. Ten budeme používat k generování šablon pro instalaci Istio v následující části.

Instalace Istio

Stáhněte si zdroje Istio z nejnovějšího vydání (původní autorova odkaz na verzi 1.0.5 byl upraven na aktuální, tj. 1.0.6 — pozn. překl.), extrahujte obsah do jedné složky, kterou budu dále nazývat [istio-resources].

Pro jednoduchou identifikaci zdrojů Istio vytvořte v K8s klastru prostor názvů istio-system:

$ kubectl create namespace istio-system

Dokončete instalaci přechodem do adresáře [istio-resources] a spuštěním 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 výstupní klíčové komponenty Istio do souboru istio.yaml. Změnili jsme standardní šablonu podle svých potřeb a uvedli následující parametry:

global.mtls.enabled nastaven na false (tj. mTLS autentizace je vypnuta — pozn. překl.), aby se usnadnil náš proces seznámení;
tracing.enabled povoluje sledování požadavků pomocí Jaeger;
kiali.enabled instaluje Kiali do klastru pro vizualizaci služeb a provozu;
grafana.enabled instaluje Grafana pro vizualizaci shromážděných metrik.

Použijeme vygenerované zdroje příkazem:

$ kubectl apply -f istio.yaml

Instalace Istio do klastru byla dokončena! Počkejte, až budou všechny pod' v prostoru názvů istio-system v běhu Dokončeno nebo , a to provedením následujícího příkazu:$ kubectl get pods -n istio-system

Nyní jsme připraveni pokračovat v následující části, kde spustíme aplikaci.

Architektura aplikace Sentiment Analysis

Využijeme příklad mikroslužbové aplikace Sentiment Analysis, použitý v již zmiňovaném

článku o úvodu do Kubernetes. Je dostatečně složité, aby ukázalo možnosti Istio v praxi.Aplikace se skládá ze čtyř mikroslužeb:

Služba

SA-Frontend , která obsluhuje frontend aplikace na Reactjs;SA-WebApp
SA-Frontend , která obsluhuje požadavky Sentiment Analysis;SA-Logic
SA-Frontend , která provádí samotnouanalýzu sentimentu; SA-Feedback;
SA-Frontend , která získává od uživatelů zpětnou vazbu o přesnosti provedené analýzy., který získává od uživatelů zpětnou vazbu o přesnosti provedené analýzy.

Na této schématu kromě služeb vidíme také Ingress Controller, který v Kubernetes směruje příchozí dotazy na odpovídající služby. V Istio se používá podobný koncept v rámci Ingress Gateway, podrobnosti o kterém následují.

Spuštění aplikace s proxy od Istio

Pro další operace zmíněné v článku si naklonujte repozitář istio-mastery. Obsahuje aplikaci a manifesty pro Kubernetes a Istio.

Vkládání sidecarů

Vkládání může být provedeno automaticky nebo ručně. Pro automatické vkládání sidecar kontejnerů je potřeba nastavit prostoru jmen štítek 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ý pod, který bude nasazen v prostoru jmen výchozí (default) dostane svůj sidecar kontejner. Abychom se ujistili, že tomu tak je, nasadíme testovací aplikaci tím, že přejdeme do kořenového adresáře repozitáře [istio-mastery] a provedeme následující příkaz:

$ 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

Rozmístěním služeb zkontrolujeme, že pod'y mají dva kontejnery (s samotnou službou a jejím sidecarem), provedeme příkaz kubectl get pods a ujistíme se, že pod sloupec READY uvádí hodnotu 2/2, symbolizující, ž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

Vizualizace to vypadá takto:

Proxy Envoy v jednom z pod'ů

Nyní, když je aplikace spuštěná a funkční, musíme povolit příchozímu provozu vstupovat do aplikace.

Ingress Gateway

Nejlepší praxí, jak toho dosáhnout (povolit provoz ve clusteru) — je přes Ingress Gateway v Istio, které se nachází na 'hranici' clusteru a umožňuje zahrnout pro příchozí provoz takové funkce Istio, jako je směrování, vyvažování zátěže, zabezpečení a monitoring.

Komponent Ingress Gateway a služba, která ji přesměrovává ven, byly nainstalovány do clusteru během instalace Istio. Abyste zjistili externí IP adresu služby, použijte:

$ 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 se budeme odkazovat pomocí této IP adresy (od nynějška ji budu nazývat EXTERNAL-IP), takže pro pohodlí uložíme 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 navštívit tuto IP adresu v prohlížeči, obdržíte chybu Service Unavailable, protože ve výchozím nastavení Istio blokuje celý příchozí provoz, dokud není definován Gateway.

Zdrojem Gateway

Gateway je CRD (Custom Resource Definition) v Kubernetes, definovaný po instalaci Istio v klastru, který aktivuje možnost specifikovat porty, protokoly 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. Úkol se realizuje následujícím definováním (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:
- "*"

Taková konfigurace nepotřebuje vysvětlení kromě selektoru istio: ingressgateway. Pomocí tohoto selektoru můžeme určit, k jakému Ingress Gateway se konfigurace aplikuje. V našem případě je tímto kontrolerem Ingress Gateway, který byl ve výchozím nastavení nainstalován v Istio.

Konfigurace se aplikuje zavoláním následujícího příkazu:

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

Nyní gateway povoluje přístup na port 80, ale nemá představu o tom, kam směrovat požadavky. K tomu budou potřeba Virtual Services.

Zdrojem VirtualService

VirtualService určuje Ingress Gateway, jak směrovat požadavky, které jsou povoleny uvnitř klastru.

Požadavky na naši aplikaci, které přicházejí přes http-gateway, by měly být odeslány na služby sa-frontend, sa-web-app a sa-feedback:

Trasy, které je třeba nastavit pomocí VirtualServices

Pojďme se podívat na požadavky, které by měly být směrovány na SA-Frontend:

Přesná shoda cesty / by měla být odeslána na SA-Frontend pro získání index.html;
Cesty s prefixem /static/* by měly být odeslány na SA-Frontend pro získání statických souborů používaných na front-endu, jako jsou CSS a JavaScript;
Cesty splňující regulární výraz '^.*\.(ico|png|jpg)$', by měly být odeslány na SA-Frontend, protože se jedná o obrázky zobrazované na stránce.

Implementace se dosahuje 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) Důležité body: Tento VirtualService se vztahuje na požadavky přicházející přes http-gateway; V cílová destinace je definován službou, kam jsou odesílány dotazy. Poznámka: Konfigurace výše je uložena v souboru sa-virtualservice-external.yaml, který také obsahuje nastavení pro směrování v SA-WebApp a SA-Feedback, ale byl zde zkrácen pro stručnost. Aplikujeme VirtualService zavoláním: $ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml virtualservice.networking.istio.io/sa-external-services vytvořen Poznámka: Když aplikujeme zdroje Istio, Kubernetes API Server vytvoří událost, kterou přijímá Istio Control Plane, a teprve poté se nová konfigurace aplikuje na proxy servery Envoy každého podu. A kontrolér Ingress Gateway se představuje jako další Envoy, který je nakonfigurován v Control Plane. Vše to na schématu vypadá takto: Konfigurace Istio-IngressGateway pro směrování dotazů Aplikace Sentiment Analysis je dostupná na http://{EXTERNAL-IP}/. Nemějte obavy, pokud dostáváte status Not Found: někdy to trvá o něco déle, než konfigurace nabude účinnosti a mezipaměti Envoy se obnovení. Před pokračováním, proveďte trochu práce s aplikací, abyste vygenerovali provoz (jeho přítomnost je nezbytná pro jasnost v následujících akcích — pozn. překl.). Kiali: sledovatelnost Abyste se dostali do administrativního rozhraní Kiali, spusťte následující příkaz: $ kubectl port-forward $(kubectl get pod -n istio-system -l app=kiali -o jsonpath='{.items[0].metadata.name}') -n istio-system 20001 … a otevřete http://localhost:20001/, přihlášením jako admin/admin. Zde najdete mnoho užitečných funkcí, například pro kontrolu konfigurace komponent Istio, vizualizaci služeb na základě informací shromážděných při odchytu síťových požadavků, odpovědi na otázky "Kdo se na koho obrací?", "U které verze služby dochází k selhání?" apod. Obecně prozkoumejte možnosti Kiali, než se posunete dál — k vizualizaci metrik s Grafana. Grafana: vizualizace metrik Metriky shromážděné v Istio putují do Prometheus a jsou vizualizovány pomocí Grafana. Abyste se dostali do administrativního rozhraní Grafana, spusťte níže uvedený příkaz, a poté otevřete 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 Kliknutím na menu Home vlevo nahoře a výběrem Istio Service Dashboard v levém horním rohu, začněte se službou sa-web-app, abyste se podívali na shromážděné metriky: Zde na nás čeká prázdné a naprosto nudné zobrazení — příručka by to nikdy neschválila. Vytvořme tedy malou zátěž následujícím příkazem: $ while true; do curl -i http://$EXTERNAL_IP/sentiment -H "Content-type: application/json" -d '{"sentence": "Miluji yogobellu"}'; sleep .8; done Nyní máme mnohem hezčí grafy a navíc skvělé nástroje Prometheus pro monitorování a Grafana pro vizualizaci metrik, které nám umožní sledovat výkon, stav zdraví a zlepšení/degradaci výkonu služeb v čase. Nakonec se podíváme na trasování požadavků ve službách. Jaeger: trasování Trasování potřebujeme, protože čím více máme služeb, tím obtížnější je zjistit příčinu selhání. Podívejme se na jednoduchý případ na obrázku níže: Typický příklad náhodného neúspěšného požadavku Požadavek přichází, a selhává — v čem je problém? První služba? Nebo druhá? Výjimky jsou v obou — podívejme se na logy každé z nich. Jak často se vás to stalo? Naše práce je spíše jako detektivní práce v oblasti softwaru, než jako vývojáři… To je běžný problém v mikroslužbách a řeší se distribuovanými trasovacími systémy, ve kterých si služby předávají jedinečný identifikátor, po němž je tato informace přesměrována do trasovacího systému, kde se porovnává s daty požadavku. Zde je ilustrace: Pro identifikaci požadavku se používá TraceId V Istio se používá Jaeger Tracer, který realizuje framework OpenTracing API nezávislý na dodavatelích. Přístup k uživatelskému rozhraní Jaeger můžete získat následujícím příkazem: $ kubectl port-forward -n istio-system $(kubectl get pod -n istio-system -l app=jaeger -o jsonpath='{.items[0].metadata.name}') 16686 Nyní přejděte na http://localhost:16686/ a vyberte službu sa-web-app. Pokud služba není zobrazena v rozbalovací nabídce — vyvolejte/simulujte činnost na stránce a obnovte rozhraní. Poté klikněte na tlačítko Najít trasování, které ukáže nejnovější trasy — vyberte libovolný — zobrazí se podrobné informace o všech trasách: Tato trasa ukazuje: Požadavek přichází do istio-ingressgateway (to je první interakce s jednou ze služeb, a pro požadavek je generován Trace ID), poté brána směruje požadavek do služby sa-web-app. Ve službě sa-web-app je požadavek zachycen Envoy sidecarem, je vytvořen "potomek" ve spaně (proto ho vidíme v trasách) a přesměrován do kontejneru sa-web-app. (Span — logická jednotka práce v Jaegeru, která má název, čas zahájení operace a její trvání. Span mohou být vnořené a seřazené. Orientovaný acyklický graf ze spanů tvoří trace. — pozn. překl.) Zde je požadavek zpracován metodou sentimentAnalysis. Tyto trasy již byly vygenerovány aplikací, tj. pro ně bylo nutné provést změny v kódu. Od tohoto okamžiku je iniciován POST požadavek na sa-logic. Trace ID musí být předán z sa-web-app. … Poznámka: Ve 4. kroku by aplikace měla vidět hlavičky vygenerované Istio a předat je do následujících požadavků, jak je znázorněno na obrázku níže: (A) Za předávání hlaviček odpovídá Istio; (B) Za hlavičky odpovídají služby Istio vykonává hlavní práci, neboť generuje hlavičky pro příchozí požadavky, vytváří nové span v každém sidecaru a předává je. Bez práce s hlavičkami uvnitř služeb bude celý sledovací proces požadavku ztracen. Je třeba zohlednit (předat) následující hlavičky: x-request-id x-b3-traceid x-b3-spanid x-b3-parentspanid x-b3-sampled x-b3-flags x-ot-span-context Je to jednoduchý úkol, avšak pro usnadnění jeho realizace již existuje mnoho knihoven — například ve službě sa-web-app klient RestTemplate předává tyto hlavičky, pokud pouze přidáme knihovny Jaeger a OpenTracing do jejich závislostí. Všimněte si, že aplikace Sentiment Analysis demonstruje realizace na Flasku, Springu a ASP.NET Core. Nyní, když je jasné, co získáváme „z krabice“ (nebo téměř „z krabice“), podívejme se na otázky jemně konfigurovatelného směrování, správy síťového provozu, bezpečnosti atd.! Pozn. přek.: o tom si přečtěte v další části materiálů k Istio od Rinora Maloku, jejichž překlady budou následovat na našem blogu v blízké době. AKTUALIZACE (14. března): Druhá část už byla zveřejněna. P.S. od překladatele Přečtěte si také náš blog: „Zpět k mikroslužbám s Istio“: část 2 (směrování, správa provozu), část 3 (autentizace a autorizace); «Conduit — lehký service mesh pro Kubernetes»; «Co je service mesh a proč ho potřebuji [pro cloudovou aplikaci s mikroslužbami]?»; «Ilustrovaný průvodce fungováním sítě v Kubernetes. Části 1 a 2»; «Jak se tento sidecar kontejner dostal sem [do Kubernetes]?». Zdroj: habr.com route: - destination: host: sa-frontend # 2 port: number: 80
Důležité body:

Tento VirtualService se vztahuje na požadavky přicházející přes http-gateway;
V cílová destinace je definován službou, kam jsou odesílány dotazy.

Poznámka: Konfigurace výše je uložena v souboru sa-virtualservice-external.yaml, který také obsahuje nastavení pro směrování v SA-WebApp a SA-Feedback, ale byl zde v článku zkrácen pro stručnost.

Použití VirtualService voláním:

Poznámka: Když aplikujeme zdroje Istio, Kubernetes API Server vytváří událost, kterou získává Istio Control Plane, a teprve poté je nová konfigurace aplikována na proxy servery Envoy každého podu. A Ingress Gateway je prezentován jako další Envoy, nakonfigurovaný v Control Plane. To všechno na diagramu vypadá takto:

Konfigurace Istio-IngressGateway pro směrování dotazů

Aplikace Sentiment Analysis je dostupná na http://{EXTERNAL-IP}/. Nemějte obavy, pokud dostáváte status Not Found: někdy to trvá o něco déle, než konfigurace nabude účinnosti a mezipaměti Envoy se obnovení.

Před pokračováním, proveďte trochu práce s aplikací, abyste vygenerovali provoz (jeho přítomnost je nezbytná pro jasnost v následujících akcích — pozn. překl.).

Kiali: sledovatelnost

Abyste se dostali do administrativního rozhraní Kiali, spusťte následující příkaz:

… a otevřete http://localhost:20001/, přihlášením jako admin/admin. Zde najdete mnoho užitečných funkcí, například pro kontrolu konfigurace komponent Istio, vizualizaci služeb na základě informací shromážděných při odchytu síťových požadavků, odpovědi na otázky "Kdo se na koho obrací?", "U které verze služby dochází k selhání?" apod. Obecně prozkoumejte možnosti Kiali, než se posunete dál — k vizualizaci metrik s Grafana.

Grafana: vizualizace metrik

Metriky shromážděné v Istio putují do Prometheus a jsou vizualizovány pomocí Grafana. Abyste se dostali do administrativního rozhraní Grafana, spusťte níže uvedený příkaz, a poté otevřete http://localhost:3000/:

Kliknutím na menu Home vlevo nahoře a výběrem Istio Service Dashboard v levém horním rohu, začněte se službou sa-web-app, abyste se podívali na shromážděné metriky:

Zde na nás čeká prázdné a naprosto nudné zobrazení — příručka by to nikdy neschválila. Vytvořme tedy malou zátěž následujícím příkazem:

Nyní máme mnohem hezčí grafy a navíc skvělé nástroje Prometheus pro monitorování a Grafana pro vizualizaci metrik, které nám umožní sledovat výkon, stav zdraví a zlepšení/degradaci výkonu služeb v čase.

Nakonec se podíváme na trasování požadavků ve službách.

Jaeger: trasování

Trasování potřebujeme, protože čím více máme služeb, tím obtížnější je zjistit příčinu selhání. Podívejme se na jednoduchý případ na obrázku níže:

Typický příklad náhodného neúspěšného požadavku

Požadavek přichází, a selhává — v čem je problém? První služba? Nebo druhá? Výjimky jsou v obou — podívejme se na logy každé z nich. Jak často se vás to stalo? Naše práce je spíše jako detektivní práce v oblasti softwaru, než jako vývojáři…

To je běžný problém v mikroslužbách a řeší se distribuovanými trasovacími systémy, ve kterých si služby předávají jedinečný identifikátor, po němž je tato informace přesměrována do trasovacího systému, kde se porovnává s daty požadavku. Zde je ilustrace:

Pro identifikaci požadavku se používá TraceId

V Istio se používá Jaeger Tracer, který realizuje framework OpenTracing API nezávislý na dodavatelích. Přístup k uživatelskému rozhraní Jaeger můžete získat následujícím příkazem:

Nyní přejděte na http://localhost:16686/ a vyberte službu sa-web-app. Pokud služba není zobrazena v rozbalovací nabídce — vyvolejte/simulujte činnost na stránce a obnovte rozhraní. Poté klikněte na tlačítko Najít trasování, které ukáže nejnovější trasy — vyberte libovolný — zobrazí se podrobné informace o všech trasách:

Tato trasa ukazuje:

Požadavek přichází do istio-ingressgateway (to je první interakce s jednou ze služeb, a pro požadavek je generován Trace ID), poté brána směruje požadavek do služby sa-web-app.
Ve službě sa-web-app žádost je zachycena sidecar Envoyem, vytváří se "potomek" ve spaně (proto ho vidíme v trasování) a přesměrovává se do kontejneru sa-web-app. (Span — logická jednotka práce v Jaeger, která má název, čas začátku operace a její trvání. Span'y mohou být vnořené a seřazené. Orientovaný acyklický graf span'ů vytváří trace. — pozn. překl.)
Zde je požadavek zpracován metodou sentimentAnalysis. Tyto trasy již byly vygenerovány aplikací, tj. pro ně bylo nutné provést změny v kódu.
Od tohoto okamžiku je iniciován POST požadavek na sa-logic. Trace ID musí být předán z sa-web-app.
…

Poznámka: Ve 4. kroku by aplikace měla vidět hlavičky vygenerované Istio a předat je do následujících požadavků, jak je znázorněno na obrázku níže:

(A) Za předávání hlaviček odpovídá Istio; (B) Za hlavičky odpovídají služby

Istio vykonává hlavní práci, protože generuje hlavičky pro příchozí žádosti, vytváří nové span'y v každém sidecaru a předává je dál. Bez práce s hlavičkami uvnitř služeb však bude celá stopa trasování žádosti ztracena.

Je třeba zohlednit (předat) následující hlavičky:

Je to jednoduchý úkol, avšak pro usnadnění jeho realizace již existuje mnoho knihoven — například ve službě sa-web-app klient RestTemplate předává tyto hlavičky, pokud pouze přidáme knihovny Jaeger a OpenTracing do jejich závislostí.

Všimněte si, že aplikace Sentiment Analysis demonstruje realizace na Flasku, Springu a ASP.NET Core.

Nyní, když je jasné, co získáváme „z krabice“ (nebo téměř „z krabice“), podívejme se na otázky jemně konfigurovatelného směrování, správy síťového provozu, bezpečnosti atd.!

Pozn. přek.: o tom si přečtěte v další části materiálů k Istio od Rinora Maloku, jejichž překlady budou následovat na našem blogu v blízké době. AKTUALIZACE (14. března): Druhá část už byla zveřejněna.

P.S. od překladatele

Přečtěte si také náš blog:

„Zpět k mikroslužbám s Istio“: část 2 (směrování, správa provozu), část 3 (autentizace a autorizace);
«Conduit — lehký service mesh pro Kubernetes»;
«Co je service mesh a proč ho potřebuji [pro cloudovou aplikaci s mikroslužbami]?»;
«Ilustrovaný průvodce fungováním sítě v Kubernetes. Části 1 a 2»;
«Jak se tento sidecar kontejner dostal sem [do Kubernetes]?».

Zdroj: habr.com