Features

Colors in the graph represent the health of your service mesh. A node colored red or orange might need attention. The color of an edge between components represents the health of the requests between those components. The node shape indicates the type of component such as services, workloads, or apps.

The health of nodes and edges is refreshed automatically based on the user’s preference. The graph can also be paused to examine a particular state, or replayed to re-examine a particular time period.

You can drill down into one selected component, whether it’s a service, a workload, or an application. Kiali offers detail graphs for any node you choose.

Double click on a graph node and you can see a detailed view centered on that component. It shows you only the incoming requests being served and the outgoing requests being made - all from the point-of-view of that component’s telemetry.

You can jump back to the main graph and continue where you left off.

Want to get a quick summary of anything in the graph? Select any node with a single-click and the side panel provides a brief summary for that component. This includes:

Or, click the graph background and the side panel to view an overall summary for the entire graph.

Kiali offers several display options for the graph, including traffic animation.

For HTTP traffic, circles represent successful requests while red diamonds represent errors. The more dense the circles and diamonds the higher the request rate. The faster the animation the faster the response times.

TCP traffic is represented by offset circles where the speed of the circles indicates the traffic speed.

Kiali offers four different graph renderings of the mesh telemetry. Each graph type provides a different view of the traffic.

Graph replay is a new feature that lets you examine the past state of your service mesh.

Istio v1.6 introduced Request Classification. This powerful feature allows users to classify requests into aggregates, called "Operations" by convention, to better understand how a service is being used. If configured in Istio the Kiali graph can show these as Operation nodes. The user needs only to enable the "Operation Nodes" display option. Operations can span services, for example, "VIP" may be configured for both CarRental and HotelRental services. To see total "VIP" traffic then display operation nodes without service nodes. To see "VIP" traffic specific to each service then also enable the "Service Nodes" display option.

When selected, an Operation node also provides a side-panel view. And when double-clicked a node detail graph is also provided.

Because operation nodes represent aggregate traffic they are not compatible with Service graphs, which themselves are already logical aggregates. For similar reasons response time information is not available on edges leading into or out of operation nodes. But by selecting the edge the response time information is available in the side panel (if configured).

Operation nodes are represented as pentagons in the Kiali graph:

The overview tab provides detail information, a contextual graph and health overview for a specific Application, Workload or Service.

For each type of element, Kiali adds additional features.

In the Workload Overview, Kiali performs several validations on workload configuration:

Workload detail shows the services for which the workload in handling requests, and the pods backing them.

The Service Overview shows the workloads running the service. It also shows the Istio traffic routing configuration, VirtualServices and DestinationRules associated with the service.

Kiali provides access to YAML definitions and allows modification and deletion access for authorized users. It provides wizards to assist in common configurations and performs additional validation on VirtualServices to detect misconfigured routes.

Both Workload and Service detail can be customized to some extent, by adding additional details supplied as annotations. This is done through the additional_display_details field in the Kiali CR or ConfigMap.

The traffic tab collects all connections from and to a specific Application, Workload and/or Service.

It groups them in Inbound and Outbound tables providing traffic details and links to specific detailed metrics.

The Workload detail offer a special Logs tab. Kiali allows side-by-side viewing of both the application and the proxy logs of a selected pod.

The logs tab adds additional filtering capabilities to show or hide specific lines.

Each detail view provides predefined metric dashboards. The metric dashboards provided are tailored to the relevant application, workload or service level.

Application and workload detail views show request and response metrics such as volume, duration, size, or tcp traffic. The traffic can also be viewed for either inbound or outbound traffic.

The service detail view shows request and response metrics for inbound traffic.

Kiali comes with default dashboards for several runtimes, including Go, Node.js, Spring Boot, Thorntail, and Vert.x.

These dashboards are simple Kubernetes resources, so you can use your favorite tool to create, modify or delete them. As they are defined as plain YAML or JSON files, so it’s easy to keep them in source control like Git, track their changes, and share them.

Check out the documentation page to learn more about it.

Kiali has now a Span duration legend item on Service Metrics tab, when enabled, correlates Span and Metrics on the same chart.

User can navigate to the traces tab to browse filtered traces for a given service in the time interval or to show details for a single trace.

The tracing toolbar offers some control over the data to fetch, to facilitate the user experience. In the tracing view, as shown in the image below, it’s possible to select the traces interval, results limit, status code, errors, adjust time (expand results on time), last Xm traffic (Traces from last minutes) and refresh interval.

After selecting a trace, Kiali shows the information related to that trace like number of spans, spans grouped by operation name, duration, date.

The Request Routing Wizard allows creating multiple routing rules.

Istio applies routing rules in order, meaning that the first rule matching an HTTP request performs the routing. The Matching Routing Wizard allows changing the rule order.

The Fault Injection Wizard allows injecting faults to test the resiliency of a Service.

The Traffic Shifting Wizard allows selecting the percentage of traffic that is routed to a specific workload.

The Request Timeouts Wizard sets up request timeouts in Envoy, using Istio.

Traffic Management Wizards have an Advanced Options section that can be used to extend the scenario.

One available Advanced Option is to expose a Service to external traffic through an existing Gateway or to create a new Gateway for this Service.

Traffic Management Wizards allows defining Circuit Breakers on Services as part of the available Advanced Options.

Traffic Management Advanced Options allows defining Security and Load Balancing settings.

A Workload can be individually annotated to control the Sidecar Injection.

A default scenario is to indicate this at Namespace level but there can be cases where a Workload shouldn’t be part of the Mesh or vice versa.

Kiali allows users to annotate the Deployment template and propagate this configuration into the Pods.

Show actions navigate from a Namespace to its specific Graph, Applications, Workloads, Services or Istio Config pages.

When Automatic Sidecar Injection is enabled in the cluster, a Namespace can be labeled to enable/disable the injection webhook, controlling whether new deployments will automatically have a sidecar.

Kiali can generate Traffic Policies based on the traffic for a namespace.

For example, at some point a namespace presents a traffic graph like this:

And a user may want to add Traffic Policies to secure that communication. In other words, to prevent traffic other than that currently reflected in the Graph’s Services and Workloads.

Using the Create Traffic Policies action on a namespace, Kiali will generate AuthorizationPolicy resources per every Workload in the Namespace.

Kiali allows creation of Istio AuthorizationPolicy resources:

Istio PeerAuthentication resources:

Istio RequestAuthentication resources:

Kiali uses Istio Wizards to generate Istio Traffic config for a specific Service, but Kiali also allows creation of Gateway, ServiceEntry and Sidecar Istio resources for more generic scenarios.

Istio Gateway resources:

Istio ServiceEntry resources:

Istio Sidecar resources: