Add node image for k8s 1.24.3

[rgl]

What would you like to be added:

I would like to have the node image for k8s 1.24.3 available at https://hub.docker.com/r/kindest/node/tags

Why is this needed:

This is required to keep up with the upstream releases at https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md

[BenTheElder]

Please see the docs about using node images from release notes: https://kind.sigs.k8s.io/docs/user/quick-start/#creating-a-cluster

these also cover how to build your own node images

There are other existing issues tracking image management, but for now we publish prebuilt images as needed for developing the project and then a spate of the latest patch versions when cutting a kind release.

we do not guarantee that mixing kind versions and image versions is compatible, though we do our best to keep it that way.

[BenTheElder]

there's an image for 1.24.3, it is not tested with kind v0.14.0 but we'll have something at least this new in v0.15.0 ~soon

[rgl]

Thank you for pointing out the build documentation and explaining what kind is tracking. That changed my ideia about kind. I thought it was a central piece of the k8s ecosystem that closely tracked/packaged the upstream k8s in way that allowed it to be sanely used in dev/ci environments.

FWIW, I find kind to be the most straightforward way to consume k8s, but not tracking upstream is a bummer for me. Even more so, because its such a joy to use.

May I ask why isn't it tracking upstream more closely? Are these k8s patch releases a PITA to test?

PS Oh the patch release might be a PITA accordingly to #197 (comment).

[aojea]

kind is tracking upstream, actually nothing can not be merged in master if it doesn't build and run with kind, you can track upstream with kind, but have to build your own node images.
Something different is that we publish node images for each release ...

[aojea]

https://kind.sigs.k8s.io/docs/user/quick-start/#building-images

[BenTheElder]

That changed my ideia about kind. I thought it was a central piece of the k8s ecosystem that closely tracked [...]

We do closely track, but we're not packaged by upstream, and there's mainly two of us handling packaging for kind.

May I ask why isn't it tracking upstream more closely? Are these k8s patch releases a PITA to test?

KIND @ HEAD supports Kubernetes @ HEAD, IE the latest kind code supports the latest Kubernetes code, continuously.

However, we cannot guarantee that Kubernetes hasn't made a breaking change that is not released yet inbetween Kubernetes 1.X releases.

Actually tracking the latest Kubernetes development on a continuous costs a lot of resources, and we're a small project, which doesn't leave a lot of energy for packaging.

So we don't necessarily get kind releases with every single point release of Kubernetes, given that users can build their own images that will support their current kind version.

In the future, when we can make it clearer the required kind version for a given image, we will revisit automated image publishing.

Are these k8s patch releases a PITA to test?

It's moreso, they're very intensive to build, and there's no easy way to do this automatically without being part of the upstream release process, and we sometimes have to make breaking changes between kind the tool and how the kind node image works, to keep up with linux or Kubernetes changes.

At any time, you can build your own images for any Kubernetes version and it will generally just work, even the absolute latest code. Occasionally it will require that you first install kind at the latest sources which you can do with make install.

Our first priority and reason for existing is testing Kubernetes itself, where kind is used to test every PR, so that's where the time goes mostly, that and user support for existing release content https://kind.sigs.k8s.io/docs/contributing/project-scope/

[BenTheElder]

In the future, I think we will adopt a tagging scheme like $kind_version-$k8s_version and automatically publish images, but first we have #2618 and some other related work, and our top priority is things like #2846 to keep up with Kubernetes's latest changes

[rgl]

Thank you for taking the time to explain this!

I now have a better understanding about the pain points of tracking k8s @ HEAD and the project role and scope (and shame on me for missing the project scope page that you've linked).

Tracking the released versions of k8s will be awesome! I for sure, will really appreciate them :-)

FWIW, the k0s project adopted a version scheme like $k8s_version+k0s.x as you could see at https://github.com/k0sproject/k0s/releases.