Microsoft has released (in alpha) the open service mesh (OSM), a service mesh implementation compliant with the SMI specification. OSM covers standard features of a service mesh like canary releases, secure communication, and application insights, similar to other service mesh implementations like Istio, Linkerd, Consul, or Kuma. Additionally, the OSM team is in the process of donating the project to the CNCF.
OSM implements the service mesh interface (SMI), a set of standard and portable APIs to deploy a service mesh in Kubernetes. When users configure a service mesh through SMI specification, they don't need to be specific about which service implementation they're running in the cluster.
Additionally, OSM comes with standard and basic service mesh features like canary releases, secure service communication, and application insights. In this alpha release, OSM comes with the ability to configure traffic shifting policies, secure communication within services through mTLS, grained access control policies, application metrics, external certificate managers, and inject the sidecar Envoy proxy automatically.
Moreover, similar to other projects like Istio, OSM uses Envoy as a sidecar proxy for communicating with other services in the mesh. However, in the OSM project repository, they mention that any xDS (service discovery protocol) compatible reverse-proxy might be used or to use advanced Envoy features.
When a user creates a pod, OSM intercepts the API through a mutating webhook to inject the Envoy sidecar proxy, and an init container uses iptables to ensure that all the traffic flows through Envoy. OSM handles access control rules, routing policies, encrypts communication, and collects metrics that, by default, can be seen in Grafana and Zipkin. Users can find more details about each of the architecture components of OSM on the project's design page. But at a high level, the below image represents the OSM components and interactions:
To get started using OSM, users need to install the OSM CLI locally and then run osm install, then the tool deploys all the components, including the SMI specification (as CRDs) in the Kubernetes cluster.
Once the OSM controller runs, users can deploy SMI objects like the below TrafficSplit manifest to distribute traffic within two versions of an application. Moreover, OSM comes with pre-configured Grafana dashboards, and when the command osm dashboard does a port forwarding to see the control and data plane metrics. Microsoft published a video to demonstrate how to install and use OSM in an existing Kubernetes cluster.
apiVersion: split.smi-spec.io/v1alpha2
kind: TrafficSplit
metadata:
name: bookstore-split
namespace: bookstore
spec:
service: bookstore.bookstore # <root-service>.<namespace>
backends:
- service: bookstore-v1
weight: 0
- service: bookstore-v2
weight: 100
OSM is not ready for production use yet, and the development progress is being tracked on the issues page of the project in GitHub. For instance, integrations with other projects like DAPR are still in progress. Moreover, the OSM team is in the process of donating the project to the CNCF as a sandbox project, and the next voting round is due to happen in September. To learn more about the project, users can visit the GitHub site to join the community, open an issue, or learn more about how to get started.
