🥇 Zurück zu Microservices mit Istio. Teil 1

Hinweis.: Service Mesh-Technologien sind zweifellos die aktuelle Lösung in modernen Infrastrukturen für Anwendungen, die der Microservices-Architektur folgen. Obwohl Istio vielen DevOps-Ingenieuren ein Begriff sein kann, ist es ein relativ neues Produkt, das aufgrund seiner komplexen Funktionalitäten eine erhebliche Einarbeitungszeit erfordern kann. Der deutsche Ingenieur Rinor Maloku, der für Cloud-Computing für große Kunden bei dem Telekommunikationsunternehmen Orange Networks verantwortlich ist, hat eine hervorragende Reihe von Materialien verfasst, die es ermöglichen, sich schnell und tief in Istio einzuarbeiten. Er beginnt seinen Bericht damit, was Istio tatsächlich leisten kann und wie man es schnell selbst in Augenschein nehmen kann.

Istio — Open-Source-Projekt, das in Zusammenarbeit von Teams aus Google, IBM und Lyft entwickelt wurde. Es löst die Herausforderungen, die in Anwendungen auf Basis von Microservices auftreten, wie zum Beispiel:

Traffic-Management: Timeouts, Wiederholungsversuche, Lastverteilung;
Sicherheit: Authentifizierung und Autorisierung des Endbenutzers;
Beobachtbarkeit: Tracing, Monitoring, Logging.

Alle diese Probleme können auf Anwendungsebene gelöst werden, doch danach hören Ihre Dienste auf, „mikro“ zu sein. Alle zusätzlichen Anstrengungen zur Lösung dieser Probleme sind eine unnötige Belastung der Unternehmensressourcen, die direkt für geschäftliche Werte verwendet werden könnten. Nehmen wir ein Beispiel:

Projektmanager: Wie lange dauert es, die Feedback-Funktion hinzuzufügen?
Entwickler: Zwei Sprints.
PM: Was?.. Das ist doch nur CRUD!
E: CRUD zu implementieren ist der einfache Teil des Auftrags, aber wir müssen auch Benutzer und Dienste authentifizieren und autorisieren. Da das Netzwerk unzuverlässig ist, müssen wir Wiederholungsanfragen umsetzen und außerdem das Muster Circuit Breaker im Client. Darüber hinaus benötigen wir Zeitlimits, um sicherzustellen, dass das gesamte System nicht ausfällt, und Bulkheads (für weitere Informationen zu den genannten Mustern siehe weiter unten im Artikel — Anmerkung des Übersetzers), und um Probleme zu erkennen, wird Monitoring, Tracing und […] benötigt.
PM: Oh, lassen Sie uns diese Funktion einfach in den Product-Service einfügen.

Ich denke, die Idee ist klar: Der Aufwand und die Schritte, die erforderlich sind, um einen Dienst hinzuzufügen, sind enorm. In diesem Artikel werden wir betrachten, wie Istio all die oben genannten Komplikationen (die nicht zur Geschäftslogik gehören) aus den Diensten entfernt.

Hinweis: Der Artikel setzt voraus, dass Sie praktische Kenntnisse in Kubernetes haben. Andernfalls empfehle ich Ihnen, meine Einführung in Kubernetes zu lesen und erst danach mit dem Lesen dieses Materials fortzufahren.

Die Idee von Istio

In einer Welt ohne Istio stellt ein Dienst direkte Anfragen an einen anderen, und im Falle eines Fehlers muss der Dienst dies selbst verarbeiten: einen neuen Versuch unternehmen, eine Zeitüberschreitung vorsehen, einen Circuit Breaker öffnen usw.

Netzwerkverkehr in Kubernetes

Istio hingegen bietet eine spezialisierte Lösung, die vollständig von den Diensten getrennt ist und durch Eingriffe in die Netzwerkinteraktion funktioniert. Dadurch realisiert es:

Ausfallsicherheit: Es versteht sich anhand des Statuscodes in der Antwort, ob ein Fehler bei der Anfrage aufgetreten ist, und führt diese erneut aus.
Canary Deployments: Leitet nur einen festgelegten Prozentsatz der Anfragen an die neue Version des Dienstes weiter.
Überwachung und Metriken: Wie lange hat der Dienst gebraucht, um zu antworten?
Tracing und Beobachtbarkeit: fügt spezielle Header zu jeder Anfrage hinzu und verfolgt sie im Cluster.
Sicherheit: extrahiert das JWT-Token, authentifiziert und autorisiert Benutzer.

Das sind nur einige der Möglichkeiten (tatsächlich nur einige!), um Ihr Interesse zu wecken. Lassen Sie uns nun in die technischen Details eintauchen!

Architektur von Istio

Istio erfasst sämtlichen Netzwerkverkehr und wendet eine Reihe von Regeln an, indem es einen intelligenten Proxy in Form eines Sidecar-Containers in jeden Pod einfügt. Die Proxys, die alle Funktionen aktivieren, bilden Data Plane, und sie können dynamisch konfiguriert werden mit Hilfe von Control Plane.

Data Plane

In Pods eingesetzte Proxys ermöglichen es Istio, mühelos die erforderlichen Anforderungen zu erfüllen. Lassen Sie uns beispielsweise die Funktionen von Retries und Circuit Breaking überprüfen.

Wie Retries und Circuit Breaking in Envoy implementiert sind

Fassen wir zusammen:

Envoy (es handelt sich um den Proxy, der sich im Sidecar-Container befindet, der auch als eigenständiges Produkt — Anmerkung des Übersetzers). die Anfrage an die erste Instanz des Dienstes B sendet und ein Fehler auftritt.
Envoy Sidecar unternimmt einen erneuten Versuch (Retry). (1)
Die fehlerhafte Anfrage wird an den aufrufenden Proxy zurückgegeben.
So wird der Circuit Breaker eröffnet und der nächste Dienst für nachfolgende Anfragen aufgerufen. (2)

Das bedeutet, dass Sie keine zusätzliche Retry-Bibliothek verwenden müssen und keine eigene Implementierung von Circuit Breaking und Service Discovery in Programmiersprachen wie X, Y oder Z entwickeln müssen. Das alles und noch viel mehr ist direkt in Istio integriert und erfordert keine Änderungen im Code.

Ausgezeichnet! Jetzt möchten Sie möglicherweise mit Istio in See stechen, haben aber noch einige Zweifel und offene Fragen. Wenn es sich um eine universelle Lösung handelt, stellen Sie sich zu Recht die Frage: Sind solche Lösungen wirklich für jeden Anwendungsfall geeignet?

Und schließlich werden Sie fragen: „Lässt es sich anpassen?“

Jetzt sind Sie bereit für die Seereise – lassen Sie uns das Control Plane kennenlernen.

Control Plane

Es besteht aus drei Komponenten: Pilot, Mixer и Citadel, die gemeinsam die Envoy-Instanzen für die Verkehrslenkung konfigurieren, Richtlinien anwenden und Telemetriedaten sammeln. Schematisch sieht das so aus:

Interaktion zwischen Control Plane und Data Plane

Die Envoy-Instanzen (d.h. Data Plane) werden mithilfe von Kubernetes CRD konfiguriert. (Custom Resource Definitions), die von Istio definiert wurden und speziell dafür vorgesehen sind. Für Sie bedeutet das, dass sie als eine weitere Ressource in Kubernetes mit der vertrauten Syntax dargestellt werden. Nach der Erstellung wird diese Ressource vom Control Plane ausgewählt und auf Envoy angewendet.

Die Beziehung von Diensten zu Istio

Wir haben die Beziehung von Istio zu den Diensten beschrieben, aber nicht umgekehrt: Wie stehen die Dienste zu Istio?

Um ehrlich zu sein, ist den Diensten die Existenz von Istio genauso bewusst wie Fischen das Wasser, wenn sie sich fragen: „Was ist überhaupt Wasser?“

Illustration Victoria Dimitrakopoulos: — Wie geht es Ihnen mit dem Wasser? — Was ist überhaupt Wasser?

So können Sie einen funktionierenden Cluster übernehmen, und nach dem Deployment der Istio-Komponenten werden die darin enthaltenen Dienste weiterhin funktionieren, und nachdem diese Komponenten entfernt wurden, wird alles wieder in Ordnung sein. Dabei ist klar, dass Sie die von Istio bereitgestellten Möglichkeiten verlieren werden.

Genug der Theorie — lassen Sie uns dieses Wissen in die Praxis umsetzen!

Istio in der Praxis

Istio benötigt einen Kubernetes-Cluster, der mindestens 4 vCPU und 8 GB RAM zur Verfügung hat. Um schnell einen Cluster aufzubauen und den Anweisungen im Artikel zu folgen, empfehle ich die Nutzung der Google Cloud Platform, die neuen Nutzern kostenlose 300 $.

Nach der Erstellung des Clusters und der Konfiguration des Zugriffs auf Kubernetes über das Konsolen-Tool können Sie Istio über den Paketmanager Helm installieren.

Helm-Installation

Installieren Sie den Helm-Client auf Ihrem Computer, wie in offiziellen Dokumentationbeschrieben wird. Diesen werden wir verwenden, um Vorlagen für die Installation von Istio im nächsten Abschnitt zu generieren.

Istio-Installation

Laden Sie die Istio-Ressourcen von der letzten Version (der Originallink zur Version 1.0.5 wurde auf die aktuelle Version 1.0.6 geändert — Anm. d. Übs.), extrahieren Sie den Inhalt in ein Verzeichnis, das ich im Folgenden als [istio-resources].

bezeichnen werde. Zur einfacheren Identifikation der Istio-Ressourcen erstellen Sie im K8s-Cluster einen Namensraum istio-system:

$ kubectl create namespace istio-system

Fahren Sie mit der Installation fort, indem Sie in das Verzeichnis [istio-resources] wechseln und den Befehl ausführen:

$ 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

Dieser Befehl gibt die Hauptkomponenten von Istio in die Datei istio.yaml. Wir haben die Standardvorlage angepasst und die folgenden Parameter angegeben:

global.mtls.enabled eingestellt auf false (d.h. mTLS-Authentifizierung ist deaktiviert — Anmerkung des Übersetzers), um unseren Einarbeitungsprozess zu vereinfachen;
tracing.enabled aktiviert das Request-Tracking mit Jaeger;
kiali.enabled installiert Kiali im Cluster zur Visualisierung von Services und Traffic;
grafana.enabled installiert Grafana zur Visualisierung der gesammelten Metriken.

Wir wenden die generierten Ressourcen mit dem Befehl an:

$ kubectl apply -f istio.yaml

Die Installation von Istio im Cluster ist abgeschlossen! Warten Sie, bis alle Pods im Namensraum istio-system den Zustand Running или Abgeschlossenerreicht haben, indem Sie den folgenden Befehl ausführen:

$ kubectl get pods -n istio-system

Jetzt sind wir bereit, im nächsten Abschnitt fortzufahren, wo wir die Anwendung starten und ausführen werden.

Architektur der Anwendung Sentiment Analysis

Wir verwenden das Beispiel der Microservices-Anwendung Sentiment Analysis, das in dem bereits erwähnten einführenden Artikel über Kubernetes. Es ist komplex genug, um die Möglichkeiten von Istio in der Praxis zu demonstrieren.

Die Anwendung besteht aus vier Microservices:

Dienste SA-Frontend, die das Frontend der Anwendung auf React.js bereitstellt;
Dienste SA-WebApp, der die Anfragen für die Sentiment-Analyse verwaltet;
Dienste SA-Logic, der die eigentliche Sentiment-Analyse durchführt;;
Dienste SA-Feedback, der von den Benutzern Feedback zur Genauigkeit der durchgeführten Analyse erhält.

In diesem Diagramm sehen wir neben den Diensten auch den Ingress Controller, der in Kubernetes eingehende Anfragen an die entsprechenden Dienste weiterleitet. In Istio wird ein ähnliches Konzept im Rahmen des Ingress Gateway verwendet, über das im Folgenden weitere Details folgen.

Starten der Anwendung mit dem Istio-Proxy

Für die weiteren in dem Artikel erwähnten Operationen klonen Sie das Repository istio-mastery. Darin sind die Anwendung und die Manifeste für Kubernetes und Istio enthalten.

Einfügen von Sidecars

Die Einfügung kann erfolgen automatisch или manuell. Für die automatische Einfügung von Sidecar-Containern muss dem Namespace das Label istio-injection=enabled, gesetzt werden, was mit folgendem Befehl geschieht:

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

Jetzt erhält jeder Pod, der im Standard-Namespace (default) bereitgestellt wird, seinen Sidecar-Container. Um dies zu überprüfen, lassen Sie uns eine Testanwendung bereitstellen, indem wir in das Stammverzeichnis des Repositories gehen [istio-mastery] und den folgenden Befehl ausführen:

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

Nachdem die Dienste bereitgestellt wurden, überprüfen wir, ob die Pods über zwei Container verfügen (den Dienst selbst und seinen Sidecar), indem wir den Befehl ausführen kubectl get pods und sicherstellen, dass unter der Spalte READY der Wert angegeben ist 2/2, was symbolisiert, dass beide Container ausgeführt werden:

$ 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

Visuell sieht das so aus:

Der Envoy-Proxy in einem der Pods

Jetzt, da die Anwendung bereitgestellt und funktionsfähig ist, müssen wir den eingehenden Verkehr zulassen, damit dieser in die Anwendung kommt.

Ingress Gateway

Die beste Praxis, um dies zu erreichen (den Verkehr im Cluster zuzulassen) — geschieht über Ingress Gateway in Istio, das sich an der „Grenze“ des Clusters befindet und es ermöglicht, für den eingehenden Verkehr Funktionen von Istio wie Routing, Lastenausgleich, Sicherheit und Monitoring zu aktivieren.

Die Ingress Gateway-Komponente und der Service, der sie nach außen leitet, wurden während der Istio-Installation im Cluster eingerichtet. Um die externe IP-Adresse des Services zu erfahren, führen Sie Folgendes aus:

$ 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

Wir werden in Zukunft auf die Anwendung über diese IP zugreifen (ich werde mich darauf als EXTERNAL-IP beziehen), daher speichern wir den Wert zur Vereinfachung in einer Variable:

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

Wenn Sie jetzt versuchen, diese IP im Browser aufzurufen, erhalten Sie einen Fehler "Service Unavailable", da Istio standardmäßig gesamten eingehenden Verkehr blockiert, solange kein Gateway definiert ist.

Ressource Gateway

Gateway ist eine CRD (Custom Resource Definition) in Kubernetes, die nach der Installation von Istio im Cluster definiert wird und die Möglichkeit aktiviert, Ports, Protokolle und Hosts anzugeben, für die wir den eingehenden Verkehr erlauben möchten.

In unserem Fall möchten wir HTTP-Verkehr auf Port 80 für alle Hosts erlauben. Dies wird durch die folgende Definition erreicht: (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:
- "*"

Diese Konfiguration benötigt keine Erklärung, außer dem Selektor. istio: ingressgateway. Mit diesem Selektor können wir angeben, auf welches Ingress Gateway die Konfiguration angewendet werden soll. In unserem Fall handelt es sich dabei um den standardmäßig in Istio installierten Ingress Gateway-Controller.

Die Konfiguration wird mit dem folgenden Befehl angewendet:

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

Jetzt erlaubt das Gateway den Zugang zum Port 80, hat jedoch keine Vorstellung davon, wohin die Anfragen weitergeleitet werden sollen. Dafür werden Virtual Services.

Die Ressource VirtualService

VirtualService weist dem Ingress Gateway zu, wie Anfragen, die innerhalb des Clusters erlaubt sind, weitergeleitet werden sollen.

Anfragen an unsere Anwendung, die über http-gateway kommen, müssen an die Dienste sa-frontend, sa-web-app und sa-feedback gesendet werden:

Routen, die mit VirtualServices konfiguriert werden müssen

Betrachten wir die Anfragen, die an SA-Frontend weitergeleitet werden sollen:

Exakte Übereinstimmung anhand des Pfads / soll an SA-Frontend gesendet werden, um index.html zu erhalten;
Pfade mit Präfix /static/* müssen an SA-Frontend gesendet werden, um statische Dateien für das Frontend wie CSS und JavaScript zu erhalten;
Pfad, der dem regulären Ausdruck entspricht '^.*.(ico|png|jpg)$', müssen an SA-Frontend gesendet werden, da es sich um Bilder handelt, die auf der Seite angezeigt werden.

Die Implementierung erfolgt durch die folgende 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) Wichtige Punkte: Dieser VirtualService bezieht sich auf Anfragen, die über http-gateway; In abgekürzt werden definiert den Service, an den die Anfragen gesendet werden. Hinweis: Die obige Konfiguration wird in der Datei gespeichert sa-virtualservice-external.yaml, die auch Einstellungen für das Routing zu SA-WebApp und SA-Feedback enthält, aber hier in dem Artikel der Kürze halber verkürzt wurde. Wenden wir VirtualService an mit dem Befehl: $ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml virtualservice.networking.istio.io/sa-external-services erstellt Hinweis: Wenn wir die Istio-Ressourcen anwenden, erstellt der Kubernetes API-Server ein Ereignis, das vom Istio-Control-Plane empfangen wird, und erst danach wird die neue Konfiguration auf die Envoy-Proxys jeder Pod angewendet. Der Ingress-Gateway-Controller wird als weiterer Envoy dargestellt, der im Control Plane konfiguriert ist. In der Grafik sieht das so aus: Istio-IngressGateway-Konfiguration für die Anfrage-Routing Die Anwendung Sentiment Analysis ist verfügbar unter http://{EXTERNAL-IP}/. Machen Sie sich keine Sorgen, wenn Sie den Status Not Found erhalten: Manchmal benötigt die Konfiguration etwas mehr Zeit, um wirksam zu werden und die Envoy-Caches zu aktualisieren.. Bevor Sie fortfahren, arbeiten Sie ein wenig mit der Anwendung, um Traffic zu generieren. (dies ist notwendig, um in den folgenden Aktionen Sichtbarkeit zu gewährleisten – Anm. d. Übers.).. Kiali: Observability Um auf die Verwaltungsoberfläche von Kiali zuzugreifen, führen Sie den folgenden Befehl aus: $ kubectl port-forward $(kubectl get pod -n istio-system -l app=kiali -o jsonpath='{.items[0].metadata.name}') -n istio-system 20001 … und öffnen Sie http://localhost:20001/, indem Sie sich mit admin/admin anmelden. Hier finden Sie zahlreiche nützliche Funktionen, zum Beispiel zur Überprüfung der Istio-Komponenten-Konfiguration, zur Visualisierung von Diensten basierend auf Informationen, die bei der Erfassung von Netzwerkaufrufen gesammelt wurden, oder um Fragen zu beantworten wie "Wer kommuniziert mit wem?", "In welcher Version des Dienstes treten Fehler auf?" usw. Insgesamt sollten Sie die Möglichkeiten von Kiali erkunden, bevor Sie zu den Visualisierungen von Metriken mit Grafana übergehen. Grafana: Metrikvisualisierung Die in Istio gesammelten Metriken gelangen zu Prometheus und werden mit Grafana visualisiert. Um auf die Verwaltungsoberfläche von Grafana zuzugreifen, führen Sie den folgenden Befehl aus und öffnen Sie danach. 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 Klicken Sie auf das Menü Startseite oben links und wählen Sie Istio Service Dashboard oben links, beginnen Sie mit dem Dienst sa-web-app, um die gesammelten Metriken zu sehen: Hier erwartet uns eine leere und völlig langweilige Darstellung — ein solches Vorgehen würde kein Handbuch genehmigen. Lassen Sie uns mit dem folgenden Befehl eine kleine Last erzeugen: $ while true; do curl -i http://$EXTERNAL_IP/sentiment -H "Content-type: application/json" -d '{"sentence": "I love yogobella"}'; sleep .8; done Jetzt haben wir deutlich schönere Grafiken, und zusätzlich bemerkenswerte Werkzeuge wie Prometheus zur Überwachung und Grafana zur Visualisierung der Metriken, die uns Informationen über die Performance, den Gesundheitszustand sowie Verbesserungen oder Verschlechterungen der Dienste im Zeitverlauf liefern. Schließlich werfen wir einen Blick auf die Anfragenverfolgung in den Diensten. Jaeger : Verfolgung Die Verfolgung benötigen wir, denn je mehr Dienste wir haben, desto schwieriger wird es, die Ursache eines Fehlers zu finden. Schauen wir uns ein einfaches Beispiel aus dem Bild unten an: Typisches Beispiel einer zufälligen fehlerhaften Anfrage Eine Anfrage kommt an, fällt aus — was ist die Ursache? Der erste Dienst? Oder der zweite? Es gibt Ausnahmen in beiden Fällen – lassen Sie uns die Protokolle jedes einzelnen ansehen. Wie oft haben Sie sich dabei ertappt? Unsere Arbeit ähnelt mehr der von Softwaredetektiven als der von Entwicklern… Dies ist ein weit verbreitetes Problem in Mikrodiensten und wird durch verteilte Tracesysteme gelöst, in denen die Dienste einzigartige Header aneinander weitergeben. Diese Informationen werden anschließend in das Tracesystem geleitet, wo sie mit den Anfragedaten verknüpft werden. Hier ist eine Illustration: Zur Identifikation der Anfrage wird TraceId verwendet. In Istio kommt der Jaeger Tracer zum Einsatz, der ein herstellerunabhängiges Framework des OpenTracing API implementiert. Der Zugriff auf das Benutzerinterface von Jaeger erfolgt mit dem folgenden Befehl: $ kubectl port-forward -n istio-system $(kubectl get pod -n istio-system -l app=jaeger -o jsonpath='{.items[0].metadata.name}') 16686 Jetzt gehen Sie zu http://localhost:16686/ und wählen Sie den Dienst sa-web-app. Wenn der Dienst nicht im Dropdown-Menü angezeigt wird, generieren Sie bitte Aktivität auf der Seite und aktualisieren Sie das Interface. Klicken Sie anschließend auf die Schaltfläche Find Traces, die die neuesten Traces anzeigt – wählen Sie einen beliebigen aus – es wird detaillierte Informationen zu allen Traces angezeigt: Diese Spur zeigt an: Die Anfrage kommt in istio-ingressgateway (dies ist die erste Interaktion mit einem der Dienste, und für die Anfrage wird eine Trace-ID generiert), danach leitet das Gateway die Anfrage an den Dienst weiter sa-web-app. Im Dienst sa-web-app wird die Anfrage vom Envoy Sidecar erfasst, ein „Kind“ im Span wird erstellt (deshalb sehen wir es in den Spuren) und an den Container weitergeleitet sa-web-app. (Span — eine logische Arbeitseinheit in Jaeger, die einen Namen, Anfangszeit und Dauer der Operation beinhaltet. Spans können geschachtelt und geordnet sein. Ein gerichteter azyklischer Graph von Spans bildet die Trace. — Anmerkung des Übersetzers) Hier wird die Anfrage durch die Methode sentimentAnalysis. Diese Spuren wurden bereits von der Anwendung generiert, d.h. es waren Änderungen im Code erforderlich. Von diesem Punkt an wird eine POST-Anfrage an sa-logic. Die Trace-ID muss aus sa-web-app. … Hinweis: In Schritt 4 muss die Anwendung die von Istio generierten Header sehen und diese in die nachfolgenden Anfragen weitergeben, wie im Bild unten gezeigt: (A) Istio ist für das Durchreichen der Header verantwortlich; (B) Die Header werden von den Diensten verwaltet Istio übernimmt die Hauptarbeit, indem es Header für eingehende Anfragen generiert, in jedem Sidecar neue Spans erstellt und sie weiterleitet. Allerdings geht der gesamte Trace-Path der Anfrage verloren, wenn die Header in den Services nicht bearbeitet werden. Die folgenden Header müssen berücksichtigt (weitergeleitet) werden: x-request-id x-b3-traceid x-b3-spanid x-b3-parentspanid x-b3-sampled x-b3-flags x-ot-span-context Das ist eine unkomplizierte Aufgabe, aber für eine einfachere Implementierung gibt es bereits zahlreiche Bibliotheken — zum Beispiel überträgt der RestTemplate-Client im Dienst sa-web-app diese Header, wenn einfach die Bibliotheken Jaeger und OpenTracing in seine Abhängigkeiten eingefügt werden.. Beachten Sie, dass die Anwendung Sentiment Analysis Implementierungen auf Flask, Spring und ASP.NET Core zeigt. Jetzt, da klar ist, was wir „out of the box“ (oder fast „out of the box“) erhalten, betrachten wir Themen wie fein abgestimmte Routings, Netzwerkverkehrsmanagement, Sicherheit usw.! Hinweis.: Lesen Sie mehr darüber im nächsten Teil der Istio-Materialien von Rinor Maloku, deren Übersetzungen bald in unserem Blog erscheinen werden. UPDATE (14. März): Der zweite Teil ist bereits veröffentlicht. P.S. vom Übersetzer Lesen Sie auch in unserem Blog: „Zurück zu Microservices mit Istio“: Teil 2 (Routing, Traffic-Management), Teil 3 (Authentifizierung und Autorisierung); «Conduit – ein leichtgewichtiges Service Mesh für Kubernetes.»; «Was ist ein Service Mesh und warum benötige ich es [für Cloud-Anwendungen mit Microservices]?»; «Illustriertes Handbuch zur Netzwerkstruktur in Kubernetes. Teile 1 und 2»; «Wie ist dieser Sidecar-Container hierher gekommen [in Kubernetes]?». Quelle: habr.com route: - Ziel: host: sa-frontend # 2 port: nummer: 80
Wichtige Punkte:

Dieser VirtualService bezieht sich auf Anfragen, die über http-gateway;
In abgekürzt werden definiert den Service, an den die Anfragen gesendet werden.

Hinweis: Die obige Konfiguration wird in der Datei gespeichert sa-virtualservice-external.yaml, der auch Einstellungen für das Routing in SA-WebApp und SA-Feedback enthält, jedoch hier im Artikel zur Kürze gekürzt wurde.

Anwendung von VirtualService durch:

Hinweis: Wenn wir Istio-Ressourcen anwenden, erstellt der Kubernetes API-Server ein Ereignis, das vom Istio Control Plane empfangen wird, und erst danach wird die neue Konfiguration auf die Envoy-Proxy-Server jedes Pods angewendet. Der Ingress Gateway Controller wird als ein weiterer Envoy dargestellt, der im Control Plane konfiguriert ist. So sieht das auf dem Diagramm aus:

Istio-IngressGateway-Konfiguration für die Anfrage-Routing

Die Anwendung Sentiment Analysis ist verfügbar unter http://{EXTERNAL-IP}/. Machen Sie sich keine Sorgen, wenn Sie den Status Not Found erhalten: Manchmal benötigt die Konfiguration etwas mehr Zeit, um wirksam zu werden und die Envoy-Caches zu aktualisieren..

Bevor Sie fortfahren, arbeiten Sie ein wenig mit der Anwendung, um Traffic zu generieren. (dies ist notwendig, um in den folgenden Aktionen Sichtbarkeit zu gewährleisten – Anm. d. Übers.)..

Kiali: Observability

Um auf die Verwaltungsoberfläche von Kiali zuzugreifen, führen Sie den folgenden Befehl aus:

… und öffnen Sie http://localhost:20001/, indem Sie sich mit admin/admin anmelden. Hier finden Sie zahlreiche nützliche Funktionen, zum Beispiel zur Überprüfung der Istio-Komponenten-Konfiguration, zur Visualisierung von Diensten basierend auf Informationen, die bei der Erfassung von Netzwerkaufrufen gesammelt wurden, oder um Fragen zu beantworten wie "Wer kommuniziert mit wem?", "In welcher Version des Dienstes treten Fehler auf?" usw. Insgesamt sollten Sie die Möglichkeiten von Kiali erkunden, bevor Sie zu den Visualisierungen von Metriken mit Grafana übergehen.

Grafana: Metrikvisualisierung

Die in Istio gesammelten Metriken gelangen zu Prometheus und werden mit Grafana visualisiert. Um auf die Verwaltungsoberfläche von Grafana zuzugreifen, führen Sie den folgenden Befehl aus und öffnen Sie danach. http://localhost:3000/:

Klicken Sie auf das Menü Startseite oben links und wählen Sie Istio Service Dashboard oben links, beginnen Sie mit dem Dienst sa-web-app, um die gesammelten Metriken zu sehen:

Hier erwartet uns eine leere und völlig langweilige Darstellung — ein solches Vorgehen würde kein Handbuch genehmigen. Lassen Sie uns mit dem folgenden Befehl eine kleine Last erzeugen:

Jetzt haben wir deutlich schönere Grafiken, und zusätzlich bemerkenswerte Werkzeuge wie Prometheus zur Überwachung und Grafana zur Visualisierung der Metriken, die uns Informationen über die Performance, den Gesundheitszustand sowie Verbesserungen oder Verschlechterungen der Dienste im Zeitverlauf liefern.

Schließlich werfen wir einen Blick auf die Anfragenverfolgung in den Diensten.

Jaeger : Verfolgung

Die Verfolgung benötigen wir, denn je mehr Dienste wir haben, desto schwieriger wird es, die Ursache eines Fehlers zu finden. Schauen wir uns ein einfaches Beispiel aus dem Bild unten an:

Typisches Beispiel einer zufälligen fehlerhaften Anfrage

Eine Anfrage kommt an, fällt aus — was ist die Ursache? Der erste Dienst? Oder der zweite? Es gibt Ausnahmen in beiden Fällen – lassen Sie uns die Protokolle jedes einzelnen ansehen. Wie oft haben Sie sich dabei ertappt? Unsere Arbeit ähnelt mehr der von Softwaredetektiven als der von Entwicklern…

Dies ist ein weit verbreitetes Problem in Mikrodiensten und wird durch verteilte Tracesysteme gelöst, in denen die Dienste einzigartige Header aneinander weitergeben. Diese Informationen werden anschließend in das Tracesystem geleitet, wo sie mit den Anfragedaten verknüpft werden. Hier ist eine Illustration:

Zur Identifikation der Anfrage wird TraceId verwendet.

In Istio kommt der Jaeger Tracer zum Einsatz, der ein herstellerunabhängiges Framework des OpenTracing API implementiert. Der Zugriff auf das Benutzerinterface von Jaeger erfolgt mit dem folgenden Befehl:

Jetzt gehen Sie zu http://localhost:16686/ und wählen Sie den Dienst sa-web-app. Wenn der Dienst nicht im Dropdown-Menü angezeigt wird, generieren Sie bitte Aktivität auf der Seite und aktualisieren Sie das Interface. Klicken Sie anschließend auf die Schaltfläche Find Traces, die die neuesten Traces anzeigt – wählen Sie einen beliebigen aus – es wird detaillierte Informationen zu allen Traces angezeigt:

Diese Spur zeigt an:

Die Anfrage kommt in istio-ingressgateway (dies ist die erste Interaktion mit einem der Dienste, und für die Anfrage wird eine Trace-ID generiert), danach leitet das Gateway die Anfrage an den Dienst weiter sa-web-app.
Im Dienst sa-web-app Die Anfrage wird vom Envoy Sidecar erfasst, ein "Kind" wird im Span erstellt (deshalb sehen wir es in den Traces) und wird in den Container umgeleitet. sa-web-app. (Span — eine logische Arbeitseinheit in Jaeger, die einen Namen, einen Startzeitpunkt der Operation und deren Dauer hat. Spans können geschachtelt und geordnet sein. Ein gerichteter azyklischer Graph aus Spans bildet den Trace. — Anmerkung des Übersetzers.
Hier wird die Anfrage durch die Methode sentimentAnalysis. Diese Spuren wurden bereits von der Anwendung generiert, d.h. es waren Änderungen im Code erforderlich.
Von diesem Punkt an wird eine POST-Anfrage an sa-logic. Die Trace-ID muss aus sa-web-app.
…

Hinweis: In Schritt 4 muss die Anwendung die von Istio generierten Header sehen und diese in die nachfolgenden Anfragen weitergeben, wie im Bild unten gezeigt:

(A) Istio ist für das Durchreichen der Header verantwortlich; (B) Die Header werden von den Diensten verwaltet

Istio erledigt die Hauptarbeit, indem es Header für eingehende Anfragen generiert, neue Spans in jedem Sidecar erstellt und sie durchleitet. Ohne die Bearbeitung von Headern innerhalb der Dienste geht jedoch der vollständige Verfolgungsweg der Anfrage verloren.

Die folgenden Header müssen berücksichtigt (weitergeleitet) werden:

Das ist eine unkomplizierte Aufgabe, aber für eine einfachere Implementierung gibt es bereits zahlreiche Bibliotheken — zum Beispiel überträgt der RestTemplate-Client im Dienst sa-web-app diese Header, wenn einfach die Bibliotheken Jaeger und OpenTracing in seine Abhängigkeiten eingefügt werden..

Beachten Sie, dass die Anwendung Sentiment Analysis Implementierungen auf Flask, Spring und ASP.NET Core zeigt.

Jetzt, da klar ist, was wir „out of the box“ (oder fast „out of the box“) erhalten, betrachten wir Themen wie fein abgestimmte Routings, Netzwerkverkehrsmanagement, Sicherheit usw.!

Hinweis.: Lesen Sie mehr darüber im nächsten Teil der Istio-Materialien von Rinor Maloku, deren Übersetzungen bald in unserem Blog erscheinen werden. UPDATE (14. März): Der zweite Teil ist bereits veröffentlicht.

P.S. vom Übersetzer

Lesen Sie auch in unserem Blog:

„Zurück zu Microservices mit Istio“: Teil 2 (Routing, Traffic-Management), Teil 3 (Authentifizierung und Autorisierung);
«Conduit – ein leichtgewichtiges Service Mesh für Kubernetes.»;
«Was ist ein Service Mesh und warum benötige ich es [für Cloud-Anwendungen mit Microservices]?»;
«Illustriertes Handbuch zur Netzwerkstruktur in Kubernetes. Teile 1 und 2»;
«Wie ist dieser Sidecar-Container hierher gekommen [in Kubernetes]?».

Quelle: habr.com