Kiali releases 1.25 to 1.28 — Trace heat maps, enhanced health insights, multi-arch images and more…

More than two months have elapsed since the last blog post with feature updates. I hope soon to go back to the usual cadence of one post per Kiali release. In the meantime, I’m happy of closing the year with this last blog post of 2020 and no writing pending.

Talking about the last four releases, the usual feature update calls happened on time. These are the links to the recordings:

• Kiali v1.25 update (sprint 46) — about 25 minutes long
• Kiali v1.26 update (sprint 47) — about 11 minutes long
• Kiali v1.27 update (sprint 48) — about 31 minutes long
• Kiali v1.28 demo (sprint 49) — about 26 minutes long

A kindly reminder that Kiali and Jaeger teams are doing a joint presentation with updates on each project. I’m providing the full recording times, but Kiali’s presentation is only a part of the meeting.

In the presentation of Kiali versions 1.25, 1.27 and 1.28 there were live demos. I encourage you to watch them to get a better idea of the new features. Anyway, if you prefer to read, let’s start with the written updates.

Multi-architecture images are being released

Some people have missed support for architectures other than amd64. Frankly, the Kiali team is not capable of providing this, because everybody in the team is using devices based on amd64. So, we are looking for community support for architectures other than amd64.

This is a little what Morlay from the community has provided: he did the needed work to publish multi-arch Kiali images for amd64, arm64, s390x (IBM Z and LinuxONE), ppc64le (PowerPC). Kiali v1.28 is the first release being published for these architectures. Installation should be transparent: follow the usual installation guide and your platform should pick the right image.

Despite now publishing images for several architectures, it’s worth to emphasize that we are doing tests only under amd64. All others are untested. Unless it can be reproduced on amd64, you will need to contribute the fix for an issue encountered on another architecture.

Proxy sync status in health

In a Service Mesh, sidecars (aka proxies) are an important component of the mesh because all traffic of a pod is sent and received through the sidecar. Surely, a failing sidecar will most likely be the source of issues.

A sidecar can become unsynced if it fails to communicate with the mesh control plane. An unsynced sidecar will trigger a degraded health status to make it clear that some action is needed.

Healthy operand in graph find/hide

If your service mesh is large, you may get a crowded graph in Kiali. If you need to focus on workloads that are having issues, you can now use the healthy operand in the Find and Hide boxes:

The healthy operand works over graph nodes. Don’t expect it to highlight any edges 😉

Principals in graph side panel

If you are using authentication or mTLS in your mesh, Istio will record in the telemetry the identities used on each request. When selecting a graph edge, Kiali is now showing the involved principals on the side panel, if available.

Principals are relevant for Authentication and Authorization. By knowing the principals used within your mesh, you can setup fine grained security policies like allowing or denying specific requests to certain services.

Learn more in Istio’s Authentication and Authorization docs.

Improved design of details area in the Traces tab

In the details page of Applications, Workloads and Services, there is a Traces tab. See how it looks:

What you are seeing in the screenshot is what appears below the traces chart after you select a span. These are the enhancements:

• Trace Details and Span Details are now under a tab control. Previously, simple cards were used to display these sections, leading to some excessive scrolling when lists are large.
• Span Details is now using a sortable table. Also, filtering options were added (similar to Applications, Workloads, and Service list pages).
• In Span Details, a heat map was introduced in the Stats column. This heat map can be expanded if you click over it. This is explained in the next section.

I think the new design is nicer and cleaner. I hope you agree with me.

Trace heat maps

In the traces tab, you will see lots of heat maps! The first one you may see is in the tool-tip of a trace in the traces chart:

Also, the Trace Details sub-tab of the Traces tab got heat maps:

And, as already mentioned in the previous section, there are heat maps in the Spans Details sub-tab of the Traces tab:

The goal of all these heat maps is to give a comparison of the duration of traces or spans against other ones, and also against the stats of a set of requests over some time — in the last screenshot you can see its requests for the last 10 mins, 60 mins and 6 hours. Greenish squares indicate that the shown span is faster when compared with that set of requests. In contrast, reddish squares indicate that the span is slower.

Mirroring in Traffic shifting wizard

Traffic mirroring is an interesting concept where traffic going to a service is duplicated and is sent to an out-of-band mirror service.

Kiali’s traffic shifting wizard got the capability for configuring mirroring:

As shown in the video, click on the new button next to the pin button and the chosen workload will be moved out of the band to receive mirrored traffic.

New TCP traffic shifting wizard

The existing Traffic shifting wizard is creating configurations only for HTTP services. Any TCP services are unaffected by this wizard.

Istio differentiates HTTP and TCP traffic. So, Kiali is doing the distinction by providing one Traffic shifting wizard for HTTP and one for TCP. In the video of the previous section you may have seen the new entry in the actions menu. Anyway, this is the picture showing it:

I’m not giving a screenshot of the new TCP Traffic Shifting wizard because it’s very similar to its HTTP analog. The only difference is that options that are HTTP specific are removed in the TCP wizard.

Traffic tab rework

The traffic tab — available in Applications, Workloads and Services details pages — had a design rework. Currently, this is how it looks:

With the new look:

• Design is unified to the other list pages. As part of it, column sorting capabilities were added.
• Icons are removed. This was the last Kiali screen to move from icons to letter badges to denote a Workload, Application or Service.
• List is flat rather than in a tree. The tree had proven to be confusing and so we are preferring a flat list.

For reference, this is how this page looked in the past:

RBAC can be disabled in OpenID authentication

Kiali’s OpenID authentication strategy required to have a Kubernetes cluster with a tight integration with the OpenID provider, but this setup isn’t available in some cloud providers. Kiali required this constraint to make use of the cluster’s RBAC capabilities. However, we got the feedback that some people are OK with the shared privileges in Kiali when using OpenID authentication. Because of this feedback, we added support in Kiali to be able to turn off RBAC in the OpenID authentication. When RBAC is turned off it’s possible to use OpenID authentication even if your Kubernetes cluster is not integrated with your identity provider.

The Kiali docs are already updated and covering this scenario. Please, read them to learn how to setup Kiali with OpenID authentication and shared privileges (RBAC off).

Support for HTTP proxies for OpenID authentication strategy

This is yet another improvement for the OpenID authentication strategy, because of (again) more user feedback.

It turns out that some people setup their Kubernetes clusters without direct Internet access. An HTTP/HTTPS proxy is used as a gateway to the Internet. Clearly, workloads must be configured to use the proxy to reach the outside Internet. Then, depending on your needs, you may be using an external OpenID provider (like Google, Auth0, AzureAD, etc).

As Kiali was missing the needed configurations to make use of an HTTP/HTTPS proxy when needed, it wasn’t possible to use external OpenID providers without direct Internet access. But this is no longer the case. Starting Kiali v1.28, the required settings have been added. Read the short section in the website describing how to configure your proxy.

New validation for Istio’s DestinationRule CRD

Usually, in previous posts there are a few new Istio CRD validations to mention. This time, there is only one new validation:

• KIA0209 — DestinationRule Subset has not labels

As always, check the docs at the website for the full description of the validation.

For new Kiali users, now is a good time to point out that validations are shown in the Istio Config list:

You can also find the validations being raised in the YAML editor when you are inspecting a specific CRD instance. The editor will highlight the offending line:

There is also an indicator in the Overview page:

Finally, at the bottom of the Workload and Service details pages, there is an Istio Config tab that will show a warning in case of any validation issue:

Dropped support for Mixer telemetry

Mixer telemetry, a.k.a. telemetry v1, was removed in Istio 1.8. Kiali followed up and support for Mixer telemetry was removed in version 1.26.

Mixer-less telemetry, a.k.a telemetry v2, became the default configuration in Istio 1.5. By then, Kiali v1.17 included support for both the new and the deprecated telemetries and this support stayed in place until Kiali v1.26.

Because of all the removals, Istio 1.8 is the recommended minimum for Kiali v1.26, which may work for earlier Istio versions (without any warranty) but certainly won’t work with Istio versions prior to 1.5 because of the absence of telemetry v2.

This is properly documented in detail in our website in the version compatibility table.

Extended information about a pod status

When you are at the details page of a workload, at the bottom you have the list of pods supporting the workload. In that list, there is a Phase column that has been there for a while. That column is now showing extended information about the pod status and/or phase:

The main goal was to show if a pod is evicted rather than showing the generic Failed message. However, implementation is not looking for an evicted status, but fetching extended pod status from the cluster. Kiali will show this extended status in the phase column and, if possible, a tooltip will contain the details of the status.

“Select all” option in the namespace selector

Starting in Kiali v1.27, this is how the namespace selector is looking:

Visually, the only difference is the new, and very convenient, Select all option. It does almost what you think 😃 It’s behavior is impacted by filtering. So, if you have nothing in the text filter, it does the expected: it lets you to either select or deselect all items. However, if you have some text in the filter box, it will let you either select or deselect all the namespaces that currently match the filter.

There is also one change in behavior: changes to the selected namespaces are now applied when the selector is closed.

True full screen on logs tab

In the logs tab, maybe you have seen these buttons:

They are labeled full-screen. It’s meant to let you see the log panes in full-screen. However, the log panes were going full page rather than full screen. For Kiali’s convenience, let’s call this “fake full screen” 😉

Well… Starting Kiali v1.26, those buttons implement “real full screen” 👌.

Please, note that although similar “full screen” buttons are available on other Kiali pages, it’s only the log page implementing “real full screen”.

Zerolog

Since early releases of Kiali, golang/glog has been the supporting library for outputting log messages. It’s a simple library. But because of its simplicity, it falls short when structured logs are needed.

A community member helped into migrating to the rs/zerolog library, which offers a richer set of configuration options, plus the required JSON output to ease parsing logs.

Check the logger options of the kiali-operator CR to learn what configurations are exposed.

Envoy config dump

In the Workload detail page, you will find a new option in the Actions menu:

You probably may have heard about Envoy, but if not, Istio is using Envoy as its sidecar which is injected in your workloads. The Istio control plane pushes configurations to these sidecars to apply the configuration that you set via Istio CRDs.

Sometimes, you may need to fetch the configuration set in a pod sidecar — usually for debugging. This is what this new Show Envoy Details option is offering. The configuration in shown in a dialog:

Because a workload can be backed by several pods, the dialog lets you select the pod to inspect its sidecar configuration. There is also a Resources menu that lets you focus on a specific section of the sidecar configuration. The clusters, listeners and routes resources are parsed by Kiali and displayed in a user friendly list. For example, this is the view when you select the listeners resources:

This dialog is the equivalent of the istioctl proxy-config command line tool.

Custom dashboards can be disabled

Custom dashboards has been a Kiali feature since pre-1.0 versions of Kiali. Of course, it has evolved a lot! It was first named Runtimes monitoring because its goal is to let you configure a screen with customized charts/dashboards. An example metrics specific to certain frameworks like Go language, Vert.x, Quarkus and others. See the docs of this feature in our website.

As not everybody may be using this feature, we are giving the choice to turn off this feature. When turned off, you can skip installation of the supporting CRDs on your cluster.

History mode by parameter

For some users, in some environments, hashed URL paths work better than Clean URLs. So, a community user added a configuration option to let you switch to using hashed URLs paths (the default is still Clean URLs).

Currently, this setting is documented only in the operator’s kiali_cr.yaml sample file.

Stay in touch

This is it for this blog post. And also, this is it for the year! Thanks for reading up to the end of this post.

This is the last post of the year, because next Kiali release was going to be scheduled for January 1st, 2021. However, this release is canceled because most people in the Kiali team is taking a well deserved break and there won’t be a lot of new stuff. If all goes as planned, expect the first Kiali release of 2021 in January 22th!

As usual, my kindly reminder that Kiali is OpenSource and you can contribute to the project! Follow us on Twitter, provide feedback, spread to the world about Kiali.

In case you celebrate them, I wish you happy holidays and a nice start of the new 2021 year! In turn, please wish the Kiali team a productive 2021 😉

Up to the next year!