Re-bonjour !.. A la veille du début des cours Nous avons préparé une autre traduction utile.
Un maillage de services est une couche d'infrastructure configurable à faible latence nécessaire pour gérer de grands volumes de communications inter-processus basées sur le réseau entre les interfaces de programmation d'applications (API). Service Mesh permet une communication rapide, fiable et sécurisée entre les services d’infrastructure d’applications conteneurisés et souvent éphémères. Service Mesh fournit des fonctionnalités telles que la découverte de services, l'équilibrage de charge, le chiffrement, la transparence, la traçabilité, l'authentification et l'autorisation, ainsi que la prise en charge des modèles d'arrêt automatique (Disjoncteur).
Un maillage de services est généralement implémenté en fournissant à chaque instance de service une instance proxy, appelée Side-car. Side-car gérer les communications entre les services, surveiller et résoudre les problèmes de sécurité, c'est-à-dire tout ce qui peut être extrait des services individuels. De cette façon, les développeurs peuvent écrire, maintenir et servir le code d'application dans les services, et les administrateurs système peuvent travailler avec Service Mesh et exécuter l'application.
Istio de Google, IBM et Lyft est actuellement l'architecture de maillage de services la plus connue. Et Kubernetes, initialement développé chez Google, est désormais le seul framework d'orchestration de conteneurs pris en charge par Istio. Les fournisseurs tentent de créer des versions d'Istio prises en charge commercialement. Il sera intéressant de voir quelles nouveautés ils peuvent apporter au projet open source.
Cependant, Istio n’est pas la seule option puisque d’autres implémentations de Service Mesh sont en cours de développement. Modèle sidecar proxy est l'implémentation la plus populaire, comme en témoignent les projets Buoyant, HashiCorp, Solo.io et autres. Il existe également des architectures alternatives : la boîte à outils technologique Netflix est l'une des approches où la fonctionnalité Service Mesh est implémentée via les bibliothèques Ribbon, Hysterix, Eureka, Archaius, ainsi que des plateformes telles qu'Azure Service Fabric.
Service Mesh possède également sa propre terminologie pour les composants et fonctions de service :
- Cadre d'orchestration de conteneurs. À mesure que de plus en plus de conteneurs sont ajoutés à l'infrastructure des applications, il devient nécessaire de disposer d'un outil distinct pour surveiller et gérer les conteneurs : un cadre d'orchestration de conteneurs. Kubernetes a fermement occupé ce créneau, à tel point que même ses principaux concurrents Docker Swarm et Mesosphere DC/OS proposent une intégration avec Kubernetes comme alternative.
- Services et instances (pods Kubernetes). Une instance est une copie unique en cours d’exécution d’un microservice. Parfois, une instance est un conteneur. Dans Kubernetes, une instance est constituée d'un petit groupe de conteneurs indépendants appelé pod. Les clients accèdent rarement directement à une instance ou à un pod ; le plus souvent, ils accèdent à un service, qui est un ensemble d'instances ou de pods (répliques) identiques, évolutifs et tolérants aux pannes.
- Proxy side-car. Sidecar Proxy fonctionne avec une seule instance ou un seul pod. Le but de Sidecar Proxy est d'acheminer ou de proxy le trafic provenant du conteneur avec lequel il travaille et de renvoyer le trafic. Sidecar interagit avec d'autres proxys Sidecar et est géré par un framework d'orchestration. De nombreuses implémentations de Service Mesh utilisent Sidecar Proxy pour intercepter et gérer tout le trafic entrant et sortant d'une instance ou d'un pod.
- Découverte de services. Lorsqu'une instance doit communiquer avec un autre service, elle doit trouver (découvrir) une instance saine et disponible de l'autre service. En règle générale, l'instance effectue des recherches DNS. L'infrastructure d'orchestration de conteneurs maintient une liste d'instances prêtes à recevoir des requêtes et fournit une interface pour les requêtes DNS.
- L'équilibrage de charge. La plupart des frameworks d'orchestration de conteneurs fournissent un équilibrage de charge au niveau de la couche 4 (transport). Service Mesh implémente un équilibrage de charge plus complexe au niveau de la couche 7 (niveau application), riche en algorithmes et plus efficace dans la gestion du trafic. Les paramètres d'équilibrage de charge peuvent être modifiés à l'aide de l'API, vous permettant d'orchestrer des déploiements bleu-vert ou Canary.
- Шифрование. Service Mesh peut chiffrer et déchiffrer les demandes et les réponses, supprimant ainsi cette charge pour les services. Service Mesh peut également améliorer les performances en priorisant ou en réutilisant les connexions persistantes existantes, réduisant ainsi le besoin de calculs coûteux pour créer de nouvelles connexions. L'implémentation la plus courante du cryptage du trafic est TLS mutuel (mTLS), où une infrastructure à clé publique (PKI) génère et distribue des certificats et des clés destinés à être utilisés par Sidecar Proxy.
- Authentification et autorisation. Le Service Mesh peut autoriser et authentifier les requêtes effectuées depuis l'extérieur ou l'intérieur de l'application, en envoyant uniquement les requêtes validées aux instances.
- Prise en charge du modèle d'arrêt automatique. Prise en charge du maillage de services , qui isole les instances défectueuses, puis les renvoie progressivement au pool d'instances saines lorsque cela est nécessaire.
La partie d'une application Service Mesh qui gère le trafic réseau entre les instances est appelée Plan de données. Créer et déployer une configuration qui contrôle le comportement Plan de données, est effectué à l'aide d'un Avion de contrôle. Avion de contrôle inclut généralement ou est conçu pour se connecter à une API, une CLI ou une interface graphique afin de contrôler l'application.
Le plan de contrôle dans le service Mesh distribue la configuration entre le proxy Sidecar et le plan de données.
L'architecture Service Mesh est souvent utilisée pour résoudre des problèmes opérationnels complexes à l'aide de conteneurs et de microservices. Pionniers dans le domaine sont des sociétés telles que Lyft, Netflix et Twitter, qui fournissent des services stables à des millions d'utilisateurs dans le monde. (). Pour les applications moins exigeantes, des architectures plus simples suffiront probablement.
Il est peu probable que l’architecture Service Mesh soit la réponse à tous les problèmes de fonctionnement et de livraison des applications. Les architectes et les développeurs disposent d'un énorme arsenal d'outils, et un seul d'entre eux est un marteau qui, parmi de nombreuses tâches, ne doit en résoudre qu'une seule : enfoncer des clous. , par exemple, comprend plusieurs modèles différents qui fournissent un continuum d'approches pour résoudre les problèmes à l'aide de microservices.
Les éléments réunis dans une architecture Service Mesh, tels que NGINX, les conteneurs, Kubernetes et les microservices en tant qu'approche architecturale, peuvent être tout aussi productifs dans les implémentations non Service Mesh. Par exemple, Istio a été conçu comme une architecture maillée de services complète, mais sa modularité permet aux développeurs de sélectionner et de mettre en œuvre uniquement les composants technologiques dont ils ont besoin. Dans cette optique, il est important de développer une compréhension claire du concept Service Mesh, même si vous n’êtes pas sûr de pouvoir un jour l’implémenter pleinement dans votre application.
Source: habr.com