-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs for the new discovery selector feature #807
Conversation
e95b42c
to
6f366bb
Compare
In I'm referring to this: |
24d3513
to
62edc20
Compare
4bd141b
to
9502d9e
Compare
9502d9e
to
8e2d0bb
Compare
we can ignore the validate error. that link (https://istio.io/v1.10/docs/setup/additional-setup/cni/#identifying-pods-requiring-traffic-redirection) really exists, dunno why the validator is getting a timeout. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I got to line 82 but I have to step out, here are some initial comments. I'll finish later...
It is possible to restrict Kiali so that it can only access a specific set of namespaces by providing [discovery selectors](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#resources-that-support-set-based-requirements) that match those namespaces. Note that Kiali will not use [Istio's discovery selectors](https://istio.io/latest/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig); if Istio has been configured with its own discovery selectors, you will likely want to configure Kiali with the same list of discovery selectors. | ||
|
||
{{% alert color="info" %}} | ||
This documentation makes a distinction between a namespace that is _accessible_ verses _visible_. Kiali can be given access to all namespaces in the cluster, or it can be given restricted permissions so that only certain namespaces are accessible to it. Of the accessible namespaces that Kiali is permitted to see, it can make some or all of them visible to end users. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This documentation makes a distinction between a namespace that is _accessible_ verses _visible_. Kiali can be given access to all namespaces in the cluster, or it can be given restricted permissions so that only certain namespaces are accessible to it. Of the accessible namespaces that Kiali is permitted to see, it can make some or all of them visible to end users. | |
This documentation makes a distinction between an _accessible_ and _visible_ namespace. Kiali can be given access to all namespaces in the cluster, or it can be given restricted permissions so that only certain namespaces are accessible to it. Of the accessible namespaces that Kiali is permitted to see, it can make some or all of them visible to end users. |
I fixed the grammatical error, "verses" is like verses of the Bible. I think you wanted "versus", but even that's not quite right. But more than that, I don't totally understand this blurb. It would be better if you describe exactly the difference between an accessible namespace and a visible namespace. Even I don't know what you're saying here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Meaning, what exactly does it mean for Kiali to have access? What level of access, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This documentation makes a distinction between an _accessible_ and a _visible_ namespace. The Kiali Server will be given permission to see either (a) all namespaces in the cluster, or (b) only certain namespaces in the cluster. These are the "accessible namespaces." This means the Kiali Server will be able to query for and access resources within those accessible namespaces, but be forbidden from seeing all the other namespaces and their resources. Of these accessible namespaces that Kiali is permitted to see, it can make some or all of them visible to end users such that the end users will be able to see those namespaces and their resources in the Kiali UI.
This is important because its the distinction between "cluster_wide_access" values of "true" and "false" which the documentation will later talk about. e.g. when you have CWA=true, the Kiali Server itself can access all namespaces in the cluster (they are "accessible") but you could still set discovery selectors to limit the visibility to only some namespaces to end users. But I didn't want to get into the details here because its all described later in the docs - but I did want to point out the distinction between "accessible" and "visible" because its important later.
Why do we do this? It's the whole cluster-scoped versus namespace-scoped caches (have a cluster-scoped cache for efficiency, have namespace-scoped caches for higher security with the downside of having many more k8s informers/watchers in the server).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, how about this:
This documentation makes a distinction between accessible and visible namespaces. The Kiali Server will be given permission to access either (a) all, or (b) a configured subset, of cluster namespaces. The Kiali Server will only be aware of, query for, and access resources within these accessible namespaces. The set of namespaces visible to an end user, via the Kiali UI, will be a subset of the accessible namespaces. In other words, the namespaces visible to a user may be all, or just some of the namespaces accessible to the Kiali Server..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see latest commit
example, if Kiali is to be installed in the `istio-system` namespace, and is | ||
expected to monitor all namespaces prefixed with `mycorp_`, the setting would | ||
be: | ||
The list of accessible namespaces is specified in the Kiali CR via the `deployment.discovery_selectors.default` setting. As an example, if Kiali is to be installed in the `istio-system` namespace, and is expected to monitor all namespaces with the label "my-mesh", the setting would be: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does Kiali's install namespace need to be labeled?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no, because later the docs say (line 57):
The Kiali Operator will always give the Kiali Server access to the namespace where the Kiali Server is installed and to the Istio control plane namespace (which may be the same namespace), whether those namespaces match a discovery selector or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's good, a few minor changes. I hope this approach is actually better than what we do currently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
part of: kiali/kiali#7546
part of KEP: https://github.com/kiali/kiali/blob/master/design/KEPS/namespace-discovery/proposal.md
server PR: kiali/kiali#7592
operator PR: kiali/kiali-operator#797
helm chart PR: kiali/helm-charts#274
docs PR: #807
Netlify links: