In a previous article, we discussed the concept of Service Meshes. We explained the need for a service mesh in a microservices environment and we also scratched the surface by building a simple lab where we used Envoy, the de facto sidecar proxy. In this article, we get to know one of the most popular service-meshes out there: Istio. Let’s start by installing the framework on your existing Kubernetes cluster.
Istio provides a lot of features including:
- Service Discovery: among the most demanding challenges in a microservices architecture is the ability to keep track of the dynamically ever-changing services. For example, under high load, the environment may scale up by adding more nodes to sustain the load. When they’re no longer needed, nodes may be removed. Service discovery entails being constantly aware of the number and type of available services.
- Routing: if you haven’t used service meshes before, you’d be amazed by the amount of control and power that Istio provides with regards to network traffic. To whet your appetite, consider the following features:
- Advanced Load Balancing: while Kubernetes provides native support for load balancing, it only supports the round-robin mechanism. Through Envoy, Istio provides more algorithms like random, weighted, and least-request.
- Health Checks: I guess you already know that Kubernetes offers health and readiness probes. Those provide simple mechanisms for ensuring that the target service is not only up and running but also serving requests the way it should be. Istio builds upon this model and provides even more insight as to how the service is behaving on a message by message basis.
- Intelligent Deployments: since the early days of Kubernetes, people managed to find workarounds for advanced deployment techniques like Canary Deployments and A/B testing using a combination of Deployment and Service components. Istio already provides multiple deployment techniques out of the box.
- Built-in Circuit Breaker: Istio can automatically detect service failure and automatically stop sending requests to it. Periodically, Istio checks the service status and resumes sending requests once the service becomes healthy again.
- TLS And Access Control: Istio can easily implement HTTPS communication between different services. The key benefit here is that you don’t need to alter any part of the application.
- Network Telemetry: Istio provides a great deal of insight into the different metrics that are exposed by each network message. That includes latency, routes, and tracing the request across different services.
Istio Architecture And Components
Before moving on to the installation and the hands-on lab, it’s good to have a general idea about how Istio is built and its different parts.
Generally, Istio is comprised of two layers:
The Data Plane
This is where the sidecar proxy is deployed. Through Envoy, Istio is able to perform the telemetry, routing, service discovery, load balancing, and security.
The Control Plane
You might be asking: if the data plane is responsible for all those tasks, which represents - almost - all the benefits that Istio brings to the table, why is the control plane needed and what is it used for? Well, you can think of the control plane as the logistics part of Istio. For example, when a proxy container needs to communicate with another one, it needs to know the ID of the target service on the network. This information is provided through the control plane. Similarly, when a new service is added to the environment, service discovery is done through the control plane. Let’s have a look at the control plane components:
- Mixer collects different statistics sent by the proxy services. For example, how long a request took to complete. Mixer is also responsible for implementing policy checks. For example, you may want to limit the request rate from one service to another to be a specific number per second, Mixer handles enforcing this policy. In order for Mixer to do its job, it uses different Adapters. The Adapter abstracts the infrastructure so that Istio can transparently interact with different cloud providers. For example, the CloudWatch adapter enables Mixer to send metrics to AWS CloudWatch service. Similarly, the Fluentd adapter pushes logs to a fluentd daemon.
- Galley is responsible for interpreting the YAML files in Kubernetes and transforming them into a format that Istio understands. Galley makes it possible for Istio to work with other environments than Kubernetes since it translates different configuration data into the common format that Istio understands.
- Pilot transforms the configuration data from the format that Istio understands into Envoy configuration format. It is also responsible for propagating configuration to the different proxy services. Through Galley and Pilot, you don’t need to study or understand how Envoy is configured because both control plane components are responsible for taking the Kubernetes configuration and transforming it into something that Envoy understands.
- Citadel is responsible for handling TLS communication between different services on the system. Citadel manages the certificates necessary to handle HTTPS communication between the cluster components.
To understand how both planes work, let’s depict them in the following diagram:
There is more than one way to install Istio. In this lab, we are using the Helm Chart method. We are assuming that you already have an up and running Kubernetes cluster with Helm installed and configured. It doesn’t matter if the cluster is running on Minikube, Docker Desktop, or on one of the major cloud providers. The first step is to download the Istio package.
- Create the required namespace for Istio components to live:
kubectl create namespace istio-system
- Download the Istio package: at the time of this writing, the latest stable Istio version is 1.4.3. You can visit https://github.com/istio/istio/releases/ and pick the version and platform of your choice:
- Untar the package: tar -xf istio-1.4.3-osx.tar.gz
- Get inside the istio directory and run the following command:
helm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f -
- The above command initializes Istio by creating the necessary Custom Resource Definitions. Let’s ensure that the tasks are complete by running this command:
kubectl -n istio-system wait --for=condition=complete job --all
In a few seconds, you should have an output similar to the following:
job.batch/istio-init-crd-10-1.4.3 condition met job.batch/istio-init-crd-11-1.4.3 condition met job.batch/istio-init-crd-14-1.4.3 condition met
- Next, we need to use one of the provided Istio configuration profiles. A configuration profile is simply a mix and match of different Istio features. Think of them as ready made installation modes that help you quickly deploy the required Istio features without going too much into customization details. In this lab, we are using the demo profile, which enables us to play with almost all the features of Istio. Run the following command:
helm template install/kubernetes/helm/istio --name istio --namespace istio-system --values install/kubernetes/helm/istio/values-istio-demo.yaml | kubectl apply -f -
The command simply installs a Helm Chart in the istio-system namespace, gives it the name of istio and uses the already-supplied values in the values-istio-demo.yml file. This is effectively activating the demo profile.
- You may want to ensure that all the pods are in the running/completed state before moving on:
kubectl get pods -n istio-system --watch
- You will see several pods in the CrashLoopBackOff state. This is perfectly normal because pods have internal dependency between them. There may be a pod that is still starting while a dependent one is already trying to run but it is waiting for its dependencies to be available. In a few minutes, all of the pods should be running or completed (for the job pods).
A Note For GKE Users
If you are using Google Kubernetes Engine, you may not need to run the above steps; as Google allows you to include Istio as part of the managed Kubernetes installation. Just make sure you check the Istio checkbox when deploying the cluster. If you are using the command-line tool gcloud for deployment, you may want to check the documentation for command syntax to deploy an Istio-enabled Kubernetes cluster.
Now that Istio is up and running, you are ready to deploy microservices applications and make use of the power the service mesh provides you with. In future articles, we start exploring Istio further by deploying a sample application and playing with the different features Istio offers.
- Istio is one of the most well-known and used service meshes today. The technology was designed in a way that makes it useful not only through Kubernetes but also in any microservices architecture.
- Istio provides a lot of powerful features, some of which are already implemented in a very basic way in Kubernetes like load balancing. However, through Envoy sidecar, Istio is capable of providing powerful features that enables both visibility as well as fine-grained policy enforcement over the service network.
- Throughout this article, we demonstrated how easy it can be to install Istio on a standard Kubernetes installation using Helm Charts. Istio offers a number of ready-made configurations called configuration profiles to help you quickly set up and use the service mesh.