-
Notifications
You must be signed in to change notification settings - Fork 476
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
Kiali working with no Istiod access #5642
Conversation
Great! If you want some reviews, ping me after this is ready! @josunect |
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.
Thanks for picking up this investigation!
kubernetes/istio.go
Outdated
func (in *K8SClient) HasIstioAccess() bool { | ||
componentStatus, err := in.CanConnectToIstiod() | ||
if err != nil { | ||
return false | ||
} | ||
if len(componentStatus) == 0 { | ||
return false | ||
} | ||
return true | ||
} |
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 think this would be better as a config option for the registry where you can enable/disable the registry altogether if you'd like rather than having it just be a fallback option: https://github.com/kiali/kiali/blob/master/config/config.go#L208.
@hhovsepy may be looking into this but you should be able to get the istio config from the kube api rather than the registry when there's no istiod access.
What will be the impact on the controlplane namespace card once there is no direct istiod access? It might still be possible to get some details, like controlplane revision, about the controlplane from the injection webhook since this may be present in the cluster even if the controlplane is 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.
Funny, I was just looking at the same thing. I also think it makes sense to configure Kiali for this scenario. By default Kiali would expect to be able to connect to istiod's debug endpoint and proceed normally. If it can't connect then that would be a FAILURE scenario for the control plane card. If configured to ignore istiod then it would be a DEGRADED scenario for the control plane card (even if it is accessible we won't connect, this could be for performance reasons, or whatever).
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.
draft solution of retrieving configs when istiod is not available #5649
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.
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.
Thanks, @jshaughn and @nrfox for the review! I'll approach the changes and submit. I've though in do it this way as it can be more robust in the sense that it can work even if Istiod is or is not available, but it is true that it is not possible to know the reason, can be intentional or not - a failure. So it make sense to do it more explicit as part of the configuration. |
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 have reviewed the backend codes, did not find any issues. LGTM. Wait for other reviews in front part :)
Thank you, @Xunzhuo ! |
Is it supposed, that the case when 'istiod' is not running/accessible and the config "istio_api_enabled: true" will be handled? Because it throws "open /var/run/secrets/kubernetes.io/serviceaccount/token: no such file or directory" error message while selecting "istiod" workload. |
In that case, it won't be handled - That should be the default behavior. But, I will reproduce it. |
@hhovsepy What is your That error message says it wants permission to list pods AT THE CLUSTER SCOPE. Which means it expects (for some reason) a ClusterRole. The Kiali SA only gets bound to a ClusterRole when accessible_namespaces is set to We never before required ClusterRole access to look at pods. So this error message seems strange. We should avoid this requirement if possible. |
When setting accessible_namespaces: [ "**" ], Kiali pod fails to get ready, but this is not PR related: |
…aryMasthead.tsx Co-authored-by: Nick Fox <nick@nrfox.com>
…ConfigOverview.tsx Co-authored-by: Nick Fox <nick@nrfox.com>
It will need to test further after the merge. I see some errors like:
|
Co-authored-by: Nick Fox <nick@nrfox.com>
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
Proposal as a first version to have Kiali running with no Istiod.
Details in: https://docs.google.com/document/d/1XjkodS5Uu14C_1l3-j7iNaWfLufQFycY-cKMlagIxyc
Changes:
Some tests to review performance: Frontend tests were showing a degraded performance so a new commit was sent to internally cache the istioAccess value
Fixes #5626