Balance innovation and agility with security and compliance
risks using a 3-step process across all cloud infrastructure.
Step up business agility without compromising
security or compliance
Everything you need to become a Kubernetes expert.
Always for free!
Everything you need to know about Magalix
culture and much more
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.
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:
This is where the sidecar proxy is deployed. Through Envoy, Istio is able to perform the telemetry, routing, service discovery, load balancing, and security.
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:
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.
kubectl create namespace istio-system
helm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f -
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
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.
kubectl get pods -n istio-system --watch
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.
Self-service developer platform is all about creating a frictionless development process, boosting developer velocity, and increasing developer autonomy. Learn more about self-service platforms and why it’s important.
More and more businesses are adopting GitOps. Learn about the 5 reasons why GitOps is important for businesses.