🥇Terug naar microservices met Istio. Deel 1

Opmerking vertaler.: Service mesh is definitely becoming a relevant solution in the modern infrastructure for applications following a microservices architecture. Although Istio may be familiar to many DevOps engineers, it is a relatively new product that, because of its comprehensive capabilities, may require a significant amount of time to get acquainted with. German engineer Rinor Maloku, who is responsible for cloud computing for major clients at the telecommunications company Orange Networks, has written an excellent series of materials that allow for a swift and deep dive into Istio. He begins his discussion by explaining what Istio can do and how to quickly glance at it firsthand.

Istio — An open-source project developed in collaboration by teams from Google, IBM, and Lyft. It addresses complexities that arise in microservices-based applications, such as:

Verkeersbeheer: timeouts, retries, load balancing;
Beveiliging: authentication and authorization of end users;
Observability: tracing, monitoring, logging.

All of these can be addressed at the application level; however, this would cause your services to no longer be 'micro'. All additional efforts to solve these problems are extra resource expenditures for the company, which could be used directly for business value. Let's consider an example:

Project Manager: How long will it take to add feedback functionality?
Developer: Two sprints.
PM: What?.. It's just CRUD!
D: Implementing CRUD is the simple part of the task, but we also need to authenticate and authorize users and services. Since the network is unreliable, we will need to implement retries, as well as the circuit breaker pattern in the clients. Furthermore, to ensure the entire system does not crash, timeouts and bulkheads (for more on both mentioned patterns, see later in the article — note by translator), and to detect problems, monitoring and tracing will be necessary, […]
PM: Oh, let's just embed this feature into the Product service.

I think the idea is clear: the volume of steps and efforts required to add a single service is enormous. In this article, we will explore how Istio eliminates all the aforementioned complexities (which are not intended for business logic) from services.

Opmerking: Dit artikel gaat ervan uit dat je praktische kennis van Kubernetes hebt. Zo niet, raad ik aan om te beginnen met mijn inleiding tot Kubernetes en pas daarna door te gaan met het lezen van dit materiaal.

Het idee van Istio

In een wereld zonder Istio maakt de ene service directe aanvragen naar de andere, en in het geval van een storing moet de service dit zelf afhandelen: een nieuwe poging doen, een time-out instellen, een circuit breaker openen, enz.

Netwerkverkeer in Kubernetes

Istio biedt daarentegen een gespecialiseerde oplossing, volledig gescheiden van de services, die werkt door in te grijpen in de netwerkcommunicatie. En zo biedt het:

Resilience: gebaseerd op de statuscode in het antwoord, begrijpt het of er een storing in de aanvraag heeft plaatsgevonden, en herhaalt deze.
Canary-releases: leidt slechts een vast percentage van de aanvragen naar de nieuwe versie van de service.
Monitoring en metrics: hoe snel heeft de service geantwoord?
Tracing en observability: voegt speciale headers toe aan elke aanvraag en volgt deze in het cluster.
Beveiliging: haalt de JWT-token op, authenticeert en autoriseert gebruikers.

Dit zijn slechts enkele van de mogelijkheden (echt slechts enkele!), om je nieuwsgierig te maken. Laten we nu in de technische details duiken!

Architectuur van Istio

Istio onderschept al het netwerkverkeer en past een set regels toe, waarbij in elke pod een slimme proxy in de vorm van een sidecar-container wordt geplaatst. De proxies die alle mogelijkheden activeren, vormen Data Plane, en ze kunnen dynamisch worden geconfigureerd met behulp van Control Plane.

Data Plane

De in pods geplaatste proxies stellen Istio in staat om gemakkelijk aan de vereiste eisen te voldoen. Laten we bijvoorbeeld de functies voor retries en circuit breaking controleren.

Hoe retries en circuit breaking zijn geïmplementeerd in Envoy

Samenvattend:

Envoy (het gaat over de proxy die zich in de sidecar-container bevindt, die ook wordt verspreid als een apart product – opmerking vert.) stuurt de aanvraag naar de eerste instantie van service B en er treedt een storing op.
Envoy Sidecar doet een herhaal poging (retry). (1)
De mislukt verzoek wordt teruggestuurd naar de proxy die het heeft aangeroepen.
Zo opent Circuit Breaker en wordt de volgende service aangeroepen voor de komende aanvragen. (2)

Dit betekent dat je geen extra Retry-bibliotheek hoeft te gebruiken, geen eigen implementatie van Circuit Breaking en Service Discovery in programmeertalen zoals X, Y of Z hoeft te maken. Dit alles en nog veel meer is standaard beschikbaar in Istio en vereist geen wijzigingen in de code. Geweldig! Nu wil je misschien op avontuur met Istio, maar er blijven nog enkele twijfels en open vragen bestaan. Als dit een universele oplossing voor alle situaties is, ontstaat er een logische vraag: zijn dergelijke oplossingen in werkelijkheid niet geschikt voor enige situatie?

En dan vraag je je eindelijk af: "Is het configureerbaar?"

Nu ben je klaar voor een zeereis — laten we kennismaken met het Control Plane.

Het bestaat uit drie componenten:

Control Plane

Pilot Mixer, Citadel en , — die gezamenlijk de Envoys configureren voor traffic routing, beleidsregels toepassen en telemetriegegevens verzamelen. Diagrammatig ziet dit er als volgt uit:Interacties tussen het Control Plane en het Data Plane

Envoys (d.w.z. data plane) zijn geconfigureerd met behulp van

Kubernetes CRD (Custom Resource Definitions), die door Istio zijn gedefinieerd en speciaal voor dit doel zijn ontworpen. Voor jou betekent dit dat ze worden gepresenteerd als een gewoon resource in Kubernetes met een vertrouwde syntaxis. Na creatie zal deze resource worden opgepikt door het control plane en toegepast op de Envoys. De relatie van services met Istio

We hebben de relatie van Istio met de services beschreven, maar niet omgekeerd: hoe staan de services tegenover Istio?

Eerlijk gezegd zijn de services zich van Istio even goed bewust als vissen van water, wanneer ze zichzelf afvragen: "Wat is eigenlijk water?"

Illustratie

Victoria Dimitrakopoulos : — Hoe vindt je het water? — Wat is eigenlijk water?Dus je kunt een werkcluster nemen en, nadat je de componenten van Istio hebt gedeployed, blijven de services daarin werken, en nadat je deze componenten hebt verwijderd, zal alles weer goed zijn. Begrijpelijk dat je dan de mogelijkheden die Istio biedt verliest.

Voldoende theorie — laten we deze kennis in de praktijk brengen!

Istio in de praktijk

Istio vereist een Kubernetes-cluster, waarin minimaal 4 vCPU en 8 GB RAM beschikbaar zijn. Om snel een cluster op te zetten en de instructies uit het artikel te volgen, raad ik aan Google Cloud Platform te gebruiken, dat nieuwe gebruikers

gratis $300 aanbiedt. gratis $300.

Na het creëren van het cluster en het instellen van de toegang tot Kubernetes via de command-line tool, kunt u Istio installeren via de package manager Helm.

Instelling Helm

Installeer de Helm-client op uw computer, zoals beschreven in de officiële documentatie. Deze zullen we gebruiken voor het genereren van sjablonen voor de installatie van Istio in de volgende sectie.

Instelling Istio

Download de Istio-resources van de laatste release (de originele link naar versie 1.0.5 is veranderd naar de actuele, namelijk 1.0.6 — red.), pak de inhoud uit in één map, die ik verder zal noemen [istio-resources].

Om de Istio-resources eenvoudig te identificeren, maakt u in het K8s-cluster een namespace aan istio-system:

$ kubectl create namespace istio-system

Voltooi de installatie door naar de map te gaan [istio-resources] en het volgende commando uit te voeren:

$ 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

Dit commando zal de belangrijkste componenten van Istio in een bestand genereren istio.yaml. We hebben de standaard sjabloon aangepast door de volgende parameters op te geven:

global.mtls.enabled is ingesteld op false (dwz mTLS-authenticatie is uitgeschakeld — red.), om ons kennismakingsproces te vereenvoudigen;
tracing.enabled schakelt verzoek tracing in met behulp van Jaeger;
kiali.enabled installeert Kiali in het cluster voor visualisatie van services en verkeer;
grafana.enabled installeert Grafana voor visualisatie van verzamelde metrics.

We passen de gegenereerde resources toe met het commando:

$ kubectl apply -f istio.yaml

De installatie van Istio in het cluster is voltooid! Wacht tot alle pods in de namespace istio-system in de status zijn Running of Completed, door het onderstaande commando uit te voeren:

$ kubectl get pods -n istio-system

Nu zijn we klaar om verder te gaan in de volgende sectie, waar we de applicatie zullen opzetten en starten.

Architectuur van de applicatie Sentiment Analysis

We nemen het voorbeeld van de microservices-applicatie Sentiment Analysis, die is gebruikt in het eerder genoemde inleidende artikel over Kubernetes. Het is complex genoeg om de mogelijkheden van Istio in de praktijk te demonstreren.

De applicatie bestaat uit vier microservices:

Dienst SA-Frontend, die de frontend van de applicatie op Reactjs bedient;
Dienst SA-WebApp, die de verzoeken voor Sentiment Analysis afhandelt;
Dienst SA-Logic, die de sentiment-analyse uitvoert;;
Dienst SA-Feedback, die feedback van gebruikers ontvangt over de nauwkeurigheid van de uitgevoerde analyse.

In dit schema zien we naast de services ook de Ingress Controller, die in Kubernetes binnenkomende verzoeken naar de bijbehorende services leidt. In Istio wordt een soortgelijke concept gebruikt binnen de Ingress Gateway, waarover meer details zullen volgen.

Een applicatie starten met Istio proxy

Voor verdere operaties die in het artikel worden genoemd, clone de repository naar jezelf istio-mastery. Deze bevat de applicatie en de manifesten voor Kubernetes en Istio.

Invoegen van sidecars

Invoegen kan gebeuren automatisch of handmatig. Voor automatische invoeging van sidecar-containers moet de namespace een label krijgen istio-injection=enabled, wat gedaan kan worden met de volgende opdracht:

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

Nu krijgt elke pod die wordt uitgerold in de standaard namespace (default) zijn eigen sidecar-container. Om dit te verifiëren, laten we een testapplicatie implementeren door naar de rootmap van de repository te gaan . In deze tak is de frontend-code gewijzigd om gebruikers naar Auth0 te omleiden voor authenticatie en om de JWT-token te gebruiken in verzoeken naar de andere services. Dit is de implementatie ( en de volgende opdracht uit te voeren:

$ kubectl apply -f resource-manifests/kube
persistentvolumeclaim/sqlite-pvc aangemaakt
deployment.extensions/sa-feedback aangemaakt
service/sa-feedback aangemaakt
deployment.extensions/sa-frontend aangemaakt
service/sa-frontend aangemaakt
deployment.extensions/sa-logic aangemaakt
service/sa-logic aangemaakt
deployment.extensions/sa-web-app aangemaakt
service/sa-web-app aangemaakt

Nadat we de services hebben uitgerold, controleren we of de pods twee containers hebben (de service zelf en zijn sidecar) door de opdracht uit te voeren kubectl get pods en ervoor te zorgen dat onder de kolom READY de waarde is aangegeven 2/2, wat betekent dat beide containers draaien:

$ 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

Visueel komt dit zo over:

Envoy proxy in een van de pods

Nu het applicatie is gestart en functioneert, moeten we binnenkomend verkeer toestaan in de applicatie.

Ingress Gateway

De beste praktijk om dit te bereiken (verkeer in de cluster toestaan) is via Ingress Gateway in Istio, dat zich aan de 'grens' van de cluster bevindt en het mogelijk maakt om functies van Istio zoals routing, load balancing, beveiliging en monitoring in te schakelen voor binnenkomend verkeer.

De Ingress Gateway-component en de service die deze extern doorgeeft, zijn tijdens de installatie van Istio in de cluster geïnstalleerd. Om het externe IP-adres van de service te achterhalen, voer het volgende uit:

$ 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

We zullen applicatie via dit IP aanspreken en verder (ik zal het als EXTERNAL-IP aanduiden), daarom noteren we de waarde voor gemak in een variabele:

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

Als je nu probeert deze IP via een browser te bezoeken, krijg je een foutmelding Service Unavailable, omdat standaard Istio al het inkomend verkeer blokkeert, totdat er een Gateway is vastgesteld.

Gateway Resource

Gateway is een CRD (Custom Resource Definition) in Kubernetes, die wordt gedefinieerd na de installatie van Istio in de cluster en activeert de mogelijkheid om poorten, protocollen en hosts op te geven waarvoor we inkomend verkeer willen toestaan.

In ons geval willen we HTTP-verkeer op poort 80 voor alle hosts toestaan. Deze taak wordt gerealiseerd met de volgende definitie (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:
- "*"

Deze configuratie behoeft geen uitleg, met uitzondering van de selector istio: ingressgateway. Met deze selector kunnen we aangeven naar welke Ingress Gateway de configuratie moet worden toegepast. In ons geval is dit de Ingress Gateway-controller die standaard in Istio is geïnstalleerd.

De configuratie wordt toegepast met de volgende opdracht:

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

Nu staat de gateway toegang toe tot poort 80, maar heeft geen idee waar de aanvragen naartoe moeten worden geleid. Hiervoor zijn er nodig Virtual Services.

VirtualService Resource

VirtualService geeft aan de Ingress Gateway hoe aanvragen die binnen de cluster zijn toegestaan, moeten worden gerouteerd.

Aanvragen voor onze applicatie die binnenkomen via http-gateway, moeten worden doorgestuurd naar de services sa-frontend, sa-web-app en sa-feedback:

De routes die geconfigureerd moeten worden met VirtualServices

Laten we kijken naar de aanvragen die moeten worden doorgestuurd naar SA-Frontend:

Exacte padmatching / moet worden doorgestuurd naar SA-Frontend voor index.html;
Paden met een prefix /static/* moeten worden doorgestuurd naar SA-Frontend voor het verkrijgen van statische bestanden die in de frontend worden gebruikt, zoals CSS en JavaScript;
Paden die voldoen aan de reguliere uitdrukking '^.*.(ico|png|jpg)$', moeten worden doorgestuurd naar SA-Frontend, omdat dit afbeeldingen zijn die op de pagina worden weergegeven.

De implementatie wordt bereikt met de volgende configuratie (sa-virtualservice-external.yaml):

soort: VirtualService metadata: naam: sa-external-services spec: hosts: - "*" gateways: - http-gateway # 1 http: - match: - uri: exact: \/ - uri: exact: \/callback - uri: prefix: \/static - uri: regex: '^.*.(ico|png|jpg) Belangrijke punten: Deze VirtualService is van toepassing op verzoeken die binnenkomen via http-gateway; In destination het wordt bepaald door de service waarheen de verzoeken worden verzonden. Opmerking: De bovenstaande configuratie wordt opgeslagen in het bestand sa-virtualservice-external.yaml, dat ook instellingen bevat voor routering in SA-WebApp en SA-Feedback, maar hier in het artikel is het ingekort voor beknoptheid. We passen VirtualService toe door de aanroep: $ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml virtualservice.networking.istio.io/sa-external-services is gemaakt Opmerking: Wanneer we de Istio-resources toepassen, creëert de Kubernetes API Server een gebeurtenis die door het Istio Control Plane wordt ontvangen, en pas daarna wordt de nieuwe configuratie toegepast op de Envoy-proxy's van elke pod. De Ingress Gateway-controller verschijnt als een andere Envoy, geconfigureerd in het Control Plane. Dit ziet er op de diagram zo uit: Istio-IngressGateway-configuratie voor het routeren van verzoeken De Sentiment Analysis-applicatie is beschikbaar op http://{EXTERNAL-IP}/. Maak je geen zorgen als je de status Not Found krijgt: soms kost het even wat meer tijd voordat de configuratie van kracht wordt en de Envoy-caches zijn ververst. Voordat je verder gaat, werk een beetje met de applicatie om verkeer te genereren (het aanwezig zijn is nodig voor de duidelijkheid in de volgende acties — opmerking van de vertaler). Kiali: observability Om toegang te krijgen tot de Kiali-beheerinterface, voer de volgende opdracht uit: $ kubectl port-forward $(kubectl get pod -n istio-system -l app=kiali -o jsonpath='{.items[0].metadata.name}') -n istio-system 20001 … en open http://localhost:20001/, en log in met admin/admin. Hier vind je veel nuttige mogelijkheden, bijvoorbeeld om de configuratie van Istio-componenten te controleren, diensten te visualiseren op basis van verzamelde informatie bij het onderscheppen van netwerkverzoeken, het beantwoorden van vragen als ‘Wie vraagt naar wie?’, ‘Bij welke versie van de service treden fouten op?’ enzovoort. Kortom, verken de mogelijkheden van Kiali voordat je verder gaat naar de visualisatie van metrics met Grafana. Grafana: visualisatie van metrics De in Istio verzamelde metrics worden naar Prometheus gestuurd en gevisualiseerd met Grafana. Om toegang te krijgen tot de Grafana-beheerinterface, voer je de onderstaande opdracht uit en open je dan 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 op het menu Home linksboven en kies Istio Service Dashboard in de linkerbovenhoek, begin met de service sa-web-app, om de verzamelde metrics te bekijken: Hier wacht ons een leeg en volledig saai overzicht — de handleiding zou dat nooit goedkeuren. Laten we een kleine belasting creëren met de volgende opdracht: $ while true; do curl -i http://$EXTERNAL_IP/sentiment -H "Content-type: application/json" -d '{"sentence": "Ik hou van yogobella"}'; sleep .8; done Nu hebben we veel mooiere grafieken, en daarnaast geweldige tools van Prometheus voor monitoring en Grafana voor het visualiseren van metrics, die ons in staat stellen om de prestaties, gezondheid, verbeteringen/degradaties van de services in de loop van de tijd te begrijpen. Laten we eindelijk eens kijken naar de tracering van verzoeken in de services. Jaeger: tracering Tracering is nodig omdat, naarmate we meer services hebben, het moeilijker wordt om de oorzaak van een fout te achterhalen. Laten we kijken naar een eenvoudig voorbeeld in de afbeelding hieronder: Typisch voorbeeld van een willekeurig mislukt verzoek Het verzoek komt binnen, faalt - wat is de oorzaak? De eerste service? Of de tweede? Uitzonderingen zijn er in beide - laten we de logs van elk bekijken. Hoe vaak bent u zichzelf hierin betrapt? Ons werk lijkt meer op dat van softwaredetectives dan op dat van ontwikkelaars... Dit is een veelvoorkomend probleem in microservices en het wordt opgelost door gedistribueerde tracingsystemen, waarin services elkaar een unieke kop geven, waarna deze informatie naar het tracingsysteem wordt doorgestuurd, waar het wordt gekoppeld aan de gegevens van het verzoek. Hier is een illustratie: TraceId wordt gebruikt voor het identificeren van het verzoek In Istio wordt de Jaeger Tracer gebruikt, die een vendor-onafhankelijke OpenTracing API-framework implementeert. Toegang tot de gebruikersinterface van Jaeger kan met de volgende opdracht worden verkregen: $ kubectl port-forward -n istio-system $(kubectl get pod -n istio-system -l app=jaeger -o jsonpath='{.items[0].metadata.name}') 16686 Ga nu naar http://localhost:16686/ en selecteer de service sa-web-app. Als de service niet wordt weergegeven in het dropdownmenu, genereer dan activiteit op de pagina en vernieuw de interface. Klik daarna op de knop Find Traces, die de recentste traceringen toont - kies er een - er verschijnt gedetailleerde informatie over alle traceringen: Deze tracering toont: Het verzoek komt binnen in istio-ingressgateway (dit is de eerste interactie met een van de services, en voor het verzoek wordt een Trace ID gegenereerd), waarna de gateway het verzoek doorstuurt naar de service sa-web-app. In de service sa-web-app wordt het verzoek opgevangen door de Envoy sidecar, er wordt een 'kind' in de span aangemaakt (vandaar dat we deze in de traceringen zien) en het wordt doorgestuurd naar de container sa-web-app. (Span Een logische eenheid van werk in Jaeger, met een naam, de starttijd van de bewerking en de duur ervan. Spans kunnen genest en geordend zijn. Een gericht acyclisch diagram van spans vormt een trace. - opmerking van de vertaler) Hier wordt het verzoek verwerkt met de methode sentimentAnalyse. Deze traces zijn al door de applicatie gegenereerd, d.w.z. hiervoor waren wijzigingen in de code nodig. Vanaf dit moment wordt er een POST-verzoek geïnitieerd naar sa-logic. De Trace ID moet worden doorgegeven vanuit sa-web-app. … Opmerking: In stap 4 moet de applicatie de door Istio gegenereerde headers zien en deze doorgeven in de latere verzoeken, zoals in de afbeelding hieronder is weergegeven: (A) Istio is verantwoordelijk voor het doorgeven van de headers; (B) De services zijn verantwoordelijk voor de headers Istio doet het meeste werk, omdat het headers genereert voor binnenkomende verzoeken, nieuwe spans aanmaakt in elke sidecar en deze doorgeeft. Echter, zonder te werken met headers binnen de services, gaat de volledige route van het traceerverzoek verloren. Het is noodzakelijk om de volgende headers in overweging te nemen (door te geven): x-request-id x-b3-traceid x-b3-spanid x-b3-parentspanid x-b3-sampled x-b3-flags x-ot-span-context Het is geen moeilijke taak, maar er zijn al verschillende bibliotheken beschikbaar — bijvoorbeeld, in de service sa-web-app geeft de RestTemplate deze headers door als je simpelweg de bibliotheken Jaeger en OpenTracing toevoegt aan zijn afhankelijkheden. Let op dat de Sentiment Analysis applicatie implementaties op Flask, Spring en ASP.NET Core demonstreert. Nu het duidelijk is wat we standaard krijgen (of bijna "uit de doos"), laten we de vragen van fijn afgestelde routing, netwerkverkeerbeheer, beveiliging enz. bespreken! Opmerking vertaler.: hierover lees je in het volgende deel van het Istio-materiaal van Rinor Maloku, waarvan de vertalingen binnenkort in onze blog zullen verschijnen. UPDATE (14 maart): Het tweede deel is al gepubliceerd. P.S. van de vertaler Lees ook op onze blog: «Terug naar microservices met Istio»: deel 2 (routering, verkeersbeheer), deel 3 (authenticatie en autorisatie); «Conduit — een lichtgewicht service mesh voor Kubernetes»; «Wat is een service mesh en waarom heb ik het nodig [voor een cloudapplicatie met microservices]?»; «Geïllustreerde gids voor netwerken in Kubernetes. Delen 1 en 2»; «Hoe is deze sidecar-container hier terechtgekomen [in Kubernetes]?». Bron: habr.com route: - bestemming: host: sa-frontend # 2 poort: nummer: 80
Belangrijke punten:

Deze VirtualService is van toepassing op verzoeken die binnenkomen via http-gateway;
In destination het wordt bepaald door de service waarheen de verzoeken worden verzonden.

Opmerking: De bovenstaande configuratie wordt opgeslagen in het bestand sa-virtualservice-external.yaml, wat ook instellingen voor routing in SA-WebApp en SA-Feedback bevat, maar hier in het artikel is ingekort voor de beknoptheid.

Pas VirtualService toe met de aanroep:

Opmerking: Wanneer we de hulpbronnen van Istio toepassen, creëert de Kubernetes API Server een gebeurtenis die ontvangen wordt door het Istio Control Plane, en pas daarna wordt de nieuwe configuratie toegepast op de Envoy-proxyservers van elk pod. De Ingress Gateway-controller verschijnt als een andere Envoy, geconfigureerd in het Control Plane. Dit ziet er in diagramvorm zo uit:

Istio-IngressGateway-configuratie voor het routeren van verzoeken

De Sentiment Analysis-applicatie is beschikbaar op http://{EXTERNAL-IP}/. Maak je geen zorgen als je de status Not Found krijgt: soms kost het even wat meer tijd voordat de configuratie van kracht wordt en de Envoy-caches zijn ververst.

Voordat je verder gaat, werk een beetje met de applicatie om verkeer te genereren (het aanwezig zijn is nodig voor de duidelijkheid in de volgende acties — opmerking van de vertaler).

Kiali: observability

Om toegang te krijgen tot de Kiali-beheerinterface, voer de volgende opdracht uit:

… en open http://localhost:20001/, en log in met admin/admin. Hier vind je veel nuttige mogelijkheden, bijvoorbeeld om de configuratie van Istio-componenten te controleren, diensten te visualiseren op basis van verzamelde informatie bij het onderscheppen van netwerkverzoeken, het beantwoorden van vragen als ‘Wie vraagt naar wie?’, ‘Bij welke versie van de service treden fouten op?’ enzovoort. Kortom, verken de mogelijkheden van Kiali voordat je verder gaat naar de visualisatie van metrics met Grafana.

Grafana: visualisatie van metrics

De in Istio verzamelde metrics worden naar Prometheus gestuurd en gevisualiseerd met Grafana. Om toegang te krijgen tot de Grafana-beheerinterface, voer je de onderstaande opdracht uit en open je dan http://localhost:3000/:

Klik op het menu Home linksboven en kies Istio Service Dashboard in de linkerbovenhoek, begin met de service sa-web-app, om de verzamelde metrics te bekijken:

Hier wacht ons een leeg en volledig saai overzicht — de handleiding zou dat nooit goedkeuren. Laten we een kleine belasting creëren met de volgende opdracht:

Nu hebben we veel mooiere grafieken, en daarnaast geweldige tools van Prometheus voor monitoring en Grafana voor het visualiseren van metrics, die ons in staat stellen om de prestaties, gezondheid, verbeteringen/degradaties van de services in de loop van de tijd te begrijpen.

Laten we eindelijk eens kijken naar de tracering van verzoeken in de services.

Jaeger: tracering

Tracering is nodig omdat, naarmate we meer services hebben, het moeilijker wordt om de oorzaak van een fout te achterhalen. Laten we kijken naar een eenvoudig voorbeeld in de afbeelding hieronder:

Typisch voorbeeld van een willekeurig mislukt verzoek

Het verzoek komt binnen, faalt - wat is de oorzaak? De eerste service? Of de tweede? Uitzonderingen zijn er in beide - laten we de logs van elk bekijken. Hoe vaak bent u zichzelf hierin betrapt? Ons werk lijkt meer op dat van softwaredetectives dan op dat van ontwikkelaars...

Dit is een veelvoorkomend probleem in microservices en het wordt opgelost door gedistribueerde tracingsystemen, waarin services elkaar een unieke kop geven, waarna deze informatie naar het tracingsysteem wordt doorgestuurd, waar het wordt gekoppeld aan de gegevens van het verzoek. Hier is een illustratie:

TraceId wordt gebruikt voor het identificeren van het verzoek

In Istio wordt de Jaeger Tracer gebruikt, die een vendor-onafhankelijke OpenTracing API-framework implementeert. Toegang tot de gebruikersinterface van Jaeger kan met de volgende opdracht worden verkregen:

Ga nu naar http://localhost:16686/ en selecteer de service sa-web-app. Als de service niet wordt weergegeven in het dropdownmenu, genereer dan activiteit op de pagina en vernieuw de interface. Klik daarna op de knop Find Traces, die de recentste traceringen toont - kies er een - er verschijnt gedetailleerde informatie over alle traceringen:

Deze tracering toont:

Het verzoek komt binnen in istio-ingressgateway (dit is de eerste interactie met een van de services, en voor het verzoek wordt een Trace ID gegenereerd), waarna de gateway het verzoek doorstuurt naar de service sa-web-app.
In de service sa-web-app de aanvraag wordt opgepikt door de Envoy sidecar, er wordt een ‘kind’ gecreëerd in de span (daarom zien we deze in de traces) en het wordt doorgestuurd naar de container sa-web-app. (Span — een logische werkseenheid in Jaeger, met een naam, begintijd van de operatie en de duur ervan. Span’s kunnen genest en geordend zijn. Een gerichte acyclische grafiek van span’s vormt een trace. — opmerking van de vertaler)
Hier wordt het verzoek verwerkt met de methode sentimentAnalyse. Deze traces zijn al door de applicatie gegenereerd, d.w.z. hiervoor waren wijzigingen in de code nodig.
Vanaf dit moment wordt er een POST-verzoek geïnitieerd naar sa-logic. De Trace ID moet worden doorgegeven vanuit sa-web-app.
…

Opmerking: In stap 4 moet de applicatie de door Istio gegenereerde headers zien en deze doorgeven in de latere verzoeken, zoals in de afbeelding hieronder is weergegeven:

(A) Istio is verantwoordelijk voor het doorgeven van de headers; (B) De services zijn verantwoordelijk voor de headers

Istio voert het zwaarste werk uit, omdat het headers genereert voor binnenkomende aanvragen, nieuwe span’s creëert in elke sidecar en deze doorgeeft. Echter, zonder het werken met headers binnen de diensten, zal het volledige pad van de aanvraagtracering verloren gaan.

Het is noodzakelijk om de volgende headers in overweging te nemen (door te geven):

Het is geen moeilijke taak, maar er zijn al verschillende bibliotheken beschikbaar — bijvoorbeeld, in de service sa-web-app geeft de RestTemplate deze headers door als je simpelweg de bibliotheken Jaeger en OpenTracing toevoegt aan zijn afhankelijkheden.

Let op dat de Sentiment Analysis applicatie implementaties op Flask, Spring en ASP.NET Core demonstreert.

Nu het duidelijk is wat we standaard krijgen (of bijna "uit de doos"), laten we de vragen van fijn afgestelde routing, netwerkverkeerbeheer, beveiliging enz. bespreken!

Opmerking vertaler.: hierover lees je in het volgende deel van het Istio-materiaal van Rinor Maloku, waarvan de vertalingen binnenkort in onze blog zullen verschijnen. UPDATE (14 maart): Het tweede deel is al gepubliceerd.