🥇Retour aux microservices avec Istio. Partie 1

Note de traduction.: Les services mesh sont devenus une solution pertinente dans les infrastructures modernes pour les applications suivant une architecture de microservices. Bien qu'Istio soit déjà familier à de nombreux ingénieurs DevOps, c'est un produit relativement nouveau qui, en raison de la complexité des fonctionnalités proposées, peut nécessiter un temps d'apprentissage considérable. Rinor Maloku, un ingénieur allemand responsable des solutions cloud pour de grands clients chez l'opérateur télécom Orange Networks, a écrit un remarquable cycle de matériaux permettant d'explorer Istio de manière rapide et approfondie. Il commence par décrire ce qu'Istio peut faire et comment y jeter un œil rapidement.

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

Gestion du trafic: timeouts, tentatives de répétition, répartition de la charge;
Sécurité: authentification et autorisation des utilisateurs finaux;
Observabilité: traçage, surveillance, journalisation.

Tous ces problèmes peuvent être résolus au niveau des applications, mais après cela, vos services cesseront d'être « micro ». Tous les efforts supplémentaires pour résoudre ces problèmes représentent un coût en ressources pour l'entreprise, qui pourrait être utilisé directement pour des valeurs commerciales. Prenons un exemple :

Chef de projet : Combien de temps pour ajouter la fonctionnalité de retour d'informations ?
Développeur : Deux sprints.
Chef de projet : Quoi ?.. C'est juste du CRUD !
Développeur : Faire le CRUD est la partie simple de la tâche, mais nous devons également authentifier et autoriser les utilisateurs et les services. Étant donné que le réseau est peu fiable, il sera nécessaire d'implémenter des requêtes répétées, ainsi que le modèle du circuit breaker dans les clients. De plus, pour s'assurer que l'ensemble du système ne tombe pas, des timeouts et des bulkheads (voir plus sur les deux modèles mentionnés plus loin dans l'article — note de traduction.), et pour détecter les problèmes, il faudra de la surveillance, du traçage, […]
Chef de projet : Oh, insérons simplement cette fonctionnalité dans le service Product.

Je pense que l'idée est claire : le volume d'étapes et d'efforts nécessaires pour ajouter un service est énorme. Dans cet article, nous examinerons comment Istio élimine toutes les complexités mentionnées ci-dessus (qui ne relèvent pas de la logique métier) des services.

Remarque: L'article suppose que vous avez des connaissances pratiques sur Kubernetes. Sinon, je vous recommande de lire mon introduction à Kubernetes et seulement après cela de continuer la lecture de ce matériel.

L'idée d'Istio

Dans un monde sans Istio, un service fait des requêtes directes à un autre, et en cas d'échec, le service doit le gérer lui-même : réessayer, prévoir un délai d'attente, ouvrir un circuit breaker, etc.

Le trafic réseau dans Kubernetes

Istio propose une solution spécialisée, entièrement dissociée des services et fonctionnant par intervention dans les interactions réseau. Ainsi, il met en œuvre :

Résilience: en s'appuyant sur le code d'état dans la réponse, il comprend si la requête a échoué, et la réexécute.
Déploiements canari: redirige un nombre fixe de requêtes vers la nouvelle version du service.
Surveillance et métriques: combien de temps le service a-t-il mis à répondre ?
Traçage et observabilité: ajoute des en-têtes spéciaux à chaque requête et les trace dans le cluster.
Sécurité: extrait le jeton JWT, authentifie et autorise les utilisateurs.

Ce ne sont là que quelques-unes des capacités (vraiment, seulement quelques-unes !) pour vous intriguer. Maintenant, plongeons dans les détails techniques !

Architecture d'Istio

Istio intercepte tout le trafic réseau et applique un ensemble de règles, en insérant dans chaque pod un proxy intelligent sous forme de conteneur sidecar. Les proxies, qui activent toutes les fonctionnalités, forment le Data Plane, et ils peuvent être configurés dynamiquement à l'aide de Control Plane.

le Data Plane

Les proxies insérés dans les pods permettent à Istio d'atteindre facilement les exigences nécessaires. Par exemple, vérifions les fonctionnalités de réessai et de circuit breaker.

Comment les retries et le circuit breaking sont réalisés dans Envoy

En résumé :

Envoy (il s'agit du proxy situé dans le conteneur sidecar, qui est également diffusé comme un produit distinct — n.d.t.) envoie une requête au premier instance du service B et un échec se produit.
Envoy Sidecar tente de réessayer (retry). (1)
La requête échouée retourne au proxy qui l'a appelée.
C'est ainsi que s'ouvre le Circuit Breaker et que le service suivant est appelé pour les requêtes ultérieures. (2)

Cela signifie que vous n'aurez pas à utiliser une autre bibliothèque Retry, pas besoin de créer votre propre implémentation de Circuit Breaking et de Service Discovery dans le langage de programmation X, Y ou Z. Tout cela et bien plus est disponible en standard dans Istio et ne nécessite pas aucun changement dans le code.

Génial ! Maintenant, vous pourriez vouloir partir en voyage avec Istio, mais vous avez encore des doutes, des questions ouvertes. Si c'est une solution universelle pour tous les cas, vous pouvez alors avoir un soupçon légitime : après tout, toutes ces solutions se révèlent souvent inadaptées à un cas particulier.

Et enfin, vous vous demandez : « Est-ce qu'on peut le configurer ? »

Vous êtes maintenant prêt pour un voyage en mer — et découvrons le Control Plane.

Control Plane

Il se compose de trois composants : Pilot, Mixer et Citadel, qui travaillent ensemble pour configurer les Envoy pour le routage du trafic, appliquer des politiques et collecter des données télémétriques. Schématiquement, cela ressemble à ceci :

Interaction entre Control Plane et Data Plane

Les Envoy (c'est-à-dire le data plane) sont configurés à l'aide de Kubernetes CRD (Custom Resource Definitions), définis par Istio et spécialement conçus à cet effet. Pour vous, cela signifie qu'ils sont présentés comme une ressource supplémentaire dans Kubernetes avec une syntaxe familière. Après création, cette ressource sera récupérée par le control plane et appliquée aux Envoy.

Relation des services avec Istio

Nous avons décrit la relation d'Istio avec les services, mais qu'en est-il de l'inverse : comment les services perçoivent-ils Istio ?

Honnêtement, la présence d'Istio est aussi connue pour les services que l'eau pour les poissons, lorsqu'ils se demandent : « Qu'est-ce que l'eau, au juste ? ».

Illustration Victoria Dimitrakopoulos: — Comment trouvez-vous l'eau ? — Qu'est-ce que l'eau, au juste ?

Ainsi, vous pouvez prendre un cluster opérationnel et, après le déploiement des composants d'Istio, les services qui s'y trouvent continueront de fonctionner, et après leur suppression, tout ira de nouveau bien. Évidemment, vous perdrez alors les fonctionnalités offertes par Istio.

Assez de théorie — mettons ce savoir en pratique !

Istio en pratique

Istio nécessite un cluster Kubernetes, où au moins 4 vCPU et 8 Go de RAM sont disponibles. Pour créer rapidement un cluster et suivre les instructions de l'article, je vous recommande d'utiliser Google Cloud Platform, qui propose aux nouveaux utilisateurs 300 $ gratuits.

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

Installation de Helm

Installez le client Helm sur votre ordinateur, comme indiqué dans la documentation officielle. Nous l'utiliserons pour générer les modèles pour l'installation d'Istio dans la section suivante.

Installation d'Istio

Téléchargez les ressources Istio à partir de la dernière version (le lien d'origine pour la version 1.0.5 a été modifié pour la version actuelle, c'est-à-dire 1.0.6 — note du traducteur), extrayez le contenu dans un répertoire que je vais appeler [istio-resources].

Pour faciliter l'identification des ressources Istio, créez dans le cluster K8s un espace de noms istio-system:

$ kubectl create namespace istio-system

Terminez l'installation en vous rendant dans le 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 produira les composants clés d'Istio dans le fichier istio.yaml. Nous avons modifié le modèle standard pour nous, en définissant les paramètres suivants :

global.mtls.enabled est défini sur faux (c'est-à-dire que l'authentification mTLS est désactivée — note du traducteur), afin de simplifier notre processus d'introduction ;
tracing.enabled active la traçabilité des requêtes avec Jaeger ;
kiali.enabled installe Kiali dans le 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 pod dans l'espace de noms istio-system soient en état Running ou Terminé, en exécutant la commande ci-dessous :

$ kubectl get pods -n istio-system

Nous sommes maintenant prêts à poursuivre dans la section suivante, où nous allons déployer et exécuter l'application.

Architecture de l'application d'analyse de sentiments

Utilisons l'exemple de l'application microservices d'analyse de sentiments, utilisée dans l' article d'introduction à Kubernetes. Elle est suffisamment complexe pour démontrer les capacités d'Istio en pratique.

L'application se compose de quatre microservices :

Service SA-Frontend, qui gère le frontend de l'application sur Reactjs ;
Service SA-WebApp, qui gère les demandes d'analyse de sentiments ;
Service SA-Logic, qui exécute le sentiment-analyse;
Service SA-Feedback, qui recueille des retours d'utilisateurs sur la précision de l'analyse effectuée.

Dans ce schéma, en plus des services, nous voyons également l'Ingress Controller, qui dans Kubernetes, route les requêtes entrantes vers les services correspondants. Dans Istio, un concept similaire est utilisé au sein de l'Ingress Gateway, dont les détails suivront.

Lancer une application avec le proxy d'Istio

Pour les opérations mentionnées dans cet article, clonez le dépôt istio-mastery. Il contient l'application et les manifestes pour Kubernetes et Istio.

Insertion des sidecars

L'insertion peut être effectuée d'appliquer automatiquement ou manuellement. Pour une insertion automatique des conteneurs sidecar, il est nécessaire d'ajouter un label à l'espace de noms istio-injection=enabled, ce qui se fait avec la commande suivante :

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

Maintenant, chaque pod qui sera déployé dans l'espace de noms par défaut (default) recevra son conteneur sidecar. Pour s'en assurer, déployons une application de test en naviguant vers le répertoire racine du dépôt [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 le déploiement des services, vérifions que les pods ont deux conteneurs (le service lui-même et son sidecar) en exécutant la commande kubectl get pods et en s'assurant que la colonne READY indique la valeur 2/2, symbole signifiant 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, cela se présente ainsi :

Proxy Envoy dans l'un des pods

Maintenant que l'application est montée et fonctionne, nous devons autoriser le trafic entrant à entrer dans l'application.

Ingress Gateway

La meilleure pratique pour cela (autoriser le trafic dans le cluster) est via Ingress Gateway dans Istio, qui se trouve à la « frontière » du cluster et permet d'activer pour le trafic entrant des fonctionnalités d'Istio telles que le routage, l'équilibrage de charge, la sécurité et la surveillance.

Le composant Ingress Gateway et le service qui le traverse ont été installés dans le cluster lors de l'installation d'Istio. Pour connaître l'adresse IP externe du 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 allons accéder à l'application via cette IP par la suite (je me référerai à elle comme EXTERNAL-IP), donc pour plus de commodité, notons 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 maintenant d'accéder à cette IP via un navigateur, vous obtiendrez une erreur Service Unavailable, car par défaut, Istio bloque tout le trafic entrant, tant qu'un Gateway n'est pas défini.

Ressource Gateway

Gateway est une CRD (Custom Resource Definition) dans Kubernetes, définie après l'installation d'Istio dans le cluster et qui active la possibilité d'indiquer les ports, les protocoles et les hôtes pour lesquels nous souhaitons autoriser le trafic entrant.

Dans notre cas, nous voulons autoriser le trafic HTTP sur le port 80 pour tous les hôtes. Cette tâche est réalisée avec 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 pas d'explications, sauf pour le sélecteur istio: ingressgateway. Avec ce sélecteur, nous pouvons indiquer à quel Ingress Gateway 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

Maintenant, le gateway autorise l'accès au port 80, mais n'a aucune idée de l'endroit où acheminer les requêtes. Pour cela, nous aurons besoin de Virtual Services.

Ressource VirtualService

VirtualService indique au Ingress Gateway comment router les requêtes qui sont autorisées à l'intérieur du cluster.

Les requêtes pour notre application, entrant via http-gateway, doivent être envoyées aux services sa-frontend, sa-web-app et sa-feedback :

Les routes qui doivent être configurées avec VirtualServices

Examinons les requêtes qui doivent être dirigées vers SA-Frontend :

Correspondance exacte par chemin / doit être envoyée à SA-Frontend pour obtenir index.html ;
Les chemins avec préfixe /static/* doivent être envoyés à SA-Frontend pour obtenir des fichiers statiques utilisés dans le frontend, tels que CSS et JavaScript ;
Les chemins correspondant à l'expression régulière '^.*\.(ico|png|jpg)$', doivent être envoyés à SA-Frontend, car ce sont des images affichées sur la page.

La mise en œuvre est obtenue avec la configuration suivante (sa-virtualservice-external.yaml):

type: VirtualService metadata: nom: sa-external-services spec: hôtes: - "*" passerelles: - http-gateway # 1 http: - correspondre: - uri: exact: \/ - uri: exact: \/callback - uri: prefix: \/static - uri: regex: '^.*.(ico|png|jpg) Points importants : Ce VirtualService concerne les requêtes arrivant via http-gateway; Dans destination le service est déterminé où les requêtes sont envoyées. Remarque: La configuration ci-dessus est stockée dans un fichier sa-virtualservice-external.yaml, qui contient également des paramètres pour le routage dans SA-WebApp et SA-Feedback, mais a été abrégé ici dans l'article pour concision. Appliquons VirtualService avec l'appel : $ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml virtualservice.networking.istio.io/sa-external-services créé Remarque: Lorsque nous appliquons des ressources Istio, le serveur API Kubernetes crée un événement qui est reçu par le plan de contrôle Istio, et c'est seulement après cela que la nouvelle configuration est appliquée aux serveurs proxy Envoy de chaque pod. Et le contrôleur Ingress Gateway se présente comme un autre Envoy configuré dans le plan de contrôle. Tout cela se présente de la manière suivante : Configuration d'Istio-IngressGateway pour le routage des requêtes L'application d'Analyse de Sentiment est accessible à http://{EXTERNAL-IP}/. Ne vous inquiétez pas si vous obtenez un statut Not Found : 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, travaillez un peu avec l'application pour générer du trafic (sa présence est nécessaire pour la clarté dans les prochaines actions — note de l'éditeur). Kiali : observabilité Pour accéder à l'interface d'administration de Kiali, exécutez la commande suivante : $ kubectl port-forward $(kubectl get pod -n istio-system -l app=kiali -o jsonpath='{.items[0].metadata.name}') -n istio-system 20001 … et ouvrez http://localhost:20001/, en vous connectant avec admin/admin. Ici, vous trouverez de nombreuses fonctionnalités utiles, par exemple pour vérifier la configuration des composants Istio, visualiser les services basés sur les informations recueillies lors de l'interception des requêtes réseau, obtenir des réponses aux questions « Qui contacte qui ? », « Quelle version du service rencontre des échecs ? », etc. En général, explorez les fonctionnalités de Kiali avant de progresser vers la visualisation des métriques avec Grafana. Grafana : visualisation des métriques Les métriques collectées dans Istio sont envoyées à Prometheus et visualisées avec Grafana. Pour accéder à l'interface d'administration de Grafana, exécutez la commande ci-dessous, puis ouvrez 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 En cliquant sur le menu Accueil en haut à gauche et en sélectionnant Tableau de bord des services Istio dans le coin supérieur gauche, commencez par le service sa-web-app, pour voir les métriques collectées : Nous aurons ici une représentation vide et totalement ennuyeuse — la direction ne l'approuvera jamais. Créons donc une petite charge avec la commande suivante : $ while true; do curl -i http://$EXTERNAL_IP/sentiment -H "Content-type: application/json" -d '{"sentence": "J'adore yogobella"}'; sleep .8; done Nous avons maintenant des graphiques beaucoup plus jolis, et en plus des outils remarquables de Prometheus pour la surveillance et Grafana pour la visualisation des métriques, ce qui nous permettra de connaître la performance, l'état de santé, les améliorations/dégâts dans le fonctionnement des services au fil du temps. Enfin, regardons le traçage des requêtes dans les services. Jaeger : traçage Le traçage est nécessaire parce que plus nous avons de services, plus il devient difficile d'arriver à la cause d'un échec. Regardons un simple cas dans l'image ci-dessous : Exemple typique d'une requête échouée aléatoirement La requête arrive, échoue — quelle en est la cause ? Premier service ? Ou deuxième ? Il y a des exceptions dans les deux — examinons les journaux de chacun. À quelle fréquence vous êtes-vous surpris à faire cela ? Notre travail ressemble plus à celui de détectives logiciels qu'à celui de développeurs… C'est un problème courant dans les microservices et il est résolu par des systèmes de traçage distribués, où les services passent entre eux un en-tête unique, puis cette information est redirigée vers le système de traçage, où elle est associée aux données de la requête. Voici une illustration : Pour identifier la requête, on utilise un TraceId Dans Istio, le Jaeger Tracer est utilisé, qui met en œuvre un cadre indépendant du fournisseur de l'API OpenTracing. Pour accéder à l'interface utilisateur de Jaeger, vous pouvez utiliser la commande suivante : $ kubectl port-forward -n istio-system $(kubectl get pod -n istio-system -l app=jaeger -o jsonpath='{.items[0].metadata.name}') 16686 Maintenant, allez sur http://localhost:16686/ et sélectionnez le service sa-web-app. Si le service n'apparaît pas dans le menu déroulant, générez une activité sur la page et rafraîchissez l'interface. Après cela, cliquez sur le bouton Find Traces, qui affichera les dernières traces — sélectionnez-en une — des informations détaillées sur toutes les traces apparaîtront : Cette trace montre : La requête arrive à istio-ingressgateway (c'est la première interaction avec l'un des services, et pour la requête un Trace ID est généré), après quoi le passerelle redirige la requête vers le service sa-web-app. Dans le service sa-web-app la requête est prise en charge par le sidecar Envoy, un « enfant » est créé dans le span (c'est pourquoi nous le voyons dans les traces) et redirigé vers le conteneur sa-web-app. (Span — unité logique de travail dans Jaeger, portant un nom, une heure de début d'opération et sa durée. Les spans peuvent être imbriqués et ordonnés. Un graphique orienté acyclique composé de spans forme un trace. — note du traducteur) Ici, la requête est traitée par la méthode sentimentAnalysis. Ces traces ont déjà été générées par l'application, c'est-à-dire qu'elles nécessitaient des modifications dans le code. À partir de ce moment, une requête POST est initiée dans sa-logic. L'ID de la trace doit être transmis depuis sa-web-app. … Remarque: À la étape 4, l'application doit voir les en-têtes générés par Istio et les transmettre dans les requêtes suivantes, comme illustré dans l'image ci-dessous : (A) Istio est responsable de la transmission des en-têtes ; (B) Les en-têtes sont gérés par les services Istio effectue le travail principal, car il génère des en-têtes pour les requêtes entrantes, crée de nouveaux spans dans chaque sidecar et les transmet. Cependant, sans gestion des en-têtes au sein des services, le chemin complet de traçage de la requête sera perdu. Il est nécessaire de prendre en compte (de transmettre) les en-têtes suivants : x-request-id x-b3-traceid x-b3-spanid x-b3-parentspanid x-b3-sampled x-b3-flags x-ot-span-context Ce n'est pas une tâche complexe, cependant 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, simplement en ajoutant les bibliothèques Jaeger et OpenTracing dans ses dépendances. Remarquez que l'application Sentiment Analysis démontre des implémentations sur Flask, Spring et ASP.NET Core. Maintenant que nous avons clarifié ce que nous recevons de manière standard (ou presque « de manière standard »), examinons les questions de routage finement réglé, de gestion du trafic réseau, de sécurité, etc. ! Note de traduction.: lisez à ce sujet dans la prochaine partie des matériaux sur Istio de Rinor Maloku, dont les traductions suivront bientôt sur notre blog. UPDATE (14 mars) : La deuxième partie est déjà publiée. P.S. de l'auteur Lisez aussi dans notre blog : « Retour aux microservices avec Istio » : partie 2 (routage, gestion du trafic), partie 3 (authentification et autorisation); «Conduit — un service mesh léger pour Kubernetes»; «Qu'est-ce qu'un service mesh et pourquoi ai-je besoin de lui [pour une application cloud avec des microservices] ?»; «Guide illustré sur la configuration du réseau dans Kubernetes. Parties 1 et 2»; «Comment ce conteneur sidecar s'est-il retrouvé ici [dans Kubernetes] ?». Source : habr.com route : - destination : host : sa-frontend # 2 port : number : 80
Points importants :

Ce VirtualService concerne les requêtes arrivant via http-gateway;
Dans destination le service est déterminé où les requêtes sont envoyées.

Remarque: La configuration ci-dessus est stockée dans un fichier sa-virtualservice-external.yaml, qui contient également des paramètres pour le routage dans SA-WebApp et SA-Feedback, mais a été raccourci ici dans l'article pour la concision.

Appliquons le VirtualService en l'appelant :

Remarque: Lorsque nous appliquons des ressources Istio, le serveur API Kubernetes crée un événement qui est reçu par le Plan de Contrôle Istio, et ensuite la nouvelle configuration est appliquée aux proxys Envoy de chaque pod. Le contrôleur Ingress Gateway se présente comme un autre Envoy, configuré dans le Plan de Contrôle. Tout cela se présente comme suit :

Configuration d'Istio-IngressGateway pour le routage des requêtes

L'application d'Analyse de Sentiment est accessible à http://{EXTERNAL-IP}/. Ne vous inquiétez pas si vous obtenez un statut Not Found : 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, travaillez un peu avec l'application pour générer du trafic (sa présence est nécessaire pour la clarté dans les prochaines actions — note de l'éditeur).

Kiali : observabilité

Pour accéder à l'interface d'administration de Kiali, exécutez la commande suivante :

… et ouvrez http://localhost:20001/, en vous connectant avec admin/admin. Ici, vous trouverez de nombreuses fonctionnalités utiles, par exemple pour vérifier la configuration des composants Istio, visualiser les services basés sur les informations recueillies lors de l'interception des requêtes réseau, obtenir des réponses aux questions « Qui contacte qui ? », « Quelle version du service rencontre des échecs ? », etc. En général, explorez les fonctionnalités de Kiali avant de progresser vers la visualisation des métriques avec Grafana.

Grafana : visualisation des métriques

Les métriques collectées dans Istio sont envoyées à Prometheus et 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 en sélectionnant Tableau de bord des services Istio dans le coin supérieur gauche, commencez par le service sa-web-app, pour voir les métriques collectées :

Nous aurons ici une représentation vide et totalement ennuyeuse — la direction ne l'approuvera jamais. Créons donc une petite charge avec la commande suivante :

Nous avons maintenant des graphiques beaucoup plus jolis, et en plus des outils remarquables de Prometheus pour la surveillance et Grafana pour la visualisation des métriques, ce qui nous permettra de connaître la performance, l'état de santé, les améliorations/dégâts dans le fonctionnement des services au fil du temps.

Enfin, regardons le traçage des requêtes dans les services.

Jaeger : traçage

Le traçage est nécessaire parce que plus nous avons de services, plus il devient difficile d'arriver à la cause d'un échec. Regardons un simple cas dans l'image ci-dessous :

Exemple typique d'une requête échouée aléatoirement

La requête arrive, échoue — quelle en est la cause ? Premier service ? Ou deuxième ? Il y a des exceptions dans les deux — examinons les journaux de chacun. À quelle fréquence vous êtes-vous surpris à faire cela ? Notre travail ressemble plus à celui de détectives logiciels qu'à celui de développeurs…

C'est un problème courant dans les microservices et il est résolu par des systèmes de traçage distribués, où les services passent entre eux un en-tête unique, puis cette information est redirigée vers le système de traçage, où elle est associée aux données de la requête. Voici une illustration :

Pour identifier la requête, on utilise un TraceId

Dans Istio, le Jaeger Tracer est utilisé, qui met en œuvre un cadre indépendant du fournisseur de l'API OpenTracing. Pour accéder à l'interface utilisateur de Jaeger, vous pouvez utiliser la commande suivante :

Maintenant, allez sur http://localhost:16686/ et sélectionnez le service sa-web-app. Si le service n'apparaît pas dans le menu déroulant, générez une activité sur la page et rafraîchissez l'interface. Après cela, cliquez sur le bouton Find Traces, qui affichera les dernières traces — sélectionnez-en une — des informations détaillées sur toutes les traces apparaîtront :

Cette trace montre :

La requête arrive à istio-ingressgateway (c'est la première interaction avec l'un des services, et pour la requête un Trace ID est généré), après quoi le passerelle redirige la requête vers le service sa-web-app.
Dans le service sa-web-app la requête est interceptée par le sidecar Envoy, un « enfant » est créé dans le span (c'est pourquoi nous le voyons dans les traces) et est redirigé vers le conteneur sa-web-app. (Span — une unité logique de travail dans Jaeger, ayant un nom, un temps de début d'opération et sa durée. Les spans peuvent être imbriqués et ordonnés. Un graphe orienté acyclique de spans forme une trace. — note de traduction.
Ici, la requête est traitée par la méthode sentimentAnalysis. Ces traces ont déjà été générées par l'application, c'est-à-dire qu'elles nécessitaient des modifications dans le code.
À partir de ce moment, une requête POST est initiée dans sa-logic. L'ID de la trace doit être transmis depuis sa-web-app.
…

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

(A) Istio est responsable de la transmission des en-têtes ; (B) Les en-têtes sont gérés par les services

Istio effectue le travail principal, car il génère des en-têtes pour les requêtes entrantes, crée de nouveaux spans dans chaque sidecar et les propage. Cependant, sans gestion des en-têtes à l'intérieur des services, le chemin complet de traçage de la requête sera perdu.

Il est nécessaire de prendre en compte (de transmettre) les en-têtes suivants :

Ce n'est pas une tâche complexe, cependant 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, simplement en ajoutant les bibliothèques Jaeger et OpenTracing dans ses dépendances.

Remarquez que l'application Sentiment Analysis démontre des implémentations sur Flask, Spring et ASP.NET Core.

Maintenant que nous avons clarifié ce que nous recevons de manière standard (ou presque « de manière standard »), examinons les questions de routage finement réglé, de gestion du trafic réseau, de sécurité, etc. !

Note de traduction.: lisez à ce sujet dans la prochaine partie des matériaux sur Istio de Rinor Maloku, dont les traductions suivront bientôt sur notre blog. UPDATE (14 mars) : La deuxième partie est déjà publiée.

P.S. de l'auteur

Lisez aussi dans notre blog :

« Retour aux microservices avec Istio » : partie 2 (routage, gestion du trafic), partie 3 (authentification et autorisation);
«Conduit — un service mesh léger pour Kubernetes»;
«Qu'est-ce qu'un service mesh et pourquoi ai-je besoin de lui [pour une application cloud avec des microservices] ?»;
«Guide illustré sur la configuration du réseau dans Kubernetes. Parties 1 et 2»;
«Comment ce conteneur sidecar s'est-il retrouvé ici [dans Kubernetes] ?».

Source : habr.com