Istio & Service Mesh – Contrôlez et tunez les flux entre vos micro services

Aujourd’hui les systèmes d’informations deviennent de plus en plus complexes, ne cessent d’évoluer. Les organisations dans les entreprises se transforment et les équipes deviennent de plus en plus pluridisciplinaires. Les périmètres de responsabilité des équipent tendent à se préciser et il est désormais dans la norme qu’une équipe devienne responsable d’un ou plusieurs produits du développement à la mise en production. En lien avec cette nouvelle organisation humaine, une nouvelle organisation technique tends à suivre les mêmes règles avec une individualisation des processus et un périmètre de responsabilité défini de la matière. Une solution à cette transformation est le passage à une architecture micro services et l’attribution de la responsabilité d’un ou plusieurs micro service à une équipe.

La granularité du découpage en micro service va dépendre de la taille des équipes et de l’organisation d’une entreprise cependant la même conclusion se pose : On passe de un Monolithe à plusieurs micro services. Plus d’éléments dit plus de configuration, plus de sécurisation, plus de supervisions, plus de points pouvant amener des problèmes et donc de nouvelles procédures à connaitre. Comment sécuriser le run de mes applications et palier les incidents potentiels ?

Le concept de Service Mesh est un moyen de répondre à ces problématiques. Plongez avec moi à la découverte d’Istio.

Sommaire

• Page 1 : Qu’est ce qu’un service mesh ? Quels sont les apports ?
• Page 2 : Adapter un projet existant pour l’intégrer dans un service mesh
• Page 3 : LoadBalancing – Canary release et A/B testing pour tous
• Page 4 : Circuit Breaker – Fail fast and gracefuly
• Page 5 : Retry & Timeout
• Page 6 : Fault Injection, fiabilisez vos chaines d’appels
• Page 7 : Istio Security – Sécurisation des échanges de votre service mesh
• Page 8 : Tracing – Visualisez une chaine d’appel
• Page 9 : Conclusion

Qu’est ce qu’un service mesh ?

Un Mesh est un maillage de service pour traduire littéralement. Un micro service A peut avoir besoin de consommer un micro service B ainsi qu’un micro service C qui a son tour pourra avoir besoin d’un micro service D. Avec cet exemple nous avons déjà un maillage de service sur un seul cas d’utilisation. Plus le nombre de cas d’utilisation augmente, plus vous allez avoir d’interactions entre micro services.

Le pattern de service mesh est une couche d’infrastructure qui va permettre de contrôler la façon dont différentes briques partagent des données. La centralisation du paramétrage sera effectuée sur un control plane et la mise en place et le respect de ces règles sera porté par un data plane.

Les apports d’Istio et Service Mesh vis à vis de Kubernetes

Pour rappel, Kubernetes permet l’ordonnancement de conteneurs, encapsulés dans des « Pods ». Dans votre cycle projet, vous allez donc créer une image docker de votre matière applicative. Comme tout conteneur, vous pourrez y ajouter un certain nombre d’éléments comme une configuration réseau, un accès à des volumes partagés etc. Cet ensemble de configuration est défini dans un descriptif de déploiement au format Yaml et permet à Kubernetes de savoir comment déployer votre application.

Kubernetes permet déjà de gérer plusieurs éléments d’une configuration réseau entre application. La notion de Service Kubernetes vous permet d’exposer vos pods à l’intérieur de votre cluster. Ainsi, si vous avez trois instances d’un service de récupération de compte, Kubernetes se charge de repartir les appels à votre service entre ces trois instances et le service permet aux autres applications d’avoir un seul point d’entrée. Lorsqu’un service est déployé, le DNS interne est mis à jour et permet a toute matière applicative d’y accéder par son nom. Un Load Balancing est d’origine disponible à travers les objets Service qui sont en chapeau de vos instances. Des politiques de sécurité sont également disponibles pour contraindre l’accès à un service. Istio améliore certains points présents et permet d’aller plus loin.

Envoy au centre de vos pods

Le fonctionnement d’Istio repose sur une brique transverse qui va porter l’ensemble de la configuration souhaitée ainsi que sur des « sidecar » injectés dans les pods de vos applications. Ces sidecars sont des proxy tournant sur le logiciel opensource Envoy. Chaque sidecar est mis à jour par la brique transverse Istio et prend en charge chaque appel réseau depuis et vers votre matière applicative. Enfin, votre matière applicative n’a pas besoin de configuration particulière. Le sidecar Envoy s’occupe d’altérer la table de routage de votre pod afin de rediriger les flux et appliquer la configuration réseau souhaitée.

Gestion du trafic entre services

Comme indiqué dans le paragraphe précédent, Istio reprend des éléments disponibles dans Kubernetes et en ajoute d’autre. La partie concernant le trafic management va permettre d’une part d’effectuer de la redirection de flux et d’autre part d’ajouter de la tolérance à la panne. Avec Istio vous pourrez configurer :

• Load Balancing manuel sur une route lors par exemple du déploiement d’une nouvelle version afin de graduellement migrer vos clients
• Circuit Breaker sur votre service afin d’éviter les timeouts sur des services indisponibles
• Politique de Retry afin de palier les indisponibilités ponctuelles du réseau
• Un timeout personnalisé en fonction d’une route
• Injection d’erreur pour tester la résilience d’une application

Sécurité

Lorsque vous confiez à Istio la gestion d’un namespace celui-ci va injecter dans le pod de votre application un proxy comme le montre le schéma plus haut. Par défaut, les sidecars permettent un trafic en clair et un trafic chiffré de sorte à ce que les services puissent continuer à communiquer entre eux, qu’ils soient gérés par Istio ou non. Cependant, ce comportement peut être changé. Dès l’activation du Mutual TLS les services hors du Service Mesh ne pourront plus communiquer directement avec ceux à l’intérieur. La couche Security d’Istio apporte en supplément :

• Des politiques d’authentification
  • De service à service (via mTLS)
  • Utilisateurs à services via JWT avec n’importe quel fournisseur d’identité
• Politiques d’autorisation
  • Qui à le droit ou l’interdiction de contacter mon service
  • Matching de requête en fonction de
    • La provenance, namespace, IP, principal
    • La destination, namespace, path de l’opération, méthode HTTP, port…
    • Condition de déclenchement, via une valeur dans un header par exemple
• Secure Naming
  • Un service peut etre exécuté par un serveur en particulier, protège du « hijacking » de flux réseau

Monitoring

La multiplication des micro services, de leur version et du nombre de leur instance rend difficile le monitoring réseau. Lors de l’installation d’Istio vous retrouverez souvent d’autres outils :

• Kiali : Visualisation de votre service mesh et des flux temps réel entre les différents services
• Jaeger : Outil de tracing permettant déterminer le chemin d’un appel réseau en s’appuyant sur les headers HTTP Opentrace
• Grafana : Outil permettant de créer des graphe et livré avec des graphes pré configuré pour avoir des statistiques sur le service mesh comme le nombre d’opération par seconde, les codes HTTP, taille des requêtes/réponses…
• Prometheus permettant la création de dashboards personnalisés et l’envoi d’alerte en fonction de seuils de déclenchements

Nous allons dans les pages suivantes aborder l’adaptation d’un projet déployé sur Kubernetes pour fonctionner avec Istio et configurer les différents éléments énumérés sur cette page.

L’ensemble des bouts de code présentés dans la suite a été testé sur Istio v1.4. Il est possible qu’ils nécessitent une adaptation pour Istio v1.5

Pour la suite de ce billet vous devez avoir des connaissances de base de Kubernetes et avoir une installation Kubernetes avec Istio. L’installation de ce dernier ne sera pas couverte étant donné qu’elle dépend de votre distribution Kubernetes. Plus d’information sur le site officiel.