Open 5nafu opened 3 years ago
Nokel81
commented
3 years ago Would having the merge only occur within a single folder sync be an acceptable solution? We don't look at the KUBECONFIG env var at all. Though I guess we could.
Note to future implementer:
After playing around with kubectl config view it seems like the merge rules prefer the order that the files are specified and ignore duplicates from subsequent files.
5nafu
commented
3 years ago Hi @Nokel81, thanks for your answer, for our usecase this would be absolutely fine, though I can not say if others may sort the configuration differently.
brad-jones
commented
3 years ago Yes please honor KUBECONFIG, I also just installed https://k9scli.io/ & it worked out of the box with zero config. If I want to use Lens I now need to maintain two sets of config, not ideal.
tgruenert
commented
2 years ago I´ve run in this case today. My scenario is sharing configuration files without any user specific credentials. These are not necessary if using OIDC auth. So i have one config file for user to authenticate via oidc (kubelogin) and one file per cluster which refers to user. So it would be really nice to see a solution for splittet config files.
Describe the bug If dividing the kubeconfig into different files, Lens will not be able to load it and does not provide syncing
To Reproduce
config.ddirectory01_preferences,02_context, ...)lensadd Configuration Sync of the above created directoryKUBECONFIGenvironment variable with all files above and check thatkubectlallows access to the cluster(s) configuredExpected behavior I would expect lens to merge the configurations and present the configured clusters.
Environment (please complete the following information):
Logs: When you run the application executable from command line you will see some logging output. Please paste them here:
Kubeconfig: Quite often the problems are caused by malformed kubeconfig which the application tries to load. Please share your kubeconfig, remember to remove any secret and sensitive information.
Additional context We have (multiple) Rancher cluster with different downstream kubernetes clusters. The Rancher system is working as an authentication proxy, resulting in the same user/token being used in multiple contexts. Additionally we do have testing accounts for different access levels to the clusters, resulting in multiple cluster configurations being used in multiple contexts as well.
To be able to more easily rotate tokens (more often) or URLs (less often), we divide the configuration into multiple files, each containing only a single component. kubectl (and other tools) are able to read those file and merge the config even over file boundaries.