🥇Întoarcere la microservicii împreună cu Istio. Partea 1

Nota traducătorului.: Serviciile mesh au devenit cu siguranță o soluție relevantă în infrastructura modernă pentru aplicațiile care adoptă arhitectura microserviciilor. Deși Istio ar putea fi cunoscut de mulți ingineri DevOps, este un produs destul de nou care, având în vedere complexitatea funcționalităților oferite, poate necesita un timp considerabil pentru a fi înțeles. Inginerul german Rinor Maloku, responsabil de cloud computing pentru clienții mari la compania de telecomunicații Orange Networks, a scris un ciclu de materiale care permit o familiarizare rapidă și profundă cu Istio. El își începe relatarea prin prezentarea capabilităților Istio și modul în care acestea pot fi vizualizate rapid.

Istio — Proiect open source, dezvoltat în colaborare cu echipe din Google, IBM și Lyft. Acesta abordează complexitățile întâmpinate în aplicațiile bazate pe microservicii, cum ar fi:

Gestionarea traficului: timeout-uri, retry-uri, balansarea încărcăturii;
Securitate: autentificarea și autorizarea utilizatorilor finali;
Observabilitate: trasare, monitorizare, logging.

Toate acestea pot fi rezolvate la nivel de aplicație, însă astfel serviciile tale nu vor mai fi „micro”. Toate eforturile suplimentare pentru a rezolva aceste probleme reprezintă o pierdere de resurse pentru companie, care ar putea fi utilizate în mod direct pentru crearea de valoare de afaceri. Să luăm un exemplu:

Manager de proiect: Cât timp va dura adăugarea funcției de feedback?
Dezvoltator: Două sprinturi.
MP: Ce?.. Este doar un CRUD!
D: Implementarea CRUD-ului este partea simplă a task-ului, dar va trebui să autentificăm și să autorizăm utilizatorii și serviciile. Deoarece rețeaua este nesigură, va fi nevoie să implementăm retry-uri și patternul circuit breaker în clienți. De asemenea, pentru a ne asigura că întreg sistemul nu pică, vor fi necesare timeout-uri și bulkheads (pentru detalii despre cele două pattern-uri menționate, consultați mai departe în articol — n.tr.), iar pentru a detecta problemele va fi necesară monitorizarea, trasarea, […]
MP: Oh, hai să adăugăm această funcție în serviciul Product.

Cred că ideea este clară: volumul de pași și eforturi necesare pentru a adăuga un singur serviciu este enorm. În acest articol, vom explora cum Istio elimină toate dificultățile menționate anterior (care nu sunt legate de logica de afaceri) din serviciile noastre.

Notă: Articolul presupune că aveți cunoștințe practice despre Kubernetes. În caz contrar, vă recomand să citiți introducerea mea în Kubernetes și abia apoi să continuați cu lectura acestui material.

Ideea Istio

Într-o lume fără Istio, un serviciu face solicitări directe către altul, iar în cazul unei defecțiuni, serviciul trebuie să gestioneze situația: să încerce din nou, să prevadă un timeout, să deschidă un circuit breaker etc.

Traficul de rețea în Kubernetes

Istio oferă o soluție specializată, complet separată de servicii, care funcționează prin intervenția în interacțiunea de rețea. Astfel, aceasta realizează:

Redundanță: bazându-se pe codul de stare din răspuns, înțelege dacă a apărut o eroare în solicitare și o execută din nou.
Versiile canar: redirecționează doar un procent fix de solicitări către noua versiune a serviciului.
Monitorizarea și metrica: cât timp a durat până a răspuns serviciul?
Trasarea și observabilitatea: adaugă antete speciale în fiecare solicitare și le trasează în cluster.
Securitate: extrage tokenul JWT, autentifică și autorizează utilizatorii.

Acestea sunt doar câteva dintre funcționalitățile disponibile (de fapt, doar câteva!), pentru a vă stârni interesul. Acum haideți să ne adâncim în detalii tehnice!

Arhitectura Istio

Istio interceptă tot traficul de rețea și îi aplică un set de reguli, inserând în fiecare pod un proxy inteligent sub formă de container sidecar. Proxii, care activează toate funcționalitățile, formează Data Plane, iar aceștia pot fi configurați dinamic folosind Control Plane.

Data Plane

Proxii inserați în pod-uri permit Istio să îndeplinească cu ușurință cerințele noastre. De exemplu, să verificăm funcțiile de retry și circuit breaker.

Cum sunt implementate retries și circuit breaking în Envoy

Să rezumăm:

Envoy (referitor la proxy-ul aflat în containerul sidecar, care se distribuie și ca produs separat — nota trad.) trimite solicitarea către primul exemplu al serviciului B și apare o eroare.
Envoy Sidecar face o nouă încercare (retry). (1)
Solicitarea eronată se întoarce la proxy-ul care a solicitat-o.
Așa se deschide Circuit Breaker și se face apel la următorul serviciu pentru solicitările ulterioare. (2)

Aceasta înseamnă că nu va trebui să folosești o altă bibliotecă Retry, nu va trebui să implementezi Circuit Breaking și Service Discovery în limbajul de programare X, Y sau Z. Toate acestea și multe altele sunt disponibile din cutie în Istio și nu necesită niciun modificări în cod.

Perfect! Acum ai putea dori să te aventurezi cu Istio, dar există încă unele îndoieli, întrebări deschise. Dacă aceasta este o soluție universală pentru toate situațiile, atunci îți va apărea o suspiciune firească: toate aceste soluții se dovedesc, de fapt, a nu fi potrivite pentru nicio situație.

Și finalmente, vei întreba: „Se configurează?”

Acum ești pregătit pentru o călătorie pe mare — să ne familiarizăm cu Control Plane.

Control Plane

Acesta este compus din trei componente: Pilot, Mixer și Citadel, — care, prin eforturi comune, configurează Envoy pentru rutarea traficului, aplică politici și colectează date de telemetrie. Schematic, totul arată așa:

Interacțiunea Control Plane cu Data Plane

Envoy (adică data plane) sunt configurate prin Kubernetes CRD (Custom Resource Definitions), definite de Istio și special concepute pentru acest scop. Acest lucru înseamnă că se prezintă ca o resursă obișnuită în Kubernetes cu o sintaxă familiară. După crearea sa, această resursă va fi preluată de control plane și aplicată Envoy.

Relația serviciilor cu Istio

Am descris relația Istio cu serviciile, dar nu invers: cum se raportează serviciile la Istio?

Sincer, serviciile sunt la fel de conștiente de prezența Istio cum sunt peștii de apă, atunci când se întreabă: „Ce este, de fapt, apa?”.

Ilustrație Victoria Dimitrakopoulos: — Cum este apa? — Ce este, de fapt, apa?

Astfel, poți lua un cluster de lucru și, după ce ai implementat componentele Istio, serviciile din el vor continua să funcționeze, iar după eliminarea acestor componente — totul va fi din nou în regulă. Evident, vei pierde capacitățile oferite de Istio.

Destul cu teoria — să punem această cunoaștere în practică!

Istio în practică

Istio necesită un cluster Kubernetes, în care sunt disponibile cel puțin 4 vCPU și 8 GB RAM. Pentru a ridica rapid un cluster și a urma instrucțiunile din articol, îți recomand să folosești Google Cloud Platform, care oferă noilor utilizatori 300 $ gratuit.

După crearea cluster-ului și configurarea accesului la Kubernetes prin utilitarul de consolă, puteți instala Istio prin managerul de pachete Helm.

Instalarea Helm

Instalați clientul Helm pe computerul dumneavoastră, așa cum este descris în documentația oficială. Acesta va fi folosit pentru generarea șabloanelor pentru instalarea Istio în secțiunea următoare.

Instalarea Istio

Descărcați resursele Istio din cea mai recentă versiune (linkul original pentru versiunea 1.0.5 a fost actualizat la versiunea 1.0.6 — nota traducătorului), extrageți conținutul într-un singur director, pe care îl voi numi în continuare [istio-resources].

Pentru a simplifica identificarea resurselor Istio, creați în cluster-ul K8s un spațiu de nume istio-system:

$ kubectl create namespace istio-system

Finalizați instalarea, navigând în directorul [istio-resources] și executând comanda:

$ 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

Această comandă va scrie componentele cheie Istio într-un fișier istio.yaml. Am modificat șablonul standard pentru nevoile noastre, specificând următoarele opțiuni:

global.mtls.enabled setat pe false (adică autentificarea mTLS este dezactivată — nota traducătorului), pentru a simplifica procesul nostru de familiarizare;
tracing.enabled activează monitorizarea cererilor folosind Jaeger;
kiali.enabled instalează Kiali în cluster pentru vizualizarea serviciilor și a traficului;
grafana.enabled instalează Grafana pentru vizualizarea metricilor colectate.

Aplicăm resursele generate cu comanda:

$ kubectl apply -f istio.yaml

Instalarea Istio în cluster a fost finalizată! Așteptați până când toate pod-urile din spațiul de nume istio-system vor fi în starea Running sau Completed, executând comanda de mai jos:

$ kubectl get pods -n istio-system

Acum suntem pregătiți să continuăm în secțiunea următoare, unde vom ridica și rula aplicația.

Arhitectura aplicației Sentiment Analysis

Vom utiliza exemplul aplicației microservicii Sentiment Analysis, folosit în deja menționata articol introductiv în Kubernetes. Este suficient de complex pentru a demonstra capacitățile Istio în practică.

Aplicația constă din patru microservicii:

Serviciu SA-Frontend, care gestionează frontend-ul aplicației pe Reactjs;
Serviciu SA-WebApp, care gestionează cererile pentru Sentiment Analysis;
Serviciu SA-Logic, care efectuează analiza de sentiment;
Serviciu SA-Feedback, care primește feedback de la utilizatori despre precizia analizei realizate.

În această diagramă, pe lângă servicii, vedem și Ingress Controller, care în Kubernetes rotește cererile de intrare către serviciile corespunzătoare. În Istio se folosește un concept similar în cadrul Ingress Gateway, despre care urmează detalii.

Lansarea aplicației cu proxy de la Istio

Pentru operațiile ulterioare menționate în articol, clonati repositioul. istio-mastery. Acesta conține aplicația și manifestele pentru Kubernetes și Istio.

Inserarea sidecar-urilor

Inserția poate fi efectuată automat sau manual. Pentru inserția automată a containerelor sidecar, va trebui să etichetați spațiul de nume istio-injection=enabled, ceea ce se face cu următoarea comandă:

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

Acum, fiecare pod care va fi desfășurat în spațiul de nume implicit (default) va obține propriul său container sidecar. Pentru a ne asigura de acest lucru, să desfășurăm o aplicație de test, mergând în directorul de bază al repositoului [istio-mastery] și executând următoarea comandă:

$ 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

După desfășurarea serviciilor, să verificăm dacă pod-urile au câte două containere (cu serviciul propriu și cu sidecar-ul său), executând comanda kubectl get pods și asigurându-ne că sub coloana READY este indicat un valoare 2/2, simbolizând că ambele containere sunt porniți:

$ 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

Vizual, aceasta apare astfel:

Proxy Envoy în unul dintre pod-uri

Acum, când aplicația este ridicată și funcționează, va trebui să permitem traficului de intrare să ajungă la aplicație.

Ingress Gateway

Cea mai bună practică pentru a realiza acest lucru (a permite traficul în cluster) este prin Ingress Gateway în Istio, care se află la «granița» cluster-ului și permite activarea pentru traficul de intrare a unor funcții Istio, cum ar fi rutarea, balansarea încărcării, securitatea și monitorizarea.

Componenta Ingress Gateway și serviciul care îl expune în exterior au fost instalate în cluster în timpul instalării Istio. Pentru a afla adresa IP externă a serviciului, executați:

$ 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

Ne vom adresa aplicației prin această adresă IP și mai departe (o voi numi EXTERNAL-IP), așa că, pentru comoditate, vom salva valoarea într-o variabilă:

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

Dacă încercați acum să accesați această adresă IP prin browser, veți primi o eroare Service Unavailable, deoarece din default, Istio blochează tot traficul de intrare, până nu este definit un Gateway.

Resursa Gateway

Gateway este o CRD (Custom Resource Definition) în Kubernetes, definită după instalarea Istio în cluster și activând capacitatea de a specifica porturi, protocoale și gazde pentru care dorim să permitem traficul de intrare.

În cazul nostru, dorim să permitem traficul HTTP pe portul 80 pentru toate gazdele. Sarcina se realizează prin următoarea definiție (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:
- "*"

Această configurație nu necesită explicații, cu excepția selectorului istio: ingressgateway. Prin acest selector putem specifica la ce Ingress Gateway se va aplica configurația. În cazul nostru, acesta este controlerul Ingress Gateway, instalat implicit în Istio.

Configurarea se aplică prin apelarea următoarei comenzi:

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

Acum, gateway-ul permite accesul la portul 80, dar nu are informații despre unde să ruteze cererile. Pentru aceasta, sunt necesare Virtual Services.

Resursa VirtualService

VirtualService indică Ingress Gateway-ului cum să ruteze cererile care sunt permise în interiorul cluster-ului.

Cererile către aplicația noastră, venind prin http-gateway, trebuie să fie trimise către serviciile sa-frontend, sa-web-app și sa-feedback:

Rutele care trebuie configurate cu VirtualServices

Să examinăm cererile care ar trebui să fie direcționate către SA-Frontend:

Potrivire exactă pe cale / trebuie să fie trimisă către SA-Frontend pentru a obține index.html;
Cărțile cu prefixul /static/* trebuie să fie trimise către SA-Frontend pentru a obține fișierele statice utilizate în frontend, precum CSS și JavaScript;
Cărțile care se încadrează în expresia regulată '^.*.(ico|png|jpg)$', trebuie să fie trimise către SA-Frontend, deoarece sunt imagini afișate pe pagină.

Implementarea se realizează prin următoarea configurație (sa-virtualservice-external.yaml):

tip: 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) Puncte importante: Acest VirtualService se referă la cererile care vin prin http-gateway; În destination se determină serviciul către care sunt trimise cererile. Notă: Configurația de mai sus este stocată într-un fișier sa-virtualservice-external.yaml, care conține de asemenea setările pentru rutare în SA-WebApp și SA-Feedback, dar a fost scurtat aici în articol pentru concizie. Aplicăm VirtualService prin apelul: $ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml virtualservice.networking.istio.io/sa-external-services creat Notă: Când aplicăm resursele Istio, Serverul API Kubernetes creează un eveniment, care este recepționat de Istio Control Plane, iar apoi noua configurație este aplicată proxy-urilor Envoy pentru fiecare pod. Iar controlerul Ingress Gateway se prezintă ca un alt Envoy, configurat în Control Plane. Totul acest lucru arată astfel în diagramă: Configurația Istio-IngressGateway pentru rutarea cererilor Aplicația Sentiment Analysis a devenit disponibilă la http://{EXTERNAL-IP}/. Nu vă faceți griji dacă primiți statusul Not Found: uneori este nevoie de puțin mai mult timp pentru ca configurația să devină efectivă și pentru ca cache-urile Envoy să se actualizeze. Înainte de a continua, lucrați puțin cu aplicația pentru a genera trafic (prezența sa este necesară pentru claritate în acțiunile viitoare — n.tr.). Kiali: observabilitate Pentru a accesa interfața administrativă Kiali, executați următoarea comandă: $ kubectl port-forward $(kubectl get pod -n istio-system -l app=kiali -o jsonpath='{.items[0].metadata.name}') -n istio-system 20001 … și deschideți http://localhost:20001/, logându-vă cu admin/admin. Aici veți găsi multe funcționalități utile, de exemplu, pentru a verifica configurația componentelor Istio, vizualizarea serviciilor pe baza informațiilor colectate în timpul interceptării cererilor de rețea, obținerea răspunsurilor la întrebările „Cine se referă la cine?”, „Cu ce versiune a serviciului apar probleme?” etc. În general, explorați funcționalitățile Kiali înainte de a merge mai departe — la vizualizarea metricilor cu Grafana. Grafana: vizualizarea metricilor Metricile colectate în Istio ajung în Prometheus și sunt vizualizate cu Grafana. Pentru a accesa interfața administrativă Grafana, executați comanda de mai jos, după care deschideți 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 Dând clic pe meniul Acasă din stânga sus și selectând Istio Service Dashboard în colțul din stânga sus, începeți cu serviciul sa-web-app, pentru a vizualiza metricile colectate: Aici ne așteaptă o prezentare goală și complet plictisitoare — conducerea nu va aproba niciodată așa ceva. Hai să creăm o mică sarcină cu următoarea comandă: $ while true; do curl -i http://$EXTERNAL_IP/sentiment -H "Content-type: application/json" -d '{"sentence": "I love yogobella"}'; sleep .8; done Acum avem grafice mult mai atractive, iar în plus, instrumentele excelente Prometheus pentru monitorizare și Grafana pentru vizualizarea metricalor ne vor permite să cunoaștem performanța, starea de sănătate și îmbunătățirile/degradările în funcționarea serviciilor pe parcursul timpului. În cele din urmă, să ne uităm la trasarea cererilor în servicii. Jaeger: trasare Trasarea este necesară, deoarece cu cât avem mai multe servicii, cu atât devine mai complicat să ajungem la cauza unei erori. Să ne uităm la un caz simplu din imaginea de mai jos: Un exemplu tipic de cerere nereușită Cererile vin, eșuează— care este cauza? Primul serviciu? Sau al doilea? Excepții există în ambele—hai să ne uităm la logurile fiecăruia. Cât de des te-ai prins făcând așa ceva? Munca noastră seamănă mai mult cu cea a detectivilor de software, nu cu cea a dezvoltatorilor... Aceasta este o problemă comună în microservicii și se rezolvă cu sisteme de trasare distribuite, în care serviciile transmit între ele un antet unic, după care aceste informații sunt redirecționate către sistemul de trasare, unde sunt corelate cu datele cererii. Iată o ilustrație: Pentru identificarea cererii se utilizează TraceId Istio folosește Jaeger Tracer, care implementează un cadru OpenTracing API independent de furnizor. Accesați interfața Jaeger cu următoarea comandă: $ kubectl port-forward -n istio-system $(kubectl get pod -n istio-system -l app=jaeger -o jsonpath='{.items[0].metadata.name}') 16686 Acum accesați http://localhost:16686/ și alegeți serviciul sa-web-app. Dacă serviciul nu este afișat în meniul derulant—initiați/generați activitate pe pagină și actualizați interfața. După aceea, faceți clic pe butonul Find Traces, care va arăta cele mai recente trasări—alegeți oricare—va apărea informații detaliate pentru toate trasările: Această trasare arată: Cererea ajunge la istio-ingressgateway (acesta este primul contact cu unul dintre servicii, iar pentru cerere se generează un Trace ID), după care gateway-ul direcționează cererea către serviciul sa-web-app. În serviciu sa-web-app cererea este preluată de Envoy sidecar, se creează un „copil” în span (de aceea îl vedem în trasări) și este redirecționată în container sa-web-app. (Span — unitatea logică de lucru în Jaeger, care are un nume, ora de început a operațiunii și durata acesteia. Span-urile pot fi imbricate și ordonate. Un graf orientat aciclic din span-uri formează un trace. — notă de traducere) Aici, cererea este procesată prin metoda sentimentAnalysis. Aceste trace-uri sunt deja generate de aplicație, adică pentru ele au fost necesare modificări în cod. Din acest moment, se inițiază o cerere POST la sa-logic. Trace ID trebuie să fie transmis din sa-web-app. … Notă: La pasul 4, aplicația ar trebui să vadă anteturile generate de Istio și să le transmită în cererile ulterioare, așa cum este ilustrat în imaginea de mai jos: (A) Transmiterea anteturilor este responsabilitatea Istio; (B) Anteturile sunt responsabilitatea serviciilor Istio face cea mai mare parte a muncii, deoarece generează anteturi pentru cererile de intrare, creează span-uri noi în fiecare sidecar și le transmite. Totuși, fără o gestionare a antetelor în interiorul serviciilor, întreaga cale de trasare a cererii va fi pierdută. Este necesar să se țină cont (să se transmită) următoarele antete: x-request-id x-b3-traceid x-b3-spanid x-b3-parentspanid x-b3-sampled x-b3-flags x-ot-span-context Aceasta nu este o sarcină complicată, însă, pentru a simplifica implementarea, există deja multe biblioteci — de exemplu, în serviciul sa-web-app, clientul RestTemplate transmite aceste antete dacă adaugă pur și simplu bibliotecile Jaeger și OpenTracing în dependințele sale. Observați că aplicația Sentiment Analysis demonstrează implementări pe Flask, Spring și ASP.NET Core. Acum, când a devenit clar ce primim „din cutie” (sau aproape „din cutie”), să discutăm problemele de rutare fin reglată, gestionarea traficului de rețea, securitatea etc.! Nota traducătorului.: citiți despre acest lucru în partea următoare a materialelor despre Istio de la Rinor Maloku, traducerile cărora vor urma pe blogul nostru în curând. UPDATE (14 martie): Partea a doua deja publicată. P.S. de la traducător Citiți și în blogul nostru: „Înapoi la microservicii împreună cu Istio”: partea 2 (rutare, gestionarea traficului), partea 3 (autentificare și autorizare); «Conduit — un service mesh ușor pentru Kubernetes»; «Ce este service mesh și de ce am nevoie [pentru aplicații cloud cu microservicii]?»; «Ghid ilustrat pentru structura rețelei în Kubernetes. Părțile 1 și 2»; «Cum a ajuns acest container sidecar aici [în Kubernetes]?». Sursa: habr.com route: - destination: host: sa-frontend # 2 port: number: 80
Aspecte importante:

Acest VirtualService se referă la cererile care vin prin http-gateway;
În destination se determină serviciul către care sunt trimise cererile.

Notă: Configurația de mai sus este stocată într-un fișier sa-virtualservice-external.yaml, care conține de asemenea setările pentru rutare către SA-WebApp și SA-Feedback, dar a fost scurtat aici în articol pentru concizie.

Se aplică VirtualService prin apelul:

Notă: Când aplicăm resursele Istio, serverul API Kubernetes creează un eveniment, care este preluat de Istio Control Plane, iar apoi noua configurație este aplicată proxy-urilor Envoy din fiecare pod. Iar controlerul Ingress Gateway este un alt Envoy, configurat în Control Plane. Toate acestea arată astfel în schemă:

Configurația Istio-IngressGateway pentru rutarea cererilor

Aplicația Sentiment Analysis a devenit disponibilă la http://{EXTERNAL-IP}/. Nu vă faceți griji dacă primiți statusul Not Found: uneori este nevoie de puțin mai mult timp pentru ca configurația să devină efectivă și pentru ca cache-urile Envoy să se actualizeze.

Înainte de a continua, lucrați puțin cu aplicația pentru a genera trafic (prezența sa este necesară pentru claritate în acțiunile viitoare — n.tr.).

Kiali: observabilitate

Pentru a accesa interfața administrativă Kiali, executați următoarea comandă:

… și deschideți http://localhost:20001/, logându-vă cu admin/admin. Aici veți găsi multe funcționalități utile, de exemplu, pentru a verifica configurația componentelor Istio, vizualizarea serviciilor pe baza informațiilor colectate în timpul interceptării cererilor de rețea, obținerea răspunsurilor la întrebările „Cine se referă la cine?”, „Cu ce versiune a serviciului apar probleme?” etc. În general, explorați funcționalitățile Kiali înainte de a merge mai departe — la vizualizarea metricilor cu Grafana.

Grafana: vizualizarea metricilor

Metricile colectate în Istio ajung în Prometheus și sunt vizualizate cu Grafana. Pentru a accesa interfața administrativă Grafana, executați comanda de mai jos, după care deschideți http://localhost:3000/:

Dând clic pe meniul Acasă din stânga sus și selectând Istio Service Dashboard în colțul din stânga sus, începeți cu serviciul sa-web-app, pentru a vizualiza metricile colectate:

Aici ne așteaptă o prezentare goală și complet plictisitoare — conducerea nu va aproba niciodată așa ceva. Hai să creăm o mică sarcină cu următoarea comandă:

Acum avem grafice mult mai atractive, iar în plus, instrumentele excelente Prometheus pentru monitorizare și Grafana pentru vizualizarea metricalor ne vor permite să cunoaștem performanța, starea de sănătate și îmbunătățirile/degradările în funcționarea serviciilor pe parcursul timpului.

În cele din urmă, să ne uităm la trasarea cererilor în servicii.

Jaeger: trasare

Trasarea este necesară, deoarece cu cât avem mai multe servicii, cu atât devine mai complicat să ajungem la cauza unei erori. Să ne uităm la un caz simplu din imaginea de mai jos:

Un exemplu tipic de cerere nereușită

Cererile vin, eșuează— care este cauza? Primul serviciu? Sau al doilea? Excepții există în ambele—hai să ne uităm la logurile fiecăruia. Cât de des te-ai prins făcând așa ceva? Munca noastră seamănă mai mult cu cea a detectivilor de software, nu cu cea a dezvoltatorilor...

Aceasta este o problemă comună în microservicii și se rezolvă cu sisteme de trasare distribuite, în care serviciile transmit între ele un antet unic, după care aceste informații sunt redirecționate către sistemul de trasare, unde sunt corelate cu datele cererii. Iată o ilustrație:

Pentru identificarea cererii se utilizează TraceId

Istio folosește Jaeger Tracer, care implementează un cadru OpenTracing API independent de furnizor. Accesați interfața Jaeger cu următoarea comandă:

Acum accesați http://localhost:16686/ și alegeți serviciul sa-web-app. Dacă serviciul nu este afișat în meniul derulant—initiați/generați activitate pe pagină și actualizați interfața. După aceea, faceți clic pe butonul Find Traces, care va arăta cele mai recente trasări—alegeți oricare—va apărea informații detaliate pentru toate trasările:

Această trasare arată:

Cererea ajunge la istio-ingressgateway (acesta este primul contact cu unul dintre servicii, iar pentru cerere se generează un Trace ID), după care gateway-ul direcționează cererea către serviciul sa-web-app.
În serviciu sa-web-app cererea este preluată de Envoy sidecar, se creează un „copil” în span (de aceea îl vedem în trace-uri) și este redirecționată în container sa-web-app. (Span — unitate logică de lucru în Jaeger, având un nume, timpul de începere a operațiunii și durata acesteia. Span-urile pot fi înglobate și ordonate. Un grafic orientat aciclic din span-uri formează un trace. — nota traducătorului)
Aici, cererea este procesată prin metoda sentimentAnalysis. Aceste trace-uri sunt deja generate de aplicație, adică pentru ele au fost necesare modificări în cod.
Din acest moment, se inițiază o cerere POST la sa-logic. Trace ID trebuie să fie transmis din sa-web-app.
…

Notă: La pasul 4, aplicația ar trebui să vadă anteturile generate de Istio și să le transmită în cererile ulterioare, așa cum este ilustrat în imaginea de mai jos:

(A) Transmiterea anteturilor este responsabilitatea Istio; (B) Anteturile sunt responsabilitatea serviciilor

Istio face marea parte a lucrării, deoarece generează antete pentru cererile de intrare, creează noi span-uri în fiecare sidecar și le trece mai departe. Totuși, fără lucrul cu antetele în interiorul serviciilor, calea completă de trasare a cererii va fi pierdută.

Este necesar să se țină cont (să se transmită) următoarele antete:

Aceasta nu este o sarcină complicată, însă, pentru a simplifica implementarea, există deja multe biblioteci — de exemplu, în serviciul sa-web-app, clientul RestTemplate transmite aceste antete dacă adaugă pur și simplu bibliotecile Jaeger și OpenTracing în dependințele sale.

Observați că aplicația Sentiment Analysis demonstrează implementări pe Flask, Spring și ASP.NET Core.

Acum, când a devenit clar ce primim „din cutie” (sau aproape „din cutie”), să discutăm problemele de rutare fin reglată, gestionarea traficului de rețea, securitatea etc.!

Nota traducătorului.: citiți despre acest lucru în partea următoare a materialelor despre Istio de la Rinor Maloku, traducerile cărora vor urma pe blogul nostru în curând. UPDATE (14 martie): Partea a doua deja publicată.