Open dewe opened 5 months ago
Happens to me as well, both with and without plugins. It seems to block me from choosing context for ~5 seconds with the following error: "😡 no connection to cached dial". Does not happen with k9s --context ...
.
Encountering the exact same problem as Emil, on K9s v0.32.4 and K8s v1.29.1.
I've also been encountering this issue. If I set a context explicitly prior to opening k9s, it's fine but I cannot switch to another context while in k9s without it breaking.
Another way to reproduce this is:
KUBECONFIG='' k9s
Not only does this issue prevent you from selecting a context, but is also the cause of another long standing issue I've had that k9s
will exit if you don't select a context fast enough.
We don't want to set a context (current-context: ""
) as we have many different k8s clusters and don't want any tooling connecting to one by default. We use the following as our ~/.kube/config
file, as generated by:
$ KUBECONFIG='' kubectl config view
apiVersion: v1
clusters: null
contexts: null
current-context: ""
kind: Config
preferences: {}
users: null
We thenhave a standalone config file per cluster, joined together in $KUBECONFIG
, e.g.
$ echo $KUBECONFIG
/home/foo/.kube/config:/home/foo/.kube/cluster-1:/home/foo/.kube/cluster-2:/home/foo/.kube/cluster-3
This all works 100% fine with kubectl --context context-1
.
Also tested by wiping out ~/.local/share/k9s
, ~/.local/state/k9s
, and ~/.config/k9s
.
Here's the full logs (KUBECONFIG='' k9s -l debug
):
i have this issue too
I got around my issue by specifying the context's namespace I had access to in my kube-config. I was not allowed to see all namespaces, but limiting it to a specific solved it.
I got around my issue by specifying the context's namespace I had access to in my kube-config. I was not allowed to see all namespaces, but limiting it to a specific solved it.
when we have mutiple cluster, we couldnt limit to specific namespace
The issue seems to be at the point where k9s tries to load plugins based on the context when said context is empty. I gave a PR a shot by just ignoring the loading of plugins from the context-based directory if the context comes empty.
Im also having this exact same issue
One additional situation that brings this up is when the gke-gcloud-auth-plugin
isn't available, k9s can't authenticate to the cluster, but the errors aren't passed up to the user. If e.g. you are using asdf, you may have to asdf reshim
to get the installed binaries to be available.
we are running k9s inside an container. In our case, there is no kubeconfig, only the in-cluster config.
It works months ago (until 0.29), but now it seems broken.
Facing the same on arch, kubernetes v1.28.2, k9s: v0.32.4
Observing this issue for one of the context, rest all context works well K9s Rev: v0.32.5 K8s Rev: v1.29.4-eks-036c24b
FWIW, I was having a similar issue this morning after putting my mac to sleep with multiple k9s running last week, and the local namespace config.yaml had some trash appended to the end of the file. Once I fixed the config yaml it was fine, and I discovered this by viewing the namespaces in the context, and when I tried to "use" the namespace I was after, it said it was missing a ":" on line 20, which was the end of the file, where I found some trash (part of the word "localhost", but without the "loc" at the start). So, perhaps unrelated, but may have some issue with multiple k9s instances viewing the same namespace saving the config on shutdown when the machine goes idle/sleep.
This issue appeared to me when I decided to rename my initially given deafult context names into something more meaninful for me. After k9s restart, the issue appeared. What I found interesting is when I opened my ~/.kube/config
file I found that the context names are correctly being renamed like I did in k9s throughout the file but - current-context
still had old context name defined (name prior to my renaming action).
:warning: Which means that this field is not being updated by k9s accordingly after the renaming nor after choosing some other context.
When I manually defined the current-context
to one of the new ones, it worked well, without issues but now it's hardcoded basically so I have to perform ctx to jump to another after initially being loaded to current-context
. It feels like k9s should have a control over current-context
value in ~/.kube/config
and define it to be last chosen context.
Additionally, like it was previously said, it would be sweet to have also no definition of context so that you basically need to choose one right from the start without any problems (some flag in k9s config.yaml file).
I fixed this by exporting the config file to the native Kubernetes path
microk8s config > ~/.kube/config
After doing this, just open K9s, and it worked fine (this worked for me as the k9s by default looks for the contexts in default k8s path)
When I manually defined the
current-context
to one of the new ones, it worked well, without issues but now it's hardcoded basically so I have to perform ctx to jump to another after initially being loaded tocurrent-context
. It feels like k9s should have a control overcurrent-context
value in~/.kube/config
and define it to be last chosen context.Additionally, like it was previously said, it would be sweet to have also no definition of context so that you basically need to choose one right from the start without any problems (some flag in k9s config.yaml file).
This seems only to be a problem in k9s version 0.32.5. I had the same issue and fixed it with a roll back to k9s version 0.31.5. After that it worked just fine without setting a current-context
in my config file.
Describe the bug When starting
k9s
without a current context set, there's an error telling me that Plugins load failed!. But when having a current context set, or specifying the --context flag when starting k9s, it works as expected. I have no plugins.To Reproduce
Historical Documents
k9s logs:
Expected behavior I'll end up in the k9s context meny with no error.
Versions (please complete the following information):