DRA: convert periodics to use pre-built kind images

[pohly]

What should be cleaned up or changed:

Cheaper than each job compiling from source.

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

Provide any links for context:

https://kubernetes.slack.com/archives/C2C40FMNF/p1734418756244779?thread_ts=1734417601.687079&cid=C2C40FMNF

cc @BenTheElder

[pohly]

@BenTheElder: on Slack you linked to https://kind.sigs.k8s.io/docs/user/quick-start/#building-images as documentation, but I don't see there how to find a pre-built kind image that matches the current Kubernetes source. Can you elaborate how that would work?

If a periodic job runs for a certain revision of the k/k repo, then I'd like to use a kind image built exactly for that revision. Otherwise detecting the exact revision which introduced a regression will be much harder. In particular, the revisions shown by testgrid would be misleading.

[pohly]

/wg device-management

[BenTheElder]

@BenTheElder: on Slack you linked to https://kind.sigs.k8s.io/docs/user/quick-start/#building-images as documentation, but I don't see there how to find a pre-built kind image that matches the current Kubernetes source. Can you elaborate how that would work?

I meant we can use pre-built kubernetes binaries, the cloud e2es consume from a shared job that publishes kubernetes CI builds with binaries / container images / tarballs of these.

kind has support to build a node image from those, so you skip compiling kubernetes and just download it instead, but you still pack that onto the base image.

[BenTheElder]

Right now we only have super convenient support for releases, where you can just do kind build node-image v1.32.0, but it can consume manually supplied kubernetes server tarball release URLs from dl.k8s.io, and you can compute that from looking up the latest CI build.

[BenTheElder]

like this shell one-liner: kind build node-image 'https://dl.k8s.io/ci/'"$(curl -sSL https://dl.k8s.io/ci/latest.txt)"'/kubernetes-server-linux-amd64.tar.gz'

[BenTheElder]

If a periodic job runs for a certain revision of the k/k repo, then I'd like to use a kind image built exactly for that revision. Otherwise detecting the exact revision which introduced a regression will be much harder. In particular, the revisions shown by testgrid would be misleading.

it's possible to write out the tested commit without it coming from the prowjob cloning it, a lot of the prowjobs using kubetest are doing this and not even cloning k/k at all, just fetching a build, and recording the commit from the build metadata.

e.g. https://prow.k8s.io/view/gs/kubernetes-ci-logs/logs/ci-kubernetes-e2e-gci-gce/1868903398972067840 doesn't clone but you can see commits in testgrid: https://testgrid.k8s.io/sig-release-master-blocking#gce-cos-master-default

this is via https://storage.googleapis.com/kubernetes-ci-logs/logs/ci-kubernetes-e2e-gci-gce/1868903398972067840/artifacts/metadata.json IIRC

[BenTheElder]

https://docs.prow.k8s.io/docs/metadata-artifacts/ (it's finished.json, which is containing a superset of the test-runner-written metadata.json)

[pohly]

Thanks, that should get me started.

/assign