kapp uses wrong default namespace when run in-cluster (with explicit KUBECONFIG
env var)
#728
Labels
bug
This issue describes a defect or unexpected behavior
What steps did you take:
kapp
/kctrl
in a Pod of a Kubernetes clusterKUBECONFIG
(and/orKAPP_KUBECONFIG
) to another cluster where no default namespace is setkapp ls
orkapp deploy
without a explicit namespaceWhat happened:
kapp
will default to the namespace of the execution environment (pod it is running in), although theKUBECONFIG
might point to a completely different cluster which doesn't have this namespaceWhat did you expect:
kapp
will install the manifests intodefault
namespace or the one explicitly configured inside theKUBECONFIG
Anything else you would like to add:
As a workaround it seems to explicitly unsetting
KUBERNETES_SERVICE_HOST
orKUBERNETES_SERVICE_PORT
seems to fix this behaviour as https://github.com/kubernetes/client-go/blob/1517ffb8d37c99e6a3a2842bcdee0aa271f0332b/tools/clientcmd/client_config.go#L604-L609 seems to check for that (thanks to @cppforlife for pointing this out in Slack)Environment:
kapp --version
): kapp version 0.54.1/etc/os-release
): Debian 11 (doesn't seem to matter)kubectl version
): not relevantVote on this request
This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.
👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"
We are also happy to receive and review Pull Requests if you want to help working on this issue.
The text was updated successfully, but these errors were encountered: