Service Mesh : les mainteneurs d’Istio à la recherche de la stabilité

2020, une année complexe pour Istio

Conscients du problème, les contributeurs principaux ont effectué un changement d’architecture majeur dans la version 1.5. Au lieu d’opérer le service mesh par le biais de quatre composants en sus du proxy Envoy, les programmeurs d’IBM, Red Hat et Google ont créé Istiod (d pour daemon), un control plane monolithique à partir des éléments déjà en place : Pilot (contrôle de routage), Citadel (authentification) et Galley (gestion de configuration pour Istio).

Mixer, chargé du contrôle d’accès aux services et de la collecte de métriques depuis Envoy, a été retiré de l’équation. Mixer imposait une connexion active entre lui et les side-car proxy (Envoy). Conséquence, la consommation en ressources CPU augmentait significativement. Mixer a été remplacé par deux modules personnalisés WebAssemby (Wasm) développés en C++ associés à Envoy. Si cette approche doit simplifier la gestion du service mesh, ou plutôt « la rendre ennuyeuse », elle implique également quelques complications. Mixer a été déprécié depuis la version 1.8.

En 2020, Google a formé une entité open source, Open Usage Commons, un comité de direction et un comité de contributeurs pour Istio. La même année, les développeurs de Google, Red Hat/IBM, Aspen Mesh et Solo.io ont (ré) introduit la compatibilité avec Helm v3 (supprimée dans la 1.6 en mai, puis rétabli en novembre dans 1,8), la sécurité par défaut avec le protocole mTLS et un Service Discovery Service, la possibilité de créer des mesh multicluster, ainsi que plusieurs optimisations.

Istio 1.9, porté sur les nouveautés

Le 9 février dernier, près d’un an après la présentation d’Istio 1.5, les responsables du projet ont dévoilé la release 1.9 du service mesh. S’il s’agit d’une version majeure, la plupart des nouvelles fonctionnalités ne sont pas achevées. Istio 1.9 introduit en bêta l’intégration dans le maillage des workloads hébergés sur des machines virtuelles. Elle rend aussi la télémétrie plus configurable grâce à des règles de classification. Istio 1.9 prend en charge en alpha les CRD (Custom Resource Definition de Kubernetes) pour Service APIs, un projet tout fraîchement renommé Gateway API. En mode expérimental, Istio introduit la capacité de s’interfacer avec des systèmes d’authentification externes comme OPA ou OAuth2.

Par ailleurs, il est possible d’essayer la configuration des filtres HTTP avec un module WebAssembly distant, de superviser leur distribution ou de développer des extensions personnalisées. Les mainteneurs ont également optimisé le CLI istioctl, le support du protocole gRPC, et fait le nécessaire pour éviter la limite de téléchargement imposée par Docker Hub.

Cette semaine, c’est sur cette base que les contributeurs principaux du projet ont dévoilé les grandes tendances de la feuille de route 2021 pour le service mesh.

Selon une étude de la Cloud Native Computing Foundation (CNCF), 27 % des 1 324 sondés emploient un service mesh en production. Istio est utilisé par 47 % de cette population, devant Linkerd et Consul (tous deux à 41 %, les entreprises maintiennent plusieurs technologies). Mais un petit sondage effectué auprès d’une soixantaine de membres de la communauté démontre que la majorité des utilisateurs (54,1 %) ont eu du mal à suivre le cycle de mise à jour en 2020.

« En 2020, il y a beaucoup de changements affectant l’architecture d’Istio et nous voulions améliorer l’outillage pour nous assurer une plus grande simplicité de mise à jour », déclare Louis Ryan, ingénieur principal chez Google. « Nous recevons encore des messages nous indiquant que les mises à jour sont parfois difficiles à réaliser ».

De fait, cette technologie est dépendante de Kubernetes et d’Envoy. « Nous suivons intentionnellement le cycle de release de Kubernetes », affirme le responsable.

L’une des raisons pour lesquelles ces mises à jour semblent plus complexes, c’est que les contributeurs principaux doivent prendre en compte la diversité des moyens désormais employés pour opérer Istio. En la matière, l’Istio Operator, Helm et les composants similaires des fournisseurs d’Istio as a Service sont les plus populaires. « Nous avons étendu le support des outils en 2020, mais nous avons encore beaucoup d’investissement à effectuer sur ce point », reconnaît Louis Ryan.

« Nous ne désirons plus modifier ces fondations, mais joindre des capacités bien étudiées, basées sur les retours des utilisateurs. »

« Nous voulons simplifier les opérations J+2 », vante Neeraj Poddar, cofondateur et chief architect chez Aspen Mesh, filiale de F5 Networks. « À J-0, vous préparez l’architecture, le design, à J+1 vous installez, paramétrez et configurez. À J+2, vous avez fait vos choix. Beaucoup de nos utilisateurs sont à ce stade, ils exécutent Istio en production. Nous voulons nous assurer que cela se passe bien pour eux, qu’ils ont les bonnes expériences de mises à jour et de gestion au quotidien et de corrections des bugs ».

Et comme l’année dernière, Neeraj Poddar évoque le fait « de rendre Istio ennuyeux… à nouveau ». Il considère que l’architecture du service mesh a atteint ce stade. « Nous ne désirons plus modifier ces fondations, mais joindre des capacités bien étudiées, basées sur les retours des utilisateurs. Vous aurez de nouvelles fonctionnalités en 2021, mais elles ne seront pas aussi nombreuses qu’en 2020 », ajoute-t-il.

Cependant, les utilisateurs ne gèrent pas Istio de manière identique. Beaucoup d’entreprises témoignant lors de l’IstioCon exploitent le Service Mesh à large échelle et prévoient même d’étendre son usage.

Une technologie hautement personnalisable… et complexe

Salesforce emploie déjà Istio de manière avancée. L’éditeur a dû opérer plusieurs changements depuis la phase de POC jusqu’à la mise en production. Les ingénieurs sont notamment passés d’une version commerciale au déploiement de la distribution open source.

L’installation des composants Istio dans un environnement cloud est dépendant d’un pipeline bien particulier qui combine des fichiers YAML envoyés dans un package Helm depuis Jenkins vers un bucket S3, avant d’être ingéré par Spinnaker et appliqué via kubectl dans un environnement Kubernetes.

Les architectes logiciels ont standardisé le déploiement d’Istio dans un projet open source (sous licence BSD-3). Helm starter n’est autre qu’un chart Helm comprenant des fichiers YAML personnalisés. Il faut tout de même ajouter des éléments pour obtenir des données de télémétrie spécifiques à un service.
Cependant, Salesforce est toujours dans une phase de migration vers la version totalement open source. De fait, l’éditeur a décidé de se lancer dans l’effort Hyperforce, une infrastructure qui combine « plusieurs types d’architectures cloud », selon Patrima Nambiar, architecte logiciel chez Salesforce. À ce titre, la firme dirigée par Marc Benioff cherche à contribuer au projet Istio et à adopter les nouvelles capacités du service mesh comme les modules WebAssembly, mais il doit pour l’instant administrer des déploiements sur des serveurs bare-metal, par exemple.

« On a déjà un fait long voyage avec Istio et Envoy, mais nous avons encore un chemin à faire », déclare la responsable siégeant au conseil des contributeurs d’Istio.

Chez Intuit, il s’agit de profiter des capacités multicluster du maillage de services. Cependant, la gestion offerte par défaut n’est pas suffisante pour administrer 160 000 clusters Kubernetes, comme le fait Intuit. À ce titre, les ingénieurs développent le projet open source Admiral, un outil pour automatiser la configuration et la découverte de microservices dans ce contexte.

Simplifier le travail de maintenance

« Nous distinguons deux grands types d’utilisateurs : les early adopters et les responsables de la maintenance. Les premiers testent les fonctionnalités, mettent à jour régulièrement le service mesh et veulent donc les bons outils pour le faire. Les seconds ont un budget à tenir pour l’entretien de l’infrastructure ; ils désirent prédire les coûts, l’allongement du support par version et ne pas effectuer toutes les mises à jour », qualifie Neeraj Poddar.

« Nous souhaitons améliorer l’expérience de mise à jour, nous avons constitué un groupe de travail spécifique. »

« Nous souhaitons améliorer l’expérience de mise à jour, nous avons constitué un groupe de travail spécifique. Nous avons aussi trouvé des manques dans nos tests qui nous empêchaient de repérer des bugs. Nous encourageons les plus gros utilisateurs d’Istio et les membres du comité à participer à l’amélioration de notre stratégie de tests », ajoute-t-il.

Par ailleurs, les prochaines itérations du service mesh doivent apporter une meilleure compréhension des API pour chacun des rôles qui les manipulent, à savoir les développeurs, les opérateurs Mesh et les administrateurs Mesh afin d’éviter les problèmes de configuration.

En 2021, les contributeurs prévoient de poursuivre les itérations des fonctionnalités introduites dans la version 1.9 d’Istio. Ils comptent également améliorer la CNI (Container Network Interface), assurer le support complet d’IPv6, une meilleure prise en charge des VM, de mesh multiclusters et de Helm v3.

Un boulevard pour les éditeurs

Par ailleurs, l’équipe doit nettoyer le statut des fonctionnalités accessibles depuis GitHub afin d’indiquer ce qu’Istio fait, sait faire et ne fait plus. Dans la même veine, certains utilisateurs remarquent que les contributeurs principaux utilisent une fork d’Envoy pour faire évoluer le service mesh. Plus spécifiquement, un dépôt correspond à une copie à l’identique du Git Envoy et un autre contient une version modifiée du proxy sur lequel siège des extensions WASM utilisées par les contributeurs principaux, selon John Howard, ingénieur logiciel chez Google.

Louis Ryan évoque de possibles chevauchements entre les API Gateway et Multi Cluster en provenance du projet Kubernetes et les capacités d’Istio. De même, il indique qu’il faut suivre en parallèle le développement du projet Envoy ; certaines de ses fonctionnalités pourraient influencer l’évolution du service mesh.

Malgré son efficacité, Istio reste complexe à gérer. Les projets concurrents comme Linkerd et Consul peuvent aussi bien prendre de l’ampleur. Mais la maîtrise d’Istio par quelques fournisseurs et éditeurs dont Google Cloud, Red Hat, Aspen Mesh, Solo.io, ou encore Tetrate leur offre les portes d’un vaste marché. Clairement, le contrôle du partage de données entre microservices et leur sécurité demeurent un sujet phare dans des environnements conteneurisés.