Service Mesh in Micro service world of Kubernetes – Part 2

Istio is playing a big role in achieving Web/Service traffic control, security and observability management and implementation, so today i am covering some of the Istio Control Plane insight through mind map diagrams.

This blog is in continuation to previous blog(Service Mesh in Micro service world of Kubernetes – Part 1) in which i talked about architecture of service mesh and its component definition and compared with other available competitive alternatives in opensource market like Linkerd and today we are drilling those Istio control Plane component down for their actual implementation in service mesh architecture hosted on Openshift/Kubernetes(k8s).

NOTE: Istio utilizes data plane component(Envoy Proxy) to enforce configuration and policies set through Istio components(Like Pilot) but here in this blog we are only focusing on Istio control plan so please assume Envoy usage during feature management in following diagrams.

We built 2 mind maps that shows overall functionality/Features of the Istio in addition to independent components functionality.

Istio Service Mesh Functionality

                                       Fig 1. Istio Service Mesh Features

In Fig 1 we can see 5 major functionality of Istio Service Mesh that falls under following categories:

  1. Service Resiliency
  2. Observability
  3. Traffic Control
  4. Chaos Testing
  5. Security

All 5 functionality/Features are self explanatory so i am not going to explain them further as those can be read from Istio web site but i will talk about how easy it is for us to configure and implement these 5 features as per your product deployment requirements.

For an example Chaos Testing is hard to achieve or plan in micro service environment in which you will introduce false delay or false errors to test upstream application behavior but using Istio we can easily test such kind of scenarios using following simple resource configuration(Following we have also covered how you will deploy following 3 configurations using istioctl or helm):

No alt text provided for this image

Second example, Traffic Control where you can easily redirect traffic for different web client agents like Chrome, Firefox and Safari agents will hit their specific micro service. Below you can see “Match and route” keywords those are playing role in traffic redirection using Precedence keyword where Precedence decides priority of multiple RouteRules in configuration running on k8s cluster in your namespace:

No alt text provided for this image

Third example, Circuity breaker in which we can see how simply we can achieve it using DestinationPolicy resource type and defining properties related to Circuit Breaker using “circuitBreaker” keyword in configuration:

No alt text provided for this image

Now, question is how things are linked in Kubernetes/Istio/Deployment Tools like Helm or how you will feed above given examples in your Service mesh:

You can directly push above mentioned configuration using “istioctl” command , for an example following command is used to deploy above mentioned Circuit Breaker YAML on your NAMEPSACE

# istioctl create -f istiofiles/application_cb_policy_version_v2.yml -n NAMESPACE

But at enterprise level normally people use K8s package manager for deployment using Tools like “Helm”. Helm contains Templates,K8s Resource configuration in yaml, Charts, Value files to build and deploy on K8s and in helm you can easily manage above mentioned Istio traffic management, circuit breaker configurations and achieve expected results. Helm and deployments are altogether independent topics that i will cover in my upcoming blogs so skipping to cover those big topics here.

In below second mind map i am trying to relate it with their architecture level components where we are showing how Pilot, Mixer and Auth are helping to achieve required Service Mesh functionality.

No alt text provided for this image

Fig 2. Istio Control Plane Components and their usage in Service Mesh

Again, above components are self explanatory and you can read it on Internet and you can easily see related functionality provided by following 3 Istio Components:

  1. Pilot
  2. Mixer
  3. Auth

So to summurize this blog we covered 3 components of Istio Control Plane and then linked concerned functionality provided by these components. We given 3 examples about how related functionality can be achieved using Istio command line and covered how “helm” kubernetes deployment tool can be used to deploy K8s/Istio resource configuration.