Istio : Ambient Mesh franchit l’obstacle de l’interopérabilité dans le cloud
En bêta dans la prochaine version du service mesh, le mode Ambient Mesh d’Istio est désormais compatible avec les services Kubernetes managés des principaux fournisseurs de cloud, et est disponible en tant que module complémentaire d’Amazon EKS.
La version d’Istio d’un service mesh sans sidecar sera bientôt disponible en version bêta, ainsi que chez un fournisseur de cloud.
Istio Ambient Mesh, présenté pour la première fois en septembre 2022, est une variante du projet de maillage de services qui adopte une approche simplifiée de l’architecture de ses proxys sidecar. Originellement, le projet créé par Google, IBM et Lyft, s’appuie sur des composants logiciels appelés sidecars. Dans cette configuration, les sidecars sont déployés sur chaque pod Kubernetes et utilisés par un plan de contrôle central pour exécuter des fonctions de gestion de réseau distribué. Cette architecture est désormais associée aux applications de microservices conteneurisées sur Kubernetes, mais les sidecars peuvent devenir encombrants et complexes à gérer lorsque les clusters évoluent. De plus, ils ne sont pas strictement nécessaires pour toutes les applications.
Istio Ambient Mesh, en alpha depuis le début de l’année 2023, offre à la place la possibilité d’utiliser un proxy partagé avec certaines fonctionnalités de routage du trafic telles qu’un TLS mutuel (mTLS) et la gestion des identités pour les charges de travail qui ne nécessitent pas de routage de la couche 7 (L7) au niveau de l’application.
Cependant, lorsque les responsables du projet sont allés tester la compatibilité d’Ambient Mesh avec les services Kubernetes managés des fournisseurs de cloud, ils se sont heurtés à un problème.
Dans les environnements Kubernetes, le service mesh d’Istio doit se connecter à l’interface de réseau de conteneurs (CNI), un framework permettant de configurer dynamiquement les ressources réseau éphémères des conteneurs au sein des clusters. Chacun des principaux services gérés par les fournisseurs de cloud pour Kubernetes – Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS) et Google Kubernetes Engine (GKE) – utilise une CNI différente, tout comme d’autres projets de réseau natifs du cloud tels que Calico et Cilium.
Les CNI des fournisseurs cloud étaient incompatibles avec le mode Ambient Mesh
Les responsables d’Istio Ambient Mesh ont découvert lors des tests alpha que les différentes CNIs géraient la redirection du trafic différemment, certains d’une manière qui les rendait incompatibles avec le mode « sidecarless » du service mesh.
« Le problème fondamental de la redirection du trafic dans le namespace du réseau hôte est qu’il s’agit précisément de l’endroit où la principale implémentation CNI du cluster doit configurer les règles de routage du trafic/réseau », indique un billet de blog des responsables d’Istio. « Cela a créé des conflits inévitables ».
« Cela signifie que chaque distribution Kubernetes qui implémente une CNI devrait être en mesure d’exécuter Istio Ambient Mesh sans changement. »
Torsten VolkAnalyste, Enterprise Management Associates
Pour surmonter cet obstacle, les ingénieurs du projet ont trouvé un moyen de gérer la redirection du trafic au niveau du pod Kubernetes sans avoir à revenir à l’utilisation de sidecars.
« Cela signifie que chaque distribution Kubernetes qui implémente une CNI devrait être en mesure d’exécuter Istio Ambient Mesh sans changement », résume Torsten Volk, analyste chez Enterprise Management Associates. « Il ne devrait pas y avoir de surcharge de performance, car ils n’ajoutent pas de conteneurs ou de logiciels supplémentaires. Ils utilisent simplement l’agent Istio pour injecter directement les instructions de routage dans le réseau de pods, au lieu d’exécuter ces mêmes instructions de routage au niveau du nœud ».
Ambient Mesh arrive sur Amazon EKS
Avec cet ajustement, à partir de la version 1.21 d’Istio, publiée le 13 mars, Ambient Mesh « a été testé avec GKE, AKS et EKS et toutes les implémentations CNI qu’ils offrent, des CNI tierces comme Calico et Cilium, et des plateformes comme OpenShift, tous avec des résultats solides », selon un billet de blog. L’article indique également qu’Ambient Mesh devrait atteindre la version bêta dans la prochaine version d’Istio service mesh. Les versions du projet sont généralement disponibles une fois par trimestre.
Entre-temps, Solo.io, éditeur d’une plateforme de réseau cloud-native, a ajouté cette version d’Ambient Mesh à son module complémentaire Amazon EKS la semaine dernière. AWS a également rendu les modules complémentaires EKS, précédemment livrés séparément via AWS Marketplace, disponibles directement dans la console de gestion EKS le 14 mars.
Ambient Mesh n’est toujours pas recommandé pour une utilisation en production, mais la disponibilité d’une version compatible directement dans la console Amazon EKS marque une étape importante vers l’adoption par les entreprises, estime Steven Dickens, analyste chez Futurum Group.
« Maintenant que Solo a fait le travail d’ingénierie, c’est une chose de moins dont l’équipe SRE [ingénierie de fiabilité des sites] ou l’équipe de développement doit se préoccuper », considère-t-il. « C’est ce qui favorise l’adoption ».
Le maillage de services, une approche encore peu adoptée
Ambient Mesh est la dernière tentative de la communauté derrière Istio et des éditeurs commerciaux qui le soutiennent pour surmonter sa réputation initiale d’outil extrêmement complexe à utiliser. Ambient Mesh trace également une voie médiane entre l’approche sans sidecar, adoptée par Isovalent de Cisco et le projet Cilium, et l’approche avec « sidecars only » de Linkerd, dont les partisans affirment qu’elle maintient la sécurité du service mesh tout en préservant la simplicité de l’approche sans sidecar.
En fin de compte, c’est la simplicité qui l’emportera sur les spécifications techniques, prédit M. Dickens.
« Il ne s’agit pas d’opposer Isovalent à Solo ou de savoir qui possède la meilleure technologie », tient-il à signaler. « Il s’agit plutôt de savoir qui a rendu le déploiement moins [difficile] ».
Istio a par ailleurs pris de l’ampleur depuis que Google en a fait don à la Cloud Native Computing Foundation, où il compte 8 800 contributeurs, dont 85 mainteneurs issus de 15 entreprises différentes. Outre Solo.io, le projet est soutenu par Tetrate, un autre éditeur.
Steve Dickens de Futurum Group hésite à déclarer Istio comme le leader incontesté dans la compétition naissante consacrée au maillage de services. Cependant, il semble que le projet porté initialement par Google, IBM et Lyft ait une longueur d’avance alors que Kubernetes et ses outils affiliés de gestion des applications distribuées sont adoptés par pratiquement toutes les grandes entreprises.
« J’ai suffisamment de cheveux gris pour savoir qu’il ne faut pas choisir d’avance les gagnants », s’amuse-t-il. « Mais je pense que dans 18 mois, nous aurons probablement une meilleure vision de la situation ».
Pour approfondir sur Architectures logicielles et SOA
