Comparaison du maillage de services Kubernetes

Lors des discussions sur l'architecture des microservices et la conteneurisation, un ensemble d'outils éprouvés en production a retenu l'attention ces dernières années : le maillage de services.

En effet, l'architecture des microservices et Kubernetes (souvent stylisés « K8 ») sont rapidement devenus la norme pour les applications évolutives, faisant du problème de la gestion des communications entre les services un sujet brûlant et des maillages de services une solution attrayante. J'ai moi-même utilisé des maillages de service en production, en particulier Linkerd, Istio et une forme antérieure d'Ambassador. Mais que font exactement les maillages de services ? Lequel est le meilleur à utiliser ? Comment savoir si vous devez en utiliser un ?

Pour répondre à ces questions, il est utile de comprendre pourquoi les maillages de services ont été développés. Historiquement, l'infrastructure informatique traditionnelle comportait des applications fonctionnant sous forme de monolithes. Un service s'exécutait sur un serveur ; s'il avait besoin de plus de capacité, la solution consistait à le mettre à l'échelle verticalement en approvisionnant une machine plus grande.

Atteignant les limites de cette approche, les grandes entreprises technologiques ont rapidement adopté une architecture à trois niveaux, séparant un équilibreur de charge des serveurs d'applications et un niveau de base de données. Alors que cette architecture restait quelque peu évolutive, ils ont décidé de décomposer le niveau application en microservices. La communication entre ces services est devenue essentielle à surveiller et à sécuriser pour que les applications évoluent.

Pour permettre la communication interservices, ces entreprises ont développé des bibliothèques internes : Finagle chez Twitter, Hystrix chez Netflix, et Stubby chez Google (devenu gRPC en 2016). Ces bibliothèques visaient à résoudre les problèmes soulevés par l'architecture des microservices : sécurité entre les services, latence, surveillance et équilibrage de charge. Mais gérer une grande bibliothèque en tant que dépendance, dans plusieurs langues, est complexe et prend du temps.

En fin de compte, ce type de bibliothèque a été remplacé par un proxy léger et plus facile à utiliser. Ces proxys étaient extérieurement indépendants de la couche d'application, potentiellement transparents pour l'application, et plus faciles à mettre à jour, à entretenir et à déployer. Ainsi, le service mesh est né.

Qu'est-ce qu'un maillage de services ?

Un maillage de services est une couche d'infrastructure logicielle permettant de contrôler la communication entre les services ; il est généralement constitué de deux composants :

1. Le plan de données , qui gère les communications à proximité de l'application. En règle générale, cela est déployé avec l'application sous la forme d'un ensemble de proxys réseau, comme illustré précédemment.
2. Le plan de contrôle, qui est le « cerveau » du maillage de services. Le plan de contrôle interagit avec les proxys pour pousser les configurations, assurer la découverte des services et centraliser l'observabilité.

Les maillages de services ont trois objectifs principaux autour de la communication interservices :

1. Connectivité
2. Sécurité
3. Observabilité

Connectivité

Cet aspect de l'architecture de maillage de services permet la découverte de services et le routage dynamique. Il couvre également la résilience des communications , comme les nouvelles tentatives, les délais d'attente, les coupures de circuit et la limitation du débit.

L' équilibrage de charge est une caractéristique essentielle des maillages de service. Tous les services étant maillés par des proxys permettent la mise en œuvre de politiques d'équilibrage de charge entre les services, telles que le tourniquet, l'aléatoire et les moindres demandes. Ces politiques sont la stratégie utilisée par le maillage de services pour décider quelle réplique recevra la demande d'origine, comme si vous aviez de minuscules équilibreurs de charge devant chaque service.

Enfin, les maillages de services offrent un contrôle du routage sous la forme de transfert et de mise en miroir du trafic.

Sécurité

Dans l'architecture traditionnelle des microservices, les services communiquent entre eux avec un trafic non chiffré. Le trafic interne non chiffré est aujourd'hui considéré comme une mauvaise pratique en termes de sécurité, en particulier pour les infrastructures de cloud public et les réseaux de confiance zéro.

En plus de protéger la confidentialité des données client lorsqu'il n'y a pas de contrôle direct sur le matériel, le chiffrement du trafic interne ajoute une couche bienvenue de complexité supplémentaire en cas de violation du système. Par conséquent, tous les maillages de services utilisent le cryptage TLS mutuel (mTLS) pour la communication interservices, c'est-à-dire toutes les communications interproxy.

Les maillages de services peuvent même appliquer des matrices complexes de politique d'autorisation , en autorisant ou en rejetant le trafic en fonction de politiques ciblant des environnements et des services particuliers.

Observabilité

L'objectif des maillages de services est d'apporter de la visibilité aux communications interservices. En contrôlant le réseau, un maillage de services renforce l'observabilité, fournissant des métriques de niveau sept , qui à leur tour permettent des alertes automatiques lorsque le trafic atteint un seuil personnalisable.

Généralement pris en charge par des outils tiers ou des plug-ins comme Jaeger ou Zipkin, un tel contrôle permet également le traçage en injectant des en-têtes de traçage HTTP .

Avantages du maillage de services

Le maillage de services a été créé pour compenser une partie de la charge opérationnelle créée par une architecture de microservices. Ceux qui ont de l'expérience dans les architectures de microservices savent qu'elles nécessitent une quantité importante de travail pour fonctionner au quotidien. Tirer pleinement parti du potentiel des microservices nécessite normalement des outils externes pour gérer la journalisation centralisée, la gestion de la configuration et les mécanismes d'évolutivité, entre autres. L'utilisation d'un maillage de services normalise ces fonctionnalités, ainsi que leur configuration et leur intégration .

L'observabilité du maillage de services, en particulier, fournit des méthodes de débogage et d'optimisation extrêmement polyvalentes. Grâce à une visibilité granulaire et complète sur les échanges entre les services, les ingénieurs, en particulier les SRE, peuvent résoudre plus rapidement les éventuels bogues et les erreurs de configuration du système. Avec le service mesh tracing, ils peuvent suivre une demande depuis son entrée dans le système (au niveau d'un équilibreur de charge ou d'un proxy externe) jusqu'aux services privés à l'intérieur de la pile. Ils peuvent utiliser la journalisation pour mapper une demande et enregistrer la latence qu'elle rencontre dans chaque service. Le résultat final : des informations détaillées sur les performances du système .

La gestion du trafic offre de puissantes possibilités avant de passer à une version complète d'une nouvelle version d'un service :

1. Redirigez de petits pourcentages de demandes.
2. Encore mieux, mettez en miroir les requêtes de production vers une nouvelle version pour tester son comportement avec le trafic en temps réel.
3. A/B tester n'importe quel service ou combinaison de services.

Les maillages de services rationalisent tous les scénarios ci-dessus, ce qui permet d'éviter et/ou d'atténuer plus facilement les surprises en production.

Comparaison des maillages de services Kubernetes

À bien des égards, les maillages de services constituent l'ensemble ultime d'outils pour l'architecture de microservices ; beaucoup d'entre eux s'exécutent sur l'un des meilleurs outils d'orchestration de conteneurs, Kubernetes. Nous avons sélectionné trois des principaux maillages de services fonctionnant sur Kubernetes aujourd'hui : Linkerd (v2), Istio et Consul Connect. Nous aborderons également d'autres maillages de services : Kuma, Traefik Mesh et AWS App Mesh. Bien qu'actuellement moins importants en termes d'utilisation et de communauté, ils sont suffisamment prometteurs pour être examinés ici et pour garder un œil sur eux en général.

Une note rapide sur les proxys sidecar

Tous les maillages de services Kubernetes n'adoptent pas la même approche architecturale, mais une approche courante consiste à tirer parti du modèle sidecar. Cela implique d'attacher un proxy (side-car) à l'application principale pour intercepter et réguler le trafic réseau entrant et sortant de l'application. En pratique, cela se fait dans Kubernetes via un conteneur secondaire dans chaque pod d'application qui suivra le cycle de vie du conteneur d'application.

L'approche side-car des maillages de services présente deux avantages principaux :

• Les proxys sidecar sont indépendants du runtime et même du langage de programmation de l'application.
  • Cela signifie qu'il est facile d'activer toutes les fonctionnalités d'un maillage de services où qu'il soit utilisé, dans toute la pile.
• Un side-car a le même niveau d'autorisations et d'accès aux ressources que l'application.
  • Le side-car peut aider à surveiller les ressources utilisées par l'application principale, sans qu'il soit nécessaire d'intégrer la surveillance dans la base de code de l'application principale.

Mais les side-cars sont un bienfait mitigé en raison de leur impact direct sur une application :

• L'initialisation du side-car peut bloquer le mécanisme de démarrage d'une application.
• Les proxys sidecar ajoutent une latence potentielle en plus de votre application.
• Les proxys side-car ajoutent également une empreinte de ressources qui peut coûter cher à grande échelle.

Compte tenu de ces avantages et inconvénients, l'approche side-car fait souvent l'objet de débats dans la communauté des maillages de services. Cela dit, quatre des six maillages de services comparés ici utilisent le proxy side-car Envoy, et Linkerd utilise sa propre implémentation side-car ; Traefik Mesh n'utilise pas de side-cars dans sa conception.

Revue Linkerd

Linkerd, qui a fait ses débuts en 2017, est le plus ancien maillage de services du marché. Créé par Buoyant (une société créée par deux anciens ingénieurs de Twitter), Linkerd v1 était basé sur Finagle et Netty.

Linkerd v1 a été décrit comme étant en avance sur son temps puisqu'il s'agissait d'un maillage de services complet et prêt pour la production. En même temps, c'était un peu lourd en termes d'utilisation des ressources. De plus, des lacunes importantes dans la documentation ont rendu difficile la configuration et l'exécution en production.

Avec cela, Buoyant a eu la chance de travailler avec un modèle de production complet, d'en acquérir de l'expérience et d'appliquer cette sagesse. Le résultat a été Conduit, la réécriture complète de Linkerd que la société a publiée en 2018 et renommée Linkerd v2 plus tard cette année-là. Linkerd v2 a apporté plusieurs améliorations convaincantes ; étant donné que le développement actif de Linkerd v1 par Buoyant a cessé il y a longtemps, nos mentions de "Linkerd" dans le reste de cet article font référence à la v2.

Entièrement open source, Linkerd s'appuie sur un proxy maison écrit en Rust pour le plan de données et sur du code source écrit en Go pour le plan de contrôle.

Connectivité

Les proxys Linkerd ont des fonctionnalités de nouvelle tentative et de temporisation, mais n'ont pas de coupure de circuit ni d'injection de retard au moment de la rédaction de cet article. La prise en charge d'Ingress est étendue ; Linkerd bénéficie d'une intégration avec les contrôleurs d'entrée suivants :

• Traefik
• Nginx
• CME
• Ambassadeur
• Gloo
• Contour
• Kong

Les profils de service dans Linkerd offrent des capacités de routage améliorées, donnant à l'utilisateur des métriques, un réglage des nouvelles tentatives et des paramètres de délai d'attente, le tout sur une base par route. En ce qui concerne l'équilibrage de charge, Linkerd propose une injection automatique de proxy, son propre tableau de bord et un support natif pour Grafana.

Sécurité

La prise en charge de mTLS dans Linkerd est pratique dans la mesure où sa configuration initiale est automatique, tout comme sa rotation quotidienne automatique des clés.

Observabilité

Prêts à l'emploi, les statistiques et les itinéraires Linkerd sont observables via une CLI. Du côté de l'interface graphique, les options incluent des tableaux de bord Grafana prédéfinis et un tableau de bord Linkerd natif.

Linkerd peut se connecter à une instance de Prometheus.

Le traçage peut être activé via un module complémentaire avec OpenTelemetry (anciennement OpenCensus) en tant que collecteur, et Jaeger effectuant le traçage lui-même.

Installation

L'installation de Linkerd se fait en injectant un proxy sidecar, ce qui se fait en ajoutant une annotation à vos ressources dans Kubernetes. Il y a deux façons d'aborder cela:

1. Utilisation d'une charte Helm. (Pour beaucoup, Helm est le gestionnaire de configuration et de modèles incontournable pour les ressources Kubernetes.)
2. Installer la CLI Linkerd, puis l'utiliser pour installer Linkerd dans un cluster.

La deuxième méthode commence par télécharger et exécuter un script d'installation :

 curl -sL https://run.linkerd.io/install | sh

À partir de là, l'outil Linkerd CLI linkerd fournit une boîte à outils utile qui aide à installer le reste de Linkerd et à interagir avec le cluster d'applications et le plan de contrôle.

linkerd check --pre exécutera toutes les vérifications préliminaires nécessaires à votre installation de Linkerd, fournissant des journaux clairs et précis sur les raisons pour lesquelles une installation potentielle de Linkerd pourrait ne pas fonctionner pour le moment. Sans --pre , cette commande peut être utilisée pour le débogage post-installation.

L'étape suivante consiste à installer Linkerd dans le cluster en exécutant :

 linkerd install | kubectl apply -f -

Linkerd installera alors de nombreux composants différents avec une très petite empreinte de ressources ; par conséquent, ils ont eux-mêmes une approche de microservices :

• linkerd-controller , qui fournit l'API publique avec laquelle la CLI et le tableau de bord interagissent
• linkerd-identity , qui fournit l'autorité de certification pour implémenter mTLS
• linkerd-proxy-injector , qui gère l'injection du proxy en mutant la configuration d'un pod
• linkerd-web , qui sert de tableau de bord permettant le suivi des déploiements et des pods, ainsi que des composants internes de Linkerd

Linkerd base la majeure partie de sa configuration sur CustomResourceDefinitions (CRD). Ceci est considéré comme la meilleure pratique lors du développement de logiciels complémentaires Kubernetes - c'est comme installer durablement un plug-in dans un cluster Kubernetes.

L'ajout de traçage distribué - qui peut ou non être ce que les utilisateurs de Linkerd recherchent réellement, en raison de certains mythes courants - nécessite une autre étape avec linkerd-collector et linkerd-jaeger. Pour cela, nous allons d'abord créer un fichier de configuration :

 cat >> config.yaml << EOF tracing: enabled: true EOF

Pour activer le traçage, nous exécuterions :

 linkerd upgrade --config config.yaml | kubectl apply -f -

Comme pour tout maillage de services basé sur des proxys side-car, vous devrez modifier le code de votre application pour activer le traçage. L'essentiel consiste simplement à ajouter une bibliothèque cliente pour propager les en-têtes de suivi ; il doit ensuite être inclus dans chaque service.

La fonctionnalité de répartition du trafic de Linkerd, exposée via son API conforme à l'interface SMI (Service Mesh Interface), autorise déjà les versions Canary. Mais pour les automatiser ainsi que la gestion du trafic, vous aurez également besoin d'outils externes comme Flagger.

Flagger est un outil de livraison progressive qui évaluera ce que Linkerd appelle les métriques « dorées » : « le volume de demandes, le taux de réussite et les distributions de latence ». (À l'origine, les SRE de Google utilisaient le terme signaux dorés et en incluaient un quatrième, la saturation, mais Linkerd ne le couvre pas car cela nécessiterait des mesures qui ne sont pas directement accessibles, telles que l'utilisation du processeur et de la mémoire.) Flagger les suit tout en divisant le trafic. utiliser une boucle de rétroaction ; par conséquent, vous pouvez implémenter des versions Canary automatisées et compatibles avec les métriques.

Après avoir approfondi le processus d'installation, il devient clair que pour avoir un maillage de services Linkerd opérationnel et exploitant les capacités généralement souhaitées, il est facile de se retrouver avec au moins une douzaine de services en cours d'exécution. Cela dit, plus d'entre eux sont fournis par Linkerd lors de l'installation qu'avec d'autres maillages de service.

Résumé du maillage de services Linkerd

Avantages :

Linkerd bénéficie de l'expérience de ses créateurs, deux ex-ingénieurs de Twitter qui avaient travaillé sur l'outil interne, Finagle, puis appris de Linkerd v1. En tant que l'un des premiers maillages de services, Linkerd possède une communauté florissante (son Slack compte plus de 5 000 utilisateurs, ainsi qu'une liste de diffusion active et un serveur Discord) et un ensemble complet de documentation et de didacticiels. Linkerd est mature avec sa sortie de la version 2.9, comme en témoigne son adoption par de grandes entreprises comme Nordstrom, eBay, Strava, Expedia et Subspace. Une assistance payante de niveau entreprise de Buoyant est disponible pour Linkerd.

Désavantages:

Il y a une courbe d'apprentissage assez forte pour utiliser les maillages de service Linkerd à leur plein potentiel. Linkerd n'est pris en charge que dans les conteneurs Kubernetes (c'est-à-dire qu'il n'y a pas de mode "universel" basé sur les machines virtuelles). Le proxy side-car Linkerd n'est pas Envoy. Bien que cela permette à Buoyant de le régler comme bon lui semble, cela supprime l'extensibilité inhérente qu'offre Envoy. Cela signifie également que Linkerd ne prend pas en charge la coupure de circuit, l'injection de retard et la limitation de débit. Aucune API particulière n'est exposée pour contrôler facilement le plan de contrôle Linkerd. (Vous pouvez cependant trouver la liaison de l'API gRPC.)

Linkerd a fait de grands progrès depuis la v1 dans sa convivialité et sa facilité d'installation. L'absence d'une API officiellement exposée est une omission notable. Mais grâce à une documentation par ailleurs bien pensée, la fonctionnalité prête à l'emploi de Linkerd est facile à tester.

Examen du Consul Connect

Notre prochain concurrent de maillage de services, Consul Connect, est un hybride unique. Consul de HashiCorp est mieux connu pour son stockage clé-valeur pour les architectures distribuées, qui existe depuis de nombreuses années. Après l'évolution de Consul en une suite complète d'outils de service, HashiCorp a décidé de créer un maillage de services par-dessus : Consul Connect.

Pour être précis sur sa nature hybride :

Le plan de données Consul Connect est basé sur Envoy, qui est écrit en C++. Le plan de contrôle de Consul Connect est écrit en Go. C'est la partie qui est soutenue par Consul KV, un magasin clé-valeur.

Comme la plupart des autres maillages de services, Consul Connect fonctionne en injectant un proxy side-car dans votre pod d'application. En termes d'architecture, Consul Connect s'articule autour d' agents et de serveurs . Prêt à l'emploi, Consul Connect est censé avoir une haute disponibilité (HA) en utilisant trois ou cinq serveurs en tant que StatefulSet spécifiant l'anti-affinité des pods. L'anti-affinité de pod est la pratique consistant à s'assurer que les pods d'un système logiciel distribué ne se retrouveront pas sur le même nœud (serveur), garantissant ainsi la disponibilité en cas de défaillance d'un seul nœud.

Connectivité

Il n'y a pas grand-chose qui fait que Consul Connect se démarque dans ce domaine; il fournit ce que fait n'importe quel maillage de services (ce qui est assez), ainsi que des fonctionnalités de couche sept pour le routage basé sur le chemin, le transfert de trafic et l'équilibrage de charge.

Sécurité

Comme pour les autres maillages de services, Consul Connect fournit des fonctionnalités mTLS de base. Il propose également une intégration native entre Consul et Vault (également par HashiCorp), qui peut être utilisé comme fournisseur d'autorité de certification pour gérer et signer des certificats dans un cluster.

Observabilité

Consul Connect adopte l'approche d'observabilité la plus courante en incorporant Envoy en tant que proxy side-car pour fournir des capacités de niveau sept. La configuration de l'interface utilisateur de Consul Connect pour récupérer des métriques implique de modifier un fichier de configuration intégré et également d'activer un fournisseur de métriques comme Prometheus. Il est également possible de configurer certains tableaux de bord Grafana pour afficher des métriques pertinentes spécifiques au service.

Installation

Consul Connect est installé dans un cluster Kubernetes à l'aide d'un chart Helm :

 helm repo add hashicorp https://helm.releases.hashicorp.com

Vous devrez modifier le fichier default values.yaml si vous souhaitez activer l'UI ou faire en sorte que le module Consul Connect injecte son proxy sidecar :

 helm install -f consul-values.yml hashicorp hashicorp/consul

Pour consulter les membres et vérifier les différents nœuds, Consul recommande de exec dans l'un des conteneurs puis d'utiliser l'outil CLI consul .

Pour servir l'interface utilisateur Web prête à l'emploi fournie par Consul, exécutez kubectl port-forward service/hashicorp-consul-ui 18500:80 .

Résumé du maillage du service Consul Connect

Avantages :

• Consul est soutenu par HashiCorp ; en tant que produit freemium, il existe également une version entreprise avec des fonctionnalités supplémentaires qui offre un support de niveau entreprise. En termes d'expérience d'équipe de développement, Consul est l'un des outils les plus anciens du marché.
• Consul possède une solide communauté d'entreprises et est connu pour fonctionner sur une infrastructure de 50 000 nœuds. De plus, il existe depuis 2014, ce qui en fait un produit mature par rapport au marché.
• Consul Connect fonctionne bien à l'intérieur d'une machine virtuelle, grâce au support natif.
• Avec Consul Connect, il est possible de réaliser des intégrations d'applications aussi profondes que les implémentations pré-service-mesh dans les entreprises technologiques de premier plan. C'est grâce à l'exposition d'une API entièrement documentée au niveau de la bibliothèque.

Désavantages:

• Consul Connect a une courbe d'apprentissage plus abrupte que les autres maillages de services et nécessitera plus de réglages pour exécuter des tableaux de bord visuels et des métriques.
• La documentation de HashiCorp n'est pas simple, laissant les utilisateurs creuser et expérimenter pour la configurer correctement.
• La documentation sur la gestion du trafic est difficile à trouver et consiste principalement en des liens vers la documentation d'Envoy, qui ne fournit pas de détails sur la gestion du trafic Consul Connect en particulier.
• L'interface SMI de Consul Connect est encore expérimentale.

Consul Connect peut être un très bon choix pour ceux qui recherchent un produit de qualité professionnelle. HashiCorp est connu pour la qualité de ses produits, et Consul Connect ne fait pas exception. Je peux voir ici deux avantages importants par rapport aux autres maillages de services : un support solide de l'entreprise avec la version entreprise et un outil prêt pour toutes sortes d'architectures (pas seulement Kubernetes).

Examen d'Istio

En mai 2017, Google, IBM et Lyft ont annoncé Istio. Lorsque Istio est entré dans la course aux outils de maillage de services, il a acquis une très bonne visibilité dans l'espace technologique. Ses auteurs ont ajouté des fonctionnalités basées sur les commentaires des utilisateurs tout au long de la version 1.9.

Istio promettait de nouvelles fonctionnalités importantes par rapport à ses concurrents à l'époque : équilibrage de charge automatique, injection de fautes, et bien d'autres encore. Cela lui a valu une large attention de la part de la communauté, mais comme nous le détaillerons plus bas, l'utilisation d'Istio est loin d'être anodine : Istio a été reconnu comme particulièrement complexe à mettre en production.

Historiquement, le projet Istio a fréquemment rebondi en termes de modifications du code source. Après avoir adopté une architecture de microservices pour le plan de contrôle, Istio est maintenant (depuis la version 1.5) revenu à une architecture monolithique. La justification d'Istio pour revenir à la centralisation était que les microservices étaient difficiles à surveiller pour les opérateurs, la base de code était trop redondante et le projet avait atteint sa maturité organisationnelle - il n'était plus nécessaire d'avoir de nombreuses petites équipes travaillant en silos.

Cependant, en cours de route, Istio a acquis la notoriété d'avoir l'un des volumes les plus élevés de problèmes GitHub ouverts. Au moment d'écrire ces lignes, le décompte s'élève à environ 800 problèmes ouverts et environ 12 000 fermés. Bien que le nombre de problèmes puisse être trompeur, dans ce cas, ils représentent une amélioration significative en termes de fonctionnalités précédemment interrompues et d'utilisation des ressources hors de contrôle.

Connectivité

Istio est assez fort dans la gestion du trafic par rapport à Consul Connect et Linkerd. Ceci grâce à une offre étendue de sous-fonctionnalités : routage des requêtes, injection de pannes, transfert de trafic, délais d'attente des requêtes, coupure de circuit et contrôle du trafic d'entrée et de sortie vers le maillage de services. La notion de services virtuels et de règles de destination le rend très complet en termes de gestion du trafic.

Cependant, toutes ces possibilités s'accompagnent d'une courbe d'apprentissage, ainsi que de la gestion de ces nouvelles ressources sur votre cluster Kubernetes.

Sécurité

Istio dispose d'un ensemble complet d'outils liés à la sécurité, avec deux axes principaux : l'authentification et l'autorisation. Istio peut appliquer différents niveaux de règles sur différentes étendues : spécifiques à la charge de travail, à l'échelle de l'espace de noms ou à l'échelle du maillage. Toutes ces ressources de sécurité sont gérées via des CRD Istio tels que AuthorizationPolicy ou PeerAuthentication .

Au-delà de la prise en charge standard de mTLS, Istio peut également être configuré pour accepter ou rejeter le trafic non chiffré.

Observabilité

Ici, Istio est assez avancé prêt à l'emploi, avec plusieurs types de télémétrie offrant des informations solides sur le maillage de services. Les métriques sont basées sur les quatre signaux d'or (latence, trafic, erreurs et, dans une certaine mesure, saturation).

Notamment, Istio fournit des métriques pour le plan de contrôle lui-même. Il sert également des traces distribuées et des journaux d'accès, offrant une compatibilité explicite avec Jaeger, Lightstep et Zipkin pour permettre le traçage.

Il n'y a pas de tableau de bord natif, mais il existe un support officiel pour la console de gestion Kiali.

Installation

L'installation est aussi simple que de suivre les étapes officielles. Istio est également intégré nativement à GKE en tant que fonctionnalité bêta, mais là, GKE utilise Istio 1.4.X, l'ancienne version des microservices par opposition à la dernière version monolithique.

Une installation native commence par le téléchargement de la dernière version :

 curl -L https://istio.io/downloadIstio | sh -

Après avoir cd dans le dossier istio-* nouvellement créé, vous pouvez l'ajouter à votre chemin afin de pouvoir utiliser l'outil utilitaire istioctl :

 export PATH=$PWD/bin:$PATH

À partir de là, vous pouvez installer Istio sur votre cluster Kubernetes via istioctl :

 istioctl install

Cela installera Istio avec un profil default . Les profils istioctl vous permettent de créer différentes configurations d'installation et de basculer entre elles si nécessaire. Mais même dans un scénario à profil unique, vous pouvez profondément personnaliser l'installation d'Istio en modifiant certains CRD.

Les ressources Istio seront plus difficiles à gérer car vous devrez gérer plusieurs types de CRD ( VirtualService , DestinationRule et Gateway au minimum) pour vous assurer que la gestion du trafic est en place.

• Une ressource VirtualService est une configuration déclarant un service et les différentes règles de routage appliquées aux requêtes.
• Une ressource DestinationRule est utilisée pour regrouper et appliquer des politiques de trafic spécifiques à la cible.
• Une ressource de Gateway est créée pour gérer le trafic de maillage de services entrant et sortant (c'est-à-dire des proxys Envoy supplémentaires, mais fonctionnant à la périphérie plutôt que comme side-cars).

Les détails sémantiques dépassent le cadre de cet examen, mais examinons un exemple rapide montrant chacun de ces éléments travaillant ensemble. Supposons que nous ayons un site Web de commerce électronique avec un service appelé products . Notre VirtualService pourrait ressembler à ceci :

 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: products-route namespace: ecommerce spec: hosts: - products # interpreted as products.ecommerce.svc.cluster.local http: - match: - uri: prefix: "/listv1" - uri: prefix: "/catalog" rewrite: uri: "/listproducts" route: - destination: host: products # interpreted as products.ecommerce.svc.cluster.local subset: v2 - route: - destination: host: products # interpreted asproducts.ecommerce.svc.cluster.local subset: v1

La DestinationRule correspondante pourrait alors être :

 apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: products spec: host: products trafficPolicy: loadBalancer: simple: RANDOM # or LEAST_CONN or ROUND_ROBIN subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 - name: v3 labels: version: v3

Enfin, notre Gateway :

 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: cert-manager-gateway namespace: istio-system spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*"

Avec ces trois fichiers en place, une installation Istio serait prête à gérer le trafic de base.

Résumé du maillage de services Istio

Avantages :

• Parmi les différents maillages de services, Istio est celui qui possède la plus grande communauté en ligne à ce jour. Avec plus de 10 fois les résultats de Stack Overflow par rapport à l'un de ses principaux concurrents, il s'agit du maillage de services dont on parle le plus sur le Web ; ses contributeurs GitHub sont également d'un ordre de grandeur supérieur à ceux de Linkerd.
• Istio prend en charge les modes Kubernetes et VM ; ce dernier est en version bêta depuis la version 1.9.

Désavantages:

• Istio n'est pas gratuit, en deux sens :
  • Ses exigences sont élevées en termes de temps nécessaire pour lire la documentation, la mettre en place, la faire fonctionner correctement et la maintenir. Selon la taille de l'infrastructure et le nombre de services, Istio prendra plusieurs semaines à plusieurs mois de travail à temps plein pour être pleinement fonctionnel et intégré à la production.
  • Cela ajoute également une quantité importante de surcharge de ressources : il faudra 350 millicores (mCPU) pour le conteneur Envoy pour 1 000 requêtes par seconde (RPS). Même le plan de contrôle lui-même peut consommer beaucoup de ressources. (Auparavant, l'utilisation des ressources était difficile à prévoir, mais après quelques efforts, istiod s'est stabilisé autour de l'utilisation de 1 vCPU et de 1,5 Go de mémoire.)
• Il n'a pas de tableau de bord d'administration natif, contrairement à Linkerd.
• Istio nécessite l'utilisation de sa propre passerelle d'entrée.
• Le plan de contrôle Istio n'est pris en charge que dans les conteneurs Kubernetes (c'est-à-dire qu'il n'y a pas de mode VM, contrairement au plan de données d'Istio).

Istio est un excellent exemple de géants de la technologie qui se sont réunis pour créer un projet open source afin de relever un défi auquel ils sont tous confrontés. Il a fallu un certain temps au projet Istio dans son ensemble pour se structurer (rappelant le passage de l'architecture des microservices au monolithique) et résoudre ses nombreux problèmes initiaux. Aujourd'hui, Istio fait absolument tout ce que l'on attend d'un maillage de services et peut être considérablement étendu. Mais toutes ces possibilités s'accompagnent d'exigences élevées en termes de connaissances, d'heures de travail et de ressources informatiques pour prendre en charge son utilisation dans un environnement de production.

Examen rapide de Kuma

Créé par Kong puis open-source, Kuma a atteint le 1.0 fin 2020. Dans une certaine mesure, il a été créé en réponse au fait que les premiers maillages de service étaient plutôt lourds et difficiles à exploiter.

Sa liste de fonctionnalités suggère qu'il est très modulaire ; l'idée derrière Kuma est de l'orienter vers l'intégration avec des applications fonctionnant déjà sur Kubernetes ou une autre infrastructure.

• Dans le domaine de la gestion du trafic , Kuma propose des fonctionnalités communes de maillage de services telles que l'injection de pannes et la coupure de circuit.
• Au-delà du chiffrement mTLS interservices, les échanges entre le plan de données et le plan de contrôle sont sécurisés dans Kuma via un jeton proxy du plan de données .
• L'observabilité est définie dans Kuma via différentes politiques de trafic autour des métriques, du traçage et de la journalisation.
• La découverte de service est disponible via Kuma grâce à son propre résolveur DNS exécuté sur le port 5653 du plan de contrôle.
• Kuma met fortement l'accent sur la fonctionnalité multimesh : vous pouvez facilement combiner plusieurs clusters Kubernetes ou environnements de VM dans un cluster Kuma commun avec son type de déploiement multizone.
• Kuma s'intègre facilement à Kong Gateway pour les utilisateurs Kong existants.

La version universelle (non-Kubernetes) de Kuma nécessite PostgreSQL en tant que dépendance, et le CTO de Kong s'est notamment opposé à la prise en charge de SMI. Mais Kuma a été développé dès le départ avec l'idée de déploiements multicloud et multicluster, et son tableau de bord en est le reflet.

Bien que Kuma soit encore jeune dans l'espace de maillage de services, avec peu de cas d'utilisation en production jusqu'à présent, c'est un concurrent intéressant et prometteur.

Examen rapide du maillage Traefik

Initialement nommé Maesh, Traefik Mesh (par Traefik Labs) est un autre nouveau venu dans la course aux outils de maillage de service. La mission du projet est de démocratiser le service mesh en le rendant facile à utiliser et à paramétrer ; l'expérience des développeurs avec le bien pensé Traefik Proxy les place dans une position privilégiée pour y parvenir.

• Les fonctionnalités de gestion du trafic dans Traefik Mesh incluent la coupure de circuit et la limitation de débit.
• En termes d' observabilité , Traefik Mesh propose une prise en charge native d'OpenTracing et des métriques prêtes à l'emploi (l'installation standard inclut automatiquement Prometheus et Grafana), ce qui permet de gagner du temps de configuration.
• Pour la sécurité - en dehors de mTLS - les spécifications sont conformes à SMI et Traefik Mesh permet le réglage fin des autorisations de trafic via le contrôle d'accès.

Traefik Mesh a besoin de CoreDNS pour être installé sur le cluster. (Alors qu'Azure utilise CoreDNS par défaut depuis la version 1.12, GKE utilise par défaut kube-dns au moment de la rédaction de cet article, ce qui signifie qu'il y a une étape supplémentaire importante dans ce cas.) Il manque également de fonctionnalités multicluster.

Cela dit, Traefik Mesh est unique dans notre comparaison de maillage de services en ce sens qu'il n'utilise pas l'injection side-car. Au lieu de cela, il est déployé en tant que DaemonSet sur tous les nœuds pour agir comme un proxy entre les services, ce qui le rend non invasif. Dans l'ensemble, Traefik Mesh est simple à installer et à utiliser.

Examen rapide d'AWS App Mesh

Dans le monde des fournisseurs de cloud, AWS est le premier à avoir implémenté un service mesh natif connectable avec Kubernetes (ou EKS notamment) mais aussi ses autres services. AWS App Mesh a été publié en novembre 2018 et AWS l'a itéré depuis lors. Le principal avantage d'AWS App Mesh est l'écosystème AWS préexistant et sa position sur le marché ; la grande communauté derrière AWS dans son ensemble continuera à piloter son utilisation et sa convivialité.

• La gestion du trafic dans AWS App Mesh inclut la coupure de circuit en plus des fonctionnalités communes.
• Since AWS App Mesh is hosted by AWS, it's a fully managed service , which means not having to worry about resource usage or control plane availability.
• Observability in AWS App Mesh can be done through Prometheus or AWS X-Ray.

The project is not open source, doesn't support SMI, and there's not much info online about HA standards for the control plane. AWS App Mesh is more complex to set up than other Kubernetes-native service meshes and has very little community online (24 answers on Stack Overflow, 400 stars on GitHub) but that's because users are meant to benefit from AWS support.

AWS App Mesh has native integration with AWS, starting with EKS and extending to other AWS services like ECS (Fargate) and EC2. Unlike Traefik Mesh, it has multicluster support. Plus, like most service meshes, it's based on injecting Envoy, the battle-tested sidecar proxy.

Kubernetes Service Mesh Comparison Tables

The six Kubernetes service mesh options presented here have a few things in common:

• Protocol support : They all work with HTTP, HTTP/2, gRPC, TCP, and WebSockets.
• They all have basic security in the form of mTLS between proxies by default.
• Service meshes, by design, provide some form of load balancing .
• These six, at least, also include a request retrying option among their traffic management features.
• Lastly, service discovery is a core feature of any service mesh.

But there are certainly differences worth highlighting when it comes to service mesh infrastructure, traffic management, observability, deployment, and other aspects.

Infrastructure

Gestion du trafic

Observability

* OpenCensus and OpenTracing merged into OpenTelemetry in 2019, but you might find Linkerd articles referring to OpenCensus, as well as Istio and Traefik Mesh articles referring to OpenTracing.

Déploiement

Other Service Mesh Considerations

Should We Use a Kubernetes Service Mesh?

Now that we have seen what service meshes are, how they work, and the multitude of differences between them, we can ask: Do we need a service mesh?

That's the big question for SREs and cloud engineers these past few years. Indeed, microservices bring operational challenges in network communication that a service mesh can solve. But service meshes, for the most part, bring their own challenges when it comes to installation and operation.

One problem we can see emerging in many projects is that with service meshes, there is a gap between the proof-of-concept stage and the production stage. That is, it's unfortunately rare for companies to achieve staging environments that are identical to production in every aspect; with service meshes involving crucial infrastructure, scale- and edge-related effects can bring deployment surprises.

Service meshes are still under heavy development and improvement. This could actually be attractive for teams with high deployment velocities—those who have mastered “the art of staying state-of-the-art” and can closely follow the development cycle of cloud-native tools.

For others, though, the pace of service mesh evolution could be more of a pitfall. It would be easy enough to set up a service mesh but then forget about the need to maintain it. Security patches may go unapplied or, even if remembered, may carry with them unplanned issues in the form of deprecated features or a modified set of dependencies.

There's also a notable cost in terms of manpower to set up a service mesh in production. It would be a sensible goal for any team to evaluate this and understand if the benefits from a service mesh would outweigh the initial setup time. Service meshes are hard, no matter what the “easy” demo installations show.

In short, service meshes can solve some of the problems typical to projects deployed at scale but may introduce others, so be prepared to invest time and energy. In a hypothetical infrastructure involving 25 microservices and load of five queries per second, I would recommend having at least one person (preferably two) dedicated for at least a month to preparing a proof of concept and validating key aspects before thinking about running it in production. Once it's set up, anticipate the need for frequent upgrades—they will impact a core component of your infrastructure, namely network communications.

Kubernetes Service Meshes: A (Complex) Evolution in Scalable App Architecture

We've seen what service meshes are: a suite of tooling to answer new challenges introduced by microservices architecture. Through traffic management, observability, service discovery, and enhanced security, service meshes can reveal deep insights into app infrastructure.

There are multiple actors on the market, sometimes promoted by GAFAM et al., that have in some cases open-sourced or promoted their own internal tooling. Despite two different implementation types, service meshes will always have a control plane—the brain of the system—and a data plane, made of proxies that will intercept the requests of your application.

Reviewing the three biggest service meshes (Linkerd, Consul Connect, and Istio) we have seen the different strategies they've chosen to implement and the advantages they bring. Linkerd, being the oldest service mesh on the market, benefits from its creators' experience at Twitter. HashiCorp, for its part, offers the enterprise-ready Consul Connect, backed by a high level of expertise and support. Istio, which initially garnered ample attention online, has evolved into a mature project, delivering a feature-complete platform in the end.

But these actors are far from being the only ones, and some less-talked-about service meshes have emerged: Kuma, Traefik Mesh, and AWS App Mesh, among others. Kuma, from Kong, was created with the idea of making the service mesh idea “simple” and pluggable into any system, not just Kubernetes. Traefik Mesh benefited from experience with the preexisting Traefik Proxy and made the rare decision to eschew sidecar proxies. Last but not least, AWS decided to develop its own version of the service mesh, but one that relies on the dependable Envoy sidecar proxy.

In practice, service meshes are still hard to implement. Although service mesh benefits are compelling, their impact, critically, cuts both ways: Failure of a service mesh could render your microservices unable to communicate with each other, possibly bringing down your entire stack. A notorious example of this: Incompatibility between a Linkerd version and a Kubernetes version created a complete production outage at Monzo, an online bank.

Nonetheless, the whole industry is structuring itself around Kubernetes and initiatives like the Microsoft-spearheaded SMI, a standard interface for service meshes on Kubernetes. Among numerous other projects, the Cloud Native Computing Foundation (CNCF) has the Envoy-based Open Service Mesh (OSM) initiative, which was also originally introduced by Microsoft. The service mesh ecosystem remains abuzz, and I predict a champion emerging in the coming years, the same way Kubernetes became the de facto container orchestration tool.