Istio

De nos jours les architectures dîtes micro-services améliorent la capacité des équipes logiciels modernes à fournir des applications à grande échelle.
Cependant la multiplication des micro-services dans nos workloads devient un vrai défi pour maintenir un réseau fiable entre les services. C’est donc de cette problématique que les Services Mesh sont nées.

Les services Mesh vont fournir plusieurs types de fonctionnalités à vos micro-services. Voici la liste non exhaustive des fonctionnalités que vous pouvez retrouver :

• Le Service Discovery,
• Le LoadBalancing,
• L’Authentification,
• etc.

Pourquoi choisir Istio, le service Mesh open source ?

Il faut tout d’abord savoir que Istio est un service Mesh open source, il est entre autre né de la collaboration entre Google, IBM et Lyft.  Celui ci permet de connecter, de surveiller et de sécuriser des micro-services déployés sur site, dans le cloud ou avec des plates-formes d’orchestrations telles que Kubernetes et Mesos.

En revanche, il est important de noter que Kubernetes n’est pas le seul moyen de déployer des micro services. De plus, Istio n’est pas non plus le seul maillage de service, mais les réflexions actuelles tendent à les rendre de plus en plus inséparables.

Pour mieux comprendre ces enjeux je vais vous présenter l’ensemble des fondements d’un Service Mesh, je vous expliquerai aussi comment vous servir d’Istio pour étendre ce modèle.

Qu’est-ce qu’un Service Mesh ?

Avant toute chose, revenons sur le pattern d’architecture micro-services.

Voici les différents avantages que nous pouvons noter pour présenter ce pattern :

• L’isolation des features dans des services indépendants,
• La livraison qui se fait de manière indépendante,
• La facilité de maintien (notamment par micro-service),
• La facilité de test (notamment par micro-service),
• L’efficacité et la rapidité de l’évolutivité,
• L’agilité.

Un Service Mesh se présente sous la forme d’une couche d’infrastructure qui permet à vos API de communiquer entre elles. Il permet également de configurer la manière dont vos API effectuent des actions critiques telles que la découverte de service, l’équilibrage de la charge, le cryptage des données, ainsi que l’authentification et l’autorisation.

Voici, de manière schématisée, à quoi peut ressembler un service Mesh :

Il est aussi important de noter que, par nature, les micro-services permettent la distribution et le déploiement continu d’applications pouvant être complexes et de grande envergure. L’émergence des services Mesh vient justement répondre aux problèmes d’accroissements des complexités que peut avoir une application.

Utiliser un service Mesh vous permettra de ne plus perdre de temps à implémenter certaines briques récurrentes de vos API car il vous fournit par défaut une couche d’abstraction. Voici un exemple de briques que vous n’aurez plus à remplir :

• Design for failure,
• Authentification,
• Monitoring,
• etc.

Cela vous permet de bénéficier alors d’une grande flexibilité. Vous pouvez déplacer vos micro-services à votre guise vers un autre serveur ou un autre cluster, sans même toucher à un bout de code. C’est désormais le service Mesh qui automatisera ces briques techniques pour vous.

Comment Istio fonctionne ?

Plongeons-nous maintenant au coeur du fonctionnement d’Istio. Il faut tout d’abord savoir que l’architecture d’un service Mesh se compose de 2 parties, que sont :

• le Data Plane,
• le Control Plane.

Le Data Plane

Le Data Plane est essentiellement un service proxy qui gère les communications entre les services.

Dans l’exemple ci dessous nous avons une communication classique entre 2 API :

L’idée d’un Data Plane est d’avoir un élément d’infrastructure qui vient se glisser entre les 2 API :

Dans le contexte de Kubernetes, Envoy est injecté en mode side-care entre les plusieurs apis.

Dans Istio, le Data Plane est déployé en tant que proxy Envoy ( un service d’infrastructure conçu pour les applications). Les Data Planes fournissent ainsi des éléments d’observabilité de traçabilité et autres.

Nous pouvons retrouver d’autres services proxy tel que NGINX , HAProxy qui fournissent eux aussi des fonctionnalités de Data Plane. C’est en revanche le proxy Envoy qui s’avère être le plus utilisé, il est en effet devenu très rapidement populaire pour ses architectures micro-services.

Le Control Plane

Le Control Plane supervise, quant à lui, les stratégies et les configurations du Data Plane : il ne gère donc aucune donnée.

Vous pouvez bien entendu exécuter Envoy en tant que proxy autonome sans Data Plane, mais vous risquez de passer à coté de la valeur ajouté d’Istio ! C’est en effet son couplage unique entre Data Plane et Control Plane qui fait de lui le Service Mesh le plus complet.

Les composants du service Mesh Istio

Plusieurs composants permettent une orchestration harmonieuse entre le Control Plane & le Data Plane.

Nous allons nous pencher sur les 3 suivantes :

• Pilot,
• Mixer,
• Citadel.

Pilot

C’est le traffic manager d’istio.Son but étant de configurer les proxys Envoy, responsable de la découverte de service et de routage.

Pilot permet notamment de gérer le contrôle du Traffic, tel que :

• Les règles de Routage,
• La stratégie de Routage,
• Le Rate Limiting.

Pilot permet aussi une gestion de la résilience avec :

• Le Circuit Breaker en cas de panne,
• Le TimeOut;
• Le Retries.

Voici comment nous pouvons schématiser ce service au coeur d’Istio :

Mixer

Mixer fait partie du composant Data Plane, il a la faculté de rassembler les données du proxy Envoy et le flux de trafic entre les services pour faire appliquer les politiques réseaux entre les services.

Mixer travail étroitement avec les proxy Envoy.

Mixer permet de gérer :

• La journalisation,
• Le traçabilité,
• Le monitoring,
• Les Quotas,
• Les APIM (pour API Management),
• D’autres Adapters (comme plugin custom par exemple).

Citadel

Avec Citadel, Istio fournit une couche de sécurité robuste, régie par des règles, pour la gestion d’authentifications et d’informations d’identification entre les proxy Envoy.

Citadel prend en charge les clés et les certificats du Service Mesh.

Devons-nous adopter Istio ?

Comme Kubernetes il y a quelques années, Istio en est encore à ses débuts en matière d’adoption globale. Cela est compréhensible car le concept de Service Mesh est encore relativement nouveau. Cependant de nombreuses entreprises commencent à l’adopter. Certains cloud provider proposent même son utilisation comme un standard.

A la question devons nous adopter Istio je réponds :
testez-le pour mieux comprendre son impact dans une architecture en micro service ! Vous finirez certainement par l’adopter !

Prochainement nous pourrons voir en détail l’utilisation d’Istio au cœur d’une application avec des scénarios concrets comme :

• Son installation,
• Son utilisation dans une application,
• L’utilisation du Circuit Breaker,
• La gestion de la télémétrie.