Kiali Releases v1.18 & v1.17 — improved list pages, Istio 1.6 support and more

Edgar Hernandez
Kiali
Published in
8 min readJun 2, 2020

Once again, another two sprints elapsed since the last sprint update. Along with this, two minor Kiali releases were published: 1.17 and 1.18. In particular, version 1.18.0 was released one week in advance because Istio 1.6 was going to be released and we wanted it to ship the latest available Kiali. After that, we released Kiali 1.18.1 to include all the work of Sprint #39 — so, version 1.18.1 is conceptually more like a regular release rather than a patch.

I hope you are already enjoying the latest releases of both Kiali and Istio, which are version 1.18.1 and 1.6, respectively.

Regarding Kiali, I’m happy to share the recordings of the demos for the last two sprints:

In case you prefer to read, read on to know the latest enhancements!

Creation of AuthorizationPolicy from Istio Config

The New Istio Config Wizard is now capable of creating AuthorizationPolicy Istio objects. Modification is not yet supported. If you need to do changes, use the YAML editor to modify the resource.

Logs tab with split view

In the Workload details page pods logs are available via the Logs tab. It is useful to be able to inspect logs of a pod. If your pod is part of the Istio mesh, it will have a sidecar and it is also quite useful to be able to inspect side-by-side the logs of the pod and the logs of the sidecar and this is now possible:

Scrollbars are not synced, though. It’s not trivial to show matching lines because formatting varies.

Auto-refresh was also incorporated and, with it, the refresh interval drop-down was also added (it’s the one next to the refresh button).

Graph toolbar in two rows

The graph toolbar was large enough to wrap to a new line in some screens. For consistency across all Kiali pages, we were trying to keep the namespace drop-down alone on its own line. The graph toolbar was placed below the namespace drop-down but the toolbar didn’t fit on some screens and some people were seeing 3 rows of options.

We know that the graph is the important component of this page which has already suffered several changes on the toolbar to use available space efficiently. This is yet another iteration to improve the usage of the available space. The top drop-downs now define your graph while the bottom is dedicated to display options:

Once again, we hope this improves usability of the graph page.

Auto-refresh in list pages

Some time ago, list pages were displaying data that was mostly static and auto-refresh was not really needed. However, list pages have incorporated new data and, in particular, indicators for health and Istio config validations were introduced in past versions. Because of these indicators, auto-refresh now makes sense and it was added to applications, workloads and services list pages. With it, the refresh interval drop-down was also added:

Labels in Overview and list pages

Recently, we introduced the ability to filter list pages by label and also the Overview page got this filter, but the experience of filtering by labels and not being able to see the labels was not optimal. So, a new Labels column was added in list pages:

In the case of the Overview page, a label indicator was added to the cards of the compact and expanded views. A tooltip will show the list of the labels:

If you use the list view of the Overview page, the Labels column is added like in the list pages. For what is worth, the list view of the Overview page, with all its enhancements, has reached feature parity of the other list pages. It has filtering, sorting, health indicators and other features:

Add support for the newer Istio Config objects

Istio 1.5 and 1.6 added the following new Custom Resources and support for listing them in Kiali in the Istio Config pages was added:

  • PeerAuthentication
  • RequestAuthentication
  • WorkloadEntry

With regards to PeerAuthentication and RequestAuthentication custom resources, if you didn’t know already, these resources were introduced in Istio 1.5 and replace the alpha version of the Authentication API (Policy and MeshPolicy resources). The alpha version of the Authentication API is removed in Istio 1.6. As a result, Kiali features related to mTLS were affected and had to be adapted to, instead, use the new resources. Because of this adaptation, Kiali versions 1.18.1 and greater are backwards incompatible with Istio 1.4 and prior versions. This shouldn’t affect many people given that Istio 1.4 enters end-of-life on June 5th.

Istio component status in masthead

Kiali is providing lots of tools to monitor your applications that are part of the Istio Service Mesh. But, what about Istio itself? Is it working correctly?

Several components form Istio, even in 1.5+ releases which are “embracing the monolith”. And you know: if one Istio component fails, the whole Service Mesh may misbehave. Kiali will now show an indicator in the main header if an Istio component looks bad:

We hope you will never see this new indicator — that’s a sign of all Istio components looking good. But if something fails, we hope this indicator is useful.

Idle indicator in overview

In the past, if a deployment was scaled down to zero, Kiali classified that as a problematic workload and showed an error status. But that’s not entirely true, because the workload is in the desired state. Thus, a third state named Idle was added to status indicators to not show an error for workloads scaled down to zero.

Removed RBAC limitation from token authentication strategy

In non-OpenShift environments, if you wanted to share Kiali with several users, you either needed to use shared credentials of the login strategy, or use the token strategy for authentication. There is also the anonymous strategy that doesn’t require credentials to access Kiali.

In teams of several members, it is desirable to use role-based access and we got this request to be implemented in Kiali. The strategy that offered the closest to RBAC was the token strategy, but it had the limitation that the token must have read privileges on all namespaces accessible by Kiali.

Starting Kiali 1.18.1 the limitation of the token strategy has been removed and it’s now possible to use it for proper RBAC for users.

TLS 1.1 or lower is banned

If you configure Kiali for HTTPS, it will now reject clients that are trying to negotiate connections using TLS versions prior to 1.1.

TLS 1.1 is a protocol that was defined in 2006. It’s quite old and there are vulnerabilities on it. Major browsers won’t use this old version, so you won’t notice this ban. This is just a small update to keep Kiali safer.

New repository for Kiali Operator

The code of the Kiali Operator was hosted on the kiali/kiali GitHub repository until release v1.17. Now, the operator code is on its own kiali/kiali-operator GitHub repository.

Historically, the operator container image is released together with the Kiali application container images. Versions of both container images were synced and the release process was a joint process for both artifacts. Although currently the release is still being done at the same time, the release process is now more de-coupled and there exists the possibility to release each artifact independently.

This move was motivated mainly to make possible for the operator to support installing several Kiali versions and not only the one that matches the operator version. We know that the operator has offered the possibility to specify the Kiali image tag to deploy. The issue was that if something important changed (like new or removed configuration options, changed CRD schemas, etc.), then either the operator would fail installing Kiali, or Kiali may not work correctly. With this de-coupling, we are aiming to make the operator install Kiali properly using whatever image version you want to try. Of course, this also makes it potentially possible to release each part at its own pace.

On another point of view, the operator code has grown and is now quite complex. Under this perspective, it also made sense to create a repository to host the code of the operator.

Providing YAML file to install Kiali Operator

A few times, the team has been contacted by people asking if there is a way to install Kiali via a regular YAML file instead of using scripts. Everybody had his own reason, but the take-away is that not all people like the idea of running a script.

So, if you don’t like the install script, we are now providing a YAML file to install the Kiali operator. You download the YAML from the GitHub repository of the operator. It’s located on the path deploy/kiali-operator-all-in-one.yaml . Use the tag of the operator version you are interested in. For example, for Kiali v1.18.1, find it here.

Run as non-root

Kiali versions prior to 1.18.1 were running using the superuser. It’s not bad that containers run using the root user and there are images that require superuser privileges to run correctly. However, in the container world, it’s a best practice to avoid running as the superuser, which goes in line with the least privilege principle.

Certainly, Kiali doesn’t require superuser privileges to run correctly. Thus, Kiali containers will now run using a regular user.

Versioned documentation in website

With Kiali being released every three weeks most of the time, it was hard to point users to the right documentation depending on the installed Kiali version. This is the reason we are now publishing documentation for each minor Kiali release. Find the archives in https://kiali.io/documentation/archive/:

Having versioned docs was a necessary first step to improving the Kiali documentation. We will be reviewing structure and content going forward!

Stay in touch

That’s the update these these two Sprint releases. Remember that Kiali is OpenSource and we encourage people to share feedback! We encourage the community to guide the direction of the project! Do you think something is wrong? Do you think something can be improved? Would you like a feature? Let us know! Contribute to the project! Read https://kiali.io/contribute/ to learn how.

--

--