Kiali is composed of two components: a back-end application running in the container application platform, and a user-facing front-end application. Moreover, Kiali depends on external services and components provided by the container application platform and Istio.
The following diagram illustrates the components involved in Kiali and its interactions:
This is the component that communicates with Istio parts, retrieves and processes data, and exposes this data to the front-end.
The back-end doesn’t need storage. When running the back-end locally, all configurations are set in files and environment variables (including the user and password used for authentication). When deploying the back-end to a cluster using the docker images, configmaps and secrets are used to set the configurations.
The front-end is a single page web application, built with React and written in Typescript. The code can be found at kiali/kiali-ui GitHub repository.
In a standard deployment, the back-end serves the front-end. Then, the front-end queries the Kiali back-end in order to get data and present it to the user.
Since, currently, there are no options for personalizations, it’s mainly stateless. Some data may be persisted - like session credentials -, but this data is stored in the browser and won’t be available in other browsers nor other devices.
Istio is a Kiali requirement. It’s the component that provides and controls the service mesh. Although Kiali and Istio can be installed separately, Kiali depends on Istio and won’t work if it’s not present.
Kiali needs to retrieve Istio data and configurations, which are exposed through Prometheus and the cluster API. This is the reason the diagram shows a dashed line: to denote indirect dependency.
Prometheus is an Istio dependency. When Istio telemetry is enabled, metrics data is stored in Prometheus. Kiali uses the data stored in Prometheus to figure out the mesh topology, show metrics, calculate health, show possible problems, etc.
Kiali communicates directly with Prometheus and assumes the data schema used by Istio Telemetery. It’s a hard dependency for Kiali, and most of it’s features will not work without it.
Currently, Kiali relies on Istio’s default metrics set. Make sure that these default metrics are always in place. Custom metrics are not supported by Kiali. Should you need custom metrics or a variant of the default ones, create new Istio metrics using custom names.
Kiali uses the API of the container application platform (cluster API) in order to fetch and resolve service mesh configurations.
Container application platforms where Kiali is known to work are OKD and Kubernetes. Kiali shoud also work on the derivatives of these platforms. If you want to learn the cluster API, check the OKD REST API reference and the Kubernetes API reference.
Kiali queries the cluster API to retrieve, for example, definitions for: namespaces, services, deployments, pods, and other entities. Kiali also makes queries to resolve relationships between the different cluster entities.
The cluster API is also queried to retrieve Istio configurations like: virtual services, destination rules, route rules, gateways, quotas, etc.
Grafana is optional. When available, the metrics pages of Kiali will show a link to direct the user to the same metric in Grafana. If you need this feature, make sure Kiali is properly configured for Grafana integration.
Kiali has basic metric capabilities. It can show the default Istio metrics for workloads, apps and services. It allows to apply some groupings to the provided metrics and fetch metrics for different time ranges. However, Kiali doesn’t allow to customize the views nor customize the Prometheus queries. If you need these capabilities, you’ll want to install Grafana. Follow the Istio documentation to install Grafana if you need it.