Getting “Meshy..” with Istio Part-1
The void being filled
I wanted to try out Istio and I’ll share what I learned, so you know this is not a production system experience. Before I get into details of a service mesh or Istio let me explain the void it fills in simple terms.
We had the components of a microservice designed in a way similar to what is shown below.
As you may see there are certain cross-cutting concerns that will be duplicated across services such as discovery, load-balancing, resiliency and etc. The purpose of doing a single thing well and being isolated is lost among various other benefits that come with the microservices approach due to cross-cutting concerns being duplicated. Then we found two places where we may place some of those components, one is the API Gateway and the other being the Service Mesh.
First, let’s look at how it would stack up in an API Gateway. I am maintaining the blue/white color combination to show the crosscutting concerns being in different setups.
When you look at the complexity, comparatively this is an easier approach than going for a service mesh and might be good enough for your business scenario. But at the same time, this could be considered a single point of failure while there are a few ways to introduce availability. Still, the API gateway is more to do with North to South traffic, what about East, West traffic. How can you secure that traffic? Is the network always reliable? If you look at the fallacies of distributed computing, you get the answer no. ( https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing ) . The tooling and infrastructure to quickly deploy and manage polyglot services are becoming mature but we are missing similar capabilities with regards to service interactions. So you’ll see that there is still some more space that could be filled. When we introduce service mesh, this is how our services will look like.
And the following diagram will further illustrate the void being filled, showcasing the capabilities that get added on top of K8s.
The Istio Architecture in brief
The Istio service mesh is primarily composed of two major sections known as the data plane and the control plane. This could be depicted as follows,
Data Plane: Intercepts all inbound(ingress) and outbound (egress) network traffic allowing your microservice to invoke remote HTTP endpoints.
Service Proxy: The service proxy acts as an intermediary/intercepter and the default proxy for Istio is based on Envoy proxy. The capabilities provided include service discovery, circuit breaker, automatic retries, security, load-balancing for HTTP 1.1/2 and gRPC. It also has the ability to trace spans, collect metrics, inject faults and much more.
Sidecar: With Istio, a second Linux container (istio-proxy)is injected into the pod that houses your microservice. Since this intercepts ingress and egress traffic,
1)new policies can be applied to reroute traffic
2)access control lists or rate limits
3)monitor and trace data
4)Introduce chaos such as network delays..etc
Control Plane: Is responsible for configuration and policy and making the data plane usable in a cluster consisting of many pods across a number of nodes.
Pilot/Galley: Is responsible for managing all the microservices’ sidecars. Provides services such as service discovery and support for virtual services. Manages sidecar configuration.
Mixer: With this, you can create policies, apply rate-limiting, and capture custom metrics.
Citadel: Also known as IStio CA or Auth, is responsible for certificate signing, certificate issuance, and revocation/rotation. Encrypts all traffic.
Let’s get going…
Make sure you have docker desktop installed.
Enable Kubernetes since we need a Kubernetes cluster. Make sure the version is greater than v1.9 . I am running,
You may do well with 4GB memory and CPUs:6 for docker.
Now let’s install Meshery, which is a multi-service mesh management tool. You can manage lifecycle, configuration and performance management of service meshes and applications running atop with this.
Using brew
brew tap layer5io/tap
brew install mesheryctl
mesheryctl start
This should open your default browser with the dashboard. For details on installing visit https://github.com/layer5io/meshery . If the browser tab does not open navigate to, http://localhost:9081
Having Meshery gives you two options to install Istio. You can install through Meshery as follows, by clicking on “latest Istio with mTLS” which pops up when you click on + sign.
Else you can manually install with,
curl -L https://git.io/getLatestIstio | ISTIO_VERSION=1.3.0 sh -
You will have to add the istioctl client to your PATH environment variable,
cd istio-*
export PATH=$PWD/bin:$PATH
After installing I checked as follows,
You may check if the cluster is ready for install,
istioctl verify-install
Install istio custom resources with
for i in install/kubernetes/helm/istio-init/files/crd*yaml; do kubectl apply -f $i; done
Get sample deployed with,
kubectl apply -f install/kubernetes/istio-demo.yaml
You may also do this with the UI of Meshery, by clicking “Manage Sample Application Lifecycle”.
As you can see, the pods were installed with two containers in the default namespace by Istio, the app service container, and the proxy container.
Now that the application is running in containers, we can perform various tasks such as automatic and manual sidecar injection, expose bookinfo via istio ingress gateway, distributed tracing and , Canary testing to name a few. Since it’s late, I just added Part-1 to the heading so that I could write about the above-mentioned areas in another article.
Thanks for reading. Hope you enjoyed.