🥇Zurück zu Mikroservices mit Istio. Teil 1

Anmerkung des Übersetzers.: Service-Meshes sind definitiv zu einer aktuellen Lösung in modernen Infrastrukturen für Anwendungen geworden, die der mikroservicebasierten Architektur folgen. Obwohl Istio vielen DevOps-Ingenieuren bekannt sein mag, handelt es sich um ein recht neues Produkt, das, wenn man die Komplexität der angebotenen Funktionen betrachtet, eine signifikante Einarbeitungszeit erfordern kann. Der deutsche Ingenieur Rinor Maloku, der für Cloud-Computing bei großen Kunden in der Telekommunikationsfirma Orange Networks verantwortlich ist, hat eine ausgezeichnete Reihe von Materialien verfasst, die es ermöglichen, sich recht schnell und tief in Istio einzuarbeiten. Er beginnt seine Erzählung mit dem, was Istio überhaupt kann und wie man es sich schnell selbst ansehen 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 entstehen, die auf Mikroservices basieren, zum Beispiel:

Verkehrsmanagement: Zeitüberschreitungen, Wiederholungsversuche, Lastverteilung;
Sicherheit: Authentifizierung und Autorisierung des Endbenutzers;
Observability: Tracing, Monitoring, Logging.

All diese Aspekte können auf Anwendungsniveau gelöst werden, aber dann hören Ihre Dienste auf, „mikro“ zu sein. Alle zusätzlichen Anstrengungen zur Lösung dieser Probleme sind ein zusätzlicher Ressourcenverbrauch für das Unternehmen, der direkt für Geschäftsziele genutzt werden könnte. Betrachten wir folgendes Beispiel:

Projektmanager: Wie lange dauert es, die Feedback-Option hinzuzufügen?
Entwickler: Zwei Sprints.
PM: Was?.. Das ist doch nur CRUD!
E: CRUD zu erstellen, ist der einfache Teil, aber wir müssen auch die Benutzer und Dienste authentifizieren und autorisieren. Da das Netzwerk unzuverlässig ist, müssen Wiederholungsanfragen sowie Circuit-Breaker-Pattern in den Clients implementiert werden. Außerdem, um sicherzustellen, dass das gesamte System nicht ausfällt, benötigen wir Zeitüberschreitungen und Bulkheads (weitere Informationen zu beiden erwähnten Mustern finden Sie weiter unten im Artikel — Anmerkung des Übersetzers), und um Probleme zu erkennen, benötigen wir Monitoring, Tracing, […]
PM: Oh, lass uns einfach diese Funktion in den Produkt-Service einfügen.

Ich denke, die Idee ist klar: Der Umfang an Schritten und Anstrengungen, die erforderlich sind, um einen Dienst hinzuzufügen, ist enorm. In diesem Artikel werden wir erörtern, wie Istio all die oben genannten Herausforderungen (die nicht für die Geschäftslogik relevant sind) aus den Diensten entfernt.

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

Die Idee von Istio

In einer Welt ohne Istio stellt ein Dienst direkte Anfragen an einen anderen, und im Falle eines Ausfalls muss der Dienst dies selbst behandeln: einen neuen Versuch unternehmen, Timeouts 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 funktioniert, indem sie in die Netzwerkinteraktion eingreift. Dadurch wird realisiert:

Fehlertoleranz: Anhand des Statuscodes in der Antwort erkennt es, ob der Antrag gescheitert ist, und wiederholt ihn.
Canary Deployments: Es leitet nur einen festen Prozentsatz der Anfragen zur neuen Version des Dienstes um.
Überwachung und Metriken: Wie lange hat der Dienst für eine Antwort benötigt?
Tracing und Beobachtbarkeit: Es fügt jeder Anfrage spezielle Header hinzu und verfolgt diese im Cluster.
Sicherheit: Es extrahiert das JWT-Token, authentifiziert und autorisiert Benutzer.

Dies sind nur einige der Möglichkeiten (wirklich nur einige!), um Sie zu interessieren. Lassen Sie uns nun in die technischen Einzelheiten eintauchen!

Die Architektur von Istio

Istio erfasst den gesamten Netzwerkverkehr und wendet eine Reihe von Regeln an, indem es in jedes Pod einen intelligenten Proxy in Form eines Sidecar-Containers einfügt. Die Proxys, die alle Funktionen aktivieren, bilden Data Plane, und sie können dynamisch über Control Plane.

Data Plane

konfiguriert werden. Die in die Pods eingefügten Proxys ermöglichen es Istio, problemlos die erforderlichen Anforderungen zu erfüllen. Prüfen wir beispielsweise die Funktionen für Wiederholungen und Circuit Breaker.

Wie Wiederholungen und Circuit Breaking in Envoy umgesetzt werden

Zusammenfassend:

Envoy (es handelt sich um den Proxy im Sidecar-Container, der sowohl als einzelnes Produkt — Anm. d. Übersetzer) die Anfrage an die erste Instanz von Dienst B sendet und es zu einem Fehler kommt.
Envoy Sidecar unternimmt einen erneuten Versuch (retry). (1)
Die fehlerhafte Anfrage wird an den aufrufenden Proxy zurückgegeben.
So wird der Circuit Breaker aktiviert und der nächste Dienst für nachfolgende Anfragen aufgerufen. (2)

Das bedeutet, dass Sie keine zusätzliche Retry-Bibliothek verwenden müssen, keine eigene Implementierung von Circuit Breaking und Service Discovery in der Programmiersprache X, Y oder Z erstellen müssen. All dies und noch viel mehr ist sofort in Istio verfügbar und erfordert keine kein Änderungen im Code.

Ausgezeichnet! Jetzt möchten Sie möglicherweise mit Istio in See stechen, aber es gibt immer noch einige Zweifel und offene Fragen. Wenn es sich um eine universelle Lösung für alle Lebenslagen handelt, dann kommt Ihnen ein berechtigter Verdacht: Solche Lösungen erweisen sich in Wirklichkeit oft als ungeeignet für irgendeinen Fall.

Und schließlich fragen Sie sich: „Kann man es konfigurieren?“

Jetzt sind Sie bereit für die Seereise — und lassen Sie uns den Control Plane kennenlernen.

Control Plane

Er besteht aus drei Komponenten: Pilot, Mixer und Citadel, — die gemeinsam die Envoy’s für das Routing des Datenverkehrs konfigurieren, Richtlinien anwenden und Telemetriedaten sammeln. Grafisch sieht das Ganze so aus:

Das Zusammenspiel zwischen Control Plane und Data Plane

Die Envoy’s (d.h. data plane) werden über Kubernetes CRD (Custom Resource Definitions), die von Istio definiert wurden und speziell für diesen Zweck gedacht sind, konfiguriert. Für Sie bedeutet das, dass sie als weitere Ressource in Kubernetes mit der vertrauten Syntax dargestellt werden. Nach der Erstellung wird diese Ressource vom Control Plane ausgewählt und auf die Envoy’s angewendet.

Die Beziehung der Dienste zu Istio

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

Ehrlich gesagt ist den Diensten die Existenz von Istio ebenso gut bekannt wie den Fischen — das Wasser, wenn sie sich fragen: „Was ist überhaupt Wasser?“

Illustration Victoria Dimitrakopoulos: — Wie gefällt Ihnen das Wasser? — Was ist überhaupt Wasser?

So können Sie einen funktionierenden Cluster erstellen und nach dem Deployment der Istio-Komponenten weiterhin mit den darin befindlichen Diensten arbeiten; nach der Beseitigung dieser Komponenten wird wieder alles gut sein. Natürlich verlieren Sie dabei die durch Istio bereitgestellten Möglichkeiten.

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

Istio in der Praxis

Istio benötigt ein Kubernetes-Cluster, in dem mindestens 4 vCPU und 8 GB RAM verfügbar sind. Um schnell einen Cluster bereitzustellen und den Anweisungen im Artikel zu folgen, empfehle ich Ihnen, die Google Cloud Platform zu nutzen, die neuen Nutzern 300 $ kostenlos.

Nach der Erstellung des Clusters und der Konfiguration des Zugangs zu Kubernetes über das Befehlszeilen-Tool können Sie Istio über den Paketmanager Helm installieren.

Installation von Helm

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

Istio kann auf zwei Arten installiert werden. Sie können

Laden Sie die Istio-Ressourcen von letzte Version (der Original-Autorlink zur Version 1.0.5 wurde auf die aktuelle Version, d.h. 1.0.6 geändert – Anm. des Üb.), entpacken Sie den Inhalt in ein Verzeichnis, das ich im Folgenden nennen werde [istio-resources].

Zur einfacheren Identifizierung der Istio-Ressourcen erstellen Sie im K8s-Cluster einen Namespace istio-system:

$ kubectl create namespace istio-system

Schließen Sie die Installation ab, indem Sie in das Verzeichnis wechseln [istio-resources] und den folgenden 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 wichtigen Istio-Komponenten in einer Datei aus istio.yaml. Wir haben die standardmäßige Vorlage an unsere Bedürfnisse angepasst und die folgenden Parameter angegeben:

global.mtls.enabled gesetzt auf false (d.h. mTLS-Auth ist deaktiviert – Anm. des Üb.), um unseren Einarbeitungsprozess zu erleichtern;
tracing.enabled aktiviert die Anfrageverfolgung mit Jaeger;
kiali.enabled installiert Kiali im Cluster zur Visualisierung von Services und Traffic;
grafana.enabled installiert Grafana zur Visualisierung der gesammelten Metriken.

Wenden Sie die generierten Ressourcen mit dem folgenden Befehl an:

$ kubectl apply -f istio.yaml

Die Istio-Installation im Cluster ist abgeschlossen! Warten Sie, bis alle Pods im Namespace istio-system im Zustand Laufend oder Abgeschlossen, indem Sie den folgenden Befehl ausführen:

$ kubectl get pods -n istio-system

Jetzt sind wir bereit, im nächsten Abschnitt fortzufahren, in dem wir die Anwendung bereitstellen und starten.

Architektur der Anwendung Sentiment Analysis

Wir verwenden ein Beispiel für die Mikrodienst-Anwendung Sentiment Analysis, das in dem bereits erwähnten Einführungsartikel zu Kubernetes. Es ist komplex genug, um die Möglichkeiten von Istio in der Praxis zu demonstrieren.

Die Anwendung besteht aus vier Mikrodiensten:

Dienst SA-Frontend, der das Frontend der Anwendung in Reactjs bedient;
Dienst SA-WebApp, der die Anfragen zur Sentiment-Analyse bearbeitet;
Dienst SA-Logic, der die eigentliche Sentiment-Analyse durchführt;;
Dienst SA-Feedback, der von den Nutzern Rückmeldungen 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 kommt ein ähnliches Konzept im Rahmen des Ingress-Gateways zum Einsatz, zu dem weitere Details folgen werden.

Anwendung mit dem Istio-Proxy starten

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

Einfügen von Sidecars

Das Einfügen kann erfolgen automatisch oder manuell. Um sidecar-Container automatisch einzufügen, muss dem Namespace ein Label zugewiesen werden istio-injection=enabled, was mit dem folgenden Befehl erfolgt:

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

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

$ 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

Nachdem die Dienste bereitgestellt sind, überprüfen wir, ob die Pods zwei Container haben (einen für den Dienst und seinen Sidecar), indem wir den Befehl ausführen kubectl get pods und sicherstellen, dass unter der Spalte READY folgender Wert angezeigt wird, 2/2der symbolisiert, dass beide Container laufen:

$ 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 stellt sich das so dar:

Envoy-Proxy in einem der Pods

Jetzt, da die Anwendung hochgefahren und funktionsfähig ist, müssen wir den eingehenden Verkehr zulassen, der in die Anwendung gelangt.

Ingress Gateway

Eine bewährte Methode, um dies zu erreichen (Verkehr im Cluster zuzulassen), ist über Ingress Gateway in Istio, das sich an der 'Grenze' des Clusters befindet und es ermöglicht, Funktionen wie Routing, Lastenausgleich, Sicherheit und Überwachung für den eingehenden Verkehr zu aktivieren.

Die Komponente Ingress Gateway und der Dienst, der sie nach außen weiterleitet, wurden beim Installieren von Istio im Cluster eingerichtet. Um die externe IP-Adresse des Dienstes zu erfahren, führen Sie 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 zu diesem IP weiter auf die Anwendung zugreifen (ich werde mich darauf als EXTERNAL-IP beziehen), daher notieren wir den Wert zur Vereinfachung in einer Variablen:

$ 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, über den Browser zu dieser IP zu gelangen, erhalten Sie einen Fehler "Service Unavailable", da Istio standardmäßig allen eingehenden Verkehr blockiert,, bis ein 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 eingehenden Traffic zulassen möchten.

In unserem Fall möchten wir HTTP-Traffic auf Port 80 für alle Hosts zulassen. Diese Aufgabe wird durch die folgende Definition umgesetzt (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 weiteren Erklärungen, mit Ausnahme des Selektors istio: ingressgateway. Mit diesem Selektor können wir angeben, auf welchen Ingress-Gateway die Konfiguration angewendet werden soll. In unserem Fall handelt es sich um den standardmäßig in Istio installierten Ingress-Gateway-Controller.

Die Konfiguration wird durch den folgenden Befehl angewendet:

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

Jetzt erlaubt der Gateway den Zugriff auf Port 80, weiß aber nicht, wohin die Anfragen geleitet werden sollen. Dafür benötigen wir Virtual Services.

Die Ressource VirtualService

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

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

Die Routen, die mit VirtualServices eingerichtet werden müssen

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

Exakte Übereinstimmung mit dem Pfad / soll an SA-Frontend gesendet werden, um index.html zu erhalten;
Pfade mit dem Präfix /static/* soll an SA-Frontend gesendet werden, um statische Dateien zu erhalten, die im Frontend verwendet werden, wie CSS und JavaScript;
Pfade, die unter das reguläre Ausdrucksmuster '^.*\.(ico|png|jpg)$', fallen, sollten an SA-Frontend gesendet werden, da es sich um Bilder handelt, die auf der Seite angezeigt werden.

Die Umsetzung erfolgt mit der folgenden Konfiguration (sa-virtualservice-external.yaml):

Art: VirtualService Metadaten: Name: sa-external-services Spektrum: Hosts: - "*" Gateways: - http-gateway # 1 http: - Übereinstimmung: - URI: genau: \/ - URI: genau: \/callback - URI: Präfix: \/static - URI: Regex: '^.*.(ico|png|jpg) Wichtige Punkte: Dieser VirtualService bezieht sich auf Anfragen, die über http-gateway; Im Ziel definiert den Dienst, an den die Anfragen gesendet werden. Hinweis: Die obige Konfiguration wird in der Datei sa-virtualservice-external.yaml, die auch Einstellungen für die Weiterleitung zu SA-WebApp und SA-Feedback enthält, aber hier im Artikel der Kürze halber gekürzt wurde. Wir wenden VirtualService mit folgendem Befehl an: $ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml virtualservice.networking.istio.io/sa-external-services erstellt Hinweis: Wenn wir die Ressourcen von Istio verwenden, 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. Alles sieht in der Grafik so aus: Istio-IngressGateway-Konfiguration zur Anforderungsmuster Die Anwendung Sentiment Analysis ist verfügbar unter http://{EXTERNAL-IP}/. Keine Sorge, wenn Sie den Status Not Found erhalten: manchmal benötigt es etwas mehr Zeit, bis die Konfiguration wirksam wird und die Envoy-Caches aktualisiert werden. Bevor Sie fortfahren, arbeiten Sie etwas mit der Anwendung, um Traffic zu generieren (seine Anwesenheit ist erforderlich, um in den folgenden Schritten anschaulich zu sein — Anmerkung des Übersetzers). Kiali: Observierbarkeit Um auf die Administrationsoberflä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 viele nützliche Funktionen, beispielsweise zur Überprüfung der Konfiguration von Istio-Komponenten, zur Visualisierung von Diensten basierend auf Informationen, die während der Erfassung von Netzwerkaufträgen gesammelt wurden, um Antworten auf die Fragen „Wer spricht mit wem?“ „Welche Version des Dienstes hat Probleme?“ usw. zu erhalten. Kurz gesagt, erkunden Sie die Möglichkeiten von Kiali, bevor Sie weiter zur Visualisierung von Metriken mit Grafana gehen. Grafana: Metriken visualisieren Die in Istio gesammelten Metriken gelangen zu Prometheus und werden mit Grafana visualisiert. Um auf die Administrationsoberflä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 im Menü Home oben links und wählen Sie Istio Service Dashboard oben links, um mit dem Dienst zu beginnen sa-web-app, um die gesammelten Metriken anzusehen: Hier erwartet uns eine leere und völlig langweilige Darstellung — das wird niemandem gefallen. Lassen Sie uns also 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 viel ansprechendere Grafiken, und zusätzlich gibt es die großartigen Prometheus-Tools für das Monitoring und Grafana für die Visualisierung der Metriken, die es uns ermöglichen, die Leistung, den Gesundheitszustand und Verbesserungen/Degenerationen in der Funktion der Dienste im Laufe der Zeit zu erkennen. Schließlich schauen wir uns das Tracing von Anfragen in den Diensten an. Jaeger: Tracing Tracing ist notwendig, denn je mehr Dienste wir haben, desto schwieriger ist es, die Ursache eines Fehlers zu finden. Schauen wir uns einen einfachen Fall aus dem Bild unten an: Typisches Beispiel einer zufälligen, fehlerhaften Anfrage Die Anfrage kommt an, schlägt fehl — was könnte die Ursache sein? Der erste Dienst? Oder der zweite? In beiden gibt es Ausnahmen — schauen wir uns die Protokolle jedes einzelnen an. Wie oft habt ihr euch dabei ertappt? Unsere Arbeit ähnelt mehr der eines Softwaredetektivs als der eines Entwicklers... Das ist ein weit verbreitetes Problem in Mikrodiensten und wird durch verteilte Tracing-Systeme gelöst, bei denen die Dienste einander einzigartige Header übermitteln. Diese Informationen werden dann in das Tracing-System weitergeleitet, wo sie mit den Anfragedaten abgeglichen werden. Hier eine Darstellung: Zur Identifizierung der Anfrage wird der TraceId verwendet. In Istio wird Jaeger Tracer verwendet, der ein herstellerunabhängiges Framework des OpenTracing API implementiert. Zugang zur Benutzeroberfläche von Jaeger erhält man mit folgendem 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 im Dropdown-Menü nicht angezeigt wird, generieren Sie Aktivitäten auf der Seite und aktualisieren Sie die Benutzeroberfläche. Klicken Sie dann auf die Schaltfläche Find Traces, die die letzten Traces zeigt — wählen Sie einen aus — es wird detaillierte Informationen zu allen Traces angezeigt: Dieser Trace zeigt an: Die Anfrage kommt in istio-ingressgateway und ist die erste Interaktion mit einem der Dienste, wobei eine Trace-ID für die Anfrage generiert wird. Danach leitet das Gateway die Anfrage an den Dienst weiter. sa-web-app. Im Dienst sa-web-app wird die Anfrage von dem Envoy Sidecar aufgegriffen, es wird ein „Kind“ im span erstellt (weshalb wir es in den Traces sehen) und es wird in den Container weitergeleitet. sa-web-app. (Span Eine logische Arbeitseinheit in Jaeger, die einen Namen, einen Zeitstempel für den Beginn der Operation und ihre Dauer hat. Spans können geschachtelt und geordnet sein. Ein gerichteter azyklischer Graph aus Spans bildet einen Trace. — Anmerkung des Übersetzers. Hier wird die Anfrage mittels sentimentAnalysisverarbeitet. Diese Traces wurden bereits von der Anwendung generiert, d.h. es wurden Änderungen am Code vorgenommen. Ab diesem Punkt wird eine POST-Anfrage an sa-logicinitiiert. Die Trace-ID muss von sa-web-app. … Hinweisübertragen werden: In Schritt 4 sollte die Anwendung die von Istio generierten Header sehen und diese in nachfolgende Anfragen übertragen, wie im Bild unten gezeigt: (A) Istio ist verantwortlich für die Übertragung der Header; (B) Die Header werden von den Services bereitgestellt. Istio erledigt die Hauptarbeit, da es Header für eingehende Anfragen generiert, neue Spans in jedem Sidecar erstellt und diese überträgt. Ohne die Bearbeitung der Header in den Services geht der vollständige Pfad der Anfrage-Trace jedoch verloren. Die folgenden Header müssen berücksichtigt (übertragen) werden: x-request-id x-b3-traceid x-b3-spanid x-b3-parentspanid x-b3-sampled x-b3-flags x-ot-span-context Es ist keine komplizierte Aufgabe, jedoch gibt es bereits zur Vereinfachung der Implementierung eine Vielzahl von Bibliotheken, zum Beispiel überträgt der RestTemplate-Client im Service sa-web-app diese Header, wenn man einfach die Bibliotheken Jaeger und OpenTracing zu seinen Abhängigkeiten hinzufügt.. 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, lassen Sie uns die Fragen zu feingesteuerter Routing, Netzwerkverkehrsmanagement, Sicherheit usw. betrachten. Anmerkung des Übersetzers.: Darüber lesen Sie im nächsten Teil der Materialien zu Istio von Rinor Maloku, deren Übersetzungen bald in unserem Blog erscheinen werden. UPDATE (14. März): Der zweite Teil bereits veröffentlicht. P.S. vom Übersetzer Lesen Sie auch in unserem Blog: Teil 1 (Eintreffen auf die grundlegenden Möglichkeiten) Teil 2 (Routing, Verkehrsmanagement), Conduit - ein leichtgewichtiger Service Mesh für Kubernetes; «Was ist ein Service Mesh und warum brauche ich es [für eine Cloudanwendung mit Mikrodiensten]?»; «Wie man einen DAG-Trigger in Airflow mit der Experimental-API erstellt»; «Illustrierte Anleitung zur Netzwerkarchitektur in Kubernetes. Teile 1 und 2»; «Wie ist dieser Sidecar-Container hier [in Kubernetes] gelandet?». Quelle: habr.com route: - destination: host: sa-frontend # 2 port: number: 80
Wichtige Punkte:

Dieser VirtualService bezieht sich auf Anfragen, die über http-gateway;
Im Ziel definiert den Dienst, an den die Anfragen gesendet werden.

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

Anwendbar durch VirtualService aufrufend:

Hinweis: Wenn wir die Ressourcen von Istio 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-Proxies jedes Pods angewendet. Der Ingress Gateway-Controller wird als ein weiterer Envoy dargestellt, der im Control Plane konfiguriert ist. Das sieht in der Übersicht folgendermaßen aus:

Istio-IngressGateway-Konfiguration zur Anforderungsmuster

Die Anwendung Sentiment Analysis ist verfügbar unter http://{EXTERNAL-IP}/. Keine Sorge, wenn Sie den Status Not Found erhalten: manchmal benötigt es etwas mehr Zeit, bis die Konfiguration wirksam wird und die Envoy-Caches aktualisiert werden.

Bevor Sie fortfahren, arbeiten Sie etwas mit der Anwendung, um Traffic zu generieren (seine Anwesenheit ist erforderlich, um in den folgenden Schritten anschaulich zu sein — Anmerkung des Übersetzers).

Kiali: Observierbarkeit

Um auf die Administrationsoberflä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 viele nützliche Funktionen, beispielsweise zur Überprüfung der Konfiguration von Istio-Komponenten, zur Visualisierung von Diensten basierend auf Informationen, die während der Erfassung von Netzwerkaufträgen gesammelt wurden, um Antworten auf die Fragen „Wer spricht mit wem?“ „Welche Version des Dienstes hat Probleme?“ usw. zu erhalten. Kurz gesagt, erkunden Sie die Möglichkeiten von Kiali, bevor Sie weiter zur Visualisierung von Metriken mit Grafana gehen.

Grafana: Metriken visualisieren

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

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

Hier erwartet uns eine leere und völlig langweilige Darstellung — das wird niemandem gefallen. Lassen Sie uns also mit dem folgenden Befehl eine kleine Last erzeugen:

Jetzt haben wir viel ansprechendere Grafiken, und zusätzlich gibt es die großartigen Prometheus-Tools für das Monitoring und Grafana für die Visualisierung der Metriken, die es uns ermöglichen, die Leistung, den Gesundheitszustand und Verbesserungen/Degenerationen in der Funktion der Dienste im Laufe der Zeit zu erkennen.

Schließlich schauen wir uns das Tracing von Anfragen in den Diensten an.

Jaeger: Tracing

Tracing ist notwendig, denn je mehr Dienste wir haben, desto schwieriger ist es, die Ursache eines Fehlers zu finden. Schauen wir uns einen einfachen Fall aus dem Bild unten an:

Typisches Beispiel einer zufälligen, fehlerhaften Anfrage

Die Anfrage kommt an, schlägt fehl — was könnte die Ursache sein? Der erste Dienst? Oder der zweite? In beiden gibt es Ausnahmen — schauen wir uns die Protokolle jedes einzelnen an. Wie oft habt ihr euch dabei ertappt? Unsere Arbeit ähnelt mehr der eines Softwaredetektivs als der eines Entwicklers...

Das ist ein weit verbreitetes Problem in Mikrodiensten und wird durch verteilte Tracing-Systeme gelöst, bei denen die Dienste einander einzigartige Header übermitteln. Diese Informationen werden dann in das Tracing-System weitergeleitet, wo sie mit den Anfragedaten abgeglichen werden. Hier eine Darstellung:

Zur Identifizierung der Anfrage wird der TraceId verwendet.

In Istio wird Jaeger Tracer verwendet, der ein herstellerunabhängiges Framework des OpenTracing API implementiert. Zugang zur Benutzeroberfläche von Jaeger erhält man mit folgendem Befehl:

Jetzt gehen Sie zu http://localhost:16686/ und wählen Sie den Dienst sa-web-app. Wenn der Dienst im Dropdown-Menü nicht angezeigt wird, generieren Sie Aktivitäten auf der Seite und aktualisieren Sie die Benutzeroberfläche. Klicken Sie dann auf die Schaltfläche Find Traces, die die letzten Traces zeigt — wählen Sie einen aus — es wird detaillierte Informationen zu allen Traces angezeigt:

Dieser Trace zeigt an:

Die Anfrage kommt in istio-ingressgateway und ist die erste Interaktion mit einem der Dienste, wobei eine Trace-ID für die Anfrage generiert wird. Danach leitet das Gateway die Anfrage an den Dienst weiter. sa-web-app.
Im Dienst sa-web-app Die Anfrage wird von dem Envoy Sidecar erfasst, ein 'Kind' im Span wird erstellt (deshalb sehen wir es in den Traces) und in den Container weitergeleitet. sa-web-app. (Span — eine logische Arbeitseinheit in Jaeger, die einen Namen, den Beginn der Operation und ihre Dauer hat. Spans können geschachtelt und geordnet sein. Ein gerichteter azyklischer Graph aus Spans bildet einen Trace. — Anmerkung des Übersetzers.)
Hier wird die Anfrage mittels sentimentAnalysisverarbeitet. Diese Traces wurden bereits von der Anwendung generiert, d.h. es wurden Änderungen am Code vorgenommen.
Ab diesem Punkt wird eine POST-Anfrage an sa-logicinitiiert. Die Trace-ID muss von sa-web-app.
…

Hinweisübertragen werden: In Schritt 4 sollte die Anwendung die von Istio generierten Header sehen und diese in nachfolgende Anfragen übertragen, wie im Bild unten gezeigt:

(A) Istio ist verantwortlich für die Übertragung der Header; (B) Die Header werden von den Services bereitgestellt.

Istio übernimmt die Hauptarbeit, da es Header für eingehende Anfragen generiert, neue Spans in jedem Sidecar erstellt und sie weiterleitet. Ohne die Arbeit mit den Headern innerhalb der Dienste geht jedoch der vollständige Trace-Pfad der Anfrage verloren.

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

Es ist keine komplizierte Aufgabe, jedoch gibt es bereits zur Vereinfachung der Implementierung eine Vielzahl von Bibliotheken, zum Beispiel überträgt der RestTemplate-Client im Service sa-web-app diese Header, wenn man einfach die Bibliotheken Jaeger und OpenTracing zu seinen Abhängigkeiten hinzufügt..

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, lassen Sie uns die Fragen zu feingesteuerter Routing, Netzwerkverkehrsmanagement, Sicherheit usw. betrachten.

Anmerkung des Übersetzers.: Darüber lesen Sie im nächsten Teil der Materialien zu Istio von Rinor Maloku, deren Übersetzungen bald in unserem Blog erscheinen werden. UPDATE (14. März): Der zweite Teil bereits veröffentlicht.