A Service mesh is a tool for managing and securing service to service communication in Kubernetes.
Right now it’s a technology very fragmented, with multiple implementations in the market from Google’s Istio that is the more popular, HashiCorp Consul, Linkerd and more.
Microsoft recently announced the launch of it’s service mesh, Open Service Mesh (OSM) that is meant to be a reference implementation of SMI (Service Mesh Interface). SMI like CNI (Container Network Interface), CRI (Container Runtime Interface) and CSI (Container Storage Interface) did in the past, aim to bring standarization in this technology, enabling flexibility and interoperability between multiple implementations that follow that standard.
Two weeks ago, it was announced that OSM project was accepted to enter the Cloud Native Computing Foundation (CNCF) as sandbox project. So I got interested in playing a little with it. This blog post is about my experience with OSM.
Open Service Mesh (OSM) is based in Envoy. An Envoy sidecar proxy is injected into each application pod, then this proxy manages all the incoming and outgoing traffic.
Envoy, represent the data plane of the solution while there’s a pod called the osm-controller that works as a control plane.
Key Features of OSM
- Configure traffic shifting for common deployment scenarios
- Secure service-to-service communication with automatic mTLS
- Enforce fine grained access control policies for services
- Observe metrics for debugging and monitoring of services
- Integrate with native or external certificate management solutions
- Onboard applications onto the mesh with automatic sidecar injection
Installing OSM and Demo
Installing OSM is very simple. The current prerequistes are:
- OSM CLI
- Kubernetes Cluster running Kubernetes 1.15 or greater.
- Kubectl installed in the client with the context pointing to the target cluster
- Local copy of the OSM GitHub Repo for the demo.
After you download the OSM CLI, you need to extract it and place in a folder that is in your PATH.
Installing the OSM Control Plane is simple:
osm install
You can have multiple services meshes in the same cluster. They are identified by a name. When you deploy your service mesh this way the installer will create a new service mesh with default name osm and install it osm-system namespace.
By default if you add applications to the mesh, no other services will be able to communicate with it. All traffic is denied by default. If you want install OSM in a way that services can still communicate you can use the –enable-permissive-traffic-policy flag from the install commmand.
Now, let’s deploy the demo applications. First you need to create 4 (four namespaces) one for each component.
for i in bookstore bookbuyer bookthief bookwarehouse; do kubectl create ns $i; done
And we will add the namespaces to the Mesh and enable automatic sidecar injection:
osm namespace add bookstore bookbuyer bookthief bookwarehouse --enable-sidecar-injection
Now you can deploy the demo app manifest file from the OSM git source folder.
kubectl apply -f docs/example/manifests/apps/
OSM uses SMI, and Service Mesh Interface specification includes four API objects: traffic spec, traffic target, traffic split, and traffic metrics. Each API object is extended as a Kubernetes CRD (Custom Resource Definition).
At this point, no applications have access to each other because no access control policies have been applied.
kubectl create -f docs/example/manifests/access/
I will leave it there for now. I will continue in the next post.
If you want to learn more about this technologies in deep I recommend this two blog post from itnex.io about OSM and SMI.