Kubernetes se renforce sur le réseau avec Istio

Si les architectures de micro-services résolvent certains problèmes, elles en ajoutent aussi de nouveaux. La division des applications en services indépendants simplifie le développement, les mises à jour et la mise à l’échelle. Mais cela oblige d’un autre côté à connecter et à sécuriser beaucoup plus de composants mobiles. Au point que la gestion de tous les services réseau – équilibrage de charge, gestion du trafic, authentification et autorisation, etc. – peut devenir incroyablement complexe. Cet espace réseau entre les services d’un cluster Kubernetes porte un nom générique : le maillage de services, ou services mesh. Le projet Istio de Google apporte une solution pour gérer le maillage de services du cluster avant de se retrouver avec une pelote inextricable.

Qu’est-ce qu’un service mesh ?

Tout groupe d’applications en réseau partage une multitude de comportements communs qui tendent à se développer autour d’eux. C’est le cas par exemple de l’équilibrage de charge : les situations où un groupe de services en réseau n’en a pas besoin sont rares. De même, la possibilité de tester différentes combinaisons de services ou de mettre en place une authentification de bout en bout sur l’ensemble des chaînes de services. Ces comportements sont collectivement appelés un maillage de services. La gestion du maillage de services ne devrait pas être déléguées aux services eux-mêmes. Car aucun d’entre eux n’est bien placé pour faire quelque chose du sommet vers la base.

Et de toute façon, ce n’est pas vraiment aux services de faire ce travail. Il est préférable de disposer d’un système séparé entre les services et le réseau avec lequel ces services communiquent. Un tel système assure deux fonctions essentielles : d’abord, il évite aux services eux-mêmes d’avoir à faire face à la complexité de la gestion de l’équilibrage du trafic sur le réseau, du routage, des tentatives multiples, etc. ; ensuite, il fournit une couche d’abstraction aux administrateurs, ce qui facilite la prise de décisions de haut niveau sur le trafic réseau dans le cluster – les politiques de contrôle, les métriques et les logs, la découverte de services, les communications sécurisées inter-services via TLS, etc.

Composants du service mesh Istio

Istio fonctionne comme un maillage de services en fournissant deux éléments d’architecture de base pour le cluster, à savoir : un plan de données et un plan de contrôle. Le plan de données gère le trafic réseau entre les services du maillage. Tout ce trafic est intercepté et redirigé par un système de proxy réseau. En ce qui concerne Istio, le proxy est fourni par un projet open source appelé Envoy. Un deuxième composant du plan de données, Mixer, rassemble les données télémétriques et statistiques d’Envoy et le flux du trafic entre services. Le plan de contrôle, coeur d’Istio, gère et sécurise le plan de données. Il configure à la fois les proxies Envoy et les Mixers qui appliquent les politiques réseau pour les services, pour définir par exemple, qui peut communiquer avec qui et à quel moment. Le plan de contrôle fournit également une couche d’abstraction programmatique pour le plan de données et tous ses comportements.

Trois autres services Istio complètent l’offre : Istio Pilot, Istio Citadel et Istio Gallery. Istio Pilot prend les règles de comportement du trafic fournies par le plan de contrôle et les convertit en configurations appliquées par Envoy en tenant compte du mode de gestion local. Pilot permet à Istio de travailler avec d’autres systèmes d’orchestration que Kubernetes, à condition qu’ils se comportent de manière cohérente entre eux. Istio Citadel contrôle l’authentification et la gestion des identités entre les services. Enfin, Istio Gallery prend les configurations spécifiées par l’utilisateur pour Istio et les convertit en configurations valides pour les autres composants du plan de contrôle. C’est un autre élément qui permet à Istio d’utiliser différents systèmes d’orchestration de manière transparente.

Capacités du service mesh Istio

L’abstraction est le premier et le plus précieux des avantages d’Istio, car elle permet de traiter les complexités d’un maillage de services sans lien de dépendance. Il est possible d’apporter n’importe quelle modification au maillage par programmation en commandant Istio. Les services connectés au maillage n’ont pas besoin d’être reprogrammés de l’intérieur pour répondre à de nouvelles politiques ou quotas de réseau, et les espaces réseau entre eux n’ont pas besoin d’être modifiés directement. De plus, Istio permet d’apporter des modifications non destructives ou provisoires à la configuration réseau du cluster. Si l’on souhaite déployer une nouvelle configuration réseau, globale ou partielle, ou réaliser un test A/B de la configuration actuelle pour la comparer à une nouvelle configuration, Istio permet de le faire d’une manière descendante. On peut également annuler ces changements s’ils s’avèrent néfastes. Un troisième avantage est celui de l’observabilité. Istio fournit des statistiques et des rapports détaillés sur ce qui se passe entre les conteneurs et les noeuds du cluster. S’il y a un problème imprévu, si quelque chose ne respecte pas la politique ou si les changements apportés s’avèrent contre-productifs, il est possible de le savoir rapidement.

Istio fournit également différents moyens pour satisfaire aux modèles communs que l’on rencontre dans un maillage de services. C’est le cas par exemple du modèle de disjoncteur, qui permet d’empêcher un service d’être bombardé de demandes si le back-end signale un problème et ne peut pas répondre aux requêtes en temps voulu. Istio a, dans sa bibliothèque standard d’application des politiques, un modèle de disjoncteur. Enfin, même si Istio travaille plus directement et plus profondément avec Kubernetes, il est conçu pour être indépendant de la plate-forme. Istio se branche sur les mêmes standards ouverts que ceux dont dépend Kubernetes. Istio peut également fonctionner de manière autonome sur des systèmes individuels ou sur d’autres systèmes d’orchestration comme Mesos et Nomad.

Comment démarrer avec Istio

Une bonne manière d’apprendre Istio pour ceux qui ont déjà l’expérience de Kubernetes est de prendre un cluster Kubernetes – pas encore en production – et d’y installer Istio à l’aide d’un diagramme de Helm. Ensuite, ils peuvent déployer une application test qui permet d’explorer les fonctionnalités courantes d’Istio comme la gestion intelligente du trafic et la télémétrie. Cela permet déjà d’acquérir une certaine expérience de base avec Istio avant de le déployer en tant que service de maillage d’un cluster d’applications. Red Hat, qui a investi dans Istio dans le cadre du projet OpenShift alimenté par Kubernetes, propose des didacticiels qui permettent de se familiariser avec les scénarios courants de déploiement et de gestion d’Istio.