Kubernetes Service Mesh: Istio Edition

In Kubernetes, applications need to communicate with each other. This could be anything from backend apps needing to send information to each other or a frontend app (like a website) needing to send information to a backend API to make a request.

Application communication is also important outside of Kubernetes. It can be for on-prem applications or cloud-native applications running in a serverless architecture or a cloud virtual machine architecture. Service mesh isn’t anything new, but it is an important integration within Kubernetes.

In this blog post, you’ll learn what a service mesh is, why it’s important, and how you can get started with Istio.

Service Mesh Breakdown

A Service Mesh, inside and outside of Kubernetes, has one primary purpose; control how different parts of an application communicate with one another. Although a service mesh is specifically for applications, it’s technically considered part of the infrastructure layer. The reason why is because a lot of what a service mesh is doing is sending traffic between services, which is primarily a networking component.

A service mesh is broken up into two pieces:

• Control plane - this is like the “headquarters”. It handles the configuration for the proxy (the proxy is a big part of the Data Plane), encryption, certs, and configurations that are needed for the services to talk to each other
• Data plane - distributed proxies that are made up of sidecars. The sidecars are simply the “helper” containers. It contains the proxy information that tells services to talk to each other (which is what the core of a service mesh is doing).

So, in short; the control plane is what holds the configurations for the proxies and the data plane distributes those configurations.

Although the primary functionality of a service mesh for many organizations is the service communication, it can perform several other tasks including:

• Load balancing
• Observability
• Security including authorization policies, TLS encryption, and access control

Why a Service Mesh Is Important

You may be thinking to yourself aren’t microservices and Kubernetes already doing this for me? and the answer is sort of. Kubernetes handles traffic out of the box with Kube-proxy. Kube-proxy is installed on every Kubernetes worker node and handles the local cluster networking. It implements iptables and IPVS rules for handling routing and load balancing on the Pods network.

Although service communication works without a service mesh, you’ll get a ton of functionality including:

• It’ll be easier to troubleshoot network latency
• You’ll have out-of-the-box security between services. Without a service mesh, there’s no security between services. You could handle this with a TLS cert, but do you really want to add on more work from that perspective?
• Communication resiliency between services so you don’t have to worry about timeouts, retries, and rate limiting
• Observability for tracing and alerting

In reality, you’ll have service communication out-of-the-box with Kubernetes. The biggest reasons that you want to implement a service mesh is for security between services, easier service discovery, and tracing service latency issues.

Getting Started With Istio

Now that you know why you’d want to implement a service mesh, let’s learn how to do it! The installation process is pretty quick and only requires a few commands.

First, download Istio. The below command installs the latest version.

curl -L https://istio.io/downloadIstio | sh -

Next, change directory cd into the Istio folder. The version will depend on when you follow along with this blog post, but the directory will always start with istio

cd istio-version_number

The installation installs a few samples and manifests, but also the instioctl binary. To use it, put the binary on your path by running the following command.

export PATH=$PWD/bin:$PATH

Install Istio by running the following command:

istioctl install

The last step is to set a namespace label to automatically inject Envoy sidecar proxies for when you deploy your apps later. If you don’t set the namespace label, the sidecar proxy containers won’t automatically install in your Pod. By default, Istio doesn’t enable this setting.

kubectl label namespace default istio-injection=enabled

Congrats! You’ve successfully installed Istio.