Kiali helps you define, validate, and observe the connections and microservices of your Istio service mesh.
Kiali works with Istio in Kubernetes distributions. It visualizes the service mesh topology and provides visibility into features like request routing, circuit breakers, request rates, latency and more. Kiali offers insights about the mesh components at different levels, from abstract Applications to Services and Workloads.
Kiali also helps to manage the Service Mesh providing Wizards to apply common traffic patterns and automatically generate Istio configuration.
- Observability Features
- Configuration and Validation Features
- Multi-cluster support
- Useful resources
The following observability features help you ensure your mesh is healthy or to quickly identify problem areas in operation. It combines topology, telemetry, traces, logs, events and definitions in a holistic view of your system.
Kiali provides a summary page of the Service Mesh namespaces and the status of their Applications, Workloads and Services.
The graph provides a powerful way to visualize the topology of your service mesh. It shows you which services communicate with each other and the traffic rates and latencies between them, which helps you visually identify problem areas and quickly pinpoint issues. Kiali provides graphs that show a high-level view of service interactions, a low level view of workloads, or a logical view of applications.
The graph also shows which services are configured with virtual services and circuit breakers. It identifies security issues by identifying traffic not configured as expected. You can observe the traffic flow between components by watching the animation or viewing the metrics.
You can configure the graph to show the namespaces and data that are important to you, and display it in the way that best meets your needs.
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:
Charts showing traffic and response times
Links to fully-detailed pages
Response Code breakdowns.
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.
The workload graph provides the a detailed view of communication between workloads.
The app graph aggregates the workloads with the same app labeling, which provides a more logical view.
The versioned app graph aggregates by app, but breaks out the different versions providing traffic breakdowns that are version-specific.
The service graph provides a high-level view, which aggregates all traffic for defined services.
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:
Kiali provides filtered list views of all your service mesh definitions. Each view provides health, details, YAML definitions and links to help you visualize your mesh. There are list and detail views for:
The overview tab provides detail information, sparkline 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:
Are Istio sidecars deployed?
Are proper app and version labels assigned?
Workload detail show you the services for which the workload in handling request the pods backing them.
The Service Overview shows the user 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.
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.
Kiali is more than observability, it also helps you to configure, update and validate your Istio service mesh.
The Istio configuration view provides advanced filtering and navigation for Istio configuration objects such as Virtual Services and Gateways. Kiali provides inline config edition and powerful semantic validation for Istio resources.
Kiali performs a set of validations to the most common Istio Objects such as Destination Rules, Service Entries, and Virtual Services. Those validations are done in addition to the existing ones performed by Istio’s Galley component. Most validations are done inside a single namespace only, any exceptions, such as gateways, are properly documented.
Galley validations are mostly syntactic validations based on the object syntax analysis of Istio objects while Kiali validations are mostly semantic validations between different Istio objects. Kiali validations are based on the runtime status of your service mesh, Galley validations are static ones and doesn’t take into account what is configured in the mesh.
Check the complete list of validations for further information.
Kiali provides different actions to create, update and delete Istio configuration driven by wizards. These are located in the Actions menu on the Service Details page.
These actions are enabled by default.
Kiali can also be installed in view only mode to restrict any write operation on Istio configuration.
Check Kiali Operator CR to get more details about how to configure this option.
With this wizard, you can select the percentage of traffic that is routed to a specific workload.
Kiali creates a pair of Istio resources, VirtualService and DestinationRule, with a single routing rule using the selected weights for the destination workloads.
The Matching Routing Wizard allows to create multiple routing rules.
Every rule is composed by a Matching and a Routes section.
The Matching section can add multiple filters using HEADERS, URI, SCHEME, METHOD or AUTHORITY Http parameters.
The Matching section can be empty, on this case, any http request received is matched against this rule.
The Routes section can select one or multiple Workloads.
Istio applies routing rules in order, meaning that first rule that matches an HTTP request, it is responsible to perform the routing. The Matching Routing Wizard allows to change order of rules.
In the same way as the previous wizard, Kiali creates a pair of Istio resources mapping the routing rules defined into the generated VirtualService.
This wizard helps user to partially or totally stop traffic for a service. You can define which workloads receive traffic.
When traffic is suspended for all workloads, Istio returns an error code to any service request.
When there is traffic for some workload, the wizard maps a weighted rule; when there is not traffic, an abort rule is coded in the pair of Istio resources VirtualService and DestinationRule generated.
All previous wizards have an Advanced Options section where the user can define specific configuration for TLS, LoadBalancing, Security and Gateways.
The following article Kiali: Observability in Action for Istio Service Mesh describes more examples of how to use the Kiali Wizards to configure Istio configuration.
Istio Wizards provide a way to apply a Service Mesh pattern and let Kiali to generate the Istio Configuration. Kiali also offers actions to create Istio Config for Gateways and Security scenarios.
These actions are located under the Istio Config page.
Kiali allows creation of AuthorizationPolicy, PeerAuthentication and RequestAuthentication Istio resources from the Create New Istio Config forms:
Kiali uses Istio Wizards to generate Istio Traffic config for a specific Service, but Kiali also allows creation of Gateway and Sidecar Istio resources for more generic scenarios:
Kiali gives support to better understand how mTLS is used in Istio meshes. Find those helpers in the graph, the masthead menu, the overview page and specific validations.
At the right side of the Masthead, Kiali shows a lock when the mesh has strictly enabled
mTLS for the whole service mesh. It means that all the communications in the mesh uses
Kiali shows a hollow lock when either the mesh is configured in
PERMISSIVE mode or there is a misconfiguration in the mesh-wide
The overview page shows all the available namespaces with aggregated data. Besides the health and validations, Kiali shows also the
mTLS status at namespace-wide. Similar to the masthead, it shows a lock when strict
mTLS is enabled or a hollow lock when permissive.
mTLS method is used to establish communication between microservices. In the graph, Kiali has the option to show which edges are using
mTLS and with what percentatge during the selected period. When an edge shows a lock icon it means at least one request with mTLS enabled is present. In case there are both mTLS and non-mTLS requests, the side-panel will show the percentage of requests using
In case the mesh-wide
mTLS is enabled, the graph will show broken locks for only those edges containing non-mTLS requests. Edges that use only
mTLS won’t show any lock.
Enable the option in the
Display dropdown, select the
Kiali has different validations to help troubleshoot configurations related to
mTLS such as
Istio provides installation instructions for three different multi-cluster scenarios: replicated control planes, shared control plane with single-network, and shared control plane with multi-network.
Currently, Kiali only works with Istio’s replicated control planes scenario. You will need to install Kiali aside each Istio’s control plane; i.e. you will need one Kiali instance per Istio’s control plane you want to monitor. Install instructions for Kiali are the same as for the single cluster scenario, so following the Getting started guide is enough. Kiali will let you observe the mesh portion that is managed by the adjacent control plane.
The shared control plane scenarios are currently not supported by Kiali.