Dive into Istio Part-2

In part-1 we looked at how to install Meshery and, install Istio through Meshery or through the command line. Then we also deployed the sample application that is made available. Now let’s have a look at the sample application architecture.

Application Architecture

Modified diagram of L Calcote

The application displays information about a book. The application has four separate microservices written in four different languages namely Python, Ruby, Java, and NodeJS and hence a polyglot. What each and every service does is as follows,

• productpage: The productpage microservice calls the details and reviews microservices to populate the page.
• details: The details microservice contains book information.
• reviews: The reviews microservice contains book reviews. It also calls the ratings microservice.
• ratings: The ratings microservice contains book ranking information that accompanies a book review.

There are 3 versions of the reviews microservice:

• Version v1 doesn’t call the ratings service.
• Version v2 calls the ratings service, and displays each rating as 1 to 5 black stars.
• Version v3 calls the ratings service, and displays each rating as 1 to 5 red stars.

As shown in the previous article, when we run the application in an Istio enabled environment with Envoy sidecars injected alongside each service the resulting deployment will look as follows,

Modified diagram of L Calcote

I just confirmed that all the services and pods are correctly defined and running while writing this part, (kubectl get services, kubectl get pods )

Now let me also confirm that the application is running by sending a request to it from a pod
kubectl exec -it $(kubectl get pod -l app=ratings -o jsonpath=’{.items[0].metadata.name}’) -c ratings — curl productpage:9080/productpage | grep -o “<title>.*</title>”

Expose Product page via Istio Ingress

We can see the ingress gateway running (highlighted)

If the application was deployed using Meshery, you will have access to the product page already, without needing any configuration. To access the page visit http://localhost/productpage .

The product page of the sample application.

To do this manually
Define the gateway: kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml
Set gateway URL: export GATEWAY_URL=$INGRESS_HOST:$INGRESS_PORT
Now you should be able to navigate to the URL to see the product page. Also if you refresh the page you will see that the book review section changes from red stars to black stars to no stars and you know why. It is because the product page is talking to all three review services randomly.

You may access the ingress gateway with
kubectl -n istio-system exec -it <istio-ingressgateway-name> bash
You may also see the gateway configuration with
cat /etc/istio/proxy/envoy-rev0.json

There are some logical constructs that get added to the setup due to the availability of Istio, which vanilla K8s does not have. A list of those resources are as follows, Kubectl get crds

You may see the gateways and the virtualservices that are there in the list. While the ingress gateway allows the traffic in, the virtualservices help route the traffic in the right way.

As per the configuration, all the HTTP traffic is allowed in from port 80. Now let’s have a look at the config for the virtualservice.

All the http traffic reaching the gateway is routed to the productpage.

Observability

We can define monitoring as a function performed, an activity whereas observability is an attribute of a system. In observability, we take into account how and in what ways the system provides us with Signals to monitor. The process of recording and transmitting the readings can be defined as telemetry. The actions taken on this data such as checking the behavior, evaluating the state can be considered as monitoring.

let’s load some data and see telemetry. You may get the IP and the port respectively with ifconfig/ipconfig commands and kubectl get service istio-ingressgateway -n istio-system — template=’{{(index .spec.ports 1).nodePort}}’. In docker desktop you can resort to just using the IP. Mine is http://192.168.8.104/productpage . I’ll be using this in Meshery to generate load on the sample application as shown below.

In the performance tab, I’ll be giving the following parameters and will run a test.

When the test is running you will see the progress happening.

After the load was generated, you will see the test results,

Now let’s connect to Prometheus by exposing the service with NodePort, for which you need to change the service type from ClusterIP to NodePort. To do that,
kubectl -n istio-system edit svc prometheus
kubectl -n istio-system get svc prometheus

Shown below is a screenshot of Prometheus, where I have executed a query on istio_request_bytes_count.

t.

The same way you could connect and get measuring data through Grafana, Jaeger and Kiali to name a few.

There are a few other things for another day such as request routing, canary testing, fault injection, identity verification and etc.

Before I end the article since we discussed the application architecture, I would like to show you how to see that from a tool. Run the following command and the Kiali dashboard will open.
istioctl dashboard kiali
Use admin as user name and password. You may go and explore the tool to see various components.

I hope you enjoyed up to this point see you again.