Exploring Kiali Dashboards

We’re about to explore Kiali as an alternative, or a complement, to Grafana dashboards. Before we do that, please cancel the tunnel to Grafana by pressing ctrl+c

Like with Grafana, we won’t go into detail; we’ll only take a quick look at Kiali. I will assume that you’ll explore it in more detail later on. After all, it’s just a UI.

Unlike Grafana, which is a general dashboarding solution that works with many different sources of metrics, Kiali is specific to service meshes. It visualizes network traffic.

Opening up the Kiali dashboard#

Let’s open it and see what we’ll get.

Just like with Grafana, we created a tunnel to Kiali, and you should see it in your browser.

We’re presented with a screen that expects us to enter a username and password. Unlike Grafana that comes without authentication by default, Kiali requires us to log in. However, we cannot do that just yet because we did not create a username and password. Kiali expects to find authentication info in a Kubernetes Secret, so we need to create it. To do that, we’ll stop the tunnel first.

Creating a Kubernetes Secret for authentication#

Press ctrl+c to stop the tunnel and to release the terminal input, before we create the Secret.

echo "apiVersion: v1kind: Secretmetadata:  name: kiali  labels:    app: kialitype: Opaquedata:  username: $(echo -n "admin" | base64)  passphrase: $(echo -n "admin" | base64)" \    | kubectl --namespace istio-system \    apply --filename -

The command we just executed output a YAML definition of a Kubernetes Secret. We used base64 to encode the username and the passphrase since that’s the format Secrets expect. The output was piped into the kubectl apply command. As a result, now we have the Secret that will be used by Kiali.

Restarting Kiali and opening the dashboard#

However, Kiali can detect authentication Secrets only during boot, so we’ll need to restart it.

Kiali was restarted, and, as a result, it should have caught the Secret. We should be able to log in.

Let’s go back to the dashboard and see whether we can authenticate.

Please login with admin as both the username and the password.

Now that we’re authenticated, we can see the overview screen.

Exploring the Graph dashboard#

Click the Graph item from the left-hand menu and select the Namespace go-demo-8.

We can see all the applications in the selected Namespace. There are three of them, and we can see that the traffic flows from the Gateway to the repeater. From there, it’s being forwarded to go-demo-8, which communicates with the database (go-demo-8-db). It is a handy way to deduce the flow of traffic and potential problems related to the communication between different components.

Kiali vs. Grafana#

Just like with Grafana, the goal is not to show you everything you can do with Kiali. I believe that you are capable of exploring it in more detail yourself.

What matters, for now, is that we have the tools to visualize what is happening on the networking (Kiali) as well as on any other levels (Grafana). Since Kiali is focused only on service mesh and networking, it is probably a better source of information related to the flow of traffic. Grafana, on the other hand, is more general, and it can visualize any metric stored in quite a few different sources. In our case, that’s Prometheus, but it could be others, like Elasticsearch. Both have their strengths and weaknesses. So,for the purpose of our experiments, we’ll use both. Soon we’ll jump back to Grafana, so please stop the tunnel to Kiali by pressing ctrl+c.

Before we proceed, I must clarify something. We’ll be watching dashboards for a while. However, they are not the end goal. Instead, they are a means to an end. We should use them to detect patterns. They are helpful to find out what goes where, and how, and when. However, once we identify the patterns, we might stop watching dashboards and create alerts. The ultimate goal should not be to stare at screens with “pretty colors,” but rather to be notified when events that require our attention happen.

My preference for alerting is Alert Manager, which is available in Prometheus. That does not mean that other alerting solutions are not good, but rather that I feel more comfortable with it than with other similar applications. Being integrated with Prometheus helps.

What is our goal regarding these dashboards?#

Anyways, the goal is not to watch dashboards indefinitely, but only to observe them as a learning experience that will allow us to create alerts. The final objective is to be notified whenever there is something wrong inside of our clusters.

Now that we have added a few new tools to the mix, even though we didn’t explore them in detail, we’ll see how we can use them in conjunction with chaos experiments.

In the next lesson, we will get prepared for running chaos experiments again and aim to terminate instances.