Weaveworks 2022.03 release featuring Magalix PaC | Learn more
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 previous articles, we’ve explained the concept of service meshes, and we’ve also started exploring Istio as an example of the most popular service mesh applications. In this article, we get to start playing with Istio to understand the features and power it provides. We start by visiting one of the tools that ships with Istio: Kiali.
Note: This lab assumes that you have a working Kubernetes cluster, with Istio installed, and the demo configuration profile selected.
To understand the full potential of Istio, we need a typical microservices application installed on the cluster. Fortunately, Istio already provides one for us. The Bookinfo application is a book rating service. The application is made up of four microservices:
The client request is fulfilled through communication between all the microservices as depicted in the following diagram:
Now let’s deploy the application to the cluster. If you haven’t already done so, you need to download the latest Istio version from https://github.com/istio/istio/releases/. Uncompress the archive and from inside the directory, issue the following commands:
kubectl label namespace default istio-injection=enabled. While this command has nothing to do with the Istio directory we’ve just downloaded, it’s a prerequisite for Istio to work correctly. Istio, by default, injects the sidecar container in any namespace that’s labeled
istio-injection=enabled
kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml
kubectl exec -it $(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}') -c ratings -- curl productpage:9080/productpage | grep -o ""
kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml
kubectl -n istio-system get service istio-ingressgateway
export INGRESS_HOST=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].port}')
export SECURE_INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="https")].port}')
$ echo http://$INGRESS_HOST:$INGRESS_PORT/productpage
http://52.146.55.86:80/productpage
Open the above page in your browser, you should see a page similar to the following:
Now that we have our application deployed, let’s take a look at what Kiali can do for us.
Since Kiali is, by default, an internal service, you can access it in either of two ways:
kubectl -n istio-system port-forward svc/kiali 20001:20001
kubectl patch service kiali --patch '{"spec":{"type":"LoadBalancer"}}' -n istio-system
Then get the IP address and port:
kubectl -n istio-system get service kiali -o jsonpath='{.status.loadBalancer.ingress[0].ip}
kubectl -n istio-system get service kiali -o jsonpath='{.spec.ports[?(@.name=="http-kiali")].port}'
Navigate to the Kiali URL (for example, http://52.150.35.253:20001/kiali/) you should see a page similar to the following:
Use the following credentials to login:
The dashboard looks like this:
Let’s verify that our Bookinfo application is receiving traffic. Execute the following command:
curl -o /dev/null -s -w %{http_code} http://52.146.55.86/productpage
Instead of refreshing the page several times, we use the watch command to continuously send HTTP GET requests to the productpage service using the curl tool. We direct any output to /dev/null, use -s to suppress curl progress status and use -w to show us the HTTP code of the response message. Now, in a few moments, the Kiali dashboard should look as follows:
We see that we have traffic on the default namespace as well as on the istio-system. You can choose which namespaces to show traffic for by typing its name in the filter (Filter by Name).
You can visualize the services and their connections in a given namespace by clicking on the “Go To Graph” button as shown:
The resulting page should look as follows:
As you can see, the graph that Kiali generated for us is very close to the system diagram that presented when we were explaining the application’s architecture. This is an excellent way to get a general idea of how a given microservices application is working behind the scenes, which services talk to which, etc. Additionally, Kiali gives you even more visibility by showing you the different components of each part. For example, in the above diagram, we have a triangle and a square in the productpage service. The triangle corresponds to a Kubernetes Service while the rectangle represents the application. You can always view a quick reference of the symbols Kiali uses by clicking on the blue “Legend” button at the bottom.
If you have an eye for details, you may be wondering: “in the architecture diagram, only the reviews API versions 2 and 3 had active communication with the ratings API, why isn’t this shown by Kiali?” Fortunately, you can view that detail by selecting the “Versioned app graph” from the dropdown list as shown:
Now, the view should look like:
We mentioned before that Istio provides you with more control over how you want to load balance your traffic. So, while Kubernetes offers only the round-robin method of traffic distribution, through Kiali we can configure weighted routing. In weighted routing, you get to choose which backend service gets more traffic than the others. This is useful in scenarios where you need to do Canary Testing, where a small amount of traffic is routed to the app version with new features while the majority is directed to the old version. If no complaints were received and everything goes OK, more traffic is gradually diverted to the new app version. Assuming that v3 of the reviews app contains the new feature that we need to test, we can direct less traffic to it as follows:
In a few moments, you should see that v1 has no traffic, v2 has 70%, and v3 30%.
“The application is acting weird,” “We get random error messages,” and “The UI does not update in response to the user actions.” Those are sample complaints that you’d frequently hear when operating an application that has issues. Troubleshooting the problem is even worse when the application is using the microservices architecture. There are just too many moving parts and you need to examine each one separately to ensure that it’s working as expected. With dozens of microservices, this can quickly turn into a nightmare. Fortunately, Istio has got you covered. The Kiali application can give you great insight into how your services are doing and which ones are failing. Now, to reinforce what we’ve discussed, let’s work through a practical hands-on:
Empower developers to delivery secure and compliant software with trusted application delivery and policy as code. Learn more.
Automate your deployments with continuous application delivery and GitOps. Read this blog to learn more.
This article explains the differences between hybrid and multi-cloud model and how GitOps is an effective way of managing these approaches. Learn more.
Implement the proper governance and operational excellence in your Kubernetes clusters.
Comments and Responses