L’essentiel sur Istio

Au-delà du simple maillage de service

Mais Istio a aussi vocation à aller bien au-delà : le projet open source propose des fonctions intelligentes de routage de trafic, de load balancer, de supervision et de télémétrie, et de sécurité, comme la gestion des accès, l’authentification des utilisateurs et le chiffrement. Bref Istio souhaite former une tour de contrôle pour développer et contrôler des architectures de micro-services.

Istio reprend en fait plusieurs projets mis en commun par les trois membres fondateurs. IBM y a contribué avec Amalgam8, un outil de gestion du routage de trafic programmable qui permet par exemple de tester la résilience des services. De son côté, Google a apporté sa technologie Service Control qui ajoute un système de gestion par règles (policies) en matière de sécurité ainsi qu’un système de télémétrie. Mais la pierre angulaire d’Istio a été apportée par Lyft. En contribuant à Envoy, un proxy maison, la société a fixé une orientation architecturale qui distingue Istio d’autres outils de Service Mesh, comme par exemple Linkerd, hébergé à la Cloud Native Computing Foundation (CNCF).

Envoy (également un projet de la CNCF) est en fait un projet open source de proxy, suffisamment léger pour permettre des déploiements dits « sidecar ». Lorsqu’on déploie Istio sur une architecture en place, il loge des proxies Envoy, au côté de chaque service présent au sein d’un pod Kubernetes par exemple. A l’origine, Istio a en effet été développé pour favoriser l’interconnexion et la gestion des services dans l’orchestrateur de conteneurs.

Avec un tel dispositif, chaque service qui doit se connecter à un autre service entre en contact avec le proxy de ce dernier, précédemment configuré à partir de règles de routage spécifiques. La base d’Istio est que ce sont les proxies qui interagissent, facilitant le contrôle et le monitoring du trafic et la collecte de données précises sur l’état de santé de chaque service.

Une architecture ouverte

Outre Envoy, Istio est composé de 4 autres composants :

• Mixer : ce composant prend en charge les contrôles d’accès aux services, les politiques en matière d’usage ainsi que la collecte des métriques depuis les proxies Envoy.
• Pilot : ce composant fonctionne de pair avec Envoy pour le contrôle et le routage du trafic entre services, et propose des fonctions de découvertes de services pour Envoy. Pilot convertit les règles de routage configurées pour les proxies Envoy et les propagent.
• Citadel : ce composant prend en charge l’authentification des utilisateurs et la gestion des identités pour sécuriser la communication de services à services.
• Galley : ce composant assure des fonctions de gestion de configuration pour Istio.

Envoy et Mixer fonctionnent la main dans la main lorsqu’une requête est envoyée. Envoy contacte Mixer avant chaque requête pour vérifier si les conditions d’exécution sont adéquates et après chaque requête pour lui expédier des données de mesure télémétrique. Le proxy sidecar dispose d’un cache en local de façon à ce qu’un grand nombre de vérifications post-traitement puisse être effectué à partir du cache. De plus, le sidecar bufferise les données de mesure afin de limiter les appels à Mixer – ou les effectue moins fréquemment.

Mixer s’adosse quant à lui à une conception modulaire qui favorise la création de plug-in (adapters) avec lesquels des éditeurs d’outils de monitoring peuvent se raccorder. Datadog a par exemple développé son propre plug-in. Mixer s’interface également aux outils de Sysdig, SolarWinds, ainsi qu’à Google Stackdriver et Amazon CloudWatch.

Istio a également été conçu pour être déployé sur une architecture existante ou pour faciliter les déploiements d’architectures de microservices. Mais en créant une couche d’abstraction en matière de gestion de l’infrastructure, il permet également de faciliter la mise en place de processus DevOps.