2.2. Comprendre le maillage de services
You are viewing documentation for a Red Hat OpenShift Service Mesh release that is no longer supported.
Les plans de contrôle Service Mesh version 1.0 et 1.1 ne sont plus pris en charge. Pour plus d'informations sur la mise à niveau de votre plan de contrôle Service Mesh, voir Mise à niveau de Service Mesh.
Pour plus d'informations sur l'état de l'assistance d'une version particulière de Red Hat OpenShift Service Mesh, consultez la page Cycle de vie du produit.
Red Hat OpenShift Service Mesh fournit une plateforme pour une vision comportementale et un contrôle opérationnel sur vos microservices en réseau dans un maillage de services. Avec Red Hat OpenShift Service Mesh, vous pouvez connecter, sécuriser et surveiller les microservices dans votre environnement OpenShift Container Platform.
2.2.1. Comprendre le maillage des services
Un service mesh est le réseau de microservices qui composent les applications dans une architecture distribuée de microservices et les interactions entre ces microservices. Lorsqu'un Service Mesh augmente en taille et en complexité, il peut devenir plus difficile à comprendre et à gérer.
Basé sur le projet open source Istio, Red Hat OpenShift Service Mesh ajoute une couche transparente sur les applications distribuées existantes sans nécessiter de modifications au code du service. Vous ajoutez la prise en charge de Red Hat OpenShift Service Mesh aux services en déployant un proxy sidecar spécial aux services pertinents dans le maillage qui intercepte toutes les communications réseau entre les microservices. Vous configurez et gérez le Service Mesh en utilisant les fonctionnalités du plan de contrôle du Service Mesh.
Red Hat OpenShift Service Mesh vous offre un moyen simple de créer un réseau de services déployés qui fournissent :
- Découverte
- Équilibrage de la charge
- Authentification de service à service
- Recouvrement des défaillances
- Metrics
- Contrôle
Red Hat OpenShift Service Mesh fournit également des fonctions opérationnelles plus complexes, notamment :
- Tests A/B
- Libération des canaris
- Contrôle d'accès
- Authentification de bout en bout
2.2.2. Architecture Red Hat OpenShift Service Mesh
Red Hat OpenShift Service Mesh est logiquement divisé en un plan de données et un plan de contrôle :
Le site data plane est un ensemble de mandataires intelligents déployés en tant que sidecars. Ces mandataires interceptent et contrôlent toutes les communications réseau entrantes et sortantes entre les microservices dans le maillage de services. Les mandataires sidecar communiquent également avec Mixer, le centre de politique et de télémétrie à usage général.
- Envoy proxy intercepte tout le trafic entrant et sortant pour tous les services dans le maillage de services. Envoy est déployé en tant que sidecar du service concerné dans le même pod.
Le site control plane gère et configure les serveurs mandataires pour acheminer le trafic, et configure les mélangeurs pour appliquer les politiques et collecter les données télémétriques.
- Mixer applique des politiques de contrôle d'accès et d'utilisation (telles que l'autorisation, les limites de débit, les quotas, l'authentification et le traçage des demandes) et collecte des données télémétriques à partir du proxy Envoy et d'autres services.
- Pilot configure les proxies au moment de l'exécution. Pilot assure la découverte des services pour les sidecars Envoy, les capacités de gestion du trafic pour un routage intelligent (par exemple, les tests A/B ou les déploiements de canaris) et la résilience (délais d'attente, nouvelles tentatives et disjoncteurs).
- Citadel émet des certificats et en assure la rotation. Citadel fournit une authentification forte entre les services et les utilisateurs finaux grâce à une gestion intégrée des identités et des références. Vous pouvez utiliser Citadel pour mettre à niveau le trafic non chiffré dans le maillage de services. Citadel permet aux opérateurs d'appliquer des politiques basées sur l'identité des services plutôt que sur les contrôles du réseau.
- Galley ingère la configuration du maillage de services, puis la valide, la traite et la distribue. Galley protège les autres composants du maillage de services contre l'obtention des détails de la configuration de l'utilisateur à partir d'OpenShift Container Platform.
Red Hat OpenShift Service Mesh utilise également le site istio-operator pour gérer l'installation du plan de contrôle. Un Operator est un logiciel qui vous permet de mettre en œuvre et d'automatiser des activités courantes dans votre cluster OpenShift Container Platform. Il agit comme un contrôleur, vous permettant de définir ou de modifier l'état souhaité des objets dans votre cluster.
2.2.3. Comprendre le Kiali
Kiali fournit une visibilité sur votre maillage de services en vous montrant les microservices dans votre maillage de services, et comment ils sont connectés.
2.2.3.1. Vue d'ensemble de Kiali
Kiali fournit une observabilité dans le Service Mesh fonctionnant sur OpenShift Container Platform. Kiali vous aide à définir, valider et observer votre maillage de services Istio. Il vous aide à comprendre la structure de votre maillage de services en déduisant la topologie, et fournit également des informations sur la santé de votre maillage de services.
Kiali fournit une vue graphique interactive de votre espace de noms en temps réel qui offre une visibilité sur des caractéristiques telles que les disjoncteurs, les taux de requête, la latence et même les graphiques des flux de trafic. Kiali offre des informations sur les composants à différents niveaux, des applications aux services et aux charges de travail, et peut afficher les interactions avec des informations contextuelles et des graphiques sur le nœud ou le bord du graphique sélectionné. Kiali offre également la possibilité de valider vos configurations Istio, telles que les passerelles, les règles de destination, les services virtuels, les politiques de maillage, etc. Kiali fournit des métriques détaillées, et une intégration Grafana de base est disponible pour les requêtes avancées. Le traçage distribué est assuré par l'intégration de Jaeger dans la console Kiali.
Kiali est installé par défaut dans le cadre du Red Hat OpenShift Service Mesh.
2.2.3.2. Architecture Kiali
Kiali est basé sur le projet open source Kiali. Kiali est composé de deux éléments : l'application Kiali et la console Kiali.
- Kiali application (back end) - Ce composant s'exécute dans la plateforme d'application conteneurisée et communique avec les composants du maillage de services, récupère et traite les données, et expose ces données à la console. L'application Kiali n'a pas besoin de stockage. Lors du déploiement de l'application sur un cluster, les configurations sont définies dans des ConfigMaps et des secrets.
- Kiali console (front end) - La console Kiali est une application web. L'application Kiali sert la console Kiali, qui interroge ensuite le back-end pour obtenir des données et les présenter à l'utilisateur.
En outre, Kiali dépend de services et de composants externes fournis par la plateforme d'application de conteneurs et Istio.
- Red Hat Service Mesh (Istio) - Istio est une exigence de Kiali. Istio est le composant qui fournit et contrôle le maillage de services. Bien que Kiali et Istio puissent être installés séparément, Kiali dépend d'Istio et ne fonctionnera pas s'il n'est pas présent. Kiali doit récupérer les données et les configurations d'Istio, qui sont exposées via Prometheus et l'API du cluster.
- Prometheus - Une instance Prometheus dédiée est incluse dans l'installation de Red Hat OpenShift Service Mesh. Lorsque la télémétrie Istio est activée, les données de métriques sont stockées dans Prometheus. Kiali utilise ces données Prometheus pour déterminer la topologie du maillage, afficher les métriques, calculer la santé, montrer les problèmes éventuels, etc. Kiali communique directement avec Prometheus et assume le schéma de données utilisé par Istio Telemetry. Prometheus est une dépendance d'Istio et une dépendance dure pour Kiali, et de nombreuses fonctionnalités de Kiali ne fonctionneront pas sans Prometheus.
- Cluster API - Kiali utilise l'API de OpenShift Container Platform (cluster API) pour récupérer et résoudre les configurations de maillage de services. Kiali interroge l'API de cluster pour récupérer, par exemple, les définitions des espaces de noms, des services, des déploiements, des pods et d'autres entités. Kiali effectue également des requêtes pour résoudre les relations entre les différentes entités du cluster. L'API de cluster est également interrogée pour récupérer les configurations Istio comme les services virtuels, les règles de destination, les règles de routage, les passerelles, les quotas, etc.
- Jaeger - Jaeger est optionnel, mais est installé par défaut dans le cadre de l'installation de Red Hat OpenShift Service Mesh. Lorsque vous installez la plateforme de traçage distribué dans le cadre de l'installation par défaut de Red Hat OpenShift Service Mesh, la console Kiali comprend un onglet permettant d'afficher les données de traçage distribué. Notez que les données de traçage ne seront pas disponibles si vous désactivez la fonctionnalité de traçage distribué d'Istio. Notez également que l'utilisateur doit avoir accès à l'espace de noms où le plan de contrôle Service Mesh est installé pour afficher les données de traçage.
- Grafana - Grafana est optionnel, mais est installé par défaut dans le cadre de l'installation de Red Hat OpenShift Service Mesh. Lorsqu'elles sont disponibles, les pages de métriques de Kiali affichent des liens pour diriger l'utilisateur vers la même métrique dans Grafana. Notez que l'utilisateur doit avoir accès à l'espace de noms où le plan de contrôle Service Mesh est installé pour afficher les liens vers le tableau de bord Grafana et visualiser les données Grafana.
2.2.3.3. Caractéristiques du Kiali
La console Kiali est intégrée à Red Hat Service Mesh et offre les fonctionnalités suivantes :
- Health - Identifier rapidement les problèmes liés aux applications, aux services ou aux charges de travail.
- Topology - Visualisez la façon dont vos applications, services ou charges de travail communiquent via le graphe Kiali.
- Metrics - Des tableaux de bord prédéfinis vous permettent de visualiser le maillage des services et les performances des applications pour Go, Node.js, Quarkus, Spring Boot, Thorntail et Vert.x. Vous pouvez également créer vos propres tableaux de bord personnalisés. Quarkus, Spring Boot, Thorntail et Vert.x. Vous pouvez également créer vos propres tableaux de bord.
- Tracing - L'intégration avec Jaeger permet de suivre le parcours d'une requête à travers les différents microservices qui composent une application.
- Validations - Effectuer des validations avancées sur les objets Istio les plus courants (règles de destination, entrées de service, services virtuels, etc.)
- Configuration - Possibilité optionnelle de créer, mettre à jour et supprimer la configuration du routage Istio en utilisant des assistants ou directement dans l'éditeur YAML de la console Kiali.
2.2.4. Comprendre Jaeger
Chaque fois qu'un utilisateur effectue une action dans une application, une requête est exécutée par l'architecture qui peut nécessiter la participation de dizaines de services différents pour produire une réponse. Le chemin de cette requête est une transaction distribuée. Jaeger vous permet d'effectuer un traçage distribué, qui suit le chemin d'une requête à travers les différents microservices qui composent une application.
Distributed tracing est une technique utilisée pour relier les informations relatives à différentes unités de travail - généralement exécutées dans différents processus ou hôtes - afin de comprendre l'ensemble de la chaîne d'événements d'une transaction distribuée. Le traçage distribué permet aux développeurs de visualiser les flux d'appels dans les grandes architectures orientées services. Il peut s'avérer très utile pour comprendre la sérialisation, le parallélisme et les sources de latence.
Jaeger enregistre l'exécution des demandes individuelles dans l'ensemble de la pile de microservices et les présente sous forme de traces. Un trace est un chemin de données/d'exécution à travers le système. Une trace de bout en bout est composée d'une ou plusieurs travées.
Un site span représente une unité logique de travail dans Jaeger, avec un nom d'opération, l'heure de début de l'opération et sa durée. Les travées peuvent être imbriquées et ordonnées pour modéliser les relations de cause à effet.
2.2.4.1. Aperçu du traçage distribué
En tant que propriétaire de service, vous pouvez utiliser le traçage distribué pour instrumenter vos services afin de recueillir des informations sur votre architecture de service. Vous pouvez utiliser le traçage distribué pour la surveillance, le profilage du réseau et le dépannage de l'interaction entre les composants dans les applications modernes, cloud-natives et basées sur les microservices.
Le traçage distribué permet d'exécuter les fonctions suivantes :
- Contrôler les transactions distribuées
- Optimiser les performances et la latence
- Effectuer une analyse des causes profondes
Le traçage distribué de Red Hat OpenShift se compose de deux éléments principaux :
- Red Hat OpenShift distributed tracing platform - Ce composant est basé sur le projet open source Jaeger.
- Red Hat OpenShift distributed tracing data collection - Ce composant est basé sur le projet open source OpenTelemetry.
Ces deux composants sont basés sur les API et l'instrumentation OpenTracing, neutres vis-à-vis des fournisseurs.
2.2.4.2. Architecture de traçage distribuée
La plateforme de traçage distribuée est basée sur le projet open source Jaeger. La plateforme de traçage distribuée est constituée de plusieurs composants qui fonctionnent ensemble pour collecter, stocker et afficher les données de traçage.
- Jaeger Client (Tracer, Reporter, application instrumentée, bibliothèques clients) - Les clients Jaeger sont des implémentations spécifiques au langage de l'API OpenTracing. Ils peuvent être utilisés pour instrumenter des applications pour le traçage distribué, soit manuellement, soit avec une variété de frameworks open source existants, tels que Camel (Fuse), Spring Boot (RHOAR), MicroProfile (RHOAR/Thorntail), Wildfly (EAP), et bien d'autres, qui sont déjà intégrés à OpenTracing.
- Jaeger Agent (Server Queue, Processor Workers) - L'agent Jaeger est un démon de réseau qui écoute les données envoyées via le protocole UDP (User Datagram Protocol), qu'il met en lots et envoie au collecteur. L'agent est censé être placé sur le même hôte que l'application instrumentée. Ceci est typiquement accompli en ayant un sidecar dans les environnements de conteneurs comme Kubernetes.
- Jaeger Collector (File d'attente, travailleurs) - Comme l'agent, le collecteur peut recevoir des travées et les placer dans une file d'attente interne en vue de leur traitement. Cela permet au collecteur de retourner immédiatement au client ou à l'agent au lieu d'attendre que la travée soit acheminée vers le stockage.
- Storage (magasin de données) - Les collecteurs ont besoin d'un backend de stockage persistant. Jaeger dispose d'un mécanisme enfichable pour le stockage des données. Notez que pour cette version, le seul stockage pris en charge est Elasticsearch.
- Query (Service d'interrogation) - L'interrogation est un service qui permet d'extraire des traces du stockage.
- Ingester (Ingester Service) - Jaeger peut utiliser Apache Kafka comme tampon entre le collecteur et le stockage réel (Elasticsearch). Ingester est un service qui lit les données de Kafka et les écrit dans un autre backend de stockage (Elasticsearch).
- Jaeger Console - Jaeger fournit une interface utilisateur qui vous permet de visualiser vos données de traçage distribuées. Sur la page Recherche, vous pouvez trouver des traces et explorer les détails des portées qui composent une trace individuelle.
2.2.4.3. Fonctionnalités de traçage distribué de Red Hat OpenShift
Le traçage distribué de Red Hat OpenShift offre les capacités suivantes :
- Intégration avec Kiali - Lorsque la configuration est correcte, vous pouvez visualiser les données de traçage distribuées à partir de la console Kiali.
- Grande évolutivité - Le back-end de traçage distribué est conçu pour ne pas avoir de point de défaillance unique et pour s'adapter aux besoins de l'entreprise.
- Propagation du contexte distribué - Permet de relier des données provenant de différents composants afin de créer une trace complète de bout en bout.
- Compatibilité ascendante avec Zipkin - Le traçage distribué Red Hat OpenShift possède des API qui lui permettent d'être utilisé comme un remplacement direct de Zipkin, mais Red Hat ne prend pas en charge la compatibilité avec Zipkin dans cette version.
2.2.5. Prochaines étapes
- Préparez-vous à installer Red Hat OpenShift Service Mesh dans votre environnement OpenShift Container Platform.
