Salut Habr ! Je présente à votre attention la traduction de l'article "Plan de données de maillage de service vs plan de contrôle" l'auteur Matt Klein.

Cette fois, j'ai « voulu et traduit » la description des deux composants du maillage de services, du plan de données et du plan de contrôle. Cette description m'a semblé la plus compréhensible et la plus intéressante, et surtout conduisant à la compréhension de « Est-ce vraiment nécessaire ?

Alors que l'idée d'un "Service mesh" est devenue de plus en plus populaire au cours des deux dernières années (Article original du 10 octobre 2017) et que le nombre de participants dans l'espace a augmenté, j'ai constaté une augmentation proportionnelle de la confusion parmi l'ensemble communauté technique sur la façon de comparer et de contraster différentes solutions.

La situation est mieux résumée par la série de tweets suivante que j’ai écrit en juillet :

Confusion du maillage de services n°1 : Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Aucun d’eux n’est égal à Istio. Istio est quelque chose de complètement différent. 1 /

Les premiers sont simplement des plans de données. Par eux-mêmes, ils ne font rien. Ils doivent être d’humeur à quelque chose de plus. 2/

Istio est un exemple de plan de contrôle qui relie les pièces entre elles. C'est une autre couche. /fin

Les tweets précédents mentionnent plusieurs projets différents (Linkerd, NGINX, HAProxy, Envoy et Istio), mais plus important encore, introduisent les concepts généraux de plan de données, de maillage de services et de plan de contrôle. Dans cet article, je vais prendre du recul et parler de ce que j'entends par les termes « plan de données » et « plan de contrôle » à un niveau très élevé, puis expliquer comment les termes s'appliquent aux projets mentionnés dans les tweets.

Qu’est-ce qu’un maillage de services, vraiment ?

Figure 1 : Présentation du maillage de services

Figure 1 illustre le concept de maillage de services à son niveau le plus élémentaire. Il existe quatre clusters de services (AD). Chaque instance de service est associée à un serveur proxy local. Tout le trafic réseau (HTTP, REST, gRPC, Redis, etc.) d'une seule instance d'application est transmis via un proxy local vers les clusters de services externes appropriés. De cette façon, l’instance d’application ne connaît pas le réseau dans son ensemble et ne connaît que son proxy local. En effet, le réseau du système distribué a été supprimé du service.

Plan de données

Dans un maillage de services, un serveur proxy situé localement pour l'application effectue les tâches suivantes :

• Découverte de services. Quels services/applications sont disponibles pour votre application ?
• Contrôle de santé. Les instances de service renvoyées par la découverte de services sont-elles saines et prêtes à accepter le trafic réseau ? Cela peut inclure des contrôles de santé actifs (par exemple, réponse/vérification de santé) et passifs (par exemple, utilisation de 3 erreurs 5xx consécutives comme indication d'un état de service défectueux).
• Routage. Lors de la réception d'une requête vers "/foo" provenant d'un service REST, à quel cluster de services la requête doit-elle être envoyée ?
• L'équilibrage de charge. Une fois qu'un cluster de services a été sélectionné lors du routage, à quelle instance de service la requête doit-elle être envoyée ? Avec quel timeout ? Avec quels réglages de coupure ? Si la demande échoue, doit-elle être réessayée ?
• Authentification et autorisation. Pour les demandes entrantes, le service appelant peut-il être identifié/autorisé cryptographiquement à l'aide de mTLS ou d'un autre mécanisme ? S'il est reconnu/autorisé, est-il autorisé à appeler l'opération demandée (point de terminaison) sur le service ou une réponse non authentifiée doit-elle être renvoyée ?
• Observabilité. Des statistiques détaillées, des journaux et des données de trace distribuées doivent être générés pour chaque demande afin que les opérateurs puissent comprendre le flux de trafic distribué et les problèmes de débogage à mesure qu'ils surviennent.

Le plan de données est responsable de tous les points précédents du maillage de services. En fait, le proxy local du service (side-car) est le plan de données. En d’autres termes, le plan de données est responsable de la diffusion, du transfert et de la surveillance conditionnelle de chaque paquet réseau envoyé vers ou depuis un service.

Le plan de contrôle

L'abstraction réseau fournie par un proxy local dans le plan de données est magique (?). Cependant, comment le proxy connaît-il réellement la route « /foo » vers le service B ? Comment les données de découverte de services renseignées par les requêtes proxy peuvent-elles être utilisées ? Comment sont configurés les paramètres d’équilibrage de charge, de timeout, de coupure de circuit, etc. ? Comment déployer une application en utilisant la méthode bleu/vert ou la méthode de transition gracieuse du trafic ? Qui configure les paramètres d’authentification et d’autorisation à l’échelle du système ?

Tous les éléments ci-dessus sont sous le contrôle du plan de contrôle du maillage de services. Le plan de contrôle prend un ensemble de proxys apatrides isolés et les transforme en un système distribué.

Je pense que la raison pour laquelle de nombreux technologues trouvent confus les concepts distincts de plan de données et de plan de contrôle est que pour la plupart des gens, le plan de données est familier tandis que le plan de contrôle est étranger/incompris. Nous travaillons depuis longtemps avec des routeurs et des commutateurs de réseau physiques. Nous comprenons que les paquets/requêtes doivent aller du point A au point B et que nous pouvons utiliser du matériel et des logiciels pour ce faire. La nouvelle génération de proxys logiciels sont simplement des versions sophistiquées des outils que nous utilisons depuis longtemps.

Figure 2 : Plan de contrôle humain

Cependant, nous utilisons des plans de contrôle depuis longtemps, même si la plupart des opérateurs de réseau n'associent pas cette partie du système à un composant technologique. La raison est simple :
La plupart des avions de contrôle utilisés aujourd'hui sont... nous.

Sur figure 2 montre ce que j’appelle le « plan de contrôle humain ». Dans ce type de déploiement, encore très courant, un opérateur humain probablement grincheux crée des configurations statiques - potentiellement via des scripts - et les déploie via un processus spécial sur tous les proxys. Les proxys commencent alors à utiliser cette configuration et commencent à traiter le plan de données à l'aide des paramètres mis à jour.

Figure 3 : Plan de contrôle de maillage de services avancé

Sur figure 3 montre le plan de contrôle « étendu » du maillage de services. Il se compose des parties suivantes :

• L'humain: Il y a toujours une personne (espérons-le moins en colère) qui prend des décisions de haut niveau concernant l'ensemble du système dans son ensemble.
• Interface utilisateur du plan de contrôle: Une personne interagit avec un certain type d’interface utilisateur pour contrôler le système. Il peut s'agir d'un portail Web, d'une application de ligne de commande (CLI) ou d'une autre interface. Grâce à l'interface utilisateur, l'opérateur a accès aux paramètres de configuration globale du système tels que :
  • Contrôle du déploiement, transition bleu/vert et/ou circulation progressive
  • Options d'authentification et d'autorisation
  • Spécifications de la table de routage, par exemple lorsque l'application A demande des informations sur "/foo", ce qui se passe
  • Paramètres de l'équilibreur de charge, tels que les délais d'attente, les tentatives, les paramètres de coupure de circuit, etc.
• Planificateur de charge de travail: Les services sont exécutés sur l'infrastructure via un certain type de système de planification/orchestration, tel que Kubernetes ou Nomad. Le planificateur est responsable du chargement du service avec son proxy local.
• Découverte de services. Lorsque le planificateur démarre et arrête les instances de service, il signale l'état de santé au système de découverte de services.
• API de configuration du proxy side-car : Les proxys locaux extraient dynamiquement l'état de divers composants du système en utilisant un modèle finalement cohérent sans intervention de l'opérateur. L'ensemble du système, composé de toutes les instances de service en cours d'exécution et des serveurs proxy locaux, converge finalement vers un seul écosystème. L'API du plan de données universel d'Envoy est un exemple de la façon dont cela fonctionne dans la pratique.

Essentiellement, le but du plan de contrôle est de définir la politique qui sera finalement acceptée par le plan de données. Des plans de contrôle plus avancés retireront davantage de parties de certains systèmes de l'opérateur et nécessiteront moins d'opérations manuelles, à condition qu'ils fonctionnent correctement !...

Plan de données et plan de contrôle. Résumé du plan de données et du plan de contrôle

• Plan de données du maillage de services: Affecte chaque paquet/requête du système. Responsable de la découverte des applications/services, de la vérification de l’état, du routage, de l’équilibrage de charge, de l’authentification/autorisation et de l’observabilité.
• Plan de contrôle du maillage de services: Fournit la politique et la configuration pour tous les plans de données en cours d’exécution au sein du réseau de service. Ne touche aucun paquet/requête sur le système. Le plan de contrôle transforme tous les plans de données en un système distribué.

Paysage actuel du projet

Après avoir compris l'explication ci-dessus, regardons l'état actuel du projet de service mesh.

• Plans de données: Linkerd, NGINX, HAProxy, Envoy, Traefik
• Plans de contrôle: Istio, Nelson, SmartStack

Plutôt que d'entrer dans une analyse approfondie de chacune des solutions ci-dessus, j'aborderai brièvement certains des points qui, selon moi, sont à l'origine d'une grande partie de la confusion dans l'écosystème à l'heure actuelle.

Linkerd a été l'un des premiers serveurs proxy de plan de données pour le maillage de services début 2016 et a réalisé un travail fantastique en sensibilisant et en attirant l'attention sur le modèle de conception de maillage de services. Environ 6 mois plus tard, Envoy a rejoint Linkerd (bien qu'il soit chez Lyft depuis fin 2015). Linkerd et Envoy sont les deux projets les plus souvent mentionnés lors des discussions sur les maillages de services.

Istio a été annoncé en mai 2017. Les objectifs du projet Istio sont très similaires au plan de contrôle étendu présenté dans figure 3. Envoy pour Istio est le proxy par défaut. Ainsi, Istio est le plan de contrôle et Envoy est le plan de données. En peu de temps, Istio a suscité beaucoup d'enthousiasme et d'autres plans de données ont commencé à s'intégrer en remplacement d'Envoy (Linkerd et NGINX ont démontré leur intégration avec Istio). Le fait que différents plans de données puissent être utilisés au sein du même plan de contrôle signifie que le plan de contrôle et le plan de données ne sont pas nécessairement étroitement couplés. Une API telle que l'API du plan de données générique d'Envoy peut former un pont entre deux parties du système.

Nelson et SmartStack aident à illustrer davantage la séparation du plan de contrôle et du plan de données. Nelson utilise Envoy comme proxy et construit un plan de contrôle fiable pour le maillage de services basé sur la pile HashiCorp, c'est-à-dire Nomade, etc. SmartStack était peut-être le premier d’une nouvelle vague de services mesh. SmartStack construit un plan de contrôle autour de HAProxy ou NGINX, démontrant la capacité de découpler le plan de contrôle du maillage de services du plan de données.

L'architecture de microservices avec un maillage de services attire de plus en plus d'attention (à juste titre !), et de plus en plus de projets et de fournisseurs commencent à travailler dans cette direction. Au cours des prochaines années, nous verrons beaucoup d’innovations dans le plan des données et dans le plan de contrôle, ainsi qu’un mélange accru de différents composants. A terme, l’architecture des microservices devrait devenir plus transparente et magique (?) pour l’opérateur.
Espérons de moins en moins irrité.

Points clés à retenir

• Un maillage de services se compose de deux parties différentes : le plan de données et le plan de contrôle. Les deux composants sont nécessaires et sans eux, le système ne fonctionnera pas.
• Tout le monde connaît le plan de contrôle, et à ce stade, le plan de contrôle pourrait être vous !
• Tous les plans de données sont en concurrence les uns avec les autres en termes de fonctionnalités, de performances, de configurabilité et d'extensibilité.
• Tous les plans de contrôle sont en concurrence les uns avec les autres en termes de fonctionnalités, de configurabilité, d'extensibilité et de facilité d'utilisation.
• Un plan de contrôle peut contenir les abstractions et API appropriées afin que plusieurs plans de données puissent être utilisés.

Source: habr.com