Cannot connect to the cluster: An unknown problem occurred. Consider taking a peek at the debug logs.

[bala-gif]

I have my k8s cluster up and running in EKS.

When I pass the kubeconfig file to Monokle app. It cannot connect to the cluster.

[GilbertGeliba]

For me, it seems like related to spaces in context name, e.g. cluster-id-John Smith-namespace. This context name is created by a CLI tool that does user authentication in my company.
If I manually edit the kubeconfig file and remove the spaces, I can connect to the cluster.

[olensmar]

thanks for adding that detail @GilbertGeliba - very helpful!

[bala-gif]

Nothing helped. I dont see any space issue in my kubeconfig file.. Adding more detailed info in debug logs would help much to narrow down.

[root@ ~]# kubectx
eks@eksxxx.us-east-1.eksctl.io
eks@xxx-22853.eu-west-1.eksctl.io

[11:02:57 - stderr]
Cannot connect to the cluster: An unknown problem occurred. Consider taking a peek at the debug logs.

[StefanSa]

Hi there,
the same Bug here.
any Help ?

[Serverfrog]

The thing i found (PS: Pressing on View Debug Logs doesn't bring up the debug log location)

[2024-02-28 15:46:25.244] [browser] [info]  [kubectl-proxy]: Append Server Path enabled.
[2024-02-28 15:46:25.300] [browser] [info]  [kubectl-proxy] {
  type: 'stderr',
  content: 'Error: flags cannot be placed before plugin name: --context=k3d-default\n',
  timestamp: 1709131585300
}
[2024-02-28 15:46:25.306] [browser] [info]  [kubectl-proxy] {
  type: 'exit',
  content: 'Exited with code 1',
  code: 1,
  timestamp: 1709131585306
}
[2024-02-28 15:46:25.306] [browser] [error] Cluster error reason: exit_before_resolve

[joebowbeer]

In my case (MacOS connecting to EKS), the debug log just shows a kubectl proxy command

kubectl --context="arn:aws:eks:us-west-2:XXX:cluster/YYY" --kubeconfig="/Users/me/.kube/config" \
  proxy --port=30007 --append-server-path=true

If I run this myself, I see:

error: listen tcp 127.0.0.1:30007: bind: address already in use

If I remove the --port argument, then the proxy runs and seems to be working.

Perhaps this provides a clue?

[WitoDelnat]

Hi folks!

We're having some trouble to reproduce the EKS connectivity problem. We tried with several (new and old) clusters and all of them connect. The authentication works with an ExecConfig using aws eks get-token under the hood (found in the kubeconfig).

As for debug logs, they would only show after the proxy properly started, which does not help if the proxy boot itself fails. @monojack made a patch release last Thursday to improve logging. Unfortunately, that does still not fix the EKS connectivity issue but it might uncover more information as to why it fails on your end.

For those who reached out to us:

• @GilbertGeliba: The release also included a minor fix to properly stringify parameters so your problem should no longer happen.
• @Serverfrog: from the logs we believe you are still on the old version, can you update and try again? The previously mentioned fix might also have fixed your problem.
• @joebowbeer, @bala-gif, @StefanSa: From Joe's latest message it seems that despite the improved logging, we still have no insight into what causes the problem. Would anyone be open to join our Discord and have a short call with us to get to the root cause of this problem?

Thank you all for taking the time to report this to us.

[GilbertGeliba]

Hi folks!

We're having some trouble to reproduce the EKS connectivity problem. We tried with several (new and old) clusters and all of them connect. The authentication works with an ExecConfig using aws eks get-token under the hood (found in the kubeconfig).

As for debug logs, they would only show after the proxy properly started, which does not help if the proxy boot itself fails. @monojack made a patch release last Thursday to improve logging. Unfortunately, that does still not fix the EKS connectivity issue but it might uncover more information as to why it fails on your end.

For those who reached out to us:

• @GilbertGeliba: The release also included a minor fix to properly stringify parameters so your problem should no longer happen.
• @Serverfrog: from the logs we believe you are still on the old version, can you update and try again? The previously mentioned fix might also have fixed your problem.
• @joebowbeer, @bala-gif, @StefanSa: From Joe's latest message it seems that despite the improved logging, we still have no insight into what causes the problem. Would anyone be open to join our Discord and have a short call with us to get to the root cause of this problem?

Thank you all for taking the time to report this to us.

For the third issue, I guess it is related to the kubectl version. I am using v1.20.15 due to our cluster version.
I am getting this error

[11:09:01 - stderr]
Error: unknown flag: --append-server-path\nSee 'kubectl proxy --help' for usage.\n
[11:09:01 - exit]
Exited with code 1

[joebowbeer]

I repro'd again on MacOS with version 2.4.8:

Cannot connect to the cluster of my-eks-context. The proxy could not be started.

Debug logs

kubectl --context="my-eks-context" --kubeconfig="/Users/me/.kube/config" proxy --port=30027 --append-server-path=true

Headlamp, Lens and Octant can now connect. (Headlamp added support recently.)