Une courte histoire sur les avantages et les inconvénients des microservices, le concept Service Mesh et les outils Google qui vous permettent d'exécuter des applications de microservices sans vous boucher la tête avec des paramètres infinis de politiques, d'accès et de certificats et de trouver rapidement des erreurs qui ne se cachent pas dans le code, mais dans la logique du microservice.
L'article est basé sur le
rapport de Craig Box lors de notre conférence DevOops 2017. La vidéo et la traduction du rapport sont en cours.
Craig Box (Craig Box,
Twitter ) - DevRel de Google en charge des microservices et des outils Kubernetes et Istio. Son histoire actuelle concerne la gestion des microservices sur ces plateformes.
Commençons par un concept relativement nouveau appelé Service Mesh. Ce terme est utilisé pour décrire le réseau de microservices en interaction qui composent l'application.
À un niveau élevé, nous voyons le réseau comme un canal qui déplace simplement les bits. Nous ne voulons pas nous en préoccuper ni, par exemple, des adresses MAC dans les applications, mais nous nous efforçons de penser aux services et aux connexions dont ils ont besoin. Si vous regardez du point de vue de l'
OSI , alors nous avons un réseau de troisième niveau (avec les fonctions de détermination de la route et de l'adressage logique), mais nous voulons penser en termes de septième (avec la fonction d'accès aux services de réseau).
À quoi devrait ressembler un véritable réseau de septième niveau? Peut-être que nous voulons voir quelque chose comme une trace de trafic autour des services problématiques. Pour que vous puissiez vous connecter au service, et en même temps, le niveau du modèle a été élevé à partir du troisième niveau. Nous voulons avoir une idée de ce qui se passe dans le cluster, trouver des dépendances involontaires, découvrir les causes profondes des échecs. Nous devons également éviter les frais généraux inutiles, par exemple, la connexion avec une latence élevée ou la connexion à des serveurs avec un cache froid ou pas complètement réchauffé.
Nous devons être sûrs que le trafic entre les services est protégé contre les attaques triviales. L'authentification TLS mutuelle est requise, mais sans intégrer les modules appropriés dans chaque application que nous écrivons. Il est important de pouvoir contrôler ce qui entoure nos applications non seulement au niveau de la connexion, mais également à un niveau supérieur.
Service Mesh est une couche qui nous permet de résoudre les problèmes ci-dessus dans un environnement de micro-service.
Monolith et microservices: avantages et inconvénients
Mais d'abord, nous nous demandons, pourquoi devrions-nous résoudre ces problèmes? Comment avons-nous fait le développement de logiciels auparavant? Nous avions une application qui ressemblait à quelque chose comme ça - comme un monolithe.
C'est super: tout le code est bien visible. Pourquoi ne pas continuer à utiliser cette approche?
Oui, car le monolithe a ses propres problèmes. La principale difficulté est que si nous voulons reconstruire cette application, nous devons redéployer chaque module, même si rien n'a changé. Nous sommes obligés de créer une application dans la même langue ou dans des langues compatibles, même si différentes équipes y travaillent. En fait, les pièces individuelles ne peuvent pas être testées indépendamment les unes des autres. Il est temps de le changer, il est temps pour les microservices.
Nous avons donc divisé le monolithe en plusieurs parties. Vous remarquerez peut-être que dans cet exemple, nous avons supprimé certaines des dépendances inutiles et cessé d'utiliser les méthodes internes appelées à partir d'autres modules. Nous avons créé des services à partir des modèles utilisés précédemment, créant des abstractions dans les cas où nous devons maintenir l'état. Par exemple, chaque service doit avoir un état indépendant afin que lorsque vous y accédez, vous n'ayez pas à vous soucier de ce qui se passe dans le reste de notre environnement.
Quel est le résultat?
Nous avons quitté le monde des applications gigantesques pour obtenir ce qui est vraiment génial. Nous avons accéléré le développement, cessé d'utiliser des méthodes internes, créé des services et maintenant nous pouvons les faire évoluer indépendamment, agrandir le service sans avoir à consolider tout le reste. Mais quel est le prix du changement que nous avons perdu?
Nous avons eu des appels fiables dans les applications parce que vous avez simplement appelé une fonction ou un module. Nous avons remplacé l'appel de confiance à l'intérieur du module par un appel de procédure distante non fiable. Mais le service de l'autre côté n'est pas toujours disponible.
Nous étions en sécurité, en utilisant le même processus à l'intérieur de la même machine. Nous nous connectons maintenant à des services qui peuvent se trouver sur différentes machines et sur un réseau non approuvé.
Dans la nouvelle approche sur le réseau, la présence d'autres utilisateurs qui tentent de se connecter aux services est possible. Les retards ont augmenté et, en même temps, leurs capacités de mesure ont diminué. Maintenant, nous avons des connexions étape par étape dans tous les services qui créent un appel de module, et nous ne pouvons plus simplement regarder l'application dans le débogueur et découvrir exactement ce qui a causé l'échec. Et ce problème doit être en quelque sorte résolu. De toute évidence, nous avons besoin d'un nouvel ensemble d'outils.
Que peut-on faire?
Il existe plusieurs options. Nous pouvons prendre notre application et dire que si
RPC ne fonctionne pas la première fois, vous devriez réessayer, puis encore et encore. Attendez un peu et réessayez ou ajoutez Jitter. Nous pouvons également ajouter des traces d'entrée-sortie pour dire que l'appel a commencé et s'est terminé, ce qui pour moi équivaut à un débogage. Vous pouvez ajouter une infrastructure pour fournir une authentification des connexions et enseigner à toutes nos applications comment travailler avec le chiffrement TLS. Nous devrons prendre en charge le contenu des équipes individuelles et garder constamment à l'esprit les différents problèmes pouvant survenir dans les bibliothèques SSL.
Maintenir la cohérence sur plusieurs plates-formes est une tâche ingrate. Je voudrais que l'espace entre les applications devienne raisonnable, afin qu'il y ait une possibilité de suivi. Nous devons également pouvoir modifier les configurations au moment de l'exécution afin de ne pas recompiler ou redémarrer les applications pour la migration. Ces liste de souhaits et implémentent le service Mesh.
Isstio
Parlez d'
Istio .
Istio est un cadre complet pour connecter, gérer et surveiller l'architecture de microservices. Istio est conçu pour fonctionner au-dessus de Kubernetes. Lui-même ne déploie pas le logiciel et ne tient pas à le rendre disponible sur les machines que nous utilisons à cet effet avec des conteneurs dans Kubernetes.
Sur la figure, nous voyons trois sections différentes des machines et des blocs qui composent nos microservices. Nous avons un moyen de les regrouper en utilisant les mécanismes fournis par Kubernetes. Nous pouvons cibler et dire qu'un groupe spécifique, qui peut avoir une mise à l'échelle automatique, est attaché à un service Web ou peut avoir d'autres méthodes de déploiement, contiendra notre service Web. Dans ce cas, nous n'avons pas besoin de penser aux machines, nous fonctionnons en termes de niveau d'accès aux services réseau.
Cette situation peut être représentée sous forme de diagramme. Prenons un exemple lorsque nous avons un mécanisme qui effectue un traitement d'image. L'utilisateur de gauche est le trafic qui nous parvient dans le microservice.
Pour accepter le paiement de l'utilisateur, nous avons un microservice de paiement distinct qui appelle une API externe située en dehors du cluster.
Pour traiter la connexion des utilisateurs, nous fournissons un microservice d'authentification, et il a à nouveau des états stockés en dehors de notre cluster dans la
base de données Cloud SQL .
Que fait Istio? Istio améliore Kubernetes. Vous l'installez à l'aide d'une fonction alpha dans Kubernetes appelée Initializer. Lorsque vous déployez le logiciel, kubernetes le remarquera et nous demandera si nous voulons changer et ajouter un autre conteneur à l'intérieur de chaque kubernetes. Ce conteneur gérera les chemins et le routage, soyez au courant de tous les changements d'application.
Voilà à quoi ressemble le circuit avec Istio.
Nous avons des machines externes qui fournissent des procurations entrantes et sortantes pour le trafic dans un service particulier. Nous pouvons décharger les fonctions dont nous avons déjà parlé. Nous n'avons pas besoin d'enseigner à l'application comment effectuer la télémétrie ou le traçage à l'aide de TLS. Mais nous pouvons ajouter d'autres choses à l'intérieur: interruption automatique, limitation de vitesse,
libération des canaris .
Tout le trafic passera désormais par des serveurs proxy sur des machines externes, et non directement vers les services. Kubernetes fait tout sur la même adresse IP. Nous pourrons intercepter le trafic qui irait aux services frontaux ou terminaux.
Le proxy externe utilisé par Istio s'appelle
Envoy .
Envoy est en fait plus âgé qu'Istio, il a été développé chez Lyft. Travaille en production depuis plus d'un an, lançant l'ensemble de l'infrastructure des microservices. Nous avons choisi Envoy pour le projet Istio en collaboration avec la communauté. Ainsi, Google, IBM et LYFT sont les trois sociétés qui y travaillent encore.
Envoy est écrit en C ++ 11. Il est en production depuis plus de 18 mois avant de devenir un projet open source. Cela ne prendra pas beaucoup de ressources lorsque vous le connecterez à vos services.
Voici quelques choses que l'Envoy peut faire. Il s'agit de la création d'un serveur proxy pour HTTP, y compris HTTP / 2 et des protocoles basés sur lui, tels que gRPC. Il peut également transmettre à d'autres protocoles au niveau binaire. Envoy contrôle votre zone d'infrastructure afin que vous puissiez rendre votre pièce autonome. Il peut gérer un grand nombre de connexions réseau avec de nouvelles tentatives et attendre. Vous pouvez définir un certain nombre de tentatives de connexion au serveur avant d'arrêter l'appel et transmettre des informations à vos serveurs auxquelles le service ne répond pas.
Pas besoin de vous soucier de recharger l'application pour y ajouter une configuration. Vous vous y connectez simplement à l'aide d'une API très similaire à kubernetes et modifiez la configuration lors de l'exécution.
L'équipe Istio a apporté une grande contribution à la plate-forme UpStream Envoy. Par exemple, une alerte d'erreur d'injection. Nous avons permis de voir comment se comporte l'application en cas de dépassement du nombre de requêtes pour l'objet qui a échoué. Et également implémenté les fonctions d'affichage graphique et de séparation du trafic afin de gérer les cas où un déploiement canari est utilisé.
La figure montre à quoi ressemble l'architecture du système Istio. Nous ne prendrons que deux microservices mentionnés précédemment. En fin de compte, dans le diagramme, tout est très similaire à un réseau défini par logiciel. À partir du serveur proxy Envoy, que nous avons déployé avec les applications, le trafic est transféré à l'aide de tables IP dans l'espace de noms. Le panneau de contrôle est responsable de la gestion de la console, mais il ne traite pas le trafic lui-même.
Nous avons trois composantes. Pilot, qui crée la configuration, examine les règles qui peuvent être modifiées à l'aide de l'API pour le panneau de configuration Istio, puis met à jour Envoy pour qu'il se comporte comme un service de découverte de cluster. Istio-Auth sert d'autorité de certification et transmet les certificats TLS aux mandataires. L'application ne nécessite pas de SSL, ils peuvent se connecter via HTTP et les mandataires géreront tout cela pour vous.
Mixer traite les demandes pour vous assurer que vous respectez la politique de sécurité, puis transmet les informations de télémétrie. Sans apporter de modifications à l'application, nous pouvons voir tout ce qui se passe à l'intérieur de notre cluster.
Avantages sociaux chez Istio
Parlons donc plus en détail des cinq choses que nous obtiendrons d'Istio. Tout d'abord, pensez à
la gestion du trafic . Nous pouvons séparer le contrôle du trafic de la mise à l'échelle de l'infrastructure, donc plus tôt nous pourrions faire quelque chose comme 20 instances de l'application et 19 d'entre elles seront sur l'ancienne version, et une sur la nouvelle, c'est-à-dire que 5% du trafic sera sur la nouvelle version. Avec Istio, nous pouvons déployer n'importe quel nombre d'instances dont nous avons besoin, tout en indiquant le pourcentage de trafic à envoyer aux nouvelles versions. Une simple règle de séparation.
Tout peut être programmé à la volée en utilisant des règles. Envoy sera mis à jour périodiquement à mesure que la configuration change, ce qui n'entraînera pas de pannes de service. Étant donné que nous travaillons au niveau de l'accès aux services réseau, nous pouvons afficher les packages, et dans ce cas, il est possible d'accéder à l'agent utilisateur, qui est situé au troisième niveau du réseau.
Par exemple, nous pouvons dire que tout trafic provenant de l'iPhone suit une règle différente, et nous allons diriger une certaine fraction du trafic vers la nouvelle version, que nous voulons tester pour un appareil spécifique. Le microservice d'appel interne peut déterminer à quelle version spécifique il doit se connecter et vous pouvez le transférer vers une autre version, par exemple 2.0.
Le deuxième avantage est la
transparence . Lorsque vous avez une vue à l'intérieur du cluster, vous pouvez comprendre comment elle est créée. Nous n'avons pas besoin de créer des outils de métriques dans le processus de développement. Les métriques sont déjà présentes dans chaque composant.
Certains estiment qu'il suffit de conserver un journal pour la surveillance. Mais en fait, tout ce dont nous avons besoin, c'est d'avoir un ensemble universel d'indicateurs pouvant être transmis à tout service de surveillance.
Voici à quoi ressemble la barre d'outils Istio créée à l'aide du service Prometheus. N'oubliez pas de le déployer à l'intérieur du cluster.
Dans l'exemple, la capture d'écran montre un certain nombre de paramètres surveillés spécifiques à l'ensemble du cluster. Des choses plus intéressantes peuvent être déduites, par exemple, quel pourcentage d'applications donne plus de 500 erreurs, ce qui implique un échec. Le temps de réponse est agrégé dans toutes les instances de service appelant et répondant au sein du cluster; cette fonctionnalité ne nécessite pas de paramètres. Istio sait ce que Prometheus prend en charge et il sait quels services sont disponibles dans votre cluster, donc Istio-Mixer peut envoyer des métriques à Prometheus sans aucun paramètre supplémentaire.
Voyons comment cela fonctionne. Si vous appelez un service spécifique, le service proxy envoie des informations sur cet appel à Mixer, qui capture des paramètres tels que le temps d'attente pour la réponse, l'état du code et IP. Il les normalise et les envoie à tous les serveurs que vous avez configurés. Surtout pour afficher les principaux indicateurs, il y a le service Prometheus et les adaptateurs FLUX DB, mais vous pouvez également écrire votre propre adaptateur et afficher les données dans n'importe quel format pour toute autre application. Et vous n'avez rien à changer dans l'infrastructure si vous souhaitez ajouter une nouvelle mesure.
Si vous souhaitez effectuer des recherches plus approfondies, utilisez le
système de suivi distribué
Zipkin . Les informations sur tous les appels acheminés via Istio-Mixer peuvent être envoyées à Zipkin. Vous y verrez toute la chaîne des appels de microservices lorsque vous répondez à l'utilisateur et trouverez facilement un service qui retarde le temps de traitement.
Au niveau de l'application, il n'est pas nécessaire de s'inquiéter de créer une trace. Envoy lui-même transmet toutes les informations nécessaires au Mixer, qui les envoie à la trace, par exemple, à Zipkin, à la
trace stackdriver de Google ou à toute autre application utilisateur.
Parlons de
tolérance aux pannes et d'efficacité .
Des délais d'attente entre les appels de service sont nécessaires pour tester la santé, tout d'abord, des équilibreurs de charge. Nous introduisons des erreurs dans cette connexion et voyons ce qui se passe. Prenons un exemple. Supposons qu'il existe une connexion entre le service A et le service B. Nous attendons une réponse du service vidéo pendant 100 millisecondes et ne donnons que 3 tentatives si le résultat n'est pas reçu. En substance, nous allons le prendre pendant 300 millisecondes avant qu'il ne signale une tentative de connexion infructueuse.
De plus, par exemple, notre service de film devrait examiner la cote du film via un autre microservice. La note a un délai d'expiration de 200 millisecondes et deux tentatives d'appel sont données. L'appel d'un service vidéo peut vous faire attendre 400 millisecondes si le nombre d'étoiles est hors de portée. Mais, nous nous souvenons, après 300 ms, le service de cinéma signalera qu'il est inactif et nous ne connaîtrons jamais la véritable cause de l'échec. L'utilisation de délais d'attente et le test de ce qui se passe dans ces cas est un excellent moyen de trouver toutes sortes de bogues intelligents dans votre architecture de microservice.
Voyons maintenant ce qui est efficace. L'équilibreur kubernetes lui-même n'agit qu'au niveau de la quatrième couche. Nous avons inventé un constructeur d'entrée pour l'équilibrage de charge de la deuxième couche à la septième. Istio est implémenté comme un équilibreur pour la couche réseau avec accès aux services réseau.
Nous effectuons le déchargement TLS, nous utilisons donc un protocole SSL moderne et bien dopé dans Envoy, vous n'avez donc pas à vous soucier des vulnérabilités.
Un autre avantage d'Istio est la
sécurité .
Quelles sont les fonctionnalités de sécurité de base d'Istio? Le service Istio-Auth fonctionne dans plusieurs directions. Il utilise un cadre public et un ensemble de normes d'authentification pour les services
SPIFFE . Si nous parlons de flux de trafic, nous avons une autorité de certification Istio qui émet des certificats pour les comptes de service que nous exécutons à l'intérieur du cluster. Ces certificats sont conformes à la norme SPIFFE et sont distribués par Envoy à l'aide du mécanisme de sécurité kubernetes. Envoy utilise des clés pour l'authentification TLS bidirectionnelle. Ainsi, les applications backend reçoivent des identifiants sur la base desquels il est déjà possible d'organiser une politique.
Istio gère lui-même les certificats racine afin que vous ne vous inquiétiez pas des dates de révocation et d'expiration. Le système répondra à la mise à l'échelle automatique, donc en introduisant une nouvelle entité, vous obtenez un nouveau certificat. Aucun réglage manuel. Vous n'avez pas besoin de configurer un pare-feu. Les utilisateurs utiliseront la stratégie réseau et kubernetes pour implémenter des pare-feu entre les conteneurs.
Enfin, l'
application des politiques . Mixer est un point d'intégration avec des backends d'infrastructure que vous pouvez étendre avec Service Mesh. Les services peuvent facilement se déplacer au sein d'un cluster, être déployés dans plusieurs environnements, dans le cloud ou localement. Tout est conçu pour le contrôle opérationnel des appels qui transitent par Envoy. , , . , - 20 . 20 , .
, , , , ICL . , , , , . , Mixer , . .
, Istio? . . , . , .
Istio
Istio kubernetes, , , 1.7 . - kubernetes. Google Container Engine Alpha clusters. , .
Istio — github. 0.2. 0.1 kubernetes. 0.2 kubernetes. , . Envoy , . Istio ,
Cloud Foundry .
. Google Container Engine 1.8 -, Istio — .
, 14 DevOops 2018 (): , .