Using Istio to Unify Microservices with a Service Mesh on Kubernetes

The lack of common infrastructure

In a typical Kubernetes environment, services related to tracing, load balancing, telemetry, routing logic, etc. are frequently used but are not shared. This means a microservices developer will have to write his own set of logic to enable shared functionalities.

At a recent Kubernetes meetup in Denver, Neeraj Poddar of Aspen Mesh brought up this very problem, which DevOps teams face when dealing with microservices.

Microservice stacks are completely separate in a typical environment (Image credit)

“If I’m an operator and I want to make sure that all the requests are sent the same way, I have to either go and make sure that application developers are listening to me to ensure that or going to be tough for me to debug things,” explained Neeraj. This way, a developer is not only concerned with building a business logic itself, but also the logic responsible for communication between microservices, which is an additional trouble in terms of effort and time.

“Imagine you’re an operator, and you have hundreds of these microservices, which have their own unique stack. There are various problems, which come up in trying to ensure uniformity across them.” —Neeraj Poddar, Aspen Mesh

Neeraj Poddar at the Kubernetes meetup in Denver

Neeraj then illustrated how this problem can be resolved through building a unified service mesh using the Istio platform.

Added control with a service mesh based on Istio

A service mesh is a configurable infrastructure layer that handles interactions between microservices. Commonly, a service mesh is implemented as a proxy in each container. In this scenario, the proxy is responsible for intercepting traffic that goes in and out of the application and then applies policies and functionalities that have been configured.

“A service mesh is essentially a common infrastructure fabric for handling communication between microservices. As an operator, you get back the control you want where you can insert uniform policies. As a developer, you don’t need to write extra logic.” —Neeraj Poddar, Aspen Mesh

All service-to-service traffic takes place on the service mesh (Image credit)

The Istio project is an open-source service-mesh architechture launched by Google, IBM, and Lyft. In Istio, the method of installing a proxy is called sidecar. Using this method, the proxy is installed as close as possible to the application. According to Neeraj, from the outside, you have a single view of the networking and security perspective, and you can also manage the life cycle of the proxy and the application container.

Istio deploys an extended version of Envoy as its sidecar proxy (Image credit)

“In Kubernetes, this means your sidecar proxy and your application container are both part of the same pod. As they are in the same pod, they are part of the same networking name space. From the outside, it feels like you’re talking to a single entity.” —Neeraj Poddar

Additionally, Istio separates the service mesh into two parts:

• The control plane manages and configures the proxies to route traffic.
• The data plane is made up of the Envoy proxies which are deployed as sidecars. These proxies manage traffic and communications between microservices and the Mixer, a component responsible for policy controls and telemetry collection.

Istio’s control plane is composed of the following components:

• Pilot provides service discovery for the Envoy proxies, traffic management capabilities for intelligent routing, and resiliency. Basically, it’s an abstraction layer, which allows operators to configure Istio using their platform-native language without worrying about the data plane.
• Mixer is where policy is reinforced, quota or rates are limited, and telemetry is collected from the Envoy proxies.
• Citadel provides service-to-service and end-user authentication with built-in identity and credential management. All the Envoy proxies get their own certificates and keys based on the service accounts.
• Sidecar injector is a Kubernetes webhook, which automates the insertion of the Envoy proxies. According to Neeraj, the sidecar injector looks at all the pods coming from the cluster and automatically inserts sidecar.

“Istio has a nice separation between control and data plane. This ensures that you can scale and upgrade them independently. Additionally, the Istio’s control plane itself is split up into various components based on functionality, which makes it possible for an operator to scale and upgrade them independently.” —Neeraj Poddar, Aspen Mesh

Istio is being actively developed. The project’s progress can be tracked in its GitHub. The Istio community also maintains quite extensive documentation.

More features for enterprises

After an overview of a service mesh built with Istio, Neeraj introduced Aspen Mesh—a supportive solution placed on top of Istio. Aspen Mesh runs in a Kubernetes cluster and feeds metadata to the cloud.

How Aspen Mesh interacts with a Kubernetes cluster (Image credit)

Aspen Mesh incorporates hosted Jaeger, Prometheus, and Grafana to provide the following enterprise features to Istio:

• added visibility into applications to see actual performance
• enforced compliance and security standards to keep services available
• integrated charts in the hosted Aspen Dashboard to provide insights across the microservices environment

“Aspen Mesh gives you insights on what is happening to your mesh, your cluster, as well as reduces the time it takes to detect failures and fix them. It also builds APIs on top of Istio for configuring security in your cluster.” —Neeraj Poddar

Neeraj Poddar at the Kubernetes meetup in Denver

As microservices evolve and gain popularity with organizations shifting away from monolithic systems, such tools as Istio are useful to ease the transition. It is likely that more solutions like that will appear soon to add more features for enterprise use.

Want details? Watch the video!

You can also check out the full presentation delivered by Neeraj.