There are other, more complex deployment settings, described in dedicated pages:
- Customization of the Ingress resource
- Customization of the service type (LoadBalancer or NodePort)
- Namespace management (configuring namespaces accessible and visible to Kiali)
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:
spec: deployment: namespace: "custom-kiali-nameespace"
It is assumed that Kiali is installed to the same namespace as Istio. Kiali reads some Istio resources and may not work properly if those resources are not found. Thus, if you are installing Kiali and Istio on different namespaces, you must specify what is the Istio namespace:
spec: istio_namespace: "istio-system"
Log level and format
By default, Kiali will print up to
INFO-level messages in simple text format.
You can change the log level, output format, and time format as in the
spec: deployment: logger: # Supported values are "trace", "debug", "info", "warn", "error" and "fatal" log_level: error # Supported values are "text" and "json". log_format: json time_field_format: "2006-01-02T15:04:05Z07:00"
The syntax for the
time_field_format is the same as the
function of the Go language.
json format is useful if you are parsing logs of your applications for
Kiali instance name
If you plan to install more than one Kiali instance on the same cluster, you may need to configure an instance name to avoid conflicts on created resources:
spec: deployment: instance_name: "secondary"
instance_name will be used as a prefix for all created Kiali resources.
The exception is the
kiali-signing-key secret which will always have the same name
and will be shared on all deployments of the same namespace, unless you specify
a custom secret name.
instance_namewill be used as a name prefix in resources, it must follow Kubernetes naming constraints.
instance_nameof an existing Kiali installation. The workaround is to uninstall Kiali and re-install with the desired
Resource requests and limits
You can set the amount of resources available to Kiali using the
spec.deployment.resources attribute, like in the following example:
spec: deployment: resources: requests: memory: "128Mi" cpu: "100m" limits: memory: "1Gi" cpu: "500m"
Please, read the Managing Resources for Containers section in the Kubernetes documentation for more details about possible configurations.
Custom labels and annotations on the Kiali pod and service
Although some labels and annotations are set on the Kiali pod and on its
service (depending on configurations), you can add additional ones. For the
pod, use the
attributes. For the service, you can only add annotations using the
spec.deployment.service_annotations attribute. For example:
spec: deployment: pod_annotations: a8r.io/repository: "https://github.com/kiali/kiali" pod_labels: sidecar.istio.io/inject: "true" service_annotations: a8r.io/documentation: "https://kiali.io/docs/installation/deployment-configuration"
Kiali page title (browser title bar)
If you have several Kiali installations and you are using them at the same time, there are good chances that you will want to identify each Kiali by simply looking at the browser’s title bar. You can set a custom text in the title bar with the following configuration:
spec: installation_tag: "Kiali West"
installation_tag is any human readable text of your desire.
Kubernetes scheduler settings
Replicas and automatic scaling
By default, only one replica of Kiali is deployed. If needed, you can change the replica count like in the following example:
spec: deployment: replicas: 2
If you prefer automatic scaling, creation of an
resource is supported. For example, the following configuration automatically
scales Kiali based on CPU utilization:
spec: deployment: hpa: api_version: "autoscaling/v1" spec: minReplicas: 1 maxReplicas: 2 targetCPUUtilizationPercentage: 80
scaleTargetReffield of the HPA spec, because this field will be populated by the Kiali operator (or by Helm) depending on other configuration.
Read the Kubernetes Horizontal Pod Autoscaler documentation to learn more about the HPA.
Allocating the Kiali pod to specific nodes of the cluster
You can constrain the Kiali pod to run on a specific set of nodes by using some of the standard Kubernetes scheduler configurations.
The simplest option is to use the
configuration which you can configure like in the following example:
spec: deployment: node_selector: worker-type: infra
You can also use the affinity/anti-affinity native Kubernetes feature if you prefer its more expressive syntax, or if you need more complex matching rules. The following is an example for configuring node affinity:
spec: deployment: affinity: node: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: worker-type operator: In values: - infra
Similarly, you can also configure pod affinity and pod anti-affinity using the
Finally, if you want to run Kiali in a node with taints, the following is an example to configure tolerations:
spec: deployment: tolerations: # Allow to run Kiali in a tainted master node - key: "node-role.kubernetes.io/master" operator: "Exists" effect: "NoSchedule"
Read the following Kubernetes documentation to learn more about these configurations:
Priority class of the Kiali pod
If you are using priority classes in your cluster, you can specify the priority class that will be set on the Kiali pod. For example:
spec: deployment: priority_class_name: high-priority
For more information about priority classes, read Pod Priority and Preemption in the Kubernetes documentation.
Adding host aliases to the Kiali pod
If you need to provide some static hostname resolution in the Kiali pod, you
can use HostAliases to add entries to the
of the Kiali pod, like in the following example:
spec: deployment: host_aliases: - ip: 192.168.1.100 hostnames: - "foo.local" - "bar.local"