Une introduction aux mailles de service

Un maillage de service est une couche d’infrastructure qui vous permet de gérer la communication entre les microservices de votre application. Tandis que de plus en plus de développeurs utilisent des microservices, les mailles de service ont évolué pour simplifier et rendre plus efficace ce travail en consolidant les tâches de gestion et d'administration courantes dans une configuration distribuée.

Adopter une approche microservice de l’architecture d’application implique de diviser votre application en un ensemble de services faiblement couplés. Cette approche offre certains avantages: les équipes peuvent itérer des conceptions et évoluer rapidement, en utilisant un plus large éventail d’outils et de langages. D'autre part, les microservices posent de nouveaux défis en termes de complexité opérationnelle, de cohérence des données et de sécurité.

Les maillages de service sont conçus pour répondre à certains de ces défis en offrant un niveau de contrôle granulaire sur la manière dont les services communiquent entre eux. Plus précisément, ils offrent aux développeurs un moyen de gérer:

Bien qu'il soit possible d'effectuer ces tâches de manière native avec des orchestrateurs de conteneurs tels queKubernetes, cette approche implique une plus grande quantité de prise de décision et d'administration en amont par rapport aux solutions de maillage de service telles queIstio etLinkerd offre hors de la boîte. En ce sens, les maillages de service peuvent rationaliser et simplifier le processus de travail avec des composants communs dans une architecture de microservice. Dans certains cas, ils peuvent même étendre les fonctionnalités de ces composants.

Les maillages de service sont conçus pour répondre à certains des défis inhérents aux architectures d'applications distribuées.

Ces architectures sont issues du modèle d’application à trois niveaux, qui a divisé les applications en niveaux Web, Web et Base de données. À grande échelle, ce modèle s'est avéré difficile pour les organisations connaissant une croissance rapide. Les bases de code d'application monolithiques peuvent devenir des“big balls of mud” lourdes, ce qui pose des problèmes de développement et de déploiement.

En réponse à ce problème, des organisations telles que Google, Netflix et Twitter ont développé des bibliothèques internes de «clients lourds» afin de standardiser les opérations d'exécution entre les services. Ces bibliothèques fournissaient l'équilibrage de charge, la coupure des circuits, le routage et la télémétrie, précurseurs des capacités de maillage des services. Cependant, ils imposaient également des limites sur les langages que les développeurs pouvaient utiliser et demandaient des modifications sur l'ensemble des services lorsqu'ils étaient eux-mêmes mis à jour ou modifiés.

Une conception de microservice évite certains de ces problèmes. Au lieu d'avoir une base de code d'application centralisée volumineuse, vous disposez d'un ensemble de services gérés de manière discrète qui représentent une fonctionnalité de votre application. Les avantages d'une approche de microservice incluent:

Dans le même temps, les microservices ont également créé des défis:

Les maillages de service sont conçus pour résoudre ces problèmes en offrant un contrôle coordonné et granulaire de la manière dont les services communiquent. Dans les sections suivantes, nous verrons comment les maillages de service facilitent la communication entre services grâce à la découverte de service, le routage et l’équilibrage de la charge interne, la configuration du trafic, le cryptage, l’authentification et les autorisations, ainsi que la métrique et la surveillance. Nous utiliserons lesBookinfo sample application d'Istio - quatre microservices qui, ensemble, affichent des informations sur des livres particuliers - comme exemple concret pour illustrer le fonctionnement des maillages de service.

Dans un cadre distribué, il est nécessaire de savoir comment se connecter aux services et s’ils sont disponibles ou non. Les emplacements d'instance de service sont attribués de manière dynamique sur le réseau et les informations les concernant changent constamment, à mesure que les conteneurs sont créés et détruits par la mise à l'échelle automatique, les mises à niveau et les échecs.

Historiquement, il y avait quelques outils pour faire la découverte de service dans un framework de microservice. Les magasins de valeurs clés commeetcd ont été associés à d'autres outils tels queRegistrator pour offrir des solutions de découverte de services. Des outils tels queConsul ont répété cela en combinant un magasin clé-valeur avec une interface DNS qui permet aux utilisateurs de travailler directement avec leur serveur ou nœud DNS.

En adoptant une approche similaire, Kubernetes offre la découverte de service basée sur DNS par défaut. Avec celui-ci, vous pouvez rechercher des services et des ports de services et effectuer des recherches IP inversées à l'aide des conventions de dénomination DNS courantes. En général, un enregistrement A pour un service Kubernetes correspond à ce modèle:service.namespace.svc.cluster.local. Voyons comment cela fonctionne dans le contexte de l’application Bookinfo. Si, par exemple, vous vouliez des informations sur le servicedetails de l'application Bookinfo, vous pouvez consulter l'entrée correspondante dans le tableau de bord Kubernetes:

Cela vous donnera des informations pertinentes sur le nom du service, l'espace de noms et lesClusterIP, que vous pouvez utiliser pour vous connecter à votre service même lorsque des conteneurs individuels sont détruits et recréés.

Un réseau de services comme Istio offre également des fonctionnalités de découverte de services. Pour effectuer la découverte de services, Istio s'appuie sur la communication entre l'API Kubernetes, le propre plan de contrôle d'Istio, géré par le composant de gestion du traficPilot, et son plan de données, géré par les proxys sidecar deEnvoy. Pilot interprète les données du serveur API Kubernetes pour enregistrer les modifications dans les emplacements des pods. Il traduit ensuite ces données en une représentation canonique d'Istio et les transmet aux mandataires du side-car.

Cela signifie que la découverte de services dans Istio est indépendante de la plate-forme, ce que nous pouvons voir en utilisant lesGrafana add-on d'Istio pour examiner à nouveau le servicedetails dans le tableau de bord des services d'Istio:

Notre application s'exécute sur un cluster Kubernetes, nous pouvons donc à nouveau voir les informations DNS pertinentes sur le servicedetails, ainsi que d'autres données de performances.

Dans une architecture distribuée, il est important de disposer d'informations sur les services actualisées, précises et faciles à localiser. Kubernetes et les réseaux de services comme Istio offrent des moyens d'obtenir ces informations à l'aide de conventions DNS.

Pour gérer le trafic dans une infrastructure distribuée, il faut contrôler l’accès du trafic à votre cluster et son acheminement vers vos services. Plus vous avez de contrôle et de spécificité dans la configuration du trafic externe et interne, plus vous serez en mesure de faire avec votre configuration. Par exemple, dans les cas où vous travaillez avec des déploiements Canary, migrez des applications vers de nouvelles versions ou testez des services particuliers par injection de fautes, il est essentiel de pouvoir déterminer le volume de trafic généré par vos services et sa provenance. le succès de vos objectifs.

Kubernetes propose différents outils, objets et services qui permettent aux développeurs de contrôler le trafic externe vers un cluster:kubectl proxy,NodePort,Load Balancers etIngress Controllers and Resources. Leskubectl proxy etNodePort vous permettent d'exposer rapidement vos services au trafic externe:kubectl proxy crée un serveur proxy qui permet d'accéder au contenu statique avec un chemin HTTP, tandis queNodePort expose un port attribué au hasard sur chaque nœud. Bien que cela offre un accès rapide, les inconvénients incluent de devoir exécuterkubectl en tant qu'utilisateur authentifié, dans le cas dekubectl proxy, et un manque de flexibilité dans les ports et les adresses IP des nœuds, dans le cas deNodePort. Et bien qu'un équilibreur de charge optimise la flexibilité en se connectant à un service particulier, chaque service nécessite son propre équilibreur de charge, ce qui peut être coûteux.

Ingress Resource et Ingress Controller offrent ensemble un degré plus élevé de flexibilité et de configuration par rapport à ces autres options. L'utilisation d'un contrôleur d'ingress avec une ressource ingress vous permet d'acheminer le trafic externe vers les services et de configurer le routage interne et l'équilibrage de la charge. Pour utiliser une ressource d'entrée, vous devez configurer vos services, le contrôleur d'entrée etLoadBalancer, ainsi que la ressource d'entrée elle-même, qui spécifieront les routes souhaitées vers vos services. Actuellement, Kubernetes prend en charge ses propresNginx Controller, mais vous pouvez également choisir parmi d'autres options, gérées parNginx,Kong et autres.

Istio effectue une itération sur le modèle de contrôleur / ressource Kubernetes avecIstio Gateways etVirtualServices. A l'instar d'un contrôleur d'ingénierie, une passerelle définit la manière dont le trafic entrant doit être traité, en spécifiant les ports exposés et les protocoles à utiliser. Cela fonctionne conjointement avec un VirtualService, qui définit les itinéraires vers les services dans le maillage. Ces deux ressources communiquent des informations à Pilot, qui les transmet ensuite aux mandataires d’Envoy. Bien qu'ils soient similaires aux contrôleurs et ressources Ingress, les passerelles et les services virtuels offrent un niveau de contrôle différent sur le trafic: au lieu de combinerOpen Systems Interconnection (OSI) layers and protocols, les passerelles et les services virtuels vous permettent de différencier les couches OSI dans vos paramètres. Par exemple, en utilisant VirtualServices, les équipes travaillant avec des spécifications de couche d’application pourraient avoir une séparation entre les préoccupations et les équipes d’opérations de sécurité travaillant avec différentes spécifications de couche. VirtualServices permet de séparer le travail sur des fonctionnalités d'application distinctes ou dans différents domaines de confiance, et peut être utilisé pour des tâches telles que le test de canaries, le déploiement progressif, le test A / B, etc.

Pour visualiser la relation entre les services, vous pouvez utiliser lesServicegraph add-on d'Istio, qui produit une représentation dynamique de la relation entre les services à l'aide de données de trafic en temps réel. L'application Bookinfo peut ressembler à ceci sans qu'aucun routage personnalisé ne soit appliqué:

De même, vous pouvez utiliser un outil de visualisation commeWeave Scope pour voir la relation entre vos services à un moment donné. L’application Bookinfo sans routage avancé pourrait ressembler à ceci:

Lors de la configuration du trafic d'application dans un cadre distribué, il existe un certain nombre de solutions différentes - des options natives de Kubernetes aux maillages de service comme Istio - qui offrent diverses options pour déterminer comment le trafic externe atteindra vos ressources d'application et comment ces ressources communiqueront avec une seule un autre.

Une infrastructure distribuée présente des opportunités de vulnérabilités de sécurité. Au lieu de communiquer via des appels internes locaux, comme dans une configuration monolithique, les services d'une architecture de microservices communiquent des informations, notamment des informations privilégiées, via le réseau. Globalement, cela crée une plus grande surface d'attaque.

La sécurisation des clusters Kubernetes implique un large éventail de procédures. nous nous concentrerons sur l'authentification, l'autorisation et le cryptage. Kubernetes propose des approches natives pour chacune de ces solutions:

La configuration de stratégies et de protocoles de sécurité individuels dans Kubernetes nécessite un investissement administratif. Un service maillé comme Istio peut consolider certaines de ces activités.

Istio est conçu pour automatiser une partie du travail de sécurisation des services. Son plan de contrôle comprend plusieurs composants qui gèrent la sécurité:

Par exemple, lorsque vous créez un service, Citadel reçoit ces informations deskube-apiserver et crée des certificats et des clésSPIFFE pour ce service. Il transfère ensuite ces informations aux sidecars des pods et d’Envoy afin de faciliter la communication entre les services.

Vous pouvez également implémenter certaines fonctionnalités de sécurité parenabling mutual TLS lors de l'installation d'Istio. Celles-ci incluent des identités de service fortes pour la communication entre clusters et entre clusters, une communication sécurisée service-à-service et utilisateur-à-service, ainsi qu'un système de gestion de clés capable d'automatiser la création, la distribution et la rotation de clés et de certificats.

En effectuant des itérations sur la manière dont Kubernetes gère l’authentification, l’autorisation et le chiffrement, les réseaux de service comme Istio peuvent consolider et étendre certaines des meilleures pratiques recommandées pour l’exploitation d’un cluster Kubernetes sécurisé.

Les environnements distribués ont modifié les exigences en matière de métriques et de surveillance. Les outils de surveillance doivent être adaptatifs, prendre en compte les changements fréquents apportés aux services et aux adresses réseau et être complets, en tenant compte de la quantité et du type d'informations échangées entre les services.

Kubernetes inclut certains outils de surveillance internes par défaut. Ces ressources appartiennent à sesresource metrics pipeline, ce qui garantit que le cluster s'exécute comme prévu. Le composantcAdvisor collecte les statistiques d'utilisation du réseau, de la mémoire et du processeur des conteneurs et des nœuds individuels et transmet ces informations à kubelet; kubelet expose à son tour ces informations via une API REST. LeMetrics Server obtient ces informations de l'API puis les transmet aukube-aggregator pour le formatage.

Vous pouvez étendre ces outils internes et capacités de surveillance avec une solution de mesures complète. L'utilisation d'un service tel quePrometheus en tant qu'agrégateur de métriques vous permet de créer directement au-dessus du pipeline de métriques de ressources Kubernetes. Prometheus s’intègre directement à cAdvisor par l’intermédiaire de ses propres agents, situés sur les nœuds. Son service d'agrégation principal collecte et stocke les données des nœuds et les expose via des tableaux de bord et des API. Des options de stockage et de visualisation supplémentaires sont également disponibles si vous choisissez d'intégrer votre service d'agrégation principal avec des outils de stockage, de journalisation et de visualisation backend tels queInfluxDB,Grafana,ElasticSearch,Logstash ,Kibana et autres.

Dans un maillage de service comme Istio, la structure du pipeline de métriques complètes fait partie de la conception du maillage. Les side-cars Envoy fonctionnant au niveau du pod communiquent des métriques àMixer, qui gère les stratégies et la télémétrie. De plus, les services Prometheus et Grafana sont activés par défaut (bien que si vous installez Istio avecHelm, vous devrezspecify granafa.enabled=true lors de l'installation). Comme c'est le cas avec le pipeline de métriques complet, vous pouvez égalementconfigure other services and deployments pour les options de journalisation et d'affichage.

Avec ces outils de métrique et de visualisation en place, vous pouvez accéder aux informations actuelles sur les services et les charges de travail dans un emplacement central. Par exemple, une vue globale de l'application BookInfo pourrait ressembler à ceci dans le tableau de bord Istio Grafana:

En répliquant la structure d'un pipeline de métriques complètes Kubernetes et en simplifiant l'accès à certains de ses composants communs, le service, tel qu'Istio, simplifie le processus de collecte et de visualisation des données lors de l'utilisation d'un cluster.

Les architectures de microservices sont conçues pour rendre le développement et le déploiement d'applications rapides et fiables. Pourtant, une augmentation de la communication interservices a modifié les meilleures pratiques pour certaines tâches administratives. Cet article décrit certaines de ces tâches, comment elles sont gérées dans un contexte natif de Kubernetes et comment elles peuvent être gérées à l'aide d'un maillage de service - dans ce cas, Istio.

Pour plus d'informations sur certains sujets de Kubernetes abordés ici, veuillez consulter les ressources suivantes:

De plus, les hubs de documentationKubernetes etIstio sont d'excellents endroits pour trouver des informations détaillées sur les sujets abordés ici.