ability to specify k8s version and not the image

[RafalSkolasinski]

What would you like to be added:

A --k8s-version or --version flag that would specify only the version of Kubernetes to be used in addition to --image.

Why is this needed:

Specifying different version of k8s using --image requires providing the full hash, for exmaple

1.20: kindest/node:v1.20.2@sha256:8f7ea6e7642c0da54f04a7ee10431549c0257315b3a634f6ef2fecaaedb19bab
1.19: kindest/node:v1.19.7@sha256:a70639454e97a4b733f9d9b67e12c01f6b0297449d5b9cbbef87473458e26dca
1.18: kindest/node:v1.18.15@sha256:5c1b980c4d0e0e8e7eb9f36f7df525d079a96169c8a8f20d8bd108c0d0889cc4
1.17: kindest/node:v1.17.17@sha256:7b6369d27eee99c7a85c48ffd60e11412dc3f373658bc59b7f4d530b7056823e
1.16: kindest/node:v1.16.15@sha256:c10a63a5bda231c0a379bf91aebf8ad3c79146daca59db816fb963f731852a99
1.15: kindest/node:v1.15.12@sha256:67181f94f0b3072fb56509107b380e38c55e23bf60e6f052fbd8052d26052fb5
1.14: kindest/node:v1.14.10@sha256:3fbed72bcac108055e46e7b4091eb6858ad628ec51bf693c21f5ec34578f6180

for 0.10.0.

This is:

• quite annoying
• renders script that automatically setup kind clusters only compatibly with certain kind version

If someone would be able to just specify --version 1.20 and Kind just selects appropriate image this would be much more user friendly.

[BenTheElder]

Specifying different version of k8s using --image requires providing the full hash, for exmaple

It does not require passing the full hash, but we strongly recommend it, because this ensures that images cannot change without you knowing it (the hash would change). It is important that you trust these images.

renders script that automatically setup kind clusters only compatibly with certain kind version

These images are only compatible with certain binary versions (see the release notes) while this project is in alpha. So for now this is harder than it sounds. Building these is also a bit expensive currently, but we're working on alternatives.

Scripts are also currently only compatible with certain kind versions because the CLI has changed. The tool is officially in alpha. https://kind.sigs.k8s.io/docs/contributing/1.0-roadmap/

If someone would be able to just specify --version 1.20 and Kind just selects appropriate image this would be much more user friendly.

Specifying an image is standard in the entire container tools space and applies the same to your pods etc. Instead I think we're more likely to make it separately more easy to identify available images and/or build your own.

It's also worth noting that 1.20 is not a kubernetes version and each patch has changes worth being aware of, I'm not sure as upstream maintainers that we'd want to encourage ignoring patch versions.

[RafalSkolasinski]

Thank you @BenTheElder for the reply.

It does not require passing the full hash, but we strongly recommend it, because this ensures that images cannot change without you knowing it (the hash would change). It is important that you trust these images.

So the strong recommendation comes more from security requirements than the compatibility?

These images are only compatible with certain binary versions (see the release notes) while this project is in alpha. So for now this is harder than it sounds. Building these is also a bit expensive currently, but we're working on alternatives.

Could then images compatible with certain kind version has its version in name? For exampel v1.20.2-0.10.0?

Specifying an image is standard in the entire container tools space and applies the same to your pods etc. Instead I think we're more likely to make it separately more easy to identify available images and/or build your own.

That's often true, yes, but when one wants to spin up kind cluster to just test app inside kubernetes what you more care is the version of k8s than the particular image running.

It's also worth noting that 1.20 is not a kubernetes version and each patch has changes worth being aware of, I'm not sure as upstream maintainers that we'd want to encourage ignoring patch versions.

Ah, that's my mistake, meant to write --name v1.20.2 with the patch version.

[BenTheElder]

So the strong recommendation comes more from security requirements than the compatibility?

Mostly yes. When we started the project dockerhub was handed but lacked 2FA etc. We still think this is a good idea in general.

Generally we try to ensure to the best we can (without literally running all scenarios with every version of the tool) that changes to images do not have any incompatibility with older versions of the tool, the opposite is not true (newer versions of the tool may assume improvements to how the images perform).

Could then images compatible with certain kind version has its version in name? For exampel v1.20.2-0.10.0?

Perhaps, though then each new version that still worked would require updating it. An updated tagging scheme is definitely being explored concurrently with possible build and registry changes.

There's an existing issue tracking how we publish images, I expect to have a proposal up in the next month, currently nobody has had much time as we've been working on changes in Kubernetes upstream.

That's often true, yes, but when one wants to spin up kind cluster to just test app inside kubernetes what you more care is the version of k8s than the particular image running.

I think that's true of most application images? I want to run app X at version Y. Here X is kindest/node and Y is :v1.20.2
Ideally we'd publish more versions pre-built, and make it cheaper to build versions we haven't. Both are priorities going forward #381 #197.

[BenTheElder]

I think this is currently out of scope for the project, there are some tricky issues to resolve first.

We should absolutely revisit this when we have a better story around managing the images.