Hinweis perev. : Service-Meshes sind definitiv eine relevante Lösung in der modernen Infrastruktur für Anwendungen geworden, die der Microservice-Architektur folgen. Obwohl Istio von vielen DevOps-Ingenieuren gehört wird, handelt es sich um ein ziemlich neues Produkt, das aufgrund seiner umfassenden Funktionen möglicherweise viel Zeit für die Bekanntschaft benötigt. Der deutsche Ingenieur Rinor Maloku, der beim Telekommunikationsunternehmen Orange Networks für das Cloud-Computing für Großkunden verantwortlich ist, hat eine bemerkenswerte Reihe von Materialien verfasst, mit denen Sie schnell und tief in Istio eintauchen können. Er beginnt seine Geschichte damit, was Istio kann und wie Sie es schnell mit eigenen Augen sehen können.Istio ist ein Open Source-Projekt, das in Zusammenarbeit mit Teams von Google, IBM und Lyft entwickelt wurde. Es löst die Schwierigkeiten, die bei Anwendungen auf der Basis von Mikrodiensten auftreten, wie zum Beispiel:
- Verkehrsmanagement : Zeitüberschreitungen, Wiederholungsversuche, Lastausgleich;
- Sicherheit : Authentifizierung und Autorisierung des Endbenutzers;
- Beobachtbarkeit : Verfolgung, Überwachung, Protokollierung.
Alle von ihnen können auf Anwendungsebene gelöst werden, aber danach werden Ihre Dienste nicht mehr "Mikro". Alle zusätzlichen Anstrengungen zur Lösung dieser Probleme sind eine zusätzliche Verschwendung von Unternehmensressourcen, die direkt für Unternehmenswerte verwendet werden könnten. Betrachten Sie ein Beispiel:
Projektmanager: Wie lange muss Feedback hinzugefügt werden?
Entwickler: Zwei Sprints.
MP: Was? .. Es ist nur CRUD!
R: CRUD zu erstellen ist ein einfacher Teil der Aufgabe, aber wir müssen Benutzer und Dienste noch authentifizieren und autorisieren. Da das Netzwerk unzuverlässig ist, müssen Sie wiederholte Anforderungen sowie das Leistungsschaltermuster in Clients implementieren. Um sicherzustellen, dass das gesamte System nicht herunterfällt, benötigen Sie Zeitüberschreitungen und Schotte (weitere Einzelheiten zu den beiden genannten Mustern finden Sie weiter im Artikel - ca. Übersetzung) . Um Probleme zu erkennen, zu überwachen, zu verfolgen, [...]
MP: Oh, dann fügen wir diese Funktion einfach in den Produktservice ein.
Ich denke, die Idee ist klar: Das Volumen der Schritte und Anstrengungen, die erforderlich sind, um einen Dienst hinzuzufügen, ist enorm. In diesem Artikel werden wir untersuchen, wie Istio alle oben genannten Schwierigkeiten (die nicht auf die Geschäftslogik abzielen) aus den Diensten entfernt.
Hinweis : In diesem Artikel wird davon ausgegangen, dass Sie über praktische Kenntnisse in Kubernetes verfügen. Ansonsten empfehle ich,
meine Einführung in Kubernetes zu lesen und erst danach dieses Material weiterzulesen.
Idee Istio
In einer Welt ohne Istio stellt ein Dienst direkte Anforderungen an einen anderen, und im Falle eines Fehlers muss der Dienst diese selbst verarbeiten: einen neuen Versuch unternehmen, eine Zeitüberschreitung bereitstellen, einen Leistungsschalter öffnen usw.
Netzwerkverkehr in KubernetesIstio bietet auch eine spezialisierte Lösung, die völlig unabhängig von Diensten und Funktionen ist, indem sie die Netzwerkinteraktion stört. Und so implementiert es:
- Fehlertoleranz : Basierend auf dem Statuscode in der Antwort wird erkannt, ob die Anforderung fehlgeschlagen ist, und erneut ausgeführt.
- Kanarische Rollouts : Leitet nur einen festen Prozentsatz der Anzahl der Anfragen auf die neue Version des Dienstes um.
- Überwachung und Metriken : Wie lange hat der Dienst geantwortet?
- Ablaufverfolgung und Beobachtbarkeit : Fügt jeder Anforderung spezielle Header hinzu und verfolgt sie im Cluster.
- Sicherheit : Extrahiert JWT-Token, authentifiziert und autorisiert Benutzer.
Dies sind nur einige der Möglichkeiten (wirklich nur einige!), Sie zu faszinieren. Lassen Sie uns nun in die technischen Details eintauchen!
Architektur Istio
Istio fängt den gesamten Netzwerkverkehr ab und wendet eine Reihe von Regeln an, wobei in jeden Pod ein intelligenter Proxy in Form eines Beiwagencontainers eingefügt wird. Proxys, die alle Features aktivieren, bilden eine Datenebene und können mithilfe der
Steuerungsebene dynamisch konfiguriert werden.
Datenebene
Die in Pods eingefügten Proxys ermöglichen es Istio, die von uns benötigten Anforderungen problemlos zu erfüllen. Überprüfen Sie beispielsweise die Wiederholungs- und Leistungsschalterfunktionen.
Wie Wiederholungsversuche und Unterbrechungen in Envoy implementiert werdenZusammenfassend:
- Gesandter (spricht von einem Proxy in einem Beiwagencontainer, der als separates Produkt verteilt wird - ca. Übersetzung) Sendet eine Anfrage an die erste Instanz von Service B, und es tritt ein Fehler auf.
- Wiederholungsversuche des Gesandtenwagens. (1)
- Die fehlgeschlagene Anforderung wird an den Proxy zurückgegeben, der sie aufgerufen hat.
- Dadurch wird der Leistungsschalter geöffnet und der nächste Dienst für nachfolgende Anforderungen aufgerufen. (2)
Dies bedeutet, dass Sie nicht die nächste Wiederholungsbibliothek verwenden müssen, sondern keine eigene Implementierung von Circuit Breaking und Service Discovery in der Programmiersprache X, Y oder Z durchführen müssen. All dies und vieles mehr ist in Istio sofort verfügbar und erfordert
keine Änderungen am Code.
Großartig! Jetzt möchten Sie vielleicht eine Reise mit Istio unternehmen, aber es gibt immer noch einige Zweifel, offene Fragen. Wenn dies eine universelle Lösung für alle Gelegenheiten im Leben ist, dann haben Sie einen berechtigten Verdacht: Schließlich erweisen sich alle derartigen Entscheidungen in Wirklichkeit für jeden Anlass als ungeeignet.
Und schließlich fragen Sie: "Ist es anpassbar?"
Jetzt sind Sie bereit für eine Seereise - und machen wir uns mit dem Kontrollflugzeug vertraut.
Steuerebene
Es besteht aus drei Komponenten:
Pilot ,
Mixer und
Citadel , die zusammenarbeiten, um Gesandte so zu konfigurieren, dass sie den Verkehr weiterleiten, Richtlinien anwenden und Telemetriedaten erfassen. Schematisch sieht alles so aus:
Steuerungsebene Interaktion mit DatenebeneGesandte (d. H. Datenebene) werden unter Verwendung von
Kubernetes CRD (Custom Resource Definitions) konfiguriert, die von Istio definiert und speziell für diesen Zweck entwickelt wurden. Für Sie bedeutet dies, dass sie die nächste Ressource in Kubernetes mit vertrauter Syntax zu sein scheinen. Nach der Erstellung wird diese Ressource von der Steuerebene aufgenommen und auf Gesandte angewendet.
Service Ratio für Istio
Wir haben Istios Einstellung zu Dienstleistungen beschrieben, aber nicht das Gegenteil: Wie hängen Dienstleistungen mit Istio zusammen?
Ehrlich gesagt weiß Istio über das Vorhandensein von Dienstleistungen und Fischen Bescheid - über Wasser, wenn sie sich fragen: „Was ist Wasser im Allgemeinen?“.
Illustration von Victoria Dimitrakopoulos : - Wie gefällt dir das Wasser? - Was ist Wasser im Allgemeinen?Auf diese Weise können Sie den Arbeitscluster verwenden. Nach der Bereitstellung der Istio-Komponenten funktionieren die darin enthaltenen Dienste weiterhin. Nach dem Entfernen dieser Komponenten ist wieder alles in Ordnung. Es ist klar, dass Sie dadurch die von Istio gebotenen Möglichkeiten verlieren.
Genug Theorie - lassen Sie uns dieses Wissen in die Praxis umsetzen!
Istio in der Praxis
Istio benötigt einen Kubernetes-Cluster, in dem mindestens 4 vCPUs und 8 GB RAM verfügbar sind. Um den Cluster schnell zu erhöhen und den Anweisungen aus dem Artikel zu folgen, empfehle ich die Verwendung der Google Cloud Platform, die neuen Nutzern
300 US-Dollar kostenlos bietet.
Nachdem Sie einen Cluster erstellt und den Zugriff auf Kubernetes über das Konsolendienstprogramm konfiguriert haben, können Sie Istio über den Helm-Paketmanager installieren.
Helminstallation
Installieren Sie den Helm-Client auf Ihrem Computer, wie in der
offiziellen Dokumentation angegeben . Wir werden es verwenden, um Vorlagen für die Installation von Istio im nächsten Abschnitt zu generieren.
Installieren Sie Istio
Laden Sie die Istio-Ressourcen aus der
neuesten Version herunter (der Link des ursprünglichen Autors zu Version 1.0.5 wurde in die aktuelle Version geändert, dh 1.0.6 - ca. Übersetzung) . Extrahieren Sie den Inhalt in ein Verzeichnis, das ich in Zukunft
[istio-resources] werde
[istio-resources] .
Erstellen Sie den
istio-system Namespace im K8s-Cluster, um die Identifizierung von Istio-Ressourcen zu vereinfachen:
$ kubectl create namespace istio-system
[istio-resources] die Installation ab, indem Sie in das
[istio-resources] und den folgenden Befehl
[istio-resources] :
$ 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 Schlüsselkomponenten von Istio in die Datei
istio.yaml . Wir haben die Standardvorlage für uns selbst geändert und die folgenden Parameter angegeben:
global.mtls.enabled auf false (d. h. die mTLS-Authentifizierung ist deaktiviert - ca. übersetzt) , um unseren Datierungsprozess zu vereinfachen.tracing.enabled die tracing.enabled mit Jaeger.kiali.enabled installiert Kiali in einem Cluster, um Dienste und Datenverkehr zu visualisieren.grafana.enabled legt Grafana fest, um gesammelte Metriken zu visualisieren.
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
istio-system Namespace ausgeführt oder
Completed indem Sie den folgenden Befehl
istio-system :
$ kubectl get pods -n istio-system
Jetzt können wir mit dem nächsten Abschnitt fortfahren, in dem wir die Anwendung auslösen und starten.
Sentiment Analysis Anwendungsarchitektur
Nehmen wir ein Beispiel für die Microservice-Anwendung Sentiment Analysis, die im bereits erwähnten
Einführungsartikel in Kubernetes verwendet wird . Es ist hoch entwickelt genug, um die Fähigkeiten von Istio in der Praxis zu demonstrieren.
Die Anwendung besteht aus vier Microservices:
- Service SA-Frontend , das Front-End-Anwendungen auf Reactjs bereitstellt;
- Ein SA-WebApp- Dienst, der Sentiment Analysis-Anforderungen bearbeitet .
- Service SA-Logic , der sentimentale Analysen durchführt ;
- Service SA-Feedback , das Feedback von Benutzern zur Genauigkeit der Analyse erhält.
In diesem Diagramm sehen wir neben den Diensten auch den Ingress Controller, der in Kubernetes eingehende Anforderungen an die entsprechenden Dienste weiterleitet. Istio verwendet ein ähnliches Konzept innerhalb des Ingress Gateway, dessen Details folgen werden.
Starten einer Anwendung mit einem Proxy von Istio
Klonen Sie für die im Artikel genannten weiteren Vorgänge das
Istio-Mastery- Repository. Es enthält die App und Manifeste für Kubernetes und Istio.
Beiwageneinsatz
Das Einfügen kann
automatisch oder
manuell erfolgen . Um Seitenwagencontainer automatisch einzufügen, müssen Sie
istio-injection=enabled Label
istio-injection=enabled auf den
istio-injection=enabled , was mit dem folgenden Befehl ausgeführt wird:
$ kubectl label namespace default istio-injection=enabled namespace/default labeled
Jetzt erhält jeder Pod, der im Standard-Namespace bereitgestellt wird, seinen Sidecar-Container. Um dies zu überprüfen, installieren wir eine
[istio-mastery] indem wir in das Stammverzeichnis des Repositorys
[istio-mastery] und den folgenden Befehl
[istio-mastery] :
$ 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 wir die Dienste erweitert haben, überprüfen wir, ob Pods zwei Container haben (mit dem Dienst selbst und seinem Beiwagen), indem
kubectl get pods Befehl
kubectl get pods ausführen und sicherstellen, dass der Wert
2/2 in der Spalte
READY , 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
Optisch sieht es so aus:
Gesandte Stellvertreter in einem der PodsNachdem die Anwendung ausgeführt wird, müssen wir zulassen, dass eingehender Datenverkehr in die Anwendung gelangt.
Ingress Gateway
Die beste Vorgehensweise, um dies zu erreichen (um Datenverkehr im Cluster zuzulassen), ist das
Ingress Gateway in Istio, das sich an der „Grenze“ des Clusters befindet und es Ihnen ermöglicht, Istio-Funktionen wie Routing, Lastausgleich, Sicherheit und Überwachung für eingehenden Datenverkehr zu aktivieren.
Die Ingress Gateway-Komponente und der Dienst, der sie nach außen weiterleitet, wurden während der Installation von Istio im Cluster installiert. Gehen Sie wie folgt vor, um die externe IP-Adresse eines Dienstes zu ermitteln:
$ 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 weiterhin über diese IP auf die Anwendung zugreifen (ich werde sie als EXTERNAL-IP bezeichnen), daher werden wir den Wert der Einfachheit halber in eine Variable schreiben:
$ 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 einen Browser auf diese IP zuzugreifen, wird der Fehler "Dienst nicht verfügbar" angezeigt, da
Standardmäßig blockiert Istio den gesamten eingehenden Datenverkehr, bis ein Gateway definiert ist.
Gateway-Ressource
Gateway ist eine CRD (Custom Resource Definition) in Kubernetes, die nach der Installation von Istio in einem Cluster und der Aktivierung der Angabe der Ports, Protokolle und Hosts definiert wird, für die eingehender Datenverkehr zugelassen werden soll.
In unserem Fall möchten wir den HTTP-Verkehr für alle Hosts auf Port 80 zulassen. Die Aufgabe wird durch die folgende Definition
( http-gateway.yaml ) implementiert :
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 bedarf keiner Erläuterung mit Ausnahme des
istio: ingressgateway . Mit diesem Selektor können wir angeben, auf welches Ingress Gateway die Konfiguration angewendet wird. In unserem Fall ist dies der Ingress Gateway-Controller, der standardmäßig in Istio installiert wurde.
Die Konfiguration wird durch Aufrufen des folgenden Befehls angewendet:
$ kubectl apply -f resource-manifests/istio/http-gateway.yaml gateway.networking.istio.io/http-gateway created
Jetzt ermöglicht das Gateway den Zugriff auf Port 80, hat jedoch keine Ahnung, wohin Anforderungen weitergeleitet werden sollen. Dies erfordert
virtuelle Dienste .
VirtualService-Ressource
VirtualService teilt Ingress Gateway mit, wie Anforderungen weitergeleitet werden sollen, die innerhalb des Clusters zulässig sind.
Anfragen an unsere Anwendung, die über das http-Gateway eingehen, müssen an die Dienste sa-frontend, sa-web-app und sa-feedback gesendet werden:
Zu konfigurierende Routen mit VirtualServicesBetrachten Sie die Anforderungen, die an SA-Frontend gesendet werden sollten:
- Eine genaue Übereinstimmung auf dem Pfad
/ sollte an SA-Frontend gesendet werden, um index.html zu erhalten. - Pfade mit dem Präfix
/static/* müssen an SA-Frontend gesendet werden, um statische Dateien zu empfangen, die im Frontend verwendet werden, z. B. CSS und JavaScript. - Pfade, die dem regulären Ausdruck
'^.*\.(ico|png|jpg)$' müssen an SA-Frontend gesendet werden Dies sind die auf der Seite angezeigten Bilder.
Die Implementierung wird durch die folgende Konfiguration erreicht
( 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)$' route: - destination: host: sa-frontend # 2 port: number: 80
Wichtige Punkte:
- Dieser VirtualService bezieht sich auf Anforderungen, die über das http-Gateway eingehen .
destination definiert den Dienst, an den Anforderungen gesendet werden.
Hinweis : Die obige Konfiguration wird in der Datei
sa-virtualservice-external.yaml gespeichert, die auch die Einstellungen für das Routing in SA-WebApp und SA-Feedback enthält, wurde jedoch hier im Artikel der Kürze halber gekürzt.
Wenden Sie VirtualService an, indem Sie Folgendes aufrufen:
$ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml virtualservice.networking.istio.io/sa-external-services created
Hinweis : Wenn wir Istio-Ressourcen verwenden, löst der Kubernetes-API-Server ein Ereignis aus, das die Istio-Steuerebene empfängt. Danach wird die neue Konfiguration auf die Envoy-Proxys jedes Pods angewendet. Der Ingress Gateway-Controller scheint der nächste in der Steuerebene konfigurierte Gesandte zu sein. Das alles auf dem Diagramm sieht so aus:
Istio-IngressGateway-Konfiguration für das Abfrage-RoutingDie Stimmungsanalyse ist unter
http://{EXTERNAL-IP}/ verfügbar. Machen Sie sich keine Sorgen, wenn Sie den Status "Nicht gefunden" erhalten:
Manchmal dauert es etwas länger, bis die Konfiguration wirksam wird und die Envoy-Caches aktualisiert werden .
Bevor Sie fortfahren, arbeiten Sie ein wenig mit der Anwendung, um Datenverkehr zu generieren
(deren Vorhandensein ist aus Gründen der Klarheit in den nächsten Schritten erforderlich - ca. Übersetzung) .
Kiali: Beobachtbarkeit
Führen Sie den folgenden Befehl aus, um zur Kiali-Verwaltungsoberfläche zu gelangen:
$ 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 / und melden Sie sich als admin / admin an. Hier finden Sie viele nützliche Funktionen, zum Beispiel zum Überprüfen der Konfiguration von Istio-Komponenten, zum Visualisieren von Diensten anhand von Informationen, die beim Abfangen von Netzwerkanforderungen gesammelt wurden, und zum Erhalten von Antworten auf die Fragen „Wer kontaktiert wen?“, „Welche Version des Dienstes stürzt ab?“. usw. Informieren Sie sich im Allgemeinen über die Möglichkeiten von Kiali, bevor Sie mit Grafana Metriken visualisieren.
Grafana: Visualisierung von Metriken
In Istio gesammelte Metriken gelangen in Prometheus und werden mit Grafana visualisiert. Führen Sie den folgenden Befehl aus, um in die Grafana-Administrationsoberfläche zu gelangen, und öffnen Sie dann
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
Beginnen Sie mit dem
sa-web-app-Dienst , indem
Sie oben links auf das
Home- Menü oben links
klicken und das
Istio-Service-Dashboard auswählen, um die gesammelten
Messdaten anzuzeigen :
Hier warten wir auf eine leere und völlig langweilige Leistung - das Management wird dies niemals gutheißen. Erstellen wir eine kleine Last mit dem folgenden Befehl:
$ 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 schönere Diagramme und zusätzlich dazu wunderbare Prometheus-Tools zur Überwachung und Grafana zur Visualisierung von Metriken, mit denen wir mehr über die Leistung, den Gesundheitszustand, Verbesserungen / Verschlechterungen der Dienste im Laufe der Zeit erfahren können.
Schauen wir uns zum Schluss die Ablaufverfolgung von Anforderungen in Diensten an.
Jaeger: Spur
Wir müssen nachverfolgen, denn je mehr Dienste wir haben, desto schwieriger ist es, die Ursache des Fehlers zu finden. Schauen wir uns einen einfachen Fall aus dem Bild unten an:
Ein typisches Beispiel für eine zufällige fehlgeschlagene AnforderungDie Anfrage kommt, fällt -
was ist der Grund? Erster Service? Oder der zweite? In beiden Fällen gibt es Ausnahmen - schauen wir uns die einzelnen Protokolle an. Wie oft machst du das? Unsere Arbeit ähnelt eher Software-Detektiven als Entwicklern ...
Dies ist ein weit verbreitetes Problem bei Mikrodiensten und wird durch verteilte Ablaufverfolgungssysteme gelöst, in denen Dienste sich gegenseitig einen eindeutigen Header übergeben. Anschließend werden diese Informationen an das Ablaufverfolgungssystem umgeleitet, wo sie den Anforderungsdaten zugeordnet werden. Hier ist eine Illustration:
TraceId wird verwendet, um die Anforderung zu identifizieren.Istio verwendet Jaeger Tracer, der ein herstellerunabhängiges OpenTracing-API-Framework implementiert. Sie können mit dem folgenden Befehl auf die Jaeger-Benutzeroberfläche zugreifen:
$ kubectl port-forward -n istio-system \ $(kubectl get pod -n istio-system -l app=jaeger \ -o jsonpath='{.items[0].metadata.name}') 16686
Gehen Sie nun zu
http: // localhost: 16686 / und wählen Sie den Dienst
sa-web-app aus . Wenn der Dienst nicht im Dropdown-Menü angezeigt wird, zeigen / generieren Sie Aktivitäten auf der Seite und aktualisieren Sie die Benutzeroberfläche. Klicken Sie anschließend auf die Schaltfläche "
Spuren suchen", um die neuesten Spuren anzuzeigen. Wählen Sie eine beliebige aus. Es werden detaillierte Informationen zu allen Spuren angezeigt:
Diese Spur zeigt:
- Die Anfrage kommt zu istio-ingressgateway (dies ist die erste Interaktion mit einem der Dienste, und für die Anfrage wird eine Trace-ID generiert). Danach sendet das Gateway die Anfrage an den sa-web-app-Dienst .
- Im sa-web-app-Dienst wird die Anfrage vom Envoy-Beiwagen abgeholt, ein „Kind“ wird in der Spanne erstellt (daher sehen wir es in den Traces) und in den sa-web-app- Container umgeleitet. ( Span ist eine logische Arbeitseinheit in Jaeger, die einen Namen, die Zeit, zu der die Operation gestartet wurde, und ihre Dauer hat. Spans können verschachtelt und geordnet werden. Ein gerichteter azyklischer Graph aus Spans bildet eine Spur. - Ca. Transl.)
- Hier wird die Anfrage von der sentimentAnalysis- Methode verarbeitet. Diese Spuren werden bereits von der Anwendung erzeugt, d.h. Sie erforderten Änderungen am Code.
- Ab diesem Moment wird eine POST-Anfrage an sa-Logik initiiert. Die Trace-ID muss von der sa-web-app weitergeleitet werden .
- ...
Hinweis : In Schritt 4 sollte die Anwendung die von Istio generierten Header sehen und an nachfolgende Anforderungen weiterleiten, wie in der folgenden Abbildung dargestellt:
(A) Istio ist für die Weiterleitung der Header verantwortlich. (B) Services sind für die Header verantwortlich.Istio erledigt den Großteil der Arbeit als generiert Header für eingehende Anfragen, erstellt neue Bereiche in jeder Sidecare und leitet diese weiter. Ohne die Arbeit mit Headern innerhalb der Dienste geht jedoch der vollständige Pfad der Anforderungsverfolgung verloren.
Folgende Überschriften sollten 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
Dies ist eine einfache Aufgabe. Um die Implementierung zu vereinfachen, sind jedoch bereits
viele Bibliotheken vorhanden. Beispielsweise leitet der RestTemplate-Client im sa-web-app-Dienst diese Header weiter, wenn Sie einfach die Jaeger- und OpenTracing-Bibliotheken hinzufügen.
Beachten Sie, dass die Sentiment Analysis-Anwendung Implementierungen auf Flask, Spring und ASP.NET Core demonstriert.Jetzt, da klar ist, was wir aus der Box bekommen (oder fast "aus der Box"), werden wir Fragen des fein abgestimmten Routings, des Netzwerkverkehrsmanagements, der Sicherheit usw. berücksichtigen!
Hinweis perev. : Lesen Sie darüber in der nächsten Ausgabe von Rinor Malokus Istio, die in naher Zukunft auf unserem Blog verfügbar sein wird. UPDATE (14. März): Der zweite Teil wurde bereits veröffentlicht.PS vom Übersetzer
Lesen Sie auch in unserem Blog: