Le projet Network Service Mesh de la CNCF met en réseau les tâches multicloud.
La technologie développée par la Cloud Native Computing Foundation (CNCF) permet de relier les tâches d'entreprise multicloud au niveau de la couche réseau, quel que soit l'endroit où elles sont exécutées.
La mise en réseau de charges de travail d'entreprise multicloud peut s'avérer compliquée et fastidieuse. Mais le projet open source Network Service Mesh placé sous les auspices de la Cloud Native Computing Foundation, une entité de la Linux Foundation, pourrait changer la donne. Son ambition ? Faire communiquer entre elles, et en toute sécurité, les charges de travail Kubernetes basées sur le cloud, quel que soit le cloud où elles sont exécutées. Et le besoin d'une telle technologie ne cesse de croître. Selon une étude publiée récemment par Cisco, les entreprises de 5 000 employés ou plus utilisent probablement plus de 10 fournisseurs de cloud publics et de 20 à 100 fournisseurs de SaaS dans des domaines comme la messagerie électronique, la collaboration et les appels vidéo, ainsi que la gestion des relations avec la clientèle et du capital humain. C'est un environnement potentiellement riche en cibles pour les partisans du Network Service Mesh. « Avec la technologie Network Service Mesh, le client peut connecter des charges de travail individuelles, où qu'elles s'exécutent - multicloud ou cloud hybride - à un maillage de services sans la complexité des passerelles Layer 7 ou sans avoir à orchestrer un domaine Layer 3 unique, vaste, complexe et plat », a déclaré Ed Warnicke, ingénieur principal Office of Open Source Initiatives de Cisco.
Un maillage de services d'application classique fonctionne au niveau de la couche Layer 7 (HTTPS) et il a pour principales caractéristiques la découverte de services et l'acheminement des demandes HTTPS des charges de travail vers les services. « Network Service Mesh reprend certains principes du maillage de services d'application traditionnel et les ramène au niveau de la couche L3. Sa fonction essentielle est d'assurer la découverte et le routage des services réseau, c'est-à-dire de connecter les charges de travail individuelles au « Network Service » à l'aide de fils virtuels ou vWires », a encore déclaré Ed Warnicke. Network Service Mesh crée des superpositions L3 plates, dynamiques et à la demande, sur lesquelles les entreprises peuvent exécuter un service mesh sur lequel elles peuvent connecter toute charge de travail autorisée. « Au final, les équipes peuvent choisir les meilleures options pour exécuter leurs charges de travail - à travers plusieurs clusters, dans des environnements existants, sur site ou dans des clouds publics - sans avoir à ajouter des couches de complexité supplémentaires ou à introduire des risques supplémentaires », a aussi déclaré l'ingénieur principal de Cisco.
Désenclaver les containers sur le réseau
Jusqu'à présent, les tentatives pour résoudre ce défi de la communication multicloud impliquaient généralement soit de placer toutes les charges de travail et le plan de contrôle du maillage de services sur un seul réseau L3 plat, soit de mettre en place un système de passerelles L7 s'interconnectant elles-mêmes sur un réseau L3 plat. Selon M. Warnicke, le réseau L3 plat est très difficile à organiser dans un environnement multicloud/hybride, et les passerelles L7 sont extrêmement complexes à maintenir et à configurer et représentent un goulot d'étranglement dans le système. « Network Service Mesh ne fournit pas en soi de services L7 traditionnels. Il fournit le service complémentaire d'un domaine L3 plat auquel les charges de travail individuelles peuvent se connecter afin que le maillage de services traditionnel puisse faire ce qu'il fait, mieux et plus facilement, sur une plus grande étendue », a expliqué M. Warnicke. « Network Service Mesh permet également le maillage multiservice, c'est-à-dire la possibilité pour un seul conteneur de se connecter simultanément à plus d'un maillage de services, quel que soit son emplacement », a ajouté M. Warnicke. « Network Service Mesh possède des fonctions de fédération d'identité et de politique d'admission qui permettent à une entreprise d'accepter de manière sélective les charges de travail d'une autre entreprise dans son maillage de services », a encore déclaré M. Warnicke.
Parmi les cas d'usage typiques de la technologie Network Service Mesh, la Cloud Foundation cite notamment :
- Un domaine vL3 plat courant de façon à ce que des bases de données fonctionnant dans plusieurs clusters/clouds/hybrides puissent communiquer uniquement entre elles pour la réplication des bases de données.
- Un seul maillage de services L7 (Istio/Linkerd/Consul/Kuma) pour connecter des charges de travail s'exécutant dans plusieurs clusters/clouds/on-prem.
- Une charge de travail unique se connectant à plusieurs maillages de services L7.
- Des charges de travail de plusieurs entreprises se connectant à un seul maillage de services « collaboratif » pour les interactions interentreprises.
Divers fournisseurs, dont Cisco, Xored et Ericsson, travaillent sur le projet Open Source Network Service Mesh de la CNCF. « Un certain nombre d'implémentations sont déjà disponibles », a précisé M. Wernicke. Tous les 60 jours, une nouvelle version est publiée. « Á mesure de la publication des versions, de nouveaux cas d'usage sont disponibles. Les cas d'usage de 'Istio extender' devraient être livrés début juin avec la version 1.4 à venir », a déclaré M. Warnicke.
