Kind: support building node images from release tarballs

[BenTheElder]

We should implement kind build node-image --type=release-tar /path/to/release.tar and use this for CI testing to dedupe building the binaries etc.

/kind feature
/priority important-soon
/assign

[BenTheElder]

punting to 0.4, but just because 0.3 was loaded down with breaking image change improvements and we need to get those out the door. this is an important feature.

[BenTheElder]

punting to 0.5, 0.4 is focused primarily on networking enhancements / fixes, general bugs / cleanup / minor features, and initial IPv6 support.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[BenTheElder]

xref: #197
I've been sketching up a revamp of the entire build, intend to ship in v0.9.0

[dims]

cc @jiatongw

[jiatongw]

@BenTheElder What is the target date of v0.9.0?

[BenTheElder]

Sorry I missed this message. After some thought v0.9.0 was moved to match Kubernetes 1.19 (not everything we wanted is ready, but it's getting long in the tooth since 0.8.1), which is scheduled for tomorrow.

I'm sweeping through issues and will try to finish up patches for most things, but this one will probably slip to early in the next version.

Some refactors related to this are done, but it's not complete, and there are a couple bugs that should get fixed first.

[BenTheElder]

This is definitely a 1.0 blocker, and I'd like it as a "beta" blocker as well, will probably update https://kind.sigs.k8s.io/docs/contributing/1.0-roadmap/ to have this under beta requirements (which we've _mostly_ otherwise finished, we're nearing ready to go beta in the APIs / stability...)

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[rosti]

@BenTheElder should kind fetch files directly from the release tar? Isn't it more flexible WRT workflow and possible future changes (e.g. somebody decides to use xz instead of gzip, or the paths in the tar file change)?

I've got a patch implementing the following workflow:

wget https://dl.k8s.io/v1.20.0/kubernetes-server-linux-arm64.tar.gz
tar zxf kubernetes-server-linux-arm64.tar.gz
kind build node-image --type bindir --kube-root kubernetes/server/bin

But I can extend it to use the tar ball directly if you insist on that.

[rosti]

/remove-lifecycle stale

[BenTheElder]

@BenTheElder should kind fetch files directly from the release tar? Isn't it more flexible WRT workflow and possible future changes (e.g. somebody decides to use xz instead of gzip, or the paths in the tar file change)?

I think most users are not going to want to even deal with wget and downloading isn't the challenging part.

They'll just want to specify a release or CI version, OR specify their source URL | directory.

Isn't it more flexible WRT workflow and possible future changes (e.g. somebody decides to use xz instead of gzip, or the paths in the tar file change)?

The k8s release may not do this without warning, there are other consumers and the release format is "an API".
I will personally raise another stink if SIG release goes to break this again without following a KEP etc. (think the hash file debacle).

---

What I've actually wanted to do here is introduce a flexible spec format for control over what goes into a node image.
Unfortunately no features are shipping right now (including feature review) because all our time is going to bug hunting or non-kind related work, otherwise we'd have cut a release already :( (e.g. #1969 is alarming and needs fixing).

[BenTheElder]

aside: as a more immediate measure, I'm sure you could get a lot of kudos from people with arm macs in the coming weeks if you publish an image like this to dockerhub or similar :+))

we're obviously going to need a more permanent solution, but as it stands we've grown a backlog reviewing features due to the bug / support load 😞

I hope to improve that soon, I've just sunk some time into https://kind.sigs.k8s.io/, particularly the contributor / developer docs, and I hope to announce some improvements to how the project is managed soon 😅

[rosti]

I uploaded 1.18.13, 1.19.5, and 1.20.0 images here.

P.S. Docker on M1 Macs seems to be a long way off, plus I think that it wouldn't be that big deal to recompile Kubernetes from source there as it is for Raspberry Pi 4 (hence this effort).