Retour aux microservices avec Istio. Partie 1

Noter. trad.: Les maillages de services sont définitivement devenus un sujet brûlant dans l'infrastructure d'aujourd'hui pour les applications suivant une architecture de microservices. Bien qu'Istio soit sur le radar de nombreux ingénieurs DevOps, il s'agit d'un produit relativement nouveau qui, bien que complexe en termes de fonctionnalités qu'il offre, peut prendre beaucoup de temps à se familiariser. L'ingénieur allemand Rinor Maloku, responsable du cloud computing pour les grands clients de la société de télécommunications Orange Networks, a écrit une merveilleuse série de documents qui vous permettent de plonger rapidement et profondément dans Istio. Il commence son histoire par ce qu'Istio peut faire et comment vous pouvez le voir rapidement de vos propres yeux.

Istio — Projet Open Source, développé en collaboration avec des équipes de Google, IBM et Lyft. Il résout les complexités qui surviennent dans les applications basées sur des microservices, par exemple, telles que :

• gestion du trafic: timeouts, retries, load balancing ;
• sécurité: authentification et autorisation de l'utilisateur final ;
• observabilité: traçage, surveillance, journalisation.

Tous peuvent être résolus au niveau de l'application, mais après cela, vos services ne seront plus "micro". Tous les efforts supplémentaires pour résoudre ces problèmes sont un gaspillage des ressources de l'entreprise qui pourraient être utilisées directement pour la valeur commerciale. Prenons un exemple :

Chef de projet : Combien de temps faut-il pour ajouter une fonctionnalité de commentaires ?
Développeur : Deux sprints.

MP : Quoi ?.. C'est juste CRUD !
R : Faire du CRUD est la partie la plus facile de la tâche, mais nous devons toujours authentifier et autoriser les utilisateurs et les services. Le réseau n'étant pas fiable, vous devrez implémenter des requêtes répétées, ainsi que modèle de disjoncteur chez les clientes. De plus, pour s'assurer que l'ensemble du système n'a pas planté, les délais d'attente et cloisons (Voir plus loin dans l'article pour plus de détails sur les deux modèles mentionnés.), et afin de détecter les problèmes, la surveillance, le traçage, […]

MP : Oh, intégrons cette fonctionnalité dans le service produit alors.

Je pense que l'idée est claire : la quantité d'étapes et d'efforts nécessaires pour ajouter un seul service est énorme. Dans cet article, nous verrons comment Istio supprime toute la complexité mentionnée ci-dessus (non ciblée par la logique métier) des services.

Noter : L'article suppose que vous avez une connaissance pratique de Kubernetes. Sinon, je recommande la lecture mon introduction à Kubernetes et seulement ensuite continuer à lire ce matériel.

Istio idée

Dans un monde sans Istio, un service fait des requêtes directes à un autre, et en cas d'échec, le service doit s'en charger lui-même : refaire une tentative, prévoir un timeout, ouvrir un disjoncteur, etc.

Trafic réseau dans Kubernetes

Istio, quant à lui, propose une solution spécialisée complètement séparée des services et des fonctions en interférant avec l'interaction réseau. Et ainsi il implémente :

• tolérance aux pannes : en fonction du code d'état dans la réponse, il comprend si la demande a échoué et la soumet à nouveau.
• Déploiements canaris: redirige uniquement un pourcentage fixe de requêtes vers la nouvelle version du service.
• Surveillance et métriques: combien de temps a-t-il fallu au service pour répondre ?
• Traçage et observabilité: ajoute des en-têtes spéciaux à chaque demande et les trace dans le cluster.
• sécurité: récupère un jeton JWT, authentifie et autorise les utilisateurs.

Ce ne sont là que quelques-unes des possibilités (vraiment quelques-unes !) de vous intriguer. Plongeons maintenant dans les détails techniques !

Architecture

Istio intercepte tout le trafic réseau et lui applique un ensemble de règles, en insérant un proxy intelligent sous la forme d'un conteneur sidecar dans chaque pod. Les procurations qui activent toutes les possibilités forment un Plan de données, et ils peuvent être ajustés dynamiquement avec Avion de contrôle.

Plan de données

Les proxys insérés dans les pods permettent à Istio de répondre facilement aux exigences dont nous avons besoin. Par exemple, vérifions les nouvelles tentatives et les fonctions du disjoncteur.

Comment les nouvelles tentatives et les coupures de circuit sont mises en œuvre dans Envoy

Pour résumer:

1. Envoyé (nous parlons d'un proxy situé dans un conteneur sidecar, qui est distribué et comment produit séparé - environ. trad.) envoie une requête à la première instance du service B et échoue.
2. Envoy Sidecar essaie à nouveau (recommencez). (1)
3. La requête ayant échoué est renvoyée au proxy qui l'a appelée.
4. Cela ouvre le disjoncteur et appelle le service suivant pour les demandes ultérieures. (2)

Cela signifie que vous n'avez pas besoin d'utiliser la prochaine bibliothèque Retry, vous n'avez pas besoin de créer votre propre implémentation de Circuit Breaking and Service Discovery dans le langage de programmation X, Y ou Z. Tout cela et plus encore est disponible sur le box dans Istio et ne nécessite pas aucun changements de codes.

Super! Maintenant, vous voudrez peut-être partir en voyage avec Istio, mais il y a encore des doutes, des questions ouvertes. S'il s'agit d'une solution universelle pour toutes les occasions de la vie, alors vous avez un soupçon légitime : après tout, toutes ces solutions ne conviennent en fait à aucun cas.

Et enfin vous demandez : "Est-ce personnalisable ?"

Vous êtes maintenant prêt pour un voyage en mer - et familiarisons-nous avec Control Plane.

Avion de contrôle

Il se compose de trois composants : Pilote, Mixer и Citadelle, qui configurent ensemble Envoys pour acheminer le trafic, appliquer des politiques et collecter des données de télémétrie. Schématiquement, tout ressemble à ceci :

Interaction du plan de contrôle avec le plan de données

Les émissaires (c'est-à-dire le plan de données) sont configurés avec CRD Kubernetes (Définitions de ressources personnalisées) définies par Istio et spécifiquement conçues à cet effet. Cela signifie pour vous qu'ils ne sont qu'une autre ressource dans Kubernetes avec une syntaxe familière. Une fois créée, cette ressource sera récupérée par le plan de contrôle et appliquée aux émissaires.

Relation des services avec Istio

Nous avons décrit la relation d'Istio aux services, mais pas l'inverse : comment les services sont-ils liés à Istio ?

Pour être honnête, les services connaissent la présence d'Istio aussi bien que les poissons connaissent l'eau, lorsqu'ils se demandent : "Qu'est-ce que l'eau de toute façon ?".

Illustration Victoria Dimitrakopoulos: Comment aimez-vous l'eau? - Qu'est-ce que l'eau de toute façon?

Ainsi, vous pouvez prendre un cluster fonctionnel et après avoir déployé les composants Istio, les services qu'il contient continueront de fonctionner, et après la suppression de ces composants, tout ira bien à nouveau. Il est clair que dans ce cas vous perdrez les opportunités offertes par Istio.

Assez de théorie - mettons ces connaissances en pratique !

Istio en pratique

Istio nécessite un cluster Kubernetes avec au moins 4 processeurs virtuels et 8 Go de RAM disponibles. Pour monter rapidement le cluster et suivre les instructions de l'article, je recommande d'utiliser Google Cloud Platform, qui propose aux nouveaux utilisateurs gratuit 300 $.

Après avoir créé le cluster et configuré l'accès à Kubernetes via l'utilitaire de console, vous pouvez installer Istio via le gestionnaire de packages Helm.

Installation de la barre

Installez le client Helm sur votre ordinateur comme décrit dans documents officiels. Nous l'utiliserons pour générer des modèles pour l'installation d'Istio dans la section suivante.

Installation

Téléchargez les ressources Istio à partir de dernière version (le lien de l'auteur original vers la version 1.0.5 a été remplacé par le lien actuel, c'est-à-dire 1.0.6 - traduction approximative), extrayez le contenu dans un seul répertoire, que j'appellerai [istio-resources].

Pour identifier facilement les ressources Istio, créez un espace de noms dans le cluster K8s istio-system:

$ kubectl create namespace istio-system

Terminez l'installation en accédant au répertoire [istio-resources] et en exécutant la commande :

$ 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

Cette commande affichera les composants clés d'Istio dans un fichier istio.yaml. Nous avons modifié le modèle standard pour nous-mêmes en spécifiant les paramètres suivants :

• global.mtls.enabled installé dans false (c'est-à-dire que l'authentification mTLS est désactivée - traduction approximative)pour simplifier notre processus de rencontres ;
• tracing.enabled permet le suivi des demandes avec Jaeger ;
• kiali.enabled installe Kiali dans un cluster pour visualiser les services et le trafic ;
• grafana.enabled installe Grafana pour visualiser les métriques collectées.

Appliquez les ressources générées avec la commande :

$ kubectl apply -f istio.yaml

L'installation d'Istio dans le cluster est terminée ! Attendez que tous les pods de l'espace de noms istio-system sera capable Running ou Completeden exécutant la commande ci-dessous :

$ kubectl get pods -n istio-system

Nous sommes maintenant prêts à passer à la section suivante, où nous allons lancer et exécuter l'application.

Architecture d'application d'analyse des sentiments

Prenons l'exemple de l'application de microservice Sentiment Analysis utilisée dans le déjà mentionné Article d'introduction à Kubernetes. Il est suffisamment complexe pour montrer les possibilités d'Istio en pratique.

L'application se compose de quatre microservices :

1. Service SA-Frontend, qui sert l'application frontale sur Reactjs ;
2. Service Application Web SA, qui sert les requêtes d'analyse des sentiments ;
3. Service Logique SAqui s'exécute analyse des sentiments;
4. Service Commentaires SA, qui reçoit les commentaires des utilisateurs sur la précision de l'analyse effectuée.

Dans ce diagramme, en plus des services, nous voyons également le contrôleur d'entrée, qui dans Kubernetes achemine les demandes entrantes vers les services correspondants. Istio utilise un concept similaire dans le cadre de la passerelle d'entrée, dont les détails suivront.

Lancer une application avec un proxy depuis Istio

Pour d'autres opérations mentionnées dans l'article, clonez votre dépôt istio-maîtrise. Il contient l'application et les manifestes pour Kubernetes et Istio.

Insertion de side-cars

L'insertion peut se faire automatiquement ou manuellement. Pour insérer automatiquement des conteneurs side-car, vous devez définir l'étiquette sur l'espace de noms istio-injection=enabled, ce qui est fait par la commande suivante :

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

Désormais, chaque pod qui sera déployé dans l'espace de noms par défaut (default) recevra son conteneur side-car. Pour vérifier cela, déployons une application de test en allant dans le répertoire racine du référentiel [istio-mastery] et en exécutant la commande suivante :

$ 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

Après avoir déployé les services, vérifiez que les pods ont chacun deux conteneurs (avec le service lui-même et son sidecar) en exécutant la commande kubectl get pods et en s'assurant que sous la colonne READY valeur spécifiée 2/2, symbolisant que les deux conteneurs sont en cours d'exécution :

$ 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

Visuellement ça ressemble à ça :

Proxy Envoy dans l'un des pods

Maintenant que l'application est opérationnelle, nous devons autoriser le trafic entrant à entrer dans l'application.

Passerelle d'entrée

La meilleure pratique pour y parvenir (autoriser le trafic dans le cluster) est via Passerelle d'entrée dans Istio, qui est situé à la « périphérie » du cluster et vous permet d'activer les fonctionnalités d'Istio telles que le routage, l'équilibrage de charge, la sécurité et la surveillance du trafic entrant.

Le composant Ingress Gateway et le service qui le transmet vers l'extérieur ont été installés sur le cluster lors de l'installation d'Istio. Pour connaître l'adresse IP externe d'un service, exécutez :

$ 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

Nous continuerons à accéder à l'application en utilisant cette IP (je l'appellerai EXTERNAL-IP), donc pour plus de commodité, nous écrirons la valeur dans une variable :

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

Si vous essayez d'accéder à cette IP via un navigateur maintenant, vous obtiendrez une erreur Service non disponible, car par défaut Istio bloque tout le trafic entrantjusqu'à ce que la passerelle soit définie.

Ressource de passerelle

La passerelle est un CRD (Custom Resource Definition) dans Kubernetes, défini après l'installation d'Istio dans un cluster et permettant de spécifier les ports, le protocole et les hôtes pour lesquels nous voulons autoriser le trafic entrant.

Dans notre cas, nous voulons autoriser le trafic HTTP sur le port 80 pour tous les hôtes. Le problème est réalisé par la définition suivante (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:
- "*"

Cette configuration ne nécessite aucune explication sauf pour le sélecteur istio: ingressgateway. Avec ce sélecteur, nous pouvons spécifier à quelle passerelle d'entrée appliquer la configuration. Dans notre cas, il s'agit du contrôleur Ingress Gateway, qui a été installé par défaut dans Istio.

La configuration est appliquée en appelant la commande suivante :

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

La passerelle autorise désormais l'accès au port 80 mais n'a aucune idée de l'endroit où acheminer les requêtes. Pour cela, vous aurez besoin Services virtuels.

Ressource de service virtuel

Le VirtualService indique à la passerelle d'entrée comment acheminer les demandes autorisées dans le cluster.

Les demandes adressées à notre application via la passerelle http doivent être envoyées aux services sa-frontend, sa-web-app et sa-feedback :

Routes à configurer avec VirtualServices

Considérez les requêtes qui doivent être envoyées à SA-Frontend :

• Correspondance exacte en cours de route / doit être envoyé à SA-Frontend pour obtenir index.html ;
• Chemins avec un préfixe /static/* doit être envoyé à SA-Frontend pour obtenir les fichiers statiques utilisés dans le frontend, tels que CSS et JavaScript ;
• Chemins correspondant à l'expression régulière '^.*.(ico|png|jpg)$', doit être envoyé à SA-Frontend, car Ce sont les images affichées sur la page.

La mise en œuvre est réalisée par la configuration suivante (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

Points importants:

 Ce service virtuel fait référence aux demandes provenant de passerelle http;
 В destination définit le service auquel les requêtes sont envoyées.

Noter: La configuration ci-dessus est stockée dans un fichier sa-virtualservice-external.yaml, qui contient également des paramètres de routage vers SA-WebApp et SA-Feedback, mais a été raccourci ici dans l'article par souci de concision.
Appliquez VirtualService en appelant :

Noter : Lorsque nous appliquons des ressources Istio, le serveur d'API Kubernetes déclenche un événement que le plan de contrôle Istio reçoit, puis la nouvelle configuration est appliquée aux proxys Envoy de chaque pod. Et le contrôleur de passerelle d'entrée semble être un autre Envoy configuré dans le plan de contrôle. Tout cela ressemble à ceci sur le schéma :


Configuration Istio-IngressGateway pour le routage des requêtes
L'analyse des sentiments est maintenant disponible sur http://{EXTERNAL-IP}/. Ne vous inquiétez pas si vous obtenez le statut Introuvable : il faut parfois un peu plus de temps pour que la configuration prenne effet et que les caches Envoy se mettent à jour.
Avant de continuer, jouez un peu avec l'application pour générer du trafic. (sa présence est nécessaire pour la clarté des actions ultérieures - env. trad.).
Kiali : observabilité
Pour accéder à l'interface d'administration de Kiali, exécutez la commande suivante :

…et ouvrir http://localhost:20001/en vous connectant en tant qu'admin/admin. Vous y trouverez de nombreuses fonctionnalités utiles, par exemple pour vérifier la configuration des composants Istio, visualiser les services à partir des informations collectées en interceptant les requêtes réseau, obtenir des réponses aux questions "Qui contacte qui ?", "Quelle version du service rencontre les échecs?" et ainsi de suite. De manière générale, explorez les possibilités de Kiali avant de passer à la visualisation des métriques avec Grafana.

Grafana : visualisation des métriques
Les métriques collectées dans Istio se retrouvent dans Prometheus et sont visualisées avec Grafana. Pour accéder à l'interface d'administration de Grafana, exécutez la commande ci-dessous, puis ouvrez http://localhost:3000/:

En cliquant sur le menu Accueil en haut à gauche et sélectionnez Tableau de bord des services Istio dans le coin supérieur gauche, commencez par le service sa-web-apppour afficher les métriques collectées :

Ici, nous attendons une performance vide et complètement ennuyeuse - la direction ne l'approuvera jamais. Créons une petite charge avec la commande suivante :

Nous avons maintenant des graphiques beaucoup plus jolis, et en plus d'eux, les merveilleux outils Prometheus pour la surveillance et Grafana pour la visualisation des métriques, qui nous permettront d'en savoir plus sur les performances, l'état de santé, les améliorations/dégradations des services au fil du temps.
Enfin, examinons le suivi des demandes dans les services.
Jaeger : traçage
Nous aurons besoin de traçage, car plus nous avons de services, plus il est difficile de trouver la cause de la panne. Regardons un cas simple à partir de l'image ci-dessous :


Exemple typique d'une requête aléatoire ayant échoué
La demande vient, tombe - quelle est la raison? Premier entretien ? Ou deuxième ? Il y a des exceptions dans les deux - regardons les journaux de chacun. Combien de fois vous êtes-vous surpris à faire cela ? Notre travail ressemble plus à des détectives de logiciels qu’à des développeurs…
Il s'agit d'un problème répandu dans les microservices et est résolu par les systèmes de traçage distribués, dans lesquels les services se transmettent un en-tête unique, après quoi ces informations sont redirigées vers le système de traçage, où elles sont comparées aux données de la demande. Voici une illustration :


TraceId est utilisé pour identifier la demande
Istio utilise Jaeger Tracer, qui implémente un framework d'API OpenTracing indépendant du fournisseur. Vous pouvez accéder à l'interface utilisateur Jaeger avec la commande suivante :

Allez maintenant à http://localhost:16686/ et sélectionnez une prestation sa-web-app. Si le service n'est pas affiché dans le menu déroulant, affichez/générez l'activité sur la page et mettez à jour l'interface. Après cela, cliquez sur le bouton Trouver des traces, qui affichera les traces les plus récentes - sélectionnez-en une - des informations détaillées sur toutes les traces apparaîtront :

Cette trace montre :

 La demande arrive istio-passerelle d'entrée (il s'agit de la première interaction avec l'un des services, et un ID de suivi est généré pour la demande), après quoi la passerelle envoie la demande au service sa-web-app.
 En service sa-web-app la requête est récupérée par le sidecar Envoy, un "enfant" est créé dans le span (c'est pourquoi on le voit dans les traces) et redirigé vers le conteneur sa-web-app. (Envergure - une unité logique de travail en Jaeger, ayant un nom, l'heure de début de l'opération et sa durée. Les étendues peuvent être imbriquées et ordonnées. Un graphe acyclique orienté de portées forme une trace. - environ. trad.)
 Ici la requête est traitée par la méthode analyse des sentiments. Ces traces sont déjà générées par l'application, c'est-à-dire ils ont exigé des changements de code.
 A partir de ce moment, une requête POST est initiée dans sa-logique. L'ID de suivi doit être transmis à partir de sa-web-app.
 ...

Noter : à l'étape 4, l'application doit voir les en-têtes générés par Istio et les transmettre aux requêtes suivantes, comme illustré dans l'image ci-dessous :


(A) Le transfert d'en-tête relève de la responsabilité d'Istio ; (B) Les services sont responsables des en-têtes
Istio fait le gros du travail car génère des en-têtes pour les requêtes entrantes, crée de nouvelles étendues dans chaque sidecare et les transmet. Cependant, sans travailler avec les en-têtes à l'intérieur des services, le chemin de trace complet de la demande sera perdu.
Les en-têtes suivants doivent être pris en compte (transmis) :

C'est une tâche simple, mais pour simplifier sa mise en œuvre, il existe déjà de nombreuses bibliothèques - par exemple, dans le service sa-web-app, le client RestTemplate transmet ces en-têtes si vous ajoutez simplement les bibliothèques Jaeger et OpenTracing à ses dépendances.
Notez que l'application Sentiment Analysis présente des implémentations dans Flask, Spring et ASP.NET Core.
Maintenant qu'il est clair ce que nous obtenons de la boîte (ou presque de la boîte), regardons le réglage fin du routage, la gestion du trafic réseau, la sécurité, et plus encore !
Noter. trad.: lire à ce sujet dans la prochaine partie des matériaux sur Istio par Rinor Maloku, dont les traductions suivront sur notre blog dans un proche avenir. MISE À JOUR (14 mars): La deuxième partie déjà publié.
PS du traducteur
A lire aussi sur notre blog :

 "Retour aux microservices avec Istio" : partie 2 (routage, contrôle du trafic), partie 3 (authentification et autorisation);
 «Conduit - maillage de service léger pour Kubernetes";
 «Qu'est-ce qu'un maillage de services et pourquoi en ai-je besoin [pour une application cloud avec des microservices] ?";
 «Un guide illustré de la mise en réseau dans Kubernetes. Parties 1 et 2";
 «Comment ce conteneur side-car s'est-il retrouvé ici [dans Kubernetes] ?».

Source: habr.com