Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow exact version match #30

Open
jonhutchens opened this issue Nov 15, 2022 · 2 comments
Open

Allow exact version match #30

jonhutchens opened this issue Nov 15, 2022 · 2 comments

Comments

@jonhutchens
Copy link

In some scenarios, in may be desirable to have a config option to force an exact version match instead of using +-1 minor revision of the k8s cluster. For example, I'm seeing this issue where EKS seemingly has failed to properly support the +-1 minor version rule and thus kubectl 1.24 does not work with a 1.23 EKS cluster. So if there was an option for kuberlr to allow the user to specify an exact version match, we could workaround issues like this more easily. I'm guessing the use case could be even broader than this though.

@jandubois
Copy link
Contributor

I can see multiple potential policies that you may want:

  • allow current ±1 version skew
  • use exact match
  • use exact match or +1, in case you want to make use of a new beta feature that is not supported by the -1 client

But maybe it is good enough to use the exact version match policy for the last case as well, to keep things simple.

@mallardduck
Copy link

Based on my understanding of: rancher-sandbox/rancher-desktop#3370

It seems the root of the original issue came from kubectl version 1.24+ having removed client.authentication.k8s.io/v1alpha1. As such, any k8s cluster running 1.23, or lower, that utilizes client.authentication.k8s.io/v1alpha1 will begin experiencing issues*. (* = Assuming that the cluster in question uses ExecCredential to facilitate LDAP, Kerberos, OAuth2, SAML, etc.) So in the case of the original Rancher desktop issue report - it seems that the 1.23 EKS cluster is using ExecCredential still at the v1alpha1 api.

Overall, I think this instance highlights some of the benefits if kuberlr had a config to control version matching. As in a situation like that you might want to match more directly, rather than relying on version skew.

I think the 3 options mentioned would be great options to expose to the user. I could see them being presented as:

  • AllowSkew/default: Follow the ±1 version skew, but prefer the newest (current behavior, default),
  • ExactMatch: Use an exact match [Strict] (Only up to X.Y - the "Z" value is ignored essentially, favors newest Z),
  • PreferMatch: Prefer exact match or newer [use exact match or +1]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants