kubernetes-sigs / kind

Kubernetes IN Docker - local clusters for testing Kubernetes
https://kind.sigs.k8s.io/
Apache License 2.0
13.55k stars 1.57k forks source link

provide machine-readable list of images for release #2376

Open kd7lxl opened 3 years ago

kd7lxl commented 3 years ago

We use kind in our CI to test against multiple versions of Kubernetes. We want to verify our code against the three latest minor versions of Kubernetes. We want to be able to automate discovery of the corresponding kindest/node images for these releases.

The docs suggest the procedure to discover the image tags is to read the release description: https://github.com/kubernetes-sigs/kind/releases/tag/v0.11.1

Images built for this release:

  • 1.21: kindest/node:v1.21.1@sha256:69860bda5563ac81e3c0057d654b5253219618a22ec3a346306239bba8cfa1a6
  • 1.20: kindest/node:v1.20.7@sha256:cbeaf907fc78ac97ce7b625e4bf0de16e3ea725daf6b04f930bd14c67c671ff9
  • 1.19: kindest/node:v1.19.11@sha256:07db187ae84b4b7de440a73886f008cf903fcf5764ba8106a9fd5243d6f32729
  • 1.18: kindest/node:v1.18.19@sha256:7af1492e19b3192a79f606e43c35fb741e520d195f96399284515f077b3b622c
  • 1.17: kindest/node:v1.17.17@sha256:66f1d0d91a88b8a001811e2f1054af60eef3b669a9a74f9b6db871f2f1eeed00
  • 1.16: kindest/node:v1.16.15@sha256:83067ed51bf2a3395b24687094e283a7c7c865ccc12a8b1d7aa673ba0c5e8861
  • 1.15: kindest/node:v1.15.12@sha256:b920920e1eda689d9936dfcf7332701e80be12566999152626b2c9d730397a95
  • 1.14: kindest/node:v1.14.10@sha256:f8a66ef82822ab4f7569e91a5bccaf27bceee135c1457c512e54de8c6f7219f8

Are these published in any machine-readable way? It would be great if they were published in something like json.

I've developed a kludge/workaround that scrapes the body of the release notes from the Github API, but this doesn't seem like a reliable long term solution.

% curl -sS "https://api.github.com/repos/kubernetes-sigs/kind/releases?per_page=1" | jq '.[].body' -r | sed -nE 's/ - ([0-9\.]+): `(kindest\/node:.+)`/{"\1": "\2"}/p' | jq -s add
{
  "1.21": "kindest/node:v1.21.1@sha256:69860bda5563ac81e3c0057d654b5253219618a22ec3a346306239bba8cfa1a6",
  "1.20": "kindest/node:v1.20.7@sha256:cbeaf907fc78ac97ce7b625e4bf0de16e3ea725daf6b04f930bd14c67c671ff9",
  "1.19": "kindest/node:v1.19.11@sha256:07db187ae84b4b7de440a73886f008cf903fcf5764ba8106a9fd5243d6f32729",
  "1.18": "kindest/node:v1.18.19@sha256:7af1492e19b3192a79f606e43c35fb741e520d195f96399284515f077b3b622c ",
  "1.17": "kindest/node:v1.17.17@sha256:66f1d0d91a88b8a001811e2f1054af60eef3b669a9a74f9b6db871f2f1eeed00 ",
  "1.16": "kindest/node:v1.16.15@sha256:83067ed51bf2a3395b24687094e283a7c7c865ccc12a8b1d7aa673ba0c5e8861",
  "1.15": "kindest/node:v1.15.12@sha256:b920920e1eda689d9936dfcf7332701e80be12566999152626b2c9d730397a95",
  "1.14": "kindest/node:v1.14.10@sha256:f8a66ef82822ab4f7569e91a5bccaf27bceee135c1457c512e54de8c6f7219f8"
}
BenTheElder commented 3 years ago

This sounds nice, they're not currently, and they're pushed and the hashes recorded by hand currently, so this would be somewhat kludgey to produce ourselves.

We'd love to automate that, but there's several other issues related to image publishing we need to look at first #1895 etc. and these are just published as a convenience https://kind.sigs.k8s.io/docs/contributing/project-scope/

This issue seems strongly related to #2349 #2114 in particular.

kuisathaverat commented 2 years ago

One small thing that could help here, right now the images published are 1.20.1, 1.21.1, 1.22.1, 1.23.1, ... this means that there is no tag I can use in the Docker registry API to grab the latest available version for the line 1.20, or 1.25. Publish the latest version available of each line will allow to detect a new version and make a PR in our repos with the changes to update to the new version. For example, the current 1.25.3 is the latest version if I publish the 1.25 tag too along with 1.25.3, I can use updatecli to make a PR updating the version and testing if the new Docker image will work before making any change.

BenTheElder commented 2 years ago

You should not just be grabbing tags from the registry, they may not work with the kind version you are using. See the docs, release notes and the linked issues.

programmer04 commented 1 year ago

We have a similar problem in Kong/kubernetes-ingress-controller. For our use case, it would be good enough just to grab the newest available version for each minor K8s version supported by us. But kindtest/node images unfortunately do not have tags like 1.27, 1.26, etc. I know that specifying the exact version is more robust, but it is tedious to keep them up to date in the tests matrix.

Would you mind starting tagging the newest patch version for each minor with the minor only tag too? E.g. kindest/node:v1.27.3 should have the tag kindest/node:v1.27 too. It's common practice for images e.g. Linux distro's based images, programming languages images, etc. I think (keeping in mind the comment above) it would be just good enough for many use cases

BenTheElder commented 1 year ago

Would you mind starting tagging the newest patch version for each minor with the minor only tag too? E.g. kindest/node:v1.27.3 should have the tag kindest/node:v1.27 too. It's common practice for images e.g. Linux distro's based images, programming languages images, etc. I think (keeping in mind the comment above) it would be just good enough for many use cases

We might, but realistically the focus is on completely revamping the entire image publishing to registry.k8s.io with a different scheme which will require immutable tags because of how kubernetes the project manages things. We have discussion about that in another issue open in the tracker.