-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
namespace defaults to in-cluster namespace when run with explicit KUBECONFIG
#1241
Comments
It's funny how the logic was here for years, and I got down to tracking down this behaviour to this logic where the library explicitly avoids using the implicit default namespace today and noticed your issue just as I was about to file my own, just hours after yours :-) To provide an example of where this happens is when one runs |
(sorry for the off-topic, just scroll on - but this needs to be said): whats even more funny is the fact that my whole endeavor finding this issue was intially caused by wrong kubeconfigs in kapp inside kuttl runs - an issue that you seem to have reported and fixed, but I was running an older version of kuttl with the bug present. If I would have updated, I would never run into this. Small small world... |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale
|
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
/remove-lifecycle rotten |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
When a
KUBECONFIG
is set explicitly to a external cluster, the client still defaults to the namespace mounted in/run/secrets/kubernetes.io/serviceaccount
. This means the same kubeconfig setting/file will behave differently depending if it is run inside or outside of a cluster.IMHO this should be changed to default to the
default
namespace as if run outside of the cluster. Defaulting to the serviceaccount's namespace doesn't really make sense here as the referenced cluster might not even have this namespace and it leads to inconsistent and unexpected behaviour.The text was updated successfully, but these errors were encountered: