Istio : un service qui maille
Développé en Go par Google, IBM et Lyft, Istio est à l’heure actuelle disponible en version 1.4. Ce service mesh permet de répondre au besoin grandissant de gestion des flux dans les architectures microservices. La multiplicité des composants au sein d’une application a de nombreux avantages, notamment l’indépendance de chaque brique. Cela complexifie cependant la mise en réseau de tous ces composants, qui communiquaient, à l’époque des architectures monolithiques, au sein même de l’application.
Qu’est-ce qu’un service mesh ?
Un service mesh est une couche de l’architecture logicielle, dédiée à la gestion et au contrôle des échanges entre les services. Dans le cas d’Istio, cela se présente sous la forme d’un plan de données qui gère le trafic réseau et d’un plan de contrôle qui gère et sécurise le plan de données. C’est donc la combinaison de ces 2 composants, le plan de données et le plan de contrôle, qui permet à Istio de mailler la communication entre les services.
L’architecture
Le plan de données comprend plusieurs éléments :
-Mixer, qui est responsable de la mise en application de la stratégie, de la mesure et de la supervision des données
-Des sidecars proxy, qui gèrent toutes les communications entrantes et sortantes des services (chaque service a son propre sidecar proxy).
Le sidecar proxy utilisé par Istio est Envoy (https://www.envoyproxy.io/). Créé par Lyft pour répondre spécifiquement aux besoins des applications cloud-native, Envoy est open source et il est géré par la CNCF (Cloud Native Computing Fondation).
Le plan de contrôle est lui aussi composé de plusieurs briques
-
Pilot
Traduit toutes les règles de routage en configuration spécifique Envoy et les propage ensuite à tous les sidecars.
-
Galley
Convertit les configurations Istio pour les autres composants du plan de contrôle.
-
Citadel
Gère l’authentification entre les services.
2 exemples de fonctionnalités proposées par Istio
Les disjoncteurs
Si un service est soumis à un trop grand nombre de requêtes, Istio a la possibilité de le disjoncter avant que celui-ci ne s’effondre. Autrement dit, toutes les nouvelles requêtes seront bloquées sans que le service n’ait besoin de les traiter. Cela lui permettra de traiter les demandes sans subir une charge de travail supplémentaire. En effet, un service surchargé augmente souvent son temps de réponse et donc accumule encore plus de requêtes. Cette spirale se termine en général par un arrêt brutal suite à l’effondrement du service. Grâce à ce disjoncteur, le service sera seulement inaccessible le temps de pouvoir absorber le pic de trafic. Lorsqu’il retrouve des temps de réponse acceptables, il est alors de nouveau disponible.
Le blue/green déploiement et AB testing
Lors de la mise en place d’une nouvelle version d’un service, il peut être intéressant de faire cohabiter 2 versions d’un même service afin de s’assurer du bon fonctionnement de la nouvelle version. Istio va pouvoir diriger le flux vers les 2 versions en fonction d’un certain nombre de critères. Il y aura par exemple la possibilité de basculer le trafic vers la nouvelle version en augmentant progressivement le pourcentage de requête ou de cibler une population spécifique. À tout moment, un rollback quasiment instantané permettra de rediriger l’ensemble du trafic vers l’ancienne version. Ces méthodes permettent de sécuriser les mises en production mais peuvent également servir à tester l’adoption de nouvelles fonctionnalités ou encore à comparer les performances de plusieurs versions d’un même service.
Freddy,
Ingénieur pôle Offres & Innovations