Installing Kiali In Anonymous and View-Only Mode Using Istioctl

So @jmazzitelli I think I see what you are saying now. What I have configured is for the kaili pod. Are you saying that it is not possible to set affinity for the kiali-operator pod?

Correct. You could pull the operator yaml down to your local machine and modify them as you see fit (if you run the script in a directory that also includes the yaml files in that directory, the script will use those yaml files). see:

So is this something that can be added or PR for a future release? I tried your suggestion, and that works, but now would be in a situation where would have to manage those files. Also, the affinity configuration is still not working for the kiali pod. Can you confirm if my kiali_cr is correct for infinity:

kind: Kiali
  name: kiali
  namespace: kiali-operator
    strategy: anonymous
          - matchExpressions:
            - key:
              operator: In
              - operations-job-nodes
    - effect: NoExecute
      operator: Equal
      value: operations-server

You can submit an enhancement request here:

As for your Kiali CR - those appear correct (at least the syntax looks OK). Take a look at the Kiali Deployment and see if those translated over there. They should make it due to this in the templates (I assume you are not running on OpenShift, if you are there is an analogous template for OpenShift):

So do a kubectl get deployment kiali -n istio-system -o yaml and look in there (if you did not deploy kiali in the istio-system namespace, pass in your own namespace with the -n option).

This stuff should be working as we have molecule tests that test it (it at least makes sure the affinity config is passed correctly to the deployment):

Doesn’t look like it is working. I ran the the kubectl get deployment kiali -n istio-system -o yaml command and not seeing any affinity or tolerations under the deployment. Here is a snippet of that output.

  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
      app: kiali
      version: v1.15.0
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
      annotations: go,kiali "9090" "true"
      creationTimestamp: null
        app: kiali
        version: v1.15.0
      name: kiali
      - command:
        - /opt/kiali/kiali

I looked at the molecule test. Is it possible affinity doesn’t work with
requiredDuringSchedulingIgnoredDuringExecution. Looking at the test it seems it is dealing mostly with preferredDuringSchedulingIgnoredDuringExecution

It should work - it blindly copies your config over.
Did you specify “version: default” explicitly in your Kiali CR? Seems like maybe the operator is running the v1.0 playbook which IIRC didn’t support this feature

Didn’t specify a “version” in the Kiali CR. Looking at the Kiali CR settings, it should use the default version of playbook if none is specified correct?

# The currently allowed values for this setting are:
#   "default", "v1.0", "v1.12"
# Refer to this file to see where these values are defined in the master branch:
# See the Kiali documentation to determine which of these versions support
# the version of Istio you are installing Kiali with.
#  ---
#  version: "default"

Are you saying this should work with default playbook or should I be using v1.12 of the playbook? Looking further, is default actually v1.0 of the playbook?

You will want to explicitly specify “version: default” under “spec” of the Kiali CR. Do not leave it unspecified. If you do not specify it, the default value is “version: v1.0” which is not what you want. We had to change this default value to “v1.0” due to some backwards compatibility issues with some particular use-cases. So you want to explicitly set “version: default” like:

  version: "default"
  ...and the rest...

It’s late and I’m not thinking straight :slight_smile: I thought the default for this setting is “v1.0” but I’m staring at the code and it seems it is “version: default”. Maybe I’m not looking at the right place.

In any event, explicitly add “version: default” like I said in my last post and see what happens.

OK, I’m not going crazy. Here it is:

I think we need to go back to the drawing board and figure out how to solve the use-case (the one that caused us to set this default to “v1.0”) so we can fall back to using “default” as the default value if it is not specified. Too many people are getting bit by this.

Anyway, for now, specify “version: default” and I believe all will work.

That worked! Thanks so much for your help!!!