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;
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í:
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.
Envoy Sidecar to zkouší znovu (zkusit znovu). (1)
Neúspěšný požadavek je vrácen serveru proxy, který jej zavolal.
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?“.
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:
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:
Služba SA-Frontend, která slouží front-endové aplikaci na Reactjs;
Služba SA WebApp, která slouží k dotazům Analýza sentimentu;
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:
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):
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.
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:
$ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml
virtualservice.networking.istio.io/sa-external-services created
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:
$ kubectl port-forward
$(kubectl get pod -n istio-system -l app=kiali
-o jsonpath='{.items[0].metadata.name}')
-n istio-system 20001
…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/:
$ 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 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:
$ while true; do
curl -i http://$EXTERNAL_IP/sentiment
-H "Content-type: application/json"
-d '{"sentence": "I love yogobella"}';
sleep .8; done
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:
$ 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, 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.