Publication d'une session de questions-réponses sur le maillage de services. La session s'est tenue en préparation de l'intensif Slurm sur le maillage de services. Il y a un enregistrement sur Youtube .
Les experts ont répondu aux questions les plus courantes sur la technologie de maillage de services et aux questions des participants à l'événement. Questions clés de la session AMA :
- Qu'est-ce qu'un maillage de services,
- Quand mettre en œuvre
- Istio alternatives,
- Pourquoi Envoy est-il utilisé dans le service mesh et non Nginx.
Marsel Ibraev, STO Slorm, a modéré l'événement, et Alexander Lukyanchenko, chef d'équipe dans l'équipe d'architecture Avito, et Ivan Kruglov, ingénieur logiciel chez Databricks, ont partagé leur expertise.
Les deux ingénieurs ont l'expérience non seulement de travailler avec une implémentation de service mesh spécifique, mais aussi de construire la leur, ce qui est beaucoup plus cool.
Marsel Ibraev : Qu'est-ce qu'un service mesh et quelles tâches résout-il ?
Alexander Lukyanchenko : Je commencerais par la définition de base selon laquelle le service mesh est, avant tout, une approche qui a de nombreuses implémentations spécifiques. Le point principal est que lorsque nous avons une sorte de système distribué qui fonctionne, interagit sur le réseau, nous ajoutons une couche réseau supplémentaire qui nous permet d'ajouter certaines fonctionnalités, toute logique à l'interaction interservices des nœuds du réseau.
En termes plus simples, lorsque nous avons un ensemble de microservices, certains éléments du système, nous ajoutons simplement un serveur proxy spécial à chacun de ces éléments et laissons le trafic entre ces microservices passer par les serveurs proxy. Ainsi, on obtient un large éventail de possibilités différentes de gestion du trafic entre ces services, de collecte de statistiques, de suivi. En fait, il y a beaucoup plus de choses intéressantes sous forme de sécurité, de TLS mutuel, etc. Mais l'essentiel est que le service mesh soit une approche.
Ivan Kruglov :Je suis d'accord avec toi. Nous connaissons tous les microservices. Et beaucoup d'entre nous prennent des monolithes et les ont vus. J'ai une telle observation que lorsque les gens parlent de découper un monolithe, ils imaginent une brique et commencent à la diviser en petits cubes. Ces cubes sont leurs services. Et quand on y pense, on se concentre sur les cubes, en oubliant que la complexité, la logique métier qui était en train de casser le monolithe, n'est allée nulle part. Une partie de la complexité est restée dans les cubes, mais beaucoup de difficultés et de problèmes restent dans l'espace entre ces cubes, dans les flèches, que les gens dessinent généralement avec des lignes fines. Et il y a beaucoup de problèmes.
Par exemple, un simple appel de fonction qui n'était auparavant qu'un appel de fonction devient un appel distant. C'est-à-dire que vous abordez tous les problèmes d'interaction réseau, plus l'autorisation, l'authentification, le traçage, la surveillance - en général, tout un ensemble de caractéristiques. Le service mesh tente de résoudre exactement le problème de la complexité des interactions interservices, ces mêmes flèches qui relient nos cubes (microservices) à vous. C'est ma compréhension du service mesh. Je pense aussi à cela comme Communication-as-a-Service. Certains services qui permettent à vos services d'interagir entre eux, faisant abstraction dans une certaine mesure des problèmes d'interaction en termes de fiabilité, de surveillance et de sécurité.
Marsel Ibraev :Nous pouvons conclure que le service mesh n'est pas une technologie spécifique, mais plutôt une approche qui, dans un sens pratique, est l'ajout de serveurs proxy à chaque microservice. Cela nous permet de gérer de manière plus flexible à la fois le trafic et la sécurité de la connexion entre ces microservices. Il existe sûrement une sorte de plan de contrôle ou de démon conditionnel qui surveille tout cela, gère cela, distribue de manière centralisée les configurations à ces serveurs proxy, etc.
Ivan Kruglov :En général, oui. Cependant, le service proxy est un attribut facultatif. Pour le service mesh, je pense que ce sera une configuration dynamique, car dans un environnement de microservice c'est important quand il est dynamique. Tout change, évolue : augmentez, diminuez. Et à mon avis, le dynamisme est le critère le plus important. Et avec le reste, je suis d'accord.
Alexander Lukyanchenko : Je dirais aussi que Control Plane n'est qu'une des parties du service mesh qui nous permet de le personnaliser, et nous dit d'un point directement à l'ensemble du système de quelles règles nous avons besoin, comment tout doit interagir. Un tel contrôle flexible sur l'ensemble du système à partir d'un seul point.
Marsel Ibraev : Passons à la question suivante : Quand devons-nous réfléchir au moment où nous devons implémenter un maillage de services ? Quels sont les avantages et les inconvénients de son utilisation ? Autant que je sache, le service mesh est une technologie relativement jeune. Dans le sens où seules les grandes entreprises s'autorisent désormais à le mettre en œuvre, elles commencent tout juste à le faire, notamment en Russie. À quel point un profane devrait-il penser au moment d'utiliser le maillage de service. Quels facteurs servent à déterminer cela? Eh bien, qu'est-ce que cela implique, quels sont les avantages et les inconvénients de l'utilisation ?
Alexandre Lukyanchenko :En tout cas, je partirais des besoins et des problèmes. Il convient de rappeler que maintenant cette technologie gagne vraiment en popularité et que beaucoup commencent à la mettre en œuvre ou souhaitent la mettre en œuvre, mais elle résout certains problèmes. L'un des cas d'utilisation très répandus pour la mise en œuvre est l'amélioration de l'observabilité - comprendre comment tous les cubes interagissent en général au sein de notre grand système. Et avec l'aide du service mesh, nous avons la possibilité de le faire de manière unifiée immédiatement et complètement pour l'ensemble du système. C'est l'un des cas de solution.
Ce qu'Ivan a dit à propos de la fiabilité et de la résilience du réseau que nous obtenons lorsque nous passons à une architecture de microservices. C'est aussi l'un des problèmes qui peuvent être résolus à l'aide d'un service mesh, en introduisant des approches telles que Circuit Breaker, des retours automatiques, c'est-à-dire des modèles d'interaction réseau, et tout cela est en dehors de notre logique métier, en dehors de nos cubes. , de manière uniforme pour l'ensemble du système.
Ayant ces problèmes dans notre système, nous pouvons simplement les résoudre en implémentant un service mesh. De toute évidence, la solution à ces cas est un plus, à la fois en termes de simplicité et de spécificités de la manière dont nous pouvons mettre un service mesh dans notre système. Parce que, par exemple, si nous devons mettre en place une sorte de surveillance unifiée dans tout le système, assurez-vous que certaines métriques communes sont collectées à partir de tous les services : pour la latence, les requêtes, les erreurs, etc., cela peut être une tâche vraiment difficile ... Et pas dans un environnement homogène cela peut être difficile à résoudre. Dans le cas du service mesh, nous avons la possibilité de le faire plus facilement en ajoutant ces conteneurs proxy et nous avons la possibilité de tout configurer dans le système de manière unifiée. C'est probablement l'une des caractéristiques clés du service mesh.
J'aime aussi la définition selon laquelle, en fait, un service mesh est une technologie qui pourrait être complètement résolue dans les applications métier, mais en raison de la complexité, nous ne pouvons pas ajouter une logique unifiée à des centaines et des milliers de composants de notre système et obtenir certains fonctionnalité, nous la déplaçons simplement vers un autre niveau d'interaction via ces proxys de service et obtenons toutes ces fonctionnalités, qui pourraient en fait être implémentées dans les applications métier elles-mêmes. Et dans les systèmes hétérogènes, cela s'avère vraiment très utile. C'est un grand avantage.
Parmi les inconvénients, je soulignerais la performance. La mise en œuvre doit évaluer avec précision comment les éléments du système interagissent. Par exemple, il existe des cas assez restreints, mais lorsque nous avons une très grande quantité d'interactions réseau synchrones, par exemple, via le protocole HTTP au sein du système, nous recevons des entrées supplémentaires via chaque proxy de service. Dans la plupart des cas, ce n'est pas un problème, mais il convient de garder à l'esprit lors de l'introduction de cette technologie, de comprendre qu'elle apporte une certaine surcharge à notre système, et nous y ajoutons chaque nœud.
Et le deuxième inconvénient, qui est probablement encore plus audacieux que le premier, est la complexité de la configuration et de la mise en œuvre de ces implémentations qui existent maintenant. Bien que la technologie ne soit plus très jeune, elle n'est toujours pas facile à mettre en œuvre sur un système de grande ou moyenne taille. Cela est dû au fait qu'il existe un grand nombre de possibilités, de grandes configurations d'étalement - le seuil d'entrée et d'introduction de cette technologie dans le système est assez élevé.
Ivan Kruglov : Je vais aussi essayer de répondre à cette question. Je viendrai de loin. Je vais essayer d'expliquer pourquoi j'ai décidé de mettre en place un service mesh dans mon entreprise en 2018. Je parle de Booking.com.
Le problème était que nous avions un certain nombre de services et une bibliothèque qui était responsable de la communication interservices. Elle savait comment émettre des métriques, était capable d'émettre des retours en arrière, c'est-à-dire des modèles de fiabilité, et était capable de découvrir des services. Tout fonctionnait bien, tout semblait aller bien. Mais il y avait deux gros problèmes.
Problème numéro un : j'ai eu 20-30 services. Ils n'étaient pas sous mon contrôle. Ils ont été déployés selon leur calendrier par une équipe située dans d'autres fuseaux horaires, et j'ai besoin de mettre à niveau une version. Et le processus de mise à niveau a pris beaucoup de temps. J'ai dû attendre. Et c'est très long à attendre.
Deuxièmement, nous avons commencé à ce moment-là à passer à une approche plus microservice. Et il était clair que nous avons une seule pile. Sasha a parlé de stacks homogènes et hétérogènes. Traduisons en russe. Une pile homogène, c'est lorsque vous disposez d'une technologie, par exemple Java, et que tous vos services sont en Java. Hétérogène, c'est quand vous avez un zoo. Un service en Python, un en Java, un troisième en Go. Chez Booking.com, nous avons décidé de ne pas miser sur un stack homogène, nous avons décidé de miser sur le fait qu'il y aura beaucoup de stacks. Par conséquent, il était clair qu'une bibliothèque, dans laquelle tout est beau, devrait être réécrite dans 4 à 5 langues potentielles, puis tout cela serait toujours pris en charge. Et il est également souhaitable de les faire tous dans le même ton. Et les métriques pour qu'elles donnent la même chose. Et ils ont également systématiquement mis en œuvre des modèles de fiabilité. En général, il était clair qu'il s'agissait d'une énorme hémorroïde,et par conséquent, nous avons trouvé une solution à ces problèmes en passant à une plate-forme ou à une approche unique, c'est-à-dire en déployant un proxy qui ferait toutes les métriques, modèles et découverte de la même manière, quelle que soit l'application sur laquelle elle est écrite. .
En parlant plus spécifiquement de l'utilisation du service mesh, alors je n'ai pas de réponse qu'à ce stade, il est nécessaire de l'utiliser, mais à ce stade, ce n'est pas nécessaire. Mais en général, plus vous avez de services et plus de langues dans lesquelles ils sont écrits, plus le maillage de services est susceptible de vous aider. Je parle de probabilité, pas de confiance, car là aussi il y a beaucoup de problèmes. Et Sasha en a parlé. Si vos services sont responsables de centaines de millisecondes, eh bien, un proxy vous ajoutera quelques millisecondes - vous ne sentirez pas beaucoup de différence.
Un problème beaucoup plus important est la diffusion de la technologie. Istio a plus d'entités que Kubernetes. C'est-à-dire que c'est plus compliqué. Ils travaillent bien sûr maintenant à la simplification, mais en général, ce sont des technologies distinctes qui doivent être soutenues, pour lesquelles des ressources doivent être allouées. En plus du fait que vous devez l'apprendre vous-même, vous devez dans une certaine mesure former certains de vos développeurs à son utilisation.
Marsel Ibraev : Concernant le surcoût, du point de vue de l'infrastructure, faire tourner un proxy sur chaque service c'est ce que j'ai vu, mais aussi la consommation de RAM. Chaque pod avec nous consomme désormais 50 à 70 Mo de RAM de plus, même au ralenti, si je me souviens bien des métriques que j'ai consultées. Autrement dit, vous devez vous demander si vous en avez vraiment besoin.
Pour résumer, si votre entreprise a un très gros cluster tentaculaire, une grande application tentaculaire avec un tas de microservices, et même écrite dans différentes langues, alors qu'il existe de sérieuses exigences en matière de tolérance aux pannes et de résolution rapide des problèmes, de sorte que si une sorte de l'échec se produit, nous pouvons résoudre rapidement tout cela, l'essentiel est de comprendre rapidement où exactement ce problème est survenu. Comme l'a dit Ivan, il n'y a pas un seul facteur ou un seul argument qui indique que nous devons maintenant implémenter un service mesh. Plus ces arguments s'additionnent, plus vous devriez vous tourner vers le service mesh et préparer un terrain, peut-être déployer sur un cluster de test, creuser plus profondément, voir comment c'est. Bien sûr, il est facilement mis en production, le même Istio.
Ivan Kruglov :C'est déjà le marché. Si vous voulez conquérir le marché, vous maximisez votre clientèle. Et pour cela, vous devez rendre l'installation aussi simple que possible. Par conséquent, tout est optimisé pour cela.
Marsel Ibraev : Oui. La prochaine question que j'aimerais aborder est que si le service mesh est une approche, une méthodologie, alors quels sont les produits spécifiques qui existent actuellement ? Qu'est-ce qui est pertinent ? Et à quoi devez-vous faire attention si une entreprise décide d'essayer un service mesh ?
Alexandre Lukyanchenko :Du point de vue de l'implémentation, il est désormais logique d'essayer différentes implémentations. Si nous parlons de noms spécifiques, alors la solution la plus populaire est maintenant Istio, qui est très puissante dans les campagnes marketing depuis plusieurs années en termes d'ensemble de ses fonctionnalités, essayant d'être implémentée partout. La plupart des gens connaissent probablement exactement Istio. Cette implémentation existe vraiment depuis assez longtemps, a un grand nombre de possibilités, et en principe, après les dernières versions, elle est déjà assez mature. Convient pour une utilisation en production et, en principe, a déjà eu quelques problèmes de base liés aux performances, à l'installation initiale et à la configuration. La personnalisation est simplifiée et la technologie devient plus déployable. Mais il y a quelques autres technologies auxquelles je ferais certainement attention.
Le premier est Console Connect. Il s'agit d'un développement de Hashicorp. Les technologies Hashicorp et leurs outils sont de haute qualité. Au cas où vous auriez déjà quelque chose de leur pile, c'est une bonne histoire à envisager d'inclure leur solution de maillage de services. En termes de nombre de possibilités, ils rattrapent généralement Istio, mais ils le mettent en œuvre de manière plus réfléchie et détaillée, en grande partie du fait que hashicorp a ses propres clients, sur lesquels ils testent d'abord ces produits, puis les publient. -apporter des solutions au public.
Et je soulignerais également Linkerd2. Il a longtemps été appelé Conduit. Cette solution mérite d'être étudiée en termes de fonctionnalités et de performances. Parce qu'il est assez différent des autres, il utilise son propre serveur proxy. Et grâce à cela, il peut offrir une meilleure évolutivité. À cet égard, Envoy-proxy convient parfaitement à presque toutes les implémentations et est utilisé dans les grandes entreprises, y compris la nôtre, et du point de vue des frais généraux, principalement en termes de ressources, combien d'utilisation supplémentaire de temps processeur, de RAM, dans principe, le rapport de par rapport à la consommation de services aux entreprises est acceptable. C'est-à-dire que cette différence concerne uniquement la mise en réseau, la pile réseau, le traitement des demandes et les fonctionnalités réelles qu'Envoy-proxy porte.
En fait, je regarderais sous différents angles trois solutions : Istio, Console Connect et Linkerd2. En fin de compte, il y a de fortes chances que les tâches que vous devez résoudre dans votre système soient toutes accomplies. Laquelle de ces technologies vous convient le mieux dépendra déjà de ce qui vous convient le mieux et de ce que vous préférez. Si nous parlons de la vision, personnellement, il me semble qu'en fin de compte, sinon les gagnants, alors dans une plus large mesure les leaders des solutions de service mesh basées sur Envoy-proxy, simplement parce qu'il gagne maintenant en popularité immense, a un très grand nombre de fonctionnalités prêtes à l'emploi ... Et, très probablement, la majeure partie du maillage de service sera dessus. Mais néanmoins, cela vaut toujours la peine de tout regarder.
Ivan Kruglov :Je suis d'accord avec Alexandre. Istio est le plus grand, le plus populaire, aussi parce que Google est derrière. C'est leur technologie. Le reste n'a pas touché et je ne sais pas. Mais je sais que Hashicorp est axé sur la facilité d'utilisation. Il est logique de regarder là-bas. Et si vous disposez d'un service Discovery ou utilisez Consul, il est également logique de chercher là-bas. Linkerd2 est la troisième version actuellement disponible.
Marsel Ibraev : Pourquoi Envoy est-il utilisé dans le service mesh ? Pourquoi pas des outils plus sophistiqués comme Nginx ou Haproxy qui ont beaucoup de fonctionnalités ? Apparemment, il manque quelque chose. Quelle?
Ivan Kruglov :La principale caractéristique d'un service mesh est le dynamisme. Et c'est précisément cela qui est absent à la fois dans Nginx et Haproxy. Ils sont nés à l'ère d'une configuration plus statique que vous pouviez écrire dans les configurations, décrire, et ils n'ont pas changé ou n'ont pas changé souvent. Dans le maillage de services, des modifications sont apportées toutes les secondes. Envoy et Linkerd ont leurs propres protocoles qui vous permettent d'y pousser dynamiquement la configuration. Vous pouvez écrire un service qui y poussera la configuration via HTTP2. Et ils reconstruisent tous les deux les tables de manière dynamique, fonctionnent très bien. C'est pour moi la principale raison pour laquelle Nginx et Haproxy ne prennent pas racine dans le service mesh.
Alexandre Lukyanchenko :Je suis d'accord que le dynamisme est la caractéristique principale, et il a été inscrit dans la conception d'Envoy. Je dois dire que Haproxy a également eu cette opportunité dans les dernières implémentations, et maintenant ils essaient activement de créer un service mesh sur sa base. Mais il y a un autre point qui est très important, à mon avis. Pour la même raison qu'Envoy a été créé en tant que solution cloud native, il a intégré des modèles en lui-même, tels qu'une distribution assez étendue de métriques sur toutes les interactions réseau. Nginx a ces choses, mais il est réalisé à l'aide de modules et de liaisons supplémentaires, et Envoy-proxy l'a et tout sort de la boîte, disponible par défaut. Et lorsque vous mettez cela dans votre système, vous obtenez immédiatement des données précieuses qui devraient être collectées, testées et affinées à l'aide d'autres technologies.
Marsel Ibraev :En conséquence, il s'avère que si nous avons des services proxy sous la forme d'Envoy, nous avons des opportunités, des fonctionnalités. Et la question suivante est liée à cela. Si nous parlons du service mesh, du fait que c'est vraiment difficile, mais qu'il semble être très cool et cool, j'aimerais maintenant me concentrer sur les fonctionnalités du service mesh ? Sécurité, observabilité, stratégies de déploiement.
Ivan Kruglov :Le terme observabilité est généralement compris comme une combinaison de trois éléments : surveillance (métriques classiques), journalisation, traçage. C'est ce qui vous permet, en tant qu'opérateur de service, de comprendre ce qui se passe ou se passait dans votre service maintenant ou dans le passé. Je dois dire tout de suite que la journalisation n'affecte en rien le service mesh. Autrement dit, dans le contexte du maillage de services, il s'agit de métriques et de traçage.
Pour répondre à cette question, je vais d'abord la reformuler. Qu'apporte l'introduction de cette technologie à l'entreprise ? À mon avis, c'est la cohérence. Laissez-moi vous expliquer maintenant. Imaginez que vous avez, relativement parlant, 100 microservices, et vous devez comprendre comment ils interagissent les uns avec les autres. Vous pouvez instrumenter des services et leur faire cracher des métriques HTTP. Mais très probablement, tout s'avérera incohérent. Quelqu'un rapportera en quelques secondes, quelqu'un rapportera en millisecondes, quelqu'un rapportera une classe d'erreur de 5xx, quelqu'un en publiera 500. Une incohérence apparaît. Par conséquent, la question se pose de construire un tableau de bord unique afin de comprendre ce qui se passe avec votre système. Et tout se transforme en un gros casse-tête. Parce que vos métriques sont appelées différemment, elles sont dans des unités différentes, etc. Avec le service mesh, ce problème est résolu d'un seul coup,parce que vous déployez tout avec un seul Envoy, il crache des métriques du même nom, dans les mêmes unités, avec les mêmes buckets, etc. Un seul tableau de bord est en cours de création, dans lequel vous sélectionnez le service souhaité et voyez une liste de tout ce qui lui arrive.
Le traçage est un peu plus compliqué, car il est construit sur des en-têtes, et ces en-têtes doivent être passés entre l'entrée dans l'application et sa sortie. C'est-à-dire qu'un peu d'instrumentation supplémentaire est nécessaire, mais en général, le résultat est le même. Une topologie vous est présentée et la possibilité de suivre une demande spécifique. Dans une architecture de microservices tentaculaire, comprendre ce qui se passe est un énorme défi. Le plan de contrôle dans le maillage de services est un panneau de contrôle centralisé, vous pouvez donc appliquer certaines politiques de manière centralisée. À partir de la fréquence des tentatives, des délais d'attente. Imaginez que vous avez créé un nouveau service. Et si vous avez correctement configuré les paramètres par défaut, vous obtenez immédiatement la surveillance, le traçage, les nouvelles tentatives, les interruptions, les disjoncteurs prêts à l'emploi - et dans certaines des meilleures implémentations. Vous pouvez pousser des certificats, des stratégies d'accès (par exemple,ce service peut parler à l'un, mais pas à l'autre).
En résumé. La cohérence est lorsque les points de référence pour le contrôle du service apparaissent dans votre architecture Microservice, ce qui est la possibilité d' une gestion centralisée des politiques, paramètres, etc.
Alexander Lukyanchenko: Je voudrais aussi ajouter que , puisque le maillage de service est d'introduire dans l' interaction synchrone entre notre microservices, les possibilités de gestion du trafic entre les services sont infinies. C'est l'occasion d'y faire des déploiements Canary, des déploiements bleu-vert - ces choses qui sont difficiles ou impossibles à faire hors de la boîte, par exemple, dans Kubernetes.
Si nous parlons de capacités d'équilibrage, il existe également un ensemble de capacités très riche en termes de paramètres internes. Il s'agit de divers équilibrages avec des politiques de hachage afin de clouer la requête à certains terminaux, la possibilité d'un même équilibrage de poids, par exemple, la protection de la connexion entre les microservices, le TLS mutuel, qui, contrairement à la configuration manuelle, sont vraiment plus faciles à exploiter, car la gestion des certificats, leur distribution et leur rotation peuvent être effectuées au niveau du service mesh, et les services métier eux-mêmes peuvent même ne pas savoir que l'interaction entre les services s'effectue via une sorte de protocole sécurisé. Cela peut être généralement un point clé, en particulier pour ceux qui travaillent dans un environnement multi-cloud, ayant des instances dans un cloud public et dans un autre, ou, par exemple, des instances étalées entre des centres de données distribués, également des cas,dans laquelle cette technologie est obligatoire pour la mise en œuvre. Et avec l'aide du service mesh, il est simplement possible de résoudre ce problème plus facilement que s'il était implémenté manuellement sans lui.
L'ensemble de ces possibilités est un outil de solution très cool. Il existe également des cas plus restreints, mais ils peuvent s'avérer essentiels. Par exemple, Chaos Engineering pour mettre en œuvre la dégradation de l'interaction, ou, par exemple, la politique. Cela s'avère vraiment être un outil de solution cool. Il existe également des cas plus restreints, mais ils peuvent être essentiels pour combler un besoin spécifique pour une entreprise spécifique.
Marsel Ibraev :Il s'avère, pour résumer, que le service mesh, quelle que soit sa mise en œuvre, représente un outil centralisé unique qui nous permet de mettre en œuvre un certain nombre de fonctionnalités, en particulier, nous avons une surveillance ou une observabilité standardisée uniforme, si l'on parle en termes de le service mesh, nous collectons toutes les métriques nécessaires, le traçage et tout ce dont vous avez besoin. Dans le même temps, nous pouvons résoudre immédiatement le problème de sécurité : nous pouvons créer des politiques de réseau, un cryptage, et nous avons des options très flexibles pour travailler avec le trafic - diverses options d'équilibrage, de déploiement délicat, etc. Cela peut suffire pour penser à la mise en œuvre, surtout sur les gros projets.
Poursuite du thème de la mise en œuvre. Disons nous avons vendu l'idée à l'entreprise et sommes devenus nous-mêmes saturés de cette idée, par quelles étapes les spécialistes doivent-ils passer d'un point de vue technique et organisationnel ? Comment implémenter correctement un service mesh chez soi si on a déjà le même Kubernetes ? Comment implémenter un service mesh sans rien casser ?
Alexandre Lukyanchenko :Ici, je vais vous parler un peu de notre expérience. L'introduction de cette technologie est possible progressivement. Nous pouvons clairement choisir les parties du système sur lesquelles nous déployons actuellement cette technologie, la tester là-bas, examiner son impact sur les mêmes performances, voir si nous obtenons le résultat souhaité, l'ensemble de fonctionnalités souhaité. Et déployez progressivement. Par exemple, Istio permet à Envoy d'être injecté automatiquement dans chaque microservice à l'aide de la technologie webhook qui ajoute un conteneur à notre pod sous le capot. Et on peut clairement dire qu'on veut voir Envoy-proxy dans tel ou tel espace de nom ou Envoy déjà implémenté dans telle ou telle instance. C'est si nous parlons de mise en œuvre en production.
Et si nous parlons d'organisation, vous devez alors comprendre comment le système fonctionne techniquement, comment se passe l'interaction avec les services, de sorte qu'au stade des problèmes, vous puissiez déjà essayer de le comprendre. Et skatez le tout sur le bac à sable. Si vous avez un cluster Kubernetes qui répète la production, mais avec moins de charge, vous pouvez implémenter, rechercher puis accéder au cluster de production. Ici, vous devez réfléchir à toutes les étapes afin de désactiver rapidement ce système en cas de problème. C'est-à-dire qu'en le faisant, vous pouvez immédiatement vous assurer que tout se passe progressivement, y compris pour chaque service. La difficulté du débogage réside dans la compréhension de ce qui se passe réellement à un moment donné, ce qui n'est pas une tâche facile, et afin de récupérer rapidement du point de vue de la mise en œuvre en production, je recommanderais certainement de commencer par un bac à sable, car malgré sa simplicité de haut niveau, la technologie difficilece n'est pas facile à déboguer, et vous devez avoir une compréhension claire de ce qui s'y passe afin de trouver rapidement les problèmes.
:Je suis d'accord. Toi, Sasha, tu as surtout parlé d'Istio. Pour être clair, quand je parle d'un service mesh, je parle d'un maillage auto-écrit. Lorsque nous avons commencé (chez Booking.com), Istio était en version 0.1 et ne voulait en aucun cas le pousser en production, car la technologie était terriblement brute. Et rétrospectivement, Vanya a tout fait correctement. La deuxième raison pour laquelle j'ai décidé d'écrire le mien, car à cette époque il n'y avait pas de service mesh en dehors de Kubernetes. Istio à cette époque avait Kubernetes comme seule plate-forme. Ils le coupent maintenant lentement en dehors de Kubernetes, mais Kubernetes est toujours la pièce maîtresse. C'est là que la configuration est stockée. Et il n'y avait pas de Kubernetes sur Booking.com il y a trois ans, et je devais vivre en dehors de ça. Pour en revenir à la question principale, oui, je suis d'accord avec Sasha que les avantages ici sontqu'il puisse être mis en œuvre progressivement. C'est ce que j'ai fait. Orienté service. Des moins critiques, puis passer à des plus critiques. En conséquence, le dernier service que nous avons déplacé vers le service mesh était le service de recherche, qui a renvoyé un million de RPS par seconde. C'était le service le plus dur de l'entreprise.
Marsel Ibrayev : Pour résumer, nous adhérons simplement à la bonne approche, ne faisons pas de mouvements brusques et, comme l'a dit Alexander, nous ne prenons pas pour argent comptant la simplicité de niveau supérieur, car tout est beaucoup plus compliqué sous le capot. Y a-t-il quelque chose à ajouter sur le service mesh en dehors de Kubernetes : Istio et Linkerd2 ?
Ivan Kruglov :La dernière fois que j'ai regardé Istio, c'était il y a environ un an - et il était dans un état semi-fonctionnel. Je pense qu'il est maintenant dans un état normal. Ils ont ajouté la possibilité d'ajouter à Kubernetes, de déclarer des instances qui sont en dehors du framework Kubernetes. Pourquoi Istio ne pouvait-il pas être étendu à Kubernetes auparavant ? Car Istio s'appuyait sur les primitives Kubernetes : service, endpoints. C'est-à-dire qu'Istio a mené sa découverte à partir de là. Ils ont introduit un concept, à mon avis, cela s'appelle un service virtuel ou une entrée de service, avec lequel vous pouvez déclarer, prescrire que j'ai une sorte d'instance, elle est disponible via une sorte d'adresse IP. Mais si je comprends bien, il est de votre responsabilité de maintenir cette description à jour. Si vous avez un service de fer sur lequel l'adresse IP est clouée, alors tout va bien. Si quelque chose de plus dynamique,alors il faut écrire avec les mains, appuyer avec les mains.
: J'ai compris cette question de cette façon : un service mesh est-il même possible, là où il n'y a pas de technologies Kubernetes. C'est techniquement possible. Parce que Kubernetes n'est qu'un orchestrateur, il existe d'autres solutions. Istio a été conçu à l'origine pour fonctionner pour une variété de solutions, et il y avait un composant qui fait maintenant partie du corps principal de Control Plane appelé Galay. Il était juste en train de convertir divers manifestes en une seule description, ce qu'Istio comprend déjà pour la configuration. Ainsi, nous pourrions le personnaliser pour presque toutes les solutions. Et du point de vue du bare-metal, ou d'une sorte de machines virtuelles, où il n'y a pas d'outils d'automatisation, là, en principe, vous pouvez installer Envoy, écrire des politiques de routage afin que le trafic passe par Envoy. Mais voici la question du profit de cela et de ce que nous voulons obtenir des fonctionnalités. Il est techniquement possible de mettre n'importe où,la seule question est la facilité d'utilisation et la nécessité de cette solution.
:Soit dit en passant, pour que les collègues comprennent, Envoy est l'un des éléments clés, l'un des deux composants clés de tous les maillages de services modernes. Il a été créé par Lyft. Leur maillage de service était très conditionnel. Ils ont configuré leurs envoyés via des fichiers de configuration. Et ce n'est que plus tard qu'ils ont développé un plan de contrôle auto-écrit. D'ailleurs, l'écriture d'un plan de contrôle n'est pas si difficile. Il y a un protocole clairement déclaré. Et il existe des développements de modèles, certaines liaisons qui vous permettent de créer votre propre plan de contrôle. En fait, sur les implémentations actuelles, la lumière n'a pas convergé comme un coin, bien sûr, ils ont beaucoup de fonctionnalités et un support communautaire, mais en général, si vous avez besoin de fonctionnalités spécifiques que vous ne pouvez pas trouver dans ce qui est, alors il y a une possibilité d'écrire le vôtre. Bien sûr, c'est un certain surcoût, assez sérieux,mais il y a une possibilité - la technologie est ouverte, les protocoles sont tous décrits. Si nous considérons la question de savoir si un service mesh est possible en dehors de Kubernetes, au sens large, oui, c'est possible, il n'y a pas de restrictions. Plus précisément, est-il possible d'étirer Istio en dehors de Kubernetes, ou Consul de s'étendre en dehors de Kubernetes, comme on dit, ça dépend. Plus on avance, plus cela devient possible. Chez Istio, je pense que ça peut être assez génial maintenant. Consul Connect, à mon avis, est entré dans cette zone sans Kubernetes. Par conséquent, il devrait fonctionner hors de la boîte. Je pense que dans Consul Connect, tout est lié à Consul Service Discovery. Si vos services sont visibles dans leur Discovery, ils le seront également dans le service mesh.il n'y a aucune restriction. Plus précisément, est-il possible d'étirer Istio en dehors de Kubernetes, ou Consul de s'étendre en dehors de Kubernetes, comme on dit, ça dépend. Plus on avance, plus cela devient possible. Chez Istio, je pense que ça peut être assez génial maintenant. Consul Connect, à mon avis, est entré dans cette zone sans Kubernetes. Par conséquent, il devrait fonctionner hors de la boîte. Je pense que dans Consul Connect, tout est lié à Consul Service Discovery. Si vos services sont visibles dans leur Discovery, ils le seront également dans le service mesh.il n'y a aucune restriction. Plus précisément, est-il possible d'étirer Istio en dehors de Kubernetes, ou Consul de s'étendre en dehors de Kubernetes, comme on dit, ça dépend. Plus on avance, plus cela devient possible. Chez Istio, je pense que ça peut être assez génial maintenant. Consul Connect, à mon avis, est entré dans cette zone sans Kubernetes. Par conséquent, il devrait fonctionner hors de la boîte. Je pense que dans Consul Connect, tout est lié à Consul Service Discovery. Si vos services sont visibles dans leur Discovery, ils le seront également dans le service mesh.Je suis entré dans cette zone sans Kubernetes. Par conséquent, il devrait fonctionner hors de la boîte. Je pense que dans Consul Connect, tout est lié à Consul Service Discovery. Si vos services sont visibles dans leur Discovery, ils le seront également dans le service mesh.Je suis entré dans cette zone sans Kubernetes. Par conséquent, il devrait fonctionner hors de la boîte. Je pense que dans Consul Connect, tout est lié à Consul Service Discovery. Si vos services sont visibles dans leur Discovery, ils le seront également dans le service mesh.
Marsel Ibrayev : En haut, nous avons maintenant une question d'Anton, qui demande ce qui sera sur le service mesh intensif. Oui, nous prévoyons d'organiser une formation intensive en ligne sur le sujet du maillage de services du 19 au 21 mars. (NDLR : le premier intensif réussi, le deuxième intensif est prévu du 24 au 26 septembre 2021.)Tout cela sera traité par nos experts. Ivan Kruglov est un chef de pratique. Tous nos programmes éducatifs sont issus de la pratique, nous y accordons donc une grande attention. Et Alexander Lukyanchenko sera le conférencier de l'intensif. Il n'y aura pas assez de la théorie d'un tel capitaine. Pour la plupart, nous nous concentrerons sur la pratique, sur l'application pratique. Allons tout de suite installer le service mesh, nous allons tout faire en utilisant Istio comme exemple. Installons, découvrons-le, exécutons-le, découvrons-le avec des abstractions, passons directement aux fonctionnalités tactiles, aux stratégies de déploiement, au multicluster, au mTLS, à l'ingénierie du chaos, etc. Nous allons certainement toucher de nos propres mains tout ce que nous avons dans le concept de service mesh, et à la fin, vous recevrez des connaissances et des compétences qui vous aideront à l'avenir à faire et à mettre en œuvre tout cela par vous-même. Format d'apprentissage, en direct, en Zoom.
C'était la première partie de la transcription de la session AMA. Une suite avec des questions supplémentaires des participants de l'événement est déjà en préparation, nous publierons bientôt. Quel est le problème de maillage de services qui vous préoccupe ?