1.3. Comprendre le maillage de services
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.
1.3.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
1.3.2. Architecture Service Mesh
La technologie de maillage de services fonctionne au niveau de la communication réseau. En d'autres termes, les composants du maillage de services capturent ou interceptent le trafic vers et depuis les microservices, modifiant les requêtes, les redirigeant ou créant de nouvelles requêtes vers d'autres services.
À un niveau élevé, Red Hat OpenShift Service Mesh se compose d'un plan de données et d'un plan de contrôle
Le site data plane est un ensemble de proxys intelligents, fonctionnant avec des conteneurs d'application dans un pod, qui interceptent et contrôlent toutes les communications réseau entrantes et sortantes entre les microservices dans le maillage de services. Le plan de données est mis en œuvre de manière à intercepter tout le trafic réseau entrant (ingress) et sortant (egress). Le plan de données Istio est composé de conteneurs Envoy fonctionnant aux côtés des conteneurs d'application dans un pod. Le conteneur Envoy agit comme un proxy, contrôlant toutes les communications réseau entrantes et sortantes du pod.
Envoy proxies sont les seuls composants d'Istio qui interagissent avec le trafic du plan de données. Tout le trafic réseau entrant (ingress) et sortant (egress) entre les services passe par les proxys. Le proxy Envoy collecte également toutes les métriques liées au trafic des services au sein du maillage. Les proxys Envoy sont déployés en tant que sidecars, fonctionnant dans le même pod que les services. Les proxys Envoy sont également utilisés pour mettre en œuvre des passerelles maillées.
- Sidecar proxies gérer les communications entrantes et sortantes pour leur instance de charge de travail.
Gateways sont des proxys fonctionnant comme des équilibreurs de charge recevant des connexions HTTP/TCP entrantes ou sortantes. Les configurations de passerelle sont appliquées aux proxys Envoy autonomes qui fonctionnent à la périphérie du maillage, plutôt qu'aux proxys Envoy sidecar qui fonctionnent aux côtés de vos charges de travail de service. Vous utilisez une passerelle pour gérer le trafic entrant et sortant de votre réseau maillé, en vous permettant de spécifier le trafic que vous souhaitez voir entrer ou sortir du réseau maillé.
- Ingress-gateway - Également connue sous le nom de contrôleur d'entrée, la passerelle d'entrée est un proxy Envoy dédié qui reçoit et contrôle le trafic entrant dans le maillage de services. Une passerelle d'entrée permet d'appliquer des fonctions telles que la surveillance et les règles de routage au trafic entrant dans le cluster.
- Egress-gateway - Également connue sous le nom de contrôleur de sortie, la passerelle de sortie est un proxy Envoy dédié qui gère le trafic quittant le maillage de service. Une passerelle de sortie permet d'appliquer des fonctions telles que la surveillance et les règles de routage au trafic sortant du maillage.
Le site control plane gère et configure les serveurs mandataires qui constituent le plan de données. Il est la source autorisée pour la configuration, gère le contrôle d'accès et les politiques d'utilisation, et recueille les mesures des proxies dans le maillage de service.
Le plan de contrôle d'Istio est composé de Istiod qui consolide plusieurs composants précédents du plan de contrôle (Citadel, Galley, Pilot) en un seul binaire. Istiod assure la découverte des services, la configuration et la gestion des certificats. Il convertit les règles de routage de haut niveau en configurations Envoy et les propage aux sidecars au moment de l'exécution.
- Istiod peut agir en tant qu'autorité de certification (CA), générant des certificats supportant la communication sécurisée mTLS dans le plan de données. Vous pouvez également utiliser une autorité de certification externe à cette fin.
- Istiod est responsable de l'injection des conteneurs proxy sidecar dans les charges de travail déployées sur un cluster OpenShift.
Red Hat OpenShift Service Mesh utilise 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. Il agit comme un contrôleur, vous permettant de définir ou de modifier l'état souhaité des objets dans votre cluster, dans ce cas, une installation Red Hat OpenShift Service Mesh.
Red Hat OpenShift Service Mesh inclut également les modules complémentaires Istio suivants dans le cadre du produit :
- Kiali - Kiali est la console de gestion pour Red Hat OpenShift Service Mesh. Elle fournit des tableaux de bord, une observabilité et de solides capacités de configuration et de validation. Il montre la structure de votre maillage de services en déduisant la topologie du trafic et affiche la santé de votre maillage. Kiali fournit des métriques détaillées, une validation puissante, un accès à Grafana et une forte intégration avec la plateforme de traçage distribuée.
- Prometheus - Red Hat OpenShift Service Mesh utilise Prometheus pour stocker les informations de télémétrie des services. Kiali dépend de Prometheus pour obtenir des métriques, l'état de santé et la topologie du maillage.
- Jaeger - Red Hat OpenShift Service Mesh prend en charge la plateforme de traçage distribuée. Jaeger est un serveur de traçabilité open source qui centralise et affiche les traces associées à une requête unique entre plusieurs services. En utilisant la plateforme de traçage distribué, vous pouvez surveiller et dépanner vos systèmes distribués basés sur des microservices.
- Elasticsearch - Elasticsearch est un moteur de recherche et d'analyse open source, distribué et basé sur JSON. La plateforme de traçage distribuée utilise Elasticsearch pour le stockage permanent.
- Grafana - Grafana fournit aux administrateurs de maillage des requêtes avancées, des analyses de métriques et des tableaux de bord pour les données Istio. En option, Grafana peut être utilisé pour analyser les métriques de maillage de services.
Les intégrations Istio suivantes sont prises en charge avec Red Hat OpenShift Service Mesh :
- 3scale - Istio fournit une intégration optionnelle avec les solutions Red Hat 3scale API Management. Pour les versions antérieures à 2.1, cette intégration était réalisée via l'adaptateur 3scale Istio. Pour les versions 2.1 et ultérieures, l'intégration de 3scale est réalisée via un module WebAssembly.
Pour plus d'informations sur l'installation de l'adaptateur 3scale, reportez-vous à la documentation de l'adaptateur Istio 3scale
1.3.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.
1.3.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.
1.3.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.
1.3.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.
1.3.4. Comprendre le traçage distribué
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 cheminement de cette requête est une transaction distribuée. La plateforme de traçage distribué vous permet d'effectuer un traçage distribué, qui suit le parcours 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.
La plateforme de traçage distribuée enregistre l'exécution des demandes individuelles dans l'ensemble de la pile de microservices et les présente sous forme de traces. Un site trace est un chemin de données/d'exécution à travers le système. Une trace de bout en bout comprend une ou plusieurs travées.
Un site span représente une unité logique de travail qui comporte 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.
1.3.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.
1.3.4.2. Architecture de traçage distribuée Red Hat OpenShift
Le traçage distribué de Red Hat OpenShift est constitué de plusieurs composants qui fonctionnent ensemble pour collecter, stocker et afficher les données de traçage.
Red Hat OpenShift distributed tracing platform - Ce composant est basé sur le projet open source Jaeger.
- Client (Client Jaeger, Tracer, Reporter, application instrumentée, bibliothèques clientes) - Les clients de la plateforme de traçage distribué sont des implémentations de l'API OpenTracing spécifiques à chaque langue. 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.
- Agent (Agent Jaeger, file d'attente du serveur, travailleurs du processeur) - L'agent de la plate-forme de traçage distribuée 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. Cela se fait généralement en ayant un sidecar dans les environnements de conteneurs tels que Kubernetes.
- Jaeger Collector (Collecteur, file d'attente, travailleurs) - Comme l'agent Jaeger, le collecteur Jaeger reçoit les travées et les place dans une file d'attente interne en vue de leur traitement. Cela permet au collecteur Jaeger de retourner immédiatement au client/à l'agent au lieu d'attendre que la travée se rende au stockage.
- Storage (Magasin de données) - Les collecteurs ont besoin d'un backend de stockage persistant. La plateforme de traçage distribuée Red Hat OpenShift dispose d'un mécanisme enfichable pour le stockage de la portée. 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) - Le traçage distribué Red Hat OpenShift peut utiliser Apache Kafka comme tampon entre le collecteur et le stockage Elasticsearch. Ingester est un service qui lit les données de Kafka et les écrit dans le backend de stockage Elasticsearch.
- Jaeger Console - L'interface utilisateur de la plateforme de traçage distribué Red Hat OpenShift vous permet de visualiser vos données de traçage distribué. Sur la page Recherche, vous pouvez trouver des traces et explorer les détails des portées qui composent une trace individuelle.
Red Hat OpenShift distributed tracing data collection - Ce composant est basé sur le projet open source OpenTelemetry.
- OpenTelemetry Collector - Le collecteur OpenTelemetry permet de recevoir, de traiter et d'exporter des données de télémétrie sans tenir compte des fournisseurs. Le collecteur OpenTelemetry prend en charge les formats de données d'observabilité open-source, par exemple Jaeger et Prometheus, en les envoyant à un ou plusieurs back-ends open-source ou commerciaux. Le collecteur est l'emplacement par défaut où les bibliothèques d'instrumentation exportent leurs données de télémétrie.
1.3.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.
1.3.5. Prochaines étapes
- Préparez-vous à installer Red Hat OpenShift Service Mesh dans votre environnement OpenShift Container Platform.
