Features

Overview

Kiali helps you define, validate, and observe your Istio service mesh. Kiali provides answers to the questions: What are the microservices in my service mesh, and how are they connected?

Kiali works with Istio in OpenShift or Kubernetes. It visualizes the service mesh topology and provides visibility into features like request routing, circuit breakers, request rates, latency and more. Kial offers insights about the mesh components at different levels, from abstract Applications to Services and Workloads.

     Kiali also includes Jaeger Tracing to provide distributed tracing out of the box.

Observability Features

Observability is being able to see your service mesh in operation. It combines topology, telemetry, traces, logs, events and definitions. It help you ensure your mesh is healthy or to quickly identify problem areas. It helps correlate different information sources into a holistic view of the system.

Graph

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. It lets you visually identify problem areas ane quickly pinpoint issues. Kiali provides four different graph types giving you a high-level view of service interactions, a low level view of pods, or a logical view of applications.

The graph also lets you see which services are configured with such things as virtual services and circuit breakers. It also identifies security issues by identifying traffic not configured as expected. And 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 is important to you, and display it in the way that best meets your needs.


Graph: Health

Colors in the graph represent the health of your service mesh. A nodes colored as red or orange may 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, services, workloads, apps, etc.

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.


Graph: Drill-Down

Sometimes you want to want to focus on just one component, whether it be a service, a workload, or an application. Kiali offers detail graphs for any component you choose

Double click on a graph node and Kiali will drill in and give you 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.


Graph: Side-Panel

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

  • Charts showing traffic and response times

  • Health details

  • Links to fully-detailed pages

  • Response Code breakdowns.

Or, click on the graph background and the side panel provides an overall summary for the entire graph.


Graph: Traffic Animation

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.


Graph: Graph Types

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/pods.

  • The app graph aggregates the workloads with the same app labeling, providing 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, aggregating all traffic for defined services.


Detail Views

Kiali provides filtered list views of all your service mesh definitions. Each view provides health, details, yamls and links to help you visualize your mesh. There are list and detail views for:

  • Services

  • Applications

  • Workloads

  • Istio Configurations (Virtual Services, Gateways, etc)


Detail: Metrics

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

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

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


Detail: Services

The service detail view 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 delete for authorized users. It provides wizards to assist in common configurations and performs additional validation on VirtualServices to detect misconfigured routes.


Detail: Workloads

Kiali performs several validations on workload configuration:

  • Are Istio sidecars deployed?

  • Are proper app and version labels assigned?

Workload detail provides a view of the services for which the workload is handling requests, and the pods backing the workload.

Workload detail also allows access to the pod logs, and provides detailed traffic breakdown.


Detail: Runtimes Monitoring/Dashboards

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, it’s a perfect fit for keeping under source control like GIT, track changes, share, etc.

Check out the documentation page to learn more about it.


Distributed Tracing

Clicking on the Distributed Tracing menu item will open a new tab with the Jaeger UI for tracing services.


Configuration and Validation Features

Kiali is more than observability, it also helps you to configure, update and validate your Istio service mesh.

Istio Configuration

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.


Validations Performed

This section lists all the validations that Kiali performs on all Istio configurations. Most of these validations are done in addition to/on top of the existing ones performed by Istio’s Galley component (except those marked as deprecated). Most validations are done inside a single namespace only, any exceptions (such as gateways) are marked below.

Table 1. List of destination rule validations
Validation message Severity Description Source Example

More than one Destination Rule for the same host subset combination

warning

Warning shown when two Destination Rules point to the same host and share one or more subsets. If non-local mTLS is enabled this check is ignored.

source code

001.yaml

This host has no matching workloads

error

When one destination rule has a host that doesn’t exist. This checks against any workload, service names as well as service entries

source code

002.yaml

This subset’s labels are not found in any matching host

error

There isn’t any workload for this host matching its labels with the ones from that subset

source code

003.yaml

MeshPolicy enabling mTLS is missing

error

When there is a DestinationRule enabling mTLS mesh-wide, but there isn’t any MeshPolicy enabling mTLS

source code

004.yaml

Table 2. List of virtual service validations
Validation message Severity Description Source Example

VirtualService is pointing to a non-existent gateway

error

When the virtual service has a specified a gateway that doesn’t exist

source code

101.yaml

DestinationWeight on route doesn’t have a valid service (host not found)

error

When a destination weight has a host that doesn’t exist. This checks against service names as well as service entries

source code

102.yaml

VirtualService doesn’t define any route protocol

error

When a Virtual Service doesn’t define any tcp, http or tls routes

source code

103.yaml

More than one Virtual Service for same host

warning

When two virtual services point to the same host. This includes hosts with wildcards also.

source code

104.yaml

Subset not found

warning

When there is no subset defined in any destination rule

source code

105.yaml

Destination field is mandatory

error

When a Destination field within a DestinationWeight is empty

source code

106.yaml

(Deprecated) Weight must be a number

error

When a destination weight is not a number

source code

107.yaml

(Deprecated) Weight should be between 0 and 100

error

When a destination weight is > 100 or < 0

source code

108.yaml

(Deprecated) Weight sum should be 100

error

When the sum of all the weights for a protocol doesn’t sum up to 100

source code

109.yaml

(Deprecated) All routes should have weight

warning

When weight sum is different from 100 and one or more destination weights have no weight, but the rest have.

source code

110.yaml

Table 3. List of Gateway validations
Validation message Severity Description Source Example

More than one Gateway for the same host port combination

warning

When two or more gateways (from same or different namespace) point to the same host-port combination

source code

201.yaml

Table 4. List of MeshPolicy validations
Validation message Severity Description Source Example

Mesh-wide Destination Rule enabling mTLS is missing

error

When there is a MeshPolicy enabling mTLS, but there isn’t any mesh-wide Destination Rule enabling mTLS

source code

401.yaml

Istio Wizards

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.

Weighted Routing Wizard

This wizard allows to select the percentage of traffic that will be routed to a specific Workload.

Kiali will create a pair of Istio resources (VirtualService and DestinationRule) with a single routing rule using the selected weights for the destination workloads.

Matching Routing Wizard

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 that the previous Wizard, Kiali will create a pair of Istio resources mapping the routing rules defined into the generated VirtualService.

Suspend Traffic Wizard

This wizard helps user to stop partially or totally traffic for a service. It allows to define which workloads will receive traffic.

When traffic is suspended for all workloads, Istio will return an error code to any Service request.

When there is traffic for some workload, the wizard will map a weighted rule; when there is not traffic, an abort rule will be coded in the pair of Istio resources VirtualService and DestinationRule generated.

Advanced Options

All previous wizards have an "advanced options" section where user can define specific configuration for TLS and LoadBalancing.

When mTLS is enabled by default in the global cluster or namespace this option is already preselected.

More Wizard examples

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.