skvoor - Fotolia

Actualites

Dans sa version 2.0, Linkerd se rapproche de Kubernetes

Fruit de la fusion avec Conduit, la version 2.0 de cette technologie de service mesh s’adosse à une architecture refondue, bâtie sur Go et Rust, pour mieux s’insérer dans l’écosystème Kubernetes.

Cyrille Chausson
par
Publié le: 20 sept. 2018

La communauté open source en charge de Linkerd a annoncé la disponibilité de la version 2.0 de ce projet de service mesh, désormais très prisé dans la sphère des applications natives pour le cloud et des micro-services.

Né chez Buoyant mi-2016, Linkerd est l’un des premiers projets à avoir considéré la problématique réseau et interconnexion des services  dans une architecture de microservices. Un service mesh, via un système de proxy sidecar - attaché à chaque container, pod ou VM -  garantit un bon routage du trafic entre services ainsi que leur connexion et propose, avec un control plane, des outils de monitoring via des données télémétriques. Certains, comme Istio, proposent également des fonctions de haute disponibilité et de monitoring.

Parce qu’il est justement l’un des premiers projets de service mesh, Linkerd n’est pas né avec Kubernetes à l’esprit. Sa technologie de proxy sidecar se reposait sur une VM Java, dont l’empreinte mémoire convenait certes à l’époque, mais devenait trop imposante pour des utilisateurs de Kubernetes. Faisant ce constat, Buoyant s’est mis à développer Conduit, dont l’architecture revisitée, bâtie sur le langage Go et les proxies Rust, permettait de limiter cette empreinte.

Fusion entre Linkerd et Conduit

Linkerd 2.0 est le résultat de la fusion entre Linkerd 1.0 et Conduit – les deux projets se sont rapprochés cet été. Dans sa version 2.0, Linkerd dispose donc d’une architecture revisitée, bâtie sur Rust et Go (pour le control plane), pour garantir aux utilisateurs de Kubernetes une consommation minimale, explique William Morgan, le CEO de Buoyant, dans un billet de blog. Pour mémoire, Kubernetes et Linkerd sont hébergés au sein de la même fondation open source (Cloud Native Computing Foundation).

Selon lui, cette version se distingue par le fait que Linkerd peut également être déployé de façon incrémentale, service par service, espacé dans le temps, à l’inverse des autres technologies qui nécessitent un déploiement global sur le cluster. Cette capacité centralisée du déploiement et du monitoring est notamment un des points clé d’Istio.

Il est vrai que ces technologies de service mesh connaissent aujourd’hui un fort intérêt chez les adeptes des microservices. Dans sa dernière étude pointant l’évolution de ses projets (réalisée auprès de 2 500 personnes dont 36 % en provenance d’Europe), la Cloud Native Computing Foundation faisait état d’une hausse de l’intérêt porté à Linkerd. En un an, son usage en production serait passé de 3 % à 16 % (d’après les retours de la communauté d’utilisateurs de la CNCF). Mais plus encore, les évaluations de Linkerd auraient tout simplement fait un bond, de 15 % à 84 % en un an.

Toutefois, cet intérêt concerne tous les outils de service mesh. Les autres technologies sont également au centre des préoccupations des équipes de développement et DevOps. C’est le cas d’Envoy, un autre projet de la CNCF – et un des fondements d’Istio. 24 % - contre 4 % il y a un an - l’ont déployé en production, et 74 % l’évaluent, contre 26 % lors du précédent comptage.

Pour approfondir sur Stockage de conteneurs