Bonjour Habr ! Je vous présente la traduction de l'article l'auteur Matt Klein.
Cette fois, j'ai eu envie de traduire la description des deux composants du maillage de services, le plan de données et le plan de contrôle. Cette description m'a semblé la plus claire et la plus intéressante, surtout parce qu'elle amène à se demander «Est-ce vraiment nécessaire ?».
Étant donné que l'idée de la «Service mesh» devient de plus en plus populaire ces deux dernières années (Article original du 10 octobre 2017), et que le nombre d'acteurs dans cet espace a augmenté, j'ai constaté une confusion croissante au sein de la communauté technique concernant la manière de comparer et de contraster différentes solutions.
La situation peut être mieux décrite par les séries de tweets suivants que j'ai écrites en juillet :
Confusion sur le maillage de services n° 1 : Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Aucun d'eux n'est égal à Istio. Istio est quelque chose de tout à fait différent. 1 /
Les premiers sont juste des plans de données. En eux-mêmes, ils ne font rien. Ils doivent être configurés pour quelque chose de plus. 2 /
Istio est un exemple de plan de contrôle qui relie les parties ensemble. C'est une couche différente. /fin
Dans les tweets précédents, plusieurs projets différents (Linkerd, NGINX, HAProxy, Envoy et Istio) sont mentionnés, mais plus important encore, des concepts généraux de plan de données, de maillage de services et de plan de contrôle sont introduits. Dans ce post, je vais prendre du recul et expliquer ce que j'entends par les termes «plan de données» et «plan de contrôle» à un niveau très élevé, puis expliquer comment ces termes se rapportent aux projets mentionnés dans les tweets.
Qu'est-ce que le maillage de services (What is a service mesh, really) ?
Figure 1 : Aperçu du maillage de services (Service mesh overview)
Figure 1 illustre le concept de maillage de services au niveau le plus basique. Il y a quatre clusters de services (A-D). Chaque instance de service est liée à un serveur proxy local. Tout le trafic réseau (HTTP, REST, gRPC, Redis, etc.) d'une instance d'application est transmis via le serveur proxy local aux clusters de services externes correspondants. Ainsi, l'instance d'application ne connaît pas le réseau dans son ensemble et ne connaît que son proxy local. En fait, le réseau du système distribué a été retiré du service.
Plan de données
Dans le maillage de services, le serveur proxy situé localement pour l'application effectue les tâches suivantes :
- Découverte de services. Quels services/applications sont disponibles pour votre application ?
- Vérification de l'état. Les instances de services retournées par la découverte de services sont-elles opérationnelles et prêtes à recevoir du trafic réseau ? Cela peut inclure à la fois des tests actifs (par exemple, vérification de la réponse) et passifs (par exemple, l'utilisation de 3 erreurs 5xx consécutives comme indication d'un état défaillant du service).
- Routage. En recevant une requête REST à « /foo », dans quel cluster de services doit-on envoyer la requête ?
- Équilibrage de charge. Après que le cluster de services ait été choisi lors du routage, vers quelle instance de service la requête doit-elle être envoyée ? Avec quel délai d'attente ? Avec quelles configurations de coupure de circuit ? Si la requête échoue, doit-elle être répétée ?
- Authentification et autorisation. Pour les requêtes entrantes, le service appelant peut-il être identifié/autorisé de manière cryptographique avec mTLS ou tout autre mécanisme ? S'il est identifié/autorisé, est-il autorisé à appeler l'opération demandée dans le service ou doit-il recevoir une réponse non authentifiée ?
- Observabilité. Pour chaque requête, des données statistiquement détaillées, des journaux et des informations de traçage distribué doivent être générées pour que les opérateurs puissent comprendre le flux de trafic distribué et les problèmes de débogage au fur et à mesure de leur apparition.
Tous les points précédents dans le maillage de services sont gérés par le plan de données. Essentiellement, le proxy local pour le service est le plan de données. En d'autres termes, le plan de données est responsable de la transmission, du routage et de l'observation de chaque paquet réseau envoyé vers ou depuis le service.
Le plan de contrôle
L'abstraction réseau fournie par le proxy local dans le plan de données (data plane) est magique (?). Cependant, comment le serveur proxy sait-il réellement que le chemin « /foo » mène au service B ? Comment les données de découverte de services (service discovery), qui sont remplies par les requêtes proxy, peuvent-elles être utilisées ? Comment les paramètres de répartition de la charge, de durée d'attente (timeout), de rupture de circuit (circuit breaking), etc., sont-ils configurés ? Comment le déploiement d'applications utilisant la méthode bleue/verte (blue/green) ou les méthodes de transition progressive du trafic sont-ils réalisés ? Qui configure les paramètres d'authentification et d'autorisation globaux ?
Tous les points ci-dessus relèvent du plan de contrôle (control plane) du maillage de services (service mesh). Le plan de contrôle (control plane) prend un ensemble de proxies isolés sans état et les transforme en un système distribué.serveurs Je pense que la raison pour laquelle de nombreux techniciens trouvent déroutants les concepts séparés du plan de données (data plane) et du plan de contrôle (control plane) est que pour la plupart des gens, le plan de données est familier, tandis que le plan de contrôle est étranger/incompréhensible. Nous avons longtemps travaillé avec des routeurs et des commutateurs 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 cela. La nouvelle génération de proxies logiciels n'est rien d'autre que des versions modernes d'outils que nous avons utilisés depuis longtemps..
Figure 2 : Plan de contrôle humain (Human control plane)
Cependant, nous utilisons des plans de contrôle (control plane) depuis longtemps, bien que la plupart des opérateurs réseau puissent ne pas associer cette partie du système à un composant technologique quelconque. La raison en est simple :
La plupart des plans de contrôle (control plane) utilisés aujourd'hui sont... nous
à la figure 2.
Sur dans le Ce que j'appelle le « Plan de contrôle humain (Human control plane) » est montré ici. Dans ce type de déploiement, qui est encore très fréquent, un opérateur humain, probablement grognon, crée des configurations statiques - potentiellement à l'aide de scripts - et les déploie via un processus spécial sur tous les serveurs proxy. Ensuite, les proxies commencent à utiliser cette configuration et traitent le plan de données (data plane) avec les paramètres mis à jour.
Figure 3 : Plan de contrôle de maillage de services avancé (Advanced service mesh control plane)
Sur figure 3 montre le « plan de contrôle élargi (control plane) » du maillage de services (service mesh). Il se compose des parties suivantes :
- L'humain (The human): Il y a toujours un humain (j'espère, moins en colère) qui prend des décisions au niveau élevé concernant l'ensemble du système.
- Interface utilisateur du plan de contrôle (Control plane UI): L'humain interagit avec un type d'interface utilisateur pour gérer le système. Cela peut être un portail web, une application en ligne de commande (CLI) ou un autre type d'interface. Grâce à l'interface utilisateur, l'opérateur a accès à des paramètres globaux de configuration du système tels que :
- Gestion des déploiements, bleu/vert (blue/green) et/ou avec un transfert progressif du trafic
- Paramètres d'authentification et d'autorisation
- Spécifications de la table de routage, par exemple, que se passe-t-il lorsque l'application A demande des informations sur « /foo »
- Paramètres du répartiteur de charge, par exemple, délais (timeouts), tentatives (retries), paramètres de rupture de circuit (circuit breaking), etc.
- Planificateur de charges de travail (Workload scheduler): Les services sont lancés sur l'infrastructure via un système de planification/orchestration de type Kubernetes ou Nomad. Le planificateur est responsable du lancement du service avec son proxy local.
- Découverte de service (Service discovery). Lorsque le planificateur lance et arrête des instances de service, il communique l'état de disponibilité au système de découverte de service.
- API de configuration du proxy local (Sidecar proxy configuration APIs) : Les proxys locaux extraient dynamiquement l'état de divers composants système selon le modèle de la « cohérence à terme » (eventually consistent) sans l'intervention de l'opérateur. L'ensemble du système, composé de toutes les instances de services et de proxys locaux actuellement en cours d'exécution, finit par converger vers un seul écosystème. L'API du plan de données (data plane) universel dans Envoy est un exemple de la façon dont cela fonctionne en pratique.
En gros, l'objectif du plan de contrôle (control plane) est d'établir une politique qui sera finalement acceptée par le plan de données (data plane). Des plans de contrôle (control planes) plus sophistiqués retireront davantage de détails aux opérateurs de certains systèmes et exigeront moins de gestion manuelle, à condition qu'ils fonctionnent correctement !..
Plan de données et plan de contrôle. Résumé (Data plane vs. control plane summary)
- Plan de données du maillage de services (Service mesh data plane): touche chaque paquet / requête dans le système. Responsable de la découverte des applications / services, de la vérification de la disponibilité, du routage, de l'équilibrage de charge, de l'authentification / autorisation et de l'observabilité.
- Plan de contrôle du maillage de services (Service mesh control plane): fournit la politique et la configuration pour tous les plans de données fonctionnant au sein du maillage de services. N'interfère pas avec les paquets / requêtes dans le système. Le plan de contrôle transforme tous les plans de données en un système distribué.
État actuel du projet (Current project landscape)
Après avoir compris l'explication ci-dessus, examinons l'état actuel du projet de maillage de services (service mesh).
- Plans de données (Data planes): Linkerd, NGINX, HAProxy, Envoy, Traefik
- Plans de contrôle (Control planes): Istio, Nelson, SmartStack
Au lieu de faire une analyse approfondie de chacune des solutions mentionnées, je vais brièvement aborder certains points qui, à mon avis, causent la plupart des confusions dans l'écosystème en ce moment.
Au début de 2016, Linkerd était l'un des premiers serveurs proxy de la couche de données (data plane) pour les maillages de services (service mesh) et a réalisé un travail fantastique pour accroître la notoriété et l'attention autour du modèle de conception « maillage de services » (service mesh). Environ six mois plus tard, Envoy a rejoint Linkerd (bien qu'il ait travaillé 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 (service mesh).
Istio a été annoncé en mai 2017. Les objectifs du projet Istio sont très similaires à une couche de contrôle étendue (control plane), comme illustré sur figure 3. Envoy pour Istio est le serveur proxy par défaut. Ainsi, Istio est une couche de contrôle (control plane) et Envoy est une couche de données (data plane). En peu de temps, Istio a suscité beaucoup d'intérêt, et d'autres couches de données (data plane) ont commencé à s'intégrer en tant que remplacement d'Envoy (tanto Linkerd que NGINX ont démontré une intégration avec Istio). Le fait qu'une seule couche de contrôle (control plane) puisse utiliser différentes couches de données (data plane) signifie que la couche de contrôle (control plane) et la couche de données (data plane) ne sont pas nécessairement étroitement liées. Un API tel que l'API universelle de la couche de données (data plane) d'Envoy peut servir de pont entre les deux parties du système.
Nelson et SmartStack aident à illustrer davantage la séparation entre la couche de contrôle (control plane) et la couche de données (data plane). Nelson utilise Envoy comme son proxy et construit une robuste couche de contrôle (control plane) d'un maillage de services (service mesh) basé sur la pile HashiCorp, c'est-à-dire Nomad, etc. SmartStack est sans doute l'un des premiers de la nouvelle vague des maillages de services (service mesh). SmartStack forme une couche de contrôle (control plane) autour de HAProxy ou NGINX, montrant la possibilité de dissociation entre la couche de contrôle (control plane) d'un maillage de services (service mesh) et la couche de données (data plane).
L'architecture microservices avec une service mesh attire de plus en plus d'attention (c'est bien !), et de plus en plus de projets et de fournisseurs commencent à travailler dans ce domaine. Au cours des prochaines années, nous verrons de nombreuses innovations tant dans les plans de données (data plane) que dans les plans de contrôle (control plane), ainsi qu'un mélange continu de divers composants. En fin de compte, l'architecture microservices doit devenir plus transparente et presque magique (?) pour l'opérateur.
J'espère que cela devient de moins en moins irritant.
Points clés (Key takeaways)
- Une service mesh se compose de deux parties distinctes : le plan de données (data plane) et le plan de contrôle (control plane). Les deux composants sont obligatoires, et sans eux, le système ne fonctionnera pas.
- Tout le monde est familier avec le plan de contrôle (control plane), et pour le moment, le plan de contrôle (control plane) peut être vous !
- Tous les plans de données (data plane) rivalisent entre eux en termes de fonctionnalités, de performance, de configurabilité et d'évolutivité.
- Tous les plans de contrôle (control plane) rivalisent entre eux en termes de fonctionnalités, de configurabilité, d'évolutivité et de convivialité.
- Un plan de contrôle (control plane) peut contenir les bonnes abstractions et API afin d'utiliser plusieurs plans de données (data plane).
Source : habr.com
