Service Mesh Hub v0.7.2 and Open Service Mesh Support

Solo.io Engineering | September 4, 2020

Service Mesh Hub is a Kubernetes-native management plane that enables configuration and operational management of multiple clusters of the same service meshes and multiple clusters of heterogeneous service meshes through a unified API. Since its open sourcing in spring of this year, we’ve been working hard with the community and ecosystem to make Service Mesh Hub more robust and stable while broadening its support for different service meshes. 

The recent 0.7.2 release includes new features like support for the recently announced Open Service Mesh by the Microsoft Azure open source team and the ability to select FailoverServices as a traffic shift destination in the TrafficPolicy CRD, in addition to a couple of fixes and updates to the docs. 

What is Open Service Mesh (OSM)?

Announced on August 5th, OSM is an open source, lightweight service mesh for Kubernetes that implements the SMI specification and exposes the Envoy APIs for functionality not provided in SMI. OSM joins a growing number of service meshes available from a variety of communities and vendors based on Envoy Proxy.

 

Try OSM with Service Mesh Hub

With this release of Service Mesh Hub, you can use it to install OSM and configure Access Policies and Traffic Policies to allow communication between the services. 

In this tutorial available in docs, we’ll walk you through a workflow to deploy OSM with a sample application and then configure the service mesh to allow traffic between services, split traffic between two different versions of the Bookstore apps resulting in the Book thief service “stealing” books from the bookstore.

 

The components of the Bookstore application do the following:

  • Book buyer – Sends requests to the Bookstore services
  • Book thief – Sends requests to the Bookstore services
  • Bookstore v1 – Sends requests to the Book warehouse service, receives requests from the Book buyer and thief
  • Bookstore v2 – Sends requests to the Book warehouse service, receives requests from the Book buyer and thief
  • Book warehouse – Receives requests from the Bookstore service

The default operating mode in OSM is “restrictive” meaning that services cannot talk to each other unless specifically allowed to via the API.  Using Service Mesh Hub, the tutorial walks through how to configure AccessPolicy which translates to OSM HTTPRouteGroup and TrafficTarget to govern access between different app services and TrafficPolicy which translates to OSM TrafficSplits CRD for traffic control, manipulation, and splitting within the application.

Get Started 

We’re continuously releasing updates in the open source so check back here and in our Github repo for the latest. We invite you to try Service Mesh Hub today for OSM, Istio, and more and give us feedback. 

Back to Blog