• Introduction
  • Table of contents
  • Description
  • Contributing
  • Getting Started
  • How and where Kiali is released?
• Developer setup
  • Create a Kubernetes cluster and install a Service Mesh
  • Building the Container Image and deploying to a cluster
  • Reloading Kiali image
  • Cluster clean-up
  • Code formatting and linting
  • Running Standalone
• Configuration
• Embedding Kiali
• Configure External Services
  • Grafana
• Additional Notes
  • Running the UI outside the cluster
  • Disabling SSL
• Exposing Kiali to External Clients Using Istio Gateway
• Experimental
  • Observing a Remote Cluster

A Microservice Architecture breaks up the monolith into many smaller pieces that are composed together. Patterns to secure the communication between services like fault tolerance (via timeout, retry, circuit breaking, etc.) have come up as well as distributed tracing to be able to see where calls are going.

A service mesh can now provide these services on a platform level and frees the application writers from those tasks. Routing decisions are done at the mesh level.

Kiali works with Istio to visualise the service mesh topology, and features like circuit breakers or request rates.

Kiali also includes an integration with Jaeger Tracing to augment the topology views with distributed transaction monitoring, and to also provide charts and stats about distributed traces.

First, check the Community section on kiali.io, which provides a brief introduction on contributing, how to report issues and request features, and how to reach us.

If you would like to make code contributions, please also check the Contribution Guide.

The target audience of this README are developers. If you are not a developer but want to learn more about Kiali, the Kiali documentation should be more helpful. For instructions on installing Kiali, please read the Installation page.

Read the RELEASING.adoc file.

-- kiali_sources
   |- kiali
   |- kiali-ui
   |- kiali-operator
   \- helm-charts

Since Kiali is a management console for an Istio-based service mesh, you will need an Istio-like Service Mesh to try Kiali. Then, Istio Meshes are installed on Kubernetes clusters.

We provide a few unsupported scripts that can help to get started:

• You can use the crc-openshift.sh script to create an OpenShift cluster on your local machine.

• If you are familiar to minikube, you may try the k8s-minikube.sh script. It has the option to install Dex which is useful if you want to test with OpenID.

• Finally, the install-istio-via-istioctl.sh and the install-bookinfo-demo.sh scripts can assist into installing Istio and the Bookinfo sample application in your cluster, respectively. You can try running these scripts without any arguments.

These scripts are written to rely on the minimum dependencies as possible and will try to download any required tools.

You can also use kind, however we don’t have a script to create a kind cluster.

Depending on the type of cluster you are using, you should define the CLUSTER_TYPE environment variable on your shell to openshift (this is the default if not set), minikube or kind value so that the Makefiles can assist in other operations. If you are not using any of these clusters, you should set the environment variable to CLUSTER_TYPE=local.

Assuming that:

• you have successfully built the back-end and the front-end,

• you also have created a Kubernetes cluster with an Istio-based Service Mesh installed on it,

• and you are not using the CLUSTER_TYPE=local environment variable

the following commands should deploy a development build of Kiali to the cluster:

If you are using the CLUSTER_TYPE=local environment variable, you will need to declare some additional environment variables to set the container registry where container images should be pushed and use make container-push* targets instead of cluster-push* targets. For example, if your container registry is localhost:5000:

If you already have Kiali installed and you want to recreate the kiali server pod, you can run the following command:

This is to facilitate development. To quickly build a new Kiali container image and load it to the cluster, you can run:

If you are changing the back-end code of Kiali, before submitting a pull request make sure your changes are properly formatted and no new linting issues are introduced by running:

You may want to run Kiali outside of any cluster environment for debugging purposes. To do this, you will want to use the run-kiali.sh hack script located in the hack directory. See the --help output for the options you can set. The default configuration it uses is found in the config template file also located in the hack directory. Read the comments at the tops of both files for more details.

Debugging With VisualStudio Code

{
    // To use this, first run "hack/run-kiali.sh --tmp-root-dir $HOME/tmp --enable-server false"
    // Pass in --help to that hack script for details on more options.
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch Kiali to use hack script services",
            "type": "go",
            "request": "launch",
            "mode": "debug",
            "program": "${workspaceRoot}/kiali.go",
            "cwd": "${env:HOME}/tmp/run-kiali",
            "args": ["-config", "${env:HOME}/tmp/run-kiali/run-kiali-config.yaml"],
            "env": {
                "KUBERNETES_SERVICE_HOST": "127.0.0.1",
                "KUBERNETES_SERVICE_PORT": "8001",
                "LOG_LEVEL": "trace"
            }
        }
    ]
}

If you have Grafana installed in a custom way that is not easily auto-detectable by Kiali, you need to change in the Kiali CR the value of the grafana > url

When developing the Kiali UI you will find it useful to run it outside of the cluster to make it easier to update the UI code and see the changes without having to re-deploy. The preferred approach for this is to use the proxy feature of React. The process is described here.

In the provided OpenShift templates, SSL is turned on by default. If you want to turn it off, you should:

• Remove the "tls: termination: reencrypt" option from the Kiali route

• Remove the "identity" block, with certificate paths, from the Kiali Config Map.

• Optionally you can also remove the annotation "service.beta.openshift.io/serving-cert-secret-name" in the Kiali Service, and the related kiali-cabundle volume that is declared and mounted in Kiali Deployment (but if you don’t, they will just be ignored).

There are certain use cases where Kiali needs to be deployed in one cluster (Control Plane) and observe a different cluster (Data Plane). Diagram.

Follow these steps:

1: You should have the remote central istiod with a single cluster setup running

2: Create the Kiali ClusterRole, ClusterRoleBinding, and ServiceAccount in the Data Plane cluster

3: Create a remote secret in the Control Plane, using the Data Plane ServiceAccount you just created. This allows the Control Plane to read from and modify the Data Plane

4: You will now run Kiali in the Control Plane. You need to add the remote secret to the Kiali Deployment by specifying a Volume and VolumeMount. When Kiali sees /kiali-remote-secret/kiali it will use the remote cluster’s API server instead of the local API server

5: Kiali now needs the Istio metrics from the sidecars. You need to run Prometheus in the Control Plane and have it scrape the metrics from an envoyMetricsService. These metrics are required:

• istio_requests_total

• istio_request_duration_milliseconds

• istio_response_bytes

• istio_request_bytes

6: Kiali in the Control Plane should now be fully functional with the Data Plane