Kiali Logo

FAQ

You’ve got questions? We’ve got answers!

General

How do I access Kiali UI?

This assumes that you have used the Getting started instructions to install Kiali.

If you are using OpenShift, installation exposes Kiali through a route. The following command should open Kiali in your default web browser:

xdg-open https://$(oc get routes -n istio-system kiali -o jsonpath='{.spec.host}')/console

If you are using Kubernetes, installation exposes Kiali through an Ingress rule. Find out your Ingress IP or domain name and use it to access Kiali by visiting this URL in your web browser: https://your_ingress_ip_or_domain/kiali.

To find your Ingress IP or domain name, as per the Kubernetes documentation, try the following command (doesn’t work if using Minikube):

kubectl get ingress kiali -n istio-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

If it doesn’t work, unfortunately, it depends on how and where you had setup your cluster. There are several Ingress controllers available and some cloud providers have their own controller or preferred exposure method. Please, check the documentation of your cloud provider. You may need to customize the pre-installed Ingress rule, or to expose Kiali using a different method.

If you are using Minikube and you have enabled the Ingress controller, the following command should open Kiali in your default web browser:

xdg-open https://$(minikube ip)/kiali

In any platform, you can use port-forwarding to access Kiali. Run any of these commands:

# If you have oc command line tool
oc port-forward svc/kiali 20001:20001 -n istio-system
# If you have kubectl command line tool
kubectl port-forward svc/kiali 20001:20001 -n istio-system

These commands will block. Access Kiali by visiting https://localhost:20001/ in your preferred web browser.

What is the License?

Kiali uses the Apache License 2.0.

How can I contribute?

Contributions are highly welcome. We look forward to community feedback, additions, and bug reports.

The code repositories are hosted on GitHub. Please see our Contribution Guidelines to learn how to contribute.

In general, we use the GitHub tracker for issues raised by the community, and JIRA for issues raised by the core engineering team. Both are publicly accessible.

Kiali does not work - What do i do?

If you are hitting a problem, whether it is listed here or not, do not hesitate to use the GitHub issue tracker. You can simply vote (using emojis) for any existing bug or feature request, this will help us to understand the most demanded enhancements, or you can create a new ticket. For existing JIRA tickets, use the vote link or add a comment describing your expectation or scenario.

Does Kiali support Internet Explorer?

No version of Internet Explorer is supported with Kiali. Users may experience some issues when using Kiali through this browser.

    In order to have the best experience with Kiali you will need to update to use a supported browser.

How can I get in touch?

  • Follow our twitter account.

  • Watch our videos using youtube.

  • Chat by joining our IRC channel in freenode.

  • Post in our users and developers groups at google groups.

  • Report a bug or request a new feature using github.

Graph

Why is the graph badly laid out?

If you search in the mailing list, you will find a number of discussions about the graph layouts.

The layout for Kiali Graph may render differently, depending on the data to display (number of graph nodes and their interactions) and it’s sometimes difficult, not to say impossible, to have a single layout that renders nicely in every situations. That’s why Kiali offers a choice of several layout algorithms. However, we may still find some scenarios where none of the proposed algorithm offer a satisfying display. If Kiali doesn’t not render your graph layout in a satisfactory manner please switch to another layout option. This can be done from the Graph Toolbar located on the bottom left of the graph.

If Kiali doesn’t produce a good graph for you, don’t hesitate to open an issue in GitHub or reach us in the mailing lists, and describe your situation.

Why are there many unknown nodes in the graph?

In some situations you can see a lot of connections from an "Unknown" node to your services in the graph, because some software external to your mesh might be periodically pinging or fetching data. This is typically the case when you setup Kubernetes liveness probes, or have some application metrics pushed or exposed to a monitoring system such as Prometheus. Perhaps you wouldn’t like to see these connections because they make the graph harder to read.

From the Graph page, you can filter them out by typing node = unknown in the Graph Hide input box.

Graph Hide
Figure 1. Hide the Unknown node

 

For a more definitive solution, there are several ways to prevent Istio from gathering this kind of telemetry.

The first is to have these endpoints (like /health or /metrics) exposed on a different port and server than your main application, and to not declare this port in your Pod's container definition as containerPort. This way, the requests will be completely ignored by the Istio proxy, as mentioned in Istio documentation (at the bottom of that page).

The second way is to modify Istio’s Prometheus rule to explicitly exclude some requests based on the User Agent. This is the Rule resource named promhttp located in istio-system. To edit it:

kubectl edit rule promhttp -n istio-system

or for OpenShift:

oc edit rule promhttp -n istio-system

Then locate the match field under spec section. Change it to filter out, for instance, the Kubernetes probes:

match: (context.protocol == "http" || context.protocol == "grpc") && (match((request.useragent | "-"), "kube-probe*") == false)

Note that, starting from Istio 1.1, Kubernetes probes will be filtered out in that way by default. But you may still want to do something equivalent with other User Agents.

Why do I have missing edges?

Kiali just shows the telemetry in Prometheus and if you don’t see what you expect it probably means that it has not been reported in Prometheus. Which means ususally that 1) the requests are not actually sent, 2) sidecars are missing, 3) requests are leaving the mesh and are not configured for telemetry

Kiali builds the graph from Istio’s telemetry. If you don’t see what you expect it probably means that it has not been reported in Prometheus. This usually means that:

1- The requests are not actually sent.

2- Sidecars are missing.

For example, If you don’t see traffic going from node A to node B, but you are sure there is traffic, the first thing you should be doing is checking the telemetry by querying the metrics, for example, if you know that MyWorkload-v1 is sending requests to ServiceA try looking for metrics of the type:

istio_requests_total{destination_service="ServiceA"}

If telemetry is missing then it may be better to take it up with Istio

Why can't I see traffic leaving the mesh?

See Why do I have missing edges?, and additionally consider:

3- Requests are not configured for telemetry.

You need to create a ServiceEntry (or several) to allow the requests to be mapped correctly.

There are a couple of bugs related to this, one incorrectly maps traffic to other ServiceEntry while the other is about not seeing a ServiceEntry even if is configured correctly.

You can check this article on how to visualize your external traffic in Kiali for more information.

Why my external HTTPS traffic is showing as TCP?

Istio can’t recognize HTTPS request that go directly to the service, the reason is that these requests are encrypted and are recognized as TCP traffic.

You can however configure your mesh to use TLS origination for your egress traffic. This will allow to see your traffic as HTTP instead of TCP.

Why does my workload graph show service nodes?

Even when Display Service Nodes is disabled a workload graph can show service nodes. Display Service Nodes ensures that you will see the service nodes between two other nodes, providing an edge to the destination service node, and a subsequent edge to the node handling the request. This option injects service nodes where they previously would not be shown. But Kiali will always show a terminal service node when the request itself fails to be routed to a destination workload. This ensures the graph visualizes problem areas. This can happen in a workload or app graph. Of course in a service graph the Display Service Nodes option is simply ignored.

Why do I see traffic to PassthroughCluster?

Requests going to PassthroughCluster (or BlackHoleCluster) are requests that did not get routed to a defined service or service entry, and instead end up at one of these built-in Istio request handlers. See Monitoring Blocked and Passthrough External Service Traffic for more information.

Unexpected routing to these nodes does not indicate a Kiali problem, you’re seeing the actual routing being performed by Istio. In general it is due to a misconfiguration and/or missing Istio sidecar. Less often but possible is an actual issue with the mesh, like a sync issue or evicted pod.

Use Kiali’s Workloads list view to ensure sidecars are not missing. Use Kiali’s Istio Config list view to look for any config validation errors.

Distributed Tracing

I can't see the tracing features embedded, new tab open when browsing traces

The Distributed Tracing item in the main menu opens a new tab when Kiali and Jaeger services are deployed under the same URI scheme (HTTP/HTTPS). In order to enable the integration, make both services run either under HTTP or HTTPS. To see which is the tracing URL Kiali uses, check the about modal like the FAQ 2.

I can’t see the link to Tracing or traces tab in service details

To see Jaeger integration (both link to browse traces and traces tabs in service details) Kiali needs to know the URL where Jaeger is running under. In order for Kiali users to know which URL Kiali users, check the About menu, as it follows:

About menu
About modal

I have no Tracing URL in the about modal

So Kiali didn’t find the tracing service. Kiali tries to search for the tracing service in tracing or jaeger-query. If you have another name for this service you must set the values in the yaml configuration for Kiali Operator

# **Tracing-specific settings:
#  - Right now we only support Jaeger
# namespace: The Kubernetes namespace that holds the Tracing service (if empty, assumes the same value as deployment.namespace)
# service: The Kubernetes service name for tracing. Kiali uses this to connect within the cluster to Jaeger.
# url: The URL that Kiali uses when integrating with Tracing. This URL must be accessible to clients external to
#      the cluster in order for the integration to work properly. If empty, an attempt to auto-discover it is made.
#    ---
#    tracing:
#      namespace: ""
#      service : ""
#      url: ""

I see an error message in embedded feature "might be temporarily down ..."

If you are working in a development environment, you can see an error as the image below.

Certificate Error

This is because your certificate is not valid, so you need to accept the certificate, open the tracing service in a new tab and accept it, after that you need to refresh the Kiali website.

I see the following informative message: "Could not fetch Jaeger info. Turning off Jaeger integration"

Jaeger Integration Disabled

Although Kiali discovered the Jaeger URL the signed up user doesn’t have access to the Jaeger query endpoint. Accessing to the discovered URL (shown in the "About" modal) shouldn’t be working. Once the endpoint will be accessible by the signed up user, the Jaeger integration will be enabled in Kiali.

I see the following informative message: "certificate signed by unknown authority"

Unstrusted certificate

In order to Kiali enable Jaeger integration, Kiali needs to check the availability of the discovered URL. If that URL uses TLS and the certificate is signed by an untrusted authority, then Kiali can’t establish connection with it for security purposes. However there is a workaround for that. Kiali can be configured to skip the authority verification through the flag: insecure_skip_verify. Change its value to true in the Kiali CR.

Validations

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.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews-dr1
  namespace: bookinfo
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews-dr2
  namespace: bookinfo
spec:
  host: reviews.bookinfo
  trafficPolicy:
    loadBalancer:
      simple: RANDOM
  subsets:
  - name: v1
    labels:
      version: v1

See the recomendation Istio gives regarding host format: "To avoid potential misconfigurations, it is recommended to always use fully qualified domain names over short names."

For best results with Kiali, you should use fully qualified domain names when specifying hosts.