Zurück zu Microservices mit Istio. Teil 1

Notiz. übersetzen: Service Meshes sind definitiv zu einem heißen Thema in der heutigen Infrastruktur für Anwendungen geworden, die einer Microservice-Architektur folgen. Auch wenn Istio auf dem Radar vieler DevOps-Ingenieure steht, handelt es sich um ein relativ neues Produkt, dessen Features zwar komplex sind, dessen Einarbeitung jedoch viel Zeit in Anspruch nehmen kann. Der deutsche Ingenieur Rinor Maloku, der beim Telekommunikationsunternehmen Orange Networks für Cloud Computing für Großkunden verantwortlich ist, hat eine wunderbare Reihe von Materialien geschrieben, die es Ihnen ermöglichen, schnell und tief in Istio einzutauchen. Er beginnt seine Geschichte damit, was Istio kann und wie man es schnell mit eigenen Augen sehen kann.

Istio — Open-Source-Projekt, entwickelt in Zusammenarbeit mit Teams von Google, IBM und Lyft. Es löst die Komplexitäten, die beispielsweise bei auf Microservices basierenden Anwendungen auftreten, wie zum Beispiel:

• Verkehrsregelung: Zeitüberschreitungen, Wiederholungsversuche, Lastausgleich;
• Sicherheit: Authentifizierung und Autorisierung des Endbenutzers;
• Beobachtbarkeit: Nachverfolgung, Überwachung, Protokollierung.

Alle diese Probleme können auf Anwendungsebene gelöst werden. Danach sind Ihre Dienste jedoch nicht mehr „Mikro“-Dienste. Der gesamte zusätzliche Aufwand zur Lösung dieser Probleme ist eine Verschwendung von Unternehmensressourcen, die direkt für den Geschäftswert genutzt werden könnten. Betrachten Sie ein Beispiel:

Projektmanager: Wie lange dauert es, eine Feedback-Funktion hinzuzufügen?
Entwickler: Zwei Sprints.

MP: Was?... Es ist einfach DURCHDACHT!
R: CRUD durchzuführen ist der einfache Teil der Aufgabe, aber wir müssen trotzdem Benutzer und Dienste authentifizieren und autorisieren. Da das Netzwerk unzuverlässig ist, müssen Sie auch wiederholte Anfragen implementieren Leistungsschaltermuster bei Kunden. Um sicherzustellen, dass das gesamte System nicht abstürzt, treten keine Zeitüberschreitungen usw. auf Schotte (Weitere Einzelheiten zu beiden genannten Mustern finden Sie später im Artikel.), und um Probleme zu erkennen, zu überwachen, zu verfolgen, […]

MP: Oh, dann lasst uns diese Funktion einfach in den Produktservice integrieren.

Ich denke, die Idee ist klar: Die Anzahl der Schritte und der Aufwand, die erforderlich sind, um einen einzelnen Dienst hinzuzufügen, sind enorm. In diesem Artikel werfen wir einen Blick darauf, wie Istio die gesamte oben erwähnte Komplexität (die nicht von der Geschäftslogik angesprochen wird) aus den Diensten entfernt.

Beachten: Der Artikel geht davon aus, dass Sie über praktische Kenntnisse in Kubernetes verfügen. Ansonsten empfehle ich die Lektüre meine Einführung in Kubernetes und lesen Sie erst dann dieses Material weiter.

Istio-Idee

In einer Welt ohne Istio stellt ein Dienst direkte Anfragen an einen anderen, und im Falle eines Ausfalls muss sich der Dienst selbst darum kümmern: einen neuen Versuch unternehmen, für eine Zeitüberschreitung sorgen, einen Leistungsschalter öffnen usw.

Netzwerkverkehr in Kubernetes

Istio hingegen bietet eine spezialisierte Lösung, die völlig unabhängig von Diensten und Funktionen ist, indem sie in die Netzwerkinteraktion eingreift. Und so implementiert es:

• Fehlertoleranz: Anhand des Statuscodes in der Antwort erkennt es, ob die Anfrage fehlgeschlagen ist, und sendet sie erneut.
• Canary-Rollouts: Leitet nur einen festen Prozentsatz der Anfragen an die neue Version des Dienstes weiter.
• Überwachung und Metriken: Wie lange hat es gedauert, bis der Dienst geantwortet hat?
• Nachverfolgung und Beobachtbarkeit: Fügt jeder Anfrage spezielle Header hinzu und verfolgt sie im gesamten Cluster.
• Sicherheit: Ruft ein JWT-Token ab, authentifiziert und autorisiert Benutzer.

Dies sind nur einige der Möglichkeiten (wirklich nur ein paar!), die Sie faszinieren werden. Kommen wir nun zu den technischen Details!

Die Architektur

Istio fängt den gesamten Netzwerkverkehr ab und wendet eine Reihe von Regeln darauf an, indem es in jeden Pod einen Smart Proxy in Form eines Sidecar-Containers einfügt. Proxys, die alle Möglichkeiten aktivieren, bilden a Datenebeneund können mit dynamisch angepasst werden Steuerebene.

Datenebene

Die in die Pods eingefügten Proxys ermöglichen es Istio, die von uns benötigten Anforderungen problemlos zu erfüllen. Schauen wir uns zum Beispiel die Wiederholungsversuche und die Schutzschalterfunktionen an.

Wie Wiederholungsversuche und Stromkreisunterbrechungen in Envoy implementiert werden

Fassen wir zusammen:

1. Gesandte (Wir sprechen von einem Proxy, der sich in einem Sidecar-Container befindet, der verteilt wird und wie separates Produkt - ca. übersetzt) sendet eine Anfrage an die erste Instanz von Dienst B und schlägt fehl.
2. Envoy Sidecar versucht es noch einmal (wiederholen). (1)
3. Die fehlgeschlagene Anfrage wird an den Proxy zurückgegeben, der sie aufgerufen hat.
4. 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 Retry-Bibliothek verwenden müssen und keine eigene Implementierung von Circuit Breaking und Service Discovery in der Programmiersprache X, Y oder Z erstellen müssen. All dies und mehr ist in der verfügbar Box in Istio und erfordert nicht nicht Codeänderungen.

Großartig! Jetzt möchten Sie vielleicht mit Istio auf eine Reise gehen, aber es gibt noch einige Zweifel und offene Fragen. Wenn es sich hierbei um eine universelle Lösung für alle Fälle im Leben handelt, dann haben Sie einen berechtigten Verdacht: Schließlich sind alle diese Lösungen tatsächlich nicht für jeden Fall geeignet.

Und schließlich fragen Sie: „Ist es anpassbar?“

Jetzt sind Sie bereit für eine Seereise – und machen wir uns mit Control Plane vertraut.

Steuerebene

Es besteht aus drei Komponenten: Pilot, Mixer и Zitadelle, die zusammen Envoys so konfigurieren, dass sie den Datenverkehr weiterleiten, Richtlinien anwenden und Telemetriedaten sammeln. Schematisch sieht das Ganze so aus:

Interaktion der Kontrollebene mit der Datenebene

Envoys (d. h. Datenebene) werden mit konfiguriert Kubernetes CRD (Custom Resource Definitions), die von Istio definiert und speziell für diesen Zweck entwickelt wurden. Für Sie bedeutet dies, dass es sich lediglich um eine weitere Ressource in Kubernetes mit einer vertrauten Syntax handelt. Sobald diese Ressource erstellt ist, wird sie von der Kontrollebene übernommen und auf Envoys angewendet.

Beziehung der Dienste zu Istio

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

Um ehrlich zu sein, wissen Dienste über das Vorhandensein von Istio genauso Bescheid wie Fische über Wasser, wenn sie sich fragen: „Was ist Wasser überhaupt?“.

Illustration Victoria Dimitrakopoulos: Wie gefällt dir das Wasser? - Was ist Wasser überhaupt?

Sie können also einen funktionierenden Cluster nehmen und nach der Bereitstellung der Istio-Komponenten funktionieren die darin enthaltenen Dienste weiterhin, und nach dem Entfernen dieser Komponenten ist alles wieder in Ordnung. Es ist klar, dass Sie in diesem Fall die Möglichkeiten verlieren, die Istio bietet.

Genug der Theorie – lasst uns dieses Wissen in die Praxis umsetzen!

Istio in der Praxis

Istio erfordert einen Kubernetes-Cluster mit mindestens 4 vCPUs und 8 GB verfügbarem RAM. 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 Benutzern angeboten wird 300 $ kostenlos.

Nachdem Sie den Cluster erstellt und den Zugriff auf Kubernetes über das Konsolendienstprogramm eingerichtet haben, können Sie Istio über den Helm-Paketmanager installieren.

Helminstallation

Installieren Sie den Helm-Client wie unter beschrieben auf Ihrem Computer amtliche Dokumentation. Wir werden damit im nächsten Abschnitt Vorlagen für die Installation von Istio generieren.

Installation

Laden Sie Istio-Ressourcen herunter von neueste Erscheinung (Der Link des ursprünglichen Autors zur Version 1.0.5 wurde auf die aktuelle geändert, d. h. 1.0.6 – ca. übersetzt.), extrahieren Sie den Inhalt in ein einzelnes Verzeichnis, das ich als bezeichnen werde [istio-resources].

Erstellen Sie zur einfachen Identifizierung von Istio-Ressourcen einen Namespace im K8s-Cluster istio-system:

$ kubectl create namespace istio-system

Schließen Sie die Installation ab, indem Sie zum Verzeichnis navigieren [istio-resources] 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 Schlüsselkomponenten von Istio in eine Datei aus istio.yaml. Wir haben die Standardvorlage für uns modifiziert, indem wir folgende Parameter angegeben haben:

• global.mtls.enabled eingebaut false (d. h. die mTLS-Authentifizierung ist deaktiviert – ca. übersetzt)um unseren Dating-Prozess zu vereinfachen;
• tracing.enabled ermöglicht die Anfrageverfolgung mit Jaeger;
• kiali.enabled installiert Kiali in einem Cluster, um Dienste und Verkehr zu visualisieren;
• grafana.enabled installiert Grafana, um die gesammelten Metriken zu visualisieren.

Wenden Sie die generierten Ressourcen mit dem folgenden Befehl an:

$ kubectl apply -f istio.yaml

Die Installation von Istio im Cluster ist abgeschlossen! Warten Sie, bis alle Pods im Namespace sind istio-system sind in der Lage Running oder Completedindem Sie den folgenden Befehl ausführen:

$ kubectl get pods -n istio-system

Jetzt können wir mit dem nächsten Abschnitt fortfahren, in dem wir die Anwendung erstellen und ausführen.

Anwendungsarchitektur für die Stimmungsanalyse

Nehmen wir das Beispiel der Microservice-Anwendung „Sentiment Analysis“, die bereits erwähnt wurde Einführungsartikel zu Kubernetes. Es ist komplex genug, um die Möglichkeiten von Istio in der Praxis aufzuzeigen.

Die Anwendung besteht aus vier Microservices:

1. Service SA-Frontend, das die Front-End-Anwendung auf Reactjs bedient;
2. Service SA-Web-App, das Sentiment-Analyse-Anfragen bedient;
3. Service SA-Logikdas sich selbst durchführt Stimmungsanalyse;
4. Service SA-Feedback, das Feedback von Benutzern zur Genauigkeit der durchgeführten Analyse erhält.

In diesem Diagramm sehen wir neben Services auch den Ingress Controller, der in Kubernetes eingehende Anfragen an die entsprechenden Services weiterleitet. Istio verwendet ein ähnliches Konzept als Teil des Ingress Gateway, Details dazu folgen.

Starten einer Anwendung mit einem Proxy von Istio

Für weitere im Artikel erwähnte Vorgänge klonen Sie Ihr Repository istio-Meisterschaft. Es enthält die Anwendung und Manifeste für Kubernetes und Istio.

Beiwagen einfügen

Einfügung kann vorgenommen werden automatisch oder manuell. Um Sidecar-Container automatisch einzufügen, müssen Sie die Bezeichnung auf den Namespace festlegen istio-injection=enabled, was mit dem folgenden Befehl erledigt wird:

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

Jetzt wird jeder Pod im Standard-Namespace bereitgestellt (default) erhält seinen Sidecar-Container. Um dies zu überprüfen, stellen wir eine Testanwendung bereit, indem wir zum Stammverzeichnis des Repositorys gehen [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

Überprüfen Sie nach der Bereitstellung der Dienste, ob die Pods jeweils über zwei Container verfügen (mit dem Dienst selbst und seinem Sidecar), indem Sie den Befehl ausführen kubectl get pods und stellen Sie sicher, dass unter der Säule READY Wert angegeben 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

Optisch sieht es so aus:

Envoy-Proxy in einem der Pods

Da die Anwendung nun betriebsbereit ist, müssen wir eingehenden Datenverkehr in die Anwendung zulassen.

Ingress-Gateway

Die beste Vorgehensweise, um dies zu erreichen (Datenverkehr im Cluster zulassen), ist durch Ingress-Gateway in Istio, das sich am „Rand“ des Clusters befindet und Ihnen die Aktivierung von Istio-Funktionen wie Routing, Lastausgleich, Sicherheit und Überwachung des eingehenden Datenverkehrs ermöglicht.

Die Ingress-Gateway-Komponente und der Dienst, der sie nach außen weiterleitet, wurden während der Istio-Installation auf dem Cluster installiert. Um die externe IP-Adresse eines Dienstes herauszufinden, 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 weiterhin über diese IP auf die Anwendung zugreifen (ich bezeichne sie als EXTERNAL-IP), daher schreiben wir der Einfachheit halber den Wert in eine 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, über einen Browser auf diese IP zuzugreifen, wird die Fehlermeldung „Dienst nicht verfügbar“ angezeigt, weil Standardmäßig blockiert Istio den gesamten eingehenden Datenverkehrbis Gateway definiert ist.

Gateway-Ressource

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

In unserem Fall möchten wir HTTP-Verkehr auf Port 80 für alle Hosts zulassen. Das Problem wird durch die folgende Definition realisiert (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 bedarf außer dem Selektor keiner Erklärung istio: ingressgateway. Mit diesem Selektor können wir angeben, auf welches Ingress-Gateway die Konfiguration angewendet werden soll. In unserem Fall handelt es sich um den Ingress Gateway Controller, der standardmäßig in Istio installiert wurde.

Die Konfiguration wird durch Aufruf des folgenden Befehls übernommen:

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

Das Gateway erlaubt nun den Zugriff auf Port 80, hat aber keine Ahnung, wohin die Anfragen weitergeleitet werden sollen. Dafür benötigen Sie Virtuelle Dienste.

Virtuelle Dienstressource

Der VirtualService teilt dem Ingress Gateway mit, wie Anfragen 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:

Mit VirtualServices zu konfigurierende Routen

Betrachten Sie die Anfragen, die an SA-Frontend gesendet werden sollten:

• Genaue Übereinstimmung auf dem Weg / sollte an SA-Frontend gesendet werden, um index.html zu erhalten;
• Pfade mit Präfix /static/* sollte an SA-Frontend gesendet werden, um im Frontend verwendete statische Dateien wie CSS und JavaScript abzurufen;
• Pfade, die dem regulären Ausdruck entsprechen '^.*.(ico|png|jpg)$', muss an SA-Frontend gesendet werden, weil 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)

Важные моменты:



 	
 Этот VirtualService относится к запросам, приходящим через http-gateway;


 	
 В destination определяется сервис, куда отправляются запросы.




Примечание: Конфигурация выше хранится в файле sa-virtualservice-external.yaml, который также содержит настройки для маршрутизации в SA-WebApp и SA-Feedback, но был сокращён здесь в статье для лаконичности.

Применим VirtualService вызовом:

$ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml
virtualservice.networking.istio.io/sa-external-services created
Примечание: Когда мы применяем ресурсы Istio, Kubernetes API Server создаёт событие, которое получает Istio Control Plane, и уже после этого новая конфигурация применяется к прокси-серверам Envoy каждого pod'а. А контроллер Ingress Gateway представляется очередным Envoy, сконфигурированным в Control Plane. Всё это на схеме выглядит так:


Конфигурация Istio-IngressGateway для маршрутизации запросов
Приложение Sentiment Analysis стало доступным по http://{EXTERNAL-IP}/. Не переживайте, если вы получаете статус Not Found: иногда требуется чуть больше времени для того, чтобы конфигурация вступила в силу и кэши Envoy обновились.
Перед тем, как продолжить, поработайте немного с приложением, чтобы сгенерировать трафик (его наличие необходимо для наглядности в последующих действиях — прим. перев.).
Kiali : наблюдаемость
Чтобы попасть в административный интерфейс Kiali, выполните следующую команду:
$ kubectl port-forward 
    $(kubectl get pod -n istio-system -l app=kiali 
    -o jsonpath='{.items[0].metadata.name}') 
    -n istio-system 20001
… и откройте http://localhost:20001/, залогинившись под admin/admin. Здесь вы найдете множество полезных возможностей, например, для проверки конфигурации компонентов Istio, визуализации сервисов по информации, собранной при перехвате сетевых запросов, получения ответов на вопросы «Кто к кому обращается?», «У какой версии сервиса возникают сбои?» и т.п. В общем, изучите возможности Kiali перед тем, как двигаться дальше — к визуализации метрик с Grafana.

Grafana: визуализация метрик
Собранные в Istio метрики попадают в Prometheus и визуализируются с Grafana. Чтобы попасть в административный интерфейс Grafana, выполните команду ниже, после чего откройте 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
Кликнув на меню Home слева сверху и выбрав Istio Service Dashboard в левом верхнем углу, начните с сервиса sa-web-app, чтобы посмотреть на собранные метрики:

Здесь нас ждёт пустое и совершенно скучное представление — руководство никогда такое не одобрит. Давайте же создадим небольшую нагрузку следующей командой:
$ while true; do 
    curl -i http://$EXTERNAL_IP/sentiment 
    -H "Content-type: application/json" 
    -d '{"sentence": "I love yogobella"}'; 
    sleep .8; done
Вот теперь у нас гораздо более симпатичные графики, а в дополнение к ним — замечательные инструменты Prometheus для мониторинга и Grafana для визуализации метрик, что позволят нам узнать о производительности, состоянии здоровья, улучшениях/деградации в работе сервисов на протяжении времени.
Наконец, посмотрим на трассировку запросов в сервисах.
Jaeger : трассировка
Трассировка нам потребуется, потому что чем больше у нас сервисов, тем сложнее добраться до причины сбоя. Посмотрим на простой случай из картинки ниже:


Типовой пример случайного неудачного запроса
Запрос приходит, падает — в чём же причина? Первый сервис? Или второй? Исключения есть в обоих — давайте посмотрим на логи каждого. Как часто вы ловили себя за таким занятием? Наша работа больше похожа на детективов программного обеспечения, а не разработчиков…
Это широко распространённая проблема в микросервисах и решается она распределёнными системами трассировки, в которых сервисы передают друг другу уникальный заголовок, после чего эта информация перенаправляется в систему трассировки, где она сопоставляется с данными запроса. Вот иллюстрация:


Для идентификации запроса используется TraceId
В Istio используется Jaeger Tracer, который реализует независимый от вендоров фреймворк OpenTracing API. Получить доступ к пользовательского интерфейсу Jaeger можно следующей командой:
$ kubectl port-forward -n istio-system 
    $(kubectl get pod -n istio-system -l app=jaeger 
    -o jsonpath='{.items[0].metadata.name}') 16686
Теперь зайдите на http://localhost:16686/ и выберите сервис sa-web-app. Если сервис не показан в выпадающем меню — проявите/сгенерируйте активность на странице и обновите интерфейс. После этого нажмите на кнопку Find Traces, которая покажет самые последние трейсы — выберите любой — покажется детализированная информация по всем трейсам:

Этот трейс показывает:

 Запрос приходит в istio-ingressgateway (это первое взаимодействие с одним из сервисов, и для запроса генерируется Trace ID), после чего шлюз направляет запрос в сервис sa-web-app.
 В сервисе sa-web-app запрос подхватывается Envoy sidecar'ом, создаётся «ребёнок» в span'е (поэтому мы видим его в трейсах) и перенаправляется в контейнер sa-web-app. (Span — логическая единица работы в Jaeger, имеющая название, время начало операции и её продолжительность. Span'ы могут быть вложенными и упорядоченными. Ориентированный ациклический граф из span'ов образует trace. — прим. перев.)
 Здесь запрос обрабатывается методом sentimentAnalysis. Эти трейсы уже сгенерированы приложением, т.е. для них потребовались изменения в коде.
 С этого момента инициируется POST-запрос в sa-logic. Trace ID должен быть проброшен из sa-web-app.
 …

Примечание: На 4 шаге приложение должно увидеть заголовки, сгенерированные Istio, и передать их в последующие запросы, как показано на изображении ниже:


(A) За проброс заголовков отвечает Istio; (B) За заголовки отвечают сервисы
Istio делает основную работу, т.к. генерирует заголовки для входящих запросов, создаёт новые span'ы в каждом sidecare'е и пробрасывает их. Однако без работы с заголовками внутри сервисов полный путь трассировки запроса будет утерян.
Необходимо учитывать (пробрасывать) следующие заголовки:
x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
x-ot-span-context
Это несложная задача, однако для упрощения её реализации уже существует множество библиотек — например, в сервисе sa-web-app клиент RestTemplate пробрасывает эти заголовки, если просто добавить библиотеки Jaeger и OpenTracing в его зависимости.
Заметьте, что приложение Sentiment Analysis демонстрирует реализации на Flask, Spring и ASP.NET Core.
Теперь, когда стало ясно, что мы получаем из коробки (или почти «из коробки»), рассмотрим вопросы тонко настраиваемой маршрутизации, управления сетевым трафиком, безопасности и т.п.!
Прим. перев.: об этом читайте в следующей части материалов по Istio от Rinor Maloku, переводы которых последуют в нашем блоге в ближайшее время. UPDATE (14 марта): Вторая часть уже опубликована.
P.S. от переводчика
Читайте также в нашем блоге:

 «Назад к микросервисам вместе с Istio»: часть 2 (маршрутизация, управление трафиком), часть 3 (аутентификация и авторизация);
 «Conduit — легковесный service mesh для Kubernetes»;
 «Что такое service mesh и почему он мне нужен [для облачного приложения с микросервисами]?»;
 «Иллюстрированное руководство по устройству сети в Kubernetes. Части 1 и 2»;
 «Как этот sidecar-контейнер оказался здесь [в Kubernetes]?».

Источник: habr.com
route:

- destination:

host: sa-frontend             # 2

port:

number: 80

Wichtige Punkte:

 Dieser VirtualService bezieht sich auf eingehende Anfragen http-Gateway;
 В destination Definiert den Dienst, an den die Anfragen gesendet werden.

Beachten: Die obige Konfiguration wird in einer Datei gespeichert sa-virtualservice-external.yaml, die auch Einstellungen für das Routing an SA-WebApp und SA-Feedback enthält, hier im Artikel jedoch der Kürze halber gekürzt wurde.
Wenden Sie VirtualService an, indem Sie Folgendes aufrufen:

Beachten: Wenn wir Istio-Ressourcen anwenden, löst der Kubernetes-API-Server ein Ereignis aus, das die Istio-Steuerungsebene empfängt, und danach wird die neue Konfiguration auf die Envoy-Proxys jedes Pods angewendet. Und der Ingress-Gateway-Controller scheint ein weiterer Envoy zu sein, der in der Steuerungsebene konfiguriert ist. Im Diagramm sieht das alles so aus:


Istio-IngressGateway-Konfiguration für das Anforderungsrouting
Die Stimmungsanalyse ist jetzt verfügbar auf http://{EXTERNAL-IP}/. 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, spielen Sie ein wenig mit der Anwendung, um Traffic zu generieren. (Seine Anwesenheit ist für die Klarheit nachfolgender Aktionen erforderlich - ca. übersetzt.).
Kiali: Beobachtbarkeit
Um zur Kiali-Administratoroberfläche zu gelangen, führen Sie den folgenden Befehl aus:

…und öffnen http://localhost:20001/indem Sie sich als Admin/Administrator anmelden. Hier finden Sie viele nützliche Funktionen, um beispielsweise die Konfiguration von Istio-Komponenten zu überprüfen, Dienste anhand der durch das Abfangen von Netzwerkanfragen gesammelten Informationen zu visualisieren und Antworten auf die Fragen „Wer kontaktiert wen?“ und „Welche Version des Dienstes wird ausgeführt?“ zu erhalten Misserfolge?“ usw. Erkunden Sie im Allgemeinen die Möglichkeiten von Kiali, bevor Sie mit der Visualisierung von Metriken mit Grafana fortfahren.

Grafana: Visualisierung von Metriken
Die in Istio gesammelten Metriken landen in Prometheus und werden mit Grafana visualisiert. Um zur Grafana-Administratoroberfläche zu gelangen, führen Sie den folgenden Befehl aus und öffnen Sie ihn http://localhost:3000/:

Durch Klicken auf das Menü Startseite oben links und wählen Sie Istio-Service-Dashboard Beginnen Sie in der oberen linken Ecke mit „Service“. sa-web-appSo zeigen Sie die gesammelten Messwerte an:

Hier erwartet uns ein leerer und völlig langweiliger Auftritt – das wird das Management niemals gutheißen. Erstellen wir eine kleine Last mit dem folgenden Befehl:

Jetzt haben wir viel schönere Diagramme und zusätzlich die wunderbaren Tools Prometheus zur Überwachung und Grafana zur Visualisierung von Metriken, die es uns ermöglichen, mehr über Leistung, Gesundheitszustand und Verbesserungen/Verschlechterungen der Dienste im Laufe der Zeit zu erfahren.
Schauen wir uns abschließend die Anforderungsverfolgung in Diensten an.
Jaeger: Aufspüren
Wir werden eine Rückverfolgung benötigen, denn je mehr Dienste wir haben, desto schwieriger ist es, die Ursache des Fehlers zu ermitteln. Schauen wir uns einen einfachen Fall aus dem Bild unten an:


Typisches Beispiel für eine zufällig fehlgeschlagene Anfrage
Bitte kommt, fällt – was ist der Grund? Erster Service? Oder zweitens? In beiden Fällen gibt es Ausnahmen – schauen wir uns die Protokolle der einzelnen Protokolle an. Wie oft haben Sie sich dabei ertappt? Unser Job ähnelt eher einem Software-Detektiv als einem Entwickler …
Dies ist ein weit verbreitetes Problem bei Microservices und wird durch verteilte Tracing-Systeme gelöst, bei denen Dienste einander einen eindeutigen Header übergeben, wonach diese Informationen an das Tracing-System weitergeleitet werden, wo sie mit den Anforderungsdaten verglichen werden. Hier ist eine Illustration:


TraceId wird zur Identifizierung der Anfrage verwendet
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:

Gehen Sie jetzt zu http://localhost:16686/ und wählen Sie einen Dienst aus sa-web-app. 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 finden, das die neuesten Spuren anzeigt – wählen Sie eine beliebige aus – detaillierte Informationen zu allen Spuren werden angezeigt:

Diese Spur zeigt:

 Die Anfrage geht ein istio-ingressgateway (Dies ist die erste Interaktion mit einem der Dienste und es wird eine Trace-ID für die Anfrage generiert.) Anschließend sendet das Gateway die Anfrage an den Dienst sa-web-app.
 Im Dienst sa-web-app Die Anfrage wird vom Envoy-Sidecar aufgenommen, im Span wird ein „Kind“ erstellt (deshalb sehen wir es in Spuren) und an den Container weitergeleitet sa-web-app. (Spannweite - eine logische Arbeitseinheit in Jaeger mit einem Namen, der Startzeit des Vorgangs und seiner Dauer. Spannen können verschachtelt und geordnet werden. Ein gerichteter azyklischer Graph von Spannen bildet eine Spur. - ca. übersetzt)
 Hier wird die Anfrage von der Methode verarbeitet Stimmungsanalyse. Diese Traces werden bereits von der Anwendung generiert, d.h. Sie erforderten Codeänderungen.
 Von diesem Moment an wird eine POST-Anfrage initiiert sa-Logik. Die Trace-ID muss weitergeleitet werden sa-web-app.
 ...

Beachten: In Schritt 4 sollte die Anwendung die von Istio generierten Header sehen und sie an nachfolgende Anfragen weitergeben, wie im Bild unten gezeigt:


(A) Die Header-Weiterleitung liegt in der Verantwortung von Istio. (B) Dienste sind für Header verantwortlich
Istio erledigt den Großteil der Arbeit, weil generiert Header für eingehende Anfragen, erstellt neue Spans in jedem Sidecare und leitet diese weiter. Ohne die Arbeit mit Headern innerhalb von Diensten geht jedoch der vollständige Anforderungsverfolgungspfad verloren.
Folgende Header müssen berücksichtigt (weitergeleitet) werden:

Dies ist eine einfache Aufgabe, aber um die Implementierung zu vereinfachen, gibt es bereits eine viele Bibliotheken – Im sa-web-app-Dienst leitet der RestTemplate-Client diese Header beispielsweise weiter, wenn Sie einfach die Jaeger- und OpenTracing-Bibliotheken hinzufügen seine Abhängigkeiten.
Beachten Sie, dass die Sentiment Analysis-Anwendung Implementierungen in Flask, Spring und ASP.NET Core demonstriert.
Nachdem nun klar ist, was wir sofort (oder fast sofort) bekommen, werfen wir einen Blick auf die Feinabstimmung von Routing, Netzwerkverkehrsmanagement, Sicherheit und mehr!
Notiz. übersetzen: Lesen Sie darüber im nächsten Teil der Materialien zu Istio von Rinor Maloku, deren Übersetzungen in naher Zukunft auf unserem Blog folgen werden. AKTUALISIEREN (14. März): Der zweite Teil bereits veröffentlicht.
PS vom Übersetzer
Lesen Sie auch auf unserem Blog:

 „Zurück zu Microservices mit Istio“: Teil 2 (Routenführung, Verkehrssteuerung), Teil 3 (Authentifizierung und Autorisierung);
 «Conduit – leichtes Service-Mesh für Kubernetes";
 «Was ist ein Service Mesh und warum benötige ich es [für eine Cloud-Anwendung mit Microservices]?";
 «Eine illustrierte Anleitung zum Networking in Kubernetes. Teile 1 und 2";
 «Wie ist dieser Sidecar-Container hier [in Kubernetes] gelandet?".

Source: habr.com