🥇Späť k mikroservisom spolu s Istio. Časť 1

Pozn. prekl.: Service mesh sa určite stalo aktívnym riešením v modernej infraštruktúre pre aplikácie, ktoré nasledujú mikroslužobnú architektúru. Hoci je Istio možno známe mnohým DevOps inžinierom, ide o pomerne nový produkt, ktorý, vzhľadom na komplexnosť poskytovaných možností, môže vyžadovať značný čas na oboznámenie sa. Nemecký inžinier Rinor Maloku, zodpovedný za cloudové výpočty pre veľkých klientov v telekomunikačnej spoločnosti Orange Networks, napísal pozoruhodný cyklus materiálov, ktoré umožňujú dosť rýchlo a hlboko preniknúť do Istio. Začína svoje rozprávanie tým, čo vlastne Istio dokáže a ako sa na to dá rýchlo pozrieť vlastnými očami.

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

Správa prevádzky: časové limity, opätovné pokusy, vyvažovanie záťaže;
Bezpečnosť: autentifikácia a autorizácia koncového používateľa;
Pozorovateľnosť: trasovanie, monitorovanie, logovanie.

Všetky tieto problémy je možné vyriešiť na úrovni aplikácie, avšak potom vaše služby prestanú byť 'mikro'. Všetky dodatočné úsilie na vyriešenie týchto problémov — je zbytočná strata zdrojov spoločnosti, ktoré by sa mohli využiť priamo pre obchodné hodnoty. Zvážte príklad:

Projektový manažér: Ako dlho trvá pridať možnosť spätnej väzby?
Vývojár: Dva sprinty.
PM: Čo?.. Veď to je len CRUD!
V: Urobiť CRUD je jednoduchá časť úlohy, ale budeme tiež potrebovať autentifikovať a autorizovať používateľov a služby. Keďže je sieť nespolehlivá, bude potrebné implementovať opätovné požiadavky, ako aj vzorec circuit breaker v klientoch. Ešte, aby sme sa uistili, že celý systém nespadne, budú potrebné časové limity a bulkheads (podrobnejšie o oboch uvedených vzorcoch nájdete ďalej v článku — pozn. prekl.), a na to, aby sa problémy odhaľovali, bude potrebné monitorovanie, trasovanie, […]
PM: Och, v takom prípade jednoducho vložme túto funkciu do služby Product.

Myslím, že nápad je jasný: množstvo krokov a úsilia potrebného na pridaní jedného služby je obrovské. V tomto článku si povieme, ako Istio odstraňuje všetky vyššie uvedené problémy (ktoré nie sú cieľom pre obchodnú logiku) z služieb.

Poznámka: Článok predpokladá, že máte praktické znalosti o Kubernetes. V opačnom prípade odporúčam prečítať si moje úvod do Kubernetes a až potom pokračovať v čítaní tohto materiálu.

Myšlienka Istio

V svete bez Istio jedna služba vykonáva priame požiadavky na druhú a v prípade zlyhania si služba musí sama poradiť: zopakovať to, predpokladať timeout, aktivovať circuit breaker a podobne.

Sieťová premávka v Kubernetes

Istio ponúka špecializované riešenie, ktoré je úplne oddelené od služieb a funguje prostredníctvom zásahu do sieťovej komunikácie. Takýmto spôsobom realizuje:

Odolnosť voči zlyhaniam: založené na kóde stavu v odpovedi, zisťuje, či došlo k zlyhaniu požiadavky, a opakuje ju.
Kanárske nasadenia: presmerováva len fixné percento požiadaviek na novú verziu služby.
Monitorovanie a metriky: za aký čas služba odpovedala?
Sledovanie a pozorovanie: pridáva špeciálne hlavičky do každej požiadavky a vykonáva ich sledovanie v klastri.
Bezpečnosť: extrahuje JWT token, autentifikuje a autorizuje používateľov.

To sú len niektoré z možností (naozaj len niektoré!), aby vás upútali. A teraz sa poďme ponoriť do technických podrobností!

Architektúra Istio

Istio zachytáva všetku sieťovú premávku a aplikuje na ňu súbor pravidiel, vkladajúc do každého podu inteligentný proxy vo forme sidecar kontajnera. Proxies, ktoré aktivujú všetky funkcie, tvoria Data Plane, a môžu sa dynamicky konfigurovať pomocou Control Plane.

Data Plane

Vkladané proxy do podov umožňujú Istio jednoducho dosiahnuť požadované potreby. Napríklad si skontrolujeme funkcie opakovaní a circuit breaker.

Ako sú retries a circuit breaking implementované v Envoy

Zhrnieme to:

Envoy (reč je o proxy, ktorá sa nachádza v sidecar kontejnery, ktorý sa distribuuje aj ako samostatný produkt — pozn. prekl.) odosiela požiadavku prvému inštancii služby B a dôjde k zlyhaniu.
Envoy Sidecar sa pokúša o opakovanie (retry). (1)
Požiadavka so zlyhaním sa vracia volajúcej proxy.
Takto sa otvára Circuit Breaker a nastáva volanie nasledujúcej služby pre ďalšie požiadavky. (2)

To znamená, že nebudete musieť používať ďalšiu knižnicu Retry, nebudete musieť vytvárať vlastnú implementáciu Circuit Breaking a Service Discovery v programovacom jazyku X, Y alebo Z. To všetko a oveľa viac je k dispozícii priamo v Istio a nevyžaduje žiadne zmienky o kóde.

Skvele! Teraz by ste mohli chcieť vydať sa na plavbu s Istio, ale stále máte nejaké pochybnosti, otvorené otázky. Ak je to univerzálne riešenie na všetky situácie, máte zákonné podozrenie: veď všetky takéto riešenia sa v skutočnosti ukázali ako nevhodné pre žiadnu situáciu.

A tak sa nakoniec opýtate: „Je to prispôsobiteľné?“

Teraz ste pripravení na námorné dobrodružstvo — a poďme sa zoznámiť s Control Plane.

Control Plane

Skladá sa z troch komponentov: Pilot, Mixer a Citadel, — ktoré spoločne nastavujú Envoy pre smerovanie sieťového prenosu, aplikujú politiky a zhromažďujú telemetrické údaje. Schematicky to vyzerá takto:

Interakcia Control Plane s Data Plane

Envoyi (t.j. data plane) sú nakonfigurované pomocou Kubernetes CRD (Custom Resource Definitions), ktoré definoval Istio a sú špeciálne navrhnuté na tento účel. Pre vás to znamená, že sú prezentované ako ďalší zdroj v Kubernetes so známou syntaxou. Po vytvorení bude tento zdroj vyselektovaný control plane a aplikovaný na Envoyi.

Vzťah služieb k Istio

Opísali sme vzťah Istio k službám, ale nie naopak: ako sa služby vzťahujú na Istio?

Úprimne povedané, o prítomnosti Istio sú služby informované tak, ako ryby o vode, keď sa pýtajú: „Čo je vlastne voda?“.

Ilustrácia Victoria Dimitrakopoulos: — Ako ti chutí voda? — Čo je vlastne voda?

Takže môžete zobrať pracovný klaster a po nasadení komponentov Istio budú služby, ktoré sú v ňom, naďalej fungovať, a po odstránení týchto komponentov sa všetko vráti do normálu. Samozrejme, že pri tom prídete o možnosti, ktoré poskytuje Istio.

Dosť teórie — prejdime k praktickému využitiu týchto znalostí!

Istio v praxi

Istio si vyžaduje klaster Kubernetes, v ktorom je minimálne k dispozícii 4 vCPU a 8 GB RAM. Aby ste rýchlo vytvorili klaster a postupovali podľa pokynov z článku, odporúčam využiť Google Cloud Platform, ktorá ponúka novým používateľom bezplatných $300.

Po vytvorení klastru a nastavení prístupu k Kubernetes cez konzolový nástroj môžete nainštalovať Istio pomocou správcu balíkov Helm.

Inštalácia Helmu

Nainštalujte klienta Helm na svoj počítač, ako je vysvetlené v oficiálnej dokumentácii. Ten budeme používať na generovanie šablón pre inštaláciu Istio v nasledujúcej časti.

Inštalácia Istio

Stiahnite si zdroje Istio z najnovšieho vydania (pôvodný autorský odkaz na verziu 1.0.5 bol aktualizovaný na aktuálnu, t.j. 1.0.6 — pozn. prekl.), extrahujte obsah do jedného adresára, ktorý budem neskôr nazývať [istio-resources].

Aby sme jednoducho identifikovali zdroje Istio, vytvorte v klastri K8s priestor názvov istio-system:

$ kubectl create namespace istio-system

Dokončite inštaláciu prechodom do adresára [istio-resources] a vykonaním 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. Zmenili sme štandardnú šablónu, aby sme prispôsobili nasledujúce parametre:

global.mtls.enabled nastavené na nepravda (t.j. mTLS autentifikácia je vypnutá — pozn. prekl.), aby sme zjednodušili náš proces zoznamovania;
tracing.enabled povoľuje sledovanie požiadaviek pomocou Jaeger;
kiali.enabled inštaluje Kiali do klastra na vizualizáciu služieb a prevádzky;
grafana.enabled inštaluje Grafana na vizualizáciu zhromaždených metrík.

Aplikujeme vygenerované zdroje príkazom:

$ kubectl apply -f istio.yaml

Inštalácia Istio do klastra bola dokončená! Počkajte, kým budú všetky pod’y v priestore názvov istio-system v stave Running alebo Completed, vykonaním nasledujúceho príkazu:

$ kubectl get pods -n istio-system

Teraz sme pripravení pokračovať v nasledujúcej časti, kde spustíme aplikáciu.

Architektúra aplikácie Sentiment Analysis

Využijeme príklad mikroslužby aplikácie Sentiment Analysis, ktorý bol použitý v už spomínanej úvodnej článku o Kubernetes. Je dostatočne zložitý, aby ukázal možnosti Istio v praxi.

Aplikácia sa skladá zo štyroch mikroslužieb:

Služba SA-Frontend, ktorá poskytuje frontend aplikácie na Reactjs;
Služba SA-WebApp, ktorá spravuje požiadavky Sentiment Analysis;
Služba SA-Logic, ktorá vykonáva samotný sentiment-analyzátor;
Služba SA-Feedback, ktorý získava od používateľov spätnú väzbu o presnosti vykonaného analýzy.

Na tomto schémate okrem služieb vidíme aj Ingress Controller, ktorý v Kubernetes smeruje prichádzajúce požiadavky na príslušné služby. V Istio sa používa podobná koncepcia v rámci Ingress Gateway, podrobnosti prídu neskôr.

Spustenie aplikácie s proxy od Istio

Pre ďalšie operácie spomenuté v článku si sklonujte repozitár istio-mastery. Obsahuje aplikáciu a manifesty pre Kubernetes a Istio.

Vloženie sidecarov

Vloženie môže byť vykonané automaticky alebo ručne. Pre automatické vloženie sidecar kontajnerov bude potrebné nastaviť názov priestoru na štítok istio-injection=enabled, čo sa robí nasledujúcim príkazom:

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

Teraz každý pod, ktorý sa nasadí v predvolenom priestore (default) dostane svoj sidecar kontajner. Aby sme sa o tom presvedčili, nasadíme testovaciu aplikáciu prechodom do koreňového adresára repozitára [istio-mastery] a vykonáme nasledujúci prí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

Po nasadení služieb skontrolujeme, či majú pod-y dva kontajnery (s vlastnou službou a jej sidecarom) vykonaním príkazu kubectl get pods a presvedčíme sa, že v stĺpci READY je uvedená hodnota 2/2, symbolizujúca, že oba kontajnery sú spustené:

$ 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

Vizualne to vyzerá takto:

Proxy Envoy v jednom z pod-ov

Teraz, keď je aplikácia spustená a funguje, potrebujeme povoliť prichádzajúcej prevádzke prístup do aplikácie.

Ingress Gateway

Najlepšia prax, ako to dosiahnuť (povoliť premávku v klastre) — je cez Ingress Gateway v Istio, ktorá sa nachádza pri „hranici“ klastru a umožňuje pre prichádzajúcu prevádzku aktivovať funkcie Istio ako smerovanie, vyvažovanie záťaže, bezpečnosť a monitorovanie.

Komponent Ingress Gateway a služba, ktorá ho smeruje von, boli nainštalované do klastru počas inštalácie Istio. Ak chcete získať externú IP adresu služby, vykonajte:

$ 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

Na tento IP budeme pristupovať k aplikácii ďalej (budem ho označovať ako EXTERNAL-IP), preto si ho pre pohodlie zapíšeme 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 pokúsite teraz navštíviť tento IP cez prehliadač, dostanete chybu Service Unavailable, pretože počas štandardného nastavenia Istio blokuje všetku prichádzajúcu prevádzku, kým nebude určitý Gateway.

Zdroje Gateway

Gateway je CRD (vlastná definícia zdrojov) v Kubernetes, definovaná po inštalácii Istio v klastroch a aktivujúca možnosť určovať porty, protokoly a hostiteľov, pre ktorých chceme povoliť prichádzajúcu prevádzku.

V našom prípade chceme povoliť HTTP prevádzku na 80. porte pre všetkých hostiteľov. Úlohu realizuje nasledujúca definícia (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:
- "*"

Takáto konfigurácia nepotrebuje vysvetlenie okrem selektora istio: ingressgateway. Pomocou tohto selektora môžeme určiť, na ktorý Ingress Gateway sa má konfigurácia aplikovať. V našom prípade ide o ovládač Ingress Gateway, ktorý bol predvolene nainštalovaný v Istio.

Konfigurácia sa aplikuje vykonaním nasledujúcej príkazu:

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

Teraz Gateway povoľuje prístup na port 80, ale nemá predstavu o tom, kam smerovať požiadavky. Pre to budú potrebné Virtuálne služby.

Zdroje VirtualService

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

Požiadavky na našu aplikáciu, ktoré prichádzajú cez http-gateway, by mali byť odoslané do služieb sa-frontend, sa-web-app a sa-feedback:

Trasy, ktoré musia byť nastavené s VirtualServices

Zvážime požiadavky, ktoré by mali smerovať na SA-Frontend:

Presné zhodovanie cesty / sa má posielať do SA-Frontend pre získanie index.html;
Cesty s prefixom /static/* sa majú posielať do SA-Frontend pre získanie statických súborov, ktoré sa používajú vo frontende, ako CSS a JavaScript;
Cesty, ktoré spadajú pod regulárny výraz '^.*.(ico|png|jpg)$', sa majú posielať do SA-Frontend, pretože ide o obrázky, ktoré sa zobrazujú na stránke.

Realizá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) Dôležité body: Tento VirtualService sa vzťahuje na požiadavky prichádzajúce cez http-gateway; V cieľ určuje sa služba, kam sa odosielajú požiadavky. Poznámka: Konfigurácia vyššie sa uchováva v súbore sa-virtualservice-external.yaml, ktorý tiež obsahuje nastavenia na smerovanie v SA-WebApp a SA-Feedback, ale bol tu skrátený na účely prehľadnosti. Aplikujeme VirtualService volaním: $ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml virtualservice.networking.istio.io/sa-external-services vytvorený Poznámka: Keď aplikujeme zdroje Istio, Kubernetes API Server vytvorí udalosť, ktorú dostane Istio Control Plane, a až potom sa nová konfigurácia aplikuje na proxy servery Envoy každého podu. A kontrolér Ingress Gateway sa predstavuje ako ďalší Envoy, nakonfigurovaný v Control Plane. To všetko na schéme vyzerá takto: Konfigurácia Istio-IngressGateway na smerovanie požiadaviek Aplikácia Sentiment Analysis sa stala dostupnou na http://{EXTERNAL-IP}/. Nezúfajte, ak dostanete stav Not Found: niekedy trvá trochu dlhšie, kým sa konfigurácia prejaví a kešovanie Envoy sa aktualizuje. Predtým, ako pokračujete, trošku pracujte s aplikáciou, aby ste vygenerovali prevádzku (jeho prítomnosť je potrebná na prehľadnosť v nasledujúcich akciách — pozn. prekl.). Kiali: sledovanie Aby ste sa dostali do administratívneho rozhrania Kiali, vykonajte nasledujúci príkaz: $ kubectl port-forward $(kubectl get pod -n istio-system -l app=kiali -o jsonpath='{.items[0].metadata.name}') -n istio-system 20001 … a otvorte http://localhost:20001/, prihlásením pod admin/admin. Tu nájdete mnoho užitočných funkcií, napríklad na kontrolu konfigurácie komponentov Istio, vizualizáciu služieb na základe informácií zozbieraných pri zachytávaní sieťových požiadaviek, získavanie odpovedí na otázky ako „Kto sa na koho obracia?“, „Pri ktorej verzii služby sa vyskytujú chyby?“ a pod. Všeobecne, preskúmajte možnosti Kiali, než prejdete ďalej — k vizualizácii metrík s Grafana. Grafana: vizualizácia metrík Metriky zozbierané v Istio sa dostanú do Prometheus a sú vizualizované prostredníctvom Grafana. Aby ste sa dostali do administratívneho rozhrania Grafana, vykonajte dolný príkaz a potom otvorte 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 vľavo hore a výberom Istio Service Dashboard v ľavom hornom rohu, začnite so službou sa-web-app, aby ste sa pozreli na zozbierané metriky: Tu nás čaká prázdna a úplne nudná prezentácia — príručka by toto nikdy neschválila. Poďme teda vytvoriť malú záťaž nasledujúcim príkazom: $ while true; do curl -i http://$EXTERNAL_IP/sentiment -H "Content-type: application/json" -d '{"sentence": "Milujem yogobella"}'; sleep .8; done Teraz máme omnoho krajšie grafy, a navyše skvelé nástroje Prometheus na monitorovanie a Grafana na vizualizáciu metrik, ktoré nám umožnia získať informácie o výkonnosti, zdravotnom stave a zlepšeniach/degradáciách v práci služieb v priebehu času. Nakoniec sa pozrieme na sledovanie požiadaviek v službách. Jaeger: sledovanie Sledovanie je potrebné, pretože čím viac máme služieb, tým ťažšie je dôjsť k príčine zlyhania. Pozrieme sa na jednoduchý prípad z obrázka nižšie: Typický príklad náhodného zlyhania požiadavky Požiadavka prichádza, zlyhá — v čom je teda problém? Prvá služba? Alebo druhá? V oboch sú výnimky — pozrime sa na záznamy každej z nich. Koľkokrát ste sa pristihli pri takejto činnosti? Naša práca skôr pripomína prácu detektívov softvéru ako vývojárov… Je to široko rozšírený problém v mikroslužbách a rieši sa to distribučnými systémami sledovania, v ktorých služby prenášajú navzájom jedinečný hlavičkový parameter, po čom sa tieto informácie prenesú do systému sledovania, kde sa porovnávajú s údajmi požiadavky. Tu je ilustrácia: Na identifikáciu požiadavky sa používa TraceId V Istio sa používa Jaeger Tracer, ktorý implementuje framework OpenTracing API nezávislý od dodávateľa. Prístup k užívateľskému rozhraniu Jaeger získate nasledujúcim príkazom: $ kubectl port-forward -n istio-system $(kubectl get pod -n istio-system -l app=jaeger -o jsonpath='{.items[0].metadata.name}') 16686 Teraz prejdite na http://localhost:16686/ a vyberte službu sa-web-app. Ak služba nie je zobrazená v rozbaľovacom menu — aktivujte/generujte činnosť na stránke a aktualizujte rozhranie. Potom kliknite na tlačidlo Find Traces, ktoré zobrazí najnovšie sledovania — vyberte akékoľvek — zobrazí sa podrobná informácia o všetkých sledovaniach: Toto sledovanie ukazuje: Požiadavka prichádza do istio-ingressgateway (toto je prvé interakcia s jednou zo služieb, a pre požiadavku sa generuje Trace ID), potom brána nasmeruje požiadavku do služby sa-web-app. V službe sa-web-app požiadavku prevziať Envoy sidecar, vytvára sa „dieťa“ v span (preto ho vidíme v sledovaniach) a je presmerovaná do kontajnera sa-web-app. (Span — logická práca v Jaeger, ktorá má názov, čas začatia operácie a jej trvanie. Span-y môžu byť vnorené a usporiadané. Orientovaný acyklický graf zo span-ov tvorí trace. — pozn. prekl.) Tu sa žiadosť spracováva metódou sentimentAnalysis. Tieto trace už boli vygenerované aplikáciou, t.j. na ich vytvorenie boli potrebné zmeny v kóde. Od tohto momentu sa iniciuje POST-žiadosť do sa-logic. Trace ID musí byť prenášané z sa-web-app. … Poznámka: V 4. kroku by mala aplikácia vidieť hlavičky generované Istio a preniesť ich do nasledujúcich žiadostí, ako je zobrazené na obrázku nižšie: (A) Za prenášanie hlavičiek je zodpovedné Istio; (B) Za hlavičky sú zodpovedné služby Istio vykonáva hlavnú prácu, pretože generuje hlavičky pre prichádzajúce žiadosti, vytvára nové span-y v každom sidecare a prenáša ich. Bez práce s hlavičkami vo vnútri služieb však bude celý sledovanie požiadaviek stratené. Je dôležité zohľadniť (prenášať) nasledujúce hlavičky: x-request-id x-b3-traceid x-b3-spanid x-b3-parentspanid x-b3-sampled x-b3-flags x-ot-span-context Nie je to zložitá úloha, avšak na zjednodušenie jej implementácie už existuje množstvo knižníc — napríklad v službe sa-web-app klient RestTemplate prenáša tieto hlavičky, ak len pridáte knižnice Jaeger a OpenTracing do jeho závislostí. Všimnite si, že aplikácia Sentiment Analysis demonštruje implementácie na Flask, Spring a ASP.NET Core. Teraz, keď je jasné, čo získavame priamo (alebo takmer ‚priamo‘), pozrime sa na otázky jemne nastaviteľnej routizácie, riadenia sieťovej prevádzky, bezpečnosti atď.! Pozn. prekl.: o tom čítajte v nasledujúcej časti materiálov o Istio od Rinora Maloku, ktoré budú nasledovať v našom blogu v najbližšej dobe. UPDATE (14. marca): Druhá časť už bola publikovaná. P.S. od prekladateľa Prečítajte si tiež na našom blogu: „Späť k mikroslužbám s Istio“: časť 2 (smerovanie, správa prevádzky), časť 3 (autentifikácia a autorizácia); «Conduit — ľahký service mesh pre Kubernetes»; «Čo je service mesh a prečo ho potrebujem [pre cloudovú aplikáciu s mikroservisami]?»; «Ilustrovaný sprievodca zariadením siete v Kubernetes. Časti 1 a 2»; «Ako sa tento sidecar-kontejner dostal sem [v Kubernetes]?». Zdroj: habr.com route: - destination: host: sa-frontend # 2 port: number: 80
Dôležité body:

Tento VirtualService sa vzťahuje na požiadavky prichádzajúce cez http-gateway;
V cieľ určuje sa služba, kam sa odosielajú požiadavky.

Poznámka: Konfigurácia vyššie sa uchováva v súbore sa-virtualservice-external.yaml, ktorý tiež obsahuje nastavenia na routizáciu v SA-WebApp a SA-Feedback, ale bol tu skrátený pre stručnosť.

Použijeme VirtualService volaním:

Poznámka: Keď použijeme zdroje Istio, Kubernetes API Server vytvorí udalosť, ktorú získa Istio Control Plane, a až potom sa nová konfigurácia aplikuje na proxy servery Envoy každého podu. A controller Ingress Gateway sa predstavuje ďalším Envoyom, konfigurovaným v Control Plane. To všetko na schéme vyzerá takto:

Konfigurácia Istio-IngressGateway na smerovanie požiadaviek

Aplikácia Sentiment Analysis sa stala dostupnou na http://{EXTERNAL-IP}/. Nezúfajte, ak dostanete stav Not Found: niekedy trvá trochu dlhšie, kým sa konfigurácia prejaví a kešovanie Envoy sa aktualizuje.

Predtým, ako pokračujete, trošku pracujte s aplikáciou, aby ste vygenerovali prevádzku (jeho prítomnosť je potrebná na prehľadnosť v nasledujúcich akciách — pozn. prekl.).

Kiali: sledovanie

Aby ste sa dostali do administratívneho rozhrania Kiali, vykonajte nasledujúci príkaz:

… a otvorte http://localhost:20001/, prihlásením pod admin/admin. Tu nájdete mnoho užitočných funkcií, napríklad na kontrolu konfigurácie komponentov Istio, vizualizáciu služieb na základe informácií zozbieraných pri zachytávaní sieťových požiadaviek, získavanie odpovedí na otázky ako „Kto sa na koho obracia?“, „Pri ktorej verzii služby sa vyskytujú chyby?“ a pod. Všeobecne, preskúmajte možnosti Kiali, než prejdete ďalej — k vizualizácii metrík s Grafana.

Grafana: vizualizácia metrík

Metriky zozbierané v Istio sa dostanú do Prometheus a sú vizualizované prostredníctvom Grafana. Aby ste sa dostali do administratívneho rozhrania Grafana, vykonajte dolný príkaz a potom otvorte http://localhost:3000/:

Kliknutím na menu Home vľavo hore a výberom Istio Service Dashboard v ľavom hornom rohu, začnite so službou sa-web-app, aby ste sa pozreli na zozbierané metriky:

Tu nás čaká prázdna a úplne nudná prezentácia — príručka by toto nikdy neschválila. Poďme teda vytvoriť malú záťaž nasledujúcim príkazom:

Teraz máme omnoho krajšie grafy, a navyše skvelé nástroje Prometheus na monitorovanie a Grafana na vizualizáciu metrik, ktoré nám umožnia získať informácie o výkonnosti, zdravotnom stave a zlepšeniach/degradáciách v práci služieb v priebehu času.

Nakoniec sa pozrieme na sledovanie požiadaviek v službách.

Jaeger: sledovanie

Sledovanie je potrebné, pretože čím viac máme služieb, tým ťažšie je dôjsť k príčine zlyhania. Pozrieme sa na jednoduchý prípad z obrázka nižšie:

Typický príklad náhodného zlyhania požiadavky

Požiadavka prichádza, zlyhá — v čom je teda problém? Prvá služba? Alebo druhá? V oboch sú výnimky — pozrime sa na záznamy každej z nich. Koľkokrát ste sa pristihli pri takejto činnosti? Naša práca skôr pripomína prácu detektívov softvéru ako vývojárov…

Je to široko rozšírený problém v mikroslužbách a rieši sa to distribučnými systémami sledovania, v ktorých služby prenášajú navzájom jedinečný hlavičkový parameter, po čom sa tieto informácie prenesú do systému sledovania, kde sa porovnávajú s údajmi požiadavky. Tu je ilustrácia:

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

V Istio sa používa Jaeger Tracer, ktorý implementuje framework OpenTracing API nezávislý od dodávateľa. Prístup k užívateľskému rozhraniu Jaeger získate nasledujúcim príkazom:

Teraz prejdite na http://localhost:16686/ a vyberte službu sa-web-app. Ak služba nie je zobrazená v rozbaľovacom menu — aktivujte/generujte činnosť na stránke a aktualizujte rozhranie. Potom kliknite na tlačidlo Find Traces, ktoré zobrazí najnovšie sledovania — vyberte akékoľvek — zobrazí sa podrobná informácia o všetkých sledovaniach:

Toto sledovanie ukazuje:

Požiadavka prichádza do istio-ingressgateway (toto je prvé interakcia s jednou zo služieb, a pre požiadavku sa generuje Trace ID), potom brána nasmeruje požiadavku do služby sa-web-app.
V službe sa-web-app žiadosť sa zachytí Envoy sidecarom, vytvorí sa „dieťa“ v spine (preto ho vidíme v trasách) a presmeruje sa do kontajnera sa-web-app. (Span — logická jednotka práce v Jaeger, ktorá má názov, čas začiatku operácie a jej trvanie. Spany môžu byť vnorené a usporiadané. Orientovaný acyklický graf zo spanov tvorí trasu. — pozn. prekl.)
Tu sa žiadosť spracováva metódou sentimentAnalysis. Tieto trace už boli vygenerované aplikáciou, t.j. na ich vytvorenie boli potrebné zmeny v kóde.
Od tohto momentu sa iniciuje POST-žiadosť do sa-logic. Trace ID musí byť prenášané z sa-web-app.
…

Poznámka: V 4. kroku by mala aplikácia vidieť hlavičky generované Istio a preniesť ich do nasledujúcich žiadostí, ako je zobrazené na obrázku nižšie:

(A) Za prenášanie hlavičiek je zodpovedné Istio; (B) Za hlavičky sú zodpovedné služby

Istio vykonáva hlavnú prácu, pretože generuje hlavičky pre prichádzajúce žiadosti, vytvára nové spany v každom sidecare a prenáša ich. Avšak bez práce s hlavičkami vo vnútri služieb bude úplná cesta trasovania požiadavky stratena.

Je dôležité zohľadniť (prenášať) nasledujúce hlavičky:

Nie je to zložitá úloha, avšak na zjednodušenie jej implementácie už existuje množstvo knižníc — napríklad v službe sa-web-app klient RestTemplate prenáša tieto hlavičky, ak len pridáte knižnice Jaeger a OpenTracing do jeho závislostí.

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

Teraz, keď je jasné, čo získavame priamo (alebo takmer ‚priamo‘), pozrime sa na otázky jemne nastaviteľnej routizácie, riadenia sieťovej prevádzky, bezpečnosti atď.!

Pozn. prekl.: o tom čítajte v nasledujúcej časti materiálov o Istio od Rinora Maloku, ktoré budú nasledovať v našom blogu v najbližšej dobe. UPDATE (14. marca): Druhá časť už bola publikovaná.