kubel
kubel copied to clipboard
kubel--can-get-namespace: Avoid spurious warning
Hello and thank you for your work!
The resolution of issue #38 did not help me as a new user - being a K8S newbie and having just installed minikube
/kubectl
v1.19.4
and kubel
, I couldn't understand why no namespaces were listed, as kubel-use-namespace-list
was set to auto
and kubectl --context minikube auth can-i list namespaces
did return yes\n
in its stdout after all.
By using --all-namespaces
, this warning disappears while still allowing kubel--can-get-namespace
to fail on other kubectl stderr warnings.
This pull request does not address the separate issue of kubectl get namespaces
not working even after kubectl can-i
returned yes\n
, but I think it does increase the chances of the user getting a namespace list out of the box.
Feel free to reject in any case!
Hi, thank you very much for submitting this. I am not 100% on top of the namespace story here and I would need to do some research to understand what's going on. Would you be able to explain or point me to a resource that could explain why --all-namespaces
is better?
@akanouras @abrochard Also facing the same issue.
Fixed it on my local by replacing equal
with s-suffix?
but as you mentioned in the previous issue the output of 'can-i' cannot be trusted completely.
Using --all-namespaces
will also fix this for my current env but might cause a issue if the role doesn't have access to all namespaces.
(I'm using a clusterrolebinding
without any namespace limitations. Maybe the warning occurs only in this scenario?)
@p4v4n thank you for chiming in there.
My design goal here is to have 3 possible values for kubel-use-namespace-list
: auto
, on
, off
. The last two are simple, they're user overrides. For auto
, the intent is to try to automatically figure it out. However, if auto
thinks that the user can list namespaces and it turns out that the user cannot (false positive case), the experience is going to be broken and some errors are going to be thrown. On the other hand, if auto
thinks that the user cannot list namespaces and it turns out that the user can (false negative case), the experience is diminished but not broken and the user can always set an override.
It's for that reason that I want to understand a bit more what --all-namespaces
does and if there's a risk of false positive. I'm more comfortable with keeping the false negative rate relatively higher in comparison.
@abrochard
Thanks for quick response and for clarifying the design decision. Makes sense that you want to avoid false positives.
Didn't check kubel-use-namespace-list
clearly before. Will use this from now on.
Regarding --all-namespaces
haven't found any clear documentation on the difference in kubectl can-i list
context except for this 1 comment.
https://github.com/kubernetes/kubernetes/issues/85869#issuecomment-565384309