Kiali releases 1.21 to 1.24 — What’s new in these two and a half months?
About two and a half months have passed since the last post commenting about new Kiali features. In this time, Kiali has had four releases.
This post is quite large; about 12 minutes of reading time. So, I’m not doing any intro. Let’s go directly with the feature updates.
About recorded demos, we only have available:
- the recorded demo for Kiali 1.24 — about half an hour long
- and the recorded demo for Kiali v1.21 — about 13 minutes long.
OK, let’s go with the updates!
The graph got several enhancements over the past four versions. So, I’m grouping together it’s enhancements.
Traces in graph
If you are using Jaeger with Istio for distributed tracing, you may already be using the Kiali features related to tracing like the Trace tab, and the combined view of spans within the metric charts.
That’s all good! But would you like if traces could also be in the graph? Now, they are! Take a look:
Click on a node of the graph, and Jaeger traces will be available in the side panel as a list in a new Traces tab. At the end of the list, there is a button to go to the Kiali traces page of the selected node. Click over a trace and it’s details will appear in the side panel, and the nodes involved in the trace will be highlighted in the graph. Also, in the details of a trace, you will be able to navigate over the involved spans and a link is provided to jump to Jaeger UI.
The animation is not showing it, but in the Traces page when you are inspecting a span a link was added to let you navigate to the graph:
When you use this link, the relevant graph node will be pre-selected, the nodes involved in the trace will be highlighted, and the side panel will also be showing the details of the relevant span.
OK, this is the first implementation. If you think it can be improved, share your thoughts!
Auto-completion for graph find and hide
The Find and Hide text boxes of the graph toolbar got auto-complete! Use the tab key repeatedly and it will show the attributes you can use to filter the graph. If you type a few characters in advance, pressing tab will show the attributes that begin with the provided text:
It is a simple auto-complete implementation. It only works with the available attributes, so don’t expect it to complete values nor operators. Also, it only takes the last word in the text-box and tries to complete that word regardless of the caret position. Despite its simplicity, we hope it’s useful.
Additionally, the Find and Hide boxes have the added support of mixing Node and Edge criteria and also it’s possible to mix AND and OR conditionals. Previously, these cases would cause an error.
Operation nodes in graph
There is an experimental Istio feature that lets you classify metrics based on request or reponse properties. This, basically, adds a new dimension (label) to the metrics stored in Prometheus, based on custom rules that you can define.
By default, Istio has pre-configured the
request_operation metric label for this feature. If you want to use another label, it’s possible with some additional setup. However, in Kiali the
request_operation metric label was used as a standard. Thus, in Kiali we are using the operation terminology.
If you are using this Istio experimental feature, you can see operation nodes in the graph by enabling the Operation nodes checkbox in the graph’s Display menu:
Graph drag and drop
Drag and drop is another “simple” feature that was added in the graph. It’s disabled by default. You can enable drag and drop by using the first button of the toolbar at the bottom. See it in action:
And by simple I mean that the scope was only to enable drag and drop. Positions won’t be saved. So, expect a graph re-layout when changing the namespaces to graph, when going to other pages and back to the graph, when drilling-down and going back to full graph, etc.
If you like this feature and would like to see a smarter behavior, let us know!
Across these four Kiali releases, Wizards received several updates to better align with Istio’s traffic management terminology.
Similarly to the graph, here are the changes in a batch:
New fault injection wizard
The fault injection wizard lets you specify whether you want to add a delay to the response of requests, and/or whether you want to inject faulty responses. In both cases, you can specify how many requests should be affected:
On the background, this creates the required VirtualService with the needed attributes to enable fault injection.
New request timeouts wizard
The request timeouts wizard lets you setup how much time to wait before a request is terminated with a timeout response. It also lets you specify the retry policy for failed requests:
Alike in the fault injection wizard, VirtualServices are the backing Istio CR enabling this configuration.
Suspend Traffic wizard is removed
On the background, the Suspend Traffic wizard was using a combination of traffic shifting and abort rules, making it redundant with other wizards that can handle traffic suspension.
This wizard was more a helper and is not part of the traffic management terminology used in Istio. Removing it made sense given that its functionality clashes with the other wizards.
Support for creating PeerAuthentication objects and Circuit breaking options
All wizards creating traffic rules (the ones in the Service details page) are now capable of creating PeerAuthentication Istio CRs. This option lets you specify the mTLS policy. The option is under the Traffic Policy tab of the wizards:
Also, all of these wizards also now include circuit breaking options, which allows specifying a limit on concurrent connections, and also allows configuration of outlier detection (control when a host is considered faulty and is ejected from the mesh):
As you may see in the images, the advanced options are now organized in a tab control. The growing number of advanced options deserved this organization.
Where is the matching routing wizard and the weighted routing wizard?
The Weighted routing wizard was renamed to Traffic Shifting. About the Matching routing wizard, it was renamed to a generic name: Request Routing. This is the image of the menu with all currently available wizards:
But, why did the Matching routing wizard get a generic name? Because it includes the request matching functionality and also combines the functionality of all other wizards. This lets you form complex routing rules:
You, first, setup all needed routing criteria using each tab on the screen. Once you have setup the routing rules across all tabs, you then click on the Add Rule button. The added rule will combine all criteria setup across all tabs.
…and let’s go back to the regular format of a plain list of feature enhancements.
Sidecar auto-injection control
In the Overview page, where you can see the list of all namespaces you have access, you can now enable and disable auto-injection of the Istio sidecar. You can control auto-injection using the relevant entries of the Kebab menu:
In the image, you are seeing the options when sidecar injection is already enabled in the namespace. When auto injection is not enabled, you would see a Enable Auto Injection option instead of the two highlighted options.
And, by the way, you may notice that the items in Kebab menu were rearranged to group together the “Show” options that redirect you to other Kiali pages.
Traffic policies actions
In the image of the previous point you may notice that there is a new Create Traffic Policies option. How does it work?
Assume the following typical graph of the Bookinfo demo application:
By using the Create Traffic Policies option of the Overview page, Kiali will create the required Istio AutorizationPolicies CRs to only allow the traffic flow as in the graph; i.e, if workloads try to do a different connection, that connection will be blocked by Istio.
If AuthorizationPolicies CRs are already in place, Kiali will instead show options to remove or update the Traffic Policies.
Traces tab in workload and service details pages
The Traces tab has been available in Kiali for a while, but it was only present in the Application detail page. In the last version of Kiali, this tab was added to both Workload and Service details pages:
This enhances feature parity across Kiali pages.
Regex support in logs filters and full-screen support
In the logs tab of the Workload details page, the Find and Hide text boxes already allow you to filter the pod logs to only see (or hide) the lines containing certain text. You now have the option to filter using a regex expression.
For example, in this screenshot the logs are being filtered to show the lines that contain either the “DEBUG” or “INFO” strings:
This page also got support for expanding the log panes to a full-screen view, which you can enable by using the new icon next to the “copy” button.
Workloads and Service details page showing related Istio CRs
In the Overview tab of the details page of a workload, an Istio Config sub-tab is added:
Quite intuitively, this tab will show Istio CRs that are linked to the workload being inspected.
This tab was also added to the Service details page, replacing the Virtual Services and Destination Rules tabs that were present in versions prior to 1.23.
Uniform view for Istio Config details and Galley error forwarding
When inspecting VirtualServices and DestinationRules, its details pages had an Overview tab. From all the supported Istio CRDs, these were the only two objects with an overview. So, user experience wasn’t uniform.
Since a sidebar is already in place in the YAML editor view, the information of the overview tab was moved to this sidebar. So, when inspecting Istio configuration, you will always see this uniform layout:
Another update of the YAML editor is that it will show you error messages emitted by Istio Galley when trying to save changes.
Istio Galley can prevent creation or updating Istio CRs if they contain errors. Kiali is now forwarding the error to the user, if any.
Requests with no response
When workloads are communicating with each other, not all traffic may flow correctly. There are cases when the response of a request may never arrive. In these cases, Istio records a zero response code in the telemetry.
Kiali wasn’t handling this special case, but now it is! This is what the graph and the side panel will show it ever happens in your service mesh:
Configurable behavior of health indicators
Kiali has health indicators in different pages. For example, this is the Overview page:
As you can see, one of the indicators is showing a degraded health of some applications.
These health indicators determined health status based on fixed rules that we thought were reasonably OK. Although no users have complained about these fixed rules, the capability to customize how health indicators behave is wanted by a few community users.
With the understanding that every app can have different tolerances to failure, the customization of health indicators is now possible. You can customize a different behavior in each namespace, resource type and even narrow down the customization to target specific resource names. Check the dedicated section in the Kiali documentation to learn all the details about how to configure health indicators.
There is a new validation to assist in finding potential Istio misconfigurations:
- KIA0105 — This field requires mTLS to be enabled. This validates that the dependency on mTLS is met when using Istio’s AuthorizationPolicies.
Also, a validation was revisited:
- KIA1106 — More than one Virtual Service for same host. This validation was modified to take into account that it’s valid to split a large VirtualService into several small ones.
Finally, with the introduction of the RequestAuthentication CRD in Istio 1.5, Kiali is now validating that CRs. As a side rework, some existing validations were upgraded to generic ones:
- KIA0502 and KIA1002 were replaced by KIA0002: More than one selector-less object in the same namespace
- KIA0503 and KIA1005 were replaced by KIA0003: More than one object applied to the same workload
- KIA0504 and KIA1001 were replaced by KIA0004: No matching workload found for the selector in this namespace
When Kiali validates RequestAuthentication CRDs, the new generics KIA0002, KIA0003, KIA0004 could be emitted if some potential issue is found.
About the removed ones, KIA05xx referred to PeerAuthentication CRDs, KIA1001 referred AuthorizationPolicy, and KIA1002 and KIA1005 referred Sidecar CRDs. Kiali is still validating these CRDs, but instead of emitting the specific error codes, the new generic error codes will be emitted.
Kiali operator Helm charts
Before Kiali v1.22, the recommended way to install the Kiali operator was through a Bash script. This wasn’t ideal for community, as Bash scripts don’t offer good transparency on what changes are being applied to the cluster.
Because of this feedback, the Bash script got deprecated, and starting Kiali v1.22, the recommended method to install the Kiali operator is by using Helm. The installation guide is already updated and the old Bash script is no longer maintained. Make the switch if you haven’t!
Kiali operator resource watching
The Kiali operator is now watching for changes in its created resources. So, if for some reason a user manually changes any of the Kiali resources involved in installation (like the Deployment, ConfigMaps, Services, etc) a reconciliation will be triggered to “fix” the manually modified resource.
This reinforces the fact that Kiali installation should be setup through the Kiali operator. Changes not made through the Kiali operator CR could be understood as an unauthorized change and the operator will try to revert the change.
LDAP and Login authentication strategies are removed
In Kiali v1.19 the LDAP and Login strategies for authentication were deprecated. These authentication strategies were removed and are no longer available, starting in Kiali v1.23.
If you update Kiali regularly, you may already have noticed this. But if you don’t, this is a word of warning in case you are using any of those removed authentication strategies.
OpenID authentication strategy enhancements
Together with the deprecation of LDAP and Login strategies, support for OpenID authentication was introduced in Kiali v1.19, but only the Implicit Flow of the OpenID spec was supported.
Starting Kiali v1.24, support for the Authorization code flow of the OpenID spec was added. In general, this is the recommended OpenID flow to use. So, we recommend configuring Kiali accordingly enable usage of this flow.
Also, support for API proxies (like kube-oidc-proxy) was added. This is useful when you are using managed Kubernetes and your provider does not support configuring OpenID integration. In these cases, you still can use OpenID by using proxies to the Kubernetes API and Kiali now supports these setups.
Experimental support for Central Istiod
There is an experimental Istio feature called Central Istiod. Under this setup, you have two Kubernetes clusters. You install the Istio control plane in one cluster. Then, the other cluster serves the workloads.
The Central Istiod feature is still in its early stages of development; no formal Istio docs yet. Regardless this, a community user contributed some code to add support for Kiali to work when Istio is installed in a Central Istiod flavor. As this Istio feature is experimental, Kiali support for it is also experimental.
Documentation of this experimental feature is in the Kiali repository README file. Try it if you are interested. Your feedback will be appreciated in both Istio and Kiali projects.
Stay in touch
This post was quite large, but you can see that four releases contain quite a lot of updates! Did you already know all this? I hope you did.
Thanks for reading up to the end of this post. I end up with the usual words: remember that Kiali is OpenSource and you can contribute to the project! Follow us on Twitter, provide feedback, spread to the world about Kiali. Embrace the project.