Azure AKS, Istio and Integration of these two.

Checking out the trend topics in DevOps. This is what a DevOps Engineer do frequently now and then. If you followed this path, you would see many content about Kubernetes and Service Mesh. In this article, I will explain the end to end integration of a popular service mesh tool called Istio on Azure AKS. Basic kubernetes knowledge is needed in order to complete the below demonstration.

Let’s start with what is “Service Mesh”. It’s basically a concept to have control over the all network in a single Kubernetes cluster. There are bunch of service mesh tools like Istio, Ambassador, Nginx Ingress, Linkerd etc. Istio is the one which is in our scope at the moment.

Istio may be easily installed by following the official documentation. We first need to install istioctl which is the command line utility of Istio before we start to install the Istio itself. This will allow us to interact with the Istio components. Here are the commands to install istioctl.

$curl -L https://istio.io/downloadIstio | sh — #download Istioctl
$cd istio-1.10.3 #change directory to Istio binary folder
$export PATH=$PWD/bin:$PATH #add the binary to your path

The current Istioctl version while writing this article is “1.10.3”. So it may vary while you are reading. You may have to change the version number accordingly. The installation folder above for instance.

Without a service mesh, any component in Kubernetes cluster communicates natively to each other. In pod terms, the container in pod sends a request to a service from the desired port.

Istio injects an envoy proxy container to each pod to intervene the network connection. After the injection, every pod communicates to each other through these envoy proxies. This method dramatically reduces the latency in pod level.

Let’s continue with the installation of Istio. It’s pretty clear like the installation of Istioctl. We will install Istio itself using istioctl. We have specified the profile as demo which only installs the basic components of Istio like istiocore, istiod, istio-ingressgateway and istio-egressgateway. This installation will assign two internal IPs. One as a kubernetes internal service with a virtual internal IP which is recognized inside of the kubernetes cluster (istio-ingressgateway). The other one placed on internal load balancer which is recognized inside of internal Azure network. (istio-egressgateway).

Switch context to desired Kubernetes cluster and run the following commands to install Istio.

$kubectl create namespace istio-system #create the namespace
$istioctl install — set profile=demo -y #install Istio
$kubectl label namespace samplens istio-injection=enabled #label ns

Notice that we have labeled the namespace called “samplens” with “istio-injection=enabled” label. Any pod created in this namespace after this operation will have the Istio’s envoy proxy container injected. You will see that the pod status is 2/2 not 1/1. This means that envoy proxy container is placed next to your application container.

Now that Istio is installed, let’s continue with how it works. We will just implement a DNS-based routing solution with Istio in this article. But be aware that Istio is capable of doing more than this. I assume that you have a working AKS cluster and its resources without an issue. Also you have a healthy application which is getting exposed from 80 port by a kubernetes service. This scenario can easily be implemented by launching sample NGINX pods and a corresponding service.

Istio’s base components are virtual gateways and virtual services. Those are proxies between your end-user and kubernetes pods. A virtual gateway should accept traffic from desired port. Also virtual service should be placed behind the Istio virtual gateway.

Istio Traffic Visualization

Primarily, we will implement the Istio virtual gateway by applying below YAML file. Note that you have to add a namespace line to below yaml file with the correct namespace info of your choice. This set of commands will create a virtual gateway which is tied to the actual gateway running on the internal load balancer of Azure. It will accept all the incoming 80 traffic from all variation of hosts.

$kubectl apply -f — <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
 name: istio-virtual-gateway
spec:
 selector:
   istio: ingressgateway
 servers:
 — port:
     number: 80
     name: http
     protocol: HTTP
   hosts:
   — “*”
EOF

We have a running virtual gateway. Now we will add a virtual service to our configuration. The virtual service is the key component doing all the heavy job.

$kubectl apply -f — <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
 name: sample-virtualservice
spec:
 hosts:
   — “nginx.sample.com”
 gateways:
   — istio-virtual-gateway
 http:
   — route:
       — destination:
           host: nginx-service.nginx-namespace.svc.cluster.local
EOF

After running the above set of commands, you will have a VirtualService resoure created. This VirtualService will capture the matched traffic according to the host URL from Istio Virtual Gateway and redirect it to the desired kubernetes service. In this case, it will capture all the traffic which has “nginx.sample.com” host in it and redirect to the service called “nginx-service”.

From this point, you have all the necessary Istio components up and running. I did not cover the Azure resources creation in this article. If you are using Azure Application Gateway to receive the initial traffic, edit it to send traffic to the Istio-IngressGateway’s IP. Then you should see that your desired URL will be accessed through Istio.

If you don’t want to use Azure App GW and still want to test this demonstration, you may login to any pod in the kubernetes network and send a request to the Istio-IngressGateway’s IP with custom host information in the header.

Hope this article helps anyone who wants to learn fundamentals of Service Mesh concept and basic usage of Istio. Feel free to ask your questions in comments section. I will try to answer them all.