Linkerd, premier service mesh certifié par la CNCF
Tout comme Kubernetes, Prometheus et Envoy, Linkerd est dorénavant un projet certifié par la CNCF. Les contributeurs principaux ont présenté une feuille de route fraîchement renouvelée pour les années à venir.
Linkerd est devenu le premier projet de maillage de services à être certifié au sein de la Cloud Native Computing Foundation, mais cela ne signifie pas que ses mainteneurs prévoient des vacances.
Le projet connu désormais sous le nom de Linkerd est en fait la deuxième incarnation d’un service mesh, lancé pour la première fois en 2016, bâti sur Java et utilisé pour orchestrer des machines virtuelles. Les créateurs de Linkerd, dont certains avaient fait leurs armes chez Twitter, avaient alors inventé le terme de service mesh pour désigner une toile de machines proxy qui assure des fonctions de gestion de réseau, supervisées par un control plane centralisé.
À mesure que Kubernetes, les microservices et l’orchestration de conteneurs ont envahi l’infrastructure des entreprises entre 2016 et 2018, l’attrait du concept de service mesh a grandi au sein des organisations comme moyen de faire face à la complexité de la gestion du réseau dans les systèmes distribués natifs du cloud. Linkerd 2, initialement appelé Conduit, a été introduit en 2017 pour prendre en charge le maillage de services basé sur Kubernetes.
La Cloud Native Computing Foundation (CNCF) a déjà certifié des projets open source essentiels au cloud, tels que Kubernetes lui-même, l’outil de découverte de services etcd, la plateforme de monitoring Prometheus, et Open Policy Agent pour la gouvernance et l’automatisation de la sécurité. L’obtention du certificat est soumise à l’approbation du comité de surveillance technique de la CNCF, qui évalue l’aptitude du projet à être utilisé en entreprise ainsi que la santé de sa communauté de contributeurs.
« Ils recherchent des signes de maturité et des signes de longévité de la communauté », affirme William Morgan, PDG de Buoyant.io, le contributeur principal de Linkerd. « Ils cherchent des moyens de dire que si vous êtes un utilisateur final et que vous adoptez ce projet, vous pourrez compter sur sa pérennité. Il s’agit de répondre à une question : est-ce que ça vaut la peine d’investir dedans ? »
Linkerd a Istio dans sa ligne de mire
Les mainteneurs du maillage de services Linkerd ont dû travailler depuis 2017 pour combler les écarts de fonctionnalités techniques avec leur plus grand projet rival, Istio, lancé la même année par des ingénieurs d’IBM, Google et Lyft spécifiquement pour Kubernetes.
Il y a quatre ans, Istio se vantait d’assurer certaines commodités de sécurité avancées que Linkerd n’avait pas, comme le support des politiques de sécurité réseau au niveau des applications. Au début de l’année, la mouture 2.10 de Linkerd a ajouté l’authentification au niveau des applications et, à partir de la prochaine version 2.11, le projet prendra en charge les politiques d’autorisation au niveau des applications. Ces règles régiront les permissions d’accès au réseau précisément au niveau des microservices, plutôt que de les lier plus largement aux composants d’infrastructure partagés.
Certains mainteneurs d’Istio travaillent également sur la prise en charge des VM, que d’autres services mesh tels que HashiCorp Consul prennent déjà en charge. Au cours de l’année à venir, les proxys de service mesh de Linkerd fonctionneront aussi sur des machines virtuelles en dehors des clusters Kubernetes, ce qui, dans un sens, bouclera la boucle du projet Linkerd 1.
« Le control plane sera probablement toujours lié à Kubernetes, mais le maillage s’étendra aux ressources hors clusters », dans les futures versions de Linkerd, anticipe William Morgan.
Enfin, Buoyant a également lancé la version bêta publique de Buoyant Cloud au début du mois de juillet, rejoignant ainsi la tendance croissante du Service Mesh en mode SaaS. Aucune date de disponibilité générale n’a encore été fixée pour Buoyant Cloud, et William Morgan a refusé de préciser le nombre d’utilisateurs inscrits à la version bêta.
Un « service mesh au petit-déjeuner »
Istio réunit encore la plus grande communauté de contributeurs parmi les projets de maillage de services open source et une base d’utilisateurs substantielle. Cependant, malgré sa notoriété initiale, Istio s’est heurté à des obstacles techniques et le projet a perdu une partie de son cachet dans l’écosystème libre après que Google a décidé de ne pas en faire don à la CNCF l’année dernière.
Entre-temps, la facilité d’utilisation présumée de Linkerd a commencé à attirer des usagers et des contributeurs du secteur privé, dont Microsoft et HP. En janvier, les responsables du projet ont créé le comité de pilotage de Linkerd, afin d’élargir la gouvernance du projet bien au-delà de ses créateurs initiaux chez Buoyant.
« Tout l’élan est venu du projet lui-même, du bouche-à-oreille et d’une vision claire de la facilité d’utilisation. »
William MorganPDG, Buoyant.io
« Linkerd n’est pas issu d’une grande entreprise disposant de ressources infinies en matière de marketing et de partenariat », martèle William Morgan. « Tout l’élan est venu du projet lui-même, du bouche-à-oreille et d’une vision claire de la facilité d’utilisation. »
Entain, une compagnie de paris sportifs en ligne basée en Australie, est un exemple typique d’entreprises qui adoptent Linkerd. La société a commencé à migrer vers Kubernetes et les microservices basés sur des conteneurs il y a trois ans, pour accélérer le développement de ses produits. Mais, l’année dernière, elle devait trouver un moyen de maintenir plus simplement les performances de son ancien monolithe couplé à sa plateforme de trading de données sportives.
Au départ, l’entreprise a utilisé le répartiteur de charge natif de Kubernetes pour équilibrer les connexions réseau du protocole gRPC entre ses microservices, mais cela est devenu difficile à gérer à l’échelle.
« L’un des aspects sombres et maléfiques de Kubernetes et de gRPC, c’est que si vous avez une application de traitement assez lourde, les mécanismes par défaut de Kubernetes pour l’équilibrage de charge peuvent vous consumer assez facilement », témoigne Steve Gray, responsable des solutions de trading chez Entain.
L’orchestrateur de conteneurs a été conçu à l’origine pour les applications Web, et celles-ci présentent des caractéristiques différentes de celles de la plateforme de trading qu’Entain devait prendre en charge. Les applications Web se déconnectent et se reconnectent souvent, et l’équilibreur de charge Kubernetes est optimisé par défaut pour supporter ce comportement.
Au départ, cela signifiait que le trafic gRPC régulier, mais important de l’application commerciale d’Entain, « grillait un serveur à la fois », au lieu d’être réparti uniformément sur le cluster, explique Steve Gray.
Le seul ingénieur DevOps de son équipe a pu modifier le répartiteur de charge pour atténuer ce problème. Mais cela n’allait clairement pas être viable à long terme, car le nombre de microservices a grossi pour atteindre plus de 300 composants répartis sur des milliers d’instances de conteneurs, selon Steve Gray.
« J’aime mettre 100 % de mon énergie dans les choses qui nous rendent uniques et intéressants, et ce n’était que du code opérationnel, dont nous ne devrions pas avoir à nous soucier », considère le responsable.
L’ingénieur DevOps d’Entain a commencé à chercher un service mesh. Le problème de load balancing de Kubernetes avait déjà conduit à une défaillance du cluster, et l’entreprise devait régler le souci rapidement. Ici, comme pour de nombreux utilisateurs de Linkerd, la facilité de configuration du projet l’a emporté sur Istio, plus avancé, mais complexe.
« Nous avons effectué toute la migration vers Linkerd en l’espace d’environ huit heures pour l’ensemble de la plateforme en production », raconte Steve Gray. « [L’ingénieur DevOps] a commencé au milieu de la nuit, toute la nuit, puis à l’heure du petit-déjeuner, nous avons lancé un maillage de services. »
