OpenShift Service Mesh vs Istio

4 min readOct 9, 2020

I found the phase “OpenShift is Kubernetes on steroids” in one of the articles about OpenShift on Medium. (Sorry, I can’t find the origin of that phase) I think this may be an implication about OpenShift in terms of its power up version of Kubernetes.

One perspective of this steroid implication is that OpenShift already integrated and tested most of the things that are required for enterprise Kubernetes for you and Service Mesh is one of those

I think many of you already heard about Service Mesh and also Istio recently. I will not discuss about benefit of Service Mesh here but I want to point out what is the different between OpenShift Service Mesh ( a.k.a OSSM — another abbreviate in our IT world) with its upstream project that is Istio.

This is the 1st blog of OpenShift Service Mesh series.

Let’s check it out for the 1st part of this series

Multi-tenant Control Plane.

Control plane of OSSM is not cluster wide. It is multi-tenant by default. This means that you can create a control plane in one namespace then select which namespaces you need to join to that control plane. With multi-tenant, You can have multiple control planes or multiple meshes in a single OpenShift (Kubernetes) cluster.

Traffic and control plane configuration for each mesh will be isolated from each other. This isolation is done by namespace, RBAC and network policies and each namespace can belong to only one mesh.

Sample of workflow with multi-tenant control plane will be

Create a control plane in namespace payment-istio-system. This can be done by creating a Custom Resource Definition (CRD) called ServiceMeshControlPlane (or smcp in shorten form) at control plane namespace. You can find sample of ServiceMeshControlPlane YAML file here

https://gitlab.com/workshop6/service-mesh/-/raw/master/install/basic-install.yml

Join namespace payment-frontend and payment-backend to payment-app-istio-system. This can be done by create Custom Resource Definition (CRD) called ServiceMeshMemberRoll (or smmr in shorten form) at control plane namespace. Following show sample ServiceMeshMemberRoll YAML file

apiVersion: maistra.io/v1
kind: ServiceMeshMemberRoll
metadata:
  name: default
spec:
  members:
  - payment-frontend
  - payment-backend

There is another flip side from ServiceMeshMemberRoll that is ServiceMeshMember. With ServiceMeshMember, you create this CRD at the namespace you want to join into the control plane. Following show sample ServiceMeshMember YAML file

apiVersion: maistra.io/v1
kind: ServiceMeshMember
metadata:
  name: default
  namespace: payment-frontend
spec:
  controlPlaneRef:
    name: basic-install
    namespace: payment-istio-system

Sidecar injection

OSSM works differently from its upstream that automatically inject sidecar to all pods in the namespace with label istio-injection=enabled but for OSSM you need to annotate deployment with sidecar.istio.io/inject: “true”. This is quite debatable that this may be more tedious but this also gives you more granularity to control with deployment to included into the mesh.

Example of how to annotate deployment e.g. Your deployment name is frontend then you can do something like

oc patch deployment/frontend -p '{"spec":{"template":{"metadata":{"annotations":{"sidecar.istio.io/inject":"true"}}}}}'

or put this part into your deployment YAML file.

spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: frontend
        version: v1
      annotations:
        sidecar.istio.io/inject: "true"

Remark:

The oc CLI is a tool provided with OpenShift. Yes, it provides some more features than kubectl and You still have flexibility to use kubectl if you want.

Kiali and Jaeger

OSSM comes with Kiali and Jaeger. Both are enabled by default. Then when you install and configure the control plane. You will automatically get the benefit of “Observability” from Kiali and Jaeger.

Kiali and Jaeger also authenticate with the same User ID and password that you authenticate to OpenShift. This can be done by OAuth2 authentication provided by OpenShift.

Here is some sample of “Visualization” provided by Kiali

Istio Container Network Interface (CNI)

One of the main components that cast magic spells to Istio is Envoy sidecar. Actually, It’s proxy. So, it needs to manipulate the iptables rules of node which that pod runs to make things happened. This is done by init containers.

Envoy itself does not need high privileges ( root) to run because it requires cap_net_admin privileges in their init-container state. Then, OpenShift Service Mesh use a much secure method that is istio-cni plugin to avoid this. This CNI plugin is responsible for manipulating iptables routing rules on pods.

That’s it! I hope this will help you to understand more about OpenShift Service Mesh and how it operates differently than its Istio upstream project.

If you interesting in playing with OpenShift Service Mesh. Let’s check this content.

Interactive Learning Portal

Learn OpenShift using interactive browser-based labs, powered by Katacoda.

learn.openshift.com

Have fun with Service Mesh!