Option to unset the namespace for the current context

[mamiu]

Feature Request

The kubectx command has the flag -u / --unset to unset the current context.
This is currently not possible with the kubens command.

Please add a flag like -u (for unset) or -x (for delete / reset) to the kubens command to unset the namespace configured with kubens.

ATM this is only possible with the following kubectl command:

kubectl config unset contexts.<NAME-OF-THE-CURRENT-CONTEXT>.namespace

Reproduce

kubectl config get-contexts

# Output:
CURRENT   NAME      CLUSTER   AUTHINFO        NAMESPACE
*         example   example   admin@example

kubens demo-namespace

CURRENT   NAME      CLUSTER   AUTHINFO        NAMESPACE
*         example   example   admin@example   demo-namespace

Now it's impossible to reset the set namespace. Setting it to "default" also won't unset it but just set it to the "default" namespace.

The only option to reset the namespace is to unset it with the following kubectl command:

kubectl config unset contexts.example.namespace

[Akaame]

I have created a crude PR for implementing this behavior. However, now that the feature is here, I am wondering what is the concrete benefit of this for you over setting it to "default"?

[mamiu]

Wow, thanks a lot @Akaame!

The problem:

Applications like k9s will use the namespace set for a particular context by default every time you start them but won't adjust the namespace for that context even when you switch between namespaces (probably because it's a change to the kube config file and I guess that's something tools like k9s and Lens don't wanna touch). K9s always used to go to the last used namespace on open (which is stored in its config file), but now always goes to the namespace specified in the kube config file (which was set by kubens). Since I'm using k9s most of the time and the kubectl CLI (with kubectx and kubens) only from time to time, it always requires an extra step of switching to the desired namespace in k9s.

The benefit:

Having the option to just unset the namespace for a context with kubens -u is an easy and memorable step at the end of using the kubectl toolchain. Third party tools then are independent from the namespace setting in the kube config file.

[Akaame]

Okay. I also had the same problem when I was switching over from k9s to kubectx+kubens+fzf.

I tested the solution with k9s and kubens -u && k9s results in default namespace being selected. Sadly, kubens -u is the same as kubens default. So, this solution does not achieve what you had in mind. But weirdly,

kubectl config unset contexts.example.namespace

Also results in the same behavior that namespace key is deleted but k9s still uses default. Can you confirm that after unset you really get the list for all-namespaces?

https://github.com/derailed/k9s/blob/fc8ffe5d37d068f14e86aed7e8b847d016c99b19/internal/config/config.go#L97

Also confirms this.

So your options are:

• Use k9s -A
• Use kubectl config set contexts.example.namespace all (hacky)
• Create a fork of kubens where kubens -u sets namespace key to all (terribly hacky)

Cheers

[mamiu]

Yes I can confirm that after running kubectl config unset contexts.<MY_CONTEXT>.namespace k9s will always use the last namespace (as well as the last resource type).

If the last namespace was all and I was in the ConfigMaps view then after restarting k9s I'm again in the ConfigMaps view for all namespaces. If I'm in the Pods view for a specific namespace, close k9s and open it again, I'm again in the Pods view for that particular namespace.

I am using k9s version 0.25.18 and kubectl version v1.23.4.

[Akaame]

So let's say you executed kubens <MY_NS>
Then opened up k9s
You see pods in <MY_NS>
Then you close k9s
Execute kubectl config unset contexts.<MY_CONTEXT>.namespace

What is the NS you see in K9s? Is it still <MY_NS>, default or all?

[mamiu]

TL;DR

Just calling k9s will ignore any namespace setting in the kube config file (e.g. done by kubens) but will always use the last namespace (which is set in the k9s config file under the active namespace of the cluster).

Calling k9s with a context (like k9s --context my-cluster) will check the kube config file first and if a namespace is set for that particular context it will set the active namespace in k9s to that namespace. If no namespace is set for that context, k9s will set the active namespace to all and will show all namespaces.

Detailed explanation with examples

Ok, so lets assume you run kubectl config get-contexts and get this output:

CURRENT   NAME              CLUSTER           AUTHINFO                NAMESPACE
          another-cluster   another-cluster   admin@another-cluster
*         my-cluster        my-cluster        admin@my-cluster

If you now call kubens a-namespace and then run kubectl config get-contexts again, you'll get:

CURRENT   NAME              CLUSTER           AUTHINFO                NAMESPACE
          another-cluster   another-cluster   admin@another-cluster
*         my-cluster        my-cluster        admin@my-cluster        a-namespace

(The NAMESPACE for my-cluster is set to a-namespace now.)

The next step is important and might have caused confusion, because you have two options which have a different behavior.

1. Just call k9s: k9s

If you just run k9s without passing a context, k9s will look at its config file (~/.config/k9s/config.yml) and will use the namespace specified under clusters.<YOUR_CLUSTER_NAME>.namespace.active. By switching between namespaces in k9s, k9s will update the active namespace. So just running k9s completely ignores the setting done with kubens. So if you set the active namespace in k9s to all, then close k9s, then run kubens some-namespace and then open k9s again, you'll still get all namespaces.

k9s:
  [...]
  currentContext: my-cluster
  currentCluster: my-cluster
  clusters:
    my-cluster:
      namespace:
        active: some-namespace
        favorites:
        - all
        - kube-system
        - another-namespace
      view:
        active: po
      [...]

2. Call k9s with a context: k9s --context my-cluster

Passing a context to k9s changes the logic of which namespace is selected when k9s is opened. That means k9s will load the namespace that is set in the kube config file (e.g. by setting it with kubens) for the specified context.

So if you run kubens some-namespace the output for kubectl config get-contexts should be:

CURRENT   NAME              CLUSTER           AUTHINFO                NAMESPACE
          another-cluster   another-cluster   admin@another-cluster
*         my-cluster        my-cluster        admin@my-cluster        some-namespace

If you now open k9s with passing my-cluster as context (k9s --context my-cluster), the some-namespace namespace will be active.

If you then change the namespace to let's say kube-system, close k9s and open it again with just k9s it'll open the kube-system namespace.

If you unset the namespace for your context (e.g. with kubectl config unset contexts.my-cluster.namespace) and open k9s again with a context (k9s --context my-cluster) it'll set the active namespace of k9s to all and the resources from all namespaces will be shown.

[Akaame]

Okay, unknowingly I was on a super old version of k9s. So the process you have described was not the case for me and sorry for taking your time. Will test the PR branch following the steps you have laid out and ping the repo owner for a review if everything works expectedly.

Thanks and cheers

[Akaame]

Test

Steps:

• kubens <MY_NS>
• k9s --context <MY_CTX>

Result: Shows pods from <MY_NS>

Then:

• kubens -u
• k9s --context <MY_CTX>

Result: Shows pods from all namespace under <MY_CTX>

---

Sorry for not checking my k9s version and dragging the discussion. I think the results cover your scenario.

@ahmetb Abi merhaba,

Would it be possible for you take a quick look at the PR?

[mamiu]

@Akaame No worries at all! It also helped me to understand the logic behind namespace handling of kubectl, kubens and k9s better.

And yes, your test steps and expected results are concise and accurate.