Kiali

KIALI-SECURITY-003 - Installation into ad-hoc namespaces

Tue, 11 May 2021 11:00:00 -0600

Description

Disclosure date: May 11, 2021
Affected Releases: prior to 1.33.0
Impact Score: 6.6 - AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:L

A vulnerability was found in the Kiali Operator allowing installation of a specified image into any namespace.

Kiali users are exposed to this vulnerability if all the following conditions are met:

Kiali operator is used for installation.
Kiali CR was edited to install an image into an unapproved namespace.

This vulnerability is filed as CVE-2021-3495

Mitigation

If you can update:

KIALI-SECURITY-002 - Authentication bypass when using the OpenID login strategy

Thu, 04 Mar 2021 11:00:00 -0600

Description

Disclosure date: March 5, 2021
Affected Releases: 1.26.0, 1.26.1, 1.26.2, 1.27.0, 1.28.0, 1.28.1, 1.29.0, 1.29.1, 1.30.0
Impact Score: 7.0 - AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N/E:F/RL:X/RC:C

A vulnerability was found in Kiali allowing an attacker to bypass the authentication mechanism. The vulnerability lets an attacker build forged credentials and use them to gain unauthorized access to Kiali.

Kiali users are exposed to this vulnerability if all the following conditions are met:

Kiali is setup with the openid authentication strategy.
As a result of configurations in both Kiali and your OpenID server, Kiali uses the implicit flow of the OpenID specification to negotiate authentication.
Kiali is setup with RBAC turned off.

This vulnerability is filed as CVE-2021-20278

KIALI-SECURITY-001 - Authentication bypass using forged credentials

Tue, 24 Mar 2020 11:00:00 -0600

Description

Disclosure date: March 25, 2020
Affected Releases: 0.4.0 to 1.15.0
Impact Score: 9.4 - AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H

A vulnerability was found in Kiali allowing an attacker to bypass the authentication mechanism. Currently, Kiali has four authentication mechanisms: login, token, openshift and ldap. All are vulnerable.

The vulnerability lets an attacker build forged credentials and use them to gain unauthorized access to Kiali.

Additionally, it was found that Kiali credentials were not being validated properly. Depending on the authentication mechanism configured in Kiali, this could facilitate unauthorized access into Kiali with forged and/or invalid credentials.

Introduction

Mon, 01 Jan 0001 00:00:00 +0000

So far, we know how good Kiali can be to understand applications, their relationships with each other and with external applications.

In the previous tutorial, Kiali was setup to observe just a single cluster. Now, we will expand its capabilities to observe more than one cluster. The extra clusters are remotes, meaning that there is not a control plane on them, they only have user applications.

This topology is called primary-remote and it is very useful to spread applications into different clusters having just one primary cluster, which is where Istio and Kiali are installed.

Introduction

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

Kiali uses Jaeger as a default distributed tracing backend. In this tutorial, we will replace it for Grafana Tempo.

We will setup a local environment in minikube, and install Kiali with Tempo as a distributed backend. This is a simplified architecture diagram:

We will install Tempo with the Tempo Operator and enable Jaeger query frontend to be compatible with Kiali in order to query traces.
We will setup Istio to send traces to the Tempo collector using the zipkin protocol. It is enabled by default from version 3.0 or higher of the Tempo Operator.
We will install MinIO and setup it up as object store, S3 compatible.

Environment

We use the following environment:

Prerequisites

Mon, 01 Jan 0001 00:00:00 +0000

Platform Setup

This tutorial assumes you have access to a Kubernetes cluster with Istio installed.

This tutorial is being updated and qualified using:

a Kind (Kubernetes in Docker) cluster with Helm-based Kiali install.
an OpenShift cluster with Kiali Operator install (qualification pending).

Tip

Platform-dependent tasks will be indicated with a special note like this.

Version pins will be recorded here as the tutorial is re-qualified. Use current stable releases of Kind, Istio, and Kiali unless noted otherwise.

Quick Start

Mon, 01 Jan 0001 00:00:00 +0000

Run Kiali locally

Kiali can be run directly on your machine without being installed into a Kubernetes cluster. It uses your kubeconfig to connect to your cluster(s). If needed, it can port-forward into the cluster to connect to your external services (prometheus, tracing, istio, grafana).

Running Kiali locally is currently experimental. Functionality may change between releases.

Download the Kiali binary from the Kiali GitHub releases page for your OS and Arch.

Release Notes

Mon, 01 Jan 0001 00:00:00 +0000

For additional information check our sprint demo videos and blogs.

2.34.0

Release: October 26, 2026

Features:

Fixes:

Install Travel Demo

Mon, 01 Jan 0001 00:00:00 +0000

Deploy the Travel Demo

This demo application deploys several services grouped into three namespaces:

travel-control — business dashboard to configure traffic and view statistics
travel-portal — shop simulators that generate traffic
travel-agency — quote and pricing services

At this step, deploy the application without joining it to the service mesh. Sidecar injection is added in Join the Mesh.

Do not label the namespaces with istio-injection=enabled yet.

Kind

From the Kiali source repository, the Travel Demo install script creates the namespaces and deploys the manifests without enabling auto-injection:

Kiali and Tempo setup

Mon, 01 Jan 0001 00:00:00 +0000

Steps to install Kiali and Grafana Tempo

We will start minikube:

minikube start

It is a requirement to have cert-manager installed:

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.12.0/cert-manager.yaml

Install the operator. It is important to download a version 3.0 or higher. In previous versions, the zipkin collector was not exposed, there was no way to change it as it was not defined in the CRD.

kubectl apply -f https://github.com/grafana/tempo-operator/releases/download/v0.3.0/tempo-operator.yaml

We will create the tempo namespace:

kubectl create namespace tempo

We will deploy minio, this is a sample minio.yaml:

Prerequisites

Mon, 01 Jan 0001 00:00:00 +0000

This tutorial is a walkthrough guide to install everything. For this reason, we will need:

minikube
istioctl
helm

This tutorial was tested on:

Minikube v1.30.1
Istio v1.18.1
Kiali v1.70

Clusters are provided by minikube instances, but this tutorial should work on on any Kubernetes environment.

We will set up some environment variables for the following commands:

CLUSTER_EAST="east"
CLUSTER_WEST="west"
ISTIO_DIR="absolute-path-to-istio-folder"

As Istio will be installed on more than one cluster and needs to communicate between clusters, we need to create certificates for the Istio installation. We will follow the Istio documentation related to certificates to achieve this:

Deploy East cluster

Mon, 01 Jan 0001 00:00:00 +0000

Run the following commands to deploy the first cluster:

minikube start -p $CLUSTER_EAST --network istio --memory 8g --cpus 4

For both clusters, we need to configure MetalLB, which is a load balancer. This is because we need to assign an external IP to the required ingress gateways to enable cross cluster communication between Istio and the applications installed.

minikube addons enable metallb -p $CLUSTER_EAST

We set up some environment variables with IP ranges that MetalLB will then assign to the services:

Join the Mesh

Mon, 01 Jan 0001 00:00:00 +0000

Sidecar Proxies

The Travel Demo was deployed in the previous chapter without Istio sidecar proxies. These are Envoy proxies that can be injected into the application pods.

Without a sidecar, workloads do not connect to the Istio control plane and do not report mesh telemetry (metrics, access logs, or distributed traces).

Confirm in Kiali

As shown in Install Travel Demo, the demo namespaces appear on the Namespaces page with type - (Not part of the mesh):

Install Istio on East cluster

Mon, 01 Jan 0001 00:00:00 +0000

The east cluster is the primary one, consequently is where the istiod process will be installed alongside other applications like Kiali.

Run the following commands to install Istio:

kubectl create namespace istio-system --context $CLUSTER_EAST

kubectl create secret generic cacerts -n istio-system --context $CLUSTER_EAST \
 --from-file=certs/$CLUSTER_EAST/ca-cert.pem \
 --from-file=certs/$CLUSTER_EAST/ca-key.pem \
 --from-file=certs/$CLUSTER_EAST/root-cert.pem \
 --from-file=certs/$CLUSTER_EAST/cert-chain.pem

kubectl --context=$CLUSTER_EAST label namespace istio-system topology.istio.io/network=network1

cat <<EOF > $CLUSTER_EAST.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
 values:
 global:
 meshID: mesh1
 multiCluster:
 clusterName: $CLUSTER_EAST
 network: network1
EOF

istioctl install -y --set values.pilot.env.EXTERNAL_ISTIOD=true --context=$CLUSTER_EAST -f $CLUSTER_EAST.yaml

After the installation, we need to create what we called an “east-west” gateway. It’s an ingress gateway just for the cross cluster configuration as we are opting to use the installation for different networks (this will be the case in the majority of the production scenarios).

Observe the Mesh

Mon, 01 Jan 0001 00:00:00 +0000

Enable Sidecars in All Workloads

An Istio sidecar proxy connects a workload to the control plane and enables service mesh functionality.

Sidecars automatically collect metrics, access logs, and distributed traces — a major observability benefit of the mesh.

In Join the Mesh we injected a sidecar only into the control workload. The rest of the Travel Demo still lacks full mesh visibility.

Step 1

Use the Traffic Graph to identify missing sidecars in the Travel Demo

Control the Mesh

Mon, 01 Jan 0001 00:00:00 +0000

This chapter uses Kiali wizards to configure Istio traffic management on the Travel Demo. Each section introduces a scenario, walks through the wizard, verifies the result in Kiali, and ends with guidance to update or delete the generated configuration.

In Observe the Mesh you explored telemetry and tracing. Here you change how traffic flows through the mesh.

Request Routing

The Travel Demo application has several portals deployed on the travel-portal namespace consuming the travels service deployed on the travel-agency namespace.

Install Kiali

Mon, 01 Jan 0001 00:00:00 +0000

Run the following command to install Kiali using the Kiali operator:

kubectl config use-context $CLUSTER_EAST

helm upgrade --install --namespace istio-system --set auth.strategy=anonymous --set deployment.logger.log_level=debug --set deployment.ingress.enabled=true --repo https://kiali.org/helm-charts kiali-server kiali-server

Verify that Kiali is running with the following command:

istioctl dashboard kiali

There are other alternatives to expose Kiali or other Addons in Istio. Check Remotely Accessing Telemetry Addons for more information.

Navigating Multiple Meshes with OSSMC

Mon, 01 Jan 0001 00:00:00 +0000

OpenShift Service Mesh Console (OSSMC) includes Istios and Kialis pages in the OpenShift Console Service Mesh menu. These pages let you browse and inspect every Istio and Kiali CR on the cluster directly from the console — without requiring a Kiali server to be connected to the plugin.

This is especially useful when a cluster hosts many mesh instances. Platform teams that operate dozens or hundreds of Istio control planes (and the Kiali instances that observe them) on a cluster can navigate that inventory in one place instead of jumping between CLI commands, individual operator UIs, or separate Kiali routes.

Install Travels on East cluster

Mon, 01 Jan 0001 00:00:00 +0000

Run the following commands to install Travels application on east cluster:

kubectl create namespace travel-agency --context $CLUSTER_EAST
kubectl create namespace travel-portal --context $CLUSTER_EAST
kubectl create namespace travel-control --context $CLUSTER_EAST

kubectl label namespace travel-agency istio-injection=enabled --context $CLUSTER_EAST
kubectl label namespace travel-portal istio-injection=enabled --context $CLUSTER_EAST
kubectl label namespace travel-control istio-injection=enabled --context $CLUSTER_EAST

kubectl apply -f <(curl -L https://raw.githubusercontent.com/kiali/demos/master/travels/travel_agency.yaml) -n travel-agency --context $CLUSTER_EAST
kubectl apply -f <(curl -L https://raw.githubusercontent.com/kiali/demos/master/travels/travel_portal.yaml) -n travel-portal --context $CLUSTER_EAST
kubectl apply -f <(curl -L https://raw.githubusercontent.com/kiali/demos/master/travels/travel_control.yaml) -n travel-control --context $CLUSTER_EAST

After the installation, we can see that the Travels application is running on the east cluster:

Secure the Mesh

Mon, 01 Jan 0001 00:00:00 +0000

Authorization Policies and Sidecars

Security is one of Istio’s main pillars.

The Istio Security High Level Architecture provides a comprehensive solution to design and implement multiple security scenarios.

In this tutorial we will show how Kiali can use telemetry information to create security policies for the workloads deployed in a given namespace.

Istio telemetry aggregates the ServiceAccount information used in workload communication. This information can be used to define authorization policies that deny and allow actions based on observed live traffic.

Deploy West cluster

Mon, 01 Jan 0001 00:00:00 +0000

Run the following commands to deploy the second cluster:

minikube start -p $CLUSTER_WEST --network istio --memory 8g --cpus 4

Similar to the east cluster, we configure MetalLB:

minikube addons enable metallb -p $CLUSTER_WEST

MINIKUBE_IP=$(minikube ip -p $CLUSTER_WEST)
MINIKUBE_IP_NETWORK=$(echo $MINIKUBE_IP | sed -E 's/([0-9]+\.[0-9]+\.[0-9]+)\.[0-9]+/\1/')
MINIKUBE_LB_RANGE="${MINIKUBE_IP_NETWORK}.30-${MINIKUBE_IP_NETWORK}.39"

cat <<EOF | kubectl --context $CLUSTER_WEST apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
 namespace: metallb-system
 name: config
data:
 config: |
 address-pools:
 - name: default
 protocol: layer2
 addresses: [${MINIKUBE_LB_RANGE}]
EOF

Install Istio on West cluster

Mon, 01 Jan 0001 00:00:00 +0000

This installation will be different as this cluster will be a remote. In a remote cluster, it won’t be an Istio control plane. Istio will install some resources that allows the primary control plane to configure the workloads in the remote cluster like injecting the sidecars and configuring the low level routing.

kubectl create namespace istio-system --context $CLUSTER_WEST

kubectl create secret generic cacerts -n istio-system --context $CLUSTER_WEST \
 --from-file=certs/$CLUSTER_WEST/ca-cert.pem \
 --from-file=certs/$CLUSTER_WEST/ca-key.pem \
 --from-file=certs/$CLUSTER_WEST/root-cert.pem \
 --from-file=certs/$CLUSTER_WEST/cert-chain.pem

kubectl --context=$CLUSTER_WEST annotate namespace istio-system topology.istio.io/controlPlaneClusters=$CLUSTER_EAST
kubectl --context=$CLUSTER_WEST label namespace istio-system topology.istio.io/network=network2

cat <<EOF > $CLUSTER_WEST.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
 profile: remote
 values:
 istiodRemote:
 injectionPath: /inject/cluster/$CLUSTER_WEST/net/network2
 global:
 remotePilotAddress: ${DISCOVERY_ADDRESS}
EOF

istioctl install -y --context=$CLUSTER_WEST -f $CLUSTER_WEST.yaml

We will also install a Prometheus instance on the remote. We will federate both Prometheus, with the east’s one being the place where all metrics will be gathered together:

Configure Kiali for multicluster

Mon, 01 Jan 0001 00:00:00 +0000

We will configure Kiali to access the remote cluster. This will require a secret (similar to the Istio secret) containing the credentials for Kiali to fetch information from the remote cluster:

curl -L -o kiali-prepare-remote-cluster.sh https://raw.githubusercontent.com/kiali/kiali/master/hack/istio/multicluster/kiali-prepare-remote-cluster.sh

chmod +x kiali-prepare-remote-cluster.sh

./kiali-prepare-remote-cluster.sh --kiali-cluster-context $CLUSTER_EAST --remote-cluster-context $CLUSTER_WEST

Finally, upgrade the installation for Kiali to pick up the secret:

kubectl config use-context $CLUSTER_EAST

helm upgrade --install --namespace istio-system --set auth.strategy=anonymous --set deployment.logger.log_level=debug --set deployment.ingress.enabled=true --repo https://kiali.org/helm-charts kiali-server kiali-server

As result, we can quickly see that a new namespace appear in the Overview, the istio-system namespace from west cluster:

Anonymous strategy

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

The anonymous strategy removes any authentication requirement. Users will have access to Kiali without providing any credentials.

Although the anonymous strategy doesn’t provide any access protection, it’s valid for some use-cases. Some examples known from the community:

Exposing Kiali through a reverse proxy, where the reverse proxy is providing a custom authentication mechanism.
Exposing Kiali on an already limited network of trusted users.
When Kiali is accessed through kubectl port-forward or alike commands that allow usage of the cluster’s RBAC capabilities to limit access.
When developing Kiali, where a developer has a private instance on his own machine.

It’s worth to emphasize that the anonymous strategy will leave Kiali unsecured. If you are using this option, make sure that Kiali is available only to trusted users, or access is protected by other means.

Chatbot

Mon, 01 Jan 0001 00:00:00 +0000

Kiali Chatbot is Kiali’s built-in AI assistant in the Kiali UI. It lets you ask questions about your service mesh and get answers backed by live data from Kiali and its configured backends (Prometheus, tracing, Kubernetes, etc.).

It does not require an external MCP server. Kiali includes its own set of MCP-style tools internally, so the AI can call them without depending on a separate MCP deployment.

Status

The Kiali chatbot was first released in Kiali version 2.22 and it is in Dev preview.

Grafana

Mon, 01 Jan 0001 00:00:00 +0000

Grafana configuration

Istio provides preconfigured Grafana dashboards for the most relevant metrics of the mesh. Although Kiali offers similar views in its metrics dashboards, it is not in Kiali’s goals to provide the advanced querying options, nor the highly customizable settings, that are available in Grafana. Thus, it is recommended that you use Grafana if you need those advanced options.

Kiali can provide a direct link from its metric dashboards to the equivalent or most similar Grafana dashboard, which is convenient if you need the powerful Grafana options.

How to Contribute

Mon, 01 Jan 0001 00:00:00 +0000

Contributing to the Docs

To contribute to the kiali.io docs see kiali.io on github.

In short you will:

Fork the kiali.io repo on GitHub.
Make your changes and send a pull request (PR).
If you’re not yet ready for a review, add “WIP” to the PR name to indicate it’s a work in progress.
1. Don’t add the Hugo property “draft = true” to the page front matter, it prevents auto-deployment of the content preview.
Wait for the automated PR workflow to do some checks. When it’s ready, you should see a comment like this: deploy/netlify — Deploy preview ready!
Click Details to the right of “Deploy preview ready” to see a preview of your updates.
Continue updating your doc and pushing your changes until you’re happy with the content.

Updating a single page

If you’ve just spotted something you’d like to change while using the docs, there is a shortcut for you:

Install Travels on West cluster

Mon, 01 Jan 0001 00:00:00 +0000

We are going to deploy two new services just to distribute traffic on the new cluster. These services are travels v2 and v3:

kubectl create ns travel-agency --context $CLUSTER_WEST

kubectl label namespace travel-agency istio-injection=enabled --context $CLUSTER_WEST

kubectl apply -f <(curl -L https://raw.githubusercontent.com/kiali/demos/master/travels/travels-v2.yaml) -n travel-agency --context $CLUSTER_WEST
kubectl apply -f <(curl -L https://raw.githubusercontent.com/kiali/demos/master/travels/travels-v3.yaml) -n travel-agency --context $CLUSTER_WEST

cat <<EOF | kubectl -n travel-agency --context $CLUSTER_WEST apply -f -
apiVersion: v1
kind: Service
metadata:
 name: travels
 labels:
 app: travels
spec:
 ports:
 - name: http
 port: 8000
 selector:
 app: travels
---
apiVersion: v1
kind: Service
metadata:
 name: insurances
 labels:
 app: insurances
spec:
 ports:
 - name: http
 port: 8000
 selector:
 app: insurances
---
apiVersion: v1
kind: Service
metadata:
 name: hotels
 labels:
 app: hotels
spec:
 ports:
 - name: http
 port: 8000
 selector:
 app: hotels
---
apiVersion: v1
kind: Service
metadata:
 name: flights
 labels:
 app: flights
spec:
 ports:
 - name: http
 port: 8000
 selector:
 app: flights
---
apiVersion: v1
kind: Service
metadata:
 name: discounts
 labels:
 app: discounts
spec:
 ports:
 - name: http
 port: 8000
 selector:
 app: discounts
---
apiVersion: v1
kind: Service
metadata:
 name: cars
 labels:
 app: cars
spec:
 ports:
 - name: http
 port: 8000
 selector:
 app: cars
EOF

After the installation, we can see that traffic is flowing to the remote cluster too:

Jaeger

Mon, 01 Jan 0001 00:00:00 +0000

Jaeger configuration

Jaeger is a highly recommended service because Kiali uses distributed tracing data for several features, providing an enhanced experience.

By default, Kiali will try to reach Jaeger at the GRPC-enabled URL of the form http://tracing.<istio_namespace_name>:16685/jaeger, which is the usual case if you are using the Jaeger Istio add-on. If this endpoint is unreachable, Kiali will disable features that use distributed tracing data.

If your Jaeger instance has a different service name or is installed to a different namespace, you must manually provide the endpoint where it is available, like in the following example:

Kiali Backstage Plugin

Mon, 01 Jan 0001 00:00:00 +0000

The Kiali Backstage Plugin provides information about each Service Mesh object related with an entity in Backstage, a framework for building developer portals.

The plugin has different views to be included in Backstage:

Added as cards to see resource lists
Added as a tab which includes all the predefined Kiali cards
Added as a page, which views are not going to be filtered by entities and offer a full Kiali view

OpenShift

Mon, 01 Jan 0001 00:00:00 +0000

These are specific notes for the External Kiali deployment model on OpenShift.

Installation

It is highly recommended that the Kiali Operator be deployed on all clusters, even if the Kiali Server itself is not deployed on some clusters. This will ensure that the proper namespace and remote cluster resources can be created. Clusters without a Kiali Server will require only the remote cluster resources necessary for remote Kiali Server authentication. To install these resources, configure the Kiali CR with:

OSSM Console

Mon, 01 Jan 0001 00:00:00 +0000

OpenShift Service Mesh Console (OSSMC) is a dynamic plugin for OpenShift Console based on OpenShift dynamic plugins technology.

OSSMC lets you navigate multiple meshes from the OpenShift Console through Istios and Kialis pages — browse every Istio and Kiali instance on the cluster without requiring a Kiali server connected to the plugin. When a Kiali instance is connected and reachable, OSSMC also provides Kiali-powered observability — a dedicated Service Mesh navigation category with pages for overview, traffic graph, mesh infrastructure, namespaces, applications, services, workloads, and Istio configuration, plus Service Mesh tabs on OpenShift resource detail pages.

OSSMC User Guide

Mon, 01 Jan 0001 00:00:00 +0000

The OpenShift Service Mesh Console (OSSMC) is an extension to the OpenShift Console which provides visibility into your Service Mesh. With the OSSMC plugin installed, a new Service Mesh menu category is available in the navigation menu on the left side of the web console.

Which pages appear depends on whether a Kiali server is connected to the plugin:

With a connected Kiali server — When a Kiali instance is connected and reachable, OSSMC provides the full Kiali-powered experience: dedicated list and detail pages for mesh components, plus Service Mesh tabs on OpenShift Workloads, Services, Projects, and Istio configuration detail pages. The features match those of the standalone Kiali Console, organized to integrate with the OpenShift Console.
Without a connected Kiali server — When no Kiali instance is connected (or Kiali is not reachable), OSSMC still provides Istios and Kialis pages that list every Istio and Kiali CR on the cluster. These pages do not require a Kiali server and are especially useful for navigating many mesh instances from one console. See Navigating Multiple Meshes.

The OSSMC plugin does not replace the standalone Kiali Console. After installing OSSMC, you can still access Kiali through its own route when a Kiali server is deployed. This User Guide discusses the extensions you see from within the OpenShift Console itself — primarily the Kiali-powered pages. For Istios and Kialis, see Navigating Multiple Meshes.

Prometheus

Mon, 01 Jan 0001 00:00:00 +0000

Prometheus configuration

Kiali uses Prometheus to generate the topology graph, show metrics, calculate health and for several other features. Prometheus is enabled by default and is required for full Kiali functionality.

Disabling Prometheus

If you want to run Kiali without a Prometheus instance, you can disable it:

spec:
 external_services:
 prometheus:
 enabled: false

When Prometheus is disabled, Kiali will still start and serve non-metrics features such as workload/service/app listing, Istio configuration, and mesh topology. However, the graph, metrics tabs, traffic tabs, and request-rate health will be unavailable. Health badges for workloads and apps will degrade to show only Kubernetes-level status (replica counts).

Token prices

Mon, 01 Jan 0001 00:00:00 +0000

Kiali can estimate the monetary cost of ChatAI usage from a per-model token price catalog. Those estimates appear on the AI consumption dashboard and can be used with optional per-user budgets.

To use consumption tracking, token prices, and the AI consumption dashboard, ai.metrics must be enabled (ai.metrics: true). If metrics are disabled, Kiali does not record token usage, does not estimate cost, and does not show consumption data.

Cost estimates, dashboard access, and the price catalog are configured under ai.consumption. For the configuration keys, see ai.metrics and ai.consumption in the Kiali CR spec.

Budgets

Mon, 01 Jan 0001 00:00:00 +0000

You can cap ChatAI usage per user with ai.consumption.budgets. Each budget sets a reset interval, optional cost and token limits, and optional provider/model allowlists. Cost limits use the same catalog described in Token prices.

To use consumption tracking, token prices, and budgets, ai.metrics must be enabled (ai.metrics: true). If metrics are disabled, budgets are not enforced and remaining-budget data is not shown.

If budgets is empty (the default), there are no budget restrictions.

Prerequisites

Mon, 01 Jan 0001 00:00:00 +0000

Istio

Before you install Kiali you must have already installed Istio. For full functionality, you should also install a telemetry storage addon (e.g. Prometheus), though Kiali can run without it if you disable Prometheus in the configuration. You might also consider installing Istio’s optional tracing addon (e.g. Tempo) and optional Grafana addon but those are not required by Kiali. Refer to the Istio documentation for details.

Optionally Enable the Debug Interface

Like istioctl, Kiali can make use of Istio’s port 8080 “Debug Interface” API. Despite the naming, this is required for accessing the status of the proxies.

Tools (schemas)

Mon, 01 Jan 0001 00:00:00 +0000

Kiali Chatbot uses internal MCP-style tools (implemented inside Kiali) to fetch live data and perform safe actions. These are not external MCP server tools.

Administrators can control which of these tools are exposed to the AI by using ai.chat.tools for global filtering and ai.chat.providers[].tools for provider-specific filtering. Use the exact tool names below in enabled_tools and disabled_tools.

The tool input schemas are defined in Kiali under kiali/ai/mcp/tools/*.yaml. The tool outputs are JSON structures returned by the Kiali backend and consumed by the model and/or UI.

ACM Observability

Mon, 01 Jan 0001 00:00:00 +0000

OpenShift Only: This guide is specifically for Red Hat OpenShift environments using Red Hat Advanced Cluster Management (ACM) for Kubernetes. ACM is an OpenShift-specific product.

Overview

Red Hat Advanced Cluster Management (ACM) provides centralized observability for multi-cluster OpenShift environments through its Observability Service. Metrics from all managed clusters (including the hub cluster itself) are collected and aggregated into a central Thanos-based storage system

This guide uses the multicluster observability add-on (MCOA) to aggregate mesh metrics on managed clusters (introduced in ACM 4.17), federate selected series, and remote-write them to the central Thanos-based storage system.

Header strategy

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

The header strategy assumes a reverse proxy is in front of Kiali, such as OpenUnison or OAuth2 Proxy, injecting the user’s identity into each request to Kiali as an Authorization header. This token can be an OpenID Connect token or any other token the cluster recognizes.

In addition to a user token, the header strategy supports impersonation headers. If the impersonation headers are present in the request, then Kiali will act on behalf of the user specified by the impersonation (assuming the token supplied in the Authorization header is authorized to do so).

Install via Helm

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

Helm is a popular tool that lets you manage Kubernetes applications. Applications are defined in a package named Helm chart, which contains all of the resources needed to run an application.

Kiali has a Helm Charts Repository at https://kiali.org/helm-charts. Two Helm Charts are provided:

The kiali-operator Helm Chart installs the Kiali operator which in turn installs Kiali when you create a Kiali CR.
The kiali-server Helm Chart installs a standalone Kiali without the need of the Operator nor a Kiali CR.

The kiali-server Helm Chart does not provide all the functionality that the Kiali Operator provides. Some features you read about in the documentation may only be available if you install the Kiali Server using the Kiali Operator (see this FAQ for details). Therefore, although the kiali-server Helm Chart is actively maintained, it is not recommended and is only provided for convenience. If using Helm, the recommended method is to install the kiali-operator Helm Chart and then create a Kiali CR to let the Operator deploy Kiali.

Kiali MCP

Mon, 01 Jan 0001 00:00:00 +0000

Kiali MCP lets an MCP-capable assistant query a live service mesh, and optionally change Istio configuration, by calling tools that Kiali already implements. The assistant does not talk to Kiali directly. It talks to an MCP server, and that server calls the Kiali API with the caller’s Kubernetes token.

This is separate from the Kiali Chatbot. The chatbot runs inside the Kiali UI and uses Kiali’s own tools. Kiali MCP is for an assistant outside Kiali, for example an IDE, that should use the same mesh data.

Perses

Mon, 01 Jan 0001 00:00:00 +0000

Perses configuration

The Perses community dashboards provide preconfigured Perses dashboards for the most relevant mesh metrics. Although Kiali offers similar views in its metrics dashboards, it is not in Kiali’s goals to provide the advanced querying options, nor the highly customizable settings, that are available in Perses. They are the same as those provided by Istio’s Grafana add-on. Thus, it is recommended that you use Perses if you need those advanced options.

Tempo

Mon, 01 Jan 0001 00:00:00 +0000

Grafana Tempo Configuration

There are two possibilities to integrate Kiali with Grafana Tempo:

Tuning

Mon, 01 Jan 0001 00:00:00 +0000

Production environments should not be using the Istio Prometheus add-on, or carrying over its configuration settings. That is useful only for small, or demo installations. Instead, Prometheus should have been installed in a production-oriented way, following the Prometheus documentation.

This page is primarily for users where Prometheus is being used specifically for Kiali, and possible optimizations that can be made knowing that Kiali does not utilize all of the default Istio and Envoy telemetry.

MultiCluster on OpenShift

Mon, 01 Jan 0001 00:00:00 +0000

This guide sets up a two-cluster OpenShift environment from scratch where:

The hub cluster runs Red Hat Advanced Cluster Management (ACM) for fleet management and centralized metrics collection (ACM Observability / Thanos)
The spoke cluster is imported into ACM and runs OpenShift Service Mesh 3 (OSSM 3) with Kiali
The spoke mesh has two demo application namespaces: one using Istio ambient mode (via the ZTunnel CR), one using Istio sidecar injection
Kiali queries metrics via the ACM Observatorium API on the hub cluster (mTLS), giving it access to Istio metrics collected and forwarded by ACM from the spoke’s User Workload Monitoring Prometheus

The result is a working Kiali installation that shows traffic graphs, metrics, and mesh topology across both the ambient-mode and sidecar-mode workloads running on the spoke.

Deployment Options

Mon, 01 Jan 0001 00:00:00 +0000

There are other, more complex deployment settings, described in dedicated pages:

All examples on this page are focused on the Kiali CR (when installing via the Kiali operator). Remember that Helm charts mirror all these configurations.

Kiali and Istio installation namespaces

By default, the Kiali operator installs Kiali in the same namespace where the Kiali CR is created. However, it is possible to specify a different namespace for installation:

Install via OperatorHub

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

The OperatorHub is a website that contains a catalog of Kubernetes Operators. Its aim is to be the central location to find Operators.

The OperatorHub relies in the Operator Lifecycle Manager (OLM) to install, manage and update Operators on any Kubernetes cluster.

The Kiali Operator is being published to the OperatorHub. So, you can use the OLM to install and manage the Kiali Operator installation.

Installing the Kiali Operator using the OLM

Go to the Kiali Operator page in the OperatorHub: https://operatorhub.io/operator/kiali.

Multi-Primary Mesh

Mon, 01 Jan 0001 00:00:00 +0000

Multi-Primary Mesh on OpenShift with ACM

This guide extends the result of the MultiCluster on OpenShift guide into a two-primary Istio mesh spanning two spoke clusters. The ACM hub cluster is not changed — it remains dedicated to fleet management and centralized metrics collection.

What this guide adds:

A second spoke cluster (ossm-kiali-spoke-two) is imported into ACM and gets OSSM 3 installed
Both spoke clusters are updated to share a single Istio mesh via East-West gateways and cross-cluster endpoint discovery
ACM Observability is extended to collect metrics from the second spoke
Kiali on the first spoke gains API access to the second spoke’s workloads via a remote cluster secret
A cross-cluster demo app demonstrates traffic flowing between the two spokes

Cluster roles after this guide:

OpenID Connect strategy

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

The openid authentication strategy lets you integrate Kiali to an external identity provider that implements OpenID Connect, and allows users to login to Kiali using their existing accounts of a third-party system.

If your Kubernetes cluster is also integrated with your OpenId provider, then Kiali’s openid strategy can offer namespace access control.

Kiali only supports the authorization code flow of the OpenId Connect spec.

Requirements

The Kiali’s signing key needs to be 16, 24 or 32 byte long. If you install Kiali via the operator and don’t set a custom signing key, the operator should create a 16 byte long signing key.

TLS Configuration

Mon, 01 Jan 0001 00:00:00 +0000

Overview

When Kiali connects to external services (Prometheus, Grafana, Jaeger/Tempo, Perses) over HTTPS, it needs to verify the TLS certificates presented by those services. By default, Kiali trusts the system certificate authorities (CAs) that are built into the container image.

If your external services use certificates issued by a private CA (such as an internal corporate CA, a service mesh CA, or self-signed certificates), you need to configure Kiali to trust those additional CAs.

Dashboards and Tracing

Mon, 01 Jan 0001 00:00:00 +0000

This guide extends the result of the Multi-Primary Mesh guide by adding two observability tools that operate across both spoke clusters. Both tools are delivered through the Red Hat Cluster Observability Operator (COO), which manages their deployment and integrates them into the OpenShift console:

Phase 1 — Perses: Deploys a Perses metrics dashboard server and OpenShift console plugin via COO. The datasource is pointed at hub Thanos so it queries aggregated metrics from both spokes, giving a true multi-cluster view.
Phase 2 — Tempo: Deploys a distributed tracing server and OpenShift console plugin via COO. A central Tempo instance on spoke collects traces from both clusters via OpenTelemetry collectors. Kiali links to the console tracing UI and can filter traces by cluster. Neither ACM Observability nor any other component already in place aggregates traces — that requires an explicit OTEL pipeline, which this guide sets up.

The diagram below shows the environment after this guide completes. Components from Guides 1–2 are marked prior; badges such as G3:P2.4-2.5 mark which guide section(s) add each piece (Guide 3, §§2.4–2.5). Click the diagram to open a full-size SVG in a new tab.

Health Status Alerts

Mon, 01 Jan 0001 00:00:00 +0000

Overview

This guide is the fourth in the series but also works standalone. The earlier guides focus on setting up a multi-cluster OpenShift environment; this guide applies to any OpenShift cluster running Kiali — single-cluster or multi-cluster. Follow Phases 1–5 on any cluster to set up health-status alerting. Phase 6 adds optional multi-cluster integration with ACM for readers who completed the earlier guides. Phase 7 is also optional: it installs the Network Observability Operator on the Kiali cluster and surfaces the same health rules on Observe > Network Health.

OpenShift strategy

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

The openshift authentication strategy is the preferred and default strategy when Kiali is deployed on an OpenShift cluster.

When using the openshift strategy, a user logging into Kiali will be redirected to the login page of the OpenShift console. Once the user provides his OpenShift credentials, he will be redireted back to Kiali and will be logged in if the user has enough privileges.

The openshift strategy supports namespace access control.

The Kiali CR

Mon, 01 Jan 0001 00:00:00 +0000

The Kiali Operator watches the Kiali Custom Resource (Kiali CR), a custom resource that contains the Kiali Server deployment configuration. Creating, updating, or removing a Kiali CR will trigger the Kiali Operator to install, update, or remove Kiali.

If you want the operator to re-process the Kiali CR (called “reconciliation”) without having to change the Kiali CR’s spec fields, you can modify any annotation on the Kiali CR itself. This will trigger the operator to reconcile the current state of the cluster with the desired state defined in the Kiali CR, modifying cluster resources if necessary to get them into their desired state. Here is an example illustrating how you can modify an annotation on a Kiali CR:

$ kubectl annotate kiali my-kiali -n istio-system --overwrite kiali.io/reconcile="$(date)"

The OSSMConsole CR

Mon, 01 Jan 0001 00:00:00 +0000

OpenShift ServiceMesh Console (aka OSSMC) provides a Kiali integration with the OpenShift Console; in other words it provides Kiali functionality within the context of the OpenShift Console when a Kiali server is connected to the plugin. OSSMC is applicable only within OpenShift environments.

The main component of OSSMC is a plugin that gets installed inside the OpenShift Console. Prior to installing this plugin, you must install the Kiali Operator. A Kiali Server is optional for the initial plugin install — without it, OSSMC still provides Istios and Kialis pages for navigating multiple mesh instances from the console. See Navigating Multiple Meshes. Please see the Installation Guide for Kiali Operator installation details.

Accessing Kiali

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

After Kiali is succesfully installed you will need to make Kiali accessible to users. This page describes some popular methods of exposing Kiali for use.

If exposing Kiali in a custom way, you may need to set some configurations to make Kiali aware of how users will access Kiali.

The examples on this page assume that you followed the Installation guide to install Kiali, and that you installed Kiali in the istio-system namespace.

Token strategy

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

The token authentication strategy allows a user to login to Kiali using the token of a Kubernetes ServiceAccount. This is similar to the login view of Kubernetes Dashboard.

The token strategy supports namespace access control.

The token strategy is only supported for single cluster.

Set-up

Since token is the default strategy when deploying Kiali in Kubernetes, you shouldn’t need to configure anything, unless your cluster is OpenShift. If you want to be verbose or if you need to enable the token strategy in OpenShift, use the following configuration in the Kiali CR:

Advanced Install

Mon, 01 Jan 0001 00:00:00 +0000

Canary upgrades

During a canary upgrade where multiple controlplanes are present, Kiali will automatically detect both controlplanes. You can visit the mesh page to visualize your controlplanes during a canary upgrade.

Installing a Kiali Server of a different version than the Operator

When you install the Kiali Operator, it will be configured to install a Kiali Server that is the same version as the operator itself. For example, if you have Kiali Operator v1.34.0 installed, that operator will install Kiali Server v1.34.0. If you upgrade (or downgrade) the Kiali Operator, the operator will in turn upgrade (or downgrade) the Kiali Server.

Session options

Mon, 01 Jan 0001 00:00:00 +0000

There are two settings that are available for the user’s session. The first one is the session expiration time, which is only applicable to token and header authentication strategies:

spec:
 login_token:
 # By default, users session expires in 24 hours.
 expiration_seconds: 86400

The session expiration time is the amount of time before the user is asked to extend his session by another cycle. It does not matter if the user is actively using Kiali, the user will be asked if the session should be extended.

Example Install

Mon, 01 Jan 0001 00:00:00 +0000

This is a quick example of installing Kiali. This example will install the operator and two Kiali Servers - one server will require the user to enter credentials at a login screen in order to obtain read-write access and the second server will allow anonymous read-only access.

For this example, assume there is a Minikube Kubernetes cluster running with an Istio control plane installed in the namespace istio-system and the Istio Bookinfo Demo installed in the namespace bookinfo:

Uninstall Travel Demo

Mon, 01 Jan 0001 00:00:00 +0000

Remove components in reverse order of installation: the Travel Demo application, Kiali, Istio, and (on Kind) the cluster itself.

Uninstall the Travel Demo

Delete the demo namespaces:

kubectl delete namespace travel-agency
kubectl delete namespace travel-portal
kubectl delete namespace travel-control

Alternatively, delete the manifests first (this removes any Istio resources created in those namespaces during the tutorial):

kubectl delete -f <(curl -L https://raw.githubusercontent.com/kiali/demos/master/travels/travel_agency.yaml) -n travel-agency --ignore-not-found
kubectl delete -f <(curl -L https://raw.githubusercontent.com/kiali/demos/master/travels/travel_portal.yaml) -n travel-portal --ignore-not-found
kubectl delete -f <(curl -L https://raw.githubusercontent.com/kiali/demos/master/travels/travel_control.yaml) -n travel-control --ignore-not-found

kubectl delete namespace travel-agency
kubectl delete namespace travel-portal
kubectl delete namespace travel-control

OpenShift

If you used the Kiali Travel Demo install script, it can also remove OpenShift-specific resources (SecurityContextConstraints and NetworkAttachmentDefinitions):

./hack/istio/install-travel-agency-demo.sh -c oc -d true

AI

Mon, 01 Jan 0001 00:00:00 +0000

What is Kiali Chatbot and what is its status?

Kiali Chatbot is Kiali’s built-in AI assistant in the Kiali UI. It helps users ask questions about their service mesh and get responses grounded in live Kiali data (for example, graph, metrics, traces, logs, and resource details).

The chatbot was first released in Kiali 2.22 and is currently in Dev preview. See Kiali Chatbot for details.

Does Kiali Chatbot require an external MCP server?

No. Kiali Chatbot does not require an external MCP server. It uses internal MCP-style tools implemented in Kiali itself.

Ambient

Mon, 01 Jan 0001 00:00:00 +0000

Why can’t I see the traffic graph when not using a Waypoint?

There can be multiple reasons, but here are some troubleshooting steps:

Is the application correctly enrolled in Ambient? Make sure you see the Ambient label in the control plane card in Kiali, or make sure the namespace is labeled with istio.io/dataplane-mode=ambient.

This means that the traffic graph will have L4 metrics if there is traffic. You want to make sure the traffic selectors select ZTunnel as well as the type of traffic (e.g. Tcp) that is flowing:

Appearance

Mon, 01 Jan 0001 00:00:00 +0000

The standalone Kiali Console lets you customize how the interface looks on your device. These choices are saved in your browser and persist across sessions.

For language settings, see Internationalization.

Opening Preferences

Open the user dropdown in the top-right corner and select Preferences.

In the Preferences modal, adjust color scheme, contrast mode, and theme:

The examples below use the Overview page so you can compare how each option changes the console.

Application Wizards

Mon, 01 Jan 0001 00:00:00 +0000

Istio Application Wizards

Kiali provides Actions to create, update and delete Istio configuration, driven by wizards.

Actions can be applied to a Service

Actions can also be applied to a Workload

And, actions are available for an entire Namespace

Service Actions

Kiali offers a robust set of service actions, with accompanying wizards.

Traffic Management: Request Routing

The Request Routing Wizard allows creating multiple routing rules.

Architecture

Mon, 01 Jan 0001 00:00:00 +0000

Kiali architecture

Kiali is composed of two components: a back-end application running in the container application platform, and a user-facing front-end application. 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:

Kiali back-end

The back-end is the application that runs in the container application platform. It’s written in Go. The code can be found at kiali/kiali GitHub repository.

Authentication

Mon, 01 Jan 0001 00:00:00 +0000

How to obtain a token when logging in via token auth strategy

When configuring Kiali to use the token auth strategy, it requires users to log into Kiali as a specific user via the user’s service account token. Thus, in order to log into Kiali you must provide a valid Kubernetes token.

Note that the following examples assume you installed Kiali in the istio-system namespace.

For Kubernetes prior to v1.24

Concepts

Mon, 01 Jan 0001 00:00:00 +0000

Application

Is a logical grouping of Workloads defined by the application labels that users apply to an object. In Istio it is defined by the Label App. See Istio Label Requirements.

Application Name

It’s the name of the Application deployed in your environment. This name is provided by the Label App on the Workload.

Envoy

A proxy that Istio starts for each pod in the service mesh. For more information see the Istio Envoy Documentation.

Envoy Health

A health check performed by Envoy proxies, for inbound and outbound traffic: see membership_healthy and membership_total from Envoy documentation.

Console Customization

Mon, 01 Jan 0001 00:00:00 +0000

Custom metric aggregations

The inbound and outbound metric pages, in the Metrics settings drop-down, provides an opinionated set of groupings that work both for filtering out metric data that does not match the selection and for aggregating data into series. Each option is backed by a label on the collected Istio telemetry.

It is possible to add custom aggregations, like in the following example:

spec:
 kiali_feature_flags:
 ui_defaults:
 metrics_inbound:
 aggregations:
 - display_name: Istio Network
 label: topology_istio_io_network
 - display_name: Istio Revision
 label: istio_io_rev
 metrics_outbound:
 aggregations:
 - display_name: Istio Revision
 label: istio_io_rev

Notice that custom aggregations for inbound and outbound metrics are defined separately.

Custom Dashboards

Mon, 01 Jan 0001 00:00:00 +0000

Custom Dashboards require some configuration to work properly.

Declaring a custom dashboard

When installing Kiali, you define your own custom dashboards in the Kiali CR spec.custom_dashboards field. Here’s an example of what it looks like:

custom_dashboards:
- name: vertx-custom
 title: Vert.x Metrics
 runtime: Vert.x
 discoverOn: "vertx_http_server_connections"
 items:
 - chart:
 name: "Server response time"
 unit: "seconds"
 spans: 6
 metrics:
 - metricName: "vertx_http_server_responseTime_seconds"
 displayName: "Server response time"
 dataType: "histogram"
 aggregations:
 - label: "path"
 displayName: "Path"
 - label: "method"
 displayName: "Method"
 - chart:
 name: "Server active connections"
 unit: ""
 spans: 6
 metricName: "vertx_http_server_connections"
 dataType: "raw"
 - include: "micrometer-1.1-jvm"
 externalLinks:
 - name: "My custom Grafana dashboard"
 type: "grafana"
 variables:
 app: var-app
 namespace: var-namespace
 version: var-version

The name field corresponds to what you can set in the pod annotation kiali.io/dashboards.

Debugging Kiali

Mon, 01 Jan 0001 00:00:00 +0000

Logs

The most basic way of debugging the internals of Kiali is to examine its log messages. A typical way of examining the log messages is via:

kubectl logs -n istio-system deployment/kiali

Each log message is logged at a specific level. The different log levels are trace, debug, info, warn, error, and fatal. By default, log messages at info level and higher will be logged. If you want to see more verbose logs, set the log level to debug or trace (trace is the most verbose setting and will make the log output very “noisy”). You set the log level in the Kiali CR:

Detail Views

Mon, 01 Jan 0001 00:00:00 +0000

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:

Applications
Istio Configuration
Services
Workloads

Selecting an object from the list will bring you to its detail page. For Istio Config, Kiali will present its YAML, along with contextual validation information. Other mesh components present a variety of Tabs.

Development Environment

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

In this section it is explained how to set up a development environment:

As described in Architecture, we would need to have the Kiali dependencies running in an OpenShift or Kubernetes
We will use a port forward to access those services outside the cluster.
We will have the project source running locally. In this case we will set up an IDE.
Bookinfo application example will also be running on our cluster.

Distributed Tracing

Mon, 01 Jan 0001 00:00:00 +0000

How to know which is the URL for Jaeger or Tempo?

From Kiali 2.11, a new tracing tool in the Mesh page is provided to help troubleshooting and provide possible valid tracing configurations.

Why is Jaeger unreachable or Kiali showing the error “Could not fetch traces”?

Istio components status indicator shows “Jaeger unreachable”:

While on any Tracing page, error “Could not fetch traces” is displayed:

General

Mon, 01 Jan 0001 00:00:00 +0000

How do I determine what version I am running?

There are several components within the Istio/Kiali infrastructure that have version information.

To see the Kiali version for the instance running your UI: Go to the Help dropdown menu found at the top-right of the Kiali Console window and select “About”. This will pop up the About dialog box which displays detailed information for the current Kiali instance. From here you can also link to the Mesh page.

Help dropdown menu:

Graph

Mon, 01 Jan 0001 00:00:00 +0000

Why is my graph empty?

There are several reasons why a graph may be empty. First, make sure you have selected at least one namespace. Kiali will look for traffic into, out of, and within the selected namespaces. Another reason is that Istio is not actually generating the expected telemetry. This is typically an indication that workload pods have not been injected with the Istio sidecar proxy (Envoy proxy). But it can also mean that there is an issue with Prometheus configuration, and it is not scraping metrics as expected. To verify that telemetry is being reported to Prometheus, see this FAQ entry.

Health

Mon, 01 Jan 0001 00:00:00 +0000

Kiali help users know whether their service mesh is healthy. This includes the health of the mesh infrastructure itself, and the deployed application services.

Service Mesh Infrastructure Health

Users can quickly confirm the health of their infrastructure by looking at the Kiali Masthead. If Kiali detects any health issues with the infrastructure of the mesh, including multi-cluster setups, it will show an indication in the masthead, severity will be reflected via color, and hovering will show the detail:

Installation

Mon, 01 Jan 0001 00:00:00 +0000

What is the difference between the operator and the server helm chart?

There are two installation mechanisms from which you can choose when installing the Kiali Server. The first is the recommended installation mechanism - the Kiali Operator. The second installation mechanism is the server helm chart. There are some features that you get with the Kiali Operator that you do not get with the server helm chart. The main differences between the two are mentioned below, though this list may be incomplete.

Internationalization

Mon, 01 Jan 0001 00:00:00 +0000

Kiali is used worldwide and some users prefer to display Kiali in a language that they are more comfortable with than English. For this reason Kiali supports internationalization, and it can be localized into multiple languages.

Current supported languages are English, Chinese, Korean, and Spanish.

For color scheme, contrast, and theme settings, see Appearance.

Language preference

In the standalone Kiali Console, open Preferences from the user dropdown as described in Appearance, then choose a value in the Language dropdown.

Istio Ambient Mesh

Mon, 01 Jan 0001 00:00:00 +0000

Kiali provides visualization for Ambient Mesh components:

The Kiali Ambient features, as well as Ambient Mesh, are evolving. Some of these features are in alpha status. For enhancements or detected issues, don’t hesitate to open a GitHub issue.

Control Plane Ambient Mesh

When the control plane is in Ambient mode, Kiali will show an Ambient badge on the Namespaces page, for the control plane namespace, in the Type column. It will also be reflected in the control plane side-panel on the Mesh page. This badge indicates that Kiali has detected a ztunnel (the L4 component for Ambient) in the control plane namespace.

Istio Component Status

Mon, 01 Jan 0001 00:00:00 +0000

How can I add one component to the list?

If you are interested in adding one more component to the Istio Component Status tooltip, you have the option to add one new component into the Kiali CR, under the spec.external_services.istio.component_status field.

For each component there, you will need to specify the app label of the deployment’s pods, the namespace and whether is a core component or add-on.

One component is ‘Not found’ but I can see it running. What can I do?

The first thing you should do is check the Kiali CR for the spec.external_services.istio.component_status field (see the reference documentation here)

Istio Configuration

Mon, 01 Jan 0001 00:00:00 +0000

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 editing and powerful semantic validation for Istio resources.

Validations

Kiali performs a set of validations on your Istio Objects, such as Destination Rules, Service Entries, and Virtual Services. Kiali’s validations go above and beyond what Istio offers. Where Istio offers mainly static checks for well-formed definitions, Kiali performs semantic validations to ensure that the definitions make sense, across objects, and in some cases even across namespaces. Kiali validations are based on the runtime status of your service mesh.

Istio Environment

Mon, 01 Jan 0001 00:00:00 +0000

Labels and resource names

Istio recommends adding app and version labels to pods to attach this information to telemetry. Kiali relies on correctness of these labels for several features.

In Istio, it is possible to use a different set of labels, like app.kubernetes.io/name and app.kubernetes.io/version, however you must configure Kiali to the labels you are using. By default, Kiali uses Istio’s recommended labels:

spec:
 istio_labels:
 app_label_name: "app"
 version_label_name: "version"

Although Istio lets you use different labels on different pods, Kiali can only use a single set.

For example, Istio lets you use the app label in one pod and the app.kubernetes.io/name in another pod and it will generate telemetry correctly. However, you will have no way to configure Kiali for this case.

Istio Infrastructure Status

Mon, 01 Jan 0001 00:00:00 +0000

A service mesh simplifies application services by deferring the non-business logic to the mesh. But for healthy applications the service mesh infrastructure must also be running normally. Kiali monitors the multiple components that make up the service mesh, letting you know if there is an underlying problem.

A component status will be one of: Not found, Not ready, Unreachable, Not healthy and Healthy. Not found means that Kiali is not able to find the deployment. Not ready means no pods are running. Unreachable means that Kiali hasn’t been successfully able to communicate with the component (Prometheus, Grafana and Jaeger). Not healthy means that the deployment doesn’t have the desired amount of replicas running. Otherwise, the component is Healthy and it won’t be shown in the list.

Kiali CR Reference

Mon, 01 Jan 0001 00:00:00 +0000

Example CR

(all values shown here are the defaults unless otherwise noted)

apiVersion: kiali.io/v1alpha1
kind: Kiali
metadata:
 name: kiali
 annotations:
 ansible.sdk.operatorframework.io/verbosity: "1"
spec:
 additional_display_details:
 - title: "API Documentation"
 annotation: "kiali.io/api-spec"
 icon_annotation: "kiali.io/api-type"

 installation_tag: ""

 version: "default"

 ai:
 chat:
 allowed_users: []
 default_provider: ""
 enabled: false
 max_tool_iterations: 5
 providers: []
 store_config:
 enabled: true
 inactivity_timeout: "30m"
 max_cache_memory_mb: 1024
 reduce_threshold: 15
 reduce_with_ai: false
 tools: {}
 consumption:
 allowed_users_dashboard: []
 budgets: []
 prices_config_map: ""
 enabled: false
 metrics: false

 auth:
 strategy: ""
 openid:
 # default: additional_request_params is empty
 additional_request_params:
 openIdReqParam: "openIdReqParamValue"
 # default: allowed_domains is an empty list
 allowed_domains: ["allowed.domain"]
 api_proxy: ""
 api_proxy_ca_data: ""
 api_token: "id_token"
 authentication_timeout: 300
 authorization_endpoint: ""
 client_id: ""
 disable_rbac: false
 http_proxy: ""
 https_proxy: ""
 insecure_skip_verify_tls: false
 issuer_uri: ""
 post_logout_redirect_uri: ""
 scopes: ["openid", "profile", "email"]
 username_claim: "sub"
 discovery_override:
 authorization_endpoint: ""
 end_session_endpoint: ""
 jwks_uri: ""
 token_endpoint: ""
 userinfo_endpoint: ""
 openshift:
 impersonation:
 allowed_groups: []
 allowed_users: []
 enabled: false
 #redirect_uris:
 #token_inactivity_timeout:
 #token_max_age: 

 clustering:
 autodetect_secrets:
 enabled: true
 label: "kiali.io/multiCluster=true"
 clusters: []
 ignore_home_cluster: false
 kiali_urls: []

 # default: custom_dashboards is an empty list
 custom_dashboards:
 - name: "envoy"

 deployment:
 additional_pod_containers_yaml: []
 additional_pod_init_containers_yaml: []
 # default: additional_service_yaml is empty
 additional_service_yaml:
 externalName: "kiali.example.com"
 affinity:
 # default: node is empty
 node:
 requiredDuringSchedulingIgnoredDuringExecution:
 nodeSelectorTerms:
 - matchExpressions:
 - key: kubernetes.io/e2e-az-name
 operator: In
 values:
 - e2e-az1
 - e2e-az2
 # default: pod is empty
 pod:
 requiredDuringSchedulingIgnoredDuringExecution:
 - labelSelector:
 matchExpressions:
 - key: security
 operator: In
 values:
 - S1
 topologyKey: topology.kubernetes.io/zone
 # default: pod_anti is empty
 pod_anti:
 preferredDuringSchedulingIgnoredDuringExecution:
 - weight: 100
 podAffinityTerm:
 labelSelector:
 matchExpressions:
 - key: security
 operator: In
 values:
 - S2
 topologyKey: topology.kubernetes.io/zone
 cluster_wide_access: true
 # default: configmap_annotations is empty
 configmap_annotations:
 strategy.spinnaker.io/versioned: "false"
 # default: custom_envs is an empty list
 custom_envs:
 - name: "HTTP_PROXY"
 value: "http://my.proxy.com:1234"
 - name: "NO_PROXY"
 value: "hostname.example.com"
 # default: custom_secrets is an empty list
 custom_secrets:
 - name: "a-custom-secret"
 mount: "/a-custom-secret-path"
 optional: true
 - name: "a-csi-secret"
 mount: "/a-csi-secret-path"
 csi:
 driver: secrets-store.csi.k8s.io
 readOnly: true
 volumeAttributes:
 secretProviderClass: kiali-secretprovider
 # default: discovery_selectors is empty
 discovery_selectors:
 default:
 - matchLabels:
 region: north
 - matchExpressions:
 - key: organization
 operator: "In"
 values: ["engineering", "accounting"]
 - matchLabels:
 region: south
 matchExpressions:
 - key: app
 operator: "DoesNotExist"
 - key: domain
 operator: "NotIn"
 values: ["production"]
 overrides:
 myRemoteCluster:
 - matchLabels:
 region: world
 - matchExpressions:
 - key: organization
 operator: "NotIn"
 values: ["marketing"]
 - matchLabels:
 region: antarctica
 matchExpressions:
 - key: app
 operator: "DoesNotExist"
 - key: domain
 operator: "In"
 values: ["staging"]
 dns:
 # default: config is empty
 config:
 options:
 - name: ndots
 value: "1"
 # default: policy is empty
 policy: "ClusterFirst"
 extra_labels: {}
 # default: host_aliases is an empty list
 host_aliases:
 - ip: "192.168.1.100"
 hostnames:
 - "foo.local"
 - "bar.local"
 hpa:
 api_version: ""
 # default: spec is empty
 spec:
 maxReplicas: 2
 minReplicas: 1
 metrics:
 - type: Resource
 resource:
 name: cpu
 target:
 type: Utilization
 averageUtilization: 50
 image_digest: ""
 image_name: ""
 image_pull_policy: "IfNotPresent"
 # default: image_pull_secrets is an empty list
 image_pull_secrets: ["image.pull.secret"]
 image_version: ""
 ingress:
 # default: additional_labels is empty
 additional_labels:
 ingressAdditionalLabel: "ingressAdditionalLabelValue"
 class_name: "nginx"
 # default: enabled is undefined
 enabled: false
 # default: override_yaml is undefined
 override_yaml:
 metadata:
 annotations:
 nginx.ingress.kubernetes.io/secure-backends: "true"
 nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
 spec:
 rules:
 - http:
 paths:
 - path: "/kiali"
 pathType: Prefix
 backend:
 service:
 name: "kiali"
 port:
 number: 20001
 instance_name: "kiali"
 logger:
 log_level: "info"
 log_format: "text"
 sampler_rate: "1"
 time_field_format: "2006-01-02T15:04:05Z07:00"
 namespace: "istio-system"
 network_policy:
 enabled: true
 # default: node_selector is empty
 node_selector:
 nodeSelector: "nodeSelectorValue"
 # default: pod_annotations is empty
 pod_annotations:
 proxy.istio.io/config: '{ "holdApplicationUntilProxyStarts": true }'
 pod_disruption_budget:
 api_version: ""
 # default: spec is empty
 spec:
 minAvailable: 1
 # default: pod_labels is empty
 pod_labels:
 sidecar.istio.io/inject: "true"
 priority_class_name: ""
 probes:
 liveness:
 initial_delay_seconds: 5
 period_seconds: 30
 readiness:
 initial_delay_seconds: 5
 period_seconds: 30
 startup:
 failure_threshold: 6
 initial_delay_seconds: 30
 period_seconds: 10
 remote_cluster_resources_only: false
 replicas: 1
 # default: resources is undefined
 resources:
 requests:
 cpu: "10m"
 memory: "64Mi"
 limits:
 memory: "1Gi"
 secret_name: "kiali"
 security_context: {}
 # default: service_annotations is empty
 service_annotations:
 svcAnnotation: "svcAnnotationValue"
 # default: service_labels is empty
 service_labels:
 svcLabel: "svcLabelValue"
 # default: service_type is undefined
 service_type: "NodePort"
 strategy: {}
 # default: tolerations is an empty list
 tolerations:
 - key: "example-key"
 operator: "Exists"
 effect: "NoSchedule"
 topology_spread_constraints: []
 version_label: ""
 view_only_mode: false

 # default: extensions is an empty list
 extensions:
 - enabled: true
 name: "skupper"

 external_services:
 custom_dashboards:
 discovery_auto_threshold: 10
 discovery_enabled: "auto"
 enabled: true
 is_core: false
 namespace_label: "namespace"
 prometheus:
 auth:
 insecure_skip_verify: false
 oauth2:
 audience: ""
 auth_style: "header"
 client_id: ""
 client_secret: ""
 scopes: []
 token_url: ""
 password: ""
 token: ""
 type: "none" # Valid values: none, basic, bearer, oauth2
 use_kiali_token: false
 username: ""
 cache_duration: 7
 cache_enabled: true
 cache_expiration: 300
 # default: custom_headers is empty
 custom_headers:
 customHeader1: "customHeader1Value"
 health_check_url: ""
 is_core: true
 # default: query_scope is empty
 query_scope:
 mesh_id: "mesh-1"
 cluster: "cluster-east"
 thanos_proxy:
 enabled: false
 retention_period: "7d"
 scrape_interval: "30s"
 url: ""
 grafana:
 auth:
 insecure_skip_verify: false
 oauth2:
 audience: ""
 auth_style: "header"
 client_id: ""
 client_secret: ""
 scopes: []
 token_url: ""
 password: ""
 token: ""
 type: "none" # Valid values: none, basic, bearer, oauth2
 use_kiali_token: false
 username: ""
 dashboards:
 - name: "Istio Service Dashboard"
 variables:
 datasource: "var-datasource"
 namespace: "var-namespace"
 service: "var-service"
 version: "var-version"
 - name: "Istio Workload Dashboard"
 variables:
 datasource: "var-datasource"
 namespace: "var-namespace"
 workload: "var-workload"
 version: "var-version"
 - name: "Istio Mesh Dashboard"
 - name: "Istio Control Plane Dashboard"
 - name: "Istio Performance Dashboard"
 - name: "Istio Wasm Extension Dashboard"
 datasource_uid: ""
 enabled: true
 external_url: ""
 health_check_url: ""
 internal_url: "http://grafana.istio-system:3000"
 is_core: false
 istio:
 component_status:
 components: []
 enabled: true
 gateway_api_classes: []
 gateway_api_classes_label_selector: ""
 istio_api_enabled: true
 istio_identity_domain: ""
 istiod_polling_interval_seconds: 20
 validation_change_detection_enabled: true
 validation_reconcile_interval: "1m"
 perses:
 auth:
 insecure_skip_verify: false
 oauth2:
 audience: ""
 auth_style: "header"
 client_id: ""
 client_secret: ""
 scopes: []
 token_url: ""
 password: ""
 type: "none" # Valid values: none, basic, bearer, oauth2
 use_kiali_token: false
 username: ""
 dashboards:
 - name: "Istio Service Dashboard"
 variables:
 datasource: "var-datasource"
 namespace: "var-namespace"
 service: "var-service"
 version: "var-version"
 - name: "Istio Workload Dashboard"
 variables:
 datasource: "var-datasource"
 namespace: "var-namespace"
 workload: "var-workload"
 version: "var-version"
 - name: "Istio Mesh Dashboard"
 - name: "Istio Control Plane Dashboard"
 - name: "Istio Performance Dashboard"
 - name: "Istio Wasm Extension Dashboard"
 enabled: false
 external_url: ""
 health_check_url: ""
 internal_url: ""
 is_core: false
 project: "istio"
 url_format: ""
 prometheus:
 auth:
 insecure_skip_verify: false
 oauth2:
 audience: ""
 auth_style: "header"
 client_id: ""
 client_secret: ""
 scopes: []
 token_url: ""
 password: ""
 token: ""
 type: "none" # Valid values: none, basic, bearer, oauth2
 use_kiali_token: false
 username: ""
 cache_duration: 7
 cache_enabled: true
 cache_expiration: 300
 # default: custom_headers is empty
 custom_headers:
 customHeader1: "customHeader1Value"
 enabled: true
 health_check_url: ""
 is_core: true
 # default: query_scope is empty
 query_scope:
 mesh_id: "mesh-1"
 cluster: "cluster-east"
 thanos_proxy:
 enabled: false
 retention_period: "7d"
 scrape_interval: "30s"
 url: ""
 tracing:
 auth:
 insecure_skip_verify: false
 oauth2:
 audience: ""
 auth_style: "header"
 client_id: ""
 client_secret: ""
 scopes: []
 token_url: ""
 password: ""
 token: ""
 type: "none" # Valid values: none, basic, bearer, oauth2
 use_kiali_token: false
 username: ""
 # default: custom_headers is empty
 custom_headers:
 customHeader1: "customHeader1Value"
 disable_version_check: false
 enabled: false
 external_url: ""
 grpc_port: 9095
 health_check_url: ""
 internal_url: ""
 is_core: false
 namespace_selector: true
 provider: "jaeger"
 # default: query_scope is empty
 query_scope:
 mesh_id: "mesh-1"
 cluster: "cluster-east"
 query_timeout: 5
 tempo_config:
 cache_capacity: 200
 cache_enabled: true
 datasource_uid: ""
 name: ""
 namespace: ""
 org_id: ""
 tenant: ""
 url_format: "grafana"
 use_grpc: true
 use_waypoint_name: false
 whitelist_istio_system: ["jaeger-query", "istio-ingressgateway"]

 health_config:
 compute:
 duration: "5m"
 refresh_interval: "3m"
 timeout: "10m"
 # default: rate is an empty list
 rate:
 - namespace: ".*"
 kind: ".*"
 name: ".*"
 tolerance:
 - protocol: "http"
 direction: ".*"
 code: "[1234]00"
 degraded: 5
 failure: 10

 identity:
 # default: cert_file is undefined
 cert_file: ""
 # default: private_key_file is undefined
 private_key_file: ""

 istio_labels:
 app_label_name: ""
 version_label_name: ""

 kiali_feature_flags:
 authz:
 require_namespace_get: false
 clustering:
 enable_exec_provider: false
 # default: custom_workload_types is an empty list
 custom_workload_types:
 - group: "argoproj.io"
 version: "v1alpha1"
 kind: "Rollout"
 disabled_features: []
 istio_annotation_action: true
 istio_injection_action: true
 istio_upgrade_action: false
 ui_defaults:
 graph:
 find_options:
 - description: "Find: slow edges (> 1s)"
 expression: "rt > 1000"
 - description: "Find: unhealthy nodes"
 expression: "! healthy"
 - description: "Find: unknown nodes"
 expression: "name = unknown"
 hide_options:
 - description: "Hide: healthy nodes"
 expression: "healthy"
 - description: "Hide: unknown nodes"
 expression: "name = unknown"
 settings:
 animation: "point"
 traffic:
 ambient: "total"
 grpc: "requests"
 http: "requests"
 tcp: "sent"
 i18n:
 language: "en"
 list:
 include_health: true
 include_istio_resources: true
 include_validations: true
 show_include_toggles: false
 mesh:
 find_options:
 - description: "Find: unhealthy nodes"
 expression: "! healthy"
 hide_options:
 - description: "Hide: healthy nodes"
 expression: "healthy"
 # default: metrics_inbound is undefined
 metrics_inbound:
 aggregations:
 - display_name: "Istio Network"
 label: "topology_istio_io_network"
 single_selection: false
 - display_name: "Istio Revision"
 label: "istio_io_rev"
 single_selection: false
 # default: metrics_outbound is undefined
 metrics_outbound:
 aggregations:
 - display_name: "Istio Network"
 label: "topology_istio_io_network"
 single_selection: false
 - display_name: "Istio Revision"
 label: "istio_io_rev"
 single_selection: false
 metrics_per_refresh: "1m"
 # default: namespaces is an empty list
 namespaces: ["istio-system"]
 refresh_interval: "1m"
 tracing:
 limit: 100
 validations:
 ignore: ["KIA1301"]
 skip_wildcard_gateway_hosts: false

 kubernetes_config:
 burst: 200
 cache_duration: 300
 cache_token_namespace_duration: 10
 excluded_workloads:
 - "CronJob"
 - "DeploymentConfig"
 - "Job"
 - "ReplicationController"
 qps: 175

 login_token:
 expiration_seconds: 86400
 signing_key: ""

 server:
 address: ""
 audit_log: true
 cors_allow_all: false
 gzip_enabled: true
 # default: node_port is undefined
 node_port: 32475
 observability:
 metrics:
 enabled: true
 health_status:
 enabled: false
 max_consecutive_na: 3
 port: 9090
 tracing:
 collector_type: "otel"
 collector_url: "jaeger-collector.istio-system:4318"
 enabled: false
 otel:
 ca_name: ""
 protocol: "http"
 skip_verify: false
 tls_enabled: false
 sampling_rate: 0.5
 port: 20001
 profiler:
 enabled: false
 require_auth: false
 web_fqdn: ""
 web_history_mode: "browser"
 web_port: ""
 web_root: ""
 web_schema: ""
 write_timeout: "60s"

Validating your Kiali CR

The Kiali CR has a CRD Schema so it will be validated when you create or update it in your cluster.

Properties

.spec

(object)

This is the CRD for the resources called Kiali CRs. The Kiali Operator will watch for resources of this type and when it detects a Kiali CR has been added, deleted, or modified, it will install, uninstall, and update the associated Kiali Server installation. The settings here will configure the Kiali Server as well as the Kiali Operator. All of these settings will be stored in the Kiali ConfigMap. Do not modify the ConfigMap; it will be managed by the Kiali Operator. Only modify the Kiali CR when you want to change a configuration setting.

.spec.additional_display_details

(array)

A list of additional details that Kiali will look for in annotations. When found on any workload or service, Kiali will display the additional details in the respective workload or service details page. This is typically used to inject some CI metadata or documentation links into Kiali views. For example, by default, Kiali will recognize these annotations on a service or workload (e.g. a Deployment, StatefulSet, etc.):

spec:
 annotations:
 kiali.io/api-spec: http://list/to/my/api/doc
 kiali.io/api-type: rest

Note that if you change this setting for your own custom annotations, keep in mind that it would override the current default. So you would have to add the default setting as shown in the example CR if you want to preserve the default links.

(array)

A list of users that are allowed to use the ChatAI feature. If this list is empty, all users have access. If populated, only the specified users can see and interact with the Chatbot.

.spec.ai.chat.allowed_users[*]

(string)

.spec.ai.chat.default_provider

(string)

The default provider to use for the ChatAI feature. This is the provider that will be used if no provider is specified in the request.

.spec.ai.chat.enabled

(boolean)

Enable or disable the ChatAI feature.

.spec.ai.chat.max_tool_iterations

(integer)

Maximum number of tool-call iterations (LLM call + tool execution round) allowed per request before the loop is force-aborted. Must be between 1 and 20.

.spec.ai.chat.providers

(array)

A list of providers that can be used for the ChatAI feature. This is the list of providers that will be available to the user to choose from.

(array)

A list of models that can be used for the ChatAI feature. This is the list of models that will be available to the user to choose from.

(object)

Configuration for the ChatAI store.

.spec.ai.chat.store_config.enabled

(boolean)

Enable or disable the ChatAI store.

.spec.ai.chat.store_config.inactivity_timeout

(string)

Idle time allowed before the conversation is deleted due to inactivity.

.spec.ai.chat.store_config.max_cache_memory_mb

(integer)

The maximum cache memory for the ChatAI store.

.spec.ai.chat.store_config.reduce_threshold

(integer)

The threshold for the ChatAI store reduction with AI. This is the number of messages in a conversation before the conversation is reduced.

.spec.ai.chat.store_config.reduce_with_ai

(boolean)

Enable or disable the ChatAI store reduction with AI.

.spec.ai.chat.tools

(object)

Optional global filter for the ChatAI toolset. enabled_tools acts as an allowlist. disabled_tools acts as a denylist and is applied afterwards.

.spec.ai.chat.tools.disabled_tools

(array)

A denylist of tool names to hide from all ChatAI providers. Applied after enabled_tools.

.spec.ai.chat.tools.disabled_tools[*]

(string)

.spec.ai.chat.tools.enabled_tools

(array)

An allowlist of tool names to expose to ChatAI providers. If set, only the listed tool names remain available.

.spec.ai.chat.tools.enabled_tools[*]

(string)

.spec.ai.consumption

(object)

(number)

Maximum estimated cost allowed in the budget interval, in the pricing currency (typically USD).

.spec.ai.consumption.budgets[*].max_tokens

(number)

Maximum number of tokens allowed in the budget interval, expressed in millions of tokens.

.spec.ai.consumption.budgets[*].usernames

(array)

Users this budget applies to. Use * as a catch-all. Required and must not be empty.

.spec.ai.consumption.budgets[].usernames[]

(string)

.spec.ai.consumption.prices_config_map

(string)

Name of a ConfigMap in the Kiali deployment namespace that holds a custom token pricing catalog. The ConfigMap is user-managed (the operator never creates or writes it). The operator mounts it read-only at /kiali-ai-pricing with optional: true. If omitted or empty, or if the file cannot be read, Kiali uses its built-in catalog. For the ConfigMap format and how to install it, see the documentation at https://kiali.io/docs/ai/chatbot/kiali-chatbot-prices/

.spec.ai.enabled

(boolean)

Enable or disable the AI feature.

.spec.ai.metrics

(boolean)

Enable or disable ChatAI usage metrics. Required for consumption tracking and the AI dashboard.

.spec.api

(object)

DEPRECATED AFTER v1.73: These settings control how the Kiali API should be accessed.

.spec.api.namespaces

(object)

(string)

DEPRECATED AFTER v1.73: A Kubernetes label selector expression that will be used to include namespaces.

.spec.auth

(object)

.spec.auth.openid

(object)

(string)

DEPRECATED since v2.21: Use auth.openid.discovery_override.authorization_endpoint instead. The URL of the provider’s authorization endpoint.

.spec.auth.openid.client_id

(string)

(string)

.spec.auth.openid.scopes

(array)

.spec.auth.openid.scopes[*]

(string)

.spec.auth.openid.username_claim

(string)

.spec.auth.openshift

(object)

To learn more about these settings and how to configure the OpenShift authentication strategy, read the documentation at https://kiali.io/docs/configuration/authentication/openshift/

.spec.auth.openshift.auth_timeout

(integer)

DEPRECATED AFTER v1.73: The amount of time in seconds Kiali will wait for a response from the OpenShift API when requesting authentication information.

.spec.auth.openshift.client_id_prefix

(string)

DEPRECATED AFTER v1.73: A prefix that will be applied to the OpenShift OAuth client identifier.

.spec.auth.openshift.impersonation

(object)

Settings for Kubernetes API impersonation. When enabled, users authenticate once to the home cluster and Kiali uses its service account to impersonate the user on all clusters (including home).

.spec.auth.openshift.impersonation.allowed_groups

(array)

When set, only these groups will be included in impersonation headers (in addition to system:authenticated and system:authenticated:oauth which are always included). If empty, all of the user’s groups are impersonated. This also restricts the Kiali SA’s ClusterRole via resourceNames. Must not contain system: prefixed groups. For full RBAC defense-in-depth, configure both allowed_users and allowed_groups.

.spec.auth.openshift.impersonation.allowed_groups[*]

The default provider to use for the ChatAI feature. This is the provider that will be used if no provider is specified in the request.

.spec.chat_ai.enabled

(boolean)

Enable or disable the ChatAI feature.

.spec.chat_ai.max_tool_iterations

(integer)

Maximum number of tool-call iterations (LLM call + tool execution round) allowed per request before the loop is force-aborted. Must be between 1 and 20.

.spec.chat_ai.providers

(array)

A list of providers that can be used for the ChatAI feature. This is the list of providers that will be available to the user to choose from.

.spec.chat_ai.providers[*]

(object)

(string)

.spec.chat_ai.providers[*].models

(array)

A list of models that can be used for the ChatAI feature. This is the list of models that will be available to the user to choose from.

.spec.chat_ai.providers[].models[]

(object)

.spec.chat_ai.providers[].models[].description

(string)

The description of the model.

.spec.chat_ai.providers[].models[].enabled

(boolean)

Enable or disable the model.

.spec.chat_ai.providers[].models[].endpoint

(string)

The endpoint of the model.

(object)

Configuration for the ChatAI store.

.spec.chat_ai.store_config.enabled

(boolean)

Enable or disable the ChatAI store.

.spec.chat_ai.store_config.inactivity_timeout

(string)

Idle time allowed before the conversation is deleted due to inactivity.

.spec.chat_ai.store_config.max_cache_memory_mb

(integer)

The maximum cache memory for the ChatAI store.

.spec.chat_ai.store_config.reduce_threshold

(integer)

The threshold for the ChatAI store reduction with AI. This is the number of messages in a conversation before the conversation is reduced.

.spec.chat_ai.store_config.reduce_with_ai

(boolean)

Enable or disable the ChatAI store reduction with AI.

.spec.chat_ai.tools

(object)

Optional global filter for the ChatAI toolset. enabled_tools acts as an allowlist. disabled_tools acts as a denylist and is applied afterwards.

.spec.chat_ai.tools.disabled_tools

(array)

A denylist of tool names to hide from all ChatAI providers. Applied after enabled_tools.

.spec.chat_ai.tools.disabled_tools[*]

(string)

.spec.chat_ai.tools.enabled_tools

(array)

An allowlist of tool names to expose to ChatAI providers. If set, only the listed tool names remain available.

.spec.chat_ai.tools.enabled_tools[*]

(string)

.spec.clustering

(object)

Multi-cluster related features.

.spec.clustering.autodetect_secrets

(object)

Settings to allow cluster secrets to be auto-detected. Secrets must exist in the Kiali deployment namespace.

.spec.clustering.autodetect_secrets.enabled

(boolean)

If true then remote cluster secrets will be autodetected during the installation of the Kiali Server Deployment. Any remote cluster secrets found in the Kiali deployment namespace will be mounted to the Kiali Server’s file system. If false, you can still manually specify the remote cluster secret information in the ‘clusters’ setting if you wish to utilize multicluster features.

.spec.clustering.autodetect_secrets.label

(string)

The name and value of a label that exists on all remote cluster secrets.

.spec.clustering.clusters

(array)

A list of clusters that the Kiali Server can access. You need to specify the remote clusters here if ‘autodetect_secrets.enabled’ is false.

.spec.clustering.clusters[*]

(object)

.spec.clustering.clusters[*].name

(string)

The name of the cluster.

.spec.clustering.clusters[*].secret_name

(string)

The name of the secret that contains the credentials necessary to connect to the remote cluster. This secret must exist in the Kiali deployment namespace. If a secret name is not provided then it’s assumed that the cluster is inaccessible.

.spec.clustering.enable_exec_provider

(boolean)

Flag to enable exec provider for clustering authentication.

.spec.clustering.ignore_home_cluster

(boolean)

Set to true for an external Kiali deployment, or if Kiali should not try to discover Istio on the home cluster. When set to true, it is required to set kubernetes_config.cluster_name.

.spec.clustering.kiali_urls

(array)

A map between cluster name, instance name and namespace to a Kiali URL. Will be used showing the Mesh page’s Kiali URLs. The Kiali service’s ‘kiali.io/external-url’ annotation will be overridden when this property is set.

.spec.clustering.kiali_urls[*]

(object)

.spec.clustering.kiali_urls[*].cluster_name

(string)

The name of the cluster.

.spec.clustering.kiali_urls[*].instance_name

(string)

The instance name of this Kiali installation. This should be the value used in deployment.instance_name for Kiali resource name.

.spec.clustering.kiali_urls[*].namespace

(string)

The namespace into which Kiali is installed.

.spec.clustering.kiali_urls[*].url

(string)

The URL of Kiali in the cluster.

.spec.custom_dashboards

(array)

A list of user-defined custom monitoring dashboards that you can use to generate metrics charts for your applications. The server has some built-in dashboards; if you define a custom dashboard here with the same name as a built-in dashboard, your custom dashboard takes precedence and will overwrite the built-in dashboard. You can disable one or more of the built-in dashboards by simply defining an empty dashboard.

An example of an additional user-defined dashboard,

spec:
 custom_dashboards:
 - name: myapp
 title: My App Metrics
 items:
 - chart:
 name: "Thread Count"
 spans: 4
 metricName: "thread-count"
 dataType: "raw"

An example of disabling a built-in dashboard (in this case, disabling the Envoy dashboard),

spec:
 custom_dashboards:
 - name: envoy

To learn more about custom monitoring dashboards, see the documentation at https://kiali.io/docs/configuration/custom-dashboard/

(object)

Additional custom yaml to add to the service definition. This is used mainly to customize the service type. For example, if the deployment.service_type is set to ‘LoadBalancer’ and you want to set the loadBalancerIP, you can do so here with: additional_service_yaml: { 'loadBalancerIP': '78.11.24.19' }. Another example would be if the deployment.service_type is set to ‘ExternalName’ you will need to configure the name via: additional_service_yaml: { 'externalName': 'my.kiali.example.com' }. A final example would be if external IPs need to be set: additional_service_yaml: { 'externalIPs': ['80.11.12.10'] }

.spec.deployment.affinity

(object)

Affinity definitions that are to be used to define the nodes where the Kiali pod should be constrained. See the Kubernetes documentation on Assigning Pods to Nodes for the proper syntax for these three different affinity types.

.spec.deployment.affinity.node

(object)

.spec.deployment.affinity.pod

(object)

.spec.deployment.affinity.pod_anti

(object)

.spec.deployment.cluster_wide_access

(boolean)

Determines if the Kiali server will be granted cluster-wide permissions to see all namespaces. When true, this provides more efficient caching within the Kiali server. It must be true if deployment.discovery_selectors.default is left unset. To limit the namespaces for which Kiali has permissions, set to false and define the desired selectors in deployment.discovery_selectors.default.

.spec.deployment.configmap_annotations

(object)

Custom annotations to be created on the Kiali ConfigMap.

.spec.deployment.custom_envs

(array)

Defines additional environment variables to be set in the Kiali server pod. This is typically used for (but not limited to) setting proxy environment variables such as HTTP_PROXY, HTTPS_PROXY, and/or NO_PROXY.

.spec.deployment.custom_envs[*]

(object)

.spec.deployment.custom_envs[*].name

(string) *Required*

The name of the custom environment variable.

.spec.deployment.custom_envs[*].value

(string) *Required*

The value of the custom environment variable.

.spec.deployment.custom_secrets

(array)

Defines additional secrets that are to be mounted in the Kiali pod.

These are useful to contain client certificates that are used by Kiali to authenticate to third party systems using mTLS (for example, see external_services.tracing.auth.cert_file and external_services.tracing.auth.key_file).

These secrets must be created by an external mechanism. Kiali will not generate these secrets; it is assumed these secrets are externally managed. You can define 0, 1, or more secrets. An example configuration is,

spec:
 deployment:
 custom_secrets:
 - name: mysecret
 mount: /mysecret-path
 - name: my-other-secret
 mount: /my-other-secret-location
 optional: true

spec:
 deployment:
 host_aliases:
 - ip: 192.168.1.100
 hostnames:
 - "foo.local"
 - "bar.local"

For details on the content of this setting, see https://kubernetes.io/docs/tasks/network/customize-hosts-file-for-pods/#adding-additional-entries-with-hostaliases

.spec.deployment.host_aliases[*]

(object)

.spec.deployment.host_aliases[*].hostnames

(array)

.spec.deployment.host_aliases[].hostnames[]

(string)

.spec.deployment.host_aliases[*].ip

(string)

.spec.deployment.hpa

(object)

Determines what (if any) HorizontalPodAutoscaler should be created to autoscale the Kiali pod. A typical way to configure HPA for Kiali is,

spec:
 deployment:
 hpa:
 api_version: "autoscaling/v2"
 spec:
 maxReplicas: 2
 minReplicas: 1
 metrics:
 - type: Resource
 resource:
 name: cpu
 target:
 type: Utilization
 averageUtilization: 50

.spec.deployment.image_pull_secrets[*]

(string)

.spec.deployment.image_version

(string)

Determines which version of Kiali to install. Choose ‘lastrelease’ to use the last Kiali release. Choose ‘latest’ to use the latest image (which may or may not be a released version of Kiali). Choose ‘operator_version’ to use the image whose version is the same as the operator version. Otherwise, you can set this to any valid Kiali version (such as ‘v1.0’) or any valid Kiali digest hash (if you set this to a digest hash, you must indicate the digest in deployment.image_digest).

Note that if this is set to ‘latest’ then the deployment.image_pull_policy will be set to ‘Always’.

Note that override_yaml.metadata.labels is not allowed - you cannot override the labels; to add labels to the default set of labels, use the deployment.ingress.additional_labels setting. Example,

spec:
 deployment:
 ingress:
 override_yaml:
 metadata:
 annotations:
 nginx.ingress.kubernetes.io/secure-backends: "true"
 nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
 spec:
 rules:
 - http:
 paths:
 - path: /kiali
 pathType: Prefix
 backend:
 service
 name: "kiali"
 port:
 number: 20001

.spec.deployment.ingress.override_yaml.metadata

(object)

.spec.deployment.ingress.override_yaml.metadata.annotations

(object)

(object)

Custom annotations to be created on the Kiali pod. By default, the following annotation is applied:

proxy.istio.io/config: '{ "holdApplicationUntilProxyStarts": true }'

If you define your own pod_annotations, they will overwrite this default. To retain the default behavior while adding your own annotations, make sure to include this value alongside your custom annotations.

.spec.deployment.pod_disruption_budget

(object)

Determines what (if any) PodDisruptionBudget should be created for the Kiali pod. A typical way to configure PDB for Kiali is,

spec:
 deployment:
 pod_disruption_budget:
 api_version: "policy/v1"
 spec:
 minAvailable: 1

.spec.deployment.pod_disruption_budget.api_version

(string)

A specific PDB API version that can be specified in case there is some PDB feature you want to use that is only supported in that specific version. If value is an empty string, the default version of ‘policy/v1’ will be used.

.spec.deployment.pod_disruption_budget.spec

(object)

The spec specified here will be placed in the created PDB resource’s ‘spec’ section. If spec is left empty, no PDB resource will be created. Note that you must not specify the ‘selector’ section in spec; the Kiali Operator will populate that for you.

.spec.deployment.pod_labels

(object)

Custom labels to be created on the Kiali pod. An example use for this setting is to inject an Istio sidecar such as,

sidecar.istio.io/inject: "true"

Note that if you set a label key that conflicts with a standard Kiali label, your value will take precedence (user labels win on collision).

.spec.deployment.priority_class_name

(string)

The priorityClassName used to assign the priority of the Kiali pod.

.spec.deployment.probes

.spec.deployment.probes.startup.initial_delay_seconds

(integer)

.spec.deployment.probes.startup.period_seconds

(integer)

.spec.deployment.remote_cluster_resources_only

(boolean)

When true, only those resources necessary for a remote Kiali Server to access this cluster are created (such as the service account and roles/bindings). There will be no Kiali Server deployment/pod created when this is true.

.spec.deployment.replicas

(integer)

The replica count for the Kiail deployment. If deployment.hpa is specified, this setting is ignored.

.spec.deployment.resources

(object)

Defines compute resources that are to be given to the Kiali pod’s container. The value is a dict as defined by Kubernetes. See the Kubernetes documentation (https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container). If you set this to an empty dict ({}) then no resources will be defined in the Deployment. If you do not set this at all, the default is,

spec:
 deployment:
 resources:
 requests:
 cpu: "10m"
 memory: "64Mi"
 limits:
 memory: "1Gi"

(string)

Minimum TLS version (e.g., TLSv1.3, TLSv1.2).

.spec.deployment.tls_config.source

(string)

TLS policy source: ‘auto’ to use OpenShift TLSSecurityProfile; ‘config’ to use explicit settings.

.spec.deployment.tolerations

(array)

A list of tolerations which declare which node taints Kiali can tolerate. See the Kubernetes documentation on Taints and Tolerations for more details.

.spec.deployment.tolerations[*]

(object)

.spec.deployment.topology_spread_constraints

(array)

A list of constraints which control how the Kiali pods are spread across your cluster to help achieve high availability as well as efficient resource utilization. See the Kubernetes documentation on Topology Spread Constraints for more details.

.spec.deployment.topology_spread_constraints[*]

(object)

.spec.deployment.verbose_mode

(boolean)

DEPRECATED AFTER v1.73: When true, Kiali will log additional debug information about its operations.

.spec.deployment.version_label

(string)

Kiali resources will be assigned a ‘version’ label when they are deployed. This setting determines what value those ‘version’ labels will have. When empty, its default will be determined as follows,

If deployment.image_version is ‘latest’, version_label will be fixed to ‘master’.
If deployment.image_version is ‘lastrelease’, version_label will be fixed to the last Kiali release version string.
If deployment.image_version is anything else, version_label will be that value, too.

.spec.deployment.view_only_mode

(boolean)

When true, Kiali will be in ‘view only’ mode, allowing the user to view and retrieve management and monitoring data for the service mesh, but not allow the user to modify the service mesh.

.spec.extensions

(array)

Defines third-party extensions whose metrics can be integrated into the Kiali traffic graph.

.spec.extensions[*]

(object)

.spec.extensions[*].enabled

(boolean)

Determines if the Kiali traffic graph should incorporate the extension’s metrics.

.spec.extensions[*].name

(string)

The name that is used to identify the metric time series for the extension.

.spec.external_services

(object)

(array)

A list of scopes to request with the token.

(object)

Settings used to authenticate with the Grafana instance.

(object)

.spec.external_services.grafana.dashboards[*].name

(string)

The name of the Grafana dashboard.

(string)

Password to be used when making requests to Perses, for basic authentication. May refer to a secret using the pattern secret:<secretName>:<secretKey>. When using a secret, the password is cached and automatically refreshed when the secret changes, enabling rotation without pod restart.

.spec.external_services.perses.auth.type

(string)

The type of authentication to use when contacting the server. Use bearer to send the token to the Perses server. Use basic to connect with username and password credentials. Use oauth2 to use OAuth2 client_credentials flow. Use none to not use any authentication.

.spec.external_services.perses.auth.use_kiali_token

(boolean)

When true and if auth.type is bearer, Kiali Service Account token will be used for the API calls to Perses.

.spec.external_services.perses.auth.username

(string)

Username to be used when making requests to Perses with basic authentication. May refer to a secret using the pattern secret:<secretName>:<secretKey>. When using a secret, the username is cached and automatically refreshed when the secret changes, enabling rotation without pod restart.

.spec.external_services.perses.dashboards

(array)

A list of Perses dashboards that Kiali can link to.

.spec.external_services.perses.dashboards[*]

(object)

.spec.external_services.perses.dashboards[*].name

(string)

The name of the Perses dashboard.

(string)

.spec.external_services.prometheus.auth.cert_file

(string)

The client certificate file to use when accessing Prometheus using https with mTLS. An empty string means no client certificate is used. May refer to a secret.

.spec.external_services.prometheus.auth.insecure_skip_verify

(boolean)

Set true to skip verifying certificate validity when Kiali contacts Prometheus over https.

.spec.external_services.prometheus.auth.key_file

(string)

.spec.external_services.prometheus.auth.oauth2

(object)

Settings for OAuth2 client_credentials authentication. When auth.type is oauth2, these settings are used to obtain an access token.

.spec.external_services.prometheus.auth.oauth2.audience

(string)

The audience parameter sent with the token request. Some providers require this to scope the token.

.spec.external_services.prometheus.auth.oauth2.auth_style

(string)

(string)

.spec.external_services.prometheus.auth.token

(string)

.spec.external_services.prometheus.auth.type

(string)

.spec.external_services.prometheus.auth.use_kiali_token

(boolean)

When true and if auth.type is bearer, Kiali Service Account token will be used for the API calls to Prometheus (in this case, auth.token config is ignored).

(string)

Thanos Scrape interval value expressed as a string.

.spec.external_services.prometheus.url

(string)

.spec.external_services.tracing

(object)

Configuration used to access the Tracing (Jaeger or Tempo) dashboards.

.spec.external_services.tracing.auth

(object)

Settings used to authenticate with the Tracing server instance.

(string)

The maximum time allowed for a single health refresh cycle. If exceeded, the refresh is cancelled and the next cycle starts on schedule.

.spec.health_config.rate

(array)

.spec.health_config.rate[*]

(object)

.spec.health_config.rate[*].kind

(string)

The type of resource that this configuration applies to. This is a regular expression.

.spec.health_config.rate[*].name

(string)

The name of a resource that this configuration applies to. This is a regular expression.

.spec.health_config.rate[*].namespace

(string)

The name of the namespace that this configuration applies to. This is a regular expression.

.spec.health_config.rate[*].tolerance

(array)

A list of tolerances for this configuration.

.spec.kiali_feature_flags.clustering.clusters[*].name

(string)

DEPRECATED AFTER v1.73: The name of the cluster.

.spec.kiali_feature_flags.clustering.clusters[*].secret_name

(string)

DEPRECATED AFTER v1.73: The name of the secret that contains the credentials necessary to connect to the remote cluster.

.spec.kiali_feature_flags.clustering.enable_exec_provider

(boolean)

DEPRECATED AFTER v1.73: Flag to enable exec provider for clustering authentication.

.spec.kiali_feature_flags.clustering.kiali_urls

(array)

DEPRECATED AFTER v1.73: A map between cluster name, instance name and namespace to a Kiali URL.

(object)

.spec.kiali_feature_flags.custom_workload_types[*].group

(string) *Required*

The API group of the custom workload type (e.g., ‘argoproj.io’).

.spec.kiali_feature_flags.custom_workload_types[*].kind

(string) *Required*

The kind of the custom workload type (e.g., ‘Rollout’).

.spec.kiali_feature_flags.custom_workload_types[*].version

(string) *Required*

The API version of the custom workload type (e.g., ‘v1alpha1’).

.spec.kiali_feature_flags.disabled_features

(array)

There may be some features that admins do not want to be accessible to users (even in ‘view only’ mode). In this case, this setting allows you to disable one or more of those features entirely.

(array)

A list of commonly used and useful find expressions that will be provided to the user out-of-box.

.spec.kiali_feature_flags.ui_defaults.graph.find_options[*]

(object)

.spec.kiali_feature_flags.ui_defaults.graph.find_options[*].auto_select

(boolean)

If true this option will be selected and take effect automatically. Note that only one option in the list can have this value be set to true.

.spec.kiali_feature_flags.ui_defaults.graph.find_options[*].description

(string)

Human-readable text to let the user know what the expression does.

.spec.kiali_feature_flags.ui_defaults.graph.find_options[*].expression

(string)

The find expression.

.spec.kiali_feature_flags.ui_defaults.graph.hide_options

(array)

A list of commonly used and useful hide expressions that will be provided to the user out-of-box.

(object)

.spec.kiali_feature_flags.ui_defaults.mesh.find_options[*].auto_select

(boolean)

If true this option will be selected and take effect automatically. Note that only one option in the list can have this value be set to true.

.spec.kiali_feature_flags.ui_defaults.mesh.find_options[*].description

(string)

Human-readable text to let the user know what the expression does.

.spec.kiali_feature_flags.ui_defaults.mesh.find_options[*].expression

(string)

The find expression.

.spec.kiali_feature_flags.ui_defaults.mesh.hide_options

(array)

A list of commonly used and useful hide expressions that will be provided to the user out-of-box.

.spec.kiali_feature_flags.ui_defaults.mesh.hide_options[*]

(object)

.spec.kiali_feature_flags.ui_defaults.mesh.hide_options[*].auto_select

(boolean)

If true this option will be selected and take effect automatically. Note that only one option in the list can have this value be set to true.

.spec.kiali_feature_flags.ui_defaults.mesh.hide_options[*].description

(string)

Human-readable text to let the user know what the expression does.

.spec.kiali_feature_flags.ui_defaults.mesh.hide_options[*].expression

(string)

The hide expression.

.spec.kiali_feature_flags.ui_defaults.metrics_inbound

(object)

Additional label aggregation for inbound metric pages in detail pages. You will see these configurations in the ‘Metric Settings’ drop-down. An example,

spec:
 kiali_feature_flags:
 ui_defaults:
 metrics_inbound:
 aggregations:
 - display_name: Istio Network
 label: topology_istio_io_network
 - display_name: Istio Revision
 label: istio_io_rev

.spec.kiali_feature_flags.ui_defaults.metrics_inbound.aggregations

(array)

.spec.kiali_feature_flags.ui_defaults.metrics_inbound.aggregations[*]

(object)

.spec.kiali_feature_flags.ui_defaults.metrics_inbound.aggregations[*].display_name

(string)

.spec.kiali_feature_flags.ui_defaults.metrics_inbound.aggregations[*].label

(string)

.spec.kiali_feature_flags.ui_defaults.metrics_inbound.aggregations[*].single_selection

(boolean)

Flag to indicate if only one option can be selected for this aggregation.

.spec.kiali_feature_flags.ui_defaults.metrics_outbound

(object)

Additional label aggregation for outbound metric pages in detail pages. You will see these configurations in the ‘Metric Settings’ drop-down. An example,

spec:
 kiali_feature_flags:
 ui_defaults:
 metrics_outbound:
 aggregations:
 - display_name: Istio Network
 label: topology_istio_io_network
 - display_name: Istio Revision
 label: istio_io_rev

.spec.kiali_feature_flags.ui_defaults.metrics_outbound.aggregations

(array)

.spec.kiali_feature_flags.ui_defaults.metrics_outbound.aggregations[*]

(object)

.spec.kiali_feature_flags.ui_defaults.metrics_outbound.aggregations[*].display_name

(string)

.spec.kiali_feature_flags.ui_defaults.metrics_outbound.aggregations[*].label

(string)

.spec.kiali_feature_flags.ui_defaults.metrics_outbound.aggregations[*].single_selection

(boolean)

Flag to indicate if only one option can be selected for this aggregation.

.spec.kiali_feature_flags.ui_defaults.metrics_per_refresh

(string)

Duration of metrics to fetch on each refresh. Value must be one of: 1m, 2m, 5m, 10m, 30m, 1h, 3h, 6h, 12h, 1d, 7d, or 30d

.spec.kiali_feature_flags.ui_defaults.namespaces

(array)

Default selections for the namespace selection dropdown. Non-existent or inaccessible namespaces will be ignored. Omit or set to an empty array for no default namespaces.

(integer)

This Kiali cache is a list of namespaces per user. This is typically a short-lived cache compared with the duration of the namespace cache defined by the cache_duration setting. This is specified in seconds.

.spec.kubernetes_config.cluster_name

(string)

The name of the cluster Kiali is deployed in. This is also known as the home cluster. This is only used in multi cluster environments. This must be set when clustering.ignore_home_cluster=true. If not set, Kiali will try to auto detect the cluster name from the Istiod deployment or use the default ‘Kubernetes’.

.spec.kubernetes_config.excluded_workloads

(array)

List of controllers that won’t be used for Workload calculation. Kiali queries Deployment, ReplicaSet, ReplicationController, DeploymentConfig, StatefulSet, Job and CronJob controllers. Deployment and ReplicaSet will be always queried, but ReplicationController, DeploymentConfig, StatefulSet, Job and CronJobs can be skipped from Kiali workloads queries if they are present in this list.

.spec.kubernetes_config.excluded_workloads[*]

(string)

.spec.kubernetes_config.qps

(integer)

The QPS value of the Kubernetes client.

Namespace access control

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

In authentication strategies other than anonymous Kiali supports limiting the namespaces that are accessible on a per-user basis. The anonymous authentication strategy does not support this, although you can still limit privileges when using an OpenShift cluster. See the access control section in Anonymous strategy.

To authorize namespaces, the standard Roles resources (or ClusterRoles) and RoleBindings resources (or ClusterRoleBindings) are used.

The Kubernetes RBAC documentation describe how to use Roles, ClusterRoles, RoleBindings and ClusterRoleBindings resources. If you are using OpenShift, read the OpenShift RBAC documentation.

Namespace Management

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

The default Kiali installation gives Kiali access to all namespaces available in the cluster and will allow all namespaces to be visible.

It is possible to restrict Kiali so that it can only access a specific set of namespaces by providing discovery selectors that match those namespaces. Note that Kiali will not use Istio’s discovery selectors; if Istio has been configured with its own discovery selectors, you will likely want to configure Kiali with the same list of discovery selectors.

Networking

Mon, 01 Jan 0001 00:00:00 +0000

Destination

For more information see the Destination definition in the Istio Glossary.

Destination Rule

For more information see the Istio Destination Rule Documentation.

Endpoint

A communication endpoint is a type of communication network node. It is an interface exposed by a communicating party or by a communication channel.

Error Rate

It’s the percentage of errors in the traffic to a specific object for a Rate Interval.

Gateway

For more information see the Gateway definition in the Istio Gateway Documentation.

No Istiod Access

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

Kiali makes use of the Istiod /debug endpoints for introspection into the control plane. If this API is unavailable Kiali continues to perform, but the feature set will be degraded. The Istio API can be unavailable for various reasons:

The Istio API has been explicitly disabled in the Istio configuration.
The deployment model prevents access to the Istio API (firewalls, other networking concerns or limitations).
The API is configured but for some, potentially unexpected, reason can not be reached by Kiali.

Configuration

When the Istio API is known to be inaccessible Kiali should be configured via the istio_api_enabled configuration item.
By default, istio_api_enabled is true.

OSSMC

Mon, 01 Jan 0001 00:00:00 +0000

What OSSMC features work without Kiali installed?

When the OpenShift Service Mesh Console (OSSMC) plugin is installed but no Kiali server is connected to the plugin, the Service Mesh menu still provides Istios and Kialis pages. Those pages list every Istio and Kiali custom resource on the cluster so you can navigate multiple mesh instances from the OpenShift Console. They do not require a Kiali server.

Pages that require a connected Kiali server (Overview, Traffic Graph, Mesh, Namespaces, Applications, Services, Workloads, Istio Config) and Service Mesh tabs on OpenShift resource detail pages need a connected and reachable Kiali instance.

OSSMConsole CR Reference

Mon, 01 Jan 0001 00:00:00 +0000

Example CR

(all values shown here are the defaults unless otherwise noted)

apiVersion: kiali.io/v1alpha1
kind: OSSMConsole
metadata:
 name: ossmconsole
 annotations:
 ansible.sdk.operatorframework.io/verbosity: "1"
spec:
 version: "default"

 deployment:
 imageDigest: ""
 imageName: ""
 imagePullPolicy: "IfNotPresent"
 # default: image_pull_secrets is an empty list
 imagePullSecrets: ["image.pull.secret"]
 imageVersion: ""
 namespace: ""

 # default: internal is an empty object (techPreview is disabled)
 # internal:
 # techPreview: true

 kiali:
 autoDiscover: true
 serviceName: ""
 serviceNamespace: ""
 servicePort: 0

Validating your OSSMConsole CR

The OSSMConsole CR has a CRD Schema so it will be validated when you create or update it in your cluster.

Properties

.spec

(object)

This is the CRD for the resources called OSSMConsole CRs. The OpenShift Service Mesh Console Operator will watch for resources of this type and when it detects an OSSMConsole CR has been added, deleted, or modified, it will install, uninstall, and update the associated OSSM Console installation.

.spec.deployment

(object)

.spec.deployment.imageDigest

.status

(object)

The processing status of this CR as reported by the OpenShift Service Mesh Console Operator.

Performance and Scalability

Mon, 01 Jan 0001 00:00:00 +0000

What are some Tips for working with a large mesh?

It can be an observability challenge to work with a large mesh. Here are a few things that can be done to improve the situation.

Resources and Connectivity

Before talking about Kiali features, it is important to understand that Kiali’s performance is dependent on the performance and responsiveness of your metrics database (typically Prometheus), and your tracing store, for installations using tracing. For Prometheus scalability tips, see Tuning. See Tempo Tuning if using Tempo for your trace store.

Search Results

Mon, 01 Jan 0001 00:00:00 +0000

Security

Mon, 01 Jan 0001 00:00:00 +0000

Kiali gives support to better understand how mTLS is used in Istio meshes. Find those helpers in the Mesh page, Traffic Graph, Overview Page, and specific validations.

Mesh indicator

At the right panel of the Istio Control Plane from the Mesh page, Kiali shows a lock when the mesh has enabled mTLS for the whole service mesh. It means that all the communications in the mesh uses mTLS.

TLS Policy

Mon, 01 Jan 0001 00:00:00 +0000

Kiali uses one TLS policy for both its inbound server endpoint and every outbound client it creates—HTTP, gRPC, tracing exporters, and OpenID/OAuth HTTP flows. The policy controls TLS versions, cipher suites, and key exchange groups. It is configured in deployment.tls_config in the Kiali CR. You decide whether the policy comes from the cluster (OpenShift TLSSecurityProfile) or from explicit settings.

Configuration Options

Setting	Description
`source`	`auto` (OpenShift only: reads cluster TLSSecurityProfile) or `config` (use explicit settings)
`min_version`	Minimum TLS version: `TLSv1.2` or `TLSv1.3`
`max_version`	Maximum TLS version: `TLSv1.2` or `TLSv1.3`
`cipher_suites`	List of OpenSSL cipher names for TLS 1.2 (ignored for TLS 1.3)
`groups`	List of TLS group names (key exchange mechanisms) for both TLS 1.2 and 1.3

Platform Defaults

OpenShift: source defaults to auto (uses cluster’s TLSSecurityProfile)
Non-OpenShift: source defaults to config (requires explicit configuration)

On OpenShift, source: config is rejected by the Kiali Operator when the cluster TLS adherence is strict. See Cluster TLS Adherence.

Topology

Mon, 01 Jan 0001 00:00:00 +0000

Kiali offers multiple ways for users to examine their mesh Topology. Each combines several information types to help users quickly evaluate the health of their service architecture.

Overview

Kiali’s default landing page is the mesh Overview. It presents a high-level view of the mesh clusters, control planes, data planes, and configuration, for the user. It combines service and application information, along with telemetry, validations and health, to provide a holistic summary of the system behavior. It highlights potential issues that the user may need to investigate.

Tracing

Mon, 01 Jan 0001 00:00:00 +0000

Kiali offers a native integration with two different Distributed Tracing platforms, Jaeger and Grafana Tempo. As such, users can access trace visualizations. But more than that, Kiali incorporates tracing into several correlated views, making your investment in trace data even more valuable.

For a quick glimpse at Kiali tracing features, see below. For a detailed explanation of tracing in Kiali, see this 3-part Trace my mesh blog series. There is a detailed guide to configure access to the different distributed tracing platform, Jaeger and Grafana Tempo.

Traffic Health

Mon, 01 Jan 0001 00:00:00 +0000

There are times when Kiali’s default thresholds for traffic health do not work well for a particular situation. For example, at times 404 response codes are expected. Kiali has the ability to set powerful, fine-grained overrides for health configuration.

Default Configuration

By default Kiali uses the traffic rate configuration shown below. Application errors have minimal tolerance while client errors have a higher tolerance reflecting that some level of client errors is often normal (e.g. 404 Not Found):

Validation

Mon, 01 Jan 0001 00:00:00 +0000

Validations

Mon, 01 Jan 0001 00:00:00 +0000

Which formats does Kiali support for specifying hosts?

Istio highly recommends that you always use fully qualified domain names (FQDN) for hosts in DestinationRules. However, Istio does allow you to use other formats like short names (details or details.bookinfo). Kiali only supports FQDN and simple service names as host formats: for example details.bookinfo.svc.cluster.local or details. Validations using the details.bookinfo format might not be accurate.

In the following example it should show the validation of “More than one Destination Rule for the same host subset combination”. Because of the usage of the short name reviews.bookinfo Kiali won’t show the warning message on both destination rules.

Virtual Machine workloads

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

Kiali graph visualizes both Virtual Machine workloads (WorkloadEntry) and pod-based workloads, running inside a Kubernetes cluster. You must ensure that the Istio Proxy is running, and correctly configured, on the Virtual Machine. Also, Prometheus must be able to scrape the metrics endpoint of the Istio Proxy running on the VM. Kiali will then be able to read the traffic telemetry for the Virtual Machine workloads, and incorporate the VM workloads into the graph.