Istio Environment
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.
Monitoring port of the IstioD pod
Kiali connects directly to the IstioD pod (not the Service) to check for its health. By default, the connection is done to port 15014 which is the default monitoring port of the IstioD pod.
Under some circumstances, you may need to change the monitoring port of the IstioD pod to something else. For example, when running IstioD in host network mode the network is shared between several pods, requiring to change listening ports of some pods to prevent conflicts.
It is possible to map the newly chosen monitoring port of the IstioD pod in the related Service to let other services continue working normally. However, since Kiali connects directly to the IstioD pod, you need to configure the assigned monitoring port in the Kiali CR:
spec:
external_services:
istio:
istiod_pod_monitoring_port: 15014
Root namespace
Istio’s root namespace is the namespace where you can create some resources to define default Istio configurations and adapt Istio behavior to your environment. For more information on this Istio configuration, check the Istio docs Global Mesh options page and search for “rootNamespace”.
Kiali uses the root namespace for some of the validations of Istio resources. If you customized the Istio root namespace, you will need to replicate that configuration in Kiali. By default, it is unset:
spec:
external_services:
istio:
root_namespace: ""
Sidecar injection, canary upgrade management and Istio revisions
Kiali can assist into configuring automatic sidecar injection, and also can assist when you are migrating workloads from an old Istio version to a newer one using the canary upgrade method. Kiali uses the standard Istio labels to control sidecar injection policy and canary upgrades.
Management of sidecar injection is enabled by default. If you don’t want this feature, you can disable it with the following configuration:
spec:
kiali_feature_flags:
istio_injection_action: false
Assistance for migrating workloads between Istio revisions when doing a canary upgrade is turned off by default. This is because it is required to know what is the revision name that was used when installing each Istio control plane. You can enable and configure the canary upgrade support with the following configuration:
spec:
external_services:
istio:
istio_canary_revision:
# Revision string of old Istio version
current: "1-10-3"
# Revision string of new Istio version
upgrade: "1-11-0"
kiali_feature_flags:
# Turns on canary upgrade support
istio_upgrade_action: true
It is important to note that canary upgrades require adding a revision name
during the installation of control planes. You will notice that the revision
name will be appended to the name of Istio resources. Thus, once/if you are
using Kiali with an Istio control plane that has a revision name you will need
to specify what is the name of a few Istio resources that Kiali uses. For
example, if your control plane has a revision name 1-11-0 you would need to
set these configurations:
spec:
external_services:
istio:
config_map_name: "istio-1-11-0"
istio_sidecar_injector_config_map_name: "istio-sidecar-injector-1-11-0"
istiod_deployment_name: "istiod-1-11-0"
There following are links to sections of Kiali blogs posts that briefly explains these features: