This message was deleted.

kubectl

installed by Rancher Desktop is actually

kuberlr

, as you already noticed. It will automatically download and use a compatible version of

kubectl

as the backend: it just checks the kube version of the apiserver, and then `exec`s to the compatible

kubectl

to perform the actual work.

Hmm, that makes sense as the kubernetes skew policy is +-1 minor revision as you mentioned. However, I have a 1.23 EKS cluster that I’m trying to connect to (we recently upgraded from EKS 1.22 to 1.23). Now whenever I try to execute a kubectl command I get

error: exec plugin: invalid apiVersion "<http://client.authentication.k8s.io/v1alpha1|client.authentication.k8s.io/v1alpha1>"

I tried this manually via the kubectl binaries in

~/.kuberlr/darwin-amd64/kubectlx.x.x

kubectl 1.24 gets the above error when trying to hit this cluster. I’m guessing kuberlr is taking the latest compatible version which should be 1.24 if the server is 1.23, so that makes sense if 1.24 is selected.

Not sure. If it isn't an EKS issue, then it would be a violation of the version skew policy. Given that the

kubectl

binaries in the kuberlr cache are from upstream releases, it wouldn't seem wrong to ask EKS support why this doesn't work. I have no idea if they respond to this or not though.

Yes that would be very helpful in a case like this

Yes, please! We'll then follow up with Flavio as needed, or make a PR directly, if that's what we are going to decide on.

Thank you!