# Kiali: the Istio service mesh console, and what it takes to run it > Kiali is a management console for Istio service mesh, written in Go and licensed Apache-2.0. It ships as an Istio add-on or as a production component, and the README points developers at a build that needs Go, Node.js 20 or later, and Docker or Podman. **kiali/kiali** — Kiali project, observability for the Istio service mesh - Repository: https://github.com/kiali/kiali - Website: https://www.kiali.io - Stars: 3,641 · Forks: 568 - Language: Go - License: Apache-2.0 - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/kiali-kiali ## What Kiali is for, and who ends up running it Kiali describes itself in the README as "a management console for Istio service mesh." That sentence sets the boundary of the product. It is not a general Kubernetes dashboard and it is not a metrics store. It is a console that assumes an Istio-compatible service mesh is already installed on a Kubernetes cluster, and it exists so that the people operating that mesh can see what it is doing. The README states plainly that to use Kiali, an Istio-compatible service mesh is required, and that Istio meshes are installed on Kubernetes clusters. The audience splits in two. The README says its target audience is developers, and points non-developers at the Kiali documentation on kiali.io instead. That split matters when you are deciding whether to adopt it. If you are an operator who wants a running console, you are following the Installation page, not the README. If you are a developer who wants to change Kiali or run it against a local cluster, the README is your document, and it assumes you can build a Go backend and a Node frontend. The repository topics list is consistent with this: istio, management, observability, openshift, service-mesh. OpenShift appears there because Kiali has OpenShift-specific client libraries in its dependency list and a script for creating a local OpenShift cluster. ## How Kiali actually works: a Go backend reading your cluster The dependency list in go.mod tells you most of the architecture. The backend is a Go HTTP service built on gorilla/mux, with Prometheus client libraries for metric queries, OpenTelemetry for tracing its own requests, and the OpenShift client-go libraries for OpenShift-specific APIs. The repository layout confirms the shape: handlers/ for the HTTP surface, kubernetes/ and istio/ for cluster access, graph/ and mesh/ for the topology model, observability/ and perses/ for dashboards, and frontend/ for the UI. The frontend is a separate build. The README's developer setup lists Node.js 20 or later with NPM, and notes that Corepack manages the Yarn version, with the exact Yarn version pinned in frontend/package.json through the packageManager field. So a full build is two builds: make build-ui for the frontend, make build for the backend. The data flow in development is worth understanding because it explains the hot-reload workflow. The backend reads from your local kubeconfig file and connects to the cluster set as your current context by default. Kiali uses air, the live-reload tool, so the backend server restarts as you edit. The frontend dev server runs separately in another terminal. Nothing about this requires Kiali to be deployed into the cluster, which is why the README calls it the simplest way to get started developing on Kiali. ## Installing Kiali and running it against a local cluster The README does not give an end-user installation procedure. It says that for instructions on installing Kiali you should read the Installation page on kiali.io. What the README does give is the developer path: clone three repositories, link the operator into the main tree, and build both halves of the application. The checkout expects a specific directory tree, and the README notes that the rest of the document assumes it. The operator is symlinked into the kiali directory rather than cloned inside it. ```bash mkdir kiali_sources cd kiali_sources export KIALI_SOURCES=$(pwd) git clone https://github.com/kiali/kiali.git git clone https://github.com/kiali/kiali-operator.git git clone https://github.com/kiali/helm-charts.git ln -s $KIALI_SOURCES/kiali-operator kiali/operator ``` After that, build the frontend and then the backend. The README shows both steps, and notes that Go test flags can be passed through the GO_TEST_FLAGS environment variable. ```bash make build-ui cd $KIALI_SOURCES/kiali make build ``` For a first real run, the README's hot-reload path is the shortest one. The backend reads your local kubeconfig and connects to your current context, and air restarts it on changes. ```bash make build-ui make run-backend ``` Additional backend arguments go through KIALI_RUN_ARGS. The README gives a logging example and a multi-cluster example, and notes that the kube context name must match the Istio cluster name unless you supply a cluster name override. ```bash make KIALI_RUN_ARGS="--log-level debug" run-backend ``` If you would rather have a cluster created for you, the README lists unsupported helper scripts in hack/: run-integration-tests.sh starts a local cluster, installs Istio and Bookinfo, and starts Kiali; crc-openshift.sh creates a local OpenShift cluster; k8s-minikube.sh includes an option to install Dex for OpenID testing; start-kind.sh creates a single-node KinD cluster with MetalLB enabled. The README warns that the multi-cluster suites do not work with podman and require Docker Engine. You then set CLUSTER_TYPE to openshift (the default), minikube, kind, or local for other cluster types. ## The build constraints Kiali puts on you The tooling list in the README is not decorative. You need Go, git, gcc, Docker or Podman, Node.js 20 or later with NPM, and GNU make or a compatible alternative. If you use Podman instead of Docker, you set DORP=podman. That variable name is easy to miss and the build will not pick up Podman without it. The Go version is a moving target by design. The README says Kiali releases are built with a specified minimum version of Go, indicated in the Makefile, and that while Kiali may compile with other versions, using the version in the Makefile is recommended for consistent builds. The Makefile derives that number from go.mod, which currently declares go 1.26.3. If your toolchain is older, you will find out at build time rather than at clone time. The frontend has a similar trap. Corepack manages Yarn, and you enable it with corepack enable. The Yarn version is pinned in frontend/package.json through the packageManager field, so a globally installed Yarn of a different version is not what the project expects. Node.js below 20 is out. There is one more constraint that is easy to overlook: the README explicitly labels the helper scripts unsupported. They are convenience tooling, run in CI, and the README says there is a high chance they will work for you, but that is not a support commitment. ## Where Kiali is the wrong tool Kiali cannot be evaluated without Istio. The README states that an Istio-compatible service mesh is required and that Istio meshes are installed on Kubernetes clusters. If your workloads are plain Kubernetes services with no sidecar mesh, Kiali has nothing to draw. The graph, the mesh view, and the traffic health panels all depend on mesh telemetry that only exists once Istio is running. It is also not a metrics backend. Prometheus client libraries appear in the dependency list because Kiali queries metrics; it does not store them. If your question is a long-range time-series question about a metric that no one is scraping, Kiali is the wrong place to ask it. Development against the project has its own friction. The README assumes a three-repository directory tree, with the operator symlinked in. Multi-cluster testing requires Docker Engine specifically, since the README says the multi-cluster suites do not work with podman. And the Chat AI integration is called out as a developer preview, with the README warning that its APIs and configuration are still evolving and may change without notice. Treat that feature as unstable if you are planning around it. The README does not document rollback for the helper scripts or for a Kiali deployment. If you need a documented undo path before you start, the README will not give you one. ## Kiali against Jaeger and Grafana The comparison people reach for is Kiali versus Jaeger or Grafana, and the difference is in what each one is built to answer. Jaeger is a distributed tracing system: it stores and queries spans, so you go to it when you need the individual request path through a set of services. Grafana is a dashboarding layer over data sources, and Kiali itself ships grafana/ and perses/ directories, which tells you the project treats external dashboarding as something it integrates with rather than replaces. Kiali's own object is the mesh. Its repository is organized around graph/, mesh/, istio/ and kubernetes/, and its stated purpose is to be a management console for Istio. The question it answers is what the mesh looks like and whether it is healthy, not what a single trace did or how an arbitrary metric moved over ninety days. That means the three are complementary in a normal Istio deployment rather than substitutes. If you already run Jaeger for traces and Grafana for dashboards, Kiali does not remove either. What it adds is a mesh-level view that neither of them presents on its own. Choosing Kiali over Grafana is not really the decision; the decision is whether you want a mesh console in addition to your existing observability stack. ## Release cadence, licence and upgrade cost Kiali is licensed Apache-2.0, and the README carries the Apache 2.0 license badge linking to the LICENSE file. Apache-2.0 is a permissive licence with an explicit patent grant and a requirement to preserve notices; the practical implication for adopters is that you can run and redistribute it, but you should read the LICENSE file yourself rather than take a summary as legal advice. Nothing in the repository suggests a dual-licence or open-core split. On cadence, the release history shows a steady monthly rhythm: v2.30.0 on 2026-08-02, v2.31.0 on 2026-08-23, and v2.32.0 on 2026-09-13. The last push to the default branch was on 2026-09-23, and the Makefile identifies the in-development version as v2.33.0-SNAPSHOT. That is frequent enough that pinning a version and reading the release notes before each upgrade is the realistic posture, particularly if you depend on the AI integration, which the README marks as a developer preview whose APIs and configuration may change without notice. The upgrade cost is mostly in the split between the two artifacts. Kiali is built from this repository, but the operator lives in a separate repository, kiali-operator, and the charts live in helm-charts. The README's developer setup clones all three and symlinks the operator into the tree. If you deploy through the operator, your upgrade path touches the operator and the charts as well as the Kiali image, so a version bump is not a single-image change. The RELEASING.adoc and RELEASING.md files in the repository describe how releases are cut, which is the place to check before planning a jump across several minor versions. ## Conclusion Adopt Kiali if you already run Istio and want one console for mesh topology, configuration and traffic health, and if you are willing to run its backend against your kubeconfig or inside the cluster. Do not adopt it as a general Kubernetes dashboard, and do not expect it to work without an Istio-compatible mesh installed first. Before you commit, verify which Go version your build needs by reading the Makefile, confirm whether your cluster type is one of the supported CLUSTER_TYPE values, and check the Installation page on kiali.io for the release you intend to run. ## FAQ ### What is Kiali and what is it used for? Kiali is a management console for Istio service mesh, licensed Apache-2.0 and written in Go. The README says it can be installed quickly as an Istio add-on or integrated as a trusted component within a production environment, and that an Istio-compatible service mesh is required to use it. ### How do I install Kiali in Istio? The README does not give end-user installation steps and instead directs readers to the Installation page on kiali.io. What it does provide is the developer build: clone kiali, kiali-operator and helm-charts, symlink the operator into the kiali tree, then run make build-ui and make build. ### How do I access the Kiali dashboard? The README does not document dashboard access or login. For a local development run it shows make build-ui followed by make run-backend, after which the backend reads from your local kubeconfig and connects to the cluster set as your current context, with the frontend dev server started separately in another terminal. ### What is the Kiali operator? The operator is a separate repository, kiali-operator, that the README's developer setup clones alongside kiali and helm-charts and symlinks into the kiali tree as kiali/operator. The Makefile references an OPERATOR_DIR and separate operator container images, so the operator is built and released independently of the main Kiali image. ### What is Kiali Istio? Kiali is not a component of Istio; it is a separate project that manages and observes an Istio-based service mesh. The README states that Kiali can be installed as an Istio add-on or integrated as a trusted component in production, and that an Istio-compatible mesh on Kubernetes is a prerequisite. ### Does Kiali replace Jaeger or Grafana? No. Kiali is a mesh management console, while Jaeger stores and queries distributed traces and Grafana is a dashboarding layer over data sources. Kiali ships grafana/ and perses/ directories, which indicates it integrates with external dashboarding rather than replacing it. ## Sources - [kiali/kiali on GitHub](https://github.com/kiali/kiali) - [License: Apache-2.0](https://github.com/kiali/kiali/blob/master/LICENSE) - [Project website](https://www.kiali.io) - [README](https://github.com/kiali/kiali/blob/master/README.md) - [Releases](https://github.com/kiali/kiali/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kiali-kiali