k9s config.yaml does not persist config for multiple k8s clusters

[gazpwc]

Describe the bug
The k9s config.yaml contains a section clusters: which can store different configurations for individual clusters (at least for my understanding). Unfortunately, this config gets overwritten whenever k9s is used to connect to another cluster. It does always only contain the settings for the currentCluster.

I already described the behaviour in #1247 when using kubie but it is also reproducible with native k9s.

To Reproduce
Steps to reproduce the behavior:

1. Start k9s using k9s --kubeconfig ~/.kube/configA --context contextA
2. Close k9s
3. Check config.yaml (on Mac /Users/me/Library/Application Support/k9s/config.yml
4. Find section:

k9s:
  clusters:
    clusterA:
.
.

4. Start k9s using k9s --kubeconfig ~/.kube/configB --context contextB
5. Close k9s
6. Check config yaml (on Mac /Users/me/Library/Application Support/k9s/config.yml
7. Find section:

k9s:
  clusters:
    clusterB:
.
.

8. But also see that the settings for ConfigA no longer exists and got removed.

Expected behavior
I would expect that k9s is able to store configurations (like last used namespace, view, ...) for multiple clusters and is able to persist that in the config.yaml also after switching from one cluster to another.

Versions (please complete the following information):

• OS: macOS 12.0.1
• K9s: 0.25.8
• K8s: 1.20.9

[derailed]

@gazpwc Thank you for reporting this! The current design tries to sanitize the context configurations to ensure unused contexts are wiped. Thus when you specify a different kubeconfig the sanitization process is triggered and any invalid contexts are cleaned up. So this is by design. If you wish to preserve the k9s cluster state you should be able to leverage KUBECONFIG env var to specify the various kube configs you need to connect to and your k9s context configs would be preserved. Does this make any sense?

[gazpwc]

Hi @derailed ,

thanks for getting back to me.

This might work, but for my way of working it's quite inconvenient to modify the KUBECONFIG env var each time I switch to a different cluster, since I need to do that a couple of times per day or even hour.

That's why I opened the first issue #1247 based on my findings with kubie (https://github.com/sbstp/kubie).
This tool allows to have your KUBECONFIGs in different files and you can easily jump from one cluster to another.

But if if the cleanup process is implemented intentionally, is it possible to make that optional? I could perfectly live with some invalid contexts in my k9s config file. For me, that would be the the smallest inconvenience by far compared to the others. 😃

[blacksd]

I came here to second this - I have many KUBECONFIGs for lots of various environments, and I hate with a passion losing my favorite namespaces, nodeShell settings, etc. on every switch (happens multiple times a day).

Edit to add: as @derailed mentioned, I already use a method to pass dynamically the single KUBECONFIG I need to my current shell, and no more than one at a time. I purposely want to keep those separated in order not to mix even accidentally cluster access.

[tobilau]

I'd like to second this feature as well. This would make working with different clusters and many namespaces even more convenient.
Currently I am maintaining a set of bash alias for connecting to the different clusters e.g.

alias clusterA="k9s --kubeconfig ~/.kubeconfig/clusterA"
alias clusterB="k9s --kubeconfig ~/.kubeconfig/clusterB"

So maybe it would be sufficient if there's an option to specify the config path, e.g.

alias clusterA="k9s --kubeconfig ~/.kubeconfig/clusterA --config ~/.config/k9s/clusterA.yaml"

[gazpwc]

Hi @derailed,

since it seems that I am not alone with that wish, do you see any chance to make that sanitization process optional in one of the future releases? That would hugely enhance my user experience.

[parsec]

@derailed any updates on this issue? We use kctx at work to manage multiple contexts, and I'd really like to be able to save favorites for each Kubernetes context. But every time I modify the config file and then open k9s, it wipes it to a default file.

I understand that this is "expected behavior" here, but a lot of people use k9s like I do with multiple kube contexts, so I believe this is an important consideration.

I would also be happy to look into submitting a PR for this if you don't mind pointing me in the right direction for where this behavior is in the codebase, I just noticed a long period of radio silence on this issue so was hoping to re-engage it.

[evgmoskalenko]

I also encountered a similar issue with the latest version of k9s, when skins were moved to the config for each cluster :-) Now, after my settings, everything gets constantly overwritten - #2336

This parameter helped me - KeepMissingClusters: true. Although, this seems more like a workaround. Previously, it was more convenient to work with skins.

[fawaf]

definite +1 here as well. another option would be to support specifying the k9s config itself on the cli. i don't believe that is an option at this time.

[derailed]

Thank you all for piping in!
I think as of v0.30.x the original ticket can be closed as the specific cluster/context config now live outside the general config and are no longer managed by k9s. Your kubeconfig changes should no longer affect the configurations as it is now the responsibility of the user to axe extraneous clusters/contexts configurations.
As for skins, you can now use a default skin aka ui.skin=xxx in the base config for all your clusters or customiize a specific cluster/context via skin=xxx in that context config.yaml.