🥇Tilbage til mikroservices med Istio. Del 1

Bem. overs.: Service meshes er bestemt blevet en relevant løsning i moderne infrastruktur for applikationer, der følger mikrotjenestearkitekturen. Selvom Istio måske er kendt af mange DevOps-ingeniører, er det et ret nyt produkt, som, når det kommer til de muligheder, det tilbyder, kan kræve betydelig tid til at blive fortrolig med. Den tyske ingeniør Rinor Maloku, der står for cloud computing for store kunder i telekommunikationsfirmaet Orange Networks, har skrevet en fremragende serie af materialer, der gør det muligt at dykke hurtigt og dybt ned i Istio. Han begynder sin fortælling med, hvad Istio egentlig kan, og hvordan man hurtigt kan se det med egne øjne.

Istio — Open Source-projekt udviklet i samarbejde mellem teams fra Google, IBM og Lyft. Det løser kompleksiteter, der opstår i applikationer baseret på mikrotjenester, såsom:

Trafikstyring: timeout, genforsøg, belastningsfordeling;
Sikkerhed: autentificering og autorisering af slutbrugeren;
Observabilitet: sporing, overvågning, logning.

Alle disse kan løses på applikationsniveau, men herefter vil dine tjenester ikke længere være "mikro". Alle de ekstra bestræbelser på at løse disse problemer er en overflødig omkostning for virksomheden, som kunne bruges direkte til forretningsværdi. Lad os overveje et eksempel:

Projektleder: Hvor lang tid tager det at tilføje feedbackmuligheden?
Udvikler: To sprint.
PL: Hvad?.. Det er jo bare CRUD!
U: At lave CRUD er den nemme del af opgaven, men vi skal også autentificere og autorisere brugere og tjenester. Da netværket er upålideligt, er det nødvendigt at implementere genforsøg, samt circuit breaker-mønsteret i klienterne. Desuden, for at sikre, at hele systemet ikke går ned, er der brug for timeouts og bulkheads (læse mere om de to nævnte mønstre senere i artiklen — bem. overs.), og for at opdage problemer, vil der være behov for overvågning, sporing, [...]
PL: Åh, lad os så bare indsætte denne funktion i Product-tjenesten.

Jeg tror, at ideen er klar: mængden af trin og indsats, der kræves for at tilføje en service, er enorm. I denne artikel vil vi se på, hvordan Istio fjerner alle de nævnte vanskeligheder (som ikke er målrettet mod forretningslogikken) fra tjenesterne.

Bemærk: Artiklen forudsætter, at du har praktisk viden om Kubernetes. Ellers anbefaler jeg at læse min introduktion til Kubernetes og først derefter fortsætte med læsningen af dette materiale.

Ideen bag Istio

I en verden uden Istio laver en service direkte anmodninger til en anden, og i tilfælde af fejl skal tjenesten selv håndtere det: prøve igen, forudse timeout, åbne circuit breaker osv.

Netværkstrafik i Kubernetes

Istio tilbyder derimod en specialiseret løsning, der er helt adskilt fra tjenesterne og fungerer ved at intervenere i det netværksmæssige samspil. Og på den måde realiserer den:

Fejltolerance: ved at stole på statuskoden i svaret forstår den, om der opstod en fejl i anmodningen, og udfører den igen.
Canary deployments: omdirigerer kun en fast procentdel af anmodningerne til den nye version af servicen.
Overvågning og metrics: hvor hurtigt svarede tjenesten?
Tracing og observabilitet: tilføjer specielle headers i hver anmodning og udfører tracing i klyngen.
Sikkerhed: udtrækker JWT-token, godkender og autoriserer brugere.

Dette er kun nogle af mulighederne (faktisk kun nogle få!), for at vække din interesse. Lad os nu dykke ned i de tekniske detaljer!

Istio-arkitektur

Istio opsnapper al netværkstrafik og anvender et sæt regler ved at indsætte en intelligent proxy i hver pod i form af en sidecar-container. Proxies, der aktiverer alle funktionerne, danner Data Plane, og de kan dynamisk konfigureres ved hjælp af Control Plane.

Data Plane

De proxies, der indsættes i pods, gør det muligt for Istio nemt at opfylde de ønskede krav. For eksempel vil vi kontrollere funktionerne for retries og circuit breaker.

Hvordan retries og circuit breaking implementeres i Envoy

Lad os opsummere:

Envoy (det handler om proxien i sidecar-containeren, som også distribueres som et separat produkt — red. anm.) sender anmodningen til den første instans af service B, og der opstår en fejl.
Envoy Sidecar forsøger at udføre en ny anmodning (retry). (1)
Anmodningen med fejlen returneres til den proxy, der udløste den.
Sådan åbnes Circuit Breaker, og den næste service kaldes for de følgende forespørgsler. (2)

Det betyder, at du ikke behøver at bruge et andet Retry-bibliotek, ikke behøver at lave din egen implementering af Circuit Breaking og Service Discovery i programmeringssproget X, Y eller Z. Alt dette og meget mere er tilgængeligt lige ud af boksen i Istio og kræver ikke nogen ændringer i koden.

Fantastisk! Nu kan du tænke på at tage på en rejse med Istio, men der er stadig nogle tvivl, åbne spørgsmål. Hvis det er en universel løsning for alle situationer, kan du have en berettiget mistanke: for sådanne løsninger viser sig ofte ikke at være passende i nogen situation.

Og til sidst vil du spørge: "Kan det konfigureres?"

Nu er du klar til sørejsen — lad os lære Control Plane at kende.

Control Plane

Det består af tre komponenter: Pilot, Mixer og Citadel, — som i fællesskab konfigurerer Envoy'er til at rute trafik, anvende politikker og indsamle telemetrisk data. Schemati ser alt dette sådan ud:

Interaktion mellem Control Plane og Data Plane

Envoy'er (dvs. data plane) er konfigureret ved hjælp af Kubernetes CRD (Custom Resource Definitions), defineret af Istio og specielt beregnet til dette formål. For dig betyder det, at de præsenteres som en anden ressource i Kubernetes med velkendt syntaks. Efter oprettelse vil denne ressource blive tilpasset af control plane og anvendt på Envoy'er.

Forholdet mellem tjenester og Istio

Vi har beskrevet forholdet mellem Istio og tjenester, men ikke det omvendte: hvordan har tjenesterne det med Istio?

Ærligt talt er tjenesterne lige så godt klar over Istios tilstedeværelse, som fiskene er klar over vandet, når de spørger sig selv: "Hvad er egentlig vand?"

Illustration Victoria Dimitrakopoulos: — Hvordan har du det med vand? — Hvad er egentlig vand?

Således kan du tage en fungerende klynge, og efter implementeringen af Istio-komponenterne vil de tjenester, der er i den, fortsætte med at fungere, og efter fjernelse af disse komponenter vil alt være godt igen. Klart, at du i mellemtiden mister de muligheder, som Istio tilbyder.

Det er nok teori — lad os omsætte denne viden til praksis!

Istio i praksis

Istio kræver en Kubernetes-klynge, hvor der som minimum er 4 vCPU og 8 GB RAM tilgængeligt. For hurtigt at opsætte en klynge og følge instruktionerne fra artiklen, anbefaler jeg at bruge Google Cloud Platform, som tilbyder nye brugere gratis $300.

Efter oprettelse af klyngen og opsætning af adgang til Kubernetes via kommandolinjeværktøjet kan du installere Istio via pakkehåndtereren Helm.

Installation af Helm

Installer Helm-klienten på din computer som beskrevet i den officielle dokumentation. Vi vil bruge den til at generere skabeloner til installationen af Istio i det næste afsnit.

Installation af Istio

Download Istio-ressourcerne fra den seneste udgivelse (det originale link til version 1.0.5 er opdateret til den aktuelle, dvs. 1.0.6 — bem. red.), udpak indholdet i en mappe, som jeg vil referere til som [istio-resources].

For nem identifikation af Istio-ressourcerne skal du oprette et namespaces i K8s-klyngen istio-system:

$ kubectl create namespace istio-system

Fuldfør installationen ved at gå til kataloget [istio-resources] og køre kommandoen:

$ 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

Denne kommando vil udskrive de centrale komponenter af Istio til en fil istio.yaml. Vi har ændret den standard skabelon, så den passer til os, ved at specificere følgende parametre:

global.mtls.enabled sat til false (dvs. mTLS-autentificering er deaktivert — bem. red.), for at forsimple vores introduktion;
tracing.enabled aktiverer sporingsanmodninger ved hjælp af Jaeger;
kiali.enabled installerer Kiali i klyngen for visualisering af tjenester og trafik;
grafana.enabled installerer Grafana for visualisering af indsamlede metrikker.

Vi anvender de genererede ressourcer med kommandoen:

$ kubectl apply -f istio.yaml

Installation af Istio i klyngen er fuldført! Vent på, at alle pod'er i namespaces istio-system er i tilstanden Kørende eller Completed, ved at køre kommandoen nedenfor:

$ kubectl get pods -n istio-system

Nu er vi klar til at fortsætte i det næste afsnit, hvor vi vil starte og køre applikationen.

Arkitektur for applikationen Sentiment Analysis

Vi vil bruge et eksempel på applikationen Sentiment Analysis, der blev nævnt i den tidligere introduktionsartikel til Kubernetes. Den er tilstrækkeligt kompleks til at demonstrere Istios muligheder i praksis.

Applikationen består af fire mikrotjenester:

Service SA-Frontend, der betjener frontend-applikationen i Reactjs;
Service SA-WebApp, der håndterer anmodninger om Sentiment Analysis;
Service SA-Logic, der udfører selve sentimentanalysen;;
Service SA-Feedback, der modtager feedback fra brugerne om nøjagtigheden af analysen.

I denne skitse ser vi udover tjenesterne også Ingress Controller, som i Kubernetes dirigerer indkommende forespørgsler til de relevante tjenester. I Istio anvendes et lignende koncept inden for Ingress Gateway, hvis detaljer følger.

Start af applikationen med Istio-proxy

For de følgende operationer, der nævnes i artiklen, skal du klone repository'et til dig selv istio-mastery. Det indeholder applikationen og manifesterne til Kubernetes og Istio.

Indsættelse af sidecar'er

Indsættelsen kan udføres automatisk eller manuelt. For automatisk indsættelse af sidecar-containere skal du sætte et label på navnerummet istio-injection=enabled, hvilket gøres med følgende kommando:

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

Nu vil hver pod, der deployeres i standard-navnerummet (default) få sin egen sidecar-container. For at bekræfte dette, lad os deployere en testapplikation ved at gå til rodmappen i repository'et . I denne gren er frontend-koden ændret, så brugere omdirigeres til Auth0 for autentificering og bruger JWT-token i forespørgsler til de øvrige tjenester. Den sidstnævnte er implementeret som følger ( og udføre følgende kommando:

$ 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

Efter at have deployeret tjenesterne, lad os tjekke, at pod'ene har to containere (selve tjenesten og dens sidecar) ved at køre kommandoen kubectl get pods og bekræfte, at under kolonnen READY er angivet værdien 2/2, som symboliserer, at begge containere kører:

$ 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

Visuelt ser dette sådan ud:

Envoy-proxy i en af pod'ene

Nu, når applikationen er oppe og kører, skal vi tillade indkommende trafik at komme ind i applikationen.

Ingress Gateway

Den bedste praksis for at opnå dette (tillade trafik i klyngen) er gennem Ingress Gateway i Istio, som ligger ved "grænsen" af klyngen og gør det muligt at inkludere funktioner som routing, load balancing, sikkerhed og overvågning for indkommende trafik.

Komponenten Ingress Gateway og tjenesten, der eksponerer den udadtil, blev installeret i klyngen under installationen af Istio. For at finde den eksterne IP-adresse for tjenesten, udfør:

$ kubectl get svc -n istio-system -l istio=ingressgateway
NAVN                   TYPE           CLUSTER-IP     EXTERNAL-IP
istio-ingressgateway   LoadBalancer   10.0.132.127   13.93.30.120

Vi vil tilgå applikationen via denne IP, som jeg fremover vil omtale som EXTERNAL-IP, så for nemheds skyld noterer vi værdien i en variabel:

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

Hvis du prøver at tilgå denne IP i din browser nu, vil du få fejlmeddelelsen Service Unavailable, fordi Istio som standard blokerer al indkommende trafik, indtil en Gateway er defineret.

Resource Gateway

Gateway er en CRD (Custom Resource Definition) i Kubernetes, der defineres efter installationen af Istio i klyngen og aktiverer muligheden for at angive porte, protokoller og værter, som vi ønsker at tillade indkommende trafik til.

I vores tilfælde ønsker vi at tillade HTTP-trafik på port 80 for alle værter. Opgaven implementeres med følgende definition (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:
- "*"

Denne konfiguration kræver ikke forklaring bortset fra sælgeren istio: ingressgateway. Med denne selector kan vi angive, hvilken Ingress Gateway konfigurationen skal anvendes på. I vores tilfælde er det kontrolpanelet Ingress Gateway, der er installeret som standard i Istio.

Konfigurationen anvendes ved at kalde den følgende kommando:

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

Nu tillader gateway adgang til port 80, men har ingen viden om, hvor den skal lede anmodningerne hen. For dette vil der være brug for Virtual Services.

Resource VirtualService

VirtualService angiver Ingress Gateway, hvordan den skal rute anmodninger, der er tilladt indeni klyngen.

Anmodninger til vores applikation, der kommer gennem http-gateway, skal sendes til tjenesterne sa-frontend, sa-web-app og sa-feedback:

Ruter, der skal konfigureres med VirtualServices

Lad os se på de anmodninger, der skal henvises til SA-Frontend:

Præcist match på stien / skal sendes til SA-Frontend for at hente index.html;
Stier med præfiks /static/* skal sendes til SA-Frontend for at hente statiske filer, der anvendes på frontenden, såsom CSS og JavaScript;
Stier, der falder ind under det regulære udtryk '^.*.(ico|png|jpg)$', skal sendes til SA-Frontend, da dette er billeder, der vises på siden.

Implementeringen opnås med følgende konfiguration (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) Vigtige punkter: Denne VirtualService vedrører anmodninger, der kommer gennem http-gateway; I destination bestemmes af tjenesten, hvorhenhen anmodningerne sendes. Bemærk: Konfigurationen ovenfor gemmes i filen sa-virtualservice-external.yaml, som også indeholder indstillinger til routing i SA-WebApp og SA-Feedback, men er her forkortet i artiklen for korthedens skyld. Vi anvender VirtualService med følgende kald: $ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml virtualservice.networking.istio.io/sa-external-services oprettet Bemærk: Når vi anvender Istio-ressourcer, genererer Kubernetes API-serveren en begivenhed, som modtages af Istio Control Plane, og derefter anvendes den nye konfiguration på proxy-serverne Envoy i hver pod. Og Ingress Gateway-controlleren præsenteres som en anden Envoy, der er konfigureret i Control Plane. Alt dette ser således ud i diagrammet: Istio-IngressGateway konfiguration til routing af anmodninger Applikationen Sentiment Analysis er blevet tilgængelig på http://{EXTERNAL-IP}/. Bekymr dig ikke, hvis du får status Not Found: nogle gange kræver det lidt mere tid, før konfigurationen træder i kraft og Envoy-cache opdateres. Før du fortsætter, skal du arbejde lidt med applikationen for at generere trafik (dets tilstedeværelse er nødvendigt for tydelighed i de kommende handlinger — bem. red.). Kiali : observabilitet For at få adgang til Kiali's administrationsgrænseflade, udfør følgende kommando: $ kubectl port-forward $(kubectl get pod -n istio-system -l app=kiali -o jsonpath='{.items[0].metadata.name}') -n istio-system 20001 … og åbne http://localhost:20001/, log ind som admin/admin. Her finder du mange nyttige funktioner, såsom at kontrollere konfigurationen af Istio-komponenter, visualisering af tjenester baseret på information indsamlet under indfangning af netværksanmodninger, få svar på spørgsmål som 'Hvem kontakter hvem?' og 'Hvilken version af tjenesten har problemer?' osv. Generelt skal du udforske Kiali's muligheder, før du går videre til visualisering af metrics med Grafana. Grafana: visualisering af metrics Metrics indsamlet i Istio sendes til Prometheus og visualiseres med Grafana. For at få adgang til Grafana's administrationsgrænseflade, udfør nedenstående kommando, hvorefter du åbner 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 Klik på menuen Home øverst til venstre og vælg Istio Service Dashboard i øverste venstre hjørne, start med tjenesten sa-web-app, for at se de indsamlede metrics: Her venter en tom og helt kedelig visning — vejledningen ville aldrig godkende det. Lad os skabe en lille belastning med følgende kommando: $ while true; do curl -i http://$EXTERNAL_IP/sentiment -H "Content-type: application/json" -d '{"sentence": "Jeg elsker yogobella"}'; sleep .8; done Nu har vi meget pænere grafer, og derudover fantastiske værktøjer som Prometheus til overvågning og Grafana til visualisering af metrics, som giver os mulighed for at forstå ydeevne, sundhed, forbedringer/nedbringelser i servicernes drift over tid. Lad os endelig se på anmodningens tracing i tjenesterne. Jaeger : tracing Tracing vil være nødvendigt, fordi jo flere tjenester vi har, desto vanskeligere bliver det at finde årsagen til en fejl. Lad os se på et enkelt tilfælde fra billedet nedenfor: Et typisk eksempel på en tilfældig mislykket anmodning Anmodningen kommer ind, falder — hvad er grunden? Den første tjeneste? Eller den anden? Der er undtagelser i begge — lad os kigge på loggene fra hver. Hvor ofte har du fanget dig selv i sådan en aktivitet? Vores arbejde ligner mere softwaredetektiver end udviklere… Dette er et udbredt problem i mikrotjenester, som løses ved hjælp af distribuerede tracesystemer, hvor tjenesterne overfører en unik header til hinanden, hvorefter disse oplysninger videresendes til tracing-systemet, hvor de matches med anmodningsdataene. Her er en illustration: TraceId bruges til at identificere anmodningen I Istio anvendes Jaeger Tracer, som implementerer en leverandøruafhængig OpenTracing API. For at få adgang til Jaeger-brugergrænsefladen kan du bruge følgende kommando: $ kubectl port-forward -n istio-system $(kubectl get pod -n istio-system -l app=jaeger -o jsonpath='{.items[0].metadata.name}') 16686 Gå nu til http://localhost:16686/ og vælg tjenesten sa-web-app. Hvis tjenesten ikke vises i drop-down menuen — generer/generér aktivitet på siden og opdater grænsefladen. Derefter skal du klikke på knappen Find Traces, som viser de seneste traces — vælg en hvilken som helst — der vil vises detaljerede oplysninger om alle traces: Denne trace viser: Anmodningen kommer til istio-ingressgateway (dette er den første interaction med en af tjenesterne, og Trace ID genereres for anmodningen), hvorefter gatewayen sender anmodningen til tjenesten sa-web-app. I tjenesten sa-web-app opfanges anmodningen af Envoy sidecar'en, der opretter et «barn» i span'en (derfor ser vi den i traces) og videresender til containeren sa-web-app. (Span — en logisk enhed af arbejde i Jaeger, der har et navn, starttidspunkt for operationen og dens varighed. Spans kan være indlejrede og ordnede. En orienteret acyklisk graf af spans danner trace. — bem. overs. Her behandles anmodningen ved hjælp af metoden sentimentAnalysis. Disse traces er allerede genereret af applikationen, dvs. der krævedes ændringer i koden. Fra dette tidspunkt igangsættes en POST-anmodning til sa-logic. Trace ID skal overføres fra sa-web-app. … Bemærk: I trin 4 skal applikationen se de headers, der er genereret af Istio, og overføre dem til de efterfølgende anmodninger, som vist på billedet nedenfor: (A) Overførslen af headers håndteres af Istio; (B) Headersne håndteres af tjenesterne Istio udfører det primære arbejde, da det genererer headers for indkommende anmodninger, opretter nye spans i hver sidecar og overfører dem. Men uden at arbejde med headers inden for tjenesterne vil den komplette sporingsbane for anmodningen gå tabt. Det er nødvendigt at tage højde for (overføre) følgende headers: x-request-id x-b3-traceid x-b3-spanid x-b3-parentspanid x-b3-sampled x-b3-flags x-ot-span-context Dette er en simpel opgave, men for at forenkle implementeringen findes der allerede mange biblioteker — for eksempel overfører RestTemplate-klienten i sa-web-app disse headers, hvis man blot tilføjer bibliotekerne Jaeger og OpenTracing til dets afhængigheder. Bemærk, at applikationen Sentiment Analysis viser implementeringer i Flask, Spring og ASP.NET Core. Nu hvor det er klart, hvad vi får ud af boksen (eller næsten 'ud af boksen'), lad os se på spørgsmålene om fintjusteret routing, netværkstrafikstyring, sikkerhed osv.! Bem. overs.: Læs om dette i den næste del af materialerne om Istio fra Rinor Maloku, hvis oversættelser snart vil følge i vores blog. OPDATERING (14. marts): Den anden del er allerede offentliggjort. P.S. fra oversætteren Læs også på vores blog: «Tilbage til mikrotjenester sammen med Istio»: del 2 (routing, trafikstyring), del 3 (autentifikation og autorisation); «Conduit - et letvægts service mesh til Kubernetes»; «Hvad er et service mesh, og hvorfor har jeg brug for det [til en cloud-applikation med mikrotjenester]?»; «Illustreret guide til opbygningen af netværket i Kubernetes. Del 1 og 2»; «Hvordan denne sidecar-container kom her [i Kubernetes]?». Kilde: habr.com route: - destination: host: sa-frontend # 2 port: number: 80
Vigtige punkter:

Denne VirtualService vedrører anmodninger, der kommer gennem http-gateway;
I destination bestemmes af tjenesten, hvorhenhen anmodningerne sendes.

Bemærk: Konfigurationen ovenfor gemmes i filen sa-virtualservice-external.yaml, som også indeholder indstillinger til routing i SA-WebApp og SA-Feedback, men blev her forkortet i artiklen for kortfattethed.

Anvend VirtualService ved at kalde:

Bemærk: Når vi anvender Istio-ressourcer, skaber Kubernetes API Server en begivenhed, som modtages af Istio Control Plane, og herefter anvendes den nye konfiguration på Envoy-proxy-serverne i hver pod. Kontrolleren Ingress Gateway præsenteres som endnu en Envoy, der er konfigureret i Control Plane. Alt dette ser således ud på skemaet:

Istio-IngressGateway konfiguration til routing af anmodninger

Applikationen Sentiment Analysis er blevet tilgængelig på http://{EXTERNAL-IP}/. Bekymr dig ikke, hvis du får status Not Found: nogle gange kræver det lidt mere tid, før konfigurationen træder i kraft og Envoy-cache opdateres.

Før du fortsætter, skal du arbejde lidt med applikationen for at generere trafik (dets tilstedeværelse er nødvendigt for tydelighed i de kommende handlinger — bem. red.).

Kiali : observabilitet

For at få adgang til Kiali's administrationsgrænseflade, udfør følgende kommando:

… og åbne http://localhost:20001/, log ind som admin/admin. Her finder du mange nyttige funktioner, såsom at kontrollere konfigurationen af Istio-komponenter, visualisering af tjenester baseret på information indsamlet under indfangning af netværksanmodninger, få svar på spørgsmål som 'Hvem kontakter hvem?' og 'Hvilken version af tjenesten har problemer?' osv. Generelt skal du udforske Kiali's muligheder, før du går videre til visualisering af metrics med Grafana.

Grafana: visualisering af metrics

Metrics indsamlet i Istio sendes til Prometheus og visualiseres med Grafana. For at få adgang til Grafana's administrationsgrænseflade, udfør nedenstående kommando, hvorefter du åbner http://localhost:3000/:

Klik på menuen Home øverst til venstre og vælg Istio Service Dashboard i øverste venstre hjørne, start med tjenesten sa-web-app, for at se de indsamlede metrics:

Her venter en tom og helt kedelig visning — vejledningen ville aldrig godkende det. Lad os skabe en lille belastning med følgende kommando:

Nu har vi meget pænere grafer, og derudover fantastiske værktøjer som Prometheus til overvågning og Grafana til visualisering af metrics, som giver os mulighed for at forstå ydeevne, sundhed, forbedringer/nedbringelser i servicernes drift over tid.

Lad os endelig se på anmodningens tracing i tjenesterne.

Jaeger : tracing

Tracing vil være nødvendigt, fordi jo flere tjenester vi har, desto vanskeligere bliver det at finde årsagen til en fejl. Lad os se på et enkelt tilfælde fra billedet nedenfor:

Et typisk eksempel på en tilfældig mislykket anmodning

Anmodningen kommer ind, falder — hvad er grunden? Den første tjeneste? Eller den anden? Der er undtagelser i begge — lad os kigge på loggene fra hver. Hvor ofte har du fanget dig selv i sådan en aktivitet? Vores arbejde ligner mere softwaredetektiver end udviklere…

Dette er et udbredt problem i mikrotjenester, som løses ved hjælp af distribuerede tracesystemer, hvor tjenesterne overfører en unik header til hinanden, hvorefter disse oplysninger videresendes til tracing-systemet, hvor de matches med anmodningsdataene. Her er en illustration:

TraceId bruges til at identificere anmodningen

I Istio anvendes Jaeger Tracer, som implementerer en leverandøruafhængig OpenTracing API. For at få adgang til Jaeger-brugergrænsefladen kan du bruge følgende kommando:

Gå nu til http://localhost:16686/ og vælg tjenesten sa-web-app. Hvis tjenesten ikke vises i drop-down menuen — generer/generér aktivitet på siden og opdater grænsefladen. Derefter skal du klikke på knappen Find Traces, som viser de seneste traces — vælg en hvilken som helst — der vil vises detaljerede oplysninger om alle traces:

Denne trace viser:

Anmodningen kommer til istio-ingressgateway (dette er den første interaction med en af tjenesterne, og Trace ID genereres for anmodningen), hvorefter gatewayen sender anmodningen til tjenesten sa-web-app.
I tjenesten sa-web-app forespørgslen fanges af Envoy sidecar'en, der skaber et «barn» i span'et (derfor ser vi det i sporene) og omdirigeres til containeren sa-web-app. (Span — en logisk arbejdsenhed i Jaeger, der har et navn, starttidspunkt for operationen og dens varighed. Span'er kan være indlejrede og ordnede. En rettet acyklisk graf af span'er danner et trace. — bem. overs.)
Her behandles anmodningen ved hjælp af metoden sentimentAnalysis. Disse traces er allerede genereret af applikationen, dvs. der krævedes ændringer i koden.
Fra dette tidspunkt igangsættes en POST-anmodning til sa-logic. Trace ID skal overføres fra sa-web-app.
…

Bemærk: I trin 4 skal applikationen se de headers, der er genereret af Istio, og overføre dem til de efterfølgende anmodninger, som vist på billedet nedenfor:

(A) Overførslen af headers håndteres af Istio; (B) Headersne håndteres af tjenesterne

Istio udfører hovedarbejdet, da det generaer headers til indgående forespørgsler, skaber nye span'er i hver sidecar og videregiver dem. Men uden arbejde med headers inde i tjenesterne vil den fulde sporingsvej for forespørgslen gå tabt.

Det er nødvendigt at tage højde for (overføre) følgende headers:

Dette er en simpel opgave, men for at forenkle implementeringen findes der allerede mange biblioteker — for eksempel overfører RestTemplate-klienten i sa-web-app disse headers, hvis man blot tilføjer bibliotekerne Jaeger og OpenTracing til dets afhængigheder.

Bemærk, at applikationen Sentiment Analysis viser implementeringer i Flask, Spring og ASP.NET Core.

Nu hvor det er klart, hvad vi får ud af boksen (eller næsten 'ud af boksen'), lad os se på spørgsmålene om fintjusteret routing, netværkstrafikstyring, sikkerhed osv.!

Bem. overs.: Læs om dette i den næste del af materialerne om Istio fra Rinor Maloku, hvis oversættelser snart vil følge i vores blog. OPDATERING (14. marts): Den anden del er allerede offentliggjort.