Comparaison des services maillés : Istio, Linkerd et Consul Connect
Les microservices fournissent aux applications, des moyens pour devenir hautement évolutives, portatives et résilientes. Ils peuvent accélérer les pipelines de livraison et d’intégration continue (CI/CD) et faciliter les environnements à nuages multiples. Ils agissent comme antidote au couplage fort qui est maintenu par les architectures monolithiques et qui peut être difficile à adapter puisqu’il faut réévaluer toute l’application lorsque que survient un problème, une mise à jour ou un changement de fonctionnalité dans un module. Les microservices renforcent les environnements volatiles et modernisés qui peuvent alimenter la demande en matière d’innovation de logiciel infonuagique natif.
Par conséquent, au cours des dernières années, l’utilisation de microservices et de conteneurs a monté en flèche, tout comme la demande pour des solutions pertinentes. Kubernetes, le système de logiciel libre d’orchestration de conteneurs est devenu la norme du secteur et a engendré un écosystème d’outils qui gravitent autour. Le paysage infonuagique natif a proliféré tant en taille qu’en portée, devenant chaque année, de plus en plus difficile et complexe à naviguer. Cela a facilité la mise en place de l’automatisation et l’utilisation plus efficace des ressources informatiques.
La volatilité propagée par les microservices est idéale pour les applications ayant de lourdes charges de travail diversifiées. Toutefois, les microservices comportent des défauts. Comme il peut être difficile d’établir la confiance entre les microservices, les opérations s’en trouvent ralenties. Les déploiements de type canari, c’est-à-dire de publier des versions pour un groupe restreint d’utilisateurs ou de serveurs, peuvent être compliqués. Il en est de même pour les retours arrière, le routage fondé sur les attributs, le chiffrement de bout à bout, la collecte de métriques et la limite de débit, qui sont aussi difficiles. Il reste tout de même des problèmes à régler avec les microservices. Ce sont des opérations auxquelles les développeurs d’applications ne veulent pas penser, mais dont ils dépendent.
Les services maillés ont surgi comme étant la solution aux problèmes de réseaux présentés par les microservices. Un service maillé désigne le support entre les différents microservices qui rend la connectivité possible. Ce réseautage est alors enrichi d’une panoplie d’autres fonctionnalités, comme la découverte de service, l’authentification et l’autorisation, la surveillance, le traçage et la régulation de flux. Les services maillés sont une partie essentielle des architectures basées sur les microservices et par conséquent, leur écosystème croît et prospère.
J’ai présenté la conférence : « Une comparaison des options de services maillés » (A Comparison of Service Mesh Options) aux récentes journées nord-Américaines Open Source Networking Days qui se sont tenues à Ottawa le 31 octobre 2018. Je me suis arrêté sur Istio, Linkerd et Consul Connect, les trois services maillés qui, selon moi, sont parmi les plus intéressants. Cet article de blogue est basé sur cette discussion.
Istio
En mai 2017, Istio a été sourcé librement par Google, IBM et Lyft. Comme il fut l’un des premiers services maillés, il est très riche en fonctionnalités. Istio, est conçu pour connecter, sécuriser et surveiller les microservices. Ces fonctionnalités incluent l’équilibrage de charge automatique pour HTTP, gRPC, WebSocket et le trafic TCP. Il offre un contrôle précis du comportement de débit, de bonnes règles de routage, des réessais, des basculements et des injections de fautes. Istio a une couche modulaire de politique et API de configuration qui soutient les contrôles d’accès, les limites de débit et les quotas. Les métriques, les enregistrements et les traces automatiques de tout le trafic à l’intérieur d’une grappe sont fournis et cela comprend aussi les entrées et les sorties de grappes. Istio a de solides politiques d’autorisation et d’authentification basées sur l’identité. Cela facilite la communication sécuritaire de service à service.
Istio utilise Envoy, un mandataire à haute performance développé en C++. Les mandataires Envoy sont déployés en motif « sidecar » qui empêche la communication entre les microservices de modifier le code de l’application. Les conteneurs ne savent pas lorsqu’un mandataire leur est attribué, mais ils reçoivent de la visibilité grâce à eux. Les mandataires Envoy fournissent la découverte dynamique de service, l’équilibrage de charge, la cessation du protocole TLS, les mandataires HTTP/2 et gRPC, des coupe-circuits, des bilans de santé, des mises en œuvre de mises en place avec répartition de trafic, injection de fautes et paramètres enrichis basés sur le pourcentage. Le projet CNCF Envoy a tout récemment atteint le stade d’achèvement et est en constante évolution.
Le plan de contrôle d’Istio se trouve au-dessus des mandataires et est composé de trois éléments. Pilot est l’élément qui se trouve au cœur, il est utilisé pour la gestion du trafic et il configure toutes les instances du mandataire Envoy. Mixer est un élément indépendant de plateforme, il fait respecter le contrôle d’accès et les politiques d’utilisation à travers le service maillé. Il collecte et analyse aussi les rapports télémétriques. Citadel, connu autrefois sous le nom de Istio-Auth, est l’exécuteur des politiques et de l’autorité de certification du service maillé. Il offre l’authentification de service à service et d’utilisateur final avec gestion intégrée d’identité et d’identifiants. Citadel peut être utilisé pour mettre à niveau le trafic non crypté dans le service maillé et pour imposer les politiques basées sur l’identité du service plutôt que sur les contrôles des réseaux.
Voici quelques autres éléments faisant partie intégrante d’Istio. Gateway, il s’agit de son équilibreur de charge, opère en périphérie du service maillé et reçoit les connexions HTTP/TCP entrantes et sortantes. VirtualServices définit les ensembles de règles du routage de trafic à appliquer lors de l’attribution d’adresses d’hôtes. Chaque règle de routage définit des critères équivalents pour le trafic de protocoles spécifiques qui, lorsqu’ils sont appariés, sont envoyés vers un service de destination désignée défini dans le registre. DestinationRules définit les politiques relatives au trafic destiné aux services qui ont déjà fait l’objet d’un routage, en spécifiant les paramètres de configuration d’équilibrage de charge, de taille de réserve de connexions et de cas particulier qui détectent et expulsent les hôtes malsains du bassin d’équilibrage de charge.
Linkerd
Au tout début, Linkerd (v1.0) était un mandataire de réseau pour activer les services maillés. En septembre 2018, il a fusionné avec Conduit pour former Linkerd 2.0, ayant tout récemment été mis en disponibilité générale. Cette mise à niveau de version a transformé le projet qui passe d’un service maillé à l’échelle de la grappe à un sidecar de service composable. Linkerd est conçu comme service maillé léger pouvant être placé sur n’importe quelle plateforme existante. Son installation est simple, tout comme ces outils CLI et n’exige pas l’utilisation d’admin de plateforme. Linkerd n’offre pas une vaste gamme de fonctionnalités, mais est d’une grande simplicité. C’est un service maillé simple, idéal pour les organisations qui n’exploitent pas un grand nombre de microservices et qui désirent mettre en place des services maillés rapidement et avec un minimum d’effort.
Le mandataire de Linkerd est petit, léger et est écrit en Rust. Il est déployé dans un motif sidecar et peut faire le chiffrement de bout à bout et l’injection automatique de mandataire, mais il comporte des lacunes au niveau de ses capacités de routage et de traçage complexes. À l’intérieur du plan de contrôle, le Contrôleur est composé de plusieurs conteneurs (incluant api public, mandataire api, destination et tap) qui fournissent la plupart des fonctionnalités. Le déploiement Web constitue le tableau de bord. Linkerd utilise Prometheus pour exposer et pour stocker les métriques. Une instance Prometheus a été configurée pour fonctionner précisément avec des données générées et déployées au sein du service maillé Linkerd. Le tableau de bord Grafana présente et affiche des tableaux de bord pouvant être atteints à partir du tableau de bord Linkerd lui-même.
Utilisez les commandes ci-dessous pour installer, injecter et inspecter le service maillé de Linkerd.
Consul Connect
Consul Connect offre la communication de service à service sécurisée avec cryptage TLS automatique et autorisation basée sur l’identité. Il met l’accent sur la découverte de service et la gestion de l’identité de service. Tout comme Istio, il utilise le mandataire Envoy et le motif sidecar.
Consul Connect est une extension de Consul, une découverte de service hautement disponible et distribué et une base de données KV. Consul Connect ajoute des capacités de service maillé et fut créé par Hashicorp en juillet 2018. C’est une extension de Consul et peut synchroniser les services Kubernetes et Consul. Il en va de même pour Consul Connect qui offre des intégrations à Vault pour la gestion des certificats et des secrets, prolongeant la découverte de service fournie par Consul.
Citrix ADC
Le Contrôleur de livraison d’application (ADC) de Citrix se rapproche davantage d’un équilibreur de charge que d’un service, il en existe de nombreuses versions adaptées à différents types d’applications. La plateforme CPX Citrix ADC est un équilibreur de charge pouvant être provisionné sur les hôtes Docker et est idéale pour les applications conteneurisées. Elle permet aux clients d’utiliser les fonctionnalités d’équilibrage de charge et de gestion de trafic de NetScaler tout en permettant également l’intégration et l’automatisation avec Istio et Consul. En tant que VPX ou MPX, elle peut être déployée comme accélérateur SSL dans un scénario nord-sud et pourrait remplacer un mandataire ou un side-car dans un scénario de déploiement est-ouest.
Citrix ADC offre le routage basé sur le contenu et laisse passer, ou bloque le trafic en se basant sur les paramètres de tête HTTP ou HTTPS. Il offre des algorithmes d’équilibrage de charge, par exemple, les moindres connexions et le moindre délai de réponse, et permet l’observabilité du trafic est-ouest par la mesure des indicateurs clés : erreurs, latence, saturation, trafic et volume.
Istio, Linkerd, Consul Connect et Citrix ADC ont tous des avantages qui pourraient répondre, ou non, aux exigences de votre pile technologique. Istio est le service maillé disponible le plus avancé, mais il peut être complexe et difficile à mettre à l’échelle et à gérer. En revanche, Linkerd offre un service maillé simple et plus facile à mettre en place et à exploiter, mais offrant moins de souplesse. Consul Connect permet l’intégration avec d’autres solutions HashiCorp, notamment Consul et Vault, tandis que Citrix ADC offre un équilibrage de charge riche en fonctionnalités et peut prendre en charge un lourd trafic de réseau d’infrastructure et offrir la décharge SSL évolutive pour le trafic public.
Istio, Linkerd, et Consul Connect ont tous leurs mérites respectifs qui répondent, ou non, aux exigences de votre pile technologique. Istio est le service maillé disponible le plus avancé, mais il peut être complexe et difficile à gérer. En revanche, Linkerd offre un service maillé simple, mais avec moins de souplesse. Consul Connect offre des intégrations à d’autres solutions Hashicorp, notamment Consul et Vault. Tandis que l’écosystème des services maillés continue de croître, nous pouvons nous attendre à voir, dans le futur, plus de fonctionnalités et de solutions qui atteignent la disponibilité générale. Pour en apprendre plus à propos de la mise en œuvre de solutions de services maillés dans le cadre d’une plus vaste pratique DevOps, inscrivez-vous à l’un de nos ateliers DevOps et assistez à ma conférence sur : Comparing Service Mesh Solutions, du 3 au 5 avril, au Sommet nord-Américain de réseautage de logiciel libre de la fondation Linux (Linux Foundation’s North American Open Networking Summit).
Syed Ahmed
Syed Ahmed est un développeur de logiciels chez CloudOps. Il est axé sur les intégrations et les problèmes qui sont difficiles à résoudre. Grâce à son expertise tant dans les piles de matériel que de logiciels, il ajoute une perspective unique dans la résolution de problèmes relatifs à l’intégration et à l’orchestration. Syed est un avide collaborateur du logiciel libre, il est aussi « Committer » et « PMC » pour le projet Apache CloudStack.
Téléchargez notre dernier livre électronique intitulé Azure Kubernetes Services : la securite des conteneurs pour un monde infonuagique écrit en collaboration avec Microsoft, qui explique les risques les plus importants liés à la sécurité des conteneurs et qui présente des moyens pour optimiser les solutions avec AKS.
