AccueilActualités informatiqueCloud-native : Open Service Mesh se dirige vers la version 1.0

Cloud-native : Open Service Mesh se dirige vers la version 1.0

L’équipe à l’origine de l’Open Service Mesh (OSM) a publié la version candidate de la première version majeure. Avec cela, le projet se dirige vers un état stable. OSM est un projet de bac à sable sous l’égide de la Cloud Native Computing Foundation (CNCF).

Microsoft a publié le projet open-source à l’été 2020 avec l’objectif déclaré d’impliquer significativement la communauté dans son développement futur. OSM est délibérément allégé et se concentre sur l’extensibilité. L’un des objectifs de la conception est qu’il soit facile à comprendre, à installer et à utiliser. Il met en œuvre l’interface de maillage de services (SMI), qui est également maintenue par la CNCF et constitue l’interface standard pour les maillages de services dans l’écosystème Kubernetes.

Outre OSM, il existe de nombreux maillages de services, dont le meilleur Istio, le solide Linkerd, le Kuma de Kong et le Consul de Hashicorp. SMI vise à assurer la compatibilité entre les mailles du réseau et la spécification implique notamment Microsoft, Hashicorp et Buoyant (la société à l’origine de Linkerd). L’Open Service Mesh est strictement orienté SMI depuis le début.

OSM, comme beaucoup d’autres maillages de services, s’appuie sur Envoy. En plus des applications individuelles, un proxy Envoy fonctionne en tant que sidecar dans le conteneur. Le proxy gère les règles de contrôle d’accès et les configurations de routage, entre autres. La couche de contrôle du maillage de services configure les proxies individuels avec les spécifications et les directives associées.

Microservices en réseau : Mailles de service

Dans une architecture de microservices, plusieurs petites applications ou services fonctionnent indépendamment les uns des autres. Un maillage de services est chargé de relier les différents services entre eux. Il se compose d’un plan de contrôle et d’un plan de données. Ce dernier est constitué de proxies qui s’exécutent aux côtés des microservices – généralement dans un sidecar d’un cluster Kubernetes.

Le plan de contrôle est responsable de la gestion des services et accède aux services via les proxies. D’une part, il peut lire les données des services et d’autre part, il peut contrôler l’interaction et configurer les services individuels.

En se connectant via des proxies dans le sidecar, les développeurs ne doivent pas adapter leurs applications pour interagir avec le maillage de services. Il n’est pas non plus nécessaire de disposer d’un cadre uniforme ou d’une passerelle API pour mettre les services en réseau.

Vous trouverez plus de détails sur le blog de l’OSM. Selon ce dernier, l’équipe a également participé à de nombreux autres projets de l’écosystème Kubernetes afin d’assurer une interaction fluide avec OSM. Il s’agit notamment de l’Open Policy Agent (OPA), de l’outil de livraison Flagger et du contrôleur d’entrée Contour. Cependant, l’article ne donne pas de date exacte pour la sortie finale, mais promet seulement une publication dans les prochaines semaines.

Plus d'articles