[eks] [request]: Use correct SemVer for Kubernetes version

[stevehipwell]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Tell us about your request
I'd like the EKS Kubernetes version to be a valid Semver 2 version, meaning no pre-release segment if it's not a pre-release.

Which service(s) is this request for?
EKS

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
The current Kubernetes version for EKS is an incorrect pre-release SemVer version (e.g. v1.18.9-eks-d1db3c) and causes any automation expecting a valid SemVer to fail. It looks like this is because you're trying to store two pieces of data in a variable only capable of storing one.

This means that Helm charts which use .Capabilities.KubeVersion.Version for conditional logic either need to provide a static override or manually sanitise the version to remove the pre-release segment.

Releated issue prometheus-community/helm-charts#1071.

Are you currently working around this issue?
For Helm this is only possible in some scenarios when the author of the chart has already come across this issue and has enabled the version to be set manually or sanitises the version to ignore pre-release segments.

Additional context
n/a

Attachments
If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)

[stevehipwell]

With the EKS v1.21 release this has become even worse as the version being reported is still a SemVer pre-release without the identifying eks flag meaning that a number of workarounds for the original issue are broken (e.g. kube-prometheus-stack).

EKS v1.21

Server Version: version.Info{Major:"1", Minor:"21+", GitVersion:"v1.21.2-13+d2965f0db10712", GitCommit:"d2965f0db1071203c6f5bc662c2827c71fc8b20d", GitTreeState:"clean", BuildDate:"2021-06-26T00:59:14Z", GoVersion:"go1.16.5", Compiler:"gc", Platform:"linux/amd64"}

EKS v1.20

Server Version: version.Info{Major:"1", Minor:"20+", GitVersion:"v1.20.4-eks-6b7464", GitCommit:"6b746440c04cb81db4426842b4ae65c3f7035e53", GitTreeState:"clean", BuildDate:"2021-03-19T19:33:03Z", GoVersion:"go1.15.8", Compiler:"gc", Platform:"linux/amd64"}

[georgejohnis]

The version notation change introduced in the release of EKS v1.21 (removal of "eks") has since been addressed. The 1.21 version now looks similar to how it was with shown for previous EKS versions. However the original issue raised here (usage of pre-release tag) has not been addressed yet but we are closely monitoring the 👍 reaction to the issue here to help with our prioritization decision.

[z0rc]

@georgejohnis with EKS 1.22 issue returned.

Server Version: version.Info{Major:"1", Minor:"22+", GitVersion:"v1.22.6-eks-7d68063", GitCommit:"f24e667e49fb137336f7b064dba897beed639bad", GitTreeState:"clean", BuildDate:"2022-02-23T19:29:12Z", GoVersion:"go1.16.12", Compiler:"gc", Platform:"linux/amd64"}

[nfisher]

@z0rc I think that's the "supported" behaviour and they're looking for enough community pressure to prioritise alignment to standard semver formatting. From this Helm issue it sounds like there's a non-trivial amount of effort to change it.

Should make the Kubernetes cluster conformance suites fail on invalid semver as it really becomes a burden of Helm chart authors who are probably too busy shipping features to search for this issue.

[stevehipwell]

I'm not sure why the build metadata part of the SemVer spec isn't being utilised here?

E.g v1.22.6+eks.7d68063

[nfisher]

@stevehipwell while unfortunate, I don't think it matters at this point for 2 reasons:

1. you're potentially breaking a number of AWS customers who have adapted to their revision format.
2. AWS probably has a lot of known and unknown things dependant on that formatting so it's a non-trivial transition.

[stevehipwell]

@nfisher I'd strongly disagree and say that it still matters, but I'm not expecting a change any time soon. This "decision" to not follow SemVer spec literally makes no sense given the high level Kubernetes version based architecture and the fact that there is a documented pattern for carrying extra version metadata.